飞桨大模型推理实践：从集中式部署到分离式部署架构演进

如果无法正常显示，请先停止浏览器的去广告插件。

1. 飞桨大模型推理实践 ——从集中式部署到分离式部署架构演进蒋佳军

2. 目录 01 飞桨大模型推理部署背景 02 集中式部署架构优化 03 分离式部署架构优化 04 总结与展望

4. 01 飞桨大模型推理背景

5. 大模型推理需求激增 Google 2025 年第二季度月处理Token 量思考模型RL 训练中推理耗时占比 IDC 预测推理工作负载占比 980万亿 80%+ 73% 推理Token 调用量大模型RL 训练推理服务器需求数据来源：Google 《Q2 earningscall: CEO’s remarks》数据来源：IDC| 浪潮信息《2025 年中国人工智能计算力发展评估报告》

6. 大模型推理基础流程分离式部署集中式部署请求 Decode Step Decode阶段的Batch 请求插入新的请求新插入的 Prefill阶段请求 P/D调度分配P/D 组合 Decode阶段计算中Step Decode阶段已完成Step 读取已计算的 KV向量写入新计算的 KV向量 Prefill Node Prefill Node Prefill阶段正在计算 Decode阶段的Batch 请求 Prefill 与Decode 混合Batch: 动态插入提升吞吐 KV Cache 传输显存池存储换计算：KV 向量缓存加速Decode 计算 Decode Node Decode Node Decode Node PD 分离：模型推理拆为Prefill 、 KVCache 传输和Decode 三个独立阶段

7. FastDeploy ：飞桨高效大模型推理工具 FastDeploy 生态兼容的统一接口设计飞桨CINN编译器结合图优化高性能低比特量化推理低时延高吞吐投机解码框架 ERNIE 4.5 使用界面兼容vLLM 的离线推理接口推理服务缓存管理大规模P/D 分离 DeepSeek Qwen 模型支持兼容OpenAI 协议的服务协议缓存异步LRU 汰换多级缓存索引推理优化大规模多机PD分离架构并行策略 CUDA 多国产化硬件后端支持 Graph 多机负载均衡上下文缓存分块预填充自适应增量传输量化策略高性能通信稀疏注意力仅权重量化注意力机制量化 CINN 编译优化投机解码权重激活量化 KV Cache 量化 PaddlePaddle …

8. 02 集中式部署架构优化

9. 集中式部署架构优化量化压缩 Weight Only INT8/INT4 国产芯片P800 Weight Only NT2 CCQ 量化混合精度计算 KVCache 量化 W4A8 MEPC 量化注意力量化 INT8 高性能优化分布式上下文缓存投机解码分块预填充多头解码图优化与CUDA Graph 稀疏注意力 PLAS 查表计算优化

10. 量化压缩：WINT2 压缩算法CCQ (Convolutional Code Quantization) Weight (INT4/INT8) 大模型推理显存占用比例 (GB) 60 Weight (BF16) Round(W/S) 40 Scale 20 加载时量化为INT4/INT8 精度降低权重显存占用 0 模型权重激活值 KV Cache Weight (INT4/INT8) ERNIE - 4.5- 21B - A3B 模型A800 单卡BF16 部署权重显存占用超过50% Weight (BF16) Round(W *S) x Activation (BF16) Scale 模型权重 ERNIE - 4.5- 21B - A3B 42GB ERNIE - 4.5- VL - 28B - A3B 55GB 3.5 7.2 9.5 ERNIE - 4.5- 300B - A47B 562GB - 30 11.3 18.5 ERNIE - 4.5- VL - 424B - A47B 789GB 313 21.3 111 文心系列模型权重大小对比 Kernel读取Weight 反量化为BF16 计算保障精度 Weight(BF16) 加载过程在线量化 0.075 47 96 127 0.236 - 127 48 78 2.465 127 9 45 Scale Weight(INT8) 计算过程反量化 3.5 7.2 9.5 - 30 11.3 18.4 313 22.2 111 Weight(BF16)

