TokenSpeed PD分离架构详解Prefill与Decode解耦如何突破吞吐极限【免费下载链接】tokenspeedTokenSpeed is a speed-of-light LLM inference engine.项目地址: https://gitcode.com/gh_mirrors/to/tokenspeedTokenSpeed 是一款被称为光速的 LLM 推理引擎其 PD 分离Prefill-Decode 解耦架构将大模型推理的Prefill提示词预填充与Decode逐词生成两个阶段拆分到独立的节点组上运行让吞吐与延迟各自独立扩展。本文面向新手完整讲解 TokenSpeed PD 分离的工作原理、P/D 角色划分、KV 缓存传输机制以及如何通过合理配置突破单实例吞吐极限。为什么分离混合执行 Prefill 与 Decode 的隐藏瓶颈理解 PD 分离先要理解 LLM 推理的两个阶段在性格上截然不同阶段计算特征核心诉求Prefill一次性处理整个提示词计算密集compute-bound快降低首 token 延迟TTFTDecode每步只生成 1 个 token访存密集memory-bound稳降低每 token 间隔TPOT当两者混在同一批请求中执行时问题就出现了一条长提示词的 Prefill 任务会霸占GPU 一整轮让所有正在 Decode 的请求集体卡顿反过来频繁的 Decode 小批次又会压低长文本的 Prefill 吞吐。TokenSpeed 的解法是彻底分家Prefill 引擎和 Decode 引擎作为独立角色启动各自针对自己的计算特征做硬件和并行策略优化。调度器设计上甚至明确规定PD 分离部署中的Decode 角色从不计算提示词行提示词 logprobs 由 Prefill 节点直接返回见 docs/design/scheduler.md。TokenSpeed PD分离怎么配P/D 角色划分与 KV 缓存传输TokenSpeed 通过--disaggregation-mode参数指定节点角色核心逻辑集中在python/tokenspeed/runtime/pd/目录P 节点Prefill--disaggregation-mode prefill负责处理提示词、构建 KV 缓存代码入口为 prefill_executor.pyD 节点Decode--disaggregation-mode decode只负责逐 token 生成代码入口为 decode_executor.pyKV 缓存怎么跨节点传P 节点算出的 KV 缓存必须完整送达 D 节点否则 Decode 无法续上上下文。TokenSpeed 基于Mooncake传输引擎实现零拷贝高速搬运控制面采用 ZMQ 状态机按bootstrap_room房间号跟踪每个请求的传输状态失败状态具有粘性避免迟到的成功信号复活已损坏的传输。关键实现传输引擎python/tokenspeed/runtime/pd/base/mooncake_engine.py收发逻辑python/tokenspeed/runtime/pd/mooncake/ 目录下的sender.py/receiver.py拓扑管理python/tokenspeed/runtime/pd/topology.py、python/tokenspeed/runtime/pd/transfer_plan.py一个精巧的细节请求被分配到哪个 P 节点由room % dp_size余数决定——也就是说放置策略内建在房间号里无需额外的负载均衡服务参与。灵活并行配置P 节点拼吞吐D 节点拼延迟PD 分离最大的红利是 P 和 D可以使用完全不同的并行拓扑。以官方 Kimi K3 多节点部署为例docs/guides/kimi-k3-hopper-pd.md引擎注意力并行路由专家执行方式PPP4, TP8, DP1每阶段内 EP8Eager 分块 PrefillDPP1, TP8, DP4跨 4 节点 EP32Decode CUDA Graph可以看到P 节点用流水线并行PP 分块 Prefill--chunked-prefill-size 8192压榨长文本算力D 节点则用数据并行DP 专家并行EP32 低延迟通信模式把每 token 间隔压到最低。这种各取所需在混合部署中是做不到的。更多并行参数说明见 docs/serving/parallelism.md。从 1P1D 到多节点如何选择合适的分离拓扑TokenSpeed 支持从最小的1P1D1 个 Prefill 实例 1 个 Decode 实例平滑扩展到多 P 多 D 的大规模拓扑入门级单机多卡1P1D 适合验证链路例如 Qwen3.5-397B 的 1P1D 部署脚本 test/ci/serve_qwen35_397b_nvfp4_pd_1p1d.sh以及 DeepSeek-V4.1 Flash 的对应测试 test/runtime/distributed/test_deepseek_v41_pd_1p1d.py生产级多节点Kimi K3 采用 P 与 D 各占 4 节点共 64 卡的布局Qwen3.5-397B 的 PD 评测配置 test/ci/eval/qwen3.5-397b-a17b-nvfp4-pd-1p1d-evalscope-aime25.yaml 展示了完整的基准测试写法选择建议提示词普遍很长RAG、代码库问答→ 加大 P 侧数量并开启分块 Prefill并发高、输出长 → 加 D 侧 DP 副本。P/D 比例可以随业务负载独立扩缩容这正是 PD 分离突破吞吐极限的关键所在。性能指标速查TTFT、TPOT 与吞吐怎么测PD 分离的收益需要用数据说话TokenSpeed 官方验证流程见 docs/guides/kimi-k3-hopper-pd.md 的 Validation 章节要求记录以下指标TTFTTime To First Token由 P 侧主导衡量提示词处理 KV 传输的总耗时TPOTTime Per Output Token由 D 侧主导衡量逐词生成速度P 侧吞吐计算输入 tokens/sD 侧吞吐输出 tokens/s每卡显存峰值与传输错误率官方 CI 中的 PD 部署评测如qwen3.5-397b-a17b-nvfp4-pd-1p1d就是按这套口径自动采集的方便你横向对比分离 vs 混合的真实差距。PD 分离常用参数与官方文档索引核心参数速览参数作用--disaggregation-mode prefill / decode指定节点角色--chunked-prefill-size 8192P 侧分块大小长文本吞吐关键--pipeline-parallel-sizeP 侧流水线并行深度--data-parallel-size/--expert-parallel-sizeD 侧扩展副本与专家并行宽度--max-num-seqsD 侧最大并发请求数延伸阅读入门与启动指南docs/guides/launching.md、docs/guides/getting-started.md并行策略全解docs/serving/parallelism.md调度与容量管理docs/design/scheduler.mdPD 传输测试用例test/runtime/distributed/test_pd_transfer_plan.py总结TokenSpeed 的 PD 分离架构通过角色分家 独立扩缩容 高速 KV 传输三板斧让 Prefill 拼算力、Decode 拼带宽互不干扰是长文本、高并发场景下突破 LLM 推理吞吐极限的完整指南式方案。从 1P1D 起步验证再按业务负载扩展 P/D 比例即可稳定获得 TTFT 与 TPOT 的双赢。【免费下载链接】tokenspeedTokenSpeed is a speed-of-light LLM inference engine.项目地址: https://gitcode.com/gh_mirrors/to/tokenspeed创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考