京东零售大模型推理优化实践

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

1. 京东零售大模型推理优化实践演讲人：杨培军

2. 目录 01 大模型应用场景 02 大模型应用挑战 03 核心优化实践 04 总结及展望

4. 01 大模型应用场景

5. 行业发展趋势互联网头部玩家悉数入局，竞逐战略要冲，攻坚大模型技术迭代大模型技术深化，多模态感知、智能体应用、边缘智能部署等多维突破大模型驱动电商全链路深度变革，重构技术基座

6. DeepSeek重塑开源生态、加速产业落地性能突破 ⚫ 在数学、代码、自然语言处理等多个评测任务中展现出强大的性能，与顶级闭源模型比肩，甚至部分超越架构创新 ⚫ ⚫ ⚫ MoE混合专家网络：6710亿参数，单次推理仅激活370亿参数，推理效率提升3倍 MLA多头潜在注意力：突破长上下文瓶颈，推理显存降低80%以上 GRPO强化学习新范式：无需人工标注，自主涌现复杂推理能力成本颠覆训练成本为同级别模型的约1/10，推理API调用成本仅为同级别模型的约1/30

7. 京东电商大模型应用场景 Generative AI • AI 生成商品图生成、短视频、AI AI 商品图生成、视频生成、AI 营销营销内容生成、AI 数字人内容生成、AI 数字人 Agentic AI • AI 生成商品图生成、短视频、AI AI 客服与售后管理、AI 经营托管、营销内容生成、AI 数字人 AI 仓配优化、AI 交互式推荐 Physical AI • AI 生成商品图生成、短视频、AI 自动分拣机器人、智能空间、自动驾驶营销内容生成、AI 数字人

8. 02 大模型应用挑战

9. 大模型应用挑战技术挑战模型的规模、效果和效率的平衡，性能优化和轻量化的挑战输入/输出长度和模态多样，硬件异构，用户优先级，不同 SLO，分布式调度的挑战

10. 内存容量、访存带宽和算力利用率压力内存容量和访存带宽是瓶颈，算力利用率低 Prefill阶段：一次Forward完成，Compute Bound Output: [‘A’] (1*di m) Output: [‘robot’] (1*di m) GEMV矩阵乘向量 In put: [‘Reci te’, ‘the’, ‘fir st’, ‘law’, ‘of’, ‘robotics’] In put: [‘Reci te’, ‘the’, ‘fir st’, ‘law’, ‘of’, ‘robotics’, ‘A’] Decode阶段：自回归串行执行，N-1次Forward完成，Memory Bound ⚫ ⚫ 模型参数量爆发式增长，以DeepSeekR1-671B为例，理论参数 (FP8) 占用671GB，而H20单卡显存只有96GB 自回归解码Prefill和Decode计算特性差异大，串行Decode算力利用率低 KV Cache导致“内存墙”瓶颈进一步加剧 ⚫ KV Cache显存占用开销随序列长度、batch size增加成倍上升，内容容量和访存问题加剧

11. 服务场景高度多样化随时间变化的输入长度 / 输出长度用户请求存在不同的高峰时间段不同的请求优先级以及SLO User A User D User B User E User C User G 多种模态 ⚫ 文本 ⚫ 图片 ⚫ 视频 ⚫ 语音异构、碎片化部署，集群Failover Instance A Instance B

12. 推理系统优化的核心要素高吞吐 Tokens/秒，单卡高吞吐意味着更低的成本低时延 TTFT/TBT，更低时延保障更好的用户体验高可用 SLO保障、Request / Instance Failover处理等

13. 03 核心优化实践

14. Introduction ~2024 GPU芯片禁售 DeepSeek爆火京东自研大模型推理框架国产芯片 NPU推理 DeepSeek 推理优化前期版本核心功能

15. 京东大模型推理架构 Highlight Feature ⚫ ⚫ ⚫ NPU/GPU高效推理 DeepSeek、Qwen3等模型支持纯C++ Runtime，全异步并行 Moreover, ⚫ 分离式架构多维并行、EPD分离、KV Cache Pool ⚫ ⚫ ⚫ ⚫ 多级负载均衡多层流水线Overlap 智能集群调度 …

16. 分离式架构深度解耦的分布式系统设计单体模式单设备 ⚫ Bert ⚫ ViT 模型结构分离拆模型结构 ⚫ TP并行 ⚫ PP并行 ⚫ EP并行 ⚫ DP并行计算阶段分离拆计算阶段 ⚫ C++ Runtime全异步并行 ⚫ Vision模态分离 ⚫ PD分离存储资源分离拆存储资源 ⚫ KV Cache Pool 突破资源瓶颈，构建弹性、高效、可扩展的分布式推理系统突破单设备算力/显存限制 -> 突破计算阶段资源错配限制 -> 突破 KV Cache 显存限制

