万亿 Token 级编码 Agent 推理服务单副本与多副本优化拆解原文Modal Blog - 《How to serve trillions of tokens for trillion-parameter coding agents》https://modal.com/blog/trillion-tokens-trillion-parameters一、先看清负载编码 Agent 的请求不是一问一答平时调托管 API 写 Agent我们几乎不会关心推理服务本身长什么样。可一旦要自己托管开源权重模型问题立刻变形——因为编码 Agent 的请求形态和普通聊天完全不同。普通问答是短上下文、请求之间互相独立。编码 Agent 的每一轮是这样拼出来的用户消息 模型回复 工具调用 工具返回再进入下一轮。到了第 T 轮输入序列里已经包含前面几乎全部内容。Modal 给这套负载起的名字很形象输入序列的高塔tower of input sequences。他们运营的这套服务里核心负载比例是200:1也就是平均每个请求约 100k 输入 token、500 输出 token。输入序列高度重叠意味着第一轮处理过的 token在第 T 轮会被重新处理 T 次。缓存不是优化项是生存条件。先把后面反复用到的两个阶段对齐阶段做什么关键指标Prefill处理输入 token填充 KV cacheTTFT首 token 延迟Decode逐 token 生成输出TPS每秒输出 token 数批量batching能摊薄每 token 的计算成本跨 token 的成本只能靠缓存摊薄。这两句话基本解释了后面所有设计。二、先算容量一台机器装不下这个模型Modal 的主案例是 Kimi K2.6约一万亿参数原文措辞是 approximately one trillion numbers权重体积 595 GB以 INT4 存储实际使用 NVFP4 格式4-bit 浮点带块级微缩放。单张 B200 只有 180 GB HBM。595 GB 权重塞进 180 GB数学上就不成立必须做张量并行TP。KV cache 的尺寸也能直接算出来模型 61 层每个 KV entry 576 个元素BF16 存储即 2 字节单 token 的 KV 约 72 KB576 × 2 × 61按这个数字两种可行配置的容量如下配置总 HBM权重占用后剩余每卡 KV约可容纳 KVTP4720 GB125 GB31.3 GB0.45M tokensTP81.44 TB845 GB105.6 GB3.0M tokens看起来 TP8 碾压容量是 TP4 的 6 倍硬件只翻倍。但 Modal 实测下来选了 TP4——因为 TP8 走 prefill-only 路线时吞吐并没有超过 TP4 的 prefill decode 组合。原文那句评价挺损Tensor Parallelism Is All You Need™ to interactivity-maxx。这里的第一个判断点值得记住容量更大不等于体验更好交互性优先于吞吐上限。三、单副本优化先榨干一个副本Modal 把单副本调优拆成两步先最大化交互性再解除 KV cache 的并发瓶颈。3.1 推测解码把 accept length 拉高推测解码speculative decoding先用一个很小的 draft 模型猜若干 token再由目标模型批量验证。Modal 用的是自研的 DFlash / DSpark特点是复用目标模型 KV 的中间状态作为 draft 输入draft 模型比目标小几个数量级。流程是先用通用混合数据训 DFlash再用 coding traces 针对 Kimi K2.6 微调。结果是 accept length从 5.00 提升到 5.84 token/步这一项带来约 20% 的增量加速。他们踩过一个很典型的坑draft 输出的是字符串形式的 token重新分词后对不上于是给 SGLang 打补丁通过sglext输出原始 token id。这个坑对自建推理栈的人同样适用——tokenization 不是恒等变换日志里的字符串 token 和模型内部的 id 不一定一一对应。3.2 KV cache整理 HBM、量化、加层级KV cache 决定并发上限这块做了三件事整理 HBM。重写 DFlash draft 的内存分配用预分配的连续 buffer 替代 list 加拷贝峰值 HBM 负载直接减半。量化。draft 模型转 FP8KV cache 从 BF16 转 FP8容量翻倍shared experts 从 FP8 转 NVFP4 再挤出一部分 HBM。加层次。用 SGLang 的 HiCache 给 KV cache 增加 L2CPU 内存和 L3分布式存储层他们实际只用 L2 削平瞬态超载。第 2 点要特别提醒降低精度不是免费的午餐模型输出可能发生剧烈变化必须跑 eval 验证原文提到了 Kimi Vendor Verifier。这和很多量化无损的宣传口径有出入以自己的评测集为准。一份单副本启动配置的示意大致是这样自拟示意非官方配置示例具体参数名与默认值以官方文档为准未验证最新版本# 自拟示意SGLang 单副本启动参数非官方示例python-msglang.launch_server\--model-path moonshotai/Kimi-K2.6\--tp-size4\--quantizationnvfp4\--kv-cache-dtype fp8_e4m3\--speculative-algorithm DFLASH\--enable-hierarchical-cache\--hicache-ratio2关键参数逐个说明--tp-size决定权重切分与 KV 分布直接影响能扛多少并发--kv-cache-dtype把单 token KV 从约 72 KB 压到约 36 KB等价于并发上限翻倍--speculative-algorithm决定是否走推测解码影响 TTFT 与 TPS不改善回答质量--enable-hierarchical-cache是过载保护手段不是常态加速开关。四、多副本路由才是真正的难点单副本调好之后多副本路由会引入一个容易被忽略的问题。最朴素的做法是均匀随机路由。Modal 算过这笔账按每副本 5 个会话规划50 个副本服务 250 个会话均匀随机会让某个副本只分到 1 个以内会话概率约 4%同时让某个副本分到 12 个以上会话概率约 0.5%。这是泊松分布的原罪——平均值好看长尾难扛。第二步引入基于一致哈希的会话亲和session affinity用Modal-Session-Id请求头把同一会话打到同一副本。但这还不够因为同一会话可能有多个并发请求被拆到不同副本原文叫 thicc sessions。更糟的是哈希运气不好时会出现 regrettably cold prefills——两个高度重叠的序列被分到不同副本KV 全部重算。最终方案是把无状态路由重写成 KV 感知加负载感知路由解决三件事拆开同一会话的并发请求、按 running requests 与 KV 利用率做细粒度放置、扩容时最小化缓存重定位。启用方式是在服务定义上加一个实验开关# 摘自 Modal 官方文章开启 KV 感知路由app.server(port8000,experimental_options{kv_aware_routing:True})classServer:...这个开关的作用是让路由层从只看会话 ID升级为同时看每个副本当前的 KV 占用与在跑请求数。文章给出的最终效果是负载呈强亚泊松分布方差不到均值的一半而不是随机路由那种必然出现的长尾。五、结果、代价与可迁移清单先说结果单副本推理性能提升每用户 2.8 倍、跨用户 5.6 倍其中一个服务每天处理数百亿 token累计达到万亿级。原文还提到朴素实现下并发用户超过 6 个左右吞吐与交互性就会一起崩。再说边界这部分比数字更重要缓存命中率。原文认为多数编码 Agent 负载的 CHRcache hit rate做到一到两个 9也就是 90%99%是很现实的但 CHR 高度依赖轨迹类型编辑类消息这种缓存不友好的模式会让优化效果明显缩水。基准测试的负载依赖性。原文单独开了一节叫 Science is a liar sometimes核心结论是我们关心的几乎每个指标都是系统 × 负载的函数TPM/GPU 取决于输出长度推测解码的 accept length 在代码上是散文的两倍。生产数据不能随便拿来调参。真实流量有限制访问且有跨请求、跨时间的变异性做实验必须隔离。如果你也在给 Agent 自建推理服务可以按这个顺序走先量化负载形态输入输出比多少、会话多少轮、重叠度多高。这一步决定后面所有取舍。再算 KV 预算单 token KV 乘目标并发数能不能装进剩余 HBM。装不下就先解决容量别急着调延迟。然后追交互性推测解码加张量并行注意 TP 度数的性价比拐点。最后处理多副本先做会话亲和再逐步上 KV 感知路由不要一上来就均匀随机。每一处量化都配 eval别把容量翻倍当成纯收益。Modal 这篇文章最有价值的不是罗列了多少 SGLang 补丁而是给出一条判断顺序先看清负载再优化单副本最后解决多副本。顺序错了前面省下的钱会在后面以更贵的方式还回来。原文也提到这些基础原理会继续复用到 Kimi K3 等新模型上具体实现细节以官方文章与 SGLang 文档为准。