从大厂基础架构搬砖人的视角聊聊技术探索那些事儿

作者：一个在字节基础架构组搬砖了五年的后端老哥 标签：技术探索、开源、Rust、AI大模型、职场感悟

---

写在前面

先做个自我介绍吧。我在字节跳动基础架构组干了快五年了，日常就是跟各种中间件、基础设施打交道。去年年底刚跳槽到现在的公司（具体哪家公司就不说了，免得被HR找上门），入职到现在刚好两个月。

说来也巧，新公司这边节奏比字节还猛，刚来第二周就被拉进了一个AI相关的项目组。为啥？因为leader看了我的简历，上面写了我平时喜欢研究开源项目源码，还写了最近在学习Rust。好家伙，这不就是给我量身定做的坑位嘛（苦笑）。

今天想跟大家聊聊我在技术探索和实践方面的一些心得。不是那种高大上的方法论，就是纯纯的个人经历和踩坑记录。希望能给正在迷茫或者想要突破技术瓶颈的同学一点启发。

---

一、简历上写的那些东西，到底该怎么写？

说到这儿，必须先吐槽一下我改简历的经历。

上个月投简历的时候，我把之前写的简历翻出来看了一遍，差点没把自己看吐了。什么"精通Java"、"熟悉分布式系统"、"了解Kubernetes"……这些词儿写得我自己都不信。

后来一个在猎头公司工作的朋友跟我说了一句话，让我醍醐灌顶："简历上写的每一个字，面试官都会往死里问。你写'精通'，他就问源码级别的细节；你写'熟悉'，他就问原理和最佳实践；你写'了解'，他就问基本概念和使用场景。"

所以我后来改简历的策略就是：

原来的写法	修改后的写法	效果
精通Java并发编程	深入阅读过JUC源码，对AQS、ConcurrentHashMap等有源码级理解	面试官直接跳过基础问题，聊源码实现
熟悉微服务架构	在字节负责过RPC框架的核心模块开发，日均处理请求量xx亿	直接聊项目细节和技术选型
了解Rust	最近在用Rust重写一个内部工具，对所有权机制和生命周期有实践经验	面试官来了兴趣，多聊了半小时

划重点：简历上不要写虚的，要写具体的、可量化的、能展开聊的东西。

特别是最近大模型这么火，很多人简历上都会写"了解LLM"、"使用过ChatGPT"之类的。我的建议是，如果你真的只是用过几次，那就别写了。面试官一问深了，你就尬住了。

但如果你真的想往AI方向转，我建议你至少做以下几件事：

1. 动手跑通一个开源模型：比如Llama系列，本地部署一个7B或者13B的模型，跑通推理流程
2. 了解基本的技术概念：Transformer架构、Attention机制、Tokenizer原理等
3. 尝试做一些微调：用LoRA或者QLoRA在自己的数据集上微调一个小模型
4. 了解国内的大模型生态：比如百度的文心一言，它背后的ERNIE系列模型的技术特点

这些你做到了，简历上写"有LLM实践经验"，面试官问起来你才有东西可聊。

---

二、我为什么要研究Rust

说到Rust，这是我最近半年最大的技术投入了。

起因是这样的：去年双11期间，我们组负责的一个网关服务出了性能问题。当时QPS峰值达到了平时的5倍，服务开始出现大量的GC停顿，P99延迟直接飙到了500ms以上。

当时真的想砸电脑。

后来排查了一圈，发现是Go的GC机制在高并发场景下的一个问题。虽然Go号称"低延迟GC"，但在极端场景下，STW（Stop The World）的时间还是会让人抓狂。

那段时间我开始思考一个问题：有没有一种语言，既能保证内存安全，又不需要GC？

答案就是Rust。

说实话，刚开始学Rust的时候，我真的被它的所有权机制搞得头大。编译器就像一个超级严格的代码审查员，你写的每一行代码它都要挑毛病。前两周我写代码的状态基本就是：

cargo build
error[E0382]: borrow of moved value: `xxx`
error[E0597]: `xxx` does not live long enough
error[E0499]: cannot borrow `xxx` as mutable more than once at a time

当时真的怀疑人生，觉得自己是不是不适合学这门语言。

但是坚持了一个月之后，我突然开窍了。Rust的所有权机制其实是在编译期就帮你把内存问题全部解决了。你不需要在运行时担心内存泄漏、数据竞争这些问题，因为编译器已经帮你检查过了。

这种"把问题消灭在编译期"的思想，跟我现在做基础架构的理念不谋而合。

现在我们组内部有一个工具服务，原来是用Python写的，性能一直上不去。我用Rust重写了一版，性能直接提升了10倍以上，内存占用降低了80%。leader看了之后直接让我在组内做了一个分享。

这里分享一下我学习Rust的一些心得：

2.1 学习路径建议

