4. 主流推理框架概览：TensorRT-LLM、vLLM、FasterTransformer、TGI等对比

4.1 为什么需要专门的推理框架

大语言模型（LLM）的训练与推理在工程目标上存在显著差异。训练阶段追求高吞吐的批量矩阵运算，而推理阶段则面临更复杂的约束：低延迟、高并发、动态请求长度以及显存碎片化。通用深度学习框架（如PyTorch）在推理时往往因为以下原因无法发挥硬件全部潜力：

  • 动态图开销：PyTorch的Eager模式每次前向传播都会产生算子调度和Python解释开销。
  • 显存管理粗放：KV Cache的分配与释放频繁，容易产生碎片，且缺乏跨请求的显存复用机制。
  • 缺乏批处理优化：无法有效处理变长序列的连续批处理（Continuous Batching），导致GPU利用率低下。

因此，业界出现了多个专门针对LLM推理优化的框架。它们通过图编译、算子融合、KV Cache管理、量化和并行策略等手段，将推理性能推向极致。理解这些框架的定位与差异，是进行性能选型的第一步。

核心判断：推理框架的核心价值不在于“能跑模型”，而在于“在相同硬件下，能支撑更高的吞吐或更低的延迟”。选型前需明确自身业务是偏向在线交互（延迟敏感）还是离线批处理（吞吐优先）。

4.2 四大主流框架核心原理与定位

目前讨论度最高的四个框架分别是：TensorRT-LLM、vLLM、FasterTransformer和HuggingFace TGI。它们并非完全替代关系，而是处于不同的技术代际与生态位。

4.2.1 TensorRT-LLM：NVIDIA官方的高性能引擎

TensorRT-LLM（简称TRT-LLM）是NVIDIA在2023年10月发布的推理框架，它并非从零编写，而是将FasterTransformer的成熟算子库与TensorRT的图优化能力深度融合。其核心特点包括：

  • 编译期优化：将模型编译为TensorRT引擎，支持层融合、内核自动调优（Tactic Selection）。
  • 运行时KV Cache管理：采用Paged KV Cache（受vLLM启发），支持块级显存分配。
  • 多精度支持：原生支持FP8、INT4/INT8量化，且针对Hopper（H100）和Ada架构深度优化。
  • 多卡并行：内置张量并行（TP）与流水线并行（PP）支持，无需额外编写通信代码。

4.2.2 vLLM：PagedAttention的开创者

vLLM由UC Berkeley开发，其最大的贡献是提出了PagedAttention技术，灵感来源于操作系统的虚拟内存分页机制。它将KV Cache划分为固定大小的块（Block），通过块表（Block Table）实现非连续显存映射。这一设计带来了两个直接收益：

  • 显存利用率接近100%：消除了传统预分配方式下的内部碎片与外部碎片。
  • 高吞吐连续批处理：请求完成或新请求到达时，无需等待整个Batch结束，即可动态插入或退出。

vLLM采用Python编写，与PyTorch生态无缝衔接，对HuggingFace模型结构兼容性极好，因此成为学术界与中小规模部署的首选。

4.2.3 FasterTransformer：老牌算子库

FasterTransformer（FT）是NVIDIA早期开源的Transformer推理加速库，以C++/CUDA算子形式提供。它不提供完整的模型服务化能力，而是作为底层加速组件被其他框架集成。例如，TensorRT-LLM的早期版本就大量复用了FT的算子。FT的优势在于极致优化的GEMM（通用矩阵乘法）与Attention内核，但缺点是缺乏动态批处理与显存管理，用户需要自行处理请求调度。

4.2.4 HuggingFace TGI：生态友好的服务化方案

Text Generation Inference（TGI）是HuggingFace推出的推理服务框架，定位是开箱即用的生产级服务。它集成了Continuous Batching、张量并行、量化（GPTQ/AWQ）等功能，并且对HuggingFace模型库的兼容性最好。TGI在性能上通常弱于TensorRT-LLM和vLLM，但其优势在于部署简单、功能丰富（如消息队列、流式输出、推理日志），适合快速搭建原型或对性能要求不极致的场景。

