AI 工程化

让 LLM 应用「稳定、便宜、可观测、安全」地跑在生产,是 AI 工程化的全部命题。模型能力是下限,服务工程决定上限——同样的模型,工程好的团队能做到 5 倍吞吐、1/3 成本与分钟级定位问题。本页按「推理服务 → 性能成本 → 可观测评测 → 安全合规 → 部署拓扑」给出可落地的工程地图;模型侧原理见 LLM 原理。

一、推理服务:跑模型的那层

• 服务框架选型:

方案	定位	何时选
vLLM	高吞吐 LLM 推理(continuous batching + PagedAttention)	自建服务首选(OpenAI 兼容 API)
TGI	Hugging Face 官方推理栈	与 HF 生态深度集成
Ollama	本地一键跑模型	桌面/开发机体验
TensorRT-LLM	极致性能优化	大规模线上 + 有编译工程投入
云托管(Anthropic/OpenAI/Gemini 等)	开箱即用	快速上线、无 GPU 运维

• 两个必须理解的核心机制:
  • Continuous batching(连续批处理):不是等整批算完才进下一批,而是有请求完成就立刻腾出位子接新请求——吞吐提升的根基;
  • PagedAttention / 分页 KV cache:把 KV cache 按页管理,消除显存碎片与预分配浪费(核心论文见 vLLM: PagedAttention 可后续收录)——长上下文与高并发的关键;
• 单模型 vs 多模型:同量级模型混部共享 GPU 提利用;异构模型按服务隔离,避免互相拖垮。

二、内存、量化与长上下文

• 显存三件套:模型权重 + KV cache + 激活;粗略公式(训练/推理的估算入门):
  • fp16 权重 ≈ 2 GB / 10 亿参数(如 7B ≈ 14 GB);
  • int4 量化 ≈ 0.5-0.6 GB / 10 亿参数(7B ≈ 4 GB 左右);
  • KV cache ≈ 2(层数 × 头数相关常数)× 序列 token 数 × 模型维数 × 精度,随并发 × 长度线性增长——长会话服务的主要显存黑洞;
• 量化路线:GPTQ(训练后权重量化,GPU 推理)、AWQ(激活感知加权)、GGUF(CPU/边缘友好,llama.cpp 生态);顺序建议:先 fp16 跑通,再 AWQ/GPTQ 到 int4 验证质量与收益;量化后必须跑金标回归——敏感任务损失可能被放大;
• 长上下文的工程应对:前缀缓存(相同系统提示/文档前缀复用 KV)、历史摘要压缩、KV cache 逐层压缩(如量化 KV、H2O/StreamingLLM 式窗口)——先量化 KV 再谈裁剪;
• 推理代理配置(vLLM 为例):--max-model-len、--gpu-memory-utilization、--enable-prefix-caching 等与业务 QPS/并发直接相关,用压测数据反推。

三、吞吐、延迟与成本优化

• 指标语言:吞吐(tokens/s 聚合)> 指标看钱;延迟(p50/p99)看体验;连续批处理下二者此消彼长,用「并发 × 批大小」压测找到甜点;
• 提速工具箱(按性价比排序):
  1. 提示词瘦身:删模板废话、关键内容前置、压缩历史——输入 token 直接是钱;
  2. 结果缓存:相同/相近请求命中缓存(精确缓存最简单;语义缓存按嵌入相似度,注意误命中风险);
  3. 模型分级路由:简单请求走小模型/便宜 API,复杂请求走大模型(级联 + 置信度判断,如「小模型拿不准再升级」);
  4. 投机解码(speculative decoding)在部分场景白赚加速;量化与 LoRA 增量挂载 属工程常规操作;
  5. 蒸馏:用大模型产出数据训练小模型,长期成本曲线最陡;
• 成本归属:按用户/按功能做 token 计量,没有计量就没有优化的起点(也是防滥用闸门)。

四、可观测与评测:改得动、出问题找得到

