vLLM 与大模型推理平台：部署、职责与选型

部署一个模型通常从推理引擎开始。vLLM 部署首先要确认驱动、GPU、Python 和安装包是否兼容，再验证一个小模型能否完成请求。模型数量、团队数量或请求流量增加后，模型发布、容量分配和请求路由需要统一管理，此时引入平台层；选型时先列出需要解决的具体问题，再检查候选系统承担哪些职责。本文聚焦 Linux 上的 NVIDIA GPU 路线，不提供缺少同等条件的 CPU/GPU 性能比较。

单引擎部署：以 vLLM 为例

核对硬件和软件边界

2026-09-13 查阅的 vLLM GPU 安装文档列出 Python 3.10—3.13，NVIDIA 路线要求计算能力至少 7.5。具体量化格式和内核还可能有更严格的硬件要求。旧版安装条件不能直接用于新版本。

bash4 行

uname -m
nvidia-smi
python3 --version
df -h

nvidia-smi 显示的 CUDA 兼容信息与环境实际安装的 CUDA Toolkit 版本需要分别核对。预编译包与 PyTorch、CUDA 的组合存在二进制兼容约束，使用独立环境可减少已有依赖造成的冲突。

显存预算包括权重、KV Cache 和运行时开销。权重能放进显存，只完成了一项容量检查；上下文长度、并发和并行配置会继续消耗空间。

安装并保存依赖快照

从已核对的发布说明选择一个确切版本，设置 VLLM_VERSION 后安装。Python 3.12 是本文环境示例。安装后验证三个点：vllm --version 输出、requirements-resolved.txt 生成、PyTorch 能识别 GPU。

bash6 行

: "${VLLM_VERSION:?设置已核对的 vLLM 版本号}"
uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install "vllm==$VLLM_VERSION"
uv pip freeze > requirements-resolved.txt
vllm --version

驱动正常但 PyTorch 无法识别 GPU 时，优先检查安装包和运行环境：

bash1 行

python -c 'import torch; print(torch.__version__); print(torch.version.cuda); print(torch.cuda.is_available())'

模型文件也需要固定 revision。先下载到独立目录，记录权重、tokenizer 和配置文件的来源及版本，再通过目录路径加载，减少之后远端文件变更带来的差异。

启动最小服务

下面绑定本机回环地址，只供同一主机上的客户端验证。设置 MODEL_DIR 指向已下载且受该版本支持的指令模型目录。

bash6 行

: "${MODEL_DIR:?设置已核对的本地模型目录}"
vllm serve "$MODEL_DIR" \
  --host 127.0.0.1 \
  --port 8000 \
  --served-model-name local-model \
  --max-model-len 2048

同一条部署的 GPU 型号、驱动、vLLM 版本与模型 revision 要保持一致；升级前先在目标组合上做一次故障注入与回滚演练，再据此调整版本卡与容量参数。

参数以安装版本的 vllm serve --help 和命令文档为准。2048 是演示用上下文上限，需要小于模型支持范围并适合现场显存。

另开终端验证模型清单和完整请求：

bash4 行

curl --fail-with-body http://127.0.0.1:8000/v1/models
curl --fail-with-body http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"local-model","messages":[{"role":"user","content":"用一句话解释 DNS。"}],"max_tokens":64,"stream":false}'

清单成功而生成失败，检查 chat template、模型架构、参数与实际输入长度。通过一个请求只能确认最小调用链路；上线前还需鉴权、流量控制、TLS、监控和过载处理。

对照现象定位失败

现象	可能涉及的层次	第一项检查
import 或动态库错误	包、PyTorch、CUDA 组合	安装版本、解析依赖和加载库路径
GPU 不可见	驱动、容器设备映射、环境变量	宿主机与运行环境分别检测
加载权重时 OOM	权重精度和并行布局	模型大小、精度和每卡实际分配
请求增多后 OOM/抢占	KV 容量和上下文分布	请求长度、并发、KV 指标
首段响应很慢	排队、prefill、模型初始化	客户端 TTFT 与服务端阶段耗时

先保存启动日志和失败请求，再一次调整一个变量。直接提高显存使用比例可能减少安全余量；缩短上下文或限制并发会改变服务容量和使用范围，需要在结果中记录。

从可调用走向可维护

