跳到主要内容

Reasoning 模型推理通信

长 CoT 与 Test-time scaling 如何放大 decode 集群的 KV 压力与调度挑战

核心要点：

  • 不是模型变大：参数与单步算力没变，但单请求 decode 步数 10-100× 放大、KV 线性膨胀、长度方差大、batch 异构化
  • decode 集群三压力：KV 占用线性膨胀 （槽位下降）；continuous batch 被 preempt 频繁打散；batch 异构化压低 HBM 带宽利用
  • 长尾延迟：P99/P99.9 vs 中位数差距拉大，TPOT 因 batch 打散而恶化，FCFS HOL 阻塞短请求
  • 四类调度策略：长度预测 (TRAIL) / 动态优先级 + 抢占 (SLO-Aware) / Thinking budget 截断 / Long-decode 隔离池
  • Self-consistency: N 路 prefill 共享 + N 路 decode 横向扩 batch + 结果聚合通信 + 共享 prefix KV 跨实例可见性
  • MLA / GQA 缓解 KV：R1 用 MLA，公开论文未给 reasoning 工作负载下的 KV 实测对比

OpenAI o1 (2024-09)、o3 (2025-04)、DeepSeek-R1 (2025-01) 等 reasoning 模型把"推理时多思考"作为一条新的能力提升轴：模型在回答前先生成一段 （通常对用户隐藏的） chain-of-thought (CoT)，让 decode 阶段输出 token 数从过去的几十到几百，跃升到几千甚至数万。本文从通信和集群调度角度梳理这些变化，不重复 PD 分离原理 (见 9.2 Prefill/Decode 分离原理) 和 KV 池化机制 (见 9.4 Mooncake)。

Reasoning 工作负载推理特征怎么变​

核心问题：单请求输出 / decode 占比 / 长度方差三个维度跟普通 chat 差多少？

非 reasoning 模型 （GPT-4、Llama、DeepSeek-V3 base 等） 的生产 trace 通常呈现"prompt 长、输出短" — 例如 Mooncake FAST '25 论文实测 Kimi trace 平均输入 7,955 token、平均输出 194 token[1]。Reasoning 模型把这个比例反转。

单请求输出 token 数量级跃迁：DeepSeek-R1 论文与模型卡公开的 benchmark 配置中，所有评测的 max_generation_length 设为 32,768 token[2]; R1-Zero 训练过程中观测到输出长度从初始约 1k token 随训练步数自发膨胀至 8k 以上[3]。OpenAI o1 / o3 公告将这种能力描述为"在回答前花更多时间思考"，并给出 o3 在 ARC-AGI 上从 low-compute 75% 提升到 high-compute 87% 是通过加大推理预算实现的[4]。第三方测算 reasoning 工作负载比传统 chat 多产出"10 倍到 100 倍 token"[5]; Jensen Huang 在 GTC 2025 上把这种工作负载描述为对算力的需求"up to 100x more"。

decode 在端到端时间中占比反转：传统 chat 中 prefill 算力占比常常超过 decode （长 prompt + 短回答）；reasoning 把比例反过来 — 同样 1k token 输入，输出从 200 token 涨到 8k token 时，decode 步数从 200 变成 8000, decode 部分的累计 HBM 读取量和单请求总时长被 decode 主导。这直接放大了 9.2 Prefill/Decode 分离原理 中讨论的"decode 池容量瓶颈"。

生成长度方差极大：R1 / o1 的实际 CoT 长度高度数据相关 — 简单题可能 200 token 就给答案，IMO / ARC-AGI 类硬题轻松突破 30k token；并且长度对模型自身也不可预测[6]。这种方差使得"按平均长度预留 KV 槽"在 reasoning 场景下失效。

Decode 集群有哪些压力​

核心问题：KV 膨胀 / batch 被 preempt / batch 异构化 / PD 比例校准四个压力分别是什么？