• 黄金指标四件套:延迟(p50/p99)、吞吐、错误率、token 成本;加上服务健康与 GPU 利用率;
• 链路追踪:OpenTelemetry 的 GenAI 语义约定(span 记 model/prompt/completion/usage),把「一次请求 → 哪几步 LLM 调用 → 各花多少 token/毫秒」串起来——Agent 场景尤其必需(步数爆炸一眼可见);
• 日志策略:prompt/response 全量留痕成本高且含敏感数据——按需抽样 + PII 脱敏后落盘,保留原始数据于受控环境;
• 评测门禁(核心):
  • 金标回归集 + 规则/LLM-as-judge 自动化(方法见 Prompt 工程 评测节与 RAG 与 Agent RAGAS 节);
  • 模型升级、prompt 变更、框架升级必须过门禁才允许灰度;
  • canary:小流量放量 → 对比业务指标(成功率/好评/成本) → 逐步放开,异常即回滚;
• 线上漂移:流量分布变了评测却不变,定期更新金标(用线上真实样本重标注)。

五、安全与合规:LLM 应用的红线

• 输入输出双层防线:输入侧注入/越狱检测,输出侧 PII 脱敏、危险指令拦截、内容策略过滤(与 Prompt 工程 安全节联动);
• 数据合规:
  • 请求数据落哪个区/存多久,与云厂商的 data retention 条款一致;
  • PII 在入上下文前脱敏(正则/模型识别),响应重建时映射还原;
  • 训练/微调数据同样适用(见 模型微调);
• Agent 权限(高危):工具级 ACL、操作限额、敏感操作人工复核——即使注入成功也翻不出墙(见 RAG 与 Agent);
• 模型与供应链:基座许可证、权重来源可审计、依赖 SBOM;重大越狱/漏洞(如间接注入)要能快速全量禁用受影响功能;
• 合规清单自检:数据流向图、留存策略、脱敏开关、审计日志、权限矩阵、红队评测记录——六项齐了再谈上线。

六、部署拓扑:让 GPU 集群干活

• 形态梯度:单机多卡(实验/小规模)→ K8s + GPU 节点池 + 设备插件(生产标准)→ 多云容灾(可平移无状态推理);
• 弹性要点:推理无状态好扩缩,但 GPU 预热与模型加载要 1-10 分钟——预占 node pool + 常驻副本应对毛刺,冷启动高峰靠队列缓冲;
• 网关层做:模型路由(分级/多租户)、限流与配额、缓存、灰度与回滚、统一鉴权;
• 高可用:多副本 + 健康检查 + 优雅降级(超时/过载时降级到小模型或返回缓存答案,而不是 5xx 雪崩);
• 成本视图:按 GPU 型号 × 时长 × 利用率复盘;利用率长期 <30% 先查 batching 与路由,而不是买新卡。

七、踩坑清单

1. 不做压测就定并发:batching 吞吐曲线先升后崩,用真实 prompt 分布压测定并发上限与超时;
2. KV cache 无规划:长会话高并发时显存暴涨,OOM 或被迫重启——量化 KV/前缀缓存/摘要压缩三选一起码做一个;
3. 量化后不回归:int4 后事实/代码任务质量悄悄崩,金标必须覆盖;
4. 日志裸存 prompt:PII 与业务机密直接落盘,合规事故;先脱敏再留存;
5. 没有评测门禁就换模型:线上模型一升级行为漂移、用户投诉才被发现;
6. 追踪只记一层:Agent 多步调用不串 trace,问题无法定位——GenAI 语义 span 要贯穿;
7. 缓存当万能:语义缓存误命中会回旧答案;精确缓存 + 显式 TTL 先行;
8. 小模型级联无退出机制:级联判断不可靠时小模型硬答错题,置信度阈值要与金标校准;
9. 降级策略缺失:GPU 过载/供应商故障时直接 5xx 雪崩,没有优雅降级预案;
10. 成本无计量:不知道每个功能花多少钱,无法优化也无法限额;
11. GPU 利用率低就扩卡:先查 batching/路由/数据搬运,常是架构问题不是容量问题。

关联阅读:模型行为层看 Prompt 工程 与 模型微调;检索系统工程见 RAG 与 Agent;本文覆盖的 vLLM/PagedAttention/投机解码等机制的论文原典可在 文献收藏 追踪收录。