11. 量化压缩：WINT2 压缩算法CCQ (Convolutional Code Quantization) 解决标量低比特压缩精度损失和向量量化的推理效率低问题标量量化向量量化卷积码最常用且直观的量化方式，但在低比特如 2 bit 下精度失严重 CCQ 飞桨自研高性能低比特大模型WINT2 压缩算法将向量分组映射，得到“索引表”和“ 码本”，保留向量数据相关性，解决标量压缩的精度损失。但同时也带来推理查表性能问题图例来源：https:// speechprocessingbook.aalto.fi /Modelling/Vector_quantization_VQ.html 通过卷积码构建“码本”，消除反量化过程的查表，仅需移位和掩码反量化，优化推理性能

12. 量化压缩： WINT2 压缩CCQ 算法 84.47 86.07 86.73 IFEval OTPS CMMLU CCQ GGUF 57.91 38.45 82.19 Ceval ERNIE - 4.5- 300B - A47 模型， 2x NVIDIA H20 - 141GB, 52 core Intel(R)Xeon(R) Platinum 8563C 276.42 TPS 197.58 FastDeploy CCQ 算法量化与反量化过程 85.26 80.22 LLAMA.CPP CCQ 与GGUF 量化对比 H20 单卡即可实现文心4.5 300B 大模型部署 ERNIE - 4.5- 300B - A47B 权重大小 GSM8K DROP MMLU RTN(WINT8) 281GB 96.62 91.13 86.52 RTN(WINT4) 149GB 96.21 91.17 86.16 CCQ(WINT2) 89GB 95.30 88.34 82.31

