自建 LLM 推理引擎：默认 vLLM 之后，什么时候该换 SGLang 或 TensorRT-LLM？
项目信息：
多数团队默认 vLLM，这个起点合理。但“换更强的引擎”不自动等于降 P99。P99 受排队、调度、KV 内存、前缀命中率、输出长度分布共同影响。换 SGLang 或 TensorRT-LLM 之前，先量化自己的 workload：平均 prompt 前缀重叠率、模型更新频率、并发与输出长度分布、硬件是否可能引入 AMD。下面按三类引擎的取舍与失败边界展开。
vLLM：默认起点，优势在调度与兼容性
vLLM 官方定位是 fast and easy-to-use library for LLM inference and serving，起源于 UC Berkeley Sky Computing Lab，2000+ contributors，Apache-2.0，GitHub 约 92k stars（2026-09）。
它的加速点集中在内存与调度：PagedAttention 管理 attention KV 内存，continuous batching、chunked prefill、prefix caching，piecewise 与 full CUDA/HIP graphs。量化支持 FP8、MXFP8/MXFP4、NVFP4、INT8、INT4、GPTQ/AWQ、GGUF、compressed-tensors、ModelOpt、TorchAO。Attention kernel 覆盖 FlashAttention、FlashInfer、TRTLLM-GEN、FlashMLA、Triton；GEMM/MoE kernel 使用 CUTLASS/TRTLLM-GEN/CuTeDSL。还支持 speculative decoding（n-gram、suffix、EAGLE、DFlash）、torch.compile 做 graph 级变换、disaggregated prefill/decode/encode。
易用性方面，vLLM 无缝对接 HuggingFace 模型，支持 parallel sampling、beam search 等解码，tensor/pipeline/data/expert/context 并行，流式输出，xgrammar 或 guidance 结构化输出，tool calling 与 reasoning 解析器，OpenAI 兼容 API server，另有 Anthropic Messages API 与 gRPC。dense 与 MoE 的多 LoRA 也可用。硬件支持 NVIDIA/AMD/Intel GPU 与 x86/ARM/PowerPC CPU，并有多家硬件插件：Google TPU、Intel Gaudi、IBM Spyre、Huawei Ascend、Rebellions NPU、Apple Silicon、MetaX 等；支持 200+ HuggingFace 模型架构，覆盖 decoder-only、MoE、混合 attention/SSM、多模态、embedding、reward 等。
安装方式：
uv pip install vllm
官方推荐 uv，也可用 pip，或从源码 build。
文档里可确认的页面包括 Online Serving、OpenAI-Compatible Server（/v1/chat/completions、/v1/completions）、Engine Arguments、Server Arguments、Conserving Memory、Optimization and Tuning（Chunked Prefill、Parallelism Strategies：TP/PP/EP/DP、Attention Backend Selection、Preemption）、Automatic Prefix Caching、Speculative Decoding（N-Gram、EAGLE、MTP、Suffix Decoding）、Quantization（FP8/INT4/INT8、Quantized KV Cache、Online Quantization）、Benchmark CLI（vllm bench）、Troubleshooting、Production Metrics。部署方式覆盖 Docker、Kubernetes、Nginx、Ray Serve、Helm 等。
vLLM 的失败边界不在“能不能跑”，而在极端前缀复用场景下可能被 SGLang 拉开差距；在纯 NVIDIA、模型长期固定的场景下，TensorRT-LLM 的峰值吞吐也可能更高。但 vLLM 的模型覆盖、无编译步骤、OpenAI 兼容开箱即用、调度与硬件兼容性，仍然是默认起点。
SGLang：RadixAttention 只有前缀命中时才有效
SGLang 的核心是 RadixAttention，按基数树共享历史 KV，配合前缀缓存与结构化输出/约束解码。硬件以 NVIDIA 为主，AMD 支持弱一些。
前缀复用是它最容易被误读的地方。若所有请求 prompt 完全不同，SGLang 相对 vLLM 只快 3-4%；若 200 条请求共享 2048 token 系统 prompt，50 并发下 SGLang 可高出 vLLM 约 35-45%，个别口径提到 LMSYS 报 6.4x。也就是说，“引擎更快”有前提：前缀要命中。
适合迁移到 SGLang 的信号比较具体：trace/压测显示前缀重叠率高，例如 RAG over 固定语料、多轮 Agent、结构化/约束解码密集；或者专门服务 DeepSeek 系 MoE。若没有前缀重叠，收益接近噪声，迁移只剩运维成本。vLLM 与 SGLang 都是 Python 原生、pip 上手，迁移代价通常低于 TensorRT-LLM。
TensorRT-LLM：编译成本与硬件锁定
TensorRT-LLM 来自 NVIDIA，走 AOT 编译成 TRT engine 的路线，做内核融合与 FP8。它仅支持 NVIDIA，编译结果与硬件绑定：A100 上编译的引擎不能拿到 H100 跑。
冷启动差距来自编译。第三方横评给出的方向是：vLLM 加载权重约 60-90 秒即可服务，SGLang 接近；TensorRT-LLM 首次编译约 28 分钟，换模型版本、改 max seq len、改 batch size 都要重编译，编译产物可复用，后续加载约 90 秒。TensorRT-LLM v1.x 新增 PyTorch 后端可跳过编译，冷启动降到 60-90 秒，代价是吞吐比编译引擎低约 15-20%。
因此它适合固定模型、长时间稳定、纯 NVIDIA、能摊薄编译与调优成本的场景。迁移代价不止性能：要建编译流水线与版本管理，模型更新频率一高，编译成本会直接吃掉收益。
部署命令与接口
vLLM 的常用启动方式：
vllm serve \
--tensor-parallel-size N \
--gpu-memory-utilization 0.9 \
--max-model-len ... \
--quantization fp8
--max-model-len、--gpu-memory-utilization 等参数与默认值以你所用版本的 --help / 官方文档为准。OpenAI 兼容接口可直接对接现有多租户网关，常用路径是 /v1/chat/completions 与 /v1/completions。需要 Anthropic Messages API 或 gRPC 时，vLLM 也有对应入口。
评测口径：数字必须来自自己硬件与流量
官方与第三方 benchmark 是上限，不是承诺。不同模型、精度、并发下结论会反转。第三方横评来自多家 2026 年文章，包括 ai-master.cc、jishuzhan.net、gpuinsights.net、genalphai.com，数字口径不一，需自行验证。
其中一份单卡 H100 80GB 实测（Llama 3.3 70B FP8，第三方自述口径）给出：50 并发吞吐 vLLM v0.18.0 1850 tok/s、SGLang v0.5.9 1920 tok/s、TensorRT-LLM v1.2.0 2100 tok/s；100 并发 p95 TTFT 分别约 1450ms / 1380ms / 1280ms；闲置显存约 71/72/74 GB。这些数字只能当作方向性参考。
自测时至少记录：吞吐、P95/P99 TTFT、ITL、端到端延迟、显存占用、冷启动时间、前缀命中率。vLLM 提供 vllm bench，可以按自己的 prompt 分布和并发曲线压。选型结论应来自自己的硬件与流量，而不是横评截图。
主流三强的定位可以这样记：vLLM 是 PagedAttention + 连续 batching 的通用引擎；SGLang 是 RadixAttention、前缀缓存 + 结构化输出/约束解码；TensorRT-LLM 是 NVIDIA 的 AOT 编译路线，内核融合/FP8。TGI 已式微，Ollama 属本地/开发用途。
默认从 vLLM 开始，模型支持最广、社区最大、无编译步骤、OpenAI 兼容开箱即用。trace/压测显示前缀重叠率高，或专门服务 DeepSeek 系 MoE，再迁 SGLang。只有固定模型、长时间稳定、纯 NVIDIA 且能摊薄编译与调优成本时，才考虑 TensorRT-LLM。先量前缀重叠率和模型更新频率，再决定是否换引擎。