KV cache 占用线性膨胀：Decode 阶段每生成一个 token 就向 KV cache 追加一层 K/V 张量，单请求 KV 占用 = n_layers × 2 × hidden_dim × seq_len × dtype_bytes。当 reasoning 把 seq_len 推到 32k 甚至 65k （R1 在 RL 中曾把 context 从 32,768 扩展到 65,536[3]），单请求 KV cache 在 H100 80 GB 显存上的占比可以从传统 chat 的"<1%"涨到"个位数到双位数百分点" — 对 DeepSeek-V3 / R1 这种 671B MoE 而言，MLA (Multi-head Latent Attention) 已经压缩了 KV，但绝对值仍随长度线性增长。影响：每张 decode GPU 能并发承载的 running 请求数大幅下降，吞吐取决于显存而非算力。

Continuous batch 持续被打散：vLLM v1 的调度算法在 KV 池耗尽时会 preempt running 请求 （recompute 或 swap to CPU[7]）。Reasoning 长生成使 KV 占用持续走高，单批被迫频繁触发 preemption-recompute，被 preempt 请求重新加入 waiting 队列后还要重算已生成 token 对应的 KV，等效 decode 步数被多算一遍。这是 reasoning 场景下吞吐塌方的最常见原因。

Decode batch 异构化：一个 batch 内可能同时存在已 decode 100 步的简单请求和正在 decode 第 8,000 步的难题请求；新请求源源不断到达但旧请求迟迟不释放槽位，导致 decode batch 平均填充率下降、HBM 带宽利用率下降。

对 PD 分离比例的影响：9.2 Prefill/Decode 分离原理 中按 prefill/decode 算力比拆 GPU 池的方法在 reasoning 下需要重新校准 — decode 池要扩大、且必须为长生成预留更多 KV 余量。这是 9.1 推理服务化通信总览 开放问题列出的"是否要演化为 prefill / short-decode / long-decode 三级"的工程背景。

长尾延迟具体什么形态​

核心问题：P99 / P99.9 跟中位数差距怎么形成？TPOT 怎么因 batch 被打散而恶化？

Reasoning 工作负载的延迟分布是双峰加长尾：大多数请求几百毫秒到几秒，少量"硬题"请求十几秒到几分钟。

P99 / P99.9 与中位数差距拉大：在长尾分布下，朴素 FCFS 调度 （vLLM 默认） 会让长 CoT 请求与短请求争同一批 KV 槽，HOL (head-of-line) 阻塞使短请求被拖慢。arXiv:2504.14966 (SLO-Aware Scheduling) 报告其原型相对 vLLM 把 SLO 达成率提升最多 5 倍，平均延迟降低 31.6%[6] — 侧面证明默认调度在多 SLO （短问与长 CoT 混合） 工作负载下的差距。

reasoning 模型用户感知延迟：OpenAI o1 公告将延迟刻画为"思考时间"，并在 UI 显式展示 thinking duration，是因为单次响应时间从亚秒涨到几十秒已不能藏在 streaming UX 里。第三方测量观察到 o1-pro 复杂任务可达分钟级单请求延迟。

TPOT vs TTFT 的失衡：TTFT 通常仍能保持秒级以下 （prefill 仍快），但 TPOT 因 batch 持续被打散而恶化；当用户已经看到首 token，后续 token 间断断续续，是典型的 reasoning 部署痛点。Fin AI 2025-07 报告 "Think Fast: Reasoning at 3ms a Token" 把 3 ms/token 作为 R1 推理的目标 TPOT，正是因为长 CoT 下 TPOT × token 数才是用户感知时延。

调度策略有哪四类​

核心问题：长度预测 / 动态优先级 / Thinking budget / Long-decode 隔离池各自怎么做？

针对 reasoning 长尾，业界与学术界出现的调度调整集中在四类。

长度感知 / 长度预测调度：TRAIL (Shahout et al. 2024b, arXiv:2410.05249) 训练一个剩余长度预测器，把"快要结束的请求"优先放进 batch、把"很长还没结束的请求"延后或单独成池。代价是对预测准确性敏感 — reasoning 模型自身长度不可预测的特性放大了这部分误差。

