分离式推理架构解析：在NVIDIA GPU上实现低延迟大模型推理

最近在研究大模型推理性能时，经常绕不开两个词：“LPU”和“分离式推理”。这两个词在网上经常混在一起，搜索量大，但靠谱的架构解析不多。本文将围绕“NVIDIA 体系下实现低延迟大模型推理”这一场景，梳理三种主流的分离式推理架构，从概念、原理、适用场景到工程踩坑，给出系统性的解析。

不过动手之前，有必要先厘清一个概念：严格意义上，NVIDIA 的公开产品线里并没有叫“LPU”的芯片。LPU 通常指 Groq 推出的 Language Processing Unit（语言处理单元），它主打 SRAM 存储和顺序 token 生成，走的是专用 ASIC 路线。而 NVIDIA 生态强调的是通用 GPU + CUDA/TensorRT 软件栈。真正想把推理延迟压低、吞吐拉高，不能靠“换个芯片名称”，要靠系统工程设计。在 NVIDIA GPU 上把 Prefill 阶段和 Decode 阶段拆开部署，就是目前业界收益最明显的优化方向之一。

这篇文章适合正在做 LLM 推理服务、离线压测或架构选型的技术同学阅读。读完你会理解：什么是 Prefill/Decode 分离，KV Cache 在分离架构中扮演什么角色，三种常见的分离式推理架构分别适合什么场景，以及实际落地时最容易踩的坑。

1. 背景与核心概念：LPU 与分离式推理是什么

1.1 先厘清概念：为什么没有“NVIDIA LPU”

先说结论：NVIDIA 官方没有 LPU 产品。如果你去搜索“NVIDIA LPU”，大概率会搜到两类内容：一类是 Groq LPU 的新闻，另一类是“NVIDIA 驱动怎么装”这类工程师常见问题。为什么会出现这种混淆？因为很多人搜词时，并不是精确地想要某一款芯片，而是想找“让大模型推理更快”的解决方案。Groq LPU 的宣传点“推理速度快”，自然会被拿来和 NVIDIA GPU 比较。

从技术路线上看，两者差异很大：

• Groq LPU 是专用处理器，思路是用大量片上 SRAM 替代传统 HBM 显存，让数据搬运更可控，非常适合做自回归式逐 token 生成。
• NVIDIA GPU 是通用并行计算平台，显存大、生态完整，能够覆盖训练、微调、推理等全流程；推理时还要配合 CUDA、TensorRT-LLM、Triton Inference Server 等软件。

也就是说，NVIDIA 不会靠一颗“LPU 芯片”去追平专用芯片的延迟，而是在通用 GPU 之上通过虚拟化、调度、异步执行和合理的架构拆分来逼近低延迟目标。

1.2 分离式推理指什么

分离式推理，英文常称为 Disaggregated Inference。它要拆分的主体是 LLM 推理的两个阶段：

1. Prefill（预填充）阶段：把用户输入的 Prompt 一次性交给模型做并行计算，生成对应的 Key/Value 缓存，通常计算密集。
2. Decode（解码）阶段：模型逐个生成 token，每个 token 生成都依赖前面已有的 KV Cache，通常访存密集。

传统单体推理服务里，一个 GPU 上可能同时做 Prefill 和 Decode。出现请求时，引擎先做 Prefill，再进入 Decode，直到生成结束。这样做实现简单，但资源冲突明显：短 Prompt、长输出和大并发场景互相干扰，一个慢请求可能拖慢整卡服务。

分离式推理的思路很简单：把 Prefill 和 Decode 分配到不同的计算资源上，分别调优、分别扩缩容。请求来了先到 Prefill 引擎处理输入，再把中间状态交给 Decode 引擎继续生成。这样既能保证首 token 延迟，也能提升整体吞吐。

1.3 分离式推理要解决什么问题

拆分不是为了炫技，而是为了解决实际矛盾。

• TTFT 与吞吐矛盾：TTFT（Time To First Token，首 token 延迟）和整体吞吐是两个独立指标。Preffill 对 TTFT 影响大，Decode 对吞吐影响大，单体推理引擎很难同时调优二者。
• GPU 利用率失衡：Prefill 阶段计算密集，显存占用是短时的；Decode 阶段虽然计算少，但 KV Cache 持续占用显存。两者混跑时，总有一类任务在“抢资源”。
• 长上下文与显存压力：KV Cache 大小随序列长度线性增长，Decoder 的显存行情直接影响能并发的请求数。如果前后阶段共用一块显存，一次长上下文请求就可能打满空间。

