Kimi K2.6 推理调优：先测负载，再动模型

Kimi K2.6 推理调优的起点，是生产流量的形态，而不是一张优化技术清单。Modal 面对的编码 Agent 负载约为 10 万输入 token、500 输出 token、多轮连续会话和大量重复前缀。这个形态让瓶颈依次从解码带宽迁移到 KV cache 容量，再迁移到缓存感知路由。

阅读时间：约 8 分钟 · 字数：约 3100 字

TL;DR

• Modal 报告 Kimi K2.6 单副本每用户交互速度提升 2.8 倍，跨用户总吞吐提升 5.6 倍。
• 这些数字对应 B200、SGLang 和输入输出比约 200:1 的编码 Agent 负载，不能直接用于其他环境。
• 可迁移的方法是：先建立请求画像，再处理解码延迟、KV 容量和多副本路由。
• 每次有效优化都会移动瓶颈，下一步必须由新测量决定。
• 投机解码可在正确实现下保持目标分布；KV cache 或权重量化需要任务级质量评测。

先测五组负载数据

脱离负载合同的推理基准，很难指导生产决策。输出长度变化会改变每 GPU 吞吐；代码与自然语言会产生不同的投机接受长度；用户回头编辑旧消息会改变缓存命中率；同一个 session 并发请求会让亲和路由制造热点。

在修改推理引擎前，先从生产日志或脱敏回放中统计五组分布：

Modal 的 Kimi K2.6 工程复盘 给出的核心负载约为 10 万输入 token 和 500 输出 token，输入输出比达到 200:1。每轮请求携带之前的会话历史，因此后续轮次和前一轮拥有高度重合的前缀。

这类流量与短对话、批量摘要、长文本生成是三种不同系统。编码 Agent 需要较快 decode 保持交互感，但总体成本更多来自长输入，以及为避免重复 prefill 而保留的状态。

先冻结基线，再选技术

服务级基线至少保留四个指标：

• TTFT：包括排队和 prefill 的首 token 延迟；
• ITL 或输出 TPS：用户感知到的 decode 速度；
• 每 GPU 每分钟 token：整体成本效率；
• p95 端到端延迟：真实用户遇到的尾延迟。

诊断层再增加 cache hit rate、KV 利用率、队列深度和单副本负载方差。所有图表都应按输入长度、输出长度、并发和前缀复用率分桶。

固定轨迹负责可复现，近期生产样本负责真实性。Modal 明确指出，项目中的几乎每个指标都同时取决于系统和负载。受控数据用于解释改动，生产形态用于验证解释能否成立。

第一阶段：解除 decode 带宽瓶颈

Modal 先优化单用户交互速度。自回归 decode 每一步都需要访问大量模型状态，才能生成下一个 token。在其部署中，最初的延迟瓶颈是 HBM 带宽。

团队组合使用 tensor parallelism 和定制 DFlash 投机解码。投机解码让较小的 drafter 一次提出多个候选 token，再由目标模型并行验证。正确的拒绝采样会保持目标模型的输出分布。NVIDIA 的技术说明展示了具体过程：草稿 token 通过验证就保留，在第一个拒绝位置回到目标模型继续生成。

这类优化成立的条件，是每次昂贵的目标模型调用能够接受足够多候选 token，覆盖草稿与验证开销。关键指标包括：

• 每步平均接受 token 数；
• drafter 耗时占目标模型耗时的比例；
• 固定并发下的输出 TPS；
• 相同目标配置下的质量一致性。

Modal 用目标模型生成的编码轨迹继续微调 drafter。官方报告平均接受长度从每步 5.00 提升到 5.84，获得增量 20% 加速。这说明 drafter 与工作负载需要匹配，通用草稿模型很可能留下大量性能空间。

这一阶段的停止条件不是无限追求最大 TPS。达到产品要求的交互速度后，如果继续增加并行度开始降低每 GPU 效率或制造更贵的瓶颈，就应进入下一层。

第二阶段：把显存预算还给 KV cache

Decode 加速后，新的约束变成 HBM 容量和单副本并发。

官方 Kimi K2.6 模型卡 标明：模型采用 MoE 架构，1T 总参数、32B 激活参数、61 层、256K context、MLA 注意力和原生 INT4 量化。Modal 在 B200 上用 NVFP4 服务，部署中的权重约为 595 GB。

Modal 比较了四卡和八卡 tensor parallel 副本。其容量粗算显示，TP4 约能容纳 45 万 token 的 KV，TP8 约能容纳 300 万 token。八卡提供约六倍缓存空间，但在目标交互约束下，每 GPU 实测性能没有证明这笔投入合理。团队保留 TP4，转而直接减少内存占用。

这个决策比具体卡数更重要。更多显存和更多 GPU 只是能力，只有受约束目标发生改善时，它们才构成优化。

容量优化分为三层：

1. 清理重复中间缓冲，把 HBM 还给缓存。
2. 在任务级评测允许时降低状态精度。
3. 增加 CPU 内存缓存层，用较慢命中缓冲瞬时过载，避免直接退化为完整重算。

Modal 报告把 KV cache 从 BF16 量化到 FP8 后，可缓存 token 数翻倍。团队还量化 shared experts，并减少 draft model 中间状态的峰值占用。其内部评测没有发现超过运行间非确定性的明显质量下降。

