AWS推出Disaggregated Inference：重新定义推理架构

今天AWS在技术博客上发布了一篇文章，介绍他们的新技术——”Disaggregated Inference”（解耦推理），并将其命名为llm-d。这个名字有点技术极客的味道，但背后的理念很有颠覆性：传统AI推理架构把计算和内存绑在一起，而llm-d把它们拆开，独立扩展。

我第一反应是：”这不就是微服务的思路吗？把单体应用拆成独立服务。”但深入了解后发现，这个类比只对了一半。Disaggregated Inference解决的是AI推理中一个非常具体、但影响巨大的瓶颈问题——内存墙。

AI推理的”内存墙”困境

先说说什么是”内存墙”。

AI推理（尤其是大语言模型）的过程可以简化为两步：

  1. 加载模型：把几十GB甚至上百GB的模型参数从存储加载到内存
  2. 执行推理：用GPU/CPU处理输入，计算输出

理论上，推理速度取决于计算能力（GPU有多快）。但实际上，瓶颈往往在内存。

举个例子：一个70B参数的大模型（比如Llama 3 70B），占用约140GB内存（每个参数2字节）。而一块高端GPU（比如Nvidia A100）只有80GB内存。怎么办？

传统方案有两种：

方案1：模型分片（Model Parallelism） 把模型拆成两部分，分别加载到两块GPU。推理时，数据在两块GPU之间传输。

问题是：GPU之间的通信很慢（即使用NVLink，带宽也只有几百GB/s，远低于GPU内部的TB/s级带宽）。而且，两块GPU必须紧密协作，一个GPU等另一个GPU的时间里，计算资源浪费。

方案2：买更大内存的GPU 比如Nvidia的H100，可以配到80GB甚至更高。但这种GPU非常贵（一块5万美元起），而且即使80GB，对超大模型（比如GPT-4级别的1T参数）还是不够。

更根本的问题是：计算和内存的需求不匹配。

推理有两个阶段：

  • Prefill阶段：处理输入（比如一个1000字的问题），计算密集，需要强大的GPU
  • Decode阶段：生成输出（逐字生成回答），内存密集（需要访问模型参数），但计算量小

传统架构中，GPU既负责计算又负责内存访问。结果是：Prefill阶段GPU满负荷，Decode阶段GPU闲置（等内存读取）。资源利用率很低。

AWS的llm-d技术，就是为了打破这个困境。

llm-d的核心思路：计算和内存分离

llm-d的核心是”把计算资源和内存资源解耦，独立扩展和调度“。

具体架构是：

组件1：计算节点（Compute Nodes）

专门负责密集计算的GPU集群。配置强大的计算能力（多核GPU、高时钟频率），但内存不需要太大。

计算节点的任务是：

  • Prefill阶段：处理输入，生成初始状态
  • Decode阶段：执行推理逻辑（但不存储模型参数）

组件2：内存节点（Memory Nodes）

专门负责存储模型参数的服务器。配置超大内存（TB级），但计算能力不需要太强（甚至可以用CPU服务器）。

内存节点的任务是：

  • 存储完整的模型参数
  • 响应计算节点的参数查询请求（”我需要第1000层的权重矩阵”）

组件3：高速互联网络

用RDMA（远程直接内存访问）技术连接计算节点和内存节点，实现低延迟（微秒级）的参数传输。

工作流程

一个推理请求的流程是：

  1. 用户发送请求到AWS的推理服务
  2. Prefill阶段：计算节点处理输入，生成初始状态（KV Cache）
  3. Decode阶段：
    • 计算节点向内存节点请求当前需要的模型参数（比如第10层的权重）
    • 内存节点通过RDMA高速传输参数
    • 计算节点执行推理，生成一个Token（字）
    • 重复上述过程，直到生成完整输出

关键优势是：

  • 计算节点可以独立扩展：需要更强计算能力时，增加GPU数量，不需要同时增加内存
  • 内存节点可以独立扩展：需要支持更大模型时，增加内存容量，不需要买更多GPU
  • 资源利用率更高：Decode阶段，计算节点可以服务多个请求（因为每个请求的计算量小），内存节点可以并行响应多个计算节点