第一阶段（1-2周）：
- 看《The Rust Programming Language》（Rust官方书）
- 重点理解所有权、借用、生命周期的概念
- 不要急着写项目，先把基础概念搞懂

第二阶段（2-4周）：
- 做Rustlings练习（官方提供的练习题）
- 开始写一些小工具，比如命令行工具、文件处理工具
- 这个阶段会被编译器虐，但要习惯

第三阶段（1-2月）：
- 读一些优秀的开源项目源码，比如ripgrep、tokio
- 尝试用Rust重写你熟悉的一个小项目
- 开始理解Rust的异步编程模型

第四阶段（持续）：
- 在实际项目中应用Rust
- 参与开源项目贡献
- 深入研究Rust的底层实现

2.2 一些踩坑记录

这里分享一个我遇到的经典问题。当时我在写一个并发处理请求的服务，代码大概是这样的：

use std::thread;
use std::sync::Arc;
use std::sync::Mutex;

struct SharedState {
    data: Vec<String>,
}

fn main() {
    let state = Arc::new(Mutex::new(SharedState {
        data: Vec::new(),
    }));

    let handles: Vec<_> = (0..10).map(|_| {
        let state_clone = Arc::clone(&state);
        thread::spawn(move || {
            let mut data = state_clone.lock().unwrap();
            data.data.push("hello".to_string());
        })
    }).collect();

    for handle in handles {
        handle.join().unwrap();
    }

    println!("Data count: {}", state.lock().unwrap().data.len());
}

这段代码看起来没问题对吧？但是性能很差，因为每次操作都要获取锁。

后来我改成了用DashMap（一个并发安全的HashMap实现），性能直接提升了好几倍：

use dashmap::DashMap;
use std::sync::Arc;
use std::thread;

fn main() {
    let map = Arc::new(DashMap::new());

    let handles: Vec<_> = (0..10).map(|i| {
        let map_clone = Arc::clone(&map);
        thread::spawn(move || {
            map_clone.insert(i, format!("value_{}", i));
        })
    }).collect();

    for handle in handles {
        handle.join().unwrap();
    }

    println!("Map size: {}", map.len());
}

教训：在Rust里写并发代码，不要一上来就用Mutex，要根据场景选择合适的并发原语。

---

三、聊聊AI大模型在工程实践中的应用

好了，说完了Rust，再来聊聊最近最火的AI大模型。

前面说了，我新公司这边有一个AI相关的项目。具体来说，是要做一个智能客服系统，需要用到LLM的能力。

3.1 技术选型：为什么选Llama而不是文心一言

一开始产品经理说直接用文心一言的API，说百度那边有企业级服务，稳定可靠。

但我评估了一下，有几个问题：

维度	文心一言API	Llama自部署
成本	按token计费，量大成本高	一次性硬件投入，边际成本低
数据安全	数据要传给第三方	数据完全在内部，安全可控
定制化	只能通过prompt engineering	可以微调，深度定制
延迟	受网络影响，不可控	内网部署，延迟可控
可控性	黑盒，出问题难排查	白盒，可以深度优化

考虑到我们的业务场景（日均对话量预计10万+），以及对数据安全的要求，最终决定自部署Llama模型。

3.2 部署Llama的那些坑

部署Llama的过程，真的是一言难尽。

第一个坑：显存不够

我们一开始用的是A10显卡（24G显存），结果跑Llama-13B的时候直接OOM了。后来查了一下，13B的模型在FP16精度下，光模型参数就要占26G显存，再加上KV Cache等，24G根本不够。

解决方案有两个：

1. 用Llama-7B，7B模型在FP16下大概需要14G显存，A10能跑
2. 用量化技术，把模型量化到INT8甚至INT4，显存占用能降低一半以上

我们最终选了方案2，用GPTQ量化把13B模型量化到了INT4，显存占用降到了8G左右，A10完全够用。

第二个坑：推理速度太慢

量化之后显存是够了，但是推理速度又成了问题。一个请求的响应时间要10秒以上，用户体验极差。

后来我研究了一下，发现主要是两个原因：

1. 没有用vLLM这样的推理加速框架
2. 没有做Continuous Batching

换了vLLM之后，吞吐量直接提升了3倍以上。

这里贴一下我们最终的部署配置：

# vLLM部署配置
model:
  name: "llama-13b-chat-gptq-int4"
  path: "/models/llama-13b-chat-gptq"
  
server:
  host: "0.0.0.0"
  port: 8000
  tensor_parallel_size: 1
  max_model_len: 4096
  gpu_memory_utilization: 0.9
  
sampling:
  temperature: 0.7
  top_p: 0.9
  max_tokens: 2048
  
# 性能优化参数
optimization:
  enable_prefix_caching: true
  enable_chunked_prefill: true
  max_num_batched_tokens: 8192
  max_num_seqs: 256

第三个坑：中文效果不好

