笙亿网络策划

vLLM与TGI部署Llama-3-8B吞吐量和首Token延迟实测对比

约 5 分钟读完 20 阅
文章导读
vLLM 与 TGI 哪个更适合部署 Llama-3-8B，不能靠拍脑袋或经验推断，因为两者的调度策略和显存管理不同，结果会随并发数、输入输出长度、量化方式、GPU 型号而反转。与其依赖他人数据，不如按一套统一条件自己跑一轮对比。下面的流程不追求实验室级精确，但能帮你得到可复用的选型依据。
📋 目录
  1. Ⅰ 测试前统一环境与模型版本
  2. Ⅱ 指标定义与采集方法
  3. Ⅲ 负载测试设计：从低并发到高并发
  4. Ⅳ 结果解读与选型建议
A A

vLLM 与 TGI 哪个更适合部署 Llama-3-8B，不能靠拍脑袋或经验推断，因为两者的调度策略和显存管理不同，结果会随并发数、输入输出长度、量化方式、GPU 型号而反转。与其依赖他人数据，不如按一套统一条件自己跑一轮对比。下面的流程不追求实验室级精确，但能帮你得到可复用的选型依据。

同等硬件、模型和请求负载下，vLLM 与 TGI 的吞吐量和首 Token 延迟差异是真实存在的，但谁更好不固定。建议先跑 3 次取中位数，重点比较吞吐量和首 Token 延迟的 P95；选型时也要看是否支持你的功能需求（如 LoRA、流式输出、量化格式），不能只看峰值指标。

测试前统一环境与模型版本

对比测试最忌变量失控。请固定 GPU 型号、驱动/CUDA 版本、容器运行时，使用同一个 Llama-3-8B 模型权重（推荐原始 fp16 或统一量化后的同格式）。如果比较量化，要保证两者加载的是同一个 GGUF 或 AWQ 文件，而不是一个用原版、一个用量化版。

启动服务时，建议给 vLLM 和 TGI 设置接近的共享显存上限、最大输入长度和最大输出长度。以下是两个服务的最小启动骨架，镜像名和参数可按实际版本替换：

# vLLM 示例（镜像名需替换为实际标签）
docker run `--gpus` all `--shm-size`=2g \
  vllm/vllm-openai:latest \
  `--model` /path/to/Llama-3-8B \
  `--max-model-len` 8196 \
  `--gpu-memory-utilization` 0.9 \
  `--trust-remote-code`

# TGI 示例（镜像名需替换为实际标签）
docker run `--gpus` all `--shm-size`=2g \
  ghcr.io/huggingface/text-generation-inference:latest \
  `--model-id` /path/to/Llama-3-8B \
  `--max-total-tokens` 8196 \
  `--max-input-tokens` 4000 \
  `--max-batch-total-tokens` 18000

启动后先用单条请求验证服务正常，再开始压测。记录下实际加载的模型路径、量化方式、显存占用，以及服务日志里是否有 fallback 或重试信息。

vLLM与TGI部署Llama-3-8B吞吐量和首Token延迟实测对比

指标定义与采集方法

吞吐量通常定义为“每秒生成的输出 tokens 总数”，而不是请求数。首 Token 延迟（TTFT）是客户端发出请求到收到第一个输出 token 的时间。两者都能从服务端日志或客户端计时获得，推荐用客户端统一记录，避免服务端预填充阶段干扰。

  • 吞吐量：压测工具统计的总输出 tokens 除以总耗时。如果每个请求输出长度不同，应记录每个请求的 tokens 数累计求和。
  • 首 Token 延迟：从发送时间到收到第一个 chunk 的时间。流式接口下这个值更容易采集。
  • 端到端延迟：完整响应时间。它受网络和客户端影响更大，建议只做辅助参考。

建议同时记录显存峰值和是否触发 swap。触发 swap 后延迟会急剧上升，这种数据要标记出来，不能混入正常数据取平均。

vLLM与TGI部署Llama-3-8B吞吐量和首Token延迟实测对比

负载测试设计：从低并发到高并发

不要只跑一个并发数。建议从 1、4、8、16、32、64 等梯度递增（具体上限视显存调整），每个并发下用固定输入长度（例如 512 tokens）和固定输出长度（例如 128 tokens）跑 2-3 分钟，记录吞吐量和 TTFT 的均值、P50、P95。这样才能看到服务在低并发和高并发下的行为差异。

下面是用 hey 发流式请求的骨架，实际需要根据你的服务地址和接口格式调整：

hey -n 200 -c 32 -m POST -H "Content-Type: application/json" \
  -d '{"prompt": "Once upon a time", "max_tokens": 128, "stream": true}' \
  http://localhost:8000/v1/completions

如果你的服务没有 OpenAI 兼容接口，就写一个简单的 Python 脚本用 requests 循环发送，并自己统计耗时和 token 计数。注意：压测客户端本身的连接复用要验证，避免开新连接拖慢测试。

vLLM与TGI部署Llama-3-8B吞吐量和首Token延迟实测对比

结果解读与选型建议

对比时不要只看吞吐量最高点。你要先确认自己的业务是“高并发小请求”还是“低并发长输出”：

  • 如果首 Token 延迟要求苛刻（如聊天助手），重点看并发小于 8 时的 P95 TTFT，哪个更平稳。
  • 如果追求整体吞吐（如离线批处理），重点看最高稳定吞吐量，同时观察此时显存是否接近极限。
  • 如果并发上去后 TTFT 突然飙升，通常是批处理排队或 swap 触发，要分清楚是哪个服务先发生。

最后，把每次测试的配置、结果和备注整理成一张表，再结合部署易用性（如 API 兼容性、文档质量、故障恢复）做决定。性能测试只能排除“完全不能用”的选项，不能告诉你“更好”，只有你的业务场景能定义“更好”。