动态优先级 / 抢占：arXiv:2504.14966 SLO-Aware Scheduling 用多 SLO （短 chat 高优、长 reasoning 低优） 的分级队列，允许低优请求被抢占。抢占的代价：被抢请求要么 recompute、要么把 KV swap 到 CPU 再 swap 回来 — 后者对 NVLink / PCIe 带宽是新增负担，与 9.7 KV cache 跨节点传输瓶颈 讨论的跨节点 KV 传输形成内存系统第二条压力路径。

Thinking budget 上限 / 主动截断：给每个请求设硬性 CoT 长度上限是工程界最朴素也最常见的做法：OpenAI Responses API 暴露 reasoning.effort (low/medium/high) 抽象出三档预算；DeepSeek-V3.1 提供 "1-Think" 配置，在维持准确率的同时把输出 token 数压低 20%-50%[8]。截断本质是把"长尾分布"硬切平。

Long-decode 隔离池：在 PD 分离基础上进一步把 decode 池按预期生成长度切成两到三段 (short-decode / long-decode)，让长 CoT 请求集中在一类 GPU 上避免污染短请求 batch。这是 9.1 推理服务化通信总览 开放问题中提到的"PD 分离演化为三级"思路，尚无公开生产实例完整披露，但 Mooncake 论文 §5 已经在 Conductor 调度层为不同负载分桶做过类似铺垫。

Self-consistency / Best-of-N 的并行通信​

核心问题：N 路 prefill 共享 + N 路 decode 横向扩 + 结果聚合，各自的通信特征？

Self-consistency[9] 和 Best-of-N 把"长 CoT"再叠加"多条 CoT 并行采样" — N 通常取 8 到 64, AIME / IMO 级评测有时取到 256 或更多。

N 路 prefill 共享：同一 prompt 采样 N 次时，prefill 阶段只需算一次 KV cache，后续 N 路 decode 共用首 token 之前的 KV; vLLM、SGLang 都用 PagedAttention 的 block-level 引用计数实现这种共享，相当于"branch from common prefix"。这把 prefill 算力放大了 N 倍 — 本来打算花 200 ms 算 prefill 现在还是 200 ms，但接下来要并发跑 N 条 decode。

N 路 decode 横向扩大 batch：N 路 decode 在调度上等同于 N 个独立请求加入 decode batch, KV 占用从单倍涨到 N 倍。当 N=32 且每路 8k token 时，单 prompt 的 KV cache 总量等同于 32 个普通 reasoning 请求叠加，对单 decode 实例的显存压力非常大 — 业界做法多半把 N 路 decode 分散到多个 decode 实例并行执行，引入两类新的通信：

  • 结果聚合通信：N 路 decode 完成后，verifier / 多数投票阶段需要把 N 条结果送到聚合节点；体积小 （每条几十 KB 量级），延迟敏感但带宽不敏感
  • 共享 prefix KV 的跨实例可见性：如果 N 路 decode 落在不同 GPU 池，prefix KV 要么复制 N 份、要么通过 KV 池化按需读取 — 后者把 self-consistency 与 KV-centric 架构耦合

投机解码与多采样的协同：ACL 2025 Findings 论文 "Speculative Decoding for Multi-Sample Inference" 提出在 N 路并行采样时，利用各路之间的 token 一致性作为 draft，再由原模型一次性 verify — 相当于在 self-consistency 内嵌投机解码。

公开数据有哪些​

