部署开源模型：别只看跑分，要评估整个推理栈

跑分不等于生产表现

开源大模型社区里，榜单和跑分是绕不开的话题。MMLU、HumanEval、MATH 这些基准测试分数刷得再高，一旦把模型放进真实生产环境，问题可能完全不同。延迟飙高、吞吐量崩塌、显存爆掉——这些都不是 benchmark 能告诉你的。

核心观点：评估开源模型时，不能只盯着模型本身的能力分数，必须审视从模型权重到最终 API 响应的整条推理链路。

推理栈包含哪些环节

一个完整的开源模型推理栈，至少涉及以下几层：

• 模型本身：参数量、上下文长度、量化精度、是否支持 KV Cache 优化
• 推理引擎：vLLM、TGI（Text Generation Inference）、llama.cpp、TensorRT-LLM 等，不同引擎在批处理策略、内存管理上差异很大
• 硬件层：GPU 型号（A100/H100/L40S）、显存大小、互联带宽（NVLink）、甚至 CPU 推理的可行性
• 服务层：请求调度、连续批处理（continuous batching）、流式输出、超时与重试机制
• 运维层：模型热更新、灰度发布、监控告警、成本核算

每一层都可能成为瓶颈。只看模型跑分，等于只检查了引擎的马力，却不管变速箱、轮胎和路面。

量化与精度：不是越无损越好

FP16 精度下模型效果最好，但显存占用也最大。生产环境通常需要在 INT8 或 INT4 量化 与精度损失之间做取舍。

实用建议：

• 先用 FP16 跑一遍基准测试，记录延迟和吞吐
• 再切换到 INT8/INT4，对比输出质量是否可接受
• 关注 量化后的首 token 延迟 和 每 token 生成时间，这两个指标直接影响用户体验

有些模型量化后效果下降明显，有些则几乎无感——这取决于模型架构和训练方式，必须实测。

推理引擎选型：没有银弹

不同推理引擎有各自的适用场景：

选型时不要只看 GitHub star 数，要关注：

• 是否支持你目标模型的架构
• 对连续批处理的支持程度
• 社区活跃度和 bug 修复速度
• 与你现有技术栈（K8s、Ray 等）的集成难度

硬件成本：容易被忽略的隐性开支

很多团队低估了硬件成本。一个 70B 参数模型，FP16 下需要约 140GB 显存，可能需要多张 A100 80G 或 H100 80G 通过 NVLink 互联。

实际部署前要算清楚：

• 单卡显存是否够用（模型权重 + KV Cache + 激活值）
• 多卡推理的通信开销
• 推理服务的 GPU 利用率（低利用率意味着高成本）
• 是否有 CPU offload 或分层推理方案可以降低成本

对于预算有限的团队，可以考虑 模型蒸馏 或选择更小的模型（如 7B/13B），配合 prompt engineering 弥补能力差距。

从评估到落地的检查清单

在决定将一个开源模型投入生产前，建议过一遍以下清单：

1. 模型能力：在你的目标任务上跑 benchmark（不是通用 benchmark，而是业务相关的评测集）
2. 推理性能：在目标硬件上测试首 token 延迟、吞吐量和显存占用
3. 量化效果：对比不同精度下的输出质量
4. 引擎兼容性：确认推理引擎支持该模型架构
5. 服务稳定性：压测并发场景，观察 OOM、超时等异常
6. 运维可行性：模型更新流程、监控指标、回滚方案
7. 总成本：硬件 + 运维 + 人力，算出单次推理成本

总结

开源模型的民主化降低了使用门槛，但生产部署的工程复杂度并没有降低。跑分是起点，不是终点。把评估目光从模型权重扩展到整个推理栈，才能避免「实验室里跑分第一，上线后处处翻车」的尴尬。

一句话：选模型看能力，选部署看栈。