17. 分离式架构 – 多维混合并行 TP 优点 ⚫ 显著降低单设备内存压力、提高计算并行度缺点 ⚫ ⚫ 权重无法切分时重复存储（MLA单head场景） All-reduce通信量大适用场景：多机多卡广泛使用 PP 优点 ⚫ 支持超深模型按层切分，降低单设备内存压力缺点 ⚫ ⚫ 流水线bubble降低利用率微批次划分影响效率适用场景：层数较多或长序列场景 DP EP 优点 ⚫ 支持多专家分散部署，降低显存压力、提高计算并行度缺点 ⚫ ⚫ 专家通信开销大专家负载均衡问题适用场景：MoE模型Only 优点 ⚫ 避免重复计算和存储，减少通信缺点 ⚫ ⚫ DP instance需存完整模型副本 DP组负载均衡问题适用场景：中小尺寸结构、减少通信

18. 分离式架构 – 多维混合并行 MoE模型EP/TP/DP混合并行设计

19. 分离式架构 – PD分离 Motivation Continous Batching调度时，PD两阶段资源需求和计算特性差异大，会产生相互干扰问题，导致资源浪费、SLO难以满足。 ⚫ Prefill：Compute-bound，一条足够长的请求就能计算饱和，计算时间长，会导致Decode时延变长 ⚫ Decode：Memory-bound，必须大batch才能计算饱和，对 KV Cache的频繁访存，会影响Prefill计算效率 Solution ⚫ ⚫ Prefill和Decode资源隔离部署，各自独立处理，解决相互干扰问题资源卡型分配和并行策略解耦，可为Prefill和Decode分别定制最适合的优化方案 -> 降低TTFT和TBT，提升系统吞吐。

20. 分离式架构 – PD分离 KV Cache传输通道 ⚫ ⚫ AS IS：PD Device直推，时延短，但PD需相互配合等待 TO BE：Offload DRAM，时延长一些，PD执行可完全解耦异步并行化 Service KV Cache传输分块 ⚫ ⚫ AS IS：Layer-wise，长sequence可降低传输时延，短sequence时存在小包问题 TO BE：根据sequence长度做判断，按需做合并传输 Prefill Instance GPU Incremental Prefill Prefix KV Cache CPU Decode Instance Incrementa l KV Cache Layer-wise Store Full KV Cache GPU 1）Device直推 Layer-wise Transfer 2）Offload DRAM Decode Full KV Cache CPU Async Load Full KV Cache

21. 分离式架构 – EPD分离 Service Autoregressive 全局调度 image request Encode Instance Download/ Preprocessing text request Prefill Instance Decode Instance Language Model Language Model KV Cache KV Cache Vision Model Image Cache ⚫ ⚫ VLM执行流程资源隔离部署，降低相互干扰 Image预处理、Encode与Text Tokenizer异步并行

22. 分离式架构 – KV Cache Pool Motivation ⚫ ⚫ KV Cache 为每个序列独立存储历史生成的所有 Key/Value 向量，其内存占用量大随序列长度线性增长（如 LLaMA2-13B单 4K长的序列缓存高达 3GB） HBM存储空间有限（如H20 96G显存） Service Prefix Cache 全局调度 ETCD KV Cache Meta上报 Solution ⚫ ⚫ KV Cache Offload到DRAM/SSD，扩展HBM空间不同Instance的HBM/DRAM/SSD多级KV Cache存储做全局共享管理，组建“KV Cache Pool” 适用场景： ⚫ 全局Prefix Cache Pool ⚫ PD KV Cache传输Pool Prefill Instance GPU Decode Instance Incremental Prefill Prefix KV Cache GPU Incrementa l KV Cache Layer-wise Load and Store Incrementa Prefix l KV Cache KV Cache Decode Full KV Cache CPU CPU KV Cache Store KV Cache Transfer Async Load and store Full KV Cache

23. 多级负载均衡 Motivation ⚫ ⚫ ⚫ ⚫ 不同请求处理负载差异大，RoundRobin无法感知Instance真实负载 RoundRobin不感知Instance KV Cache，导致匹配率降低 DP并行，DP单子batch负载差异大，导致整体时延变高 EP并行，热点专家负载高，导致整体时延变高 Service ETCD 负载均衡全局调度 Prefix Cache 全局调度 KV Cache 及负载上报 Solution ⚫ ⚫ ⚫ 全局调度器， Prefix Cache Aware的全局调度，提高匹配率 KV Cache Aware的全局调度，平衡Instance负载 PD分离场景，Prefill节点结合sequence length的调度 DPLB Instance内DP组间的“全局调度器”，均衡DP实例的负载 EPLB 热点专家冗余部署、专家重排（静态） Prefill Instance Decode Instance Local Scheduler Local Scheduler Chunked Prefill Scheduler Continous Batching DP LB Scheduler DP LB Scheduler EP LB Scheduler EP LB Scheduler KV Cache 及负载上报

