LLM推理优化实战：vLLM vs TGI 在 GPU 资源受限场景下的真实体验

大家好，我是老张，过去半年在边缘侧和中小团队私有化部署场景里反复折腾 vLLM 和 TGI（Text Generation Inference），手头常是单卡 A10 或 24G 的 RTX 4090，显存吃紧、预算有限——今天就来分享一份「不吹不黑」的对比实测笔记。

测试环境与基准配置

• 硬件：NVIDIA RTX 4090（24GB VRAM），Ubuntu 22.04，CUDA 12.1
• 模型：Qwen2-7B-Instruct（AWQ 4-bit 量化版，约 5.2GB 显存占用）
• 请求负载：并发数 8，输入长度 128，输出长度 256，使用 locust 模拟真实用户流

注意：所有测试均关闭 --enable-prefix-caching（vLLM）和 --flash-attn（TGI）以外的高级特性，确保公平性。量化模型统一使用 AWQ，避免因权重格式差异干扰结论。

吞吐量与延迟：谁更扛得住并发？

我们用 curl + time 做了 100 次批请求压测（batch_size=4）：

vLLM 在吞吐上稳赢，这得益于其 PagedAttention 内存管理机制——它把 KV 缓存切分成固定大小的块，按需分配，大幅降低碎片率。而 TGI 的默认 continuous batching 虽然也做批处理，但 KV 缓存仍按 sequence 对齐，在小显存卡上容易“撑爆”。

显存占用与启动时间：小内存卡用户的生死线

启动时间尤其关键：运维同学反馈，客户现场重启服务时，等 90 秒以上会直接投诉

# vLLM 启动命令（精简版）
python -m vllm.entrypoints.api_server \
 --model Qwen2-7B-Instruct \
 --quantization awq \
 --tensor-parallel-size 1 \
 --gpu-memory-utilization 0.9 \
 --max-model-len 4096

# TGI 启动命令（对应配置）
text-generation-inference \
 --model-id Qwen2-7B-Instruct \
 --quantize awq \
 --num-shard 1 \
 --max-total-tokens 8192 \
 --port 8080

• vLLM 平均启动耗时：6.2 秒（加载+初始化）
• TGI 平均启动耗时：14.8 秒（含 tokenizer 加载、shard 初始化、CUDA context 创建）

提示：TGI 在首次加载 AWQ 模型时会触发一次权重重排（repacking），若磁盘 I/O 慢（比如 SATA SSD），可能卡住 5 秒以上——我们踩了个坑，后来加了 --disable-custom-kernels 反而快了 2 秒，因为绕过了部分 CUDA kernel 编译。

实际部署建议：别只看 benchmark

根据我们落地的 5 个客户项目，总结出三条硬经验：

• 优先选 vLLM 的场景：

- 需要高并发低延迟（如客服机器人 API）
- 显存 ≤ 24GB，且必须跑 7B+ 模型
- 团队熟悉 Python 生态，愿意微调 vllm API Server（它原生支持 OpenAI 兼容接口）

• TGI 更适合的场景：

- 已深度集成 Rust/Python 混合栈（TGI 的 text-generation-server 是 Rust 写的，稳定性高）
- 需要细粒度控制采样参数（如 best_of, seed 的原子性保证更强）
- 运维习惯 Docker + Prometheus 监控（TGI 的 /metrics 接口开箱即用）

• 通用避坑清单：

1. 不要在 vLLM 中盲目开启 --enable-chunked-prefill（小模型下反而增延迟）
2. TGI 的 --max-input-length 必须 ≤ --max-total-tokens，否则静默失败
3. 两者都建议搭配 nginx 做连接复用和超时兜底（我们曾因客户端 keep-alive 超时导致 vLLM 连接堆积）

总结与讨论

说实话，vLLM 在资源受限场景下表现更均衡：启动快、显存省、吞吐高；TGI 则胜在工程健壮性和可观测性。没有银弹，只有适配——我们的最终方案往往是：开发/测试用 vLLM 快速迭代，生产交付给客户时，用 TGI + 自定义健康检查脚本兜底。

你用过哪个？有没有在 A10/A16 上跑通 13B 模型的经验？欢迎评论区聊聊你踩过的坑，或者贴出你的 nvidia-smi 截图一起分析