NVIDIA NIM、vLLM 与 TGI 怎么选？支持矩阵、压测与迁移指南

直接结论：如果你需要 NVIDIA 已验证的容器、硬件 Profile、企业生命周期和集成健康管理，先评估 NIM；如果团队能自行承担版本、组合与回归，并希望最快获得开放模型和引擎能力，优先评估 vLLM；如果已有 TGI 生产系统，可以继续维护并制定迁移窗口，但截至 2026-09-25，Hugging Face 官方已把 TGI 标为 maintenance mode，因此不宜再把它当作默认的新平台起点。

三者并不是三个完全独立、只比速度的“同类产品”。NVIDIA 当前文档把 NIM LLM/VLM 描述为围绕 vLLM 后端的企业编排层，增加经过验证的配置、Profile、健康、观测与安全能力；vLLM 是快速演进的开放推理引擎；TGI 是 Hugging Face 的既有推理服务工具，但维护状态改变了长期选型权重。本文核验的是公开文档与可复现的验收方法，没有在本站 GPU 上跑三套真实模型，因此不会给出虚构的吞吐冠军。

先理解三者的关系：NIM 不是另一套完全无关的引擎

NVIDIA NIM 当前架构文档明确说明，NIM LLM/VLM 的核心推理后端是 vLLM，外层代理和编排组件负责启动、Profile、健康、路由、TLS、指标与企业能力。选择 NIM 与选择裸 vLLM，常常不是“两个内核谁更快”，而是要不要购买和接受一套经过验证、带约束的交付与生命周期。即使底层引擎接近，镜像版本、编译、Profile、权重格式和默认参数不同，结果也不能直接外推。

model-specific NIM 面向经过策划的模型、权重和优化 Profile；model-free NIM 允许运行时配置模型，扩大了覆盖面，但官方支持矩阵也明确写出：未显式验证的模型仍取决于容器内 vLLM 或 SGLang 后端版本是否支持。换句话说，“model-free”不是“任何模型都由 NVIDIA 验证”，文章和采购文件必须保留这条边界。

vLLM 提供 OpenAI 兼容服务、健康、负载与 Prometheus 指标等接口，也提供在线服务 benchmark 命令。它让团队更直接控制引擎和参数，适合需要快速适配新架构、愿意读发行说明并维护回归集的组织。开放与快速并不自动等于低成本：版本升级、CUDA 组合、镜像、漏洞修复和夜间故障仍需有人负责。

TGI 仍有 launcher、多后端和既有部署文档，但官方首页当前明确提示项目进入维护模式，并推荐转向后续生态方案。维护模式不表示现有服务立刻失效，也不能从这一行文字推断安全停止更新；它证明的是产品生命周期信号已经变化。新项目应把迁移能力和长期维护列为硬门槛，现有项目则应先盘点依赖再迁移。

一张表先做首轮分流

这张表只做首轮分流，不能代替目标模型的支持矩阵和同条件压测。若硬门槛冲突，例如目标 GPU 不受支持、模型许可不允许用途或关键接口缺失，应直接保持候选，而不是用其他维度的高分抵消。

如何读 NIM 支持矩阵，避免把“能跑”写成“验证过”

先锁定 NIM 版本，再记录模型、Profile、精度、张量并行和 GPU。支持矩阵中的 verified hardware 与 model profile 是特定组合证据，不可拆开拼接。例如某张 GPU 出现在 model-free NIM 列表，并不说明所有模型都能在该卡显存中启动；官方页面会对部分模型写出额外显存要求。部署前还要核对驱动、容器运行时、存储、网络和账号凭证。

选择 model-specific NIM 时，优势是组合空间更小、权重和配置更明确；代价是只能在相应 offering 的发布与支持边界内工作。选择 model-free NIM 时，模型覆盖更灵活，但应把底层 vLLM/SGLang 版本、模型自定义代码和未验证组合写入风险登记。两者都不能省略质量回归，因为厂商验证主要不等于你的业务任务正确。

如何评估 vLLM：自由度的另一面是回归责任

vLLM 当前服务文档提供多种生成、池化、评分和监控入口，但具体模型是否支持某个功能，仍要看模型类型、聊天模板、解析器与版本。升级时锁定镜像 digest 和包版本，先用最小模型验证 CUDA 与设备可见性，再加载目标模型。一次只改变引擎、权重、量化或调度中的一层，否则即使性能变化也无法归因。

利用官方 vllm bench serve 时，保存 backend、model、dataset、input length、output length、request rate 和 prompt 数量。不要只保存终端最后一行。把原始 JSON、错误请求、服务器指标、GPU 记录和客户端时钟一起归档，才能解释某个高吞吐是否由短输出、拒绝请求或更高尾延迟换来。

TGI 进入维护模式后，现有系统怎么做

