大模型进阶·之六:架构师视角:部署、LLMOps、数据治理与边缘推理
架构师不是把模型“跑起来”就结束了,而是要让它长期、稳定、可观测、可迭代地跑下去。
你要管的不是一条请求,而是一整条能力链路。
架构师到底在管什么
当大模型进入真实系统以后,问题会从“回答得好不好”变成:
- 能不能稳定访问
- 能不能控制延迟
- 能不能压住成本
- 能不能追踪问题
- 能不能安全地更新
这就是架构师的活。
典型的 LLM 系统长什么样
一个常见的 LLM 应用,通常会有这些层:
- 前端和业务入口
- API 网关和鉴权
- Prompt 与策略层
- 检索和向量库
- 模型服务层
- 缓存、限流和降级
- 日志、监控和评估
你要看的不是某个模块本身,而是模块之间怎么配合。
部署和推理优化
大模型部署时,性能优化往往比“换一个更大模型”更重要。
常见手段包括:
- batching:提高吞吐
- kv cache:减少重复计算
- 量化:降低资源占用
- 流式输出:改善体验
- 缓存:减少重复请求成本
如果你做边缘或本地推理,还要特别关注:
- 显存/内存上限
- CPU 架构差异
- 首 token 延迟
- 长上下文的成本
可深入看的官方资料包括 vLLM、llama.cpp、NVIDIA TensorRT-LLM 和 NVIDIA TensorRT。
LLMOps 和数据治理
LLMOps 可以理解成“大模型时代的持续交付体系”。
你至少要关心这些事:
- 模型版本管理
- Prompt 版本管理
- 评估集管理
- 线上 trace 和回放
- 故障回滚
- 敏感数据脱敏
数据治理尤其重要,因为大模型系统很容易把日志、上下文、检索数据和用户输入混在一起。
一旦管不好,就会在安全、合规和稳定性上出问题。
边缘和嵌入式场景
嵌入式工程师的独特优势,在边缘推理场景里会被放大。
你天然会关心:
- 算力是否够
- 内存是否够
- 实时性是否够
- 离线是否可用
- 故障时是否能降级
这也是为什么嵌入式背景的人做 LLM 架构,不只是“懂一点硬件”,而是很容易在资源约束和系统设计上形成优势。
下一步
最后一篇主系列,我们不再看技术模块,而是看你怎么把这些东西讲给别人听。
因为真正能带团队的人,不只是会做,还要会讲、会拆、会教。