# 分离式推理架构实战：在AWS EKS上部署llm-d实现70%吞吐量提升 > 这个开源项目展示了如何在Amazon EKS上部署llm-d分离式推理框架，通过将预填充和解码阶段分离到不同Pod，并借助EFA RDMA实现毫秒级KV缓存传输，将LLM推理吞吐量提升高达70%。 - 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm) - 发布时间: 2026-04-22T08:18:00.000Z - 最近活动: 2026-04-22T08:25:17.827Z - 热度: 159.9 - 关键词: 分离式推理, LLM推理优化, llm-d, Kubernetes, EFA RDMA, KV缓存, 预填充解码分离, AWS EKS - 页面链接: https://www.zingnex.cn/forum/thread/aws-eksllm-d70 - Canonical: https://www.zingnex.cn/forum/thread/aws-eksllm-d70 - Markdown 来源: ingested_event --- # 分离式推理架构实战：在AWS EKS上部署llm-d实现70%吞吐量提升 大语言模型的推理服务是当前AI基础设施中最核心的挑战之一。随着模型规模不断增大，如何在保证延迟的同时最大化吞吐量，成为每个AI团队必须面对的问题。今天介绍的这个开源项目，提供了一种前沿的解决方案——通过预填充/解码分离（P/D Disaggregation）架构，在AWS环境下实现了显著的推理性能提升。 ## 什么是分离式推理 要理解分离式推理的价值，首先需要了解LLM推理的两个核心阶段。 **预填充阶段（Prefill）**是计算密集型的。当用户发送一个请求时，模型需要一次性处理整个输入提示词，为每个token计算注意力权重并生成KV缓存。这个过程需要大量的矩阵运算，对GPU的计算能力要求很高。 **解码阶段（Decode）**则是内存带宽密集型的。模型逐个生成输出token，每次只需要计算一个新token与所有历史token之间的注意力。这个过程的瓶颈不在计算，而在于需要频繁读取庞大的KV缓存数据。 传统的推理部署将这两个阶段放在同一个GPU上执行，但它们对硬件的需求截然不同。这就像让一个运动员同时参加举重和马拉松——虽然都能完成，但效率远非最优。分离式推理的核心思想就是将这两个阶段分配到不同的硬件节点上，让每种节点专注于自己擅长的工作。 ## llm-d框架简介 llm-d是一个开源的Kubernetes原生框架，专为分布式LLM推理服务设计。它的核心设计理念是将推理过程解耦为独立的微服务，每个服务可以独立扩缩容，从而实现更精细的资源管理。 在这个项目的参考架构中，llm-d部署了两个预填充Pod和一个解码Pod。预填充Pod使用张量并行度4（TP=4），专注于处理输入提示词。解码Pod同样使用TP=4，专注于token生成。两者之间通过高速网络传输KV缓存数据。 这种架构的优势在于灵活性。在实际生产环境中，预填充和解码的负载比例会随着请求特征变化。长提示词、短回复的场景需要更多预填充资源；而短提示词、长回复的场景则需要更多解码资源。分离式架构允许运维团队根据实际流量模式独立调整各阶段的资源配置。 ## EFA RDMA：毫秒级KV缓存传输的秘密 分离式推理面临的最大技术挑战是KV缓存的跨节点传输。对于一个大型模型，KV缓存可能达到数百MB甚至数GB。如果使用传统的TCP网络传输，延迟会严重影响整体推理速度，完全抵消分离带来的好处。 这个项目的解决方案是利用AWS的Elastic Fabric Adapter（EFA）提供RDMA（远程直接内存访问）能力。RDMA允许GPU直接将数据写入远程节点的内存，绕过操作系统内核和TCP/IP协议栈，从而实现极低延迟的数据传输。 在具体实现上，项目使用了NIXL库配合libfabric协议，通过EFA接口实现KV缓存的高速传输。实测数据显示，KV缓存的传输延迟约为2毫秒，传输吞吐量超过1GB/s。这个性能水平使得分离式架构的额外通信开销几乎可以忽略不计。 项目使用的p5.48xlarge实例配备了32个EFA接口（efa-only模式），这些接口被配置在集群放置组（Cluster Placement Group）中，确保物理上的紧邻部署，进一步降低网络延迟。 ## 完整的基础设施架构 项目提供了一套完整的Terraform配置，可以一键部署整个推理基础设施。核心组件包括： **网络层**：一个跨4个可用区的VPC，配备NAT网关为私有GPU节点提供网络访问。EFA专用安全组配置了自引用的入站和出站规则，确保RDMA流量的正常通信。 **计算层**：系统节点使用m5.2xlarge实例运行Istio网关、监控组件和EPP路由器。GPU节点使用p5.48xlarge实例，每个节点配备8块H100 GPU和32个EFA接口。自定义启动模板配置了500GB gp3存储卷。 **服务网格**：Istio作为服务网格，处理流量路由和负载均衡。Gateway API配合Inference Extension CRDs实现了推理感知的流量管理。 **智能路由**：EPP（Endpoint Picker）组件实现了缓存感知的请求路由。它能够识别哪些解码Pod已经持有特定请求的KV缓存，将后续请求路由到这些Pod上，最大化缓存复用率。 **可观测性**：Prometheus和Grafana提供了完整的vLLM指标监控能力，帮助运维团队实时了解推理服务的健康状况和性能表现。 ## 性能表现 根据项目文档和AWS博客的数据，分离式推理架构在高并发场景下表现尤为出色。在128个并发请求的测试中，与标准vLLM部署相比，吞吐量提升了约70%。 这种提升的来源是多方面的。首先，预填充和解码阶段的计算资源不再相互干扰。在标准部署中，一个长预填充请求可能会阻塞同一GPU上其他请求的解码过程。分离后，两个阶段完全独立运行，消除了这种干扰。 其次，EPP的缓存感知路由减少了不必要的KV缓存重新计算。当多个请求共享相同的系统提示词时，EPP可以将它们路由到同一个解码Pod，复用已有的KV缓存。 实际部署日志显示，预填充Pod的生成吞吐量接近于零（约0.1 tokens/s），说明它完全专注于提示词处理。而解码Pod则专注于token生成，两者的分工非常清晰。 ## 部署流程与实践要点 项目的部署流程设计得相当规范。整体分为三个阶段：首先通过Terraform创建EKS集群和基础设施（约需20-25分钟），然后配置HuggingFace访问令牌和命名空间，最后通过Helmfile部署llm-d组件。 值得注意的是几个关键的部署细节。EFA接口必须配置为efa-only模式而非普通efa模式，这是p5.48xlarge实例的特殊要求。集群放置组确保GPU节点物理上紧邻部署，这对RDMA延迟至关重要。安全组需要配置自引用规则以允许节点间的RDMA通信。 ## 适用场景与局限 分离式推理架构特别适合以下场景：高并发的在线推理服务、输入提示词长度变化较大的应用、需要精细化资源管理的生产环境，以及对吞吐量有极高要求的批量推理任务。 但这种架构也并非没有代价。它增加了系统的复杂性，需要额外的网络基础设施（EFA），并且对运维团队的Kubernetes经验有较高要求。对于低并发或请求模式简单的场景，标准的推理部署可能更为经济实用。 ## 结语 分离式推理代表了LLM推理优化的一个重要方向。通过将计算密集型和内存密集型的工作负载分开处理，配合高速互联技术消除通信瓶颈，这种架构为大规模推理服务提供了显著的性能提升。这个开源项目提供了完整的参考实现和详细的部署文档，对于正在构建或优化LLM推理基础设施的团队来说，是一份极有价值的实践参考。