核心问题：DeepSeek-R1 / OpenAI o3 / R1 vs o1 成本几个关键数据？

  • DeepSeek-R1 评测 token 配置：所有公开 benchmark 使用 32,768 token max generation length; R1-Zero 训练后期上调至 65,536[3]
  • DeepSeek-V3.1 "1-Think"：在保持准确率的同时把输出 token 减少 20%-50%[8]
  • OpenAI o3 ARC-AGI: low-compute 配置 75.7%, high-compute 配置 87.5% — 同模型仅靠扩大推理预算[10]
  • OpenAI o3 / o4-mini 公告原话："retracing the scaling path—this time in RL—we've pushed an additional order of magnitude in both training compute and inference-time reasoning"[4]
  • DeepSeek-R1 vs OpenAI o1 推理成本：第三方测算 R1 在等效任务上比 o1 便宜约 70%[5]
  • DeepSeek-V3 部署形态：官方技术报告 §3.4 描述部署在 H800 集群，节点内 NVLink、节点间 IB[11]; R1 复用同一 stack
  • R1 推理 TPOT 目标：Fin AI 2025-07 报告把 3 ms/token 作为生产部署的 TPOT 目标[12]
  • Kinetics 论文观点：arXiv:2506.05333 论证先前 compute-optimality 视角下的 test-time scaling 忽略了内存访问瓶颈，BoN 类策略的实际效率比理论低[13]

Takeaway​

知识点核心结论
工作负载变化不是模型变大，是 decode 步数 10-100× 放大、KV 线性膨胀、长度方差大
Decode 集群三压力KV 占用线性膨胀 → 槽位下降；preempt 频繁打散 batch; batch 异构化压低 HBM
PD 比例需重校准decode 池扩大 + 长生成预留 KV 余量；可能演化为 prefill / short-decode / long-decode 三级
长尾延迟P99 / P99.9 vs 中位数差距拉大；FCFS HOL 阻塞短请求；TPOT 因 batch 打散恶化
四类调度策略TRAIL 长度预测 / SLO-Aware 抢占 / Thinking budget 截断 / Long-decode 隔离池
Self-consistencyN 路 prefill 共享 + N 路 decode 横扩 batch + 结果聚合 + 共享 prefix 跨实例可见
公开数据R1 max 32k token; o3 ARC-AGI 75→87% 靠扩预算；R1 比 o1 便宜 ~70%; TPOT 目标 3 ms/token

参考资料​

  1. Mooncake, arXiv:2407.00079. https://arxiv.org/abs/2407.00079
  2. HuggingFace deepseek-ai/DeepSeek-R1 model card. https://huggingface.co/deepseek-ai/DeepSeek-R1
  3. DeepSeek-R1 Nature article (DOI 10.1038/s41586-025-09422-z). https://www.nature.com/articles/s41586-025-09422-z
  4. OpenAI Introducing o3 and o4-mini (2025-04-16). https://openai.com/index/introducing-o3-and-o4-mini/
  5. Introl: Inference-Time Scaling (2025-12-12). https://introl.com/blog/inference-time-scaling-research-reasoning-models-december-2025
  6. SLO-Aware Scheduling for LLM Inferences, arXiv:2504.14966. https://arxiv.org/html/2504.14966v1
  7. vLLM Optimization and Tuning. https://docs.vllm.ai/en/stable/configuration/optimization/
  8. BentoML: The Complete Guide to DeepSeek Models. https://www.bentoml.com/blog/the-complete-guide-to-deepseek-models-from-v3-to-r1-and-beyond
  9. Self-Consistency Improves Chain of Thought Reasoning, arXiv:2203.11171. https://arxiv.org/abs/2203.11171
  10. ARC Prize, OpenAI o3 Breakthrough High Scores on ARC-AGI-Pub. https://arcprize.org/blog/oai-o3-pub-breakthrough
  11. DeepSeek-V3 Technical Report, arXiv:2412.19437. https://arxiv.org/html/2412.19437v1
  12. Fin AI: Think Fast — Reasoning at 3ms a Token (2025-07-18). https://fin.ai/research/think-fast-reasoning-at-3ms-a-token/
  13. Kinetics: Rethinking Test-Time Scaling Laws, arXiv:2506.05333. https://arxiv.org/html/2506.05333v1