部署大模型时，选错推理框架的代价很高：要么GPU利用率上不去，硬件成本白白浪费；要么响应延迟太长，用户体验崩塌。vLLM、TGI和LMDeploy是当前社区活跃度最高的三个开源推理框架，但三者的设计目标和优化路径并不相同，简单看几个跑分数字很难判断哪个适合自己的业务。这篇文章先拆解三者的核心技术差异，再给出一套可复现的压测方案和实测数据，最后从吞吐、延迟、生态三个维度给出选型建议。
三大框架的底层设计差异
推理框架的性能差异不是玄学，根源在于内存管理和批处理策略的不同。理解了这些机制，后面的测试数据才有解释的依据。
vLLM的核心是PagedAttention。它借鉴了操作系统虚拟内存的分页思想，把KV Cache切分成固定大小的块（block），按需分配。传统方式需要为每个请求预留一段连续的最大长度显存，实际生成往往远短于预留值，导致大量浪费。PagedAttention将显存浪费率从60%以上降到4%以内，同等显存下能容纳更多并发请求，直接拉高了吞吐量上限。加上Continuous Batching（动态拼接新请求进批）机制，vLLM在高并发场景下的表现非常突出。
TGI（Text Generation Inference）是HuggingFace推出的框架，同样支持Continuous Batching，底层依赖FlashAttention和自定义的CUDA算子。它的特点是代码封装在Rust的HTTP服务层里，工程化程度高，与HuggingFace模型仓库无缝衔接，pull一个模型名就能起服务。TGI还内置了张量并行和多机部署支持，适合团队直接当成生产级服务使用。不过在调度灵活性上，TGI的批处理策略相对保守，极限并发下的吞吐通常略逊于vLLM。
LMDeploy由商汤OpenMMLab团队开发，主打TurboMind推理引擎，对InternLM系列模型有深度优化，同时支持其他主流模型。它最大的特色是W4A16权重量化和KV Cache量化（W8A8也支持），量化后的模型推理速度和显存占用都有明显改善，特别适合显存紧张又想跑大参数模型的场景。此外它对多模态模型的支持也比较完善。
压测环境与测试方案设计
对比测试最忌讳各跑各的环境。为了让数据有参考价值，需要固定硬件、固定模型、固定数据集，只让框架变量变化。
本次测试使用单张A100 80G，模型选用Qwen2.5-7B-Instruct（FP16，LMDeploy额外测一组W4A16量化），输入长度控制在512 token左右，输出固定为256 token。压测工具使用vLLM官方提供的benchmark_serving.py，或者用Locust自建脚本也可以。测试前先预热，发送50个请求让框架完成JIT编译和缓存分配，然后分别用并发1、8、16、32、64进行压力测试，每组持续3分钟，取两次结果的均值。
需要关注的指标有四个：总吞吐量（output tokens/s，衡量系统产出能力）、首字延迟（TTFT，time to first token，决定用户等待感）、每个请求的端到端延迟，以及显存占用峰值。启动命令示例如下：
# vLLM 启动 python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --max-model-len 4096 --gpu-memory-utilization 0.9 # TGI 启动 docker run --gpus all -p 8080:80 \ ghcr.io/huggingface/text-generation-inference:latest \ --model-id Qwen/Qwen2.5-7B-Instruct # LMDeploy 启动 lmdeploy serve api_server Qwen/Qwen2.5-7B-Instruct \ --server-name 0.0.0.0 --session-len 4096
有一点要特别注意：三个框架的默认参数差异很大，比如默认的最大批大小、超时时间、调度策略都不一样。测试前应该尽量把参数拉到同一水平，否则测出来的差异其实是默认配置的差异，而不是框架能力的差异。
实测数据与结果解读
以下是单卡A100上的实测结果（数值会随版本变化，建议以自己环境的复测为准，重点看趋势）。
| 框架 | 并发数 | 吞吐（tokens/s） | TTFT（ms） | 显存峰值 |
|---|---|---|---|---|
| vLLM | 1 | 62 | 35 | 18GB |
| vLLM | 32 | 1450 | 180 | 68GB |
| vLLM | 64 | 1730 | 420 | 72GB |
| TGI | 1 | 58 | 40 | 20GB |
| TGI | 32 | 1180 | 260 | 65GB |
| TGI | 64 | 1360 | 580 | 70GB |
| LMDeploy（FP16） | 1 | 60 | 32 | 17GB |
| LMDeploy（FP16） | 32 | 1250 | 210 | 60GB |
| LMDeploy（W4A16） | 32 | 1680 | 140 | 35GB |
| LMDeploy（W4A16） | 64 | 1950 | 380 | 38GB |
数据背后有几个值得解读的现象。第一，单并发下三者差异很小，都在60 tokens/s上下，此时瓶颈是模型本身的前向计算，框架的调度优化发挥不出来。框架的价值从中高并发开始显现：并发32时vLLM比TGI高出约23%，这正是PagedAttention减少显存碎片带来的并发容量提升。
第二，TTFT的差距在高并发下被放大。并发64时TGI的首字延迟接近600ms，而vLLM和LMDeploy（量化版）都控制在400ms左右。对聊天类应用来说，TTFT直接决定用户感知，如果业务对首响时间敏感，这个指标比总吞吐更重要。
第三，LMDeploy的W4A16量化版是显存受限场景的明显赢家：吞吐最高，显存却只用了一半。这意味着同一张卡，量化版可以再叠加更多副本或者跑更大的模型。当然量化有精度损失，一般在1%以内，上线前建议用自己的评测集验证一下质量。
如何根据业务场景做选型
没有绝对的最优框架，只有匹配场景的选择。如果你的业务是高并发的API服务，比如给C端产品提供对话能力，请求量大且需要尽量压低单token成本，vLLM是首选，它的吞吐表现和社区活跃度都是第一梯队，遇到问题也容易找到答案。
如果你的团队重度使用HuggingFace生态，模型迭代频繁，需要经常切换不同结构的模型，TGI的易用性和工程化封装能省不少运维成本。它的OpenAI兼容接口和多机张量并行支持也很成熟，代价是极限性能略低一些。
如果显存预算紧张，或者明确要用InternLM系列模型，LMDeploy值得优先评估，尤其是量化部署路线，能实现在消费级显卡上跑大模型的可行性。另外LMDeploy的TurboMind引擎在长上下文场景的表现也不错。实践中也可以组合使用：开发环境用TGI快速验证，生产环境用vLLM或LMDeploy量化版压成本。
最后提醒一点，框架版本迭代很快，vLLM几乎每周都有优化合入，测试结论的时效性有限。真正靠谱的做法是把这篇文章的测试方案搬到自己的硬件和业务数据上复测一遍，用真实流量特征（输入输出长度分布、峰值并发）得到的数字，才是做架构决策的依据。