因此，分离式推理本质上是用“资源专业化”换“延迟和吞吐的可控性”。

2. 环境准备：在 NVIDIA GPU 上做分离式推理的前置条件

分离式推理属于系统架构层面的事情，不是某个单一框架的功能开关。动手前，建议先确认底层 GPU 环境和推理框架版本。

2.1 检查 NVIDIA 驱动与 GPU 状态

很多读者在实际服务器上做推理时，第一步就卡在“GPU 驱动无法识别”上。比较常见的报错是：

nvidia-smi has failed because it couldn't communicate with the NVIDIA driver

这个错误通常意味着内核模块没有加载，或者驱动和内核版本不匹配。建议按顺序检查：

# 1. 检查系统能否识别 NVIDIA 设备 lspci | grep -i nvidia # 2. 检查驱动状态 nvidia-smi # 3. 检查内核模块是否加载 lsmod | grep nvidia # 4. 查看最近的内核日志 dmesg | grep -i nvidia | tail -n 20

如果nvidia-smi能正常输出 GPU 型号、驱动版本、显存使用率，说明驱动层面没有问题。如果输不出来，要优先排查驱动安装方式，比如是在物理机上安装，还是在容器里挂载的 NVIDIA Container Toolkit。不要一上来就盲目卸载驱动重装，容易引入二次问题。

驱动版本选择遵循一个原则：不是越新越好，而是要和 CUDA 版本、推理框架版本匹配。生产环境建议锁定一套经过验证的驱动版本，并在测试环境提前验证后再推广应用。

2.2 推理框架与项目结构

分离式推理架构可以基于不同框架实现。目前比较主流的开源选择有：

• vLLM：使用 PagedAttention 管理 KV Cache，吞吐表现好，社区生态活跃。
• SGLang：强调 RadixAttention，对多轮对话和历史前缀复用友好。
• NVIDIA TensorRT-LLM：适合用 NVIDIA GPU 做深度优化，支持模型编译和 CUDA Graph。
• NVIDIA Triton Inference Server：适合做模型服务化编排。

不同框架对 Prefill/Decode 分离的支持程度不同，有的需要写额外调度组件，有的已经内置相关配置项。版本变化较快，具体参数名要以你使用的框架文档为准，不要照抄网上任意一段旧命令。

2.3 网络和集群条件

分离式推理涉及 GPU 之间传输数据。当 Prefill 和 Decode 位于同一台服务器时，走 NVLink 或 PCIe 即可；一旦跨节点，就需要考虑网络互联方案：

• InfiniBand：延迟低、带宽高，适合跨节点 KV Cache 传输。
• RoCE（RDMA over Converged Ethernet）：在普通以太网上实现 RDMA，部署成本相对可控。
• 普通 TCP/IP：可用，但传输延迟高，跨节点分离收益会被明显稀释。

因此，如果只是单机测试，可以先用“同节点卡组分离”思路验证；如果要支撑大规模在线服务，再考虑跨节点方案。

3. 需要先理解的两个关键点：Prefill/Decode 与 KV Cache

进入三种架构前，先补充两个核心概念。不理解它们，后面看架构会发现“每个字都认识，但串不起来”。

3.1 Prefill 和 Decode 的计算特征差异

Prefill 阶段会并行处理整个输入序列，计算吞吐高，显存申请是“突发式”的。传统 Transformer 首轮推理时，会把用户完整 Prompt 一次算完。此时 GPU 利用率较高，但如果输入长度短、请求数量少，Prefill 的时间其实很短。

Decode 阶段则是逐 token 生成，每生成一个 token 就要读取一遍之前的 KV Cache。真正消耗时间的是“从显存中把历史信息取回来”，而不是矩阵乘法本身。这也是为什么 Decode 阶段对显存带宽要求高，而不是对纯算力要求高。

如果将两个阶段绑定在同一张卡上，Prefill 可能会阻塞正在等待 token 的 Decode 请求；反过来，大量 Decode 请求又会占满 KV Cache，导致新来的 Prefill 请求无法分配显存。

3.2 KV Cache 是分离架构的“衔接件”

KV Cache 是模型在前向计算时，为每个 token 保留的 Key 和 Value 向量。自回归生成时，新 token 只需要和 KV Cache 中的内容做注意力计算，不必重新计算历史 token。

