如果你最近在搜大模型推理优化相关的内容大概率会反复撞见这几个词PD 分离、Disaggregated Inference、KV Cache 复用、Decode 延迟优化。如果再叠加“NVIDIA”“LPU”这样的关键词不少入门读者很容易被绕晕。这篇文章的目标很直接把“分离式推理”这个概念拆开讲清楚典型的三类拆分方式分别解决什么问题在 NVIDIA GPU 环境下它们又是怎么落地和观察的。先说一个容易踩坑的点LPU 这个缩写并不只有一个含义。Groq 的 LPU 是 Language Processing Unit是专用推理芯片和 NVIDIA 没有绑定关系而在另一类技术讨论中LPU 会被抽象成“低时延推理处理单元”或“解码处理角色”它更多是一种部署角色分析视角不是 NVIDIA 官方发布的某一款芯片名称。因此下文讲“NVIDIA LPU 三种分离式推理架构解析”时重点放在架构本身一类以 Prefill/Decode 角色拆分一类以 Transformer 层/流水线阶段拆分一类以 KV Cache/推理上下文状态拆分。三种拆分方式都能把原来“大一统”的推理服务拆开让 GPU 资源各司其职。看完这篇文章你能建立起一张比较完整的判断地图分离式推理到底拆什么、三种架构各有什么特点、什么时候该用哪一种、在 NVIDIA 多卡环境里用什么工具做验证和排错。部分部署示例会涉及 vLLM、TensorRT-LLM 或 NVIDIA Triton 这类常见推理服务组件但不会绑定某一个特定仓库版本实际落地时请以你选择的推理框架官方文档为准。1. 先说清楚“LPU”和“分离式推理”1.1 LPU 的两种常见指代网络热词和搜索结果里经常同时出现 NVIDIA、LPU、架构这些词但 LPU 并不是一个被 NVIDIA 产品线固定下来的官方名词。为了避免后面讨论跑偏先做一张澄清表名称常见含义与 NVIDIA 的关系使用语境Groq LPULanguage Processing Unit面向语言模型的专用处理器无直接关系不同厂商/团队的产品Groq 产品介绍、LPU 推理对比LPU 角色化理解Logit Processing Unit / Latency Processing Unit / Low-latency Processing Unit 等缩写出现在一些推理架构分析文章中用来描述“延迟敏感的解码/输出处理角色”技术文章、系统设计讨论、架构解析广义“LPU 式节点”只负责模型推理中延迟敏感阶段的计算节点可以运行在 NVIDIA GPU 上指导节点服务角色切分分离式推理架构设计本文采用第三种理解。也就是说本文并不声称“NVIDIA 官方发布了一颗叫 LPU 的新芯片”而是把 LPU 当作一种“低时延解码处理单元”的抽象角色去分析 Prefill/Decode 分离、流水线并行分离、KV Cache 状态分离这三类架构。这样既能避免误解也能让读者从角色和资源角度读懂推理架构。1.2 分离式推理在拆什么经典的大模型在线推理服务请求进入后通常会经历两个阶段Prefill把用户的 Prompt 一次性计算一遍生成完整的 KV Cache并产出第一个输出 token。这个阶段计算量密集对首 token 时延TTFT影响最大。Decode每步读取上一步输出 token结合已有 KV Cache 做一次自回归解码逐步生成新 token。这个阶段显存访问密集输出速度往往被显存带宽限制。传统做法是把 Prefill 和 Decode 放在同一批 GPU 上执行。这样做简单但也会同时承受两类不同特征的工作负载。分离式推理的核心思想就是把这几个原本绑在一起的步骤或状态拆开交给不同资源池处理从而在并发、延迟、显存利用率之间做更细粒度的权衡。2. 三种分离式推理架构速览为了让你后面读起来有抓手先用一张表把三种架构的核心差异摆出来架构拆分维度主要解决的问题典型落地方式对 NVIDIA 环境的依赖Prefill/Decode 分离PD 分离按请求处理阶段拆分Prefill 和 Decode 互相抢占资源导致 Decode 时延抖动独立 Prefill 实例池 独立 Decode 实例池实例间传递上下文状态NVLink/InfiniBand 互联、TensorRT-LLM/vLLM/SGLang 等框架支持流水线并行推理Pipeline Parallelism按模型层/流水线阶段拆分单卡显存放不下完整模型权重的扩展问题将模型按层切分每张 GPU 负责一部分 Transformer 层多卡互联、NVSwitch、NCCL 通信、框架 PP 参数KV Cache/上下文状态分离按状态存储与计算角色拆分长上下文、多轮 Agent 场景下缓存复用率低、推理节点重启丢状态KV Cache 独立池支持 Prefix Cache、Radix Cache、跨实例缓存复用显存/NVMe/内存分层存储、网络传输协议、Frameworks 的 cache 后端三种架构不是互斥关系。实际生产环境中一个推理集群可能同时启用流水线并行来扩大单模型可部署规模再用 PD 分离把不同实例的服务角色拆开同时给 KV Cache 做独立缓存后端。区分理解是为了在选型时不混淆。3. 为什么推理要分离Prefill 与 Decode 的矛盾分离式推理的核心动机来自 Prefill 和 Decode 两个阶段完全不同的资源画像。3.1 Prefill 与 Decode 的资源特征维度PrefillDecode计算特征高并行矩阵计算密集大量 token 同时处理每步只生成 1 个 token逻辑串行主要瓶颈GPU 算力/Tensor Core 利用率显存带宽、KV Cache 读取吞吐关键延迟指标TTFT首 token 时延TPOT每输出 token 时延、ITLtoken 间延迟对批量友好的程度天然适合大 batch可提升算力利用率batch 越大每轮要读取的 KV Cache 越多带宽压力越大对线程/核心的需求算力并行需求高等待访存的比例高核心未必吃满如果只用一个 GPU 实例同时接收长 Prompt 和高并发 Decode 请求会出现明显的“资源互踩”某个长 Prompt 进来时Prefill 计算瞬间抢占算力正在处理的 Decode 请求的 token 生成速度就会被拉慢表现为 TTFT 和 TPOT 都开始抖动。为了保证在线服务的延迟稳定运营者又不得不降低 batch size结果 GPU 算力又吃不饱。3.2 分离带来的收益把两阶段拆开后可以得到三个直接收益各自独立做资源扩缩容。如果业务中长文档摘要多Prefill 池可以单独扩容如果聊天交互多Decode 池可以单独扩容。延迟指标可以分开优化。Prefill 池追求高算力 batchDecode 池可以用更小 batch、更高显存带宽实例来保证单 token 延迟。调度策略解耦。不同阶段的超时时间、重试策略、并发限制可以分别设置不再用一刀切策略去约束两种完全不同特征的任务。这并不意味着分离没有代价。请求上下文需要从一个实例传到另一个实例网络传输会带来额外时延系统调度也变得更复杂。架构设计的重点是判断收益是否大于这些额外开销。4. 架构一Prefill/Decode 分离部署PD 分离4.1 拓扑结构与工作流程PD 分离架构中一组 GPU 实例专职处理 Prefill另一组实例专职处理 Decode。请求到达后调度层先把 Prompt 交给 Prefill 实例Prefill 实例计算得到 KV Cache 和相关上下文状态再通过内部网络把它交给某一个 Decode 实例由 Decode 实例继续完成剩余的自回归生成。这个流程的优点很直接一个实例不会同时处理 Prefill 和 Decode因此长 Prompt 导致的算力高峰不会打断同一实例上的解码过程。反过来Decode 实例也不需要为偶发的大计算预留过多算力。从前文“LPU 角色化理解”的角度看Decode 实例就是典型的延迟敏感处理角色。它不负责一次性的大规模并行前向计算而是持续做低时延解码操作。这个角色如果拆到独立资源池就可以用更贴近实际时延要求的 GPU 规格去配置。4.2 适用场景与优缺点比较适合使用 PD 分离的场景在线聊天机器人对输出 token 间隔有明确稳定要求大量长文档问答请求Prompt 输入长、Prompt 长度波动大需要同时服务多种不同延迟优先级请求的平台。相对明显的代价多一跳网络传递在非高速互联环境下会增加调度复杂度如果集群总并发不高拆分反而可能造成部分节点闲置对调度器要求更高至少要能感知“当前 Decode 实例是否适合接收某个请求”。4.3 在 NVIDIA GPU 环境的关键配置在 NVIDIA 环境下落地 PD 分离重点看三层实例间通信。如果两个角色在同一个 NVLink 域内传输延迟相对可控跨节点部署则要关注 InfiniBand 或 RoCE 网络的带宽与延迟。推理框架支持。TensorRT-LLM 的多实例部署能力、vLLM 的分布式参数、SGLang 的路由能力都可能是 PD 分离的承载点。框架版本差异会影响具体参数名部署前先看官方文档。资源调度编排。可以用 Kubernetes 配合 GPU 调度插件把不同角色调度到不同节点池也可以直接用 Slurm 做多节点任务编排。下面给一段调度示意代码作用是说明 Prefill / Decode 分离模式下不同角色可能被分配不同资源池。具体实现请按实际调度系统调整# 概念示意角色分离的节点分配 # 实际命令不是固定标准请根据自己使用的推理框架和调度平台改写 # Prefill 节点池偏算力适合处理长 Prompt 预填充 kubectl label node gpu-node-01 roleprefill # Decode 节点池偏低时延解码适合持续输出 kubectl label node gpu-node-02 roledecode # 给 Prefill 服务打上节点选择器 kubectl apply -f - EOF apiVersion: apps/v1 kind: Deployment metadata: name: prefill-server spec: replicas: 2 selector: matchLabels: app: prefill template: metadata: labels: app: prefill spec: nodeSelector: role: prefill containers: - name: prefill image: your-inference-image:latest command: [python, run_server.py, --role, prefill] resources: limits: nvidia.com/gpu: 8 EOF如果你是在单机多卡阶段做小规模验证可以先不引入 Kubernetes直接通过 NCCL 与本地 IPC 通信验证两个分离角色可以并行跑通确认收益后再扩大规模。5. 架构二按层切分的流水线并行推理5.1 工作方式模型分层不等于请求分发另一类分离式推理是把大模型的 Transformer 层按顺序切到不同 GPU 上。比如一个 40 层模型被切成 4 段GPU 0 负责 0-9 层GPU 1 负责 10-19 层依此类推。请求像流水线一样从第一段流到最后一层。这种分离方式并不是把“不同请求”分给不同 GPU而是把一个模型本身拆成串行阶段。它在大模型单卡放不下的场景里尤其有用如果模型权重超过单卡显存仅靠并行复制权重到多卡可能不现实按层切分让每张卡只负责一部分权重。5.2 微批次与气泡性能关键流水线并行是否能跑出效果很依赖“微批次”的调度策略。如果每个 GPU 一次只处理一个完整请求后段 GPU 会长时间空闲。实践中通常把一个 batch 切成多个 micro-batch让不同 micro-batch 在不同 GPU 段上重叠执行减少流水线气泡。这种做法带来两个后果吞吐通常能提高因为多张卡都能同时处于工作状态单个请求的首 token 延迟会增加因为它必须经过所有 GPU 段才算完一次前向跨节点时还要加上网络传输时延。因此流水线并行的分离方式更适合“模型大、吞吐优先、对绝对首 token 延迟不那么敏感”的任务如果业务要求极低 TTFT完全依赖纯流水线并行可能不是最优选择。5.3 与架构一的组合PD 分离和流水线并行并不冲突因为两者分离的维度不同。PD 分离拆的是“同一个请求的 Prefill 与 Decode 阶段”流水线并行拆的是“模型的层序列”。实际部署中一个 Prefill 池内部可能还要用 Tensor Parallel Pipeline Parallel 把超大模型跑起来Decode 池同样可以用流水线并行扩大容量。梳理这两层关系时建议先画一张图外部是角色分离内部是并行策略。在 NVIDIA 环境中跨卡通信依赖 NCCL。单机多卡时容易受到 NVSwitch/NVLink 拓扑影响跨节点时则依赖 InfiniBand 或 RoCE。启动类似服务时常见做法是把--tensor-parallel-size和--pipeline-parallel-size显式写清楚# 通用启动示例需要先确认框架是否支持 tensor parallel / pipeline parallel # 请使用你当前安装框架版本支持的参数名建议先执行 --help 查看 python -m vllm.entrypoints.openai.api_server \ --model /models/your-model \ --tensor-parallel-size 4 \ --pipeline-parallel-size 2 \ --host 0.0.0.0 \ --port 8000这段命令只用于展示并行参数的配置位置。实际项目中模型路径、TP/PP 数值、框架入口、容器挂载都需要按你当前环境改写如果 GPU 数量不够、显存不足启动时很可能直接报 CUDA OOM 或 NCCL 通信错误。6. 架构三KV Cache 与推理状态分离6.1 KV Cache 为什么会成为瓶颈Prefill 阶段每读到一个输入 token就会生成对应的 Key 和 Value 向量缓存下来供后续 Decode 阶段使用。这个缓存就是 KV Cache。随着模型层数、上下文长度、并发请求数量增加KV Cache 会以非常快的速度占满显存。举一个直观现象同样是 7B/8B 级别模型短文本并发 100 路可能显存并不紧张但把每路上下文拉长到 32K 甚至更长后KV Cache 可能比模型权重占用的显存更高。长上下文已经成为当前大模型应用的重要场景因此 KV Cache 管理对推理集群的稳定性影响极大。6.2 缓存复用与状态分离第三种分离式架构的思路是把 KV Cache 从计算节点中分离出来做成独立的缓存池或状态存储。这样计算实例可以做得“无状态”某一台节点重启时不会把用户多轮会话的上下文全部丢失用相同前缀的请求也可以复用已有 KV Cache减少重复 Prefill 计算。工程上常见的技术方向包括Prefix Cache对相同前缀的 Prompt 做 KV Cache 复用适合多轮对话和固定 system prompt 场景Radix Cache以树状前缀结构管理上下文缓存适合多轮分支式 Agent 任务分布式 KV Cache Store把缓存放到独立存储池中多个推理节点共享。在 NVIDIA 环境下这种架构通常要面对显存、NVMe、主机内存构成的多级存储体系。计算节点本地显存是最高速但容量最小的层级独立缓存池将一部分 KV Cache 放到远端节点显存或服务器内存让更多请求能命中缓存代价是缓存命中时仍需要多一次远程读取。6.3 架构特点特点说明核心收益提高长上下文场景缓存命中率、减少重复 Prefill、推理节点状态可恢复核心代价远程 KV Cache 读取会增加响应时延没有命中缓存时可能比纯本地多一次网络开销适合场景长文档多轮问答、Agent 工作流、高并发共享前端的知识库服务NVIDIA 环境相关点显存分配、NVLink/网络延迟、缓存后端与 GPU 显存之间的数据搬移都直接影响命中收益“无状态推理节点 有状态 KV Cache 池”的抽象非常接近现代微服务架构的做法计算服务不保存业务状态把状态放到独立存储层从而提升弹性与可用性。它也让“杀掉一个推理容器再拉起一个”的成本变低因为关键上下文已经被外部存储接管。如果只是小规模试验可以先不开独立存储服务只在框架中开启 Prefix Caching用相同前缀的请求做对比测试观察不同长度前缀下的缓存命中率与响应延迟变化。这样最容易验证状态分离是否适合你的业务。7. NVIDIA 环境实践指南观察工具与启动验证7.1 环境准备通用清单在开始架构验证之前建议先确认以下环境信息避免因为基础配置不对导致后续排错困难GPU 型号与显存大小nvidia-smi查看记住每个节点的 GPU UUID 和显存总量。多卡互联拓扑nvidia-smi topo -m查看 NVLink/NVSwitch 连接关系判断哪些卡处于同一高速互联域。驱动与 CUDA 版本不同推理框架对 CUDA 版本适配范围不同驱动版本过旧可能导致 CUDA 初始化失败。网络配置跨节点场景确认 InfiniBand/RoCE 网卡是否被正确识别NCCL 是否能走 RDMA 通道。磁盘空间模型文件、日志、KV Cache 落盘缓存都需要预留空间尤其是长上下文测试场景。推理框架版本vLLM、SGLang、TensorRT-LLM 的版本不同参数名和功能支持差异较大先用--help确认。7.2 查看 GPU 互联拓扑架构解析离不开物理拓扑判断。PD 分离和流水线并行都需要把通信开销考虑进去而通信开销首先取决于 GPU 之间的物理连接。# 查看当前节点的 GPU 拓扑矩阵 nvidia-smi topo -m # 查看实时 GPU 利用率、显存占用和温度 nvidia-smi # 周期性刷新 GPU 指标适合观察推理时长的负载变化 nvidia-smi dmon -s pumnvidia-smi topo -m输出结果里能看到当前节点内 GPU 的互联方式。如果某两块卡之间是NV#说明走 NVLink如果输出是PHB或SYS说明要走 PCIe 甚至跨 CPU 访问通信延迟明显更高。跨节点做 PD 分离前判断好通信路径比盲目调框架参数更重要。7.3 启动推理服务与 API 观察在分离式推理架构还没有完全固化到你自己的集群前最容易的验证方式是用一个 OpenAI 兼容的 API 服务先跑通请求链路再切换不同并行配置观察指标。下面代码只做通用展示实际路径和框架参数需要修改# 先确认当前环境里 GPU 是否可用 python -c import torch; print(torch.cuda.device_count(), torch.cuda.get_device_name(0)) # 启动 OpenAI 兼容接口服务的通用示意以 vLLM 为例 # 不同版本启动命令有差异请先运行 python -m vllm.entrypoints.openai.api_server --help 确认 python -m vllm.entrypoints.openai.api_server \ --model /models/your-model \ --tensor-parallel-size 2 \ --pipeline-parallel-size 2 \ --gpu-memory-utilization 0.9 \ --host 0.0.0.0 \ --port 8000服务起来后用下面的 Python 脚本发一个简单的 Chat Completion 请求确认 token 输出是否正常import requests import time url http://127.0.0.1:8000/v1/chat/completions payload { model: your-model, messages: [ {role: system, content: 你是一个帮助排查推理服务的助手。}, {role: user, content: 请用一句话解释 PD 分离。} ], max_tokens: 256, temperature: 0.2 } start time.time() resp requests.post(url, jsonpayload, timeout180) data resp.json() print(耗时(秒):, round(time.time() - start, 2)) print(输出:, data[choices][0][message][content]) print(用量:, data.get(usage))通过观测耗时和usage中的 token 数可以大致推算首 token 延迟和每个输出 token 的平均间隔。不过注意单次请求的结果受网络抖动影响不能作为准确性能结论。要做可靠判断仍然需要压测工具和多次采样。8. 三种架构的选型参考与验证思路不同团队的需求差异很大这里给一个比较实用的参考方向业务现象优先考虑的架构验证重点长 Prompt 一进来在线对话的每秒输出 token 明显变慢Prefill/Decode 分离观察分离后 TPOT 是否更稳定Prefill 峰值是否不再干扰解码单卡显存放不下一个较大模型又不想频繁切分流水线并行Pipeline Parallelism对比不同 micro-batch 下 GPU 利用率和 TTFT 变化多轮 Agent 反复访问长上下文、相同前缀出现频率高KV Cache/状态分离统计前缀缓存命中率对比命中与不命中时的响应时延多个不同模型和多个在线业务共享同一批 GPUPD 分离 节点池划分验证不同角色节点之间的网络隔离和调度隔离需要快速弹性扩缩容节点经常被杀掉重建状态分离 无状态推理节点重建节点后来自 KV Cache 池的上下文能否继续解码选型时建议先做一个小规模对照实验。比如针对 PD 分离可以先在同一批硬件上分别跑“混合模式”和“分离模式”固定相同并发、相同 Prompt 分布、相同采样参数统计 TTFT 和 TPOT 的 P50、P95。如果分离后 TPOT 改善不明显说明当前瓶颈可能不在 Prefill/Decode 互踩而要检查其他因素。9. 性能观察方法与常见排查9.1 需要记录的核心指标指标反映内容观察方式TTFT首 token 出现前的耗时主要受 Prefill 阶段影响API 服务日志、自定义埋点TPOT生成一个输出 token 的平均耗时主要受 Decode 阶段影响压测工具、框架 metricsITLtoken 与 token 之间的间隔时间体现输出稳定性框架 metrics、监控面板GPU 利用率SM 忙碌程度注意不等于算力饱和nvidia-smi dmon显存占用权重 KV Cache 激活值 框架开销nvidia-smi、DCGMKV Cache 命中率长上下文和缓存复用效果推理框架自带日志或 metrics一个容易误判的点看到nvidia-smi里 GPU 利用率接近 100%不一定代表算力被有效利用。Decode 阶段大量时间可能花在等待显存数据读取上此时 SM 虽然“有任务”但很多是在等访存返回。要区分算力瓶颈和访存瓶颈需要结合 token 生成速度一起判断。9.2 常见问题排查问题现象可能原因排查方式解决思路服务启动后长时间无法对外提供服务模型文件缺失、路径错误或权重格式不对查看启动日志确认模型路径是否可读重新下载或转换模型权重修正路径GPU 利用率很低但显存已经占满KV Cache/权重占用过高batch 被压缩查看显存分配、上下文平均 token 长度降低单请求上下文长度、开启 Prefix Cache、增加节点跨节点通信非常慢网络没有走 RDMA 或 NVLink/NVSwitch 配置不对nvidia-smi topo -m看拓扑检查 NCCL 环境变量调整网络配置确认 RoCE/InfiniBand 驱动可用PD 分离后请求反而更慢单请求规模不足以抵消网络传输和调度开差对比混合模式与分离模式 P95提高并发再评估分离收益或先小规模验证长上下文请求频繁 OOMKV Cache 增长过快触发显存不足观察显存曲线与 KV Cache metrics降低max_model_len、增加显存、打开缓存复用推理节点重启后多轮会话无法继续KV Cache 未做外部化或会话未重启会话观察容器是否挂载持久化缓存启用外部 KV Cache/状态存储确认重启恢复策略10. 最佳实践与合规提醒分离式推理架构本身不复杂但落地到生产环境时工程细节会决定成败。建议把下面几项作为基础规则先跑通最小可运行环境不要一上来就上大规模多节点。先做单机多卡拓扑检查再切换到 PD 分离或者状态分离测试。多卡并行参数不是越大越好。TP 值受显卡显存和通信拓扑限制PP 值增加会带来额外同步开销需要实测对比。所有性能结论都要基于固定 Prompt 分布、固定并发和多次采样不要用单次请求判断架构好坏。推理服务默认端口如果冲突先检查ss -lntp或netstat -lntp再换端口启动。涉及开源模型和数据集时要遵守对应许可证要求在线服务处理用户数据前应做好脱敏和访问控制。不要把 KV Cache 状态、用户会话、业务日志直接暴露给外部。独立状态存储服务也需要鉴权和网络访问限制。如果模型用于内部知识库、Agent 或自动生成内容使用前应结合自身业务场景做效果复核和合规评估避免因模型输出问题引发业务风险。11. 总结回到开头的问题NVIDIA 语境下的分离式推理到底有哪些值得关注的设计这里给出的三种架构是三个不同的切入角度。Prefill/Decode 分离解决的是“同一批 GPU 上两类工作负载互相干扰”的问题适合在线服务抖动明显、需要独立扩缩容的场景。按层切分的流水线并行解决的是“单卡显存放不下大模型”和“多卡协同跑单个模型”的问题适合模型规模大、吞吐优先的任务。而 KV Cache/状态分离解决的是“长上下文、多轮对话、缓存复用与状态恢复”的问题适合 Agent 场景和高并发知识库系统。对刚接触这些概念的读者最推荐的行动路径是先在一台 NVIDIA GPU 服务器上跑nvidia-smi topo -m看物理拓扑然后用一个 OpenAI 兼容的推理服务做 baseline 压测再逐项开启 TP/PP 参数和 Prefix Cache观察 TTFT、TPOT、显存占用和 KV Cache 命中率。不要一开始就照搬超大集群配置先把指标体系和最小组件跑通再往分离式方向扩展。这样你才会真正感受到这类架构优化是为了解决哪些具体问题。