到了2026年，部署清单里可能同时出现B200、A100、H20和昇腾910B/910C。选推理引擎时，最危险的做法是拿别人的吞吐表直接做自己的容量规划。即便都使用A100，模型版本、量化方式、输入输出长度、并发和张量并行配置一变，结果也会跟着变。
类似“vLLM快2—3倍”“TensorRT-LLM高10%—20%”“TTFT下降15%”“H20吞吐提升18%”“成本降低30%”的说法，如果没有完整测试环境，只能当作调优线索，不能写进预算承诺。《大模型推理性能Benchmark 实践：vLLM vs TensorRT-LLM》给出的方向很清楚：vLLM依靠PagedAttention改善KV Cache调度，强调高并发和易用；TensorRT-LLM借助NVIDIA原生编译争取更多性能空间。真正的选择仍取决于请求怎么来、模型多久换一次，以及团队愿意投入多少维护成本。
先把漂亮数字放回测试环境
一份能用于选型的压测，至少要写清这些条件：
- 模型名称、版本与权重是否一致，例如7B—13B模型不能直接和Llama-3.1-70B横比；
- 使用全精度、AWQ、INT8、INT4还是FP8；
- 输入长度、输出长度和
max_seq_len； - GPU型号、显存、卡数与张量并行配置；
- 并发请求是否达到50+，请求是集中到达还是随机进入；
- 首字延迟、单Token生成时延、总吞吐、显存峰值和OOM次数。
同一批请求应分别交给两个引擎运行。只报吞吐、不报首字延迟，可能掩盖排队时间；只测固定Batch，也无法代表线上Chatbot的随机流量。压测脚本和模型参数没有对齐时，所谓胜负往往只是测试口径不同。
vLLM的长处，是少折腾也能把并发跑起来
vLLM把KV Cache切成固定大小的Block，按需分配，而不是为每条序列提前保留一整块连续显存。PagedAttention解决的首先是显存碎片和预分配浪费，并不是让GPU计算能力凭空增加。配合Continuous Batching，请求结束后释放出的槽位可以继续接纳新请求，比较适合到达时间不规律的在线服务。
两个参数最值得先看：
--max-num-batched-tokens决定一次调度可处理多少Token。A100 80GB运行70B模型时，可以把2048—4096作为试探区间，但不能照抄为固定答案。数值上调后，吞吐可能增加，排队和显存峰值也可能随之上升。--gpu-memory-utilization默认值为0.9。同卡还有其他进程时，可从0.85开始测试，给系统和其他任务留下约15%的空间，再根据OOM记录调整。
vLLM对LoRA以及Llama、Mistral、Qwen等模型的接入较直接。团队需要频繁更换基座模型、更新权重或验证新版本时，这种低接入成本通常比单次压测领先更有价值。
TensorRT-LLM快不快，要看编译成本能否摊薄
TensorRT-LLM通过计算图编译和算子融合贴近NVIDIA硬件。模型、请求形态和部署配置较稳定时，编译优化更容易转化为吞吐或延迟收益。但它不是换一条启动命令就能得到的免费加速。
70B模型构建TensorRT Engine可能需要数小时，权重微调后还可能重新编译。对每周都在换模型的团队，这段等待时间和维护工作会抵消一部分性能收益；对长期运行同一模型、流量较稳定的服务，编译投入才更容易摊薄。
AWQ、INT8和FP8也不能只看显存数字。量化后要重新测回答质量、首字延迟和持续生成速度。高并发短请求不必然属于vLLM，RAG后端或Embedding也不必然属于TensorRT-LLM。比应用名称更重要的，是请求到达是否随机、输入长度是否稳定，以及权重更新是否频繁。
H20还能直接比较，昇腾要换一套问题
H20仍在NVIDIA软件栈内，可以继续比较vLLM和TensorRT-LLM。长输入场景若受到数据传输或显存带宽影响，可把vLLM的--enable-chunked-prefill纳入测试，将Prefill切成较小的Chunk。
看到“Qwen2.5-72B在H20上调整Chunk后吞吐提升约18%”这类结果时，还要继续追问输入长度、Chunk大小、并发、量化方式和GPU数量。缺少这些信息，18%无法直接复现，更不能套到另一套业务流量上。
昇腾910B/910C则不是同一道选择题。TensorRT-LLM依赖NVIDIA软件栈，无法用于昇腾平台，需要比较MindIE与vLLM Ascend Backend。迁移时应先验证算子覆盖、LoRA Adapter加载、batch_size和max_seq_len，而不是先追求峰值吞吐。若没有同模型、同精度、同请求集的测试，也不宜直接宣称910B已经接近A100上的某个结果。
省钱靠测量，不靠默认参数
| 部署条件 | 优先测试 | 先排查什么 |
|---|---|---|
| 请求随机、模型更新频繁、需要LoRA | vLLM | KV Cache占用、排队时间、max_num_seqs |
| NVIDIA GPU、模型长期稳定、请求形态可预测 | TensorRT-LLM | 编译耗时、量化精度、Engine维护成本 |
| H20上的长上下文服务 | 两者都测 | Chunked Prefill、显存带宽、首字延迟 |
| 昇腾910B/910C | MindIE或vLLM Ascend Backend | 算子兼容、LoRA加载、序列长度 |
降低30%推理成本不应被写成一套通用配方。混合部署也不是默认答案：同时维护vLLM和TensorRT-LLM，意味着两套镜像、监控、回滚流程和模型副本。只有实时请求与后台任务的负载差异足够大，分流才可能值得。
量化同样需要克制。INT4能明显压低权重显存，但服务总显存还包括KV Cache和运行时开销，不能由此推导硬件数量必然减半。FP8是否合适，也要结合硬件支持和质量测试判断。
监控可以接入Prometheus，重点看队列长度、KV Cache Block利用率、首字延迟和OOM重启。启用Prefix Caching后，再看KV Cache命中率。Block利用率低于60%可以作为排查信号，但不是通用故障线：它可能来自并发不足、序列长度分布或预留空间过大。增加并发或调高max_num_seqs之前，先确认延迟和显存仍在可接受范围内。
更稳妥的落地顺序是：先用vLLM建立可运行、可观测的基线；如果模型稳定运行在NVIDIA GPU上，再构建TensorRT-LLM版本做同流量对照；昇腾平台单独评估MindIE与Ascend Backend。这样测出的差异，才属于引擎，而不是测试环境。