在分离式推理里，Prefill 引擎处理完 Prompt 后，会产出一份 KV Cache；Decode 引擎必须拿到这份数据才能继续生成。所以KV Cache 的生成、传递、存储方式，直接决定分离式架构的性能。

单实例场景下，KV Cache 住在显存里就好，访问很快。多实例/跨节点场景下，KV Cache 需要从 Prefill 节点“搬”到 Decode 节点。这一步的传输速度如果慢，整体收益会被抵消。

3.3 怎么理解“三种分离式推理架构”

“分离”这个词在不同层级理解不同。本文按工程落地粒度，把常见方案分为三类：

1. 单节点内卡组分离：把一台服务器内的 GPU 划分成 Prefill 卡组和 Decode 卡组。
2. 跨节点池分离：把集群中多台节点分别组成 Prefill 池和 Decode 池。
3. 以 KV Cache 为中心的缓存与计算分离：把 KV Cache 单独做一层分布式存储，所有计算节点按需读写。

下面逐个展开。

4. 三种分离式推理架构详解

4.1 架构一：单节点内卡组分离（Intra-node PD Disaggregation）

4.1.1 核心思路

同一台 GPU 服务器内，把不同显卡分配给不同角色。例如一台 8 卡 GPU 服务器，可以将前 4 张卡配置为 Prefill Engine，后 4 张卡拆成两个 2 卡 Decode Engine。请求进入后，由调度层决定先调用 Prefill Engine，再调用 Decode Engine。

这个方案的分离粒度在“卡”，核心优势是数据通路短。同节点内 GPU 之间通过 NVLink 或 PCIe 通信，KV Cache 不需要跨机器搬运，实现难度相对低。

架构示意如下：

单台 8 卡 GPU 服务器 ┌─────────────────────────────────────────────┐ │ GPU0 ~ GPU3 GPU4 ~ GPU5 │ │ Prefill Engine Decode Engine 1 │ │ (并行处理 Prompt) (逐token生成) │ │ │ │ GPU6 ~ GPU7 │ │ Decode Engine 2 │ └─────────────────────────────────────────────┘ │ ▲ │ KV Cache / 中间状态 │ ▼ │ 请求入口 ──调度层──→ 返回结果

4.1.2 示例：按显卡序号划分不同角色

下面是一个“职责划分”的示意图，用CUDA_VISIBLE_DEVICES控制进程可见的 GPU。实际项目中启动命令和框架参数会更多，这里只体现卡组分离思路：

# 在一台 8 卡机器上启动一个 Prefill Worker，占用 GPU 0-3 export CUDA_VISIBLE_DEVICES=0,1,2,3 python launch_worker.py --role=prefill --port=8001 & # 在 GPU 4-5 上启动一个 Decode Worker export CUDA_VISIBLE_DEVICES=4,5 python launch_worker.py --role=decode --port=8002 & # 在 GPU 6-7 上启动另一个 Decode Worker export CUDA_VISIBLE_DEVICES=6,7 python launch_worker.py --role=decode --port=8003 &

说明：launch_worker.py是占位脚本，不代表某个框架的真实入口。核心逻辑是给不同 Worker 分配不同显卡资源。如果使用 vLLM 这类框架，需要再查对应版本的“Disaggregated Prefill”相关参数，不同版本之间差异较大。

4.1.3 适用场景与优缺点

这种架构适合单机资源充足、服务规模还不大的场景。比如企业内部先做 PoC，或者某个模型只部署在少量 GPU 服务器上，但希望避免 Prefill 和 Decode 互相干扰。

优点：

• 部署简单，不需要跨节点网络调度。
• 延迟低，KV Cache 传输几乎不经过网络。
• 运维成本低，所有资源都在一台物理机内。

缺点：

• 单台服务器 GPU 数量有限，扩展性受限制。
• 卡组比例固定后，如果流量特征变化，比如长 Prompt 请求变多，需要重新划分显卡比例，灵活性不高。

4.2 架构二：跨节点池分离（Inter-node PD Disaggregation）

4.2.1 核心思路

当单机容量不足以支撑业务时，可以把 Prefill 和 Decode 放到不同节点上，形成两个独立节点池。外部请求先进入 Prefill 节点池，处理完毕后，通过高速网络把 KV Cache 传给 Decode 节点池，Decode 节点生成文本并返回。

这个模式的分离粒度在“节点”，也常被称为 Pod/Node 级别的 PD 分离。它的核心好处是两类节点可以独立扩缩容。例如业务输入特别长，那就扩容 Prefill 池；如果用户对话轮次多，输出文本长，就扩容 Decode 池。