把模型 revision、vLLM 版本、驱动、GPU、启动参数和请求样本保存为版本卡。下一步按公平测量文章固定工作负载，记录延迟分布和 SLO goodput。固定工作负载的记录为下文验证平台候选系统提供复用基础。

平台层：职责、选型与验证

把三类调度分开观察

当模型、团队或流量规模增加，平台层把引擎之外的调度职责集中起来。先把三类调度分开观察，可以避免把管理能力与请求执行能力混为一谈。

层次	决策对象	主要输入	典型失败
资源放置	副本、GPU 和节点	资源申请、拓扑、配额、节点状态	Pod Pending、跨卡拓扑不合适
请求路由	一次请求交给哪个副本	排队、模型版本、缓存位置、负载	热点、错误路由、排队超时
引擎执行	一轮处理哪些序列和 Token	KV 容量、上下文长度、执行预算	显存不足、抢占、生成延迟增加

表格用于分析责任边界，具体产品可能覆盖多层。一个控制器能创建 GPU Pod，只能说明它管理工作负载；KV 感知路由还需要缓存状态、路由策略和失效处理。详细机制见三层调度。

候选项目从哪里开始核对

以下是一手项目入口和阅读问题，供整理候选清单使用。各项目的功能状态与兼容矩阵需要绑定具体 release，不能按名称推断全部支持同一组能力。

项目	阅读重点	验证问题
NVIDIA Dynamo	分布式推理、路由与 KV 数据传输	选用后端、传输库和控制组件是否属于同一支持组合？
llm-d	Kubernetes 上的分布式推理与请求调度	Gateway、调度插件和引擎之间如何交换状态？
Kthena	模型服务编排与路由	发布对象、路由规则和扩缩容由谁更新？
OME	模型推理服务管理	模型规格、运行时和硬件如何匹配？
AIBrix	推理服务基础设施	缓存、路由和伸缩组件的兼容范围是什么？
KServe	模型服务 API 与运行时集成	选定部署模式提供哪些能力、依赖哪些组件？
GPUStack	GPU 资源与模型服务管理	异构后端、模型格式和部署方式是否经过目标环境验证？

原材料还涉及 RoleBasedGroup 一类分组工作负载抽象。组内实例创建、就绪和重建是一项独立职责，需核对实际项目与 CRD 版本；本文不保留来源和版本无法一一对应的部署 YAML。

三条数据路径决定运维复杂度

请求路径是客户端、网关、路由器到引擎；控制路径负责发布、扩容和状态协调；模型文件与 KV 状态构成另一条数据路径。后两条路径故障时，进程可能仍存活，但请求已经无法完成。

评审架构图时标出每条边传输的内容、超时、重试以及所有者。例如模型副本扩容完成后，还需加载权重、完成必要初始化并通过就绪检查，才适合加入流量池。Kubernetes 的容器启动时间不能直接当作模型服务冷启动时间。

P/D 分离还引入 KV 传输与双资源池容量问题。长输入场景可能获益，传输时间或池间碎片也可能抵消收益。判断条件见P/D 分离决策文章。

用同一工作负载验证候选系统

固定模型 revision、精度、硬件拓扑、输入输出长度分布、到达率和缓存状态。先跑单副本基线，再增加一个平台能力，避免同时更换引擎、路由和并行方式。

除了吞吐，还记录 TTFT、TPOT/ITL、端到端延迟、错误率与 SLO 内完成的请求数。对用户任务，另测答案质量和任务成功率。统一字段见工作负载模板。

至少验证四种失败：副本退出、扩容时权重下载失败、路由状态滞后、客户端中途取消。检查失败请求是否被重复执行、容量能否回收，以及新请求何时恢复。这些结果比未注明环境的项目排行榜更能支持部署决定。验证步骤：先跑单副本基线并保存指标，再逐项加入失败注入，对照同一份日志与时间线核对恢复点。

何时保留简单架构

单模型、单节点、流量稳定且团队能维护现有部署时，可以先用引擎加网关建立基线。只有遇到明确的多租户、弹性或分布式需求，再引入相应控制组件。每增加一个组件，都要为它定义状态存储、升级方式和故障恢复责任。

本文提供选型方法与项目入口，候选产品的对比与来源边界见 llm-d 与 Dynamo 专题。

← 返回文章