这个结论只能作为该环境的证据。投机解码可以通过目标模型验证保持分布，量化则可能改变任务结果。编码正确性、工具调用、长上下文和安全评测都应在最终 serving build 上重跑。

这一阶段真正要看的不是模型宣称支持多长 context，而是并发与 session 长度增加时，cache hit rate 如何下降。支持 256K context，不等于一个副本能同时保留多条长会话而不驱逐。

第三阶段：把请求路由到状态，而不只是服务器

单副本优化完成后，瓶颈移动到多副本请求放置。

KV cache 让副本在性能层面具有状态。缓存未命中不会破坏正确性，却会触发昂贵重算。最直接的方案是 session affinity：对 session ID 做哈希，让后续轮次回到保存前缀的副本。

它只能作为起点，仍有三个失效场景：

第一，同一个 session 产生并发请求，会压垮固定副本。第二，不同 session 的工作量差异很大，只计算 session 数会把 3k token 和 300k token 当作相同负载。第三，扩容改变副本集合，热 session 被重映射后会产生冷 prefill。

Modal 最终分别处理这三类问题：

• 当 session 并发超过阈值时主动拆分，允许少量缓存复制换取负载释放；
• 新 session 依据运行中请求数和 KV 利用率放置，完成放置后再保持亲和；
• 扩容时优先把新 session 交给新副本，减少热缓存迁移。

官方报告的一个部署样本中，单副本负载方差降到均值的一半以下，尾部 TTFT 更稳定，多副本吞吐也更接近单副本测量结果。

这里的通用结论是：局部性和均衡是两个相互竞争的目标。完美局部性会制造热点，完美均衡会丢掉热状态。路由器需要结合当前负载与可复用状态，计算下一次放置的实际成本。

一套瓶颈迁移 Runbook

把案例改写成循环，才具有迁移价值。

1. 定义受约束目标

例如要求 p95 TTFT 低于某个阈值，同时保持最低每 GPU 吞吐。缺少约束时，基准很容易通过牺牲另一条轴制造漂亮结果。

2. 用冻结轨迹复现问题

覆盖有代表性的长度、重合率和并发分桶。每次结果同时记录引擎版本、模型 revision、精度、并行方式、硬件、scheduler 配置和路由策略。

3. 判断当前资源约束

• Decode 很慢而计算单元仍有空闲，优先检查内存带宽和串行步骤。
• 并发升高后命中率下降、重算增加，优先检查 KV 容量。
• 单副本良好、多副本尾延迟恶化，优先检查路由和扩容。

4. 一次只改一层

针对当前约束应用投机解码、分配清理、缓存精度、分层缓存或路由策略。保持其他控制项和负载不变。

5. 同时重跑性能与质量门禁

查看均值与尾部。任何有损改动都需要任务级质量评测。吞吐提高但工具调用或补丁正确率下降，仍然属于验收失败。

6. 重新定位瓶颈

主约束迁移后，停止继续优化旧层。下一次测量负责选择下一项工程投入。

五类常见误区

把 2.8 倍和 5.6 倍写进自己的容量规划。 这是厂商在特定模型、硬件、引擎和负载上的报告值，不是可移植常数。

只看平均请求长度。 均值会掩盖耗尽 KV 容量和制造 p95 延迟的长尾。

无限追求缓存局部性。 Session affinity 需要为高并发和超大 session 提供负载逃生通道。

把量化视为免费优化。 部分改动只影响性能，另一些会改变模型行为，后者必须通过任务级 eval。

用不同负载比较引擎。 输出长度、前缀重合率和并发变化，足以在系统不变时重排性能结果。

常见问题

应该先优化 TTFT 还是输出 TPS？

从产品约束出发。长 prefill 负载可能先违反 TTFT，交互式编码 Agent 也需要足够 decode TPS。两者都测，优先处理未达标的一项。

投机解码什么时候最有效？

Drafter 足够便宜，且候选 token 接受率较高时最有效。接受率依赖负载，代码与自然语言需要分别测量。

为什么并发升高后 KV cache 性能会突然下降？

更多活跃历史争夺有限 HBM，驱逐后需要重算长前缀，交互速度和总吞吐会同时下降。

Session affinity 足以支持 Agent 负载吗？

它是合理基线。并发请求、session 大小不均和扩容重映射仍会制造热点或冷 prefill，需要把实时负载和 KV 状态加入决策。

Modal 的配置能直接迁移到其他模型吗？

诊断顺序具有迁移价值。并行度、精度、缓存层级和路由阈值必须针对新模型、硬件、引擎与流量重新测量。

参考资料

• Modal：How to serve trillions of tokens for trillion-parameter coding agents
• Moonshot AI：Kimi K2.6 模型卡
• NVIDIA：投机解码技术说明
• KV Cache 变成 Agent 运行时后
• GigaToken 基准审计：1000 倍加速何时真的有效

下一步：导出一小时请求元数据，按输入长度、输出长度、前缀重合率和 session 并发分桶，再重跑当前 serving 基线。这份画像会直接告诉你，下一轮工程时间应投入 decode、cache 还是 routing。