4.2.2 集群调度示例：Kubernetes 节点池划分

在 Kubernetes 环境里，可以通过 Node Label 区分 Prefill 节点和 Decode 节点。先给节点打标签：

# 将节点标记为 Prefill 池 kubectl label node gpu-node-prefill-01 gpu.example.com/role=prefill kubectl label node gpu-node-prefill-02 gpu.example.com/role=prefill # 将节点标记为 Decode 池 kubectl label node gpu-node-decode-01 gpu.example.com/role=decode kubectl label node gpu-node-decode-02 gpu.example.com/role=decode

然后分别创建 Deployment，通过nodeSelector把不同角色绑定到对应节点池：

# prefill-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: llm-prefill spec: replicas: 2 selector: matchLabels: app: llm-prefill template: metadata: labels: app: llm-prefill spec: nodeSelector: gpu.example.com/role: prefill containers: - name: engine image: registry.example.com/llm-engine:0.8.0 resources: limits: nvidia.com/gpu: 8

Decode Deployment 使用相同的模板，把nodeSelector改成gpu.example.com/role: decode即可。这里只展示调度分层，真正的请求转发还需要在 Prefill 和 Decode 之间实现 KV Cache 传递。比如请求调度器在 Prefill 完成后，确定一个目标 Decode Worker，然后把 KV Cache 传输过去。

4.2.3 典型的学术与开源参考

跨节点 PD 分离并不只是概念。近两年的系统论文与开源项目开始广泛采用：

• DistServe是较早系统化分析 Prefill/Decode 分离的论文之一，思路是把 Prefill 和 Decode 分布到不同 GPU 上，分别优化并行度。
• Mooncake以及部分以 KVCache 为中心的 serving 项目，也把跨节点分离和分布式 KV Cache 看成一个整体来设计。

实际工程中，框架层面的 PD Disaggregation 能力正在逐步成熟，但是否开启、如何调参，需要结合集群规模和实际流量验证。

4.2.4 适用场景与优缺点

适合大规模在线推理系统，尤其适合以下情况：

• 请求 Prompt 普遍很长，导致 Prefill 计算量高。
• Decode 输出普遍较长，并发对话多。
• 需要细粒度扩缩容，希望 Prefill 节点和 Decode 节点独立伸缩。

优点：

• 弹性好，两类节点可以分别扩容。
• 可以为 Prefill 和 Decode 选择不同 GPU 型号。
• 长 Prompt 和长输出场景下，整体吞吐优势显著。

缺点：

• 引入网络传输延迟，KV Cache 传递可能成为新瓶颈。
• 系统复杂度高，需要额外的调度组件和失败重试机制。
• 没有高速 RDMA 网络时，跨节点收益可能不明显。

4.3 架构三：以 KV Cache 为中心的缓存与计算分离（KVCache-centric Disaggregation）

4.3.1 核心思路

第三种架构不再只按“算 Prefill”和“算 Decode”来切分，而是将KV Cache 独立成一层分布式存储系统。计算节点仍然分为 Prefill 和 Decode，但 KV Cache 不绑定在某一块 GPU 显存里，而是存放在统一的 Block Store 中。

每次请求到达后，如果请求的前缀在 KV Cache 层已经存在，只需要对新增部分做增量 Prefill，然后直接进入 Decode。这本质上是一种“以存储为中心”的架构，和传统单体推理有显著区别。

架构示意：

┌──────────────────────────────┐ request ───▶ │ 计算平面 (Compute Plane) │ │ Prefill Worker / Decode │ │ Worker │ └─────────────┬────────────────┘ │ 读写 KV Block ┌─────────────▼────────────────┐ │ 缓存平面 (KVCache Store) │ │ 分布式存储、块管理、淘汰 │ └──────────────────────────────┘

在这个模型中，KV Cache Store 不是备份系统，而是服务链路中的“主存”。它负责 KV Block 的分配、访问、淘汰、复制。计算节点不再因为显存不足而拒绝请求，可以把更多显存用于计算。

4.3.2 代码思路示意

以下伪代码演示“先查 KV Cache，算不到再执行 Prefill”的思路，不是某个框架的真实 SDK：

