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 参数）。

五、总结

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

1. 对话生成场景 vLLM 最优：TTFT P99 180ms 是唯一满足 < 200ms SLA 的引擎，吞吐量也最高。但无法支持多模型共存。

2. 长文本摘要场景 vLLM 最优：吞吐 1800 token/s 远超 SLA 目标，GPU 利用率 75% 最大化硬件投资回报。TGI 吞吐仅 1300 不达标。

3. 多模型共存场景 Triton 唯一可用：vLLM 和 TGI 都不支持单 GPU 多模型共存。Triton 的 MIG 分时复用是唯一方案，代价是单模型性能损失 15-20%。

4. 部署易用性场景 TGI 最优：Docker 一键部署，HuggingFace Hub 直接拉取模型，10 分钟上线。代价是性能落后 vLLM 约 20%。

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