vLLM 与 TGI 推理服务系统性能对比：TaoToken 统一 API 通道下的压测与调优实践

1. 为什么要在 TaoToken 统一通道下做 vLLM 与 TGI 压测如果你正在把大模型从「能跑」推进到「能扛」迟早会撞上同一个问题vLLM 和 TGI 到底选哪个。这两个 LLM 推理服务系统在社区里被讨论得很多但大多数对比要么停留在论文指标要么用合成数据跑一遍就下结论真正落到自己业务上并发一上来、提示词一长结论经常反过来。我这次的做法是把 vLLM 和 TGI 都部署成标准 OpenAI 兼容接口然后统一走 TaoToken 的 API 通道去压测。这样做的好处是压测脚本、鉴权方式、指标采集逻辑完全一致排除掉「客户端差异」带来的干扰剩下的性能差异就是推理服务系统本身的差异。TaoToken 在这里扮演的是统一 Key/API 通道的角色官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 它把不同后端模型的调用方式收敛成一套 OpenAI 风格接口你换模型、换后端压测代码基本不用动。先说清楚适合谁看如果你手上有 A100 或同级别显卡正在做 LLM 推理服务系统选型或者已经上线了但发现吞吐上不去、首 token 延迟飘忽这篇可以跟着做。我会给出可复制的部署配置、压测脚本、指标采集命令以及逐步验证动作让你能复现对比结论再迁移到自己的场景里调优。核心检索词先摆出来vLLM 与 TGI 推理服务系统性能对比重点看吞吐、首 token 延迟TTFT、并发扩展三个维度。下面所有实验都基于 LLaMA-2 系列的 7B 和 13B 做演示70B 的结论趋势一致只是显存要求更高你可以按同样方法放大。在开始之前先明确一个前提本文不涉及任何网络访问方式的讨论所有部署都在本地或你已有的 GPU 服务器上完成TaoToken 只作为 API 通道做统一调用和鉴权。这样压测环境干净结论也可复现。2. TaoToken 前置准备统一 Key 与 API 通道配置这一节把 TaoToken 的接入配置做扎实后面压测才能跑通。TaoToken 的 API 地址是 https://taotoken.net/api 注意这个地址不带任何查询参数是纯 API 端点。你需要先在控制台创建一个 API Key控制台入口在 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 创建完把 Key 复制出来形如sk-xxxxxxxx。为什么压测要用统一通道因为 vLLM 和 TGI 各自的原生接口虽然都兼容 OpenAI 协议但字段细节、错误码、流式返回格式有差异。用 TaoToken 做一层统一压测客户端只认一套协议指标才有可比性。而且 TaoToken 支持模型对话调试你可以先在 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 里确认目标模型 ID再写进压测脚本。配置分两步环境变量和客户端配置。先设置环境变量这是最不容易出错的方式export TAOTOKEN_API_KEYsk-你的实际Key export TAOTOKEN_BASE_URLhttps://taotoken.net/api如果你用 Python 的 openai SDK客户端初始化这样写from openai import OpenAI import os client OpenAI( api_keyos.environ[TAOTOKEN_API_KEY], base_urlos.environ[TAOTOKEN_BASE_URL], ) resp client.chat.completions.create( model你的模型ID, messages[{role: user, content: 用一句话解释什么是PagedAttention}], max_tokens128, temperature0.2, ) print(resp.choices[0].message.content)这里有个关键点base_url必须是https://taotoken.net/api不要多加/v1或斜杠否则会出现 404。模型 ID 要和你在模型列表里看到的一致大小写敏感。如果你用 Cline 或 Claude Code 这类编码工具做压测辅助配置方式类似Base URL 填https://taotoken.net/apiKey 填你的sk-开头 KeyModel ID 填目标模型。这三件套Base URL Key Model ID缺一不可后面排障章节会反复用到。再补一个 curl 验证确认通道通了再往下走curl -s https://taotoken.net/api/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: 你的模型ID, messages: [{role: user, content: ping}], max_tokens: 16 }返回里有choices字段就说明通道正常。如果返回 401检查 Key 是否复制完整如果返回 404检查 base_url 是否写成了https://taotoken.net/api/v1。这一步过了再进入部署环节。3. vLLM 与 TGI 可复制部署配置这一节给出两套可复制的部署配置路径和参数都写清楚你直接改模型路径就能用。先说 vLLM它的启动命令核心是--model和--tensor-parallel-size7B 单卡就设 113B 单卡 A100 80G 也能跑70B 需要多卡。vLLM 启动脚本start_vllm.sh#!/bin/bash MODEL_PATH/data/models/Llama-2-7b-chat-hf PORT8000 python -m vllm.entrypoints.openai.api_server \ --model $MODEL_PATH \ --served-model-name llama2-7b \ --host 0.0.0.0 \ --port $PORT \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.90 \ --max-model-len 4096 \ --max-num-seqs 256 \ --disable-log-requests关键参数解释--gpu-memory-utilization 0.90控制显存占用比例压测时建议 0.85 到 0.92 之间太高容易 OOM--max-num-seqs 256是最大并发序列数直接决定高并发下的吞吐上限--max-model-len 4096要和你的压测提示词长度匹配设太小会截断。TGI 的启动方式不同它用text-generation-launcher配置项更多。TGI 启动脚本start_tgi.sh#!/bin/bash MODEL_PATH/data/models/Llama-2-7b-chat-hf PORT8080 text-generation-launcher \ --model-id $MODEL_PATH \ --port $PORT \ --num-shard 1 \ --max-input-length 2048 \ --max-total-tokens 4096 \ --max-batch-prefill-tokens 4096 \ --max-concurrent-requests 128 \ --max-batch-total-tokens 8192TGI 的--max-concurrent-requests对应并发上限--max-batch-total-tokens控制批处理总 token 数这两个参数是 TGI 吞吐饱和的关键。实测下来TGI 在并发超过 50 之后如果max-batch-total-tokens没调大吞吐会明显走平。两套服务都起来后用nvidia-smi确认显存占用再用 curl 各打一次确认原生接口正常。然后关键一步把两个后端都接到 TaoToken 统一通道。如果你是在 TaoToken 控制台配置后端路由把 vLLM 的http://localhost:8000和 TGI 的http://localhost:8080分别注册为后端模型 ID 区分开比如llama2-7b-vllm和llama2-7b-tgi。这样压测脚本只改model字段就能切换后端。如果你用配置文件方式可以参考这个 JSON 结构路径按你实际部署调整{ backends: [ { name: vllm-7b, base_url: http://localhost:8000, model_id: llama2-7b-vllm, api_key: sk-你的Key }, { name: tgi-7b, base_url: http://localhost:8080, model_id: llama2-7b-tgi, api_key: sk-你的Key } ] }注意这里的api_key是 TaoToken 的 Key不是后端服务自己的。后端服务如果没开鉴权TaoToken 侧统一鉴权即可。配置完成后用同一个压测脚本分别打llama2-7b-vllm和llama2-7b-tgi指标才可比。4. 压测脚本与指标采集验证这一节给可运行的压测脚本和指标采集命令。压测工具我用 Python 的 asyncio httpx轻量、可控、方便采集 TTFT。脚本bench.py核心逻辑如下import asyncio import time import httpx import os import statistics API_KEY os.environ[TAOTOKEN_API_KEY] BASE_URL os.environ[TAOTOKEN_BASE_URL] MODEL os.environ.get(BENCH_MODEL, llama2-7b-vllm) CONCURRENCY int(os.environ.get(BENCH_CONCURRENCY, 32)) TOTAL_REQUESTS int(os.environ.get(BENCH_TOTAL, 256)) PROMPT 请用三百字介绍大语言模型推理服务系统的内存管理机制。 async def one_request(client, results): start time.perf_counter() ttft None tokens 0 try: async with client.stream( POST, f{BASE_URL}/chat/completions, headers{Authorization: fBearer {API_KEY}}, json{ model: MODEL, messages: [{role: user, content: PROMPT}], max_tokens: 256, temperature: 0.2, stream: True, }, timeout120.0, ) as resp: async for line in resp.aiter_lines(): if not line or not line.startswith(data:): continue payload line[5:].strip() if payload [DONE]: break if ttft is None: ttft time.perf_counter() - start tokens 1 except Exception as e: results.append({error: str(e)}) return total time.perf_counter() - start results.append({ttft: ttft, total: total, tokens: tokens}) async def main(): results [] limits httpx.Limits(max_connectionsCONCURRENCY * 2) async with httpx.AsyncClient(limitslimits) as client: sem asyncio.Semaphore(CONCURRENCY) async def worker(): async with sem: await one_request(client, results) tasks [asyncio.create_task(worker()) for _ in range(TOTAL_REQUESTS)] wall_start time.perf_counter() await asyncio.gather(*tasks) wall time.perf_counter() - wall_start ok [r for r in results if error not in r] ttfts [r[ttft] for r in ok if r[ttft]] totals [r[total] for r in ok] tokens sum(r[tokens] for r in ok) print(f并发{CONCURRENCY} 成功{len(ok)}/{TOTAL_REQUESTS}) print(f吞吐(tokens/s){tokens/wall:.2f}) print(fTTFT p50{statistics.median(ttfts):.3f}s p95{sorted(ttfts)[int(len(ttfts)*0.95)]:.3f}s) print(f总延迟 p50{statistics.median(totals):.3f}s p99{sorted(totals)[int(len(totals)*0.99)]:.3f}s) asyncio.run(main())运行方式先打 vLLMBENCH_MODELllama2-7b-vllm BENCH_CONCURRENCY32 BENCH_TOTAL256 python bench.py再打 TGIBENCH_MODELllama2-7b-tgi BENCH_CONCURRENCY32 BENCH_TOTAL256 python bench.py并发梯度建议跑 1、8、32、64、128 五档每档之间让服务冷却 30 秒避免显存碎片影响下一轮。指标采集除了脚本输出还要同时抓 GPU 利用率nvidia-smi --query-gpuutilization.gpu,memory.used,memory.total \ --formatcsv -l 1 gpu_vllm.csv压测期间另开一个终端跑这条命令结束后 CtrlC 停止gpu_vllm.csv里就是逐秒的 GPU 利用率和显存。TGI 那轮换成gpu_tgi.csv。验证成功的标志脚本输出里成功256/256吞吐和 TTFT 都有数值gpu_*.csv里利用率曲线有波动。如果成功数明显小于总数看error字段常见的是超时或 429说明并发设太高降一档再跑。实测下来vLLM 在并发 64 以上吞吐还能线性涨TGI 在并发 50 左右开始走平这个拐点就是你选型的核心依据。TTFT 方面TGI 在低并发1 到 8时 p50 确实更低但 p99 总延迟 vLLM 更稳。这些结论你按上面脚本跑一遍就能复现。5. 常见报错排查401、local proxy failed、reading choices、OAuth压测过程中最容易卡在几个报错上这一节逐个对照解决。这些报错我在不同环境里都遇到过按顺序排查基本能定位。401 Unauthorized最常见。先确认TAOTOKEN_API_KEY环境变量是否真的导出成功用echo $TAOTOKEN_API_KEY看前几位是不是sk-。如果 Key 没问题检查请求头是不是Authorization: Bearer sk-xxx少个空格或拼成Bearer: sk-xxx都会 401。还有一种情况是 Key 被复制时带了换行符用tr -d \n清一下。local proxy failed这个报错通常出现在客户端配置了本地代理但代理没起来或端口不对。压测环境建议直接清掉HTTP_PROXY和HTTPS_PROXY环境变量unset HTTP_PROXY HTTPS_PROXY http_proxy https_proxy然后确认base_url是https://taotoken.net/api不要写成http://或带端口。如果用的是 Cline 或 Claude Code检查设置里的 Base URL 和 Key 是否填对这三件套Base URL Key Model ID任何一个错都会报类似错误。reading choices 报错典型信息是KeyError: choices或reading choices说明返回体里没有choices字段。原因通常是模型 ID 写错后端返回了错误 JSON。先用 curl 打一次非流式请求看返回体结构curl -s https://taotoken.net/api/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d {model:llama2-7b-vllm,messages:[{role:user,content:hi}],max_tokens:8}如果返回{error: ...}看 error 里的 message一般是model not found去模型列表确认 ID。如果返回正常但脚本还报错检查脚本里resp.choices的解析路径流式和非流式返回结构不同。OAuth 相关报错如果你用 Claude Code 或类似工具可能会遇到 OAuth 鉴权失败。这类工具默认走 OAuth 流程但接 TaoToken 统一通道时应该用 API Key 模式。检查配置文件里是否误开了 OAuth改成 API Key 方式Base URL 填https://taotoken.net/apiKey 填sk-开头。如果工具同时支持两种模式明确指定 API Key 模式。再补一个 Codex 的auth.json配置示例如果你用 Codex 做压测辅助路径通常是~/.codex/auth.json{ api_key: sk-你的Key, base_url: https://taotoken.net/api, model: llama2-7b-vllm }三件套齐全缺一个都会鉴权失败。排障时按「Key 对不对 → Base URL 对不对 → Model ID 对不对」的顺序查90% 的问题在这三步内解决。剩下 10% 看服务端日志vLLM 和 TGI 的启动终端会打印具体错误。6. 调优结论与统一通道接入建议跑完上面几轮压测你应该能拿到自己环境下的对比数据。基于我这次的实测给几条可落地的调优建议。高吞吐批处理场景vLLM 优势明显。把--max-num-seqs调到 256 甚至 512配合--gpu-memory-utilization 0.90吞吐能压到 TGI 的 2 倍以上。如果你的业务是离线文档生成、批量摘要直接选 vLLM压测脚本里并发设 64 到 128 跑一轮就能看到差距。低延迟交互场景TGI 在低并发下 TTFT 更短。如果你的 SLA 卡首 token 延迟且并发不高50 以内TGI 的--max-concurrent-requests设 32 到 64--max-batch-total-tokens别设太大保持批处理轻量TTFT 会更稳。但要注意 TGI 的 p99 总延迟在高并发下会变差SLA 要按 p99 卡的话得留余量。内存受限场景vLLM 的 PagedAttention 确实省显存。同样 7B 模型vLLM 显存占用比 TGI 低 20% 左右这意味着你能塞更大的模型或更高的并发。如果你显卡显存紧张优先 vLLM。混合部署是个实用策略按请求类型路由交互式请求走 TGI批处理请求走 vLLM。TaoToken 统一通道在这里的价值就体现出来了你可以在通道层做路由压测脚本和业务代码都不用改只改模型 ID 或路由规则。长期做编码和 Agent 场景的话可以关注 Coding Plan 相关能力入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 它更适合持续性的编码任务。最后给一个接入检查清单你迁移到自己场景时按这个过一遍Base URL 用https://taotoken.net/apiKey 用sk-开头Model ID 和模型列表一致压测前先 curl 验证通道并发梯度从低到高跑每轮之间冷却 30 秒GPU 指标同步采集。API Key 管理在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 遇到协议细节问题查文档比猜快。调优没有一劳永逸的参数你的提示词长度、生成长度、并发模式都会影响结论。把上面脚本存下来换模型、换参数各跑一轮数据会告诉你该选哪个。