BotOf TechAI / IoT / Full-Stack / 植物养护知识分享
返回首页推理集群正在从同构 GPU 池变成流水线：异构解耦的收益与代价

推理集群正在从同构 GPU 池变成流水线：异构解耦的收益与代价

·7 分钟阅读·
AI InfraLLM 推理Disaggregated InferenceKV Cachellm-d

7 月 23 日，AMD 与 Cerebras 公布一套异构推理方案：AMD Helios 负责高吞吐 prompt 处理和大上下文 Prefill，Cerebras Wafer-Scale Engine 负责低延迟 Decode 与 token 生成，两类系统组成同一条推理流水线。厂商预计最高可提高 5 倍 tokens/s/W，并计划在 2026 年下半年先通过 Cerebras Cloud 提供。

先不急着接受性能数字。这项合作真正重要的地方，是两家公司不再假设“一种加速器应当完成整次推理”。它们按 Prefill 与 Decode 的计算特征拆开硬件，让推理集群从同构资源池走向阶段化流水线。

这种架构与 llm-d、NVIDIA Dynamo 等软件栈正在推进的 Prefill/Decode disaggregation 相互印证。AI Infra 的下一轮优化，很可能不是再找一张各项指标都更强的卡，而是把模型执行拆成阶段，为每个阶段匹配计算、内存、互联和扩缩容策略。

一次 LLM 请求，其实包含两种机器

Prefill 读取整段 prompt，计算各层的 Key/Value 并生成首个 token 所需状态。它能并行处理大量输入 token，通常更偏计算密集，压力随输入长度和上下文数量增长。

Decode 在已有 KV cache 上逐 token 生成。每一步计算量相对较小，却要反复读取模型权重和 KV 状态，常受显存带宽、容量、并发和批处理效率约束。

阶段主要输入主要瓶颈用户感知
Prefillprompt、检索文档、图像编码结果计算吞吐、长上下文、排队TTFT
DecodeKV cache、上一 token内存带宽、活跃序列、批处理TPOT、输出速度

聚合式部署让每个 worker 同时承担两阶段，简单但会互相干扰：一个超长 prompt 可能占住计算，让正在输出的请求发生抖动；为峰值 Prefill 扩容，又可能留下大量 Decode 闲置能力。

解耦后，两类 worker 可以使用不同并行度、不同副本数，甚至不同硬件。代价是 Prefill 生成的 KV cache 必须在 Decode 开始前跨设备可见。

KV cache 传输决定解耦是否成立

对标准多头注意力，一个请求的 KV 状态量级可以近似写成：

KV bytes ≈ 2 × layers × sequence_length
           × kv_heads × head_dim × bytes_per_element

前面的 2 代表 Key 与 Value。GQA/MQA 会通过更少的 kv_heads 降低体积，低精度 KV 也能减少字节数，但长上下文、多层模型和高并发仍会快速放大传输量。

因此解耦后的首 token 时间变成：

TTFT = 排队 + Prefill 计算 + KV 传输 + Decode 启动

如果 KV 从 GPU 回到 CPU，再走普通 TCP，到另一台机器后重新写入显存，传输成本可能吞掉全部分离收益。高性能实现通常依赖 NVLink、InfiniBand/RDMA、GPUDirect 和 NIXL/UCX 等路径，让 Decode worker 直接拉取 Prefill worker 显存中的 KV block。

llm-d 文档明确指出：KV 传输位于 TTFT 关键路径；一旦 RDMA 缺失或悄悄退化到 TCP，常见现象就是 Prefill 有容量、Decode 在等待，但端到端 TTFT 仍然变差。

异构硬件比同构解耦再多一层兼容问题

同一型号 GPU 上分离 Prefill 与 Decode，主要处理拓扑和调度；AMD Helios 与 Cerebras WSE 这种异构组合，还要解决执行格式、KV layout、精度、分片和跨运行时协议。

至少要有一份可验证的阶段契约：

model_revision
tokenizer_revision
attention_layout
kv_dtype
page_size
layer_partition
sequence_position
request_id
transfer_capability
checksum_or_integrity_tag

任何一项不一致，都可能不是“报错退出”，而是更危险的 silent corruption。比如 tokenizer 或位置编码版本不同，表面仍能输出 token，语义却已经偏离；KV dtype 或 page layout 不一致，则可能在传输或恢复阶段失败。

llm-d 的 SGLang 运维文档因此建议：滚动升级时不要把不兼容的新旧 Prefill/Decode 实例混在同一个 InferencePool，而是创建新池，再用 Gateway/HTTPRoute 逐步切流。这和普通无状态 Web Pod 的滚动发布完全不同，因为 worker 之间共享的是 GPU 内存布局契约。

路由器从负载均衡器升级为推理调度器

传统负载均衡器看连接数、请求数和健康状态。解耦推理路由至少要同时理解：

  • 模型、精度和 KV layout 是否兼容；
  • prompt 长度与预计 Prefill 成本；
  • Decode 侧活跃序列和剩余 KV 容量；
  • 哪个 worker 已缓存相同前缀；
  • Prefill 与 Decode 的网络拓扑和传输带宽；
  • 租户优先级、TTFT/TPOT SLO 与最大排队时间。

