Kimi K3 模型结构（10）：RL 与服务，状态住在哪里
内容提要
本文介绍Kimi K3模型在1M上下文强化学习与线上服务中的系统设计，核心是状态管理。KV块和KDA状态通过write-back策略在GPU与DRAM池间迁移，训练态让位NVMe，参考模型权重借梯度缓冲槽位流入GPU，沙箱支持pause/fork/snapshot，集群调度采用缓存亲和与预算准入，确保资源高效利用。
延伸解读
write-back 策略的代价权衡
文章强调外部 KV 池采用 write-back 而非 write-through，核心在于避免为 GPU 上活跃的块支付冗余的 DRAM 空间和带宽。但 write-back 也意味着被驱逐的块在下次复用前需要预取，若预取不及时或发生抖动，可能增加延迟。这种设计更适合长上下文、复用率高的场景，而对短请求或复用率低的情况，write-through 可能更简单直接。
自动节流与资源利用率
固定并发数在长上下文 rollout 中难以平衡早期欠饱和与后期过载。K3 通过运行时信号动态调整并发，使 GPU 利用率更平稳。这提示在类似场景中，自适应控制比静态配置更有效，但依赖准确的信号监测和快速响应机制，否则可能引入新的不稳定因素。
参考模型权重的显存复用
将参考模型权重放入策略模型的梯度缓冲槽位，是一种巧妙的显存复用技巧，避免了额外分配和碎片。但安全性依赖于前向计算必须在梯度更新前完成，这要求严格的计算时序控制。若流水线被打断或同步出错，可能导致数据覆盖，因此实现时需谨慎设计同步机制。
沙箱生命周期与成本
AgentENV 的 pause/fork/snapshot 设计针对 agent 等待推理结果时的高空闲率，通过暂停释放资源，fork 支持无副作用判分，snapshot 用于错误恢复。但 checkpoint 和恢复本身有延迟（133ms/49ms），频繁操作可能累积开销。高密度（6.5倍超售）依赖写时复制优化，但超售比过高可能带来性能波动，需在密度与稳定性间权衡。
Q&A
Kimi K3 在 1M 上下文强化学习中，状态管理的主要瓶颈是什么？
在 1M 上下文的强化学习中，瓶颈不再是算力，而是状态放在哪里、什么时候搬。状态主要包括 KV 块和 KDA 状态，它们需要在 GPU、DRAM 池和 NVMe 之间迁移，以高效利用资源。
Kimi K3 的外部 KV 池为什么采用 write-back 策略而不是 write-through？
write-through 策略在每个块生成时同步写一份到 DRAM，会为所有块（包括活跃在 GPU 上不会被驱逐的块）付出 DRAM 空间和传输带宽。而 write-back 只在块被驱逐时写回 DRAM，只为离开活跃解码路径的前缀付出代价，避免了冗余的 CPU 副本，更高效。
Kimi K3 如何实现 rollout 的自动节流？
K3 在 LLM 请求调度层加入自动节流，利用运行时信号（如活跃请求数、排队请求数、KV cache 利用率）动态控制送入推理引擎的请求数。早期上下文短时并发高，随着 KV 压力上升自动降低并发，避免过载或欠饱和，无需手动调整。
参考模型权重是如何在 GPU 上物化的？
参考模型权重常驻 CPU，需要时按 VPP chunk 流进 GPU 上的两个梯度缓冲槽位。一个槽用于当前 chunk 的前向，另一个预取下一个 chunk，拷贝时间隐藏在计算后，不增加 GPU 显存占用。真正的梯度计算会覆盖这些权重，因此安全性有保障。
AgentENV 沙箱提供了哪些生命周期操作？
AgentENV 基于 microVM，支持 Pause/Resume（暂停的沙箱不占资源，等待推理时可暂停）、Fork（从原沙箱状态复制新沙箱，用于无副作用判分）、Snapshot（定期快照用于错误恢复）。底层支持增量 checkpoint，延迟低至 133ms（checkpoint）和 49ms（resume）。
Kimi K3 的集群调度如何保证缓存亲和性和故障恢复？
K3 使用一致性哈希为每个会话分配主备两个集群。主集群服务流量并持有前缀缓存，备集群在主集群故障时接管，但无缓存需重新 prefill。一致性哈希将不同会话的备集群均匀分散，使故障时的重 prefill 负载分散到整个集群池，避免集中。常态下缓存局部性得以保持。
预算准入机制解决了什么问题？
生产流量中短请求不到 2K，长请求可达 1M，单个请求代价跨三个数量级，导致按平均请求的容量规划失效。预算准入为不同请求类别分配独立资源预算，使长上下文突发最多消耗自己份额，不会拖垮其他类别的 SLO，保证可预测性。
