技术探索与实践：我的五年 AIGC 工程师之路
引言
大家好，我是从事 AI 生成内容（AIGC）方向五年的工程师。从最初接触 NLP 到如今深度参与大模型训练、微调、推理优化等完整链路，这一路上有过困惑、踩过坑、也收获了不少成就感。
今天我想和大家分享一下我在技术探索与实践过程中的一些体会。这些经验来自于我亲自参与的几个真实项目，涉及文本生成、图像生成以及多模态融合的应用场景，其中不乏我们在产品上线前夜临时调整架构的“惊险时刻”，也有面对用户量激增时如何稳定服务的“极限操作”。
希望通过这篇文章，能让刚入行的朋友少走弯路，也能让同行伙伴有所共鸣。
我遇到的一个典型挑战：从千人并发到万人并发的跃迁
去年年底，我们团队承接了一个基于大语言模型的企业知识问答系统项目。用户的业务需求是为内部员工提供一个智能助手，可以快速检索公司内部文档并回答问题。
当时我们采用的是 Llama-2 系列中的 7B 版本，在本地部署的基础上做了指令微调，并通过 FastAPI 暴露接口，前端使用 React 做了轻量级界面。听起来一切很顺利，但上线第一周就遇到了严重的性能瓶颈——当并发请求达到 500 以上时，响应时间明显拉长，甚至出现超时挂起的情况。
这个问题在测试阶段没有暴露出来，因为我们只模拟了几十个并发用户，而实际上企业内部使用时瞬间涌入了几千名员工，尤其是在午休时间和开会前那段时间访问量暴涨，系统根本扛不住。
技术方案的调整思路
面对这个情况，我们紧急开了几个会，分析性能瓶颈到底出在哪里：
- 模型推理层：单机部署导致每个请求都串行处理
- 负载均衡层：FastAPI 作为网关本身不具备高并发能力
- 缓存机制缺失：相同的问题重复提问造成了重复计算资源浪费
- 日志与监控薄弱：出现问题后定位困难，恢复周期长
分布式推理服务构建
我们决定将模型推理模块独立出来，做成一个可水平扩展的服务。最终选择了 Triton Inference Server 来承载我们的模型推理任务。Triton 支持多个后端（ONNX、PyTorch、TensorRT），而且可以通过配置 batch 大小来提升吞吐量。
模型方面我们也进行了量化压缩，把原本 float16 的权重转换成了 int8 格式，内存占用降低了一半，同时速度提升了 15% 左右。
# 使用 HuggingFace Optimum 对模型进行量化示例
from optimum.onnxruntime import ORTQuantizer
from transformers import AutoTokenizer, AutoModelForSequenceClassification
model_name = "bert-base-uncased"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForSequenceClassification.from_pretrained(model_name)
quantizer = ORTQuantizer.from_pretrained(model)
quantizer.export(
onnx_model_path="model.onnx",
feature="sequence-classification",
quantized_model_output_dir="./quantized_model"
)
然后通过 Triton 配置文件 config.pbtxt 定义批量推理参数：
name: "bert_int8"
platform: "onnxruntime_onnx"
max_batch_size: 32
input [
{
name: "input_ids"
data_type: TYPE_INT64
dims: [128]
},
...
]
output [
...
]
dynamic_batching {
max_queue_delay_microseconds: 100000
}
接口服务升级
原 FastAPI 在高并发下表现不佳，我们将其替换为 Golang + Fiber 构建的中间层服务，用于接收 HTTP 请求，并负责调度到多个 Triton 实例上执行推理。
同时引入 Redis 缓存机制，对常见问题的答案做缓存处理。这部分逻辑很简单：
func answerQuestion(q string) (string, error) {
cacheKey := fmt.Sprintf("qa:%s", hashString(q))
if val, err := rdb.Get(cacheKey).Result(); err == nil && val != "" {
return val, nil
}
// 向 Triton 发送推理请求
resp, err := tritonClient.Infer(...)
if err != nil {
return "", err
}
// 写入缓存，保留 2 小时
rdb.SetEx(cacheKey, resp.Answer, 2*time.Hour)
return resp.Answer, nil
}
此外，我们用 Kubernetes 进行了容器编排，并结合 Horizontal Pod Autoscaler 做弹性伸缩；配合 Prometheus + Grafana 监控整个链路的各项指标。
踩坑实录：那些年我们一起经历的日子
虽然整体架构设计好了，但开发过程中还是踩了不少坑，这里简单分享几个印象深刻的例子。
Triton 部署 GPU 占用异常
刚开始部署 Triton 时，我们发现每台 GPU 机器只能支持一两个并发推理请求，GPU 利用率非常低。后来才意识到，模型加载时默认是以非批处理方式运行的，没有开启 dynamic batching，也没有设置合适的 max_batch_size，相当于还是“串行推理”的模式。
解决方式是在 config.pbtxt 文件中配置 dynamic_batching 并启用批量输入，之后 GPU 利用率一下子提升了 50%。
Golang 中间层连接池不足
在压测过程中突然发现 Golang 服务经常报错：connection refused。排查后发现问题出在 Triton 客户端的 gRPC 连接池不够用了。
解决方案是修改客户端连接池大小，并复用连接句柄而不是每次请求都新建连接：
conn, _ := grpc.Dial(fmt.Sprintf("%s:%d", tritonHost, 8001), grpc.WithInsecure())
client := runtimev1.NewGRPCInferenceServiceClient(conn)
// 重复使用 client 实例
Redis 缓存雪崩风险
为了提高缓存命中率，我们设置了统一的缓存 TTL 时间。结果某个半夜缓存集中失效，大量请求穿透到了 Triton，造成短时响应延迟飙升。
优化方式是对缓存添加随机过期偏移时间，比如：
ttl := time.Hour * 2
offset := time.Duration(rand.Intn(30)) * time.Minute // 添加随机偏移
rdb.SetEx(key, value, ttl + offset)
最终效果：从卡顿到丝滑的蜕变
改造完成后，我们重新上线了一次：
- QPS 提升了 8 倍，从原来的最大 200 到稳定维持在 1600 左右；
- P99 Latency 控制在 400ms 以内；
- 用户反馈响应流畅、答案准确，满意度大幅提升；
- 成本方面，得益于推理效率提升，整体算力资源节省了约 30%，也为后续大规模扩容打下了基础。
更重要的是，整套系统具备了良好的可观测性与弹性扩缩容能力，能支撑更多业务场景和模型迭代。
给读者的技术建议与心得
如果你正在或即将投身 AIGC 工程领域，以下几点是我走过弯路总结出来的建议，希望能对你有帮助：
1. 别怕折腾，技术选型要敢于尝试
AIGC 是个发展非常快的方向，新技术新工具层出不穷。我见过不少人在项目前期纠结于到底该用哪个框架（比如是 LangChain 还是 Transformers），最后迟迟不敢推进。
其实大多数时候，“先跑起来再说”比“完美选型再动”更有价值。很多性能瓶颈和技术难点只有在实际跑起来之后才能看到，提前规划太细往往事倍功半。
2. 模型不是万能的，系统工程同样重要
很多人以为做大模型就是调模型参数、改 prompt，其实真正落地时，工程层面的挑战远大于模型本身。
比如怎么高效分发请求？怎么保证服务可用性？怎么控制成本？这些问题不解决，即使你有一个世界顶级的大模型也无法商业化。
所以，不要只盯着模型那一块，系统架构、网络通信、缓存机制、日志追踪都需要懂一点。
3. 性能优化是一个持续的过程
很多时候你一开始做的选择可能并不是最优解，但没关系，只要能工作就行。重要的是建立一套完善的观测手段，不断收集数据，识别瓶颈，持续迭代。
比如我们最早用 FastAPI，后来换成 Go，再到后来加入缓存、动态批处理，每一步都不是一开始就做到的，而是逐步演进的。
4. 多写文档和注释，方便别人也方便自己
工程代码写多了你会发现，几个月后回头去看自己写的代码，有时还不如看别人的明白 😂。特别是像 AIGC 这种涉及到模型、服务、调度等多个环节的系统，如果没有清晰的注释和文档，后期维护起来非常痛苦。
5. 持续学习，保持对新技术的敏感度
AIGC 领域更新很快，几乎每个月都有新工具和论文发布。建议关注如下几个渠道：
- HuggingFace Models Hub（模型仓库）
- Papers with Code（论文+基准测试）
- GitHub Trending（开源项目趋势）
- Twitter/Reddit 上的社区讨论
- 各大公司的官方博客（如 NVIDIA、Google、Meta）
你可以设定每周花 1~2 小时浏览这些信息，积累下来会有意想不到的收获。
结语：致热爱技术的你
作为一名 AIGC 工程师，我一直觉得我们所处的时代非常幸运。过去只能在论文里看到的前沿模型，现在都能跑在我们自己的服务器上；曾经被认为“科幻”的应用场景，现在正被我们亲手实现。
这条路当然不会一帆风顺，它需要我们不断地试错、学习、重构。但正是这些挑战，构成了我们成长的阶梯。
愿你在技术探索的路上越走越远，也能在实践中找到属于你的那份成就感。
“技术之美不在炫技，而在解决问题。”
—— 一位 AIGC 工程师的五年感悟
评论 0