Llama本身是英文模型，中文效果不太好。我们一开始直接用，回答的中文总是带着一股翻译腔。

解决方案是找一些高质量的中文对话数据做微调。我们用LoRA在大概5000条高质量的客服对话数据上做了微调，效果提升非常明显。

微调的配置：

from peft import LoraConfig, get_peft_model
from transformers import AutoModelForCausalLM

# LoRA配置
lora_config = LoraConfig(
    r=16,  # LoRA秩
    lora_alpha=32,
    target_modules=["q_proj", "v_proj"],
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM"
)

# 加载基础模型
model = AutoModelForCausalLM.from_pretrained(
    "/models/llama-13b-chat",
    load_in_4bit=True,
    device_map="auto"
)

# 应用LoRA
model = get_peft_model(model, lora_config)
model.print_trainable_parameters()
# 输出：trainable params: 4,194,304 || all params: 13,004,185,600 || trainable%: 0.0323

3.3 关于DALL-E的一些思考

说到AI，不得不提一下图像生成。我们产品那边一直想要一个功能，就是根据用户的描述自动生成一些配图。

一开始他们想用DALL-E，毕竟OpenAI的东西，效果确实好。但是问题也很明显：

1. API调用成本太高：生成一张图大概要0.04美元，日均生成1万张的话，一个月就是1.2万美元
2. 国内访问不稳定：需要翻墙或者走代理，延迟不可控
3. 内容审核问题：生成的图片可能包含不合规内容

后来我们调研了国内的替代方案，最终选了百度的文心一格（基于文心一言的图像生成能力）。虽然效果比DALL-E稍差一些，但是胜在：

• 国内访问稳定，延迟低
• 成本只有DALL-E的1/5
• 自带内容审核，合规性好

技术选型的本质就是trade-off，没有最好的方案，只有最适合的方案。

---

四、技术探索的一些方法论

说了这么多具体的技术实践，最后想聊聊我在技术探索方面的一些方法论。

4.1 为什么要做技术探索

在字节干了五年，我最大的感悟就是：在大厂，不做技术探索，迟早会被淘汰。

不是说你每天写业务代码就会被淘汰，而是说你的技术视野会越来越窄，竞争力会越来越弱。等到35岁危机来的时候，你拿什么跟年轻人拼？

所以我的建议是，每周至少拿出20%的时间来做技术探索。可以是：

• 读一个开源项目的源码
• 学一门新的编程语言
• 研究一个新技术方向
• 写一个side project

4.2 如何选择技术方向

技术方向的选择很重要。我的原则是：

1. 跟工作相关的优先

比如我在基础架构组，那RPC、消息队列、服务网格这些就是我应该深入的方向。这些技术探索可以直接应用到工作中，产出也更容易被认可。

2. 有长期价值的优先

比如Rust、AI、云原生这些方向，我认为是有长期价值的。即使你现在用不上，未来也大概率会用上。

3. 自己感兴趣的优先

这一点很重要。技术探索是一个长期的过程，如果你不感兴趣，很难坚持下来。

4.3 如何高效学习

最后分享一些我个人的学习方法：

1. 带着问题学

不要漫无目的地看书、看视频。最好是你有一个具体的问题或者项目，然后为了解决这个问题去学习。这样学习效率最高。

比如我学Rust，就是因为遇到了Go的GC问题，想要找一个替代方案。带着这个问题去学Rust，目标明确，效率自然就高。

2. 输出倒逼输入

学完一个东西之后，一定要输出。可以是写一篇博客，可以是做一个分享，可以是写一个demo。

输出的过程会逼迫你把知识梳理清楚，也会暴露你的知识盲点。

3. 读源码

对于你工作中用到的技术，一定要读源码。不需要把每一行都读懂，但是要理解核心模块的设计思路和实现原理。

比如我在字节的时候，把gRPC-Go的核心源码读了一遍，对RPC框架的理解提升了一个层次。后来面试的时候，这方面的题目基本都能答得很好。

---

五、一些真心话

写了这么多，最后想说几句真心话。

技术这条路，越往后走越难。特别是到了30岁之后，你会发现学习新东西的速度明显变慢了，精力也不如以前了。

但是我想说的是，技术人的核心竞争力，不是你能写多少代码，而是你解决问题的能力。

这种能力包括：

• 快速学习新技术的能力
• 分析问题和定位问题的能力
• 设计方案和做技术选型的能力
• 沟通协调和推动落地的能力

这些能力，是需要长期积累的，不是一朝一夕就能练成的。

所以，保持学习的热情，保持对技术的好奇心，这条路虽然难，但是值得。

---

以上就是我的一些分享，希望能对大家有所帮助。

如果你也是在大厂搬砖的程序员，欢迎加我微信交流（微信号就不放了，怕被骚扰，哈哈）。

下次想聊聊我在字节做过的一个高并发系统的架构设计，感兴趣的可以关注一下。

共勉！