三个推理引擎我全跑了一遍，结论和官网 benchmark 不一样
vLLM / TensorRT-LLM / SGLang 横评：我在原生 Windows 上连 pip install 都装不上
系列第 1 篇 · 推理选型决策
⚠️ 数据性质声明（先看这段，避免误读）：本文只有「三框架在 Windows 的安装可装性」是本人实跑核验（用 PyPI 官方 JSON API 查 wheel 平台标签）；「性能吞吐」全部来自各项目官方公开 benchmark（非本人实测），已在对应表格下方标注来源。本地真实推理基准已在本系列第 3、4 篇以「本人实测」补上：本机
torch加载 CUDA 扩展仍崩溃（GPU 路径不可用），故改用纯 NumPy CPU 推理引擎（OpenBLAS）实跑 Qwen2.5-0.5B/1.5B 的中文生成延迟（约 15 / 5 tok/s）与量化精度损失（int8 保留 94%、int4 保留 82%），数据真实可复现。所有数字请以你自己的硬件复测为准。
官网说 vLLM 比 HuggingFace Transformers 快 3 倍，但我在自己的RTX 5060 笔记本（原生 Windows 11）上敲pip install vllm，直接报「找不到匹配的 Windows 包」。先别盲信 benchmark，部署门槛才是第一道关。
本辑主线：把大模型从「能调通」做到「跑得快、跑得省、测得准、守得住」。这一篇先解决选型——同一模型、同一硬件，三个推理引擎到底怎么选。
一、为什么不直接用 API？
API 够用，但三个动因迟早把你推向自建推理引擎：
- 并发：API 按 token 计费，高并发下成本失控，且速率限制卡脖子。
- 成本：长文本+高 QPS 场景，自托管一张卡往往比 API 账单便宜一个数量级。
- 私有化：数据不出内网，金融/医疗/政企的硬要求。
但自建的第一课不是「谁最快」，是「谁装得上」。
二、三框架定位差异（一眼看懂）
| 引擎 | 定位 | 强项 | 代价 |
|---|---|---|---|
| vLLM | 通用均衡 | 社区大、连续批处理成熟、易上手 | 极致性能非最强 |
| SGLang | 结构化输出 | RadixAttention 复用前缀、Agent/多轮强 | 配置心智负担大 |
| TensorRT-LLM | N 卡极致 | NVIDIA 上延迟/吞吐最优 | 编译重、版本锁死、Linux only |
三、实测环境与数据来源（哪些是我真跑的）
- GPU：NVIDIA RTX 5060 Laptop GPU，8GB 显存，Blackwell 架构（计算能力 12.0）
- 驱动：610.62
- 系统：Windows 11（win32，原生，非 WSL2）
- 框架：Python 3.13，已安装
torch（CUDA 12.8 版） - 诚实补充：本机
import torch在加载 CUDA 扩展时存在环境级崩溃（torch 自带 CUDA 运行时与系统nvcuda.dll驱动接口不兼容），因此本文尚未完成本地 Qwen2.5 的真实推理基准。下文「安装可装性」为本人实跑核验；「性能吞吐」为官方公开数据，非本人实测。
数据边界（务必看清）：①「安装可装性」= 本人本机/PyPI 实跑；②「性能吞吐」= 各项目官方 benchmark 公开数据（非本人实测），文末附来源；③本地推理基准已在本系列第 3、4 篇以纯 NumPy CPU 推理引擎补上（GPU 路径因 torch 崩溃仍不可用）。
四、第一关：原生 Windows 到底能不能装？（本人实跑）
我用 PyPI JSON API 拉了三者最新版的 wheel 平台标签，结论很直接：
| 引擎(最新版) | PyPI wheel 平台 | Windows wheel | CUDA wheel | 本机pip install |
|---|---|---|---|---|
vLLM0.26.0 | manylinux_2_28 (x86/aarch64) | 无 | 无 | ❌ 无匹配包 |
SGLang0.5.16 | manylinux_2_34 (x86/aarch64) | 无 | 无 | ❌ 无匹配包 |
TensorRT-LLM1.2.1 | 无任何 wheel（仅源码包） | 无 | 无 | ❌ 需源码编译 |
反直觉结论：三大引擎最新版在 PyPI 上全都只发 Linux wheel，没有 Windows 轮子。想在原生 Windows消费级显卡上直接pip install，目前三个都装不上。
注意措辞：是「原生 Windows」装不上，不是「Windows 完全不行」——下面第七节给了 WSL2 解法。
血的教训：别信「某某框架支持 Windows」的旧教程。版本迭代极快，装之前先
pip index versions <pkg>或查 PyPIfiles页确认有没有win_amd64轮子，否则白折腾一下午。
五、性能怎么摆（公开 benchmark，非本人实测）
装得上才谈性能。下表汇总各项目官方文档/benchmark 博客的相对结论（绝对 QPS 随硬件天差地别，请在你自己的卡上复现）：
| 维度 | vLLM | SGLang | TensorRT-LLM |
|---|---|---|---|
| 吞吐(对比 HF) | 官方称连续批处理带来2–4×提升 | 前缀复用场景高吞吐 | N 卡上通常最优 |
| TTFT(首 token) | 中 | 中 | 低（编译优化） |
| TPOT(每 token) | 低 | 低 | 最低 |
| 峰值显存 | 中（PagedAttention） | 中 | 低（内核融合） |
| 来源 | vLLM 官方文档/Blog | SGLang GitHub | TRT-LLM 官方 Docs |
标注：上表为公开数据（非本人实测），来源见文末。绝对数值请以你本机压测为准。
六、血泪坑实录
- TRT-LLM 锁 CUDA 版本：编译对 CUDA/driver 极其挑剔，换张卡或升驱动可能整套重编，CI 里是噩梦。
- SGLang 路由配置：RadixAttention 强，但多卡/路由参数配错时吞吐不升反降，日志还不直观。
- vLLM 的 prefix cache 默认关：多轮对话/共享前缀场景，不显式开
enable_prefix_caching等于白买内存带宽。
七、选型决策树
你用的是 N 卡 + Linux 生产环境？ ├─ 是，且要极致延迟/吞吐 → TensorRT-LLM（肯花编译成本） ├─ 是，常规高并发服务 → vLLM（最稳，社区答案） └─ 否（Windows / 消费级卡 / 想快上手） ├─ 多轮/Agent/结构化输出 → 上 WSL2 + SGLang └─ 通用推理 → WSL2 + vLLM一句话：生产无脑 vLLM，N 卡极致上 TRT-LLM，结构化输出看 SGLang；Windows 用户先装 WSL2，别在原生 Windows 里死磕。
八、读者交付物
①选型决策树（上图，可截图） ②一键压测脚本骨架（vegeta 版，GitHub 风格片段）：
# 用 vegeta 压你的 /v1/completions 接口echo'{"model":"qwen2.5","prompt":"你好","max_tokens":128}'\|vegetaattack-rate=20-duration=30s-method=POST\-header="Content-Type: application/json"\-target=https://your-host/v1/completions\|vegetareport# 看吞吐 QPS / p99 延迟结尾：今天就能动手的 3 条清单
- 先查轮子再动手：
pip index versions vllm，确认有你系统的 wheel，别上来就pip install。 - 装 WSL2：Windows 用户花 10 分钟
wsl --install，推理引擎的世界在 Linux 侧。 - 压一次基线：用上面 vegeta 片段压你现有接口，记下 QPS/p99，下篇我们拆延迟。
实测环境与免责：本次环境见第三节。安装可装性为本人在本机/PyPI 实跑（PyPI 官方 JSON API 核验）；性能吞吐为各项目官方公开 benchmark（非本人实测），来源：vLLM 官方文档与 Blog、SGLang GitHub README、NVIDIA TensorRT-LLM 官方 Docs。本地真实推理基准已在本系列第 3、4 篇以「本人实测」补上：本机 torch 加载 CUDA 扩展崩溃（GPU 不可用），改用纯 NumPy CPU 推理引擎实跑 Qwen2.5-0.5B/1.5B 延迟（约 15/5 tok/s）与量化损失（int8 94%/int4 82%）。数据基于本人环境，仅供参考，请以你自己的硬件复测为准。**
下篇我们聊：为什么三引擎吞吐差这么多？——连续批处理 + 投机解码的实测账。