最近围绕大模型推理的讨论总绕不开两个词NVIDIA GPU 和 LPU。很多人把 LPU 理解成又一种能跑的 AI 芯片于是在各种社区里争论LPU 能不能取代 NVIDIA GPU训练能不能用它既然 Groq 的 LPU 跑 Llama 那么快为什么大厂还在疯狂抢 H100、H200这些问题的答案并不在“芯片参数对比表”里而在一个更值得关注的概念上分离式推理架构。先给一个判断LPU 真正有价值的地方不是它的单卡推理延迟比 GPU 低多少而是它用一套完全不同的硬件设计倒逼行业重新审视一个一直被忽略的问题——大模型推理的各个阶段资源性格根本不是同一种。预填充阶段吃算力解码阶段吃访存带宽控制面和数据面对延迟的要求完全不同通用算力和专用推理引擎各有所长。如果始终用一台服务器、一块 GPU、一个推理进程把请求从头跑到尾那么无论芯片多强系统里必然存在资源浪费。NVIDIA 生态和 Groq LPU 看似在竞争实际上正从不同方向推动同一件事把推理拆开让每一段计算被放到最合适的位置上执行。这篇文章会先讲清楚为什么推理架构会出现“分离”趋势再结合 NVIDIA 的 NIM、Triton、TensorRT-LLM以及 Groq LPU 这类专用推理芯片梳理当前工程上已经成型的三种分离式推理架构服务化分离、阶段分离PD 分离、异构算力分离。读完你不仅能理解这些概念还能照着文中的示例在自己的机器上跑通一个最小可验证的推理服务并对生产环境中是否值得做“分离”有更清晰的判断标准。1. 一次大模型请求里藏着一场“资源性格冲突”要理解分离式推理架构先要理解一次大模型请求内部发生了什么。假设用户输入一段 1000 个 token 的 Prompt要求模型写一篇文章模型的执行过程可以粗略分成两个完全不同的阶段。第一个阶段叫 Prefill预填充。模型要把这 1000 个 token 和权重矩阵做完整的前向计算生成第一个输出 token 所需的中间状态。这个阶段的特点是计算量巨大、并行度极高GPU 的 Tensor Core 可以充分运转属于典型的“算力密集型”任务。用户看到的“首 token 延迟”TTFTTime To First Token主要由这一段决定。第二个阶段叫 Decode解码生成。模型生成第一个 token 后要逐个生成后面的 token每次只基于当前已有的序列预测下一个 token。这个阶段的特点是每次迭代只计算一个 token并行度低但必须反复读取权重和 KV Cache。GPU 的计算单元大量闲置真正卡住系统的是“访存带宽”——很像一个仓库里货物很多但传送带只有一条工人能力再强也只能等着货物送到面前。这也是业内常说的 Memory Wall访存墙。如果把这两个阶段硬塞在同一块 GPU、同一个推理进程里执行会出现一个尴尬的局面一台 8 卡 GPU 服务器可能在 Prefill 阶段算力打满但到了 Decode 阶段整体吞吐被访存卡住GPU 利用率可能掉到很低。反过来为了照顾 Decode 阶段的迭代式生成系统又不敢接太多长 Prompt否则 Prefill 会把资源全部抢走导致正在生成的其他请求全部变慢。更麻烦的是不同业务请求的资源诉求差异很大。一个 100 token 的轻量问答和一个 10000 token 的文档分析在 Prefill 阶段需要的算力差了几十倍一个只要求输出 50 token 的命令行补全和一个需要输出 2000 token 的长文写作在 Decode 阶段占用的时间也完全不同。把这些请求混合到同一个推理引擎里需要调度器不断“错峰”和“抢占”复杂度会越来越高。这说明一个核心问题大模型推理的瓶颈早已不只是“芯片算力不够”而是“一段请求里不同环节的资源需求互相冲突单一引擎无法同时满足”。传统的优化思路是提高单卡算力、加大显存带宽但这相当于在现有的单引擎架构上不停打补丁。另一种思路则激进得多既然 Prefill 和 Decode 资源性格完全不同为什么不把它们拆开分别放在不同的 GPU 池里甚至放在不同的芯片上执行这就是分离式推理架构要回答的问题。2. GPU 与 LPU两条路线同一个趋势在深入三种架构之前有必要先厘清 GPU 和 LPU 的定位差异因为后面很多分离决策都建立在这两个概念上。需要先说明一个事实LPU 并不是 NVIDIA 的产品而是由 Groq 公司设计的 Language Processing Unit语言处理单元。NVIDIA 的主流方案仍是 GPU。把 NVIDIA 和 LPU 放在一起讨论本质上是把“通用 GPU 推理方案”和“专用语言推理芯片方案”放在一起对比。NVIDIA GPU 的优势是通用性和生态。它本质上是一个大规模并行计算设备既支持 FP32、FP64 科学计算也支持 FP16、FP8 深度学习训练和推理。到了 Hopper、Blackwell 架构NVIDIA 加入 Transformer Engine、NVLink、NVSwitch进一步强化了多卡互联和大模型训练能力。但它有一个物理上的痛点显存带宽永远追不上算力的增长速度而且 HBM 的成本和功耗都很高。于是在 Decode 这种访存密集型任务里GPU 经常处于“算得动但喂不饱”的状态。Groq LPU 走的是一条更极端的路线。从公开资料看LPU 没有使用 HBM 高带宽显存而是把大量 SRAM 直接做到芯片附近并用软件定义网络在芯片间通信。这样的好处是推理延迟非常确定不需要像 GPU 那样频繁地把数据从显存搬到计算单元低并发单请求场景下生成的 token 速度可以非常快。代价也很明显SRAM 容量有限不像 GPU 显存那样动辄几十 GB、上百 GB可编程性和通用计算能力远不如 GPU几乎不能用于大模型训练也不适合需要灵活处理各种算子变化的任务。它更像一个针对 Transformer 推理过程做了深度定制的专用 DSP。对比维度NVIDIA GPUGroq LPU设计目标通用并行计算、训练与推理兼顾专用语言模型推理强调低延迟计算核心大规模 CUDA Core / Tensor Core专用推理核心确定性执行存储层次HBM 高带宽显存容量大SRAM 为主容量较小访问延迟低片上通信NVLink / NVSwitch生态成熟软件定义网络芯片间可扩展训练支持支持生态完善基本不支持推理优势高吞吐、支持长上下文、弹性大低并发低延迟、延迟抖动小生态成熟度CUDA、TensorRT-LLM、NIM、HuggingFace 生态独立生态以 Groq API 为主我不建议把 NVIDIA GPU 和 Groq LPU 理解成“谁取代谁”的关系。更准确的理解是GPU 适合当“通才”LPU 这类专用芯片适合当“专科医生”。当系统里同时存在“大批量、长上下文、需要频繁调整模型”的任务以及“小批量、延迟敏感、结构固定”的任务时把它们放在不同芯片上执行本身就是一种异构算力分离的思路。NVIDIA 显然也看到了单一 GPU 引擎处理所有推理请求的局限性。从 NIMNVIDIA Inference Microservices到 Triton Inference Server再到 TensorRT-LLM 和后续的 Dynamo 推理框架NVIDIA 其实一直在做一件事让模型推理从“跑进程”变成“跑服务”把推理过程中的计算、显存、调度、路由逐步解耦方便上层按需编排。这不是 NVIDIA 官方提出的“三种分离式架构”但确实是行业里正在形成的技术主线。3. 分离式架构之一服务化分离——把推理能力变成独立服务第一种分离发生在“模型调用方”和“模型运行后端”之间也就是服务化分离。它解决的问题非常实际如果一个团队要同时维护多个模型不同模型来自不同框架有的是 PyTorch、有的是 TensorRT、有的是 ONNX调用方的业务代码不可能为每个模型单独写一套客户端。在没有服务化分离的传统方式里业务团队通常把模型直接加载进业务进程或者在一个大单体服务里同时管理多个模型实例。这样做有几个隐患模型升级必须跟着业务版本发布风险很大某个模型触发的显存溢出可能拖垮整个服务不同模型对 GPU 的利用率差异很大混在一起难以精细化分配资源模型推理代码变更后还要重新做一遍业务回归测试。NVIDIA NIM 提供了一种更干净的服务化封装把某个模型连同推理后端、预处理、后处理、运行时依赖做成一个容器镜像暴露一个标准化的 OpenAI 兼容 HTTP API。调用方不再关心模型是用 TensorRT-LLM、vLLM 还是其他引擎跑的只要按照统一的 API 格式发送请求就行。每一个 NIM 容器可以独立部署、独立扩缩容、独立更新版本这就把模型推理从业务系统里剥离成了一组可独立运维的微服务。下面用一个最小示例演示服务化分离的思路。以 NVIDIA NIM 的一个 Llama 3 8B Instruct 镜像为例启动一个容器化推理服务# 1. 登录 NVIDIA NGC 容器仓库 # 用户名固定填写 $oauthtoken密码是你在 NGC 生成的 API Key docker login nvcr.io # 2. 启动 NIM 容器 # 注意镜像名称和 tag 以 NVIDIA 官方 NIM 页面发布为准不同时间版本不同 docker run -d --name nim-llama3 \ --gpus all \ -e NGC_API_KEY你的NGC_API_KEY \ -p 8000:8000 \ nvcr.io/nim/meta/llama3-8b-instruct:latest容器启动后会打印日志。看到类似“server started”或者“Uvicorn running on http://0.0.0.0:8000”的信息说明模型已经作为独立服务对外提供能力。然后可以通过任意 HTTP 客户端验证服务是否可用curl -X POST http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: meta/llama3-8b-instruct, messages: [ {role: user, content: 用一句话解释服务化推理} ], max_tokens: 128 }在业务端同样只面对一个标准的 HTTP 接口。如果把多个模型都封装成 NIM 容器网关层还可以根据请求里的 model 字段做路由把不同模型请求分发到不同的后端实例。from openai import OpenAI # 无论后端容器运行的是 Llama、Qwen 还是其他模型 # 客户端配置都保持统一的 OpenAI 兼容格式 client OpenAI( base_urlhttp://localhost:8000/v1, api_keynot-needed # 本地测试时并不真正校验 ) resp client.chat.completions.create( modelmeta/llama3-8b-instruct, messages[ {role: user, content: 解释一下服务化分离的好处} ], max_tokens256, ) print(resp.choices[0].message.content)服务化分离带来的核心变化是模型生命周期和业务生命周期解耦。业务团队发布新功能不需要重新部署模型模型升级或回滚也不影响业务进程。配合 Kubernetes还可以为不同模型设置不同的副本数、不同的 GPU 资源配额、不同的扩缩容策略。模型冷热分离、大模型和小模型分离都可以通过服务编排来做。如果团队暂时使用不了 NVIDIA NIM也可以用 vLLM、Triton Inference Server 或 FastAPI 自己封装。关键在于 API 层是否稳定、模型是否独立部署、是否可以只升级单个模型而不影响其他模块。只要做到这三点本质上就完成了第一种分离。4. 分离式架构之二阶段分离——Prefill 与 Decode 各跑各的第二种分离发生在模型推理流程内部是把 Prefill预填充阶段和 Decode解码生成阶段拆开执行行业内通常叫 PD 分离。它直接回应了本文开头说的“资源性格冲突”。先回顾一下问题。在一个正常的自回归生成请求里第一次前向计算需要处理全部 Prompt token计算量非常大之后开始逐 token 生成每次只做一个 token 的自回归推断。如果不做任何拆分系统必须用同一批 GPU 同时服务这两种负载。当大量长 Prompt 进来时GPU 的算力会被 Prefill 占满当大量短输出请求在 Decode 时GPU 的访存带宽又成为瓶颈。两个阶段的资源需求互相拉扯调度器只能做各种近似优化很难让所有指标都好看。PD 分离的基本思路是把请求的处理流程拆成“先由 Prefill 工作组处理长序列输入再把生成状态交给 Decode 工作组”。Prefill 实例侧重算力可以批量处理很多 PromptDecode 实例侧重吞吐和访存优化专门负责逐 token 生成。二者之间通过 KV Cache 的传输和协调来衔接。这样一来两类实例可以独立扩缩容Prompt 流量大了就扩容 Prefill 实例输出需求大了就扩容 Decode 实例不会再互相拖累。有的读者可能会问这不就是把一个大模型服务拆成了两个 RPC 阶段吗确实它的代价也在这里。KV Cache 在 Prefill 实例上生成后需要转移到 Decode 实例如果两个实例不在同一台机器还要考虑跨节点传输。状态转移的延迟、调度器的复杂度、KV Cache 的显存管理都会比单体服务更复杂。所以 PD 分离并不是所有业务的第一选择它更适合那些“上下文很长、并发很高、对吞吐有要求”的生产环境。而从公开资料看已有不少大模型推理平台在采用类似思路例如 DeepSeek 在技术分享中提到的预填充与解码分离部署就是把不同的 GPU 池分别用于 Prefill 和 Decode。如果你用的是 vLLM最简单的实践方式并不是直接在生产环境配置完整的 PD 分离而是先理解“可以用多个推理实例分担不同负载”这一层。下面是一个简化的多实例部署示意用于演示流量分层的思想# Prefill 实例监听 8001主要接收长 Prompt 请求 python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --port 8001 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 # Decode 实例监听 8002主要接收生成后阶段的请求 python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --port 8002 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9需要提醒的是上面这个示例只是把服务拆成了两个独立实例让入口流量可以按阶段分开真正的 PD 分离还需要打通两个实例之间的 KV Cache 传输和状态协调不同版本的 vLLM 对 PD 分离的支持程度不同具体配置以你使用的版本官方文档为准。如果你想在生产环境做 PD 分离还需要关注三个关键组件KV Cache 传输方式、调度策略、故障恢复机制。PD 分离的本质是把“一次完整前向推理”从单一黑盒变成可编排流水线。对于工程团队判断是否要做 PD 分离建议先观察两个指标一是 GPU 在 Decode 阶段的实际利用率是否长期偏低二是长 Prompt 请求和短请求混部时TTFT 和单 token 生成速度是否频繁波动。只有当这些问题明显影响业务时才值得引入阶段分离因为它的复杂度会让运维成本上一个台阶。5. 分离式架构之三异构算力分离——GPU 与 LPU 类专用芯片协同第三种分离不是在软件流程里拆阶段而是在硬件资源层做分工把不同特征的计算放到不同芯片上执行。这是 LPU 这类专用推理芯片出现后最值得关注的一种架构变化。我常用一个类比来理解这种分离全科医生和专科门诊。GPU 是全科医生什么都能看训练模型、微调、跑各种框架、处理长上下文都能胜任LPU 这类专用推理芯片更像是某个专科门诊它对语言模型的推理过程做了深度定制在特定的低延迟生成场景下很有优势但你不会派它去做大模型训练也不会拿它来跑复杂的科学计算。在真实的推理系统里异构算力分离通常表现为NVIDIA GPU 集群负责训练、微调、中长期批量任务Groq LPU 或 GPU 中的专用推理实例负责对延迟极其敏感的在线生成任务CPU、DPU 负责数据预处理、网络卸载和部分控制逻辑。上层有一个统一的路由层根据请求特征决定把它送到哪一类算力。假设你已经拥有了一个可以同时管理 GPU 池和 LPU 池的推理网关可以用策略引擎区分请求。下面是一个简化的路由策略示例def route_request(request): # 离线批量任务优先走 GPU 大吞吐池 if request.get(task_type) batch_offline: return gpu_batch_pool # 延迟要求小于 200ms 且输出长度可控走 LPU 低延迟池 if request.get(latency_sla_ms, 1000) 200 and request.get(max_tokens, 4096) 2048: return lpu_latency_pool # 长上下文或复杂多轮对话走 GPU 长文本池 if len(request.get(messages, [])) 10 or request.get(long_context): return gpu_long_context_pool # 默认走成本较低的通用服务池 return gpu_shared_pool上面的代码只是工程示意不是任何厂商的官方标准但它点出了异构算力分离的关键路由层需要知道每个请求的延迟要求、上下文长度、输出长度、业务类型再结合不同算力池的成本和实时状态做调度。这个路由层本身也是前面讲的“服务化分离”的延伸——先有稳定可调用的独立服务才能在服务之上按策略做分发。异构算力分离最大的收益是成本与延迟的平衡。并不是所有请求都需要最强的 GPU 来跑简单指令、固定格式抽取、短文本分类这些任务放在专用推理芯片或规格较小的推理实例上可能又快又便宜复杂的长文本生成、Agent 多轮规划、需要频繁调用工具的任务再交给大算力 GPU。这样可以把有限的 GPU 资源集中留给真正复杂的模型和请求。但异构算力分离也有明显的适用边界。首先不同芯片的量化格式、算子和部署方式不同把一个模型从 GPU 迁到 LPU 并不是几行代码能完成的需要额外工程适配。其次引入异构资源后监控、告警、日志链路会变长排障成本上升。最后也是最重要的一点如果请求复杂性很高、模型频繁升级异构部署会拖慢迭代速度。我的建议是适合异构分离的团队通常已经有比较稳定的模型版本和清晰的服务分层如果模型还在快速迭代阶段先别急着把算力拆得太散。6. 三种分离之间的关系从“能跑”到“可编排”理解了三种分离之后还需要把它们放在同一张图里看因为它们不是三个并列的技术选项而是分别作用于系统的不同层次。服务化分离属于“接口层”的分离它解决的是模型与应用之间的耦合问题让模型变成可以独立部署、独立升级的服务。这个分离一旦做好上层做流量路由、灰度发布、多模型切换都会顺手很多。阶段分离PD 分离属于“流水线层”的分离它解决的是同一个模型请求内部不同阶段对资源需求冲突的问题。异构算力分离则属于“资源层”的分离它关注的是多个模型、多个请求之间如何分配到不同的芯片和实例上。用一个现实中的部署演进来看这三种分离之间的关系一开始你在一台 GPU 服务器上加载了一个模型通过一个 Python 脚本对外提供预测这是“能跑”阶段。接着你把这个模型封装成独立的 HTTP 服务业务代码通过 API 调用这是完成了服务化分离。再往后你发现长 Prompt 请求和短输出请求混在一起时性能不稳定于是把服务拆成 Prefill 池和 Decode 池让请求在两个阶段之间流转这是完成了阶段分离。最后你发现自己手里有 GPU也有专用推理资源部分简单任务完全可以用专用芯片跑于是你在网关层加了一个路由策略把请求分流到不同后端这是完成了异构算力分离。可以看到三种分离是渐进叠加的关系。没有服务化分离后面的阶段分离和异构分离都无处挂载因为上层调度器需要一套稳定的接口去操作后端没有阶段分离异构分离也只能停留在“把整个模型搬到另一类芯片”的粗粒度层面没法针对同一模型的不同阶段做精细化分流。谁先做、谁后做取决于当前最痛的问题在哪一层。分离维度解决的主要矛盾典型实现建议落地顺序服务化分离业务与模型部署耦合NIM、Triton、vLLM 服务化封装先做阶段分离Prefill 与 Decode 资源冲突PD 分离、异构推理框架第二步异构算力分离不同请求成本与延迟不平衡GPU 池 LPU/专用实例 路由层第三步生产环境真正难的往往不是在某一个维度上做到极致而是要把三个维度的能力组合成一个可观测、可灰度、可回滚的推理系统。例如采用 NIM 后不同模型服务可能由不同镜像和不同后端生成统计口径不一致这时需要监控层对服务做统一的数据采集做 PD 分离后KV Cache 的传输和状态同步是否正常需要新的监控项做异构分离后同一个请求可能在不同资源池间跳转调用链追踪和计费逻辑也要随之调整。每一步分离都要有配套的工程能力跟上。7. 实践在自己机器上跑通一个服务化推理入口理论讲得再多不如跑通一个最小系统。下面用一个更通用的示例帮助你在有 NVIDIA GPU 的机器上启动一个服务化推理入口。之所以用 vLLM 而不是直接使用 NVIDIA NIM 镜像是因为 vLLM 面向社区更开放不需要企业级 NGC API Key适合作为理解服务化分离的入门工具。环境准备方面你需要一台安装了 Ubuntu 或 CentOS 的 Linux 机器最好带一块 NVIDIA GPU显存建议至少 16GB这样可以运行 7B 到 13B 参数级别的模型。操作系统、NVIDIA 驱动、CUDA 版本的组合请以实际环境为准本文示例重点是通用流程。先确认 GPU 驱动是否正常输入命令lspci | grep -i nvidia nvidia-smi如果nvidia-smi正常输出 GPU 型号、驱动版本、显存信息说明驱动环境可用。如果你是第一次在 Ubuntu 上安装 NVIDIA 驱动建议多留意驱动与内核版本的匹配问题这也是常见的入门坑。然后创建 Python 虚拟环境并安装 vLLMpython3 -m venv venv source venv/bin/activate pip install --upgrade pip pip install vllm安装完成后选择一个你能够下载的开源模型。这里以 Qwen2.5-7B-Instruct 为例。如果你的机器无法直接访问 Hugging Face可以换成 ModelScope 上可下载的模型或提前配置镜像源。启动服务后python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --port 8000 \ --max-model-len 8192 \ --gpu-memory-utilization 0.8启动日志如果出现“Starting vLLM API server”以及监听地址说明服务已经运行。vLLM 默认也会暴露一份/health或/v1/models接口可以用 curl 检查curl http://localhost:8000/v1/models成功后会返回一个 JSON包含当前部署模型的 ID 和元数据。如果这一步看到模型信息说明你已经把模型封装成了一个标准的推理服务。接下来模拟业务侧调用写一个 Python 脚本from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keynot-needed, ) resp client.chat.completions.create( modelQwen/Qwen2.5-7B-Instruct, messages[ {role: system, content: 你是一名擅长解释技术的工程师。}, {role: user, content: 为什么大模型推理需要服务化部署} ], max_tokens256, ) print(resp.choices[0].message.content)运行脚本后如果能正常打印结果说明你的调用方已经完全不再关心模型内部运行逻辑只依赖服务的 HTTP 接口。这也是第一种分离架构的直观体感。如果一次请求处理时间特别长不要先怀疑代码先检查模型加载日志和 GPU 资源占用。还可以在另一台机器上用同样的 Python 代码访问这台服务器的 8000 端口只要网络策略允许就会发现推理能力已经被网络 API 解耦这本质上就是微服务化的第一步。8. 常见问题与排查方法nvidia-smi报错“couldnt communicate with the NVIDIA driver”是刚接触 NVIDIA GPU 时最容易遇到的问题。这种情况通常不是硬件坏了而是驱动和当前内核版本不匹配或者驱动安装后没有正确加载。先用dmesg | grep -i nvidia查看内核日志再用lsmod | grep nvidia检查模块是否加载。对于具体驱动安装建议不要在业务服务器上直接操作而是先在测试环境验证驱动与 CUDA 的兼容组合。Docker 启动 GPU 容器时报错“could not select device driver with capabilities: gpu”原因是宿主机缺少 NVIDIA Container Toolkit。需要在宿主机安装并配置好 nvidia-container-runtime然后重启 Docker 才能让容器使用 GPU。模型第一次推理耗时很长往往是正常的。服务启动时只是加载模型权重还没完成预热有些推理后端会在首次请求时构建优化引擎例如 TensorRT-LLM 需要把模型编译成 TensorRT Engine这个过程可能需要几分钟甚至更久。建议在服务上线前先发一个预热请求或者提前构建好引擎。TTFT 很高但 GPU 利用率波动很大可能不是单实例问题而是 Prefill 请求和 Decode 请求混跑互相争抢资源。先通过监控拆分两类请求的耗时如果确实存在互相干扰再考虑做 PD 分离或在服务入口限制长 Prompt 请求的数量。PD 分离后 Decode 侧频繁报显存不足要检查 KV Cache 的容量和调度策略。KV Cache 是影响并发上限的核心因素输出 token 越长占用的显存越多。可以适当降低单请求最大输出长度或为 Decode 实例分配更多 GPU必要时使用 KV Cache offload 技术把不常用状态迁移到 CPU 内存。长并发场景返回 502 或超时优先查看后端服务日志和负载均衡器日志。如果后端 GPU 利用率已经打满说明需要扩容如果后端没有报错但响应很慢可能是路由层或网络层问题例如容器网络带宽不足、跨机 KV Cache 传输延迟过大。问题现象可能原因排查方式解决方案nvidia-smi 无法连接驱动驱动与内核不匹配 / 驱动未加载dmesg、lsmod、nvidia-smi在测试环境重装匹配驱动Docker 无法使用 GPU缺少 NVIDIA Container Toolkitdocker info、nvidia-container-cli info安装配置容器运行时首次推理极慢权重加载、引擎构建、未预热查看启动日志、GPU 利用率预热请求或预构建引擎TTFT 高但 GPU 利用率不稳Prefill 和 Decode 混跑互相干扰分阶段监控限制长 Prompt 或做 PD 分离Decode 侧显存不足KV Cache 过大、输出限制过高查看显存监控调低 max_tokens、开启 KV Cache offload接口超时后端打满 / 网络延迟检查后端日志、负载均衡扩容、优化网络、限流降级9. 最佳实践与工程建议不要为了分离而分离。很多团队看到前沿架构很兴奋第一反应就是做 PD 分离、搞异构算力池结果系统复杂度陡增收益却不明显。分离式架构解决的是真实瓶颈而不是概念时髦。建议动手之前先回答一个问题当前推理链路里哪一个环节的资源浪费最严重哪一个环节的延迟或吞吐已经影响到业务如果答案都很模糊先保持单体服务把监控做扎实。建议按“接口稳定、服务独立、流量可路由”的顺序演进。先把模型封装成独立服务保证 API 层稳定再根据监控数据判断是否需要拆阶段最后才是异构资源池化。每一步都要能回滚。如果你的团队刚起步最务实的做法是先从 vLLM 或 Triton Inference Server 这类开源方案入手在单机单卡上把服务化跑通不要一上来就追完整的 PD 分离。推理服务上线后要统一关注四类指标TTFT 反映第一次响应速度TPOTTime Per Output Token或 ITLInter-Token Latency反映生成速度吞吐量反映系统整体处理能力GPU 利用率反映资源使用效率。没有监控数据做基础谈任何架构优化都是拍脑袋。关于安全与凭证管理需要认真强调。NIM 或 NGC 的 API Key、云服务密钥都属于敏感凭证不要直接写死在 Dockerfile、代码或默认环境变量里。生产环境建议使用密钥管理服务容器运行前通过安全渠道注入环境变量。模型服务涉及数据输入输出时还要考虑内容安全和用户隐私合规问题。如果是在团队内部做实验也要遵循最小权限原则不要在共享机器上随意开放 0.0.0.0 监听端口。多模型团队还要建立一套模型版本管理规范。一个推理服务可能同时存在线上稳定版、灰度候选版、废弃旧版三种状态。建议在服务路由层维护模型版本映射表每次模型升级时先切小流量验证再逐步放开最后再下线旧版。不要把模型文件名写得过长建议用规范化的命名例如model-name-version-date方便日志和监控中检索。在写监控时尽量让业务方也能看到模型服务的状态。服务化分离的初衷就是让模型成为标准的基础设施能力因此一线业务开发也应该能通过自助平台了解某个模型的并发量、平均延迟和错误率。一个内部开发者门户式的工具往往比再复杂的底层调度器更能推动团队落地这套架构。10. 总结与延伸学习方向这篇文章的核心判断是NVIDIA GPU 和 Groq LPU 之间的争论只是表象真正值得关注的是它们共同推动的分离式推理架构。无论你用的是 NVIDIA 生态还是计划接入 LPU 类专用推理芯片三种分离思路都会反复出现服务化分离解决的是系统边界问题阶段分离解决的是计算特征冲突问题异构算力分离解决的是成本与延迟平衡问题。从“能跑”到“可编排”是大模型推理基础设施建设绕不开的一步。读到这里你可以先做一个简单的实验回到自己的环境用一个开源模型部署一个标准 API 服务观察一次带长 Prompt 的请求在不同阶段的 GPU 利用率和耗时。拿到数据之后再判断你的业务是否需要做更深入的拆解。如果发现 Prefill 阶段和 Decode 阶段的负载长期严重不均衡下一步就可以去研究 PD 分离如果发现大量短文本请求占用 GPU下一步可以研究异构推理资源对接。需要继续深入了解的方向还包括KV Cache 的管理与 offload、NVIDIA Dynamo 这类面向推理系统的调度框架、多模型网关的设计、以及推测解码这类让解码阶段变快的新技术。芯片选型的争论还会持续但“让一个引擎把请求从头跑到尾”的做法在大规模生产环境里会越来越少。
从GPU到LPU：分离式推理架构如何重塑大模型推理
最近围绕大模型推理的讨论总绕不开两个词NVIDIA GPU 和 LPU。很多人把 LPU 理解成又一种能跑的 AI 芯片于是在各种社区里争论LPU 能不能取代 NVIDIA GPU训练能不能用它既然 Groq 的 LPU 跑 Llama 那么快为什么大厂还在疯狂抢 H100、H200这些问题的答案并不在“芯片参数对比表”里而在一个更值得关注的概念上分离式推理架构。先给一个判断LPU 真正有价值的地方不是它的单卡推理延迟比 GPU 低多少而是它用一套完全不同的硬件设计倒逼行业重新审视一个一直被忽略的问题——大模型推理的各个阶段资源性格根本不是同一种。预填充阶段吃算力解码阶段吃访存带宽控制面和数据面对延迟的要求完全不同通用算力和专用推理引擎各有所长。如果始终用一台服务器、一块 GPU、一个推理进程把请求从头跑到尾那么无论芯片多强系统里必然存在资源浪费。NVIDIA 生态和 Groq LPU 看似在竞争实际上正从不同方向推动同一件事把推理拆开让每一段计算被放到最合适的位置上执行。这篇文章会先讲清楚为什么推理架构会出现“分离”趋势再结合 NVIDIA 的 NIM、Triton、TensorRT-LLM以及 Groq LPU 这类专用推理芯片梳理当前工程上已经成型的三种分离式推理架构服务化分离、阶段分离PD 分离、异构算力分离。读完你不仅能理解这些概念还能照着文中的示例在自己的机器上跑通一个最小可验证的推理服务并对生产环境中是否值得做“分离”有更清晰的判断标准。1. 一次大模型请求里藏着一场“资源性格冲突”要理解分离式推理架构先要理解一次大模型请求内部发生了什么。假设用户输入一段 1000 个 token 的 Prompt要求模型写一篇文章模型的执行过程可以粗略分成两个完全不同的阶段。第一个阶段叫 Prefill预填充。模型要把这 1000 个 token 和权重矩阵做完整的前向计算生成第一个输出 token 所需的中间状态。这个阶段的特点是计算量巨大、并行度极高GPU 的 Tensor Core 可以充分运转属于典型的“算力密集型”任务。用户看到的“首 token 延迟”TTFTTime To First Token主要由这一段决定。第二个阶段叫 Decode解码生成。模型生成第一个 token 后要逐个生成后面的 token每次只基于当前已有的序列预测下一个 token。这个阶段的特点是每次迭代只计算一个 token并行度低但必须反复读取权重和 KV Cache。GPU 的计算单元大量闲置真正卡住系统的是“访存带宽”——很像一个仓库里货物很多但传送带只有一条工人能力再强也只能等着货物送到面前。这也是业内常说的 Memory Wall访存墙。如果把这两个阶段硬塞在同一块 GPU、同一个推理进程里执行会出现一个尴尬的局面一台 8 卡 GPU 服务器可能在 Prefill 阶段算力打满但到了 Decode 阶段整体吞吐被访存卡住GPU 利用率可能掉到很低。反过来为了照顾 Decode 阶段的迭代式生成系统又不敢接太多长 Prompt否则 Prefill 会把资源全部抢走导致正在生成的其他请求全部变慢。更麻烦的是不同业务请求的资源诉求差异很大。一个 100 token 的轻量问答和一个 10000 token 的文档分析在 Prefill 阶段需要的算力差了几十倍一个只要求输出 50 token 的命令行补全和一个需要输出 2000 token 的长文写作在 Decode 阶段占用的时间也完全不同。把这些请求混合到同一个推理引擎里需要调度器不断“错峰”和“抢占”复杂度会越来越高。这说明一个核心问题大模型推理的瓶颈早已不只是“芯片算力不够”而是“一段请求里不同环节的资源需求互相冲突单一引擎无法同时满足”。传统的优化思路是提高单卡算力、加大显存带宽但这相当于在现有的单引擎架构上不停打补丁。另一种思路则激进得多既然 Prefill 和 Decode 资源性格完全不同为什么不把它们拆开分别放在不同的 GPU 池里甚至放在不同的芯片上执行这就是分离式推理架构要回答的问题。2. GPU 与 LPU两条路线同一个趋势在深入三种架构之前有必要先厘清 GPU 和 LPU 的定位差异因为后面很多分离决策都建立在这两个概念上。需要先说明一个事实LPU 并不是 NVIDIA 的产品而是由 Groq 公司设计的 Language Processing Unit语言处理单元。NVIDIA 的主流方案仍是 GPU。把 NVIDIA 和 LPU 放在一起讨论本质上是把“通用 GPU 推理方案”和“专用语言推理芯片方案”放在一起对比。NVIDIA GPU 的优势是通用性和生态。它本质上是一个大规模并行计算设备既支持 FP32、FP64 科学计算也支持 FP16、FP8 深度学习训练和推理。到了 Hopper、Blackwell 架构NVIDIA 加入 Transformer Engine、NVLink、NVSwitch进一步强化了多卡互联和大模型训练能力。但它有一个物理上的痛点显存带宽永远追不上算力的增长速度而且 HBM 的成本和功耗都很高。于是在 Decode 这种访存密集型任务里GPU 经常处于“算得动但喂不饱”的状态。Groq LPU 走的是一条更极端的路线。从公开资料看LPU 没有使用 HBM 高带宽显存而是把大量 SRAM 直接做到芯片附近并用软件定义网络在芯片间通信。这样的好处是推理延迟非常确定不需要像 GPU 那样频繁地把数据从显存搬到计算单元低并发单请求场景下生成的 token 速度可以非常快。代价也很明显SRAM 容量有限不像 GPU 显存那样动辄几十 GB、上百 GB可编程性和通用计算能力远不如 GPU几乎不能用于大模型训练也不适合需要灵活处理各种算子变化的任务。它更像一个针对 Transformer 推理过程做了深度定制的专用 DSP。对比维度NVIDIA GPUGroq LPU设计目标通用并行计算、训练与推理兼顾专用语言模型推理强调低延迟计算核心大规模 CUDA Core / Tensor Core专用推理核心确定性执行存储层次HBM 高带宽显存容量大SRAM 为主容量较小访问延迟低片上通信NVLink / NVSwitch生态成熟软件定义网络芯片间可扩展训练支持支持生态完善基本不支持推理优势高吞吐、支持长上下文、弹性大低并发低延迟、延迟抖动小生态成熟度CUDA、TensorRT-LLM、NIM、HuggingFace 生态独立生态以 Groq API 为主我不建议把 NVIDIA GPU 和 Groq LPU 理解成“谁取代谁”的关系。更准确的理解是GPU 适合当“通才”LPU 这类专用芯片适合当“专科医生”。当系统里同时存在“大批量、长上下文、需要频繁调整模型”的任务以及“小批量、延迟敏感、结构固定”的任务时把它们放在不同芯片上执行本身就是一种异构算力分离的思路。NVIDIA 显然也看到了单一 GPU 引擎处理所有推理请求的局限性。从 NIMNVIDIA Inference Microservices到 Triton Inference Server再到 TensorRT-LLM 和后续的 Dynamo 推理框架NVIDIA 其实一直在做一件事让模型推理从“跑进程”变成“跑服务”把推理过程中的计算、显存、调度、路由逐步解耦方便上层按需编排。这不是 NVIDIA 官方提出的“三种分离式架构”但确实是行业里正在形成的技术主线。3. 分离式架构之一服务化分离——把推理能力变成独立服务第一种分离发生在“模型调用方”和“模型运行后端”之间也就是服务化分离。它解决的问题非常实际如果一个团队要同时维护多个模型不同模型来自不同框架有的是 PyTorch、有的是 TensorRT、有的是 ONNX调用方的业务代码不可能为每个模型单独写一套客户端。在没有服务化分离的传统方式里业务团队通常把模型直接加载进业务进程或者在一个大单体服务里同时管理多个模型实例。这样做有几个隐患模型升级必须跟着业务版本发布风险很大某个模型触发的显存溢出可能拖垮整个服务不同模型对 GPU 的利用率差异很大混在一起难以精细化分配资源模型推理代码变更后还要重新做一遍业务回归测试。NVIDIA NIM 提供了一种更干净的服务化封装把某个模型连同推理后端、预处理、后处理、运行时依赖做成一个容器镜像暴露一个标准化的 OpenAI 兼容 HTTP API。调用方不再关心模型是用 TensorRT-LLM、vLLM 还是其他引擎跑的只要按照统一的 API 格式发送请求就行。每一个 NIM 容器可以独立部署、独立扩缩容、独立更新版本这就把模型推理从业务系统里剥离成了一组可独立运维的微服务。下面用一个最小示例演示服务化分离的思路。以 NVIDIA NIM 的一个 Llama 3 8B Instruct 镜像为例启动一个容器化推理服务# 1. 登录 NVIDIA NGC 容器仓库 # 用户名固定填写 $oauthtoken密码是你在 NGC 生成的 API Key docker login nvcr.io # 2. 启动 NIM 容器 # 注意镜像名称和 tag 以 NVIDIA 官方 NIM 页面发布为准不同时间版本不同 docker run -d --name nim-llama3 \ --gpus all \ -e NGC_API_KEY你的NGC_API_KEY \ -p 8000:8000 \ nvcr.io/nim/meta/llama3-8b-instruct:latest容器启动后会打印日志。看到类似“server started”或者“Uvicorn running on http://0.0.0.0:8000”的信息说明模型已经作为独立服务对外提供能力。然后可以通过任意 HTTP 客户端验证服务是否可用curl -X POST http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: meta/llama3-8b-instruct, messages: [ {role: user, content: 用一句话解释服务化推理} ], max_tokens: 128 }在业务端同样只面对一个标准的 HTTP 接口。如果把多个模型都封装成 NIM 容器网关层还可以根据请求里的 model 字段做路由把不同模型请求分发到不同的后端实例。from openai import OpenAI # 无论后端容器运行的是 Llama、Qwen 还是其他模型 # 客户端配置都保持统一的 OpenAI 兼容格式 client OpenAI( base_urlhttp://localhost:8000/v1, api_keynot-needed # 本地测试时并不真正校验 ) resp client.chat.completions.create( modelmeta/llama3-8b-instruct, messages[ {role: user, content: 解释一下服务化分离的好处} ], max_tokens256, ) print(resp.choices[0].message.content)服务化分离带来的核心变化是模型生命周期和业务生命周期解耦。业务团队发布新功能不需要重新部署模型模型升级或回滚也不影响业务进程。配合 Kubernetes还可以为不同模型设置不同的副本数、不同的 GPU 资源配额、不同的扩缩容策略。模型冷热分离、大模型和小模型分离都可以通过服务编排来做。如果团队暂时使用不了 NVIDIA NIM也可以用 vLLM、Triton Inference Server 或 FastAPI 自己封装。关键在于 API 层是否稳定、模型是否独立部署、是否可以只升级单个模型而不影响其他模块。只要做到这三点本质上就完成了第一种分离。4. 分离式架构之二阶段分离——Prefill 与 Decode 各跑各的第二种分离发生在模型推理流程内部是把 Prefill预填充阶段和 Decode解码生成阶段拆开执行行业内通常叫 PD 分离。它直接回应了本文开头说的“资源性格冲突”。先回顾一下问题。在一个正常的自回归生成请求里第一次前向计算需要处理全部 Prompt token计算量非常大之后开始逐 token 生成每次只做一个 token 的自回归推断。如果不做任何拆分系统必须用同一批 GPU 同时服务这两种负载。当大量长 Prompt 进来时GPU 的算力会被 Prefill 占满当大量短输出请求在 Decode 时GPU 的访存带宽又成为瓶颈。两个阶段的资源需求互相拉扯调度器只能做各种近似优化很难让所有指标都好看。PD 分离的基本思路是把请求的处理流程拆成“先由 Prefill 工作组处理长序列输入再把生成状态交给 Decode 工作组”。Prefill 实例侧重算力可以批量处理很多 PromptDecode 实例侧重吞吐和访存优化专门负责逐 token 生成。二者之间通过 KV Cache 的传输和协调来衔接。这样一来两类实例可以独立扩缩容Prompt 流量大了就扩容 Prefill 实例输出需求大了就扩容 Decode 实例不会再互相拖累。有的读者可能会问这不就是把一个大模型服务拆成了两个 RPC 阶段吗确实它的代价也在这里。KV Cache 在 Prefill 实例上生成后需要转移到 Decode 实例如果两个实例不在同一台机器还要考虑跨节点传输。状态转移的延迟、调度器的复杂度、KV Cache 的显存管理都会比单体服务更复杂。所以 PD 分离并不是所有业务的第一选择它更适合那些“上下文很长、并发很高、对吞吐有要求”的生产环境。而从公开资料看已有不少大模型推理平台在采用类似思路例如 DeepSeek 在技术分享中提到的预填充与解码分离部署就是把不同的 GPU 池分别用于 Prefill 和 Decode。如果你用的是 vLLM最简单的实践方式并不是直接在生产环境配置完整的 PD 分离而是先理解“可以用多个推理实例分担不同负载”这一层。下面是一个简化的多实例部署示意用于演示流量分层的思想# Prefill 实例监听 8001主要接收长 Prompt 请求 python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --port 8001 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 # Decode 实例监听 8002主要接收生成后阶段的请求 python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --port 8002 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9需要提醒的是上面这个示例只是把服务拆成了两个独立实例让入口流量可以按阶段分开真正的 PD 分离还需要打通两个实例之间的 KV Cache 传输和状态协调不同版本的 vLLM 对 PD 分离的支持程度不同具体配置以你使用的版本官方文档为准。如果你想在生产环境做 PD 分离还需要关注三个关键组件KV Cache 传输方式、调度策略、故障恢复机制。PD 分离的本质是把“一次完整前向推理”从单一黑盒变成可编排流水线。对于工程团队判断是否要做 PD 分离建议先观察两个指标一是 GPU 在 Decode 阶段的实际利用率是否长期偏低二是长 Prompt 请求和短请求混部时TTFT 和单 token 生成速度是否频繁波动。只有当这些问题明显影响业务时才值得引入阶段分离因为它的复杂度会让运维成本上一个台阶。5. 分离式架构之三异构算力分离——GPU 与 LPU 类专用芯片协同第三种分离不是在软件流程里拆阶段而是在硬件资源层做分工把不同特征的计算放到不同芯片上执行。这是 LPU 这类专用推理芯片出现后最值得关注的一种架构变化。我常用一个类比来理解这种分离全科医生和专科门诊。GPU 是全科医生什么都能看训练模型、微调、跑各种框架、处理长上下文都能胜任LPU 这类专用推理芯片更像是某个专科门诊它对语言模型的推理过程做了深度定制在特定的低延迟生成场景下很有优势但你不会派它去做大模型训练也不会拿它来跑复杂的科学计算。在真实的推理系统里异构算力分离通常表现为NVIDIA GPU 集群负责训练、微调、中长期批量任务Groq LPU 或 GPU 中的专用推理实例负责对延迟极其敏感的在线生成任务CPU、DPU 负责数据预处理、网络卸载和部分控制逻辑。上层有一个统一的路由层根据请求特征决定把它送到哪一类算力。假设你已经拥有了一个可以同时管理 GPU 池和 LPU 池的推理网关可以用策略引擎区分请求。下面是一个简化的路由策略示例def route_request(request): # 离线批量任务优先走 GPU 大吞吐池 if request.get(task_type) batch_offline: return gpu_batch_pool # 延迟要求小于 200ms 且输出长度可控走 LPU 低延迟池 if request.get(latency_sla_ms, 1000) 200 and request.get(max_tokens, 4096) 2048: return lpu_latency_pool # 长上下文或复杂多轮对话走 GPU 长文本池 if len(request.get(messages, [])) 10 or request.get(long_context): return gpu_long_context_pool # 默认走成本较低的通用服务池 return gpu_shared_pool上面的代码只是工程示意不是任何厂商的官方标准但它点出了异构算力分离的关键路由层需要知道每个请求的延迟要求、上下文长度、输出长度、业务类型再结合不同算力池的成本和实时状态做调度。这个路由层本身也是前面讲的“服务化分离”的延伸——先有稳定可调用的独立服务才能在服务之上按策略做分发。异构算力分离最大的收益是成本与延迟的平衡。并不是所有请求都需要最强的 GPU 来跑简单指令、固定格式抽取、短文本分类这些任务放在专用推理芯片或规格较小的推理实例上可能又快又便宜复杂的长文本生成、Agent 多轮规划、需要频繁调用工具的任务再交给大算力 GPU。这样可以把有限的 GPU 资源集中留给真正复杂的模型和请求。但异构算力分离也有明显的适用边界。首先不同芯片的量化格式、算子和部署方式不同把一个模型从 GPU 迁到 LPU 并不是几行代码能完成的需要额外工程适配。其次引入异构资源后监控、告警、日志链路会变长排障成本上升。最后也是最重要的一点如果请求复杂性很高、模型频繁升级异构部署会拖慢迭代速度。我的建议是适合异构分离的团队通常已经有比较稳定的模型版本和清晰的服务分层如果模型还在快速迭代阶段先别急着把算力拆得太散。6. 三种分离之间的关系从“能跑”到“可编排”理解了三种分离之后还需要把它们放在同一张图里看因为它们不是三个并列的技术选项而是分别作用于系统的不同层次。服务化分离属于“接口层”的分离它解决的是模型与应用之间的耦合问题让模型变成可以独立部署、独立升级的服务。这个分离一旦做好上层做流量路由、灰度发布、多模型切换都会顺手很多。阶段分离PD 分离属于“流水线层”的分离它解决的是同一个模型请求内部不同阶段对资源需求冲突的问题。异构算力分离则属于“资源层”的分离它关注的是多个模型、多个请求之间如何分配到不同的芯片和实例上。用一个现实中的部署演进来看这三种分离之间的关系一开始你在一台 GPU 服务器上加载了一个模型通过一个 Python 脚本对外提供预测这是“能跑”阶段。接着你把这个模型封装成独立的 HTTP 服务业务代码通过 API 调用这是完成了服务化分离。再往后你发现长 Prompt 请求和短输出请求混在一起时性能不稳定于是把服务拆成 Prefill 池和 Decode 池让请求在两个阶段之间流转这是完成了阶段分离。最后你发现自己手里有 GPU也有专用推理资源部分简单任务完全可以用专用芯片跑于是你在网关层加了一个路由策略把请求分流到不同后端这是完成了异构算力分离。可以看到三种分离是渐进叠加的关系。没有服务化分离后面的阶段分离和异构分离都无处挂载因为上层调度器需要一套稳定的接口去操作后端没有阶段分离异构分离也只能停留在“把整个模型搬到另一类芯片”的粗粒度层面没法针对同一模型的不同阶段做精细化分流。谁先做、谁后做取决于当前最痛的问题在哪一层。分离维度解决的主要矛盾典型实现建议落地顺序服务化分离业务与模型部署耦合NIM、Triton、vLLM 服务化封装先做阶段分离Prefill 与 Decode 资源冲突PD 分离、异构推理框架第二步异构算力分离不同请求成本与延迟不平衡GPU 池 LPU/专用实例 路由层第三步生产环境真正难的往往不是在某一个维度上做到极致而是要把三个维度的能力组合成一个可观测、可灰度、可回滚的推理系统。例如采用 NIM 后不同模型服务可能由不同镜像和不同后端生成统计口径不一致这时需要监控层对服务做统一的数据采集做 PD 分离后KV Cache 的传输和状态同步是否正常需要新的监控项做异构分离后同一个请求可能在不同资源池间跳转调用链追踪和计费逻辑也要随之调整。每一步分离都要有配套的工程能力跟上。7. 实践在自己机器上跑通一个服务化推理入口理论讲得再多不如跑通一个最小系统。下面用一个更通用的示例帮助你在有 NVIDIA GPU 的机器上启动一个服务化推理入口。之所以用 vLLM 而不是直接使用 NVIDIA NIM 镜像是因为 vLLM 面向社区更开放不需要企业级 NGC API Key适合作为理解服务化分离的入门工具。环境准备方面你需要一台安装了 Ubuntu 或 CentOS 的 Linux 机器最好带一块 NVIDIA GPU显存建议至少 16GB这样可以运行 7B 到 13B 参数级别的模型。操作系统、NVIDIA 驱动、CUDA 版本的组合请以实际环境为准本文示例重点是通用流程。先确认 GPU 驱动是否正常输入命令lspci | grep -i nvidia nvidia-smi如果nvidia-smi正常输出 GPU 型号、驱动版本、显存信息说明驱动环境可用。如果你是第一次在 Ubuntu 上安装 NVIDIA 驱动建议多留意驱动与内核版本的匹配问题这也是常见的入门坑。然后创建 Python 虚拟环境并安装 vLLMpython3 -m venv venv source venv/bin/activate pip install --upgrade pip pip install vllm安装完成后选择一个你能够下载的开源模型。这里以 Qwen2.5-7B-Instruct 为例。如果你的机器无法直接访问 Hugging Face可以换成 ModelScope 上可下载的模型或提前配置镜像源。启动服务后python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --port 8000 \ --max-model-len 8192 \ --gpu-memory-utilization 0.8启动日志如果出现“Starting vLLM API server”以及监听地址说明服务已经运行。vLLM 默认也会暴露一份/health或/v1/models接口可以用 curl 检查curl http://localhost:8000/v1/models成功后会返回一个 JSON包含当前部署模型的 ID 和元数据。如果这一步看到模型信息说明你已经把模型封装成了一个标准的推理服务。接下来模拟业务侧调用写一个 Python 脚本from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keynot-needed, ) resp client.chat.completions.create( modelQwen/Qwen2.5-7B-Instruct, messages[ {role: system, content: 你是一名擅长解释技术的工程师。}, {role: user, content: 为什么大模型推理需要服务化部署} ], max_tokens256, ) print(resp.choices[0].message.content)运行脚本后如果能正常打印结果说明你的调用方已经完全不再关心模型内部运行逻辑只依赖服务的 HTTP 接口。这也是第一种分离架构的直观体感。如果一次请求处理时间特别长不要先怀疑代码先检查模型加载日志和 GPU 资源占用。还可以在另一台机器上用同样的 Python 代码访问这台服务器的 8000 端口只要网络策略允许就会发现推理能力已经被网络 API 解耦这本质上就是微服务化的第一步。8. 常见问题与排查方法nvidia-smi报错“couldnt communicate with the NVIDIA driver”是刚接触 NVIDIA GPU 时最容易遇到的问题。这种情况通常不是硬件坏了而是驱动和当前内核版本不匹配或者驱动安装后没有正确加载。先用dmesg | grep -i nvidia查看内核日志再用lsmod | grep nvidia检查模块是否加载。对于具体驱动安装建议不要在业务服务器上直接操作而是先在测试环境验证驱动与 CUDA 的兼容组合。Docker 启动 GPU 容器时报错“could not select device driver with capabilities: gpu”原因是宿主机缺少 NVIDIA Container Toolkit。需要在宿主机安装并配置好 nvidia-container-runtime然后重启 Docker 才能让容器使用 GPU。模型第一次推理耗时很长往往是正常的。服务启动时只是加载模型权重还没完成预热有些推理后端会在首次请求时构建优化引擎例如 TensorRT-LLM 需要把模型编译成 TensorRT Engine这个过程可能需要几分钟甚至更久。建议在服务上线前先发一个预热请求或者提前构建好引擎。TTFT 很高但 GPU 利用率波动很大可能不是单实例问题而是 Prefill 请求和 Decode 请求混跑互相争抢资源。先通过监控拆分两类请求的耗时如果确实存在互相干扰再考虑做 PD 分离或在服务入口限制长 Prompt 请求的数量。PD 分离后 Decode 侧频繁报显存不足要检查 KV Cache 的容量和调度策略。KV Cache 是影响并发上限的核心因素输出 token 越长占用的显存越多。可以适当降低单请求最大输出长度或为 Decode 实例分配更多 GPU必要时使用 KV Cache offload 技术把不常用状态迁移到 CPU 内存。长并发场景返回 502 或超时优先查看后端服务日志和负载均衡器日志。如果后端 GPU 利用率已经打满说明需要扩容如果后端没有报错但响应很慢可能是路由层或网络层问题例如容器网络带宽不足、跨机 KV Cache 传输延迟过大。问题现象可能原因排查方式解决方案nvidia-smi 无法连接驱动驱动与内核不匹配 / 驱动未加载dmesg、lsmod、nvidia-smi在测试环境重装匹配驱动Docker 无法使用 GPU缺少 NVIDIA Container Toolkitdocker info、nvidia-container-cli info安装配置容器运行时首次推理极慢权重加载、引擎构建、未预热查看启动日志、GPU 利用率预热请求或预构建引擎TTFT 高但 GPU 利用率不稳Prefill 和 Decode 混跑互相干扰分阶段监控限制长 Prompt 或做 PD 分离Decode 侧显存不足KV Cache 过大、输出限制过高查看显存监控调低 max_tokens、开启 KV Cache offload接口超时后端打满 / 网络延迟检查后端日志、负载均衡扩容、优化网络、限流降级9. 最佳实践与工程建议不要为了分离而分离。很多团队看到前沿架构很兴奋第一反应就是做 PD 分离、搞异构算力池结果系统复杂度陡增收益却不明显。分离式架构解决的是真实瓶颈而不是概念时髦。建议动手之前先回答一个问题当前推理链路里哪一个环节的资源浪费最严重哪一个环节的延迟或吞吐已经影响到业务如果答案都很模糊先保持单体服务把监控做扎实。建议按“接口稳定、服务独立、流量可路由”的顺序演进。先把模型封装成独立服务保证 API 层稳定再根据监控数据判断是否需要拆阶段最后才是异构资源池化。每一步都要能回滚。如果你的团队刚起步最务实的做法是先从 vLLM 或 Triton Inference Server 这类开源方案入手在单机单卡上把服务化跑通不要一上来就追完整的 PD 分离。推理服务上线后要统一关注四类指标TTFT 反映第一次响应速度TPOTTime Per Output Token或 ITLInter-Token Latency反映生成速度吞吐量反映系统整体处理能力GPU 利用率反映资源使用效率。没有监控数据做基础谈任何架构优化都是拍脑袋。关于安全与凭证管理需要认真强调。NIM 或 NGC 的 API Key、云服务密钥都属于敏感凭证不要直接写死在 Dockerfile、代码或默认环境变量里。生产环境建议使用密钥管理服务容器运行前通过安全渠道注入环境变量。模型服务涉及数据输入输出时还要考虑内容安全和用户隐私合规问题。如果是在团队内部做实验也要遵循最小权限原则不要在共享机器上随意开放 0.0.0.0 监听端口。多模型团队还要建立一套模型版本管理规范。一个推理服务可能同时存在线上稳定版、灰度候选版、废弃旧版三种状态。建议在服务路由层维护模型版本映射表每次模型升级时先切小流量验证再逐步放开最后再下线旧版。不要把模型文件名写得过长建议用规范化的命名例如model-name-version-date方便日志和监控中检索。在写监控时尽量让业务方也能看到模型服务的状态。服务化分离的初衷就是让模型成为标准的基础设施能力因此一线业务开发也应该能通过自助平台了解某个模型的并发量、平均延迟和错误率。一个内部开发者门户式的工具往往比再复杂的底层调度器更能推动团队落地这套架构。10. 总结与延伸学习方向这篇文章的核心判断是NVIDIA GPU 和 Groq LPU 之间的争论只是表象真正值得关注的是它们共同推动的分离式推理架构。无论你用的是 NVIDIA 生态还是计划接入 LPU 类专用推理芯片三种分离思路都会反复出现服务化分离解决的是系统边界问题阶段分离解决的是计算特征冲突问题异构算力分离解决的是成本与延迟平衡问题。从“能跑”到“可编排”是大模型推理基础设施建设绕不开的一步。读到这里你可以先做一个简单的实验回到自己的环境用一个开源模型部署一个标准 API 服务观察一次带长 Prompt 的请求在不同阶段的 GPU 利用率和耗时。拿到数据之后再判断你的业务是否需要做更深入的拆解。如果发现 Prefill 阶段和 Decode 阶段的负载长期严重不均衡下一步就可以去研究 PD 分离如果发现大量短文本请求占用 GPU下一步可以研究异构推理资源对接。需要继续深入了解的方向还包括KV Cache 的管理与 offload、NVIDIA Dynamo 这类面向推理系统的调度框架、多模型网关的设计、以及推测解码这类让解码阶段变快的新技术。芯片选型的争论还会持续但“让一个引擎把请求从头跑到尾”的做法在大规模生产环境里会越来越少。
