超级管理员
楼主
vLLM 0.31 和 llama.cpp 0.6 同期发布，正好聊聊怎么给推理引擎做升级。这类升级的坑比想象中多，因为它的失败模式经常是「看起来正常」。
为什么推理引擎升级特别危险 普通应用升级出问题会报错、会崩。推理引擎升级出问题往往是：
- 吞吐悄悄降了 20%，没人发现。
- 某个特定长度的 prompt 触发了不同的内核路径，延迟翻倍。
- 数值精度变化导致输出质量退化，但没有硬指标能捕捉。
- 保存的状态（session、KV cache 快照）格式变了，加载失败。
这次 llama.cpp 0.6.0 就是个典型例子：会话格式改了，升级后老 session 全部失效。
四层绑定 模型权重、推理引擎、硬件后端、API 行为，这四层是绑在一起的。任何一层变了，其他三层的表现都可能变。
所以「我在 A100 上测过没问题」不能推导出「在 L40S 上也没问题」。同理，同一个引擎版本换了权重，性能特征也可能完全不同。
一个可执行的升级流程
定义工作负载。选有代表性的模型、prompt 长度分布、并发数、模态类型，以及延迟和吞吐目标。别用「平均长度 500 token」这种拍脑袋的数字，从生产日志里抽真实分布。
双环境对比。在同一批硬件上，用新旧引擎各跑一遍。测的不只是吞吐，还要有：尾延迟（P99/P999）、显存峰值、输出正确性。
输出正确性怎么测。这是最容易被跳过的一步。做法：固定温度和种子，用同一批 prompt 跑新旧两版，对比输出的 token 级一致性和人工抽检质量。分类任务可以用准确率这类硬指标；生成任务可以准备一组标准问题做人工打分。
灰度。先在 5% 流量上切，观察 24 小时，重点看错误率和延迟分布，不是看平均延迟。
准备好回滚。容器镜像 tag、权重版本、引擎版本全部固定。别用 latest。
两个额外提醒
- 多模态输入要当不可信数据校验：媒体类型、大小、模型能力，都不能假设。
- 缓存要在租户之间隔离。多租户共享推理服务时，缓存串了是数据泄露。
最后一句话 引擎升级应该和应用发布走同一套变更管理流程。别因为它是「基础设施」就放松要求。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。