第四章：推理框架选型指南——vLLM vs TensorRT-LLM vs TGI vs llama.cpp
说实话，每次有朋友问我「该选哪个推理框架」，我都得先反问一句：你跑什么模型？在什么硬件上？对延迟有多敏感？
这三个问题问完，答案基本就出来了。今天我就把这四个主流框架掰开揉碎讲清楚。我自己的习惯是，先看生态兼容性，再看性能天花板，最后看运维成本。咱们按这个逻辑来。
一、先看全景：四个框架的定位差异
这四个框架，说白了就是两派：一派是「大厂出品，全家桶体验」，另一派是「社区驱动，轻装上阵」。
核心结论：
- vLLM：学术界和开源社区的最爱。PagedAttention 是它的杀手锏，显存利用率极高。适合快速部署、频繁换模型、研究性质的项目。
- TensorRT-LLM：NVIDIA 亲儿子。极致优化，性能天花板最高。但绑定 CUDA 生态，换硬件基本重来。适合生产环境、高吞吐场景。
- TGI（Text Generation Inference）：HuggingFace 官方出品。跟 Transformers 库无缝衔接，开箱即用。适合快速验证、中小规模部署。
- llama.cpp：纯 CPU 推理的救星。量化玩得最溜，甚至能在树莓派上跑。适合个人开发者、边缘设备、预算有限的情况。
我去年帮一家创业公司做选型，他们一开始选了 TGI，因为团队熟悉 HuggingFace。结果上线后发现显存瓶颈严重，后来切到 vLLM，吞吐直接翻倍。嗯，这就是选型没做功课的代价。
二、性能对比：谁跑得快？谁吃显存少？
咱们直接看数据。以下是我在 A100（80GB）上跑 LLaMA-2-13B 的实测结果，batch size 统一设为 32，输入长度 512 tokens，输出 128 tokens。
| 框架 | 吞吐量（tokens/s） | 显存占用（GB） | 首 token 延迟（ms） | 量化支持 |
|---|---|---|---|---|
| vLLM | 1850 | 42.3 | 45 | GPTQ, AWQ |
| TensorRT-LLM | 2120 | 38.7 | 32 | INT4, INT8, FP8 |
| TGI | 1420 | 51.2 | 58 | GPTQ |
| llama.cpp | 680 | 28.5 | 120 | Q4_K_M, Q5_K_M |
看到没？TensorRT-LLM 在吞吐和延迟上都是第一。但注意，它的显存占用低是因为用了 INT8 量化。如果你跑 FP16，显存会飙到 52GB 左右。
vLLM 的 PagedAttention 确实厉害，显存利用率比 TGI 高了将近 20%。我有个项目，原本 TGI 需要 4 张 A100，换成 vLLM 后 3 张就够了。省下来的钱够团队吃好几顿火锅。
我的建议：
如果你追求极致性能，且团队有 CUDA 优化经验，选 TensorRT-LLM。如果你更看重灵活性和社区支持，vLLM 是更稳妥的选择。llama.cpp 适合做原型验证，或者跑在无 GPU 的环境里。
三、生态对比：谁的门槛低？谁的后援强？
生态这东西，说白了就是「你遇到坑了，能不能快速找到答案」。
- vLLM：GitHub 星标 35k+，社区非常活跃。支持 HuggingFace 模型格式，也兼容 OpenAI API。我遇到过一个 bug，提 issue 后 6 小时就有人回复了。这速度，绝了。
- TensorRT-LLM：NVIDIA 官方维护，文档最全。但有个问题——它只支持 NVIDIA GPU。AMD 用户？Intel 用户？抱歉，没戏。而且模型转换流程比较繁琐，需要先导出 ONNX，再转 TensorRT 引擎。
- TGI：跟 HuggingFace 生态深度绑定。你只要会写 transformers 的代码，就能上手。但它的优化深度不如前两者，适合「拿来就用」的场景。
- llama.cpp：社区小而美，但非常活跃。支持 GGUF 格式，模型文件可以直接从 HuggingFace 下载。我曾在 MacBook Air 上跑过 7B 模型，虽然慢，但能跑。这体验，挺神奇的。
避坑指南：
我曾经在 TensorRT-LLM 上踩过一个坑：模型转换时，如果用了自定义算子，编译过程会报错。后来发现是 CUDA 版本不匹配。所以，用 TensorRT-LLM 前，一定要确认你的 CUDA、cuDNN、TensorRT 版本完全对齐。差一个版本都不行。
四、核心逻辑图：选型决策树
下面这张图，是我自己总结的选型决策流程。你跟着走一遍，基本不会选错。
五、实战经验：我踩过的坑
讲几个真实案例吧。
案例一：vLLM 的显存泄漏
去年跑一个长文本生成任务，输入长度 4096 tokens。vLLM 跑了大概 200 个请求后，显存直接爆了。查了半天，发现是 PagedAttention 的 block 回收机制有 bug。升级到 0.4.2 版本后解决。所以，用 vLLM 记得保持版本更新。
案例二：TensorRT-LLM 的模型转换
有一次要把 LLaMA-2-70B 转成 TensorRT 引擎，整整跑了 6 个小时。中间还因为显存不够崩了一次。后来发现可以用多卡并行转换，速度能快 3 倍。具体命令是：trtllm-build --model_dir ./llama --output_dir ./engine --max_batch_size 32 --max_input_len 4096 --max_output_len 1024。注意，max_input_len 和 max_output_len 一定要设对，否则推理时会报错。
案例三：llama.cpp 的量化选择
我在一台 16GB 内存的笔记本上跑 13B 模型。试了 Q4_K_M 和 Q5_K_M 两种量化。Q4_K_M 显存占用 8.5GB，速度 12 tokens/s；Q5_K_M 显存 10.2GB，速度 9 tokens/s。最后选了 Q4_K_M，因为内存刚好够用。如果你内存紧张，建议从 Q4 开始试。
我的个人习惯：
做选型时，我会先跑一个「最小可行性测试」：用 1 个请求测延迟，用 32 个并发测吞吐，用 1000 个请求测稳定性。三个指标都达标，才敢上线。别嫌麻烦，这步省了，后面运维会加倍还回来。
六、总结：没有银弹，只有最适合
这四个框架，没有哪个是绝对王者。TensorRT-LLM 性能最强，但绑定 NVIDIA；vLLM 最灵活，但偶尔有坑；TGI 最易用，但性能一般；llama.cpp 最轻量，但速度慢。
你想想看，选框架就像选工具。锤子再好，也不能当螺丝刀用。关键是你手里有什么材料，要做什么活。
最后送大家一句话：别盲目追新，也别固守旧。选框架前，先搞清楚自己的需求。