AWS SageMaker HyperPod 推出分离式预填充与解码（DPD）架构，优化长上下文 LLM 推理性能

一句话看懂

AWS 在 SageMaker HyperPod 上推出分离式预填充与解码（DPD）架构，通过 EFA RDMA 将预填充和解码分配到独立 GPU 池，消除长提示对并发解码的干扰，提升长上下文、高并发流式推理的稳定性。

详细发生了什么

LLM 推理包含两个本质不同的阶段：预填充（prefill）是计算密集型，并行处理整个输入提示生成初始 KV cache；解码（decode）是内存密集型，逐 token 生成并需要大量内存带宽。当两者共享同一 GPU 时，长提示会阻塞所有并发请求的解码，导致 token 延迟飙升。

AWS 在 SageMaker HyperPod 上利用 vLLM Production Stack 路由器和 LMCache 实现了分离式预填充与解码（DPD）。核心思路是将预填充和解码分配到独立的 GPU 池，通过 Elastic Fabric Adapter（EFA）和 RDMA 进行 KV cache 传输。路由器根据 token 阈值智能分流：长提示走预填充器→解码器路径，短提示直接发送到解码器，避免不必要的跨 GPU 传输。

预填充器使用 LMCache 的 PD 发送端逐层推送 KV cache，同时利用 CPU L1 缓存复用常见前缀（如系统提示、多轮历史），减少 GPU 重计算。解码器预留 GPU 内存（PD_BUFFER_SIZE）接收 KV cache，运行完整的 CUDA graphs，解码延迟在并发下保持稳定。KV 传输栈为 LMCache PD → NIXL → libfabric → EFA，在 ml.p5.48xlarge 实例上，8000 token 的 Llama 3.3 70B 传输仅需个位数毫秒。

部署需要 HyperPod Inference Operator v3.2+，支持 P5/P6 实例族（需同一可用区），并预集成 vLLM、LMCache、NIXL 和 EFA libfabric 的 worker 镜像。

中文圈视角

国内用户用得上吗？ 目前 DPD 是 AWS 托管服务，需要 AWS 账号和 HyperPod 集群，对国内用户存在一定门槛（需海外 AWS 区域、可能涉及数据出境）。但技术思路值得关注：分离式推理架构对长上下文、高并发场景（如智能客服、文档分析、RAG）效果显著，国内云厂商（阿里云 PAI、华为云 ModelArts、腾讯云 TI-ONE）可能跟进类似优化。

国产替代对比： 国内主流推理框架如 vLLM（开源）、TGI（Hugging Face）、SGLang 等均支持连续批处理和 PagedAttention，但原生分离式预填充/解码支持较少。DeepSeek 的推理优化（如 FlashAttention、MLA）侧重单卡效率，而 DPD 解决的是多节点编排问题。智谱的 GLM 系列在私有化部署中可能受益于类似架构，但尚未公开实现。

对中文用户的具体场景： 中文长文本（如法律合同、学术论文、小说生成）的推理延迟问题突出，DPD 能显著改善首 token 延迟（TTFT）和 token 间延迟（ITL）的稳定性。对于使用 OpenAI API 的国内开发者，DPD 是自建推理服务的优化方向，但需权衡 EFA 网络成本和运维复杂度。

监管/合规角度： 自建推理服务需满足《生成式人工智能服务管理暂行办法》，DPD 架构本身不涉及内容安全，但数据在预填充和解码节点间传输需确保加密和合规。

几条值得记住的细节

DPD 要求至少一个预填充节点和一个解码节点，实例需支持 EFA RDMA 读写（P5/P6 实例族），且位于同一可用区。
路由器通过可配置的 token 阈值决定请求路径：长提示走分离路径，短提示直接到解码器，避免不必要的 KV 传输开销。
预填充器利用 LMCache 的 CPU L1 缓存复用常见前缀（如系统提示、多轮历史），减少 GPU 重计算，显著降低 TTFT。
KV cache 传输使用四层栈（LMCache PD → NIXL → libfabric → EFA），在 ml.p5.48xlarge 上 8000 token 传输仅需个位数毫秒。
部署需要 HyperPod Inference Operator v3.2+，支持两种 worker 镜像：开源 LMCache 镜像（lmcache/vllm-openai v0.4.3）和 SageMaker DLC。

一句话总结

如果你在 AWS 上部署长上下文、高并发的 LLM 推理服务，DPD 能显著提升解码稳定性，但国内用户需关注网络门槛和国产替代方案。