摘要

随着大语言模型（LLM）在MaaS（Model as a Service）场景下的广泛应用，服务端面临着极其复杂的流量特征：极端的变长输入、突发的并发请求以及严格的延迟SLA（TTFT与TPOT）。传统的整体式推理架构在处理这些挑战时，往往受限于显存碎片化和计算/访存特性的冲突，难以兼顾高吞吐与低时延。本文探讨了一种基于Prefill/Decode（PD）分离的解耦式Serving架构，重点分析了如何利用PD分离部署结合智能路由、全局KVCache管理及专家并行（EP）等关键技术，解决大规模部署中的资源瓶颈，提出了一套能够最大化GPU利用率并有效应对高并发的系统级解决方案。

关键词

大规模推理部署；高并发；Serving架构；PD分离；KV Cache优化

引言

大模型推理的本质是由两个截然不同的阶段组成的：Prefill（预填充）阶段和Decode（解码）阶段。

◆Prefill阶段：处理输入的Prompt，是一次性的计算密集型（Compute-bound）任务，对算力要求极高，注重吞吐。

◆Decode阶段：逐Token生成回复，是内存带宽密集型（Memory-bound）任务，受限于显存带宽，注重时延。

图1 大模型推理过程的两个阶段

在传统的Continuous Batching（连续批处理）架构中，Prefill和Decode任务混合运行在同一张GPU上。当并发量激增且请求长度差异巨大时，Prefill任务会显著抢占计算资源，导致正在Decode的请求出现明显的卡顿（Inter-token latency增加）。同时，KV Cache的显存占用随着并发数线性增长，极易触发OOM（Outof Memory），限制了系统的最大并发数。

为了解决上述MaaS场景下的核心痛点，PD分离（Prefill-DecodeDisaggregation）架构应运而生。本文将阐述该架构的设计原理及其在DeepSeekV3等大规模MoE模型部署中的深度优化实践。

1 Prefill/Decode分离架构原理与核心优势

1.1 解耦设计的理论基础

PD分离的核心思想是将推理集群划分为两类独立的实例池：

1）Prefill实例池：专门负责Prompt处理，计算出KV Cache。该池通常配置高算力利用率的调度策略。

2）Decode实例池：专门负责Token生成。该池通过接收Prefill阶段生成的KVCache，专注于低延迟的Token输出。

1.2 架构协同流程

在一个典型的优化后架构中，处理流程如下：

1）请求接入：流量经过网关进入全局调度器（Global Scheduler）。

2）Prefill计算：调度器将请求分发至Prefill节点，节点快速并行计算，生成KV Cache。

3）KV传输：通过高速互联网络（如RDMA、NVLink）将KVCache从Prefill节点传输至选定的Decode节点。

4）Decode生成：Decode节点加载KVCache，开始自回归生成，直至结束。

图2 PD分离架构下请求处理过程

这种分离彻底消除了Prefill计算对Decode生成的干扰，使得我们可以针对两个阶段不同的硬件特性（计算密集 vs 访存密集）进行异构硬件选型或独立的参数调优。

2 Serving架构的深度优化：迈向极致性能

仅实现物理上的分离不足以应对大规模高并发，必须引入系统级的深度优化。我们重点探讨以下关键技术。

2.1 智能路由与全局调度 (Smart Routing)

在MaaS场景下，请求并非无状态。为了提高缓存命中率，调度器必须具备“记忆”能力。

◆KV Cache-Aware Routing（KV Cache感知路由）：调度器维护全局的KVCache分布表。当一个新的请求包含常见的前缀（如System Prompt或多轮对话的历史记录）时，智能路由会将该请求分发到已经存有该前缀KV Cache的节点上。

◆负载感知均衡策略：调度器需实时预测各节点的显存水位和计算负载，在“缓存亲和性”与“负载均衡”之间寻找最优解，避免热点节点过载。

图3 缓存、负载感知调度流程示意

2.2 极致的KV Cache管理：前缀缓存与卸载

KV Cache是推理过程中最大的显存开销，也是PD分离中传输的瓶颈。

◆前缀缓存（Prefix Caching / Radix Attention）：

利用基数树（Radix Tree）结构管理KV Cache。对于多轮对话或RAG（检索增强生成）场景，大量Prompt具有公共前缀。系统通过Radix Attention机制，自动匹配并复用显存中已有的KV块，通过减少重复计算（Re-computation）大幅降低TTFT（首字延迟）。

