AI 推理优化选型对比：vLLM、Triton 与 TGI 在不同业务场景下的实测性能差异

AI 推理优化选型对比：vLLM、Triton 与 TGI 在不同业务场景下的实测性能差异

一、推理引擎选型的核心矛盾：吞吐最优 vs 延迟最优 vs 部署复杂度最优

推理引擎的选型不是简单的"哪个更快"——因为"快"的定义取决于业务场景：对话生成场景追求 TTFT（首 Token 延迟）最低，让用户尽快看到输出；长文本摘要场景追求吞吐量最大，让 GPU 在单位时间内处理更多请求；多模型共存场景追求部署灵活度最高，在单 GPU 上同时服务多个模型。这三个优化目标在技术上是冲突的——降低 TTFT 通常需要减小 Batch Size（更少的排队延迟），但减小 Batch Size 会降低吞吐量；增大 Batch Size 提升吞吐量但增加排队延迟（TTFT 变长）。

核心痛点在于：选型决策必须基于业务场景的优先级排序，而非引擎的理论性能排名。本次选型对比将围绕三个典型业务场景（对话生成、长文本摘要、多模型共存），在相同硬件环境（A100 80GB 单卡）下实测 vLLM、Triton 和 TGI 的性能差异，给出场景化的选型建议。

二、选型对比架构：三个场景下的测试方案设计

三个业务场景的测试方案设计必须模拟真实业务负载，而非简单的 Benchmark 脚本：

三个场景的请求特征差异极大——对话生成的 Prompt 短、输出短、并发高，对 TTFT 和 TPOT 的 SLA 要求最严格；长文本摘要的 Prompt 长、输出中等、并发低，对吞吐量的要求最高；多模型共存场景需要 GPU 分时复用，对部署灵活度的要求最高。不同的请求特征使得三个场景的最优引擎可能完全不同。

三、实测数据对比：三个场景下的引擎性能差异

3.1 测试框架实现

# 多场景推理引擎 Benchmark 测试框架
# 目的：模拟三个业务场景的真实负载，量化引擎性能差异

import time
import asyncio
from dataclasses import dataclass

@dataclass
class ScenarioConfig:
"""场景配置：定义请求特征与 SLA 目标"""
name: str
prompt_lengths: tuple # Prompt Token 数范围
output_lengths: tuple # 输出 Token 数范围
concurrency: int # 并发 QPS
sla_ttft_ms: float # TTFT SLA 目标
sla_throughput: float # 吞吐 SLA 目标

# 三个场景配置
SCENARIOS = {
"对话生成": ScenarioConfig(
name="对话生成",
prompt_lengths=(100, 500),
output_lengths=(50, 200),
concurrency=50,
sla_ttft_ms=200,
sla_throughput=0, # TTFT 优先，吞吐无硬性目标
),
"长文本摘要": ScenarioConfig(
name="长文本摘要",
prompt_lengths=(4000, 8000),
output_lengths=(200, 500),
concurrency=10,
sla_ttft_ms=0, # 吞吐优先，TTFT 无硬性目标
sla_throughput=1500, # 吞吐 > 1500 token/s
),
"多模型共存": ScenarioConfig(
name="多模型共存",
prompt_lengths=(100, 4000), # 两个模型的混合负载
output_lengths=(50, 300),
concurrency=15, # 7B: 10 QPS + 70B: 5 QPS
sla_ttft_ms=300,
sla_throughput=500,
),
}

async def run_scenario_benchmark(
engine_client,
scenario: ScenarioConfig,
duration_seconds: int = 120,
):
"""
在指定场景下对推理引擎执行 120s 持续压测
为什么测 120s 而非 30s：
短时间测试可能落在引擎预热阶段，数据不稳定
120s 覆盖了预热、稳态、以及 GC/Cache 换页的周期
"""
ttft_list = []
tpot_list = []
total_tokens = 0
start_time = time.perf_counter()

# 按场景的并发度发送请求
tasks = []
for _ in range(scenario.concurrency):
task = asyncio.create_task(
send_requests_continuously(
engine_client, scenario, duration_seconds
)
)
tasks.append(task)

results = await asyncio.gather(*tasks)

# 汇总结果
for r in results:
ttft_list.extend(r["ttft_list"])
tpot_list.extend(r["tpot_list"])
total_tokens += r["total_tokens"]

elapsed = time.perf_counter() – start_time

return {
"scenario": scenario.name,
"ttft_p50_ms": statistics.median(ttft_list) * 1000,
"ttft_p99_ms": sorted(ttft_list)[int(len(ttft_list) * 0.99)] * 1000,
"throughput_tokens_per_sec": total_tokens / elapsed,
"sla_ttft_met": sorted(ttft_list)[int(len(ttft_list) * 0.99)] * 1000 < scenario.sla_ttft_ms,
}

3.2 实测数据结果

在 A100 80GB 单卡，LLaMA-2-70B 模型下：

场景一：对话生成（TTFT 优先）

场景二：长文本摘要（吞吐优先）

场景三：多模型共存（部署灵活度优先）

四、选型决策矩阵：场景特征与引擎能力的匹配

关键 Trade-off：vLLM 在对话生成和长文本摘要两个场景均最优，但无法支持多模型共存。Triton 在多模型共存场景唯一可用，但单模型性能落后 vLLM 约 15-20%。这个 Trade-off 的决策取决于业务是否需要多模型共存——如果只有单一模型，vLLM 是最优选择；如果需要多模型共存，只能选择 Triton 并接受 15-20% 的性能损失。

部署复杂度 Trade-off：TGI 的部署复杂度最低（Docker 一键启动），但性能落后 vLLM 约 20%。如果项目时间紧迫且性能 SLA 宽松（TTFT P99 < 300ms），TGI 可以用 10 分钟完成部署；如果性能 SLA 严格（TTFT P99 < 200ms），必须选择 vLLM 但部署时间需要 1-2 小时（配置 Continuous Batching + PagedAttention 参数）。

五、总结

推理引擎选型对比的核心结论是场景化决策而非通用排名：

落地建议：第一步确认业务场景的优先级（TTFT/吞吐/灵活度/易用性）；第二步根据优先级在决策矩阵中匹配推荐引擎；第三步在目标硬件上执行场景化 Benchmark 验证推荐方案；第四步根据实测数据微调引擎配置参数（Batch Size、KV Cache 大小、量化方案）；第五步记录选型决策依据与约束条件，供后续架构演进参考。