4. 推理框架选型：vLLM、TGI、TensorRT-LLM、llama.cpp对比与适用场景分析
说到推理框架选型，这其实是个挺让人头疼的事。我刚开始接触大模型部署那会儿，面对一堆框架名字，说实话有点懵。每个都说自己快，每个都说自己省显存，但到底哪个适合你的场景？
今天我就把这四个主流框架——vLLM、TGI、TensorRT-LLM、llama.cpp，掰开揉碎了讲清楚。嗯，咱们不搞虚的，直接上干货。
4.1 为什么需要专门的推理框架？
你可能想问：直接用PyTorch跑推理不行吗？
行是行，但效率太低了。我举个例子，你用PyTorch加载一个70B的模型，显存占用轻松超过140GB，而且推理速度慢得让人抓狂。推理框架做了三件核心事：
- 内存优化：通过PagedAttention、KV Cache量化等技术，把显存占用降下来
- 计算加速：利用CUDA Graph、FlashAttention、算子融合等手段，把推理速度提上去
- 服务化封装：提供HTTP接口、动态批处理、流式输出等生产级能力
说白了，推理框架就是帮你把大模型从「实验室玩具」变成「生产工具」的关键一环。
4.2 四大框架核心对比
先看一张总览表，心里有个底：
| 特性 | vLLM | TGI | TensorRT-LLM | llama.cpp |
|---|---|---|---|---|
| 开发方 | UC Berkeley | Hugging Face | NVIDIA | 社区（ggerganov） |
| 核心优化 | PagedAttention | 连续批处理 | 图编译+算子融合 | CPU/GPU混合量化 |
| GPU支持 | NVIDIA GPU | NVIDIA GPU | NVIDIA GPU（最优） | CPU为主，GPU可选 |
| 量化支持 | GPTQ、AWQ、FP8 | GPTQ、AWQ | INT4、INT8、FP8、INT4_AWQ | Q2_K~Q8_0、IQ系列 |
| 最大优势 | 高并发下显存利用率极高 | 与Hugging Face生态无缝集成 | 单卡/多卡推理速度最快 | CPU可跑，资源门槛最低 |
| 典型场景 | 高并发在线服务 | 快速原型验证 | 极致性能要求的线上服务 | 个人电脑、边缘设备 |
4.3 vLLM：高并发场景的首选
vLLM是我个人用得最多的框架。为什么？因为它解决了大模型推理中最头疼的问题——显存碎片化。
传统方式下，每个请求的KV Cache是连续分配的，请求结束后释放，时间长了显存就像一盘散沙。vLLM的PagedAttention借鉴了操作系统的分页思想，把KV Cache切成固定大小的块，按需分配。效果立竿见影：
- 显存利用率从60%提升到95%以上
- 可以同时处理的请求数翻倍甚至更多
我在项目中遇到过这样一个场景：用原生PyTorch部署13B模型，8张A100只能同时处理32个请求。换成vLLM后，同样的硬件，并发数直接飙到128。客户当场就愣住了。
适用场景总结：高并发在线API服务、多租户场景、需要最大化硬件利用率的场景。
我的小技巧：vLLM搭配AWQ量化使用效果最佳。我一般先用AutoAWQ把模型量化到4bit，再用vLLM加载，显存占用能再降一半。
4.4 TGI：Hugging Face生态的嫡系部队
TGI是Hugging Face官方出品的推理框架。如果你已经在用Transformers库，那TGI几乎零学习成本。
它的核心优势在于「开箱即用」：
- 支持所有Hugging Face模型格式，不用做任何转换
- 内置了Message API，兼容OpenAI的接口格式
- 连续批处理机制，动态合并请求，提升吞吐量
但说实话，TGI在极致性能上不如vLLM和TensorRT-LLM。我做过对比测试，同样条件下TGI的吞吐量大约是vLLM的70%-80%。
适用场景总结：快速原型验证、中小规模部署、团队已经深度使用Hugging Face生态的场景。
注意：TGI对自定义模型的支持不如vLLM灵活。如果你用了非标准的模型结构，可能需要自己写代码适配。
4.5 TensorRT-LLM：性能怪兽
如果你追求极致性能，TensorRT-LLM是当之无愧的王者。它把模型编译成高度优化的CUDA内核，推理速度能比vLLM快30%-50%。
但代价也很明显——部署流程复杂。你需要：
- 先把模型转换成TensorRT-LLM支持的格式
- 然后编译成TensorRT引擎（这个过程可能耗时几十分钟）
- 最后才能部署服务
我记得有一次帮客户部署一个70B模型，光编译就花了40分钟。而且一旦模型结构有变化，就得重新编译。嗯，这确实是个痛点。
适用场景总结：对延迟要求极高的场景（如实时对话）、硬件资源充足且模型结构稳定的场景。
我的建议：如果你决定用TensorRT-LLM，一定要做好CI/CD流程。把模型编译做成自动化流水线，不然每次更新模型都手动编译，会把人逼疯的。
4.6 llama.cpp：CPU也能跑大模型
llama.cpp是个神奇的项目。它最初的目标是在MacBook上跑LLaMA，后来发展成了CPU推理的首选方案。
它的核心武器是量化：
- 支持从Q2_K到Q8_0的多种量化级别
- 独创的IQ系列量化，在极低比特下保持不错的效果
- CPU推理速度比PyTorch快10倍以上
我曾经在一台只有16GB内存的笔记本上，用llama.cpp跑7B模型，量化到Q4_K_M，推理速度能达到每秒15个token。虽然比不上GPU，但至少能用了。
适用场景总结：个人电脑部署、边缘设备、没有GPU的环境、对成本敏感的场景。
注意：llama.cpp的GPU支持比较有限。虽然现在有CUDA后端，但优化程度远不如vLLM和TensorRT-LLM。如果你有GPU，还是优先考虑前三个框架。
4.7 选型决策指南
说了这么多，到底怎么选？我总结了一个简单的决策流程：
- 有GPU，追求高并发 → vLLM
- 有GPU，追求极致速度 → TensorRT-LLM
- 有GPU，快速验证想法 → TGI
- 没有GPU，或者跑在笔记本上 → llama.cpp
当然，实际项目中往往需要组合使用。比如我现在的做法是：开发阶段用TGI快速迭代，上线后用vLLM承载高并发流量，对延迟敏感的核心接口用TensorRT-LLM做加速。各取所长嘛。
最后说一句：框架选型没有银弹。我见过有人非要用TensorRT-LLM跑一个每天只有几百次调用的服务，结果编译时间比运行时间还长。也见过有人用llama.cpp在数据中心跑70B模型，白白浪费了GPU资源。选框架之前，先想清楚你的场景到底需要什么。