◆KV Cache 卸载（Offloading）：

当高并发导致GPU显存不足时，传统的做法是驱逐（Evict）缓存。优化后的架构引入多级存储层次：GPU HBM→Host RAM→SSD。利用PCIe带宽，将暂时不活跃的KVCache卸载到CPU内存，需要时再快速预取（Prefetch）。这使得单卡支持的并发容量提升了数倍。

图4 多级KV Cache缓存卸载示意

2.3 高效通信与流水线掩盖

PD分离引入了额外的KV传输开销。为了掩盖这一延迟，系统设计必须做到通信与计算的重叠（Overlap）。

◆分层分块传输：在Prefill计算过程中，不等待全部层计算完毕，而是采用流水线方式，计算完一层（Layer）即传输一层，使得Decode节点可以尽早开始加载数据。

◆传输协议优化：基于RDMA技术优化传输协议，绕过CPU直接在GPU显存间传输数据，减少系统调用开销。

3 应对超大模型：大EP专家并行与MoE优化

对于如DeepSeek-V3/R1这类采用混合专家（MoE）架构的超大模型，参数量巨大（如671B），单卡无法容纳，且计算模式更为稀疏。

3.1 大EP（Expert Parallelism）专家并行

在混合专家（MoE）架构中，每个Token只激活少部分专家。为了解决通信瓶颈，架构采用了大规模专家并行：

◆专家分布：将不同的专家网络分布在不同的GPU甚至不同的节点上，针对SharedExperts（共享专家）进行特殊处理，确保这些高频访问的参数常驻高速缓存。

◆All-to-All通信优化：在推理过程中，Token需要被路由到特定的专家所在的GPU进行计算，计算后再汇聚。这产生的大量All-to-All通信，通过优化算子和网络拓扑感知（Topology-aware）路由进行加速，确保高并发下的通信不阻塞计算。

3.2 专家间负载均衡 (EPLB)

在混合专家（MoE）架构的推理中，大规模并发下，会导致显著的负载不均衡。例如，在处理大量编程类请求时，负责“代码生成”的专家所在的 GPU 会成为计算热点，而其他处理通用文本的 GPU 则处于空闲状态。这会导致整个 Batch 的推理延迟取决于最慢的那个 GPU，严重拖累 TPOT（Token Per Output Token）。

为了解决这一问题，系统引入了EPLB（Expert Parallelism Load Balancing） 机制，从系统层面动态抹平计算负载：

1）基于预测的动态冗余（PredictiveDynamic Redundancy）：

传统的 EP 策略通常是静态分配专家。EPLB 机制引入了“热点漂移”监测。Serving系统会实时统计滑动窗口内的专家激活热度图（Heatmap）。当识别到特定专家（Hot Expert）的访问频率持续超过阈值时，系统会利用闲置的显存资源，在低负载的GPU节点上动态复制该专家的权重副本。调度器随后将部分Token路由至副本节点，通过多路冗余计算消除单点瓶颈。

2）通信感知的全局规约优化：

在专家并行中，Token的Dispatch（分发）和 Combine（汇聚）涉及海量的All-to-All通信。EPLB不仅均衡计算，还均衡通信量。通过感知网络拓扑，EPLB 算法会尽量将激活相同专家的Token打包，或者优先调度位于同一 NVLink 域内的专家请求，减少跨节点的 RDMA 通信开销，确保计算密集型与通信密集型任务在时间轴上的完美交错（Overlap）。

4 动态自适应资源调度

现代Serving架构不仅是静态的执行引擎，更是动态的调节系统。

◆动态配额调整：系统根据实时流量监控和实例上报的Metric指标动态伸缩实例个数。同时，在没有额外资源时，实现PD实例角色转换，闲置P实例可转为D实例（反之亦然），智能调整PD配比，实现资源复用。

图5 PD实例动态伸缩与转换示意

5 结束语

面对MaaS场景下的大规模AI推理挑战，单一的技术手段已无法满足需求。通过Prefill/Decode分离架构的落地，配合智能路由、前缀缓存（Radix Attention）、KV Cache卸载以及针对MoE模型的大EP并行策略和EPLB专家负载均衡策略，可以构建一套高吞吐、低时延的现代化Serving系统。这种系统级优化方案，可成功将GPU利用率提升至新的高度，解决了高并发下的资源争抢问题，为万亿参数时代的实时AI应用提供了坚实的算力底座。