最近在研究大模型推理性能时经常绕不开两个词“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 推理的两个阶段Prefill预填充阶段把用户输入的 Prompt 一次性交给模型做并行计算生成对应的 Key/Value 缓存通常计算密集。Decode解码阶段模型逐个生成 token每个 token 生成都依赖前面已有的 KV Cache通常访存密集。传统单体推理服务里一个 GPU 上可能同时做 Prefill 和 Decode。出现请求时引擎先做 Prefill再进入 Decode直到生成结束。这样做实现简单但资源冲突明显短 Prompt、长输出和大并发场景互相干扰一个慢请求可能拖慢整卡服务。分离式推理的思路很简单把 Prefill 和 Decode 分配到不同的计算资源上分别调优、分别扩缩容。请求来了先到 Prefill 引擎处理输入再把中间状态交给 Decode 引擎继续生成。这样既能保证首 token 延迟也能提升整体吞吐。1.3 分离式推理要解决什么问题拆分不是为了炫技而是为了解决实际矛盾。TTFT 与吞吐矛盾TTFTTime 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 couldnt 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 传输。RoCERDMA 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 CacheDecode 引擎必须拿到这份数据才能继续生成。所以KV Cache 的生成、传递、存储方式直接决定分离式架构的性能。单实例场景下KV Cache 住在显存里就好访问很快。多实例/跨节点场景下KV Cache 需要从 Prefill 节点“搬”到 Decode 节点。这一步的传输速度如果慢整体收益会被抵消。3.3 怎么理解“三种分离式推理架构”“分离”这个词在不同层级理解不同。本文按工程落地粒度把常见方案分为三类单节点内卡组分离把一台服务器内的 GPU 划分成 Prefill 卡组和 Decode 卡组。跨节点池分离把集群中多台节点分别组成 Prefill 池和 Decode 池。以 KV Cache 为中心的缓存与计算分离把 KV Cache 单独做一层分布式存储所有计算节点按需读写。下面逐个展开。4. 三种分离式推理架构详解4.1 架构一单节点内卡组分离Intra-node PD Disaggregation4.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_DEVICES0,1,2,3 python launch_worker.py --roleprefill --port8001 # 在 GPU 4-5 上启动一个 Decode Worker export CUDA_VISIBLE_DEVICES4,5 python launch_worker.py --roledecode --port8002 # 在 GPU 6-7 上启动另一个 Decode Worker export CUDA_VISIBLE_DEVICES6,7 python launch_worker.py --roledecode --port8003 说明launch_worker.py是占位脚本不代表某个框架的真实入口。核心逻辑是给不同 Worker 分配不同显卡资源。如果使用 vLLM 这类框架需要再查对应版本的“Disaggregated Prefill”相关参数不同版本之间差异较大。4.1.3 适用场景与优缺点这种架构适合单机资源充足、服务规模还不大的场景。比如企业内部先做 PoC或者某个模型只部署在少量 GPU 服务器上但希望避免 Prefill 和 Decode 互相干扰。优点部署简单不需要跨节点网络调度。延迟低KV Cache 传输几乎不经过网络。运维成本低所有资源都在一台物理机内。缺点单台服务器 GPU 数量有限扩展性受限制。卡组比例固定后如果流量特征变化比如长 Prompt 请求变多需要重新划分显卡比例灵活性不高。4.2 架构二跨节点池分离Inter-node PD Disaggregation4.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/roleprefill kubectl label node gpu-node-prefill-02 gpu.example.com/roleprefill # 将节点标记为 Decode 池 kubectl label node gpu-node-decode-01 gpu.example.com/roledecode kubectl label node gpu-node-decode-02 gpu.example.com/roledecode然后分别创建 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: 8Decode 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 Disaggregation4.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”的思路不是某个框架的真实 SDKdef 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. 三种分离式推理架构对比与选型建议把三种架构放在一起对比能更直观地看清差异对比维度架构一单节点卡组分离架构二跨节点池分离架构三KVCache 中心化分离分离粒度单机内 GPU 卡组集群节点池KV Cache 存储层实现难度低中高高KV Cache 传输成本很低中高依赖网络中可通过缓存命中降低扩容方式单机扩容节点池独立扩缩容计算池与存储池独立扩容适用场景PoC、单机服务大规模在线推理长上下文、前缀复用主要风险单机资源上限KV 网络传输延迟分布式存储复杂度选型时先问自己三个问题流量规模多大如果 GPU 总量不超过一台服务器直接选架构一即可没必要引入分布式复杂度。网络条件如何是否有 InfiniBand 或 RoCE如果只有普通 10GbE 以太网跨节点分离的 KV 传输会拖后腿。业务是否重前缀复用如果很多请求前缀相同架构三的收益最大如果每个请求都是全新的长文本架构三的缓存命中率会偏低。6. 实践中的常见问题与排查思路分离式推理尤其是跨节点方案落地时经常出现“架构图画得很漂亮压测数据反而不如单体服务”的情况。下面按经验整理几类高频问题。问题现象常见原因解决思路开启 PD 分离后延迟反而升高KV Cache 传输耗时高于 Prefill 节省的时间先用同节点架构验证通过 profiling 确认传输耗时占比Prefill 节点空闲Decode 节点排队严重节点池配比不合理根据 TTFT/ITL 指标动态调整比例必要时扩 Decode 池多 GPU 集群状态不一致驱动或容器镜像版本不匹配统一驱动版本和镜像标签禁止各自升级KV Cache 存储层读写延迟高网络协议栈未启用 RDMA在测试环境验证 InfiniBand/RoCE并关注 MTU 配置某请求在 Decode 节点找不到对应 KV调度器没把中间状态和请求绑定好请求维度引入全局 Request ID日志全链路关联GPU 利用率很好但吞吐不涨框架后处理阶段或 tokenizer 成为新瓶颈对 Decode 后处理做异步化分析 CPU 火焰图6.1 为什么“分离后反而更慢”这是咨询频率最高的问题。原因通常是请求量还没有大到让单体服务产生明显的 Prefill 和 Decode 冲突。如果每分钟只有几十个请求单体推理很容易完成全部工作强行跨节点后KV Cache 还要走一遍网络额外开销大于优化收益。建议先做压测。观察在单体服务下当并发提升到某个阈值后TTFT 是否快速恶化如果并没有恶化就不需要过早拆分。6.2 如何观察节点配比是否合理核心指标不是简单的 GPU 利用率而是TTFTTime To First Token首 token 延迟主要反映 Prefill 和调度效率。ITLInter-Token Latency相邻 token 之间的生成间隔反映 Decode 能力。Token 吞吐单位时间内生成的 token 总数。排队长度请求在 Prefill 和 Decode 前的等待数量。如果排队集中在 Decode说明 Decode 节点不够如果集中在 Prefill则要扩容 Prefill。单纯看nvidia-smi的显存占用并不能说明问题因为显存高可能只是缓存碎片造成的。6.3 驱动层问题的排查顺序在多机集群中最怕的是“每一台机器单独看都正常整体调度后忽然 GPU 掉线”。遇到nvidia-smi无法连接驱动时建议按以下顺序排查确认物理机和容器内驱动版本一致。检查内核模块lsmod | grep nvidia。查看容器是否挂载了与主机匹配的 NVIDIA Container Toolkit。查看 Kubernetes 是否使用 NVIDIA Device Plugin 或 GPU Operator。不要在业务高峰期直接改动驱动或 docker 运行时变更前必须有回滚方案。7. 工程建议与最佳实践架构设计完成后真正拉开差距的是工程细节。下面这几条是实际部署时容易忽略的点。7.1 先单实例调优再谈分离很多团队还没把单个 vLLM/SGLang 实例的参数调好就直接上跨节点分离。这是本末倒置。建议顺序是先做单机/单实例压测确定模型本身能达到的 TTFT 和吞吐基线。再在单