第一步不是立即停机，而是建立事实清单：当前 TGI 版本、镜像 digest、模型与量化、GPU 后端、启动参数、扩缩容、指标、客户端协议、已知补丁和负责团队。第二步冻结无回执的大升级，确认官方安全与维护入口。第三步用真实流量样本建立迁移回归，选择 vLLM、NIM 或其他候选时保持权重、质量门槛与硬件尽量一致。

迁移可以采用影子流量、离线重放或小租户灰度。若请求会调用外部工具，影子执行必须关闭副作用或使用沙箱。客户端虽然都可能使用 OpenAI 风格接口，仍需验证流式事件、错误体、停止条件、工具 JSON、token 统计和取消语义。只有兼容性、质量、容量和回滚全部过线，才逐步撤销 TGI 流量。

同条件压测：先固定不可比较的变量

性能对比前建立实验合同：同一模型 revision、同一权重或等价精度、同一 tokenizer、同一 GPU 与功率策略、同一驱动、同一输入输出分布、同一到达率和同一质量门槛。若 NIM 使用专有 Profile、vLLM 使用另一量化，而 TGI 无法加载该格式，就把结果写成“各自最佳可用配置”，不要写成纯引擎性能比较。

至少分四个场景：短输入短输出的交互请求、长输入短输出的摘要或 RAG、短输入长输出的生成、长输入长输出的极限压力。每个场景从低到高增加并发，记录 TTFT、inter-token latency、端到端 P50/P95/P99、请求吞吐、token 吞吐、成功率、错误类型、显存峰值和功耗边界。达到预设延迟或错误门槛后停止继续放大。

三十项选型与上线检查

以下每一项都要形成可定位回执。表格第三列给出最小证据格式，不要求公开敏感原文。使用受控路径、摘要与访问权限替代把密钥或客户数据复制到报告。

独立任务资产：用约束而非品牌印象生成试验顺序

本文配套保存 select-inference-stack.py。输入是否必须企业支持、是否需要快速新模型、是否已有 TGI、目标是否为 NVIDIA GPU、团队能否自行维护和是否要求已验证 Profile，脚本先检查硬门槛，再给出“先测哪一条路线”的说明。它不连接 GPU、不测性能，也不代替采购或许可判断。

{
  "must_have_enterprise_lifecycle": true,
  "need_fast_new_model_support": false,
  "existing_tgi_deployment": false,
  "nvidia_gpu_target": true,
  "team_can_own_engine_upgrades": false,
  "require_validated_profile": true
}

固定夹具的预期结果是先评估 NIM，并同时要求查当前支持矩阵；另一个夹具若已有 TGI、团队可维护且需要快速模型支持，会建议保持现网、并行评估 vLLM 迁移。输出只是试验顺序，不是“总分最高就采购”的自动决策。

推荐的三阶段试验设计

阶段一：兼容与质量

每套方案先用小流量验证启动、接口、聊天模板、结构化输出、工具参数、长输入和拒绝路径。保存成功与失败样本，不计算速度冠军。某方案如果不能满足关键功能或质量门槛，停止进入成本比较，并记录被淘汰的具体组合。

阶段二：容量与故障

对通过质量门槛的候选逐档增加请求率，观察排队、TTFT、生成速度、吞吐、错误和显存。然后注入模型仓库不可用、节点重启、GPU 错误、客户端取消和超长输入，检查服务是否正确拒绝、恢复和留证。

阶段三：灰度与运营

使用低风险租户或影子流量，持续观察质量代理、人工复核、延迟、成本与安全事件。安排值班人员完成一次升级和一次回滚，计算真实人工时间。只有目标团队能够解释告警并按时恢复，方案才算可运营。

常见错误结论

• “NIM 一定比 vLLM 快”：NIM 当前后端就是 vLLM，具体差异来自版本、Profile、权重、编译与配置；必须同条件测。
• “vLLM 开源所以总成本最低”：许可不等于零运营成本，升级、回归、安全和故障责任仍由团队承担。
• “TGI 维护模式所以今天不能用”：官方状态是生命周期信号，不是本站对每个部署安全性的测试结论。
• “OpenAI compatible 所以客户端不用验收”：兼容接口不保证全部参数、事件、错误与工具语义一致。
• “公开 benchmark 数字可以直接采购”：不同硬件、模型、长度、精度和负载不可直接比较。
• “HTTP 200 说明服务健康”：可达不证明模型加载、质量、权限、容量或下游依赖正常。

把官方文档变成可执行核对项

NVIDIA NIM：先看介绍、架构，再查目标版本支持矩阵

NVIDIA NIM LLM/VLM 介绍用于确认当前 offering、model-specific 与 model-free 的定位，以及官方如何描述验证容器和企业生命周期。不要只截取“production-ready”作为采购结论；同一页面也要求继续查看具体支持矩阵、故障排查和发行说明。把页面版本、访问日期和目标容器版本一起保存。