def serve(request, cache_store, prefill_engine, decode_engine): prefix_key = request.prefix_key # 1. 尝试从全局 KV Cache 中匹配历史前缀 prefix_blocks = cache_store.match(prefix_key) # 2. 如果历史前缀没有缓存，需要完整跑 Prefill，并写回缓存 if prefix_blocks is None: prefix_blocks = prefill_engine.compute(request.prompt) cache_store.put(prefix_key, prefix_blocks) # 3. 只对新增内容生成，或者直接拉取缓存进入 Decode response = decode_engine.generate(request.tail, prefix_blocks) return response

这个思路的价值在于：对同一套知识库问答、同一批次相似 Prompt，很多用户输入前缀高度重合。如果每次都重算，浪费大量算力；如果把 KV Cache 做成独立可复用层，可以显著降低重复 Prefill 开销。

4.3.3 适用场景与优缺点

适合多轮对话频繁、知识库问答、长上下文服务等场景。这类业务的共同点是历史请求前缀重复度高，或者上下文非常长，单纯把 KV Cache 塞在一张卡里会迅速占满显存。

优点：

• 显存压力和计算资源解耦，GPU 显存利用率更可控。
• 前缀复用可以减少重复 Prefill，提升有效吞吐。
• 长上下文场景下容错性更好，某个节点故障后 KV Block 可以从其他副本恢复。

缺点：

• 架构复杂度最高，需要实现分布式 KV Cache 的读写一致性。
• KV Cache 存储层本身需要消耗额外机器资源和运维人力。
• 访问远端 KV Block 的延迟必须足够低，否则缓存收益会被网络开销吃掉。

5. 三种分离式推理架构对比与选型建议

把三种架构放在一起对比，能更直观地看清差异：

选型时先问自己三个问题：

1. 流量规模多大：如果 GPU 总量不超过一台服务器，直接选架构一即可，没必要引入分布式复杂度。
2. 网络条件如何：是否有 InfiniBand 或 RoCE；如果只有普通 10GbE 以太网，跨节点分离的 KV 传输会拖后腿。
3. 业务是否重前缀复用：如果很多请求前缀相同，架构三的收益最大；如果每个请求都是全新的长文本，架构三的缓存命中率会偏低。

6. 实践中的常见问题与排查思路

分离式推理，尤其是跨节点方案，落地时经常出现“架构图画得很漂亮，压测数据反而不如单体服务”的情况。下面按经验整理几类高频问题。

6.1 为什么“分离后反而更慢”

这是咨询频率最高的问题。原因通常是：请求量还没有大到让单体服务产生明显的 Prefill 和 Decode 冲突。如果每分钟只有几十个请求，单体推理很容易完成全部工作；强行跨节点后，KV Cache 还要走一遍网络，额外开销大于优化收益。

建议先做压测。观察在单体服务下，当并发提升到某个阈值后，TTFT 是否快速恶化；如果并没有恶化，就不需要过早拆分。

6.2 如何观察节点配比是否合理

核心指标不是简单的 GPU 利用率，而是：

• TTFT（Time To First Token）：首 token 延迟，主要反映 Prefill 和调度效率。
• ITL（Inter-Token Latency）：相邻 token 之间的生成间隔，反映 Decode 能力。
• Token 吞吐：单位时间内生成的 token 总数。
• 排队长度：请求在 Prefill 和 Decode 前的等待数量。

如果排队集中在 Decode，说明 Decode 节点不够；如果集中在 Prefill，则要扩容 Prefill。单纯看nvidia-smi的显存占用并不能说明问题，因为显存高可能只是缓存碎片造成的。

6.3 驱动层问题的排查顺序

在多机集群中，最怕的是“每一台机器单独看都正常，整体调度后忽然 GPU 掉线”。遇到nvidia-smi无法连接驱动时，建议按以下顺序排查：

1. 确认物理机和容器内驱动版本一致。
2. 检查内核模块lsmod | grep nvidia。
3. 查看容器是否挂载了与主机匹配的 NVIDIA Container Toolkit。
4. 查看 Kubernetes 是否使用 NVIDIA Device Plugin 或 GPU Operator。
5. 不要在业务高峰期直接改动驱动或 docker 运行时，变更前必须有回滚方案。

7. 工程建议与最佳实践

架构设计完成后，真正拉开差距的是工程细节。下面这几条是实际部署时容易忽略的点。

7.1 先单实例调优，再谈分离

很多团队还没把单个 vLLM/SGLang 实例的参数调好，就直接上跨节点分离。这是本末倒置。建议顺序是：

• 先做单机/单实例压测，确定模型本身能达到的 TTFT 和吞吐基线。
• 再在单