KV-aware routing 和 P/D disaggregation 是相关但不同的能力。前者尽量把请求送到已有相同 prefix cache 的 worker，减少重复计算；后者把两个阶段放进不同池。生产系统通常需要两者一起工作，但调试时必须分开度量，否则 cache hit 变高却 TTFT 变差时，很难知道是路由还是传输出了问题。

为什么 Agent 和实时交互会推动解耦

普通聊天还能容忍几秒等待，Agent、代码生成、语音交互和机器人控制更依赖反馈速度。Agent 每轮可能只生成少量 token 就调用工具，再根据结果继续推理；如果每轮 TTFT 都很高，几十轮以后墙钟时间会迅速累积。

同时，Agent 的上下文越来越长：系统指令、工具 schema、历史轨迹、检索资料和工作区状态会共同进入 Prefill。于是同一工作负载同时要求“吞下更长输入”和“更快开始输出”。

异构解耦正好允许两个目标分别优化：吞吐型系统处理大规模 Prefill，低延迟系统负责 Decode。但它不能解决所有等待。工具 API、沙箱启动、数据库、网络和人工审批仍可能占据主要时间，优化 token 速度前必须先画出完整关键路径。

什么情况下解耦反而更差

Disaggregated inference 不是默认答案。以下场景通常先保留聚合部署：

  • 模型较小、prompt 短、并发低；
  • Prefill 与 Decode 比例稳定，单池已经有高利用率；
  • 集群没有可靠的 GPU-direct 或 RDMA 路径；
  • 团队尚不能观测 KV 传输、队列与拓扑；
  • 业务更看重简单恢复，而不是极致 TTFT/吞吐。

解耦新增了路由、KV 索引、传输、两类 worker、版本契约和跨阶段取消。任何一个组件出错都可能让请求占着 GPU 内存等待。

例如客户端在 Prefill 完成前断开，系统需要同时取消 Decode 等待、通知 Prefill、释放已分配 KV、清理路由元数据。某些实现中，NIXL 路径上的 prefill cache 并不会因为 bootstrap bookkeeping 被清理而自动释放；如果取消和超时没有覆盖每个阶段，显存会以“没有活跃请求”的形式慢慢泄漏。

基准测试要同时保护延迟、吞吐和正确性

厂商的“最高 5 倍 tokens/s/W”属于面向未来联合方案的预期值，不是任意模型与流量下的保证。自己的 PoC 至少要用真实分布比较聚合和解耦：

  1. 输入长度 P50/P95/P99，而不是固定 1K prompt；
  2. 输出长度与并发分布；
  3. prefix 重复率和 cache hit；
  4. TTFT、TPOT、端到端延迟和 timeout；
  5. Prefill/Decode queue time 与 GPU 利用率；
  6. KV 传输字节、带宽、耗时和 TCP fallback；
  7. tokens/s/W 与每个通过质量门请求的成本；
  8. 节点故障、路由重启、版本升级和客户端取消后的资源回收。

同时做输出一致性检查。不同硬件、精度和 runtime 可能带来数值差异，不能只因为 token 更快就接受质量回退。对确定性任务可做 schema 和 exact/semantic match；对开放生成至少用冻结评测集和人工抽检。

一条更稳妥的落地路线

第一阶段先在同构硬件上分离 Prefill/Decode，证明工作负载确实存在阶段失衡，并把 KV transfer 路径跑通。第二阶段加入 KV-aware routing 和独立 autoscaling。第三阶段才尝试不同型号或不同厂商加速器。

每一步都保留聚合基线和快速回退：

Stage 0  aggregated baseline
Stage 1  same-node P/D, NVLink or IPC
Stage 2  cross-node P/D, RDMA + topology-aware routing
Stage 3  independent scaling + KV-aware routing
Stage 4  heterogeneous accelerator pipeline

不要从 Stage 0 直接跳到 Stage 4。否则性能问题发生时，无法区分是模型、runtime、网络、KV 格式、路由策略还是硬件本身。

趋势判断：推理芯片会专业化，软件接口必须反向统一

训练时代追求更大的同构集群，因为同步计算和集合通信需要一致性。推理流量更加多样：长上下文、短输出、实时语音、批量生成、Agent 循环、视觉编码和稀疏 MoE 对硬件的偏好不同。

因此推理基础设施更可能走向专业化：某些系统擅长 Prefill，某些擅长低延迟 Decode，某些承担多模态 Encode，CPU、GPU、TPU、WSE 和专用 ASIC 共同存在。硬件越异构，软件越需要统一模型身份、KV/embedding 传输、路由目标、可观测性与发布协议。

真正的护城河不会只是“拥有哪一种芯片”，而是能否让不同计算阶段在不牺牲正确性、可恢复性和运维效率的情况下协同。推理集群从资源池变成流水线之后，数据移动和控制面会像计算本身一样重要。

参考资料

← 返回所有文章