NIM 当前架构文档用于确认代理、nimlib、Profile 管理与 vLLM 后端的责任边界。它能证明公开架构如何组成，不能证明你的模型在目标硬件上更快。压测报告应记录代理端口、后端版本、最终 Profile 与请求路径，避免把额外代理开销或默认配置差异错误归因于推理内核。

NIM 支持矩阵用于逐项核对模型、精度、张量并行、LoRA 与已验证 GPU。保存匹配行而不是只保存页面首页。若模型只由底层后端支持、没有显式 validated 行，应在决策单标为“可试验、未获该组合验证”，并安排更完整的稳定性与升级回归。

model-free NIM 文档解释运行时模型来源和 Profile 组合。固定旧版本链接有助于复现某次决定，但正式上线仍要打开当前版本，比较命令、环境变量和支持边界是否变化。不要把旧文档命令未经验证复制到新镜像。

vLLM：接口文档和 benchmark 文档解决的是两个问题

vLLM 官方仓库中的 OpenAI-compatible server 文档用于列出服务端点、健康、负载、指标和具体参数。验收表应标记每个业务使用的字段是否支持、默认值是什么、错误时返回什么。文档存在某个端点，只证明该版本公开描述了接口；模型类型、解析器与客户端组合仍要实际调用。

vLLM 官方仓库中的 benchmark CLI 文档用于固定数据集、输入输出长度、请求率、样本数和后端标签。运行时同时保存服务端启动参数和监控快照。若只留下聚合数字，日后无法判断提升来自引擎、缓存、短输出、失败请求还是硬件功率状态。

Hugging Face TGI：维护状态、启动参数与后端覆盖要分开读

TGI 文档首页是维护状态的直接证据，也是本文官方截图来源。页面状态会变化，迁移工单应保存日期和必要局部截图。维护模式影响长期路线，但现有系统是否继续运行，还取决于安全修复、依赖、团队能力和业务恢复要求。

TGI launcher 参数文档用于还原当前启动配置。迁移前导出模型、分片、批处理、最大 token、量化、缓存和端口等参数，再映射到候选引擎；不要只把容器名换掉。未知参数应进入差异清单，由真实请求验证，而不是默认忽略。

TGI 多后端文档用于确认硬件与后端路线。它不证明所有后端具有相同功能和性能。若现网依赖特定硬件或内核，先确认迁移候选能否满足精度、并行、量化与监控，再安排双栈窗口。

从一次试验到长期运营：四类回执不能缺

对象回执保存模型 revision、权重摘要、tokenizer、镜像 digest、引擎版本、驱动、GPU、配置和许可入口；质量回执保存任务集版本、风险切片、失败样本、重复次数和人工复核；运行回执保存负载生成、延迟、吞吐、错误、资源、冷启动和故障注入；控制回执保存身份、网络、日志、灰度、停止条件、批准与回滚演练。四类证据互相补充，任何一类都不能替代其他三类。

回执还要写出“能证明什么”和“不能证明什么”。支持矩阵能证明公开验证范围，不能证明业务质量；benchmark 能证明特定条件下的观测，不能外推不同模型和硬件；健康检查能证明端点状态，不能证明回答正确；官方维护提示能证明生命周期信号，不能证明现有系统立即不安全。保持这些边界，才能避免把发现证据包装成生产结论。

最终建议

新建 NVIDIA GPU 企业平台、希望减少未经验证组合时，从 NIM 支持矩阵和条款开始；研发平台或模型变化快、已有强平台团队时，从 vLLM 的目标版本开始；现有 TGI 则先保留稳定服务，建立兼容与迁移回归，不再无计划扩大锁定。任何路线都要经过相同模型、相同质量门槛、相同负载与故障条件的试验。

继续准备容量时，可查看KV cache 容量与并发验收、CUDA 驱动与框架兼容检查、模型部署灰度与回滚验收以及本地大模型显存估算。这些页面分别处理容量、运行时、发布治理与硬件预算，不与本文的推理栈选择意图重叠。

来源、核验日期与边界

本文于 2026-09-25 重新打开 NVIDIA NIM LLM/VLM 介绍、架构、支持矩阵与 model-free NIM 文档，vLLM OpenAI-compatible server 与在线服务 benchmark 文档，以及 Hugging Face TGI 首页、launcher 与多后端文档。官方材料支持产品架构、公开接口、支持矩阵和维护状态；本站的三十项清单、试验合同和选择脚本是编辑部综合，不是厂商原文。

本文没有登录读者或厂商受限账号，没有验证商业支持资格，没有在目标 GPU 上运行三套服务，也没有给出吞吐、成本或质量提升数字。版本、价格、许可、地区、支持矩阵和维护状态都可能变化；真正部署前必须在目标日期重新核验官方页面并保存回执。