24. 多层流水线Overlap Motivation ⚫ ⚫ ⚫ CPU调度和模型Forward串行执行，导致GPU/NPU利用率低单流交替执行计算、通信，计算/通信资源利用不充分计算和数据搬运串行，无法打满算力框架调度层模型图层算子层

25. 多层流水线Overlap Solution ⚫ ⚫ ⚫ CPU调度和NPU计算异步流水线：使用fake token提前执行iter i+1的CPU调度，NPU forward计算前进行真假token替换 NPU计算和通信异步流水线：采用两个micro batch和通信、计算双流执行，将batch 1的计算和batch 0的通信重叠 NPU Cube计算单元、Vector计算单元、访存流水并行框架调度层模型图层算子层

26. 多层流水线Overlap DeepSeek MTP投机推理的流水线并行 ⚫ ⚫ Motivation：DeepSeek推理使用MTP进行投机解码加速，可获得1.3-1.5倍的效率提升，在Draft/Target模型交互执行阶段，也存在因串行调度导致的bubble。 Solution：使用fake token提前准备iter+1的target model的Input，以及K步的draft model的Input构造，与当前iter的 forward Overlap起来。

27. 多层流水线Overlap PD分离通信与计算Overlap ⚫ ⚫ Motivation：Prefill Instance执行完毕，需要把KV Cache发送给Decode Instance，计算结束串行传输耗时长 Solution：使用LayerWise异步传输KV Cache，与当前Iter forward step Overlap，有效降低长sequence传输耗时，提升吞吐 Compute Stream： Layer 0 Compute Layer 1 Compute Layer 2 Compute Layer 0 KV Transfer Communication Stream： Compute Stream： Communication Stream： Layer 0 Compute Layer 1 Compute Layer 2 Compute Layer 0 KV Transfer Layer 1 KV Transfer Layer 2 KV Transfer Layer 1 KV Transfer Layer 2 KV Transfer

28. 业务落地效果可交互导购商品对比商品总结购物建议商品理解 TP99 下降 50%，资源节省～60%，支持业务场景效果UCVR 大模型吞吐提升 3X，助力模型推理成本节省～70%，多模态大模型提升 +5%，活跃用户占比提升 +2% 推理吞吐提升～20X，支持标签的实效性提升 10X 以上

29. 03 总结及展望

30. 总结及展望系统：分布式架构赋能，实现高性能、强扩展、高可用 ⚫ ⚫ 大模型推理本质也是分布式系统，架构日益复杂，可借鉴传统分布式系统的极致性能追求和成熟经验构建智能集群调度（AutoPD、Dynamic EP）、高效的Failover容错架构、KV Cache重算及迁移备份等能力模型：深入理解模型结构，挖掘硬件理论性能极限 ⚫ ⚫ 高效Fusion Kernel及并行，FlashAttention/FlashMLA/LargeEP等访存、通信与计算的Overlap，最大化硬件资源利用硬件：软硬深度协同，打开算力存储与通信天花板 ⚫ CloudMatrix384超节点通过全对等互联架构和光通信技术，实现了单集群如“一体机” CloudMatrix384 超节点UB全对等互联

31. 总结及展望生成式推荐与LLM技术同源，技术可赋能与协同设计适用场景 ⚫ ⚫ 类生成式推荐（Kuaishou OneRec、Meta GR）类生成式检索（Google TIGER）的推理加速 … 相似点 ⚫ ⚫ ⚫ 序列缓存：用户序列Embedding缓存 vs Prefix Cache 分离式架构：CPU & GPU解耦（FeatureServer & GPU serving）vs LLM场景EPD分离存储 & 计算解耦（分布式Embedding）vs KV Cache Pool 长序列建模：SIM GSU序列压缩 vs DeepSeek NSA序列压缩 … 挑战点 ⚫ ⚫ 大规模稀疏特征表达问题，亿级 vs 万级推荐场景流量大，完全的list-wise “自回归生成”资源消耗大，在Tokenizer/DeTokenizer、Vocabulary规模以及采样策略等方面持续探索效果和性能的balance

32. 联系我们热招岗位：大模型推理优化生成式推荐优化邮箱：yangpeijun1@jd.com

33. THANKS 探索 AI 应用边界 Explore the limits of AI applications