13. 量化压缩：MoE 模型的W4A8 多专家并行协同量化 MEPC 算法 Mo E 模型W4A8 量化挑战 (Multi- Expert Parallel Collaboration ）专家并行协同量化量化效率 • 专家多粒度小，计算资源利用不充分 • 激活所有专家，需要大量训练数据 • 多专家拼接并行校准，提升计算资源利用率 • 激活专家推算未激活专家系数，降低训练数据量跨节点异常点转移算法 • 通过权重重排操作，所奖有的outliers 迁移，集中到一张卡，减少整体的量化损失量化效果 • 张量并行下异常点多节点分布问题 • 节点内的异常值影响层自适应的旋转转置 • 分块旋转与排列结合，兼顾推理效率和异常值平滑 • 根据各层特点自适应选择优先处理激活或处理权重

14. 量化压缩：MoE 模型的W4A8 多专家并行协同量化文心4.5模型精度接近无损，相比FP8 吞吐提升 17%~30% 1000000 111083 129726 100000 10000 6761 8781 1000 ERNIE-4.5-300B FD-8bit 基于MEPC算法解决MoE模型的量化效率与效果问题 ERNIE-4.5-21B FD-W4A8 W4A8与FP8推理吞吐对比 8 x NVIDIA H800 - 80GB ，CUDA 12.8 48 core Intel(R) Xeon(R) Platinum 8468V

15. 突破长文性能瓶颈：可插拔式稀疏注意力PLAS 低成本蒸馏微调注意力门控选择重要性块模型根据输入长度自适应选择 Full Attention 或 Sparse Attention Head 及Token 维度对齐实现高性能推理同时加速P/D 性能精度 (LongBenchV2) 性能 FullAttention PLAS TTFT TPOT QPS ERNIE - 4.5- 300B - A47B - 128K 40.02 40.05(+0.03%) - 30% - 34% +23% ERNIE - 4.5- 21B - A3B - 128K 30.82 30.41(- 0.41%) - 48% - 31% +48%

16. 国产昆仑P800 芯片性能优化优化1：整网BF16 存储+FP16 计算方案 FP16 方案 BF16 + FP32 FP16 BF16 cast GEMM (FP16) FP32 优化3 ：基于查表优化复杂函数计算优化2 ：INT4 *INT8 直接计算 BF16+FP16 权重 BF16 INT4 cast_te (per token) 𝑆𝑤𝑖𝑠ℎ 𝛽 𝑥 = Dequat 激活 FP32 GEMM (FP32) FP32 FP16 GEMM (FP16) 𝑒 𝑥 𝑖 𝑆𝑜𝑓𝑡𝑚𝑎𝑥 𝑥 = σ 𝑗 𝑒 𝑥 𝑗 INT8 INT8 𝑥 1 + 𝑒 −𝛽𝑥 GEMM (INT8) FP32 cast cast FP16 FP16 cast BF16 激活 lookup_table 权重 INT8 INT4 table 量化 x index N [0, N- 1] GEMM (INT8) 模型效果无法达标性能劣化 30% 效果性能达标利用硬件特性，发挥算力优势，性能提升 10% ！ … 利用硬件查表指令，实现对复杂函数快速计算，性能提升 5% ！

17. 分布式多级上下文缓存高效管理 Cache 感知调度全局索引查询优化请求调度内存分配连续性优化 GPU 换至CPU 引擎同步读取Cache Cache 管理异步执行LRU 引擎读写与KVCache 的LRU 异步解耦零拷贝优化 AttentionStore 0 2 9 DRAM 4 7 6 3 … … Cache 流水线并行优化正反向索引高效构建查询驱逐释放 CPU Cache 写入KV Cache 异步LRU 非阻塞管理 AttentionStore Master GPU Cache Engine LLM Engine HBM 读取CPU KV 读取KV 多设备并行读写 SSD SSD SSD SSD 0 基于最小堆管理 KV Cache 存储块 2 4 基于普通列表管理，分配显存地址 [0,2,9,4] 3 7 6 9 基于最小堆管理，分配显存地址 [0,2,3,4] 优化后显存分配地址连续性强，更友好跨介质间的数据拷贝

18. 03 分离式部署架构优化

19. 分离式部署需求分析集中式推理问题 Prefill与Decode所需资源类型不同 Prefill 为计算密集型，依赖算力强劲的GPU 加速 Decode 为存储密集型，依赖更高的内存带宽 1 Prefill混合并行带来的性能波动 Prefill 与Decode 混合并行的『木桶效应』：长输入的Prefill 任务导致Decode 阶段时延急剧上升 2 资源浪费和成本增加生产环境中Prefill 与Decode 的资源需求随输入输出长度动态变化，集中式的部署无法灵活按需配置资源 3 独立优化与异构部署针对Prefill 与Decode 分别做推理上的优化，采用不同的硬件满足计算和存储需求更优的性能与更可靠的SLO 摆脱『木桶效应』，更快的请求响应速度，同时解决长输入请求带来的时延上升问题，保障稳定性精细化资源管理通过系统输入输出长度变化，以及对首Token ， Token 间时延的要求，精细调整Prefill/Decode 资源

20. 分离式部署架构分离式部署挑战 … 负载均衡相比集中式部署，需分别平衡Prefill 与Decode 的负载；针对MoE 模型EP 并行，需进一步平衡各专家的负载 Request (p0, d3) Prefill 0 Request (p1,d1) Prefill 1 Prefill 2 Prefill 3 KV传输与通信 Prefill 计算的KV 传输至Decode P refill 计算完的KV 需要跨进程跨节点传输给Decode 计算，额外引入传输耗时。在MoE 模型采用EP 并行后，进一步引入专家间数据传输系统运维 Decode 0 Decode 1 Decode 2 Decode 3 分离式部署架构中，各Prefill 和Decode 不再是独立的实例节点，Prefill 需感知所有的Decode 实例，同时处理在KV Cache 传输或者Decode 实例异常问题 PD 分离下，请求先在Prefill 计算完生成首 Token ，再在Decode 继续生成剩余的Token

21. 分离式部署与分布式上下文缓存加速推理请求负载均衡查询Cache 命中全局KVCache 索引 Prefill负载均衡 Prefill 各DP 负载指标为未完成请求 Token 总数与Cache 命中Token 数差值，Scheduler以此为均衡条件进行调度 Token 流 Scheduler Decode 流式返回生成的Token PrefillDP 从Scheduler 拉取分配给自己的请求 Cache 索引定期同步 Prefill_0DP_0 EP0 Decode_0 Prefill_0DP_1 EP1 EP2 EP3 EP4 EP5 Attention EPLB 申请Cache 资源 EP0 DP_0 EP1 Decode_0 EP2 DP_1 EP4 EP5 Attention EPLB EP3 Decode负载均衡 Decode 各DP 负载指标为未守成请求数，Scheduler以此为均衡条件进行调度 Attention 读取Prefix Cache HBM 专家负载均衡收集Prefill/Decode 各DP 上专家负载，定期重排各节点及各卡上的专家权重 Cache 加载至HBM EPLB 写入KV Cache Cache HBM Cache Attention KV 传输 HBM EPLB Cache HBM Cache Cache 同步至AS AttentionStore (DRAM/SSD Cache) AttentionStore (DRAM/SSD Cache) AttentionStore (DRAM/SSD Cache) AttentionStore (DRAM/SSD Cache)

22. KV 传输与通信优化轻量高效的RDMA 传输协议自适应的增量Cache 传输传输库 • 轻量：部署简单轻量，仅需基础的RDMA 运行环境即仅传输新增部分的 Cache 同一节点内 NVLink Prefill 可使用 • 高性能：减少CQE 数量和支持PCIe Relaxed Ordering 等优化，单线程传输效率更高，多线程带宽打满 Decode 跨节点 Prefill RDMA NIC Prefill Decode Cache Cache Decode • 动态建连：支持PD 比例动态扩缩容 Layerwise 方式掩盖传输耗时 RDMA 单线程传输速度对比 Decode Prefill 60 40 layer0 20 layer1 0 layer2 1K 2K 4K 8K FastDeploy 16K 32K Mooncake 64K 128K 256K … KV Transfer KV Transfer KV Transfer KV Transfer layer0 layer1 layer2 …

23. 基于DeepEP 的自适应双阶段通信优化纯RDMA 通信带宽受限自适应双阶段通信优化 • EP 并行度低的场景下，存在大量节点内通信 • 节点内通信采用NVLink ，节点间通信采用RDMA • 跨节点通信第一阶段基于RDMA 将数据传输至对应节点对应GPU 卡，第二阶段在对应节点内基于 NVLink 将数据传至其它GPU 卡 • 跨节点通信存在重复使用RDMA 进行传输需求 RDMA 通信 EP0 Node 0 Node 1 Token Token EP1 EP2 EP3 EP4 NVLink 通信 RDMA 通信 EP5 EP6 EP16 通信效率提升1倍 EP7 EP0 Node 0 Node 1 Token Token EP1 EP2 EP3 EP4 EP5 EP6 EP7

24. 分离式系统稳定性保障稳定性保障 Scheduler调度服务发现重调度与实例更新 • 重调度接口支持Prefill/Decode 即时通知调度处理异常请求 • 专家负载均衡定期滚动更新，实例异步权重加载 PD 流转过程异常系统无感的EPLB 请求即时重调度异步滚动重排 PD 实例集群续推Agent • 针对实例软硬件问题，即时将异常请求与已生成结果拼接进行续推，避免PV Lost同时，优化计算资源抢占Agent • 针对集群资源动态调整需求，结合续推Agent ，实现推理实例实时退出实例间RDMA 建连实时更新 Prefill Decode 软硬件问题异常请求续推处理续推Agent Decode Prefill Prefill Decode 结合续推实现系统资源无损实时抢占抢占Agent

25. 文心大模型的分离式部署优化 PD 分离分布式架构，文心性能再提升 ITPS 56K ，OTPS 21K ，TPOT 50ms ERNIE - 4.5- 300B - A47B Prefill Proposal 多Token 上下文 FP8 MTP 调度层Query 均衡 Ngram + 服务层Token 均衡 INT4 KV Step1: Daft Token Step2: Verify Verify Decode 引擎层专家负载均衡 Tree Attention W4A8 Prefill/Decode/KV传输优化动态置信度自适应双阶段通信优化投机解码加速优化 PD 负载均衡多级负载均衡优化

26. 04 总结与展望

27. 文心飞桨推理架构的演进史 2025.06 2023.03 2023.08 PagedAttention 文心一言发布支持大模型动态插入与KV Cache 支持PagedAttention 及异步调度，性能优于vLLM 2024.10 FastDeploy 分离式部署部署代码全面重构升级，对外正式开源FastDeploy 2.0 Prefill 与Decode 的分离，以及分布式 PrefixCaching 上线

28. 未来计划四级缓存通过集群KVCache 池化支持推理实例从其它推理实例获取 KVCache 加速Prefill 计算 Prefill AF 分离进一步推理资源管理精细化 CPU 传输优化资源利用率 KV传输 DRAM GPU 直传依赖提前占用Decode 显存资源导致资源利用不充分， Decode HBM HBM KVCache KVCache NVLink /RDMA 传输新增CPU 传输优化吞吐 AF分离针对Attention 与FFN 任务的差异进一步精细化部署的资源管理，降低推理成本 DRAM/ SSD KVCache 集群Cache 池化作为第四级缓存 DRAM/SSD KVCache

29.

30. THANKS 大模型正在重新定义软件 Large Language Model Is Redefining The Software