大模型推理与部署

推理是模型上线后真正响应请求的过程。用户看到的是一段回答，系统背后要处理上下文拼装、token 生成、缓存、并发、延迟、显存、成本和安全边界。

推理链路

一次请求通常经过：

1. 接收用户输入。
2. 拼接系统规则、历史对话、检索资料和工具结果。
3. Token 化。
4. 模型逐 token 生成。
5. 流式返回或完整返回。
6. 记录日志、指标和安全审计。

这条链路里，模型只是核心计算部分。上下文构造、限流、重试、超时、输出过滤同样影响最终体验。

关键指标

指标	含义	影响
首 token 延迟	从请求到第一个 token 返回的时间	影响用户等待感
生成速度	每秒生成多少 token	影响长回答体验
吞吐	单位时间处理多少请求	影响服务容量
上下文长度	单次请求可输入多少 token	影响资料承载能力
显存占用	模型运行需要多少 GPU 内存	影响部署成本
成本	每次请求消耗的计算资源	影响商业可持续性

KV Cache

模型逐 token 生成时，需要反复利用历史上下文。KV Cache 缓存历史 token 的中间结果，避免每一步都重新计算全部上下文。

它带来的收益是生成更快，代价是占用更多显存。长上下文、多并发场景下，KV Cache 往往是服务容量的关键瓶颈。

量化

量化用更低精度表示模型权重或计算结果，目标是降低显存和计算成本。

常见取舍：

• 精度越低，资源越省。
• 精度越低，效果越可能下降。
• 不同任务对量化敏感度不同。

量化后必须重新评估真实任务，不要只看模型能否启动。

批处理

批处理把多个请求合并在一起执行，提高硬件利用率。它适合高并发服务，但会引入排队等待。

在线交互型应用要控制等待时间；离线批量处理则可以更重视吞吐。

流式输出

流式输出会边生成边返回。它不能减少总计算量，但能显著改善用户感知，因为用户不必等完整回答生成完。

适合对话、写作、代码生成；不适合必须一次性校验完整 JSON 的场景，除非有额外的结构化输出处理。

MoE 部署关注点

MoE 模型每次只激活部分专家，看起来推理成本低，但部署并不简单：

• 专家分布在不同设备时会产生通信成本。
• 路由不均衡会造成部分专家过载。
• 批处理需要考虑不同请求激活专家不同。
• 监控要看专家负载，而不只是整体 GPU 利用率。

MoE 的价值来自大参数容量和稀疏激活，但工程复杂度也更高。

上下文成本

长上下文不是免费能力。上下文越长：

• 首 token 延迟可能更高。
• KV Cache 占用更大。
• 模型更容易被噪音干扰。
• 单次请求成本更高。

更稳妥的做法是先检索、过滤、摘要，再把高质量上下文交给模型。

部署选型

场景	关注重点
内部问答	检索质量、引用来源、权限控制
代码生成	长上下文、工具验证、输出速度
客服对话	首 token 延迟、稳定口径、安全过滤
批量摘要	吞吐、成本、失败重试
高敏数据	私有化部署、审计、脱敏

总结

推理部署关注的是模型如何稳定、快速、可控地服务真实请求。KV Cache、量化、批处理、流式输出、上下文裁剪和 MoE 调度都在解决同一个问题：在效果、延迟、吞吐和成本之间取得平衡。