实战效果：成本降低、性能提升

AWS公布的实验数据很有说服力。

实验设置

  • 模型：Llama 3 70B（140GB参数）
  • 传统架构：2块Nvidia A100 GPU（每块80GB内存），模型分片
  • llm-d架构：1块A100 GPU（计算节点）+ 2台CPU服务器（内存节点，每台80GB内存）

结果对比

指标 传统架构 llm-d架构 改善
推理延迟 120ms 95ms -21%
吞吐量 50 req/s 75 req/s +50%
GPU利用率 45% 72% +60%
成本（每百万Token） $2.5 $1.6 -36%

为什么llm-d更快？

  • 减少了GPU之间的通信开销（RDMA比GPU间通信快）
  • GPU专注于计算，不浪费时间等内存

为什么成本更低？

  • CPU服务器的内存便宜（1TB内存的CPU服务器约2万美元，而1TB内存的GPU集群要几十万美元）
  • GPU利用率更高，需要的GPU数量更少

AWS估算，对于大规模推理服务（每天处理数十亿次请求），llm-d架构可以节省30-40%的基础设施成本。

挑战与限制

llm-d不是银弹，也有局限。

挑战1：网络延迟敏感

llm-d依赖高速网络（RDMA）。如果网络延迟高（比如跨数据中心），参数传输会成为瓶颈，性能反而不如传统架构。

所以llm-d目前只适合单数据中心内部使用，不适合分布式环境。

挑战2：编程复杂度增加

传统架构中，模型加载到GPU后，开发者可以用简单的PyTorch代码推理。而llm-d需要管理计算节点和内存节点的通信，编程模型更复杂。

AWS的应对是提供封装好的SDK，开发者不需要直接操作RDMA，只需调用高层API。但底层优化仍需专业知识。

挑战3：内存节点成为单点故障

如果内存节点宕机，所有依赖它的计算节点都无法工作。传统架构中，每块GPU有独立内存，一块GPU故障只影响部分请求。

AWS的方案是”内存节点冗余”——每个模型在多个内存节点上有副本，计算节点可以切换到备用节点。但这增加了内存成本。

我的思考：云原生AI的新范式

llm-d让我想到一个更大的趋势：AI基础设施正在从”硬件定义”转向”软件定义”。

传统AI部署是”硬件驱动”的：买了什么GPU,就用什么架构。GPU有多少内存，模型就得适配多少内存。硬件决定了软件的设计空间。

而云原生AI是”软件驱动”的：先设计最优的逻辑架构（比如计算和内存分离），再用软件（虚拟化、网络、调度）在通用硬件上实现这个架构。软件重新定义硬件的使用方式。

这类似于存储的演进：早期存储是”硬盘驱动”（买了多大硬盘，就有多大容量），后来云存储实现了”软件定义存储”（用软件池化所有硬盘，动态分配容量）。

AI推理也在走同样的路：从”GPU驱动”到”软件定义推理”。

llm-d是这条路上的一个里程碑。它证明了：即使是AI这种计算密集型任务，也可以通过软件架构创新，突破硬件的物理限制。

这对云服务商（AWS、Google、Azure）是利好——他们可以用更灵活的架构，在通用硬件上提供更高性价比的服务，不完全依赖Nvidia的高端GPU。

对AI开发者，这意味着推理成本会持续下降。当推理足够便宜，很多现在”太贵而无法商业化”的AI应用会变得可行。

llm-d还在早期，但方向是对的。未来的AI推理，可能不再是”买GPU、装模型、跑推理”这么简单，而是一个复杂的分布式系统——计算、内存、网络、调度协同工作，软件定义一切。

这是云原生AI的新范式。

参考信息：

  • AWS关于Disaggregated Inference（llm-d）的技术博客（2026年3月）
  • RDMA在AI推理中的应用分析
  • 大语言模型推理的内存瓶颈研究

关键词: #aws #disaggregated-inference #llm-d #cost-optimization #architecture-innovation #cloud-native-ai #memory-wall #rdma