主流推理框架技术定位与生态关系 NVIDIA GPU 硬件层（H100 / A100 / L40S ...） 底层算子库 / 编译基础设施 CUDA Kernels · TensorRT · FasterTransformer 算子集 TensorRT-LLM NVIDIA 官方 图编译 + 引擎 Paged KV Cache FP8/INT4 量化 TP/PP 多卡并行 极致性能 vLLM UC Berkeley PagedAttention Continuous Batching PyTorch 原生 HF 模型兼容 高吞吐 · 易用 FasterTransformer NVIDIA 早期 C++/CUDA 算子 无动态批处理 无显存管理 被 TRT-LLM 继承 底层组件 HuggingFace TGI HuggingFace 服务化方案 Continuous Batching 量化 (GPTQ/AWQ) 生态兼容 快速部署 ↑ 越靠上越接近应用层 · 越靠下越接近硬件层 关键差异速览 • 编译方式：TRT-LLM 静态图编译；vLLM/TGI 动态图 + 运行时优化 • 显存管理：TRT-LLM 与 vLLM 均支持 Paged KV Cache；FT 不支持 • 部署形态：TGI 提供完整 HTTP 服务；其余需搭配 Triton/自建 API

4.3 多维度对比：从吞吐到生态

为了更直观地指导选型，下表从性能、易用性、功能特性和适用场景四个维度进行对比。请注意，性能数据会因GPU型号、模型大小、Batch Size和量化方案不同而有显著差异，下表为经验性结论。

对比维度 TensorRT-LLM vLLM FasterTransformer TGI
峰值吞吐 最高（编译优化） 高（PagedAttention） 较高（算子级） 中等
首Token延迟 低（引擎预热） 低 低 中低
动态批处理 支持 支持（核心优势） 不支持 支持
量化支持 FP8/INT4/INT8 GPTQ/AWQ/FP8 INT8/INT4 GPTQ/AWQ/FP8
多卡并行 TP/PP 原生 TP/PP（需配置） TP 支持 TP 支持
模型兼容 需转换引擎 HF 模型直接加载 需自定义脚本 HF 模型直接加载
服务化能力 需搭配 Triton 自带 API Server 无 自带完整 API
学习曲线 陡峭 平缓 陡峭 平缓

4.4 选型案例与场景复盘

4.4.1 案例一：高并发在线客服机器人

某互联网公司需要部署一个7B参数的对话模型，要求平均首Token延迟小于300ms，且需要支撑每秒50个并发请求。初期使用TGI快速上线，但发现GPU利用率仅40%左右。随后切换到vLLM，利用其Continuous Batching特性，将吞吐提升了2.3倍，GPU利用率达到85%。复盘结论：对于延迟不极端敏感、但并发量大的场景，vLLM的批处理收益最明显。

4.4.2 案例二：金融行业私有化部署

某银行采购了H100 GPU，要求运行70B模型并开启FP8量化，同时需要严格保证推理延迟的稳定性。由于对硬件利用率要求极高，且IT团队具备C++/CUDA能力，最终选择TensorRT-LLM。通过编译期优化，相比PyTorch原生推理延迟降低了约40%。复盘结论：当硬件成本敏感且团队技术储备充足时，TRT-LLM的极致性能值得投入。

常见误区：不要盲目追求“最高性能”的框架。TensorRT-LLM虽然吞吐最高，但模型转换过程可能遇到算子不支持、动态Shape受限等问题，调试成本较高。如果业务模型迭代频繁（每周更新），vLLM的“零转换”优势会大幅缩短上线周期。

4.4.3 误区复盘：FasterTransformer的“过时”标签

很多开发者认为FasterTransformer已被TensorRT-LLM完全取代。实际上，FT的算子设计思想仍被广泛借鉴，且在一些非标准模型结构（如自定义Attention变体）中，直接调用FT的底层GEMM内核反而比使用TRT-LLM的图编译更灵活。此外，FT不依赖TensorRT运行时，适合嵌入到自研的C++推理服务中。

4.5 选型决策清单

在实际项目中，建议按以下顺序进行框架选型评估：

  1. 明确约束：记录业务对延迟（P99）、吞吐（QPS）、显存上限的硬性要求。
  2. 评估模型迭代频率：若每周更新模型，优先考虑vLLM或TGI；若模型固定且追求极限，选择TRT-LLM。
  3. 检查硬件环境：确认GPU架构（Ampere/Ada/Hopper），TRT-LLM对Hopper的FP8支持最佳。
  4. 验证量化兼容性：使用AWQ/GPTQ量化时，需确认框架对量化算子的支持程度。
  5. 进行PoC测试：用相同的模型和请求负载，分别部署两个候选框架，测量吞吐、延迟和显存占用。

实操建议：如果团队刚接触LLM推理，建议从vLLM开始。它能在不修改模型代码的情况下获得接近TensorRT-LLM 80%的性能，且调试体验友好。当业务规模扩大、硬件成本成为瓶颈时，再逐步迁移到TensorRT-LLM。

← 上一章 📖 返回目录 下一章 →