（十六）32天GPU测试从入门到精通-LLM 推理引擎概览day14
目录
引言
大语言模型 (LLM) 的爆发式发展，使得推理引擎的选择成为生产部署的关键决策。不同的推理引擎在性能、功能、易用性上有显著差异。
LLM 推理引擎测试是 GPU 服务器评估的核心内容：
- 为什么需要专用 LLM 推理引擎？ 原生 PyTorch 推理效率低
- vLLM 的 PagedAttention 有什么优势？ 显存效率提升 10-20x
- TensorRT-LLM 性能最强吗？ NVIDIA GPU 上的最优选择
- 何时选择 llama.cpp？ CPU 推理、边缘部署场景
- 如何选择合适的引擎？ 场景需求决定技术选型
这些问题都指向一个核心主题：LLM 推理引擎概览。
LLM 推理的挑战
当你第一次尝试将大语言模型部署到生产环境时，很快会遇到一个现实问题：为什么直接用 PyTorch 加载模型进行推理，性能会如此糟糕？这背后涉及到 LLM 推理的几个核心挑战。
首先是显存瓶颈问题。一个 7B 参数的模型，仅权重就需要约 14GB 显存（FP16 精度），而这还只是"入场券"。实际推理过程中，KV Cache（键值缓存）会随着序列长度线性增长，激活值会随 batch size 扩大而膨胀。很多开发者都遇到过这样的场景：模型明明能加载，但一运行推理就 OOM（显存溢出）。这就是为什么需要专门的显存管理技术。
其次是计算密集的特性。Transformer 架构中的 Attention 机制具有 O(n²) 的时间复杂度，意味着序列长度翻倍，计算量会变成四倍。而解码过程是自回归的——必须等上一个 token 生成完才能生成下一个，这导致无法像训练那样大规模并行化。结果就是延迟高、吞吐量低，难以满足生产需求。
第三个挑战是请求的波动性。在生产环境中，用户请求的长度参差不齐，有的问一句话，有的需要长文档分析。输出长度同样不可预测，有时模型三言两语就回答完了，有时会生成一大段文字。这种不确定性使得预先分配资源变得困难，往往导致资源利用率低下——分配多了浪费，分配少了不够用。
最后是部署复杂性。多 GPU 之间的通信开销、动态批处理的调度逻辑、模型量化的精度权衡，每一个环节都需要专业知识。对于中小团队来说，运维成本高得令人望而却步。
正是这些挑战催生了专用 LLM 推理引擎的发展。从 2022 年的早期探索，到 2023 年 vLLM 和 TensorRT-LLM 的突破，再到 2024 年功能丰富化，推理引擎已经发展成为一个成熟的技术领域。理解这些引擎的原理和特性，是进行高效 LLM 部署的前提。
┌─────────────────────────────────────────────────┐
│ LLM 推理的主要挑战 │
├─────────────────────────────────────────────────┤
│ │
│ 显存瓶颈: │
│ ├── 模型权重：7B 模型 ~14GB (FP16) │
│ ├── KV Cache：随序列长度线性增长 │
│ ├── 激活值：随 batch size 增长 │
│ └── 结果：OOM 或 batch size 受限 │
│ │
│ 计算密集: │
│ ├── Attention: O(n²) 复杂度 │
│ ├── FFN: 大量矩阵乘法 │
│ ├── 解码：自回归，无法并行 │
│ └── 结果：延迟高，吞吐量低 │
│ │
│ 请求波动: │
│ ├── 请求长度不确定 │
│ ├── 输出长度不确定 │
│ ├── 并发请求波动 │
│ └── 结果：资源利用率低 │
│ │
│ 部署复杂: │
│ ├── 多 GPU 通信 │
│ ├── 动态批处理 │
│ ├── 模型量化 │
│ └── 结果：运维成本高 │
│ │
└─────────────────────────────────────────────────┘
推理引擎的演进
理解了 LLM 推理的挑战之后，让我们看看业界是如何一步步解决这些问题的。推理引擎的发展大致经历了四个阶段，每个阶段都有其标志性的技术突破。
2022 年是早期探索期。当时开发者主要依赖 PyTorch Native 配合 HuggingFace 的 transformers 库进行推理。这种方式虽然灵活，但存在明显问题：显存效率低下，没有批处理优化，每个请求都要单独处理。想象一下，如果你的服务同时收到 100 个请求，原生 PyTorch 只能一个一个处理，或者简单地把它们拼成一个 batch——但这样会导致短请求必须等待长请求完成，效率极低。
2023 年迎来了专用引擎的兴起。这一年，UC Berkeley 发布了 vLLM，其核心创新 PagedAttention 借鉴了操作系统中的虚拟内存和分页思想，将 KV Cache 分块存储，按需分配。这一突破使得显存效率提升了 10-20 倍，意味着同样的显存可以支持 10 倍以上的并发请求。几乎同时，NVIDIA 推出了 TensorRT-LLM，针对自家 GPU 进行了深度优化，在 NVIDIA 硬件上达到了当时的性能巅峰。
2024 年进入功能丰富化阶段。SGLang 的出现专注于结构化生成场景，特别适合 Agent 系统和工具调用。llama.cpp 则让 CPU 推理变得实用化，使得在没有 GPU 的设备上运行大模型成为可能。这一年的特点是场景覆盖更广，不同引擎开始形成各自的特色。
到了 2025 年，推理引擎已经走向生产成熟化。各引擎之间的功能开始趋同，性能差距缩小，易用性大幅提升。生产部署的门槛显著降低，即使是小团队也能快速搭建高效的推理服务。下面的对比图展示了主流引擎的核心特性。
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 2022: 早期探索 │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ PyTorch Native + HuggingFace │ │
│ │ 问题：显存效率低，无批处理优化 │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ ↓ │
│ 2023: 专用引擎兴起 │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ vLLM (UC Berkeley): PagedAttention │ │
│ │ TensorRT-LLM (NVIDIA): 深度优化 │ │
│ │ 突破：显存效率提升 10-20x │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ ↓ │
│ 2024: 功能丰富化 │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ SGLang (UC Berkeley): 结构化生成 │ │
│ │ llama.cpp: CPU 推理普及 │ │
│ │ 突破：场景覆盖更广 │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ ↓ │
│ 2025: 生产成熟化 │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 多引擎融合，功能趋同 │ │
│ │ 性能差距缩小，易用性提升 │ │
│ │ 突破：生产部署门槛降低 │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘
LLM 推理引擎对比
在了解了推理引擎的发展历程后，我们需要对当前市场上的主流选择有一个全面的认识。选择合适的推理引擎就像选择数据库或 Web 框架一样，需要综合考虑性能、功能、易用性和生态支持等多个维度。
目前市场上有六款主流推理引擎，它们各有特色，适用于不同的场景。vLLM 由 UC Berkeley 开发，以其 PagedAttention 技术闻名，是通用场景下的首选。TensorRT-LLM 是 NVIDIA 的官方方案，在 NVIDIA GPU 上性能最优，但绑定 NVIDIA 生态。SGLang 同样来自 UC Berkeley，专注于结构化生成，适合 Agent 和工具调用场景。llama.cpp 是社区驱动的项目，主打 CPU 推理和边缘部署。TGI 由 HuggingFace 官方维护，生产就绪度高。DeepSpeed-Inference 则是微软的产品，训练推理一体化。
主流引擎总览
下面的表格从开发方、核心特性、支持模型和许可证四个维度对比了这些引擎。值得注意的是，除了 llama.cpp 使用 MIT 许可证外，其他引擎大多采用 Apache 2.0 许可证，这意味着它们都可以用于商业项目。模型支持方面，vLLM 和 llama.cpp 的支持最为广泛，几乎涵盖了所有主流开源模型。
├──────────────┬─────────────┬─────────────┬─────────────┬──────────┤
│ 引擎 │ 开发方 │ 核心特性 │ 支持模型 │ 许可证 │
├──────────────┼─────────────┼─────────────┼─────────────┼──────────┤
│ vLLM │ UC │ Paged │ LLaMA, │ Apache │
│ │ Berkeley │ Attention │ Qwen, │ 2.0 │
│ │ │ │ Mistral │ │
├──────────────┼─────────────┼─────────────┼─────────────┼──────────┤
│ TensorRT │ NVIDIA │ 深度优化 │ LLaMA, │ Apache │
│ -LLM │ │ 多 GPU │ Qwen, │ 2.0 │
│ │ │ │ GPT │ │
├──────────────┼─────────────┼─────────────┼─────────────┼──────────┤
│ SGLang │ UC │ 结构化 │ LLaMA, │ Apache │
│ │ Berkeley │ 生成 │ Qwen │ 2.0 │
├──────────────┼─────────────┼─────────────┼─────────────┼──────────┤
│ llama.cpp │ 社区 │ CPU │ LLaMA, │ MIT │
│ │ │ 推理 │ 多模型 │ │
├──────────────┼─────────────┼─────────────┼─────────────┼──────────┤
│ TGI │ Hugging │ 生产就绪 │ 多模型 │ Apache │
│ │ Face │ │ │ 2.0 │
├──────────────┼─────────────┼─────────────┼─────────────┼──────────┤
│ DeepSpeed │ Microsoft │ 训练推理 │ 多模型 │ MIT │
│ -Inference │ │ 一体化 │ │ │
└──────────────┴─────────────┴─────────────┴─────────────┴──────────┘
性能对比参考
光看功能特性还不够，性能数据才是选择推理引擎的关键依据。我们在 A100 80GB GPU 上使用 LLaMA-2-7B 模型进行了基准测试，结果如下。
需要说明的是，这些测试数据是在特定条件下获得的：A100 80GB GPU，FP16 精度（llama.cpp 为 INT4 量化），batch size 和序列长度都有严格控制。实际生产环境中的性能会受到硬件配置、模型大小、量化精度、并发请求模式等多种因素影响，但这些数据仍然具有重要的参考价值。
从延迟角度看，TensorRT-LLM 表现最优，batch=1 时仅需 30-50ms，这得益于 NVIDIA 对自家硬件的深度优化。vLLM 和 SGLang 处于第二梯队，延迟在 45-70ms 之间。llama.cpp 由于运行在 CPU 上，延迟最高，达到 200-300ms，但考虑到它不需要 GPU，这个表现已经相当不错。
吞吐量方面，TensorRT-LLM 同样领先，达到 150-180 tokens/s。vLLM 和 SGLang 在 100-130 tokens/s 区间。原生 PyTorch 的吞吐量最低，只有 50-60 tokens/s，这也是为什么生产环境不推荐直接使用原生 PyTorch 的原因。
显存效率是最能体现推理引擎价值的指标。vLLM 的 PagedAttention 技术使其显存效率达到 80-90%，相比原生 PyTorch 的 30-40% 提升了 2-3 倍。TensorRT-LLM 通过内核融合和显存池技术，效率达到 85-95%。这意味着同样的显存，这些引擎可以支持更多的并发请求。
├──────────────┬─────────────┬─────────────┬─────────────┬──────────┤
│ 引擎 │ 延迟 (ms) │ 吞吐量 │ 显存效率 │ 备注 │
│ │ (batch=1) │ (tokens/s)│ (%) │ │
├──────────────┼─────────────┼─────────────┼─────────────┼──────────┤
│ PyTorch │ 80-100 │ 50-60 │ 30-40 │ 原生 │
│ Native │ │ │ │ │
├──────────────┼─────────────┼─────────────┼─────────────┼──────────┤
│ vLLM │ 50-70 │ 100-120 │ 80-90 │ FP16 │
│ │ │ │ │ │
├──────────────┼─────────────┼─────────────┼─────────────┼──────────┤
│ TensorRT │ 30-50 │ 150-180 │ 85-95 │ FP16 │
│ -LLM │ │ │ │ │
├──────────────┼─────────────┼─────────────┼─────────────┼──────────┤
│ SGLang │ 45-65 │ 110-130 │ 80-90 │ FP16 │
│ │ │ │ │ │
├──────────────┼─────────────┼─────────────┼─────────────┼──────────┤
│ llama.cpp │ 200-300 │ 20-30 │ 70-80 │ INT4 │
│ (CPU) │ │ │ │ │
└──────────────┴─────────────┴─────────────┴─────────────┴──────────┘
注：测试条件 A100 80GB，实际性能受硬件和配置影响
功能对比
除了性能指标，功能特性同样重要。不同的应用场景对功能的需求不同：有的需要 CPU 推理能力，有的需要结构化生成，有的则看重多 GPU 支持。下面的功能对比表可以帮助你根据具体需求选择合适的引擎。
PagedAttention 是现代推理引擎的标配技术，vLLM、TensorRT-LLM 和 SGLang 都支持这一特性，它通过分页管理 KV Cache 大幅提升显存效率。llama.cpp 由于主要针对 CPU 推理，采用了不同的内存管理策略，因此不支持 PagedAttention。
连续批处理（Continuous Batching）是另一个关键功能。传统批处理需要等待 batch 中所有请求都完成才能开始下一批，而连续批处理允许在某个请求完成后立即插入新请求，无需等待整个 batch 结束。这显著提升了 GPU 利用率，vLLM、TensorRT-LLM 和 SGLang 都支持此功能。
多 GPU 支持对于部署大模型至关重要。vLLM、TensorRT-LLM 和 SGLang 都支持张量并行和流水线并行，可以将大模型拆分到多张 GPU 上运行。llama.cpp 目前不支持多 GPU，这也是它在大规模部署场景下的主要限制。
量化支持方面，各引擎都有不同程度的支持。llama.cpp 在量化方面最为灵活，支持 INT4/INT5/INT8 等多种精度，这也是它能在 CPU 上高效运行的关键。TensorRT-LLM 支持 INT8 和 FP8（Hopper GPU），在 NVIDIA 硬件上可以实现 4 倍吞吐提升。
结构化生成是 SGLang 的杀手锏功能。当你的应用需要输出 JSON、SQL 或代码等结构化内容时，SGLang 的约束解码可以确保输出格式 100% 符合预期，同时还能提升 2-5 倍的生成速度。其他引擎目前缺乏原生的结构化生成支持。
├──────────────┬─────────┬─────────┬─────────┬─────────┬────────────┤
│ 功能 │ vLLM │ TRT-LLM│ SGLang │ llama.cpp│ 说明 │
├──────────────┼─────────┼─────────┼─────────┼─────────┼────────────┤
│ PagedAttention│ ✓ │ ✓ │ ✓ │ ✗ │ 显存优化 │
├──────────────┼─────────┼─────────┼─────────┼─────────┼────────────┤
│ 连续批处理 │ ✓ │ ✓ │ ✓ │ ✗ │ 动态 batching│
├──────────────┼─────────┼─────────┼─────────┼─────────┼────────────┤
│ 多 GPU 支持 │ ✓ │ ✓ │ ✓ │ ✗ │ 模型并行 │
├──────────────┼─────────┼─────────┼─────────┼─────────┼────────────┤
│ 量化支持 │ INT8 │ INT8/4 │ INT8 │ INT4/5/8│ 精度压缩 │
├──────────────┼─────────┼─────────┼─────────┼─────────┼────────────┤
│ CPU 推理 │ ✗ │ ✗ │ ✗ │ ✓ │ 边缘部署 │
├──────────────┼─────────┼─────────┼─────────┼─────────┼────────────┤
│ 结构化生成 │ ✗ │ ✗ │ ✓ │ ✗ │ 约束解码 │
├──────────────┼─────────┼─────────┼─────────┼─────────┼────────────┤
│ OpenAI API │ ✓ │ ✓ │ ✓ │ ✗ │ API 兼容 │
├──────────────┼─────────┼─────────┼─────────┼─────────┼────────────┤
│ 易用性 │ 高 │ 中 │ 中 │ 高 │ 部署难度 │
└──────────────┴─────────┴─────────┴─────────┴─────────┴────────────┘
vLLM 架构与特性
在了解了各引擎的整体对比后，让我们深入看看每个引擎的具体架构和特性。首先从最流行的 vLLM 开始。
vLLM 之所以能够迅速成为最流行的开源推理引擎，关键在于它用简洁优雅的方案解决了 LLM 推理的核心痛点——显存效率。它的核心创新 PagedAttention 借鉴了操作系统中虚拟内存的思想，这一跨领域的技术迁移堪称经典。
vLLM 简介
vLLM 由 UC Berkeley 的研究团队于 2023 年发布，定位为高吞吐量、高显存效率的推理引擎。它的设计哲学很明确：在保持易用性的同时，最大化硬件利用率。这使得 vLLM 既适合研究实验，也适合生产部署。
vLLM 的核心创新主要有四项。PagedAttention 是最著名的，它将 KV Cache 分成固定大小的 block，按需分配，使得显存利用率从传统方法的 30-40% 提升到 90% 以上。Continuous Batching 允许动态插入和完成请求，避免 GPU 空闲等待。CUDA Graph 技术降低了 kernel 启动开销，进一步提升性能。分布式推理支持则使得大模型可以跨多张 GPU 运行。
性能方面，vLLM 的表现非常突出。吞吐量比原生 PyTorch 高 10-20 倍，这意味着同样的硬件可以服务 10 倍以上的用户。显存效率的提升使得单卡可以支持 10 倍以上的并发请求。而延迟方面，vLLM 与原生推理相当，没有因为优化而牺牲响应速度。
├─────────────────────────────────────────────────┤
│ │
│ 定位： │
│ ├── UC Berkeley 开发的开源推理引擎 │
│ ├── 专注于高吞吐量、高显存效率 │
│ ├── 支持多种开源 LLM 模型 │
│ └── 生产环境广泛采用 │
│ │
│ 核心创新: │
│ ├── PagedAttention: 显存效率提升 10-20x │
│ ├── Continuous Batching: 动态批处理 │
│ ├── CUDA Graph: 降低 kernel 启动开销 │
│ └── 分布式推理：多 GPU 张量并行 │
│ │
│ 性能优势: │
│ ├── 吞吐量：比 PyTorch 高 10-20x │
│ ├── 显存效率：支持 10x 并发请求 │
│ └── 延迟：与原生推理相当 │
│ │
└─────────────────────────────────────────────────┘
PagedAttention 原理
PagedAttention 是 vLLM 的核心创新，也是它能够在 2023 年迅速走红的关键。理解 PagedAttention 的工作原理，对于深入掌握 vLLM 至关重要。
传统 Attention 机制的显存浪费问题源于一个简单的事实：在推理开始前，我们无法预知每个请求会生成多少 token。为了保险起见，传统方法会为每个请求预分配固定长度的显存，通常按照最大序列长度分配。但实际情况是，大多数请求的序列长度远小于最大值。研究表明，这种预分配策略导致的显存浪费率高达 60-80%。想象一下，你为每个客户都预留了一间豪华套房，但大多数人只需要一个标准间，这就是传统方法的低效之处。
PagedAttention 的解决方案非常巧妙：它借鉴了操作系统中的虚拟内存和分页思想。在操作系统中，程序不需要连续的物理内存，而是通过页表将虚拟地址映射到物理地址。vLLM 将这一思想应用到 KV Cache 管理上：将 KV Cache 分成固定大小的 block（通常 16-32 个 token），每个 block 可以存储在显存的任意位置，通过 block table 记录映射关系。
这种设计带来了多重好处。首先，显存利用率大幅提升到 90% 以上，因为不再需要预分配连续的大块显存。其次，支持动态扩展，当请求需要更多 token 时，只需分配新的 block，无需重新分配整个序列。第三，零拷贝设计意味着数据不需要在显存中移动，减少了额外的开销。
实际效果非常显著：显存效率提升 10-20 倍，这意味着同样的显存可以支持 10 倍以上的并发请求。吞吐量提升 2-4 倍，因为 GPU 可以更充分地利用。这就是为什么 PagedAttention 被认为是 LLM 推理领域的突破性创新。
├─────────────────────────────────────────────────┤
│ │
│ 问题：传统 Attention 显存浪费 │
│ ├── 预分配固定长度显存 │
│ ├── 实际序列长度参差不齐 │
│ ├── 浪费率：60-80% │
│ └── 结果：并发请求数受限 │
│ │
│ 解决：分页注意力机制 │
│ ├── 借鉴操作系统虚拟内存思想 │
│ ├── KV Cache 分块存储 (block) │
│ ├── 按需分配，动态扩展 │
│ └── 结果：显存利用率 >90% │
│ │
│ 实现细节: │
│ ├── Block Table: 记录序列的 block 映射 │
│ ├── Block Size: 通常 16-32 tokens │
│ ├── 非连续内存：通过 block table 访问 │
│ └── 零拷贝：无需数据移动 │
│ │
│ 效果: │
│ ├── 显存效率：提升 10-20x │
│ ├── 并发请求：支持 10x 更多请求 │
│ └── 吞吐量：提升 2-4x │
│ │
└─────────────────────────────────────────────────┘
vLLM 架构图
理解了 PagedAttention 的原理后，让我们从系统层面看看 vLLM 的整体架构。vLLM 采用了分层设计，每一层都有明确的职责，这种模块化设计使得系统既高效又易于维护。
最上层是 API Layer，提供了多种接口方式。OpenAI API 兼容接口使得你可以无缝切换现有的 OpenAI 应用，无需修改代码。Async API 支持异步调用，适合高并发场景。CLI 则方便命令行测试和脚本集成。
第二层是 Scheduler（调度器），这是 vLLM 的大脑。它维护着请求队列，根据优先级进行调度，并管理 GPU 资源分配。调度器的设计直接影响系统的吞吐量和延迟表现。
第三层是 Worker（执行引擎），负责实际的模型推理。Model Runner 加载并执行模型，PagedAttention 模块管理 KV Cache，Continuous Batching 模块处理动态批处理。这一层是 vLLM 性能优化的核心所在。
第四层是 KV Cache Manager，专门管理显存中的 KV Cache。Block Allocator 负责分配和回收 block，Block Table 维护映射关系，Memory Pool 提供显存池化复用。这一层的设计直接决定了显存效率。
最底层是 GPU Memory，存储模型权重、KV Cache 和激活缓冲区。通过 PagedAttention 技术，KV Cache 可以高效地存储在非连续的显存空间中。
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ API Layer │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ OpenAI API │ │ Async API │ │ CLI │ │ │
│ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ Scheduler (调度器) │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ 请求队列 │ │ 优先级调度 │ │ 资源管理 │ │ │
│ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ Worker (执行引擎) │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ Model │ │ Paged │ │ Continuous │ │ │
│ │ │ Runner │ │ Attention │ │ Batching │ │ │
│ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ KV Cache Manager │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ Block │ │ Block │ │ Memory │ │ │
│ │ │ Allocator │ │ Table │ │ Pool │ │ │
│ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ GPU Memory │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ Model │ │ KV Cache │ │ Activation │ │ │
│ │ │ Weights │ │ (Paged) │ │ Buffers │ │ │
│ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘
TensorRT-LLM 架构与特性
如果说 vLLM 是开源社区的代表，那么 TensorRT-LLM 就是 NVIDIA 官方实力的体现。作为 NVIDIA 官方的 LLM 推理优化库，TensorRT-LLM 在 NVIDIA GPU 上提供了业界领先的性能。
TensorRT-LLM 的优势在于深度整合。它基于 NVIDIA 多年积累的 TensorRT 技术，针对 Transformer 架构进行了深度优化。从 kernel 级别的融合，到多 GPU 通信的优化，再到量化支持，TensorRT-LLM 提供了一套完整的优化方案。如果你使用的是 NVIDIA GPU，特别是数据中心级的 A100 或 H100，TensorRT-LLM 通常能提供最佳性能。
TensorRT-LLM 简介
TensorRT-LLM 的定位非常明确：在 NVIDIA GPU 上提供极致的推理性能。它基于 TensorRT 深度学习推理优化器，针对 LLM 的特殊需求进行了大量定制。
核心优化技术包括多项。Kernel 融合将多个算子合并为一个，减少内存访问次数，这是 TensorRT 的传统优势。多 GPU 通信方面，针对 NVLink 和 InfiniBand 进行了优化，使得多卡扩展效率达到 90% 以上。量化支持涵盖 INT8 和 FP8（Hopper GPU），可以在几乎不损失精度的情况下实现 4 倍吞吐提升。In-flight Batching 是 NVIDIA 对连续批处理的实现，进一步提升了 GPU 利用率。Paged Attention 则是吸收了 vLLM 的思想，提升了显存效率。
性能方面，TensorRT-LLM 在 NVIDIA GPU 上确实是最强的。延迟可以达到 30-50ms（batch=1），是业界最低水平。吞吐量达到 150-180 tokens/s，同样是业界最高。显存效率达到 85-95%，与 vLLM 相当。
适用场景主要是 NVIDIA GPU 的生产部署，特别是对性能要求极高的场景，以及多 GPU 大规模部署。如果你有专业的团队进行维护，TensorRT-LLM 是不错的选择。
├─────────────────────────────────────────────────┤
│ │
│ 定位： │
│ ├── NVIDIA 官方的 LLM 推理优化库 │
│ ├── 基于 TensorRT 深度优化 │
│ ├── 针对 NVIDIA GPU 全系列优化 │
│ └── 性能最优，功能最全 │
│ │
│ 核心优化: │
│ ├── Kernel 融合：减少内存访问 │
│ ├── 多 GPU 通信：NVLink/IB 优化 │
│ ├── 量化：INT8/FP8 支持 │
│ ├── In-flight Batching: 动态批处理 │
│ └── Paged Attention: 显存优化 │
│ │
│ 性能优势: │
│ ├── 延迟：业界最低 (30-50ms) │
│ ├── 吞吐量：业界最高 (150-180 tokens/s) │
│ └── 显存效率：85-95% │
│ │
│ 适用场景: │
│ ├── NVIDIA GPU 生产部署 │
│ ├── 对性能要求极高的场景 │
│ └── 多 GPU 大规模部署 │
│ │
└─────────────────────────────────────────────────┘
TensorRT-LLM 优化技术
┌─────────────────────────────────────────────────┐
│ TensorRT-LLM 优化技术 │
├─────────────────────────────────────────────────┤
│ │
│ 1. Kernel 优化: │
│ ├── GEMM 优化：针对 Tensor Core 定制 │
│ ├── Attention 融合：减少中间结果 │
│ ├── LayerNorm 融合：与前后算子合并 │
│ └── 激活函数优化：快速近似实现 │
│ │
│ 2. 通信优化: │
│ ├── NVLink P2P: GPU 直连通信 │
│ ├── 重叠通信计算：隐藏通信延迟 │
│ ├── 梯度同步优化：Ring AllReduce │
│ └── 拓扑感知：自动选择最优路径 │
│ │
│ 3. 量化优化: │
│ ├── INT8 量化：4x 吞吐提升 │
│ ├── FP8 量化 (Hopper): 2x 吞吐提升 │
│ ├── 混合精度：关键层 FP16，其他 INT8 │
│ └── 校准：自动确定 scale 因子 │
│ │
│ 4. 显存优化: │
│ ├── Paged Attention: 分页管理 │
│ ├── 激活重计算：节省显存 │
│ ├── 内存池：复用显存分配 │
│ └── 零拷贝：减少数据搬运 │
│ │
└─────────────────────────────────────────────────┘
SGLang 架构与特性
在 vLLM 和 TensorRT-LLM 之后，让我们看看 SGLang——一个专注于结构化生成和复杂推理任务的推理引擎。SGLang 同样来自 UC Berkeley，但它选择了与 vLLM 不同的差异化路线。
SGLang 的核心价值在于解决一个特定但重要的问题：如何让 LLM 可靠地输出结构化内容？在 Agent 系统、工具调用、数据提取等场景中，我们往往需要模型输出 JSON、SQL 或代码等格式严格的内容。传统方法依靠 prompt 工程和后处理，但无法保证 100% 符合格式要求。SGLang 通过约束解码技术，从根源上解决了这个问题。
SGLang 简介
SGLang 的定位是结构化生成语言，专注于复杂推理任务。它的设计哲学是：对于特定场景，提供专门的优化，而不是追求通用性。
核心创新包括多项。结构化生成支持 JSON、SQL 等格式约束，通过约束解码确保输出 100% 符合预期格式。RadixAttention 是 SGLang 的 KV Cache 复用技术，通过树状结构存储共享前缀，在多轮对话场景下可以减少 50-70% 的重复计算。多轮对话优化使得上下文管理更加高效。编程模型采用类似 Python 的 DSL（领域特定语言），使得开发者可以用熟悉的语法编写复杂的推理流程。
性能方面，SGLang 在结构化生成场景下比无约束生成快 2-5 倍，这是因为约束解码减少了无效探索。KV Cache 复用进一步减少了重复计算。多轮对话场景下，延迟可以降低 30-50%。
适用场景非常明确：Agent 系统（工具调用、任务规划）、数据提取（JSON/XML 输出）、代码生成（语法约束）、多轮对话（聊天机器人）以及复杂推理（思维链、树形思维）等。
├─────────────────────────────────────────────────┤
│ │
│ 定位： │
│ ├── UC Berkeley 开发的结构化生成语言 │
│ ├── 专注于复杂推理任务 │
│ ├── 支持约束解码和结构化输出 │
│ └── 适合 Agent、工具调用场景 │
│ │
│ 核心创新: │
│ ├── 结构化生成：JSON、SQL 等格式约束 │
│ ├── RadixAttention: KV Cache 复用 │
│ ├── 多轮对话优化：上下文高效管理 │
│ └── 编程模型：类似 Python 的 DSL │
│ │
│ 性能优势: │
│ ├── 结构化生成：比无约束快 2-5x │
│ ├── KV Cache 复用：减少重复计算 │
│ └── 多轮对话：延迟降低 30-50% │
│ │
│ 适用场景: │
│ ├── Agent 系统：工具调用、规划 │
│ ├── 数据提取：JSON/XML 输出 │
│ ├── 代码生成：语法约束 │
│ └── 多轮对话：聊天机器人 │
│ │
└─────────────────────────────────────────────────┘
结构化生成示例
# SGLang 结构化生成示例
import sglang as sgl
@sgl.function
def extract_info(s, text):
s += "从以下文本中提取信息：\n"
s += text + "\n"
s += "请以 JSON 格式输出：\n"
s += sgl.gen("json_output",
max_tokens=500,
regex=r'\{.*\}') # JSON 约束
# 运行
state = extract_info.run(text="张三，25 岁，北京人，工程师")
print(state["json_output"])
# 输出：{"name": "张三", "age": 25, "city": "北京", "job": "工程师"}
llama.cpp 架构与特性
介绍完三个 GPU 推理引擎后，让我们看看一个完全不同的选择：llama.cpp。这是一个纯 C++ 实现的推理引擎，专注于 CPU 推理和边缘部署，让大语言模型在无 GPU 设备上运行成为可能。
llama.cpp 的诞生有一个有趣的故事。2023 年初，当大多数研究者都在追求更大模型、更多 GPU 时，llama.cpp 的作者反其道而行之：如何让 7B 模型在普通笔记本上流畅运行？通过精心优化的量化技术和 CPU 指令集利用，llama.cpp 做到了这一点，并迅速成为 GitHub 上最热门的 AI 项目之一。
llama.cpp 简介
llama.cpp 的定位非常独特：纯 C++ 实现的 CPU 推理引擎。它不依赖 Python，不依赖 GPU，甚至可以在树莓派这样的嵌入式设备上运行。这种"零门槛"特性使得 LLM 真正走向了普及。
核心特性包括多项。GGUF 格式是 llama.cpp 专为量化设计的模型格式，支持多种精度，使得模型可以高效存储在内存中。CPU 优化方面，充分利用 AVX2/AVX512 等指令集，最大化 CPU 性能。GPU 加速是可选的，支持 CUDA、Metal 和 Vulkan，可以在有 GPU 的设备上进一步提升性能。量化支持涵盖 INT4/INT5/INT8/FP16，用户可以根据需求在精度和速度之间权衡。内存映射技术使得大模型可以在低内存设备上运行，70B 模型甚至可以在 16GB 内存的笔记本上运行。
性能特点需要客观看待。CPU 推理速度在 20-30 tokens/s（单线程），对于阅读速度来说已经够用。GPU 加速后可以达到 50-100 tokens/s（入门 GPU）。显存占用方面，7B INT4 仅需约 4GB，这使得它可以在消费级硬件上运行。延迟在 200-300ms（CPU），虽然比 GPU 引擎高，但考虑到无需 GPU 的成本优势，这是可以接受的。
适用场景包括边缘设备（笔记本、手机、嵌入式）、隐私敏感场景（本地运行，数据不出域）、成本敏感场景（无需 GPU）以及离线场景（无网络环境）。
├─────────────────────────────────────────────────┤
│ │
│ 定位： │
│ ├── 社区开发的纯 C++ 推理实现 │
│ ├── 专注于 CPU 推理和边缘部署 │
│ ├── 支持多种量化格式 │
│ └── 无 GPU 依赖，跨平台 │
│ │
│ 核心特性: │
│ ├── GGUF 格式：高效量化模型格式 │
│ ├── CPU 优化：AVX2/AVX512 指令集 │
│ ├── GPU 加速：可选 CUDA/Metal/Vulkan │
│ ├── 量化支持：INT4/INT5/INT8/FP16 │
│ └── 内存映射：大模型低内存运行 │
│ │
│ 性能特点: │
│ ├── CPU 推理：20-30 tokens/s (单线程) │
│ ├── GPU 加速：50-100 tokens/s (入门 GPU) │
│ ├── 显存占用：7B INT4 仅需 ~4GB │
│ └── 延迟：200-300ms (CPU) │
│ │
│ 适用场景: │
│ ├── 边缘设备：笔记本、手机、嵌入式 │
│ ├── 隐私敏感：本地运行，数据不出域 │
│ ├── 成本敏感：无需 GPU，CPU 即可 │
│ └── 离线场景：无网络环境 │
│ │
└─────────────────────────────────────────────────┘
GGUF 量化格式
量化是 llama.cpp 能够在 CPU 上高效运行的关键技术。GGUF 格式支持多种量化精度，用户可以根据需求在模型大小、精度和速度之间进行权衡。
Q4_0 是最常用的 INT4 量化格式，7B 模型仅需约 4GB 内存，精度损失约 2-3%，速度最快，适合资源受限场景。Q4_K_M 是 INT4 混合精度量化，通过重要权重使用更高精度的策略，在同样 4.5GB 大小下将精度损失降低到 1-2%，是平衡场景的推荐选择。Q5_K_M 使用 INT5 混合精度，7B 模型约 5GB，精度损失仅 0.5-1%，适合对精度要求较高的场景。Q8_0 是 INT8 量化，7B 模型约 8GB，精度损失仅 0.1-0.5%，接近 FP16 精度。FP16 则是无量化版本，7B 模型需要 14GB，但没有任何精度损失，适合最高精度要求场景。
选择合适的量化等级需要考虑你的具体需求。如果是个人使用或资源受限，Q4_K_M 是很好的平衡选择。如果需要更高精度，Q5_K_M 或 Q8_0 是更好的选择。如果追求极致精度且有足够内存，FP16 是最佳选择。
├─────────────────────────────────────────────────┤
│ │
│ Q4_0 (INT4): │
│ ├── 大小：7B 模型 ~4GB │
│ ├── 精度损失：~2-3% │
│ ├── 速度：最快 │
│ └── 推荐：资源受限场景 │
│ │
│ Q4_K_M (INT4 混合精度): │
│ ├── 大小：7B 模型 ~4.5GB │
│ ├── 精度损失：~1-2% │
│ ├── 速度：快 │
│ └── 推荐：平衡场景 │
│ │
│ Q5_K_M (INT5 混合精度): │
│ ├── 大小：7B 模型 ~5GB │
│ ├── 精度损失：~0.5-1% │
│ ├── 速度：中等 │
│ └── 推荐：精度要求较高场景 │
│ │
│ Q8_0 (INT8): │
│ ├── 大小：7B 模型 ~8GB │
│ ├── 精度损失：~0.1-0.5% │
│ ├── 速度：较慢 │
│ └── 推荐：接近 FP16 精度 │
│ │
│ FP16: │
│ ├── 大小：7B 模型 ~14GB │
│ ├── 精度损失：无 │
│ ├── 速度：慢 │
│ └── 推荐：最高精度要求 │
│ │
└─────────────────────────────────────────────────┘
适用场景分析
在了解了各推理引擎的技术特性后，让我们从应用场景的角度来分析如何选择。不同的业务场景对推理引擎的需求差异很大：高吞吐云服务追求极致性能，企业私有部署看重稳定性和易用性，边缘部署则需要低成本和离线能力。
理解这些场景的特点和需求，是做出正确选型决策的前提。下面的分析将帮助你根据自己的实际情况选择合适的引擎。
场景分类
高吞吐云服务场景典型特征是：高并发、低延迟、24/7 不间断运行。这类场景对吞吐量的要求通常在 1000 tokens/s 以上，需要多卡 A100 或 H100 支持。vLLM 和 TensorRT-LLM 是首选，它们都能提供高吞吐和低延迟。
企业私有部署场景的特征是：中等并发、数据安全要求高、需要可控成本。延迟要求通常在 100ms 以内，需要易于维护。vLLM 和 TGI 是推荐选择，它们都有良好的文档和社区支持，部署相对简单。硬件方面，单卡或双卡 A10/A30 通常就够用。
边缘/本地部署场景的特征是：无 GPU、资源受限、需要离线运行。内存通常限制在 8GB 以内，只能使用 CPU 推理。llama.cpp 是唯一选择，它可以让 7B 模型在普通笔记本上流畅运行。
Agent/工具调用场景的特征是：需要结构化输出、多轮对话、复杂推理。需要 JSON 或代码格式输出，需要约束解码支持。SGLang 是首选，它的结构化生成和 RadixAttention 技术特别适合这类场景。
研发/测试场景的特征是：需要灵活性高、快速迭代、支持多模型。需要易于部署，支持快速切换模型。vLLM 和 llama.cpp 是推荐选择，它们都有良好的易用性和模型支持。
├─────────────────────────────────────────────────┤
│ │
│ 高吞吐云服务: │
│ ├── 特征：高并发、低延迟、24/7 运行 │
│ ├── 需求：吞吐量>1000 tokens/s │
│ ├── 推荐：vLLM、TensorRT-LLM │
│ └── 硬件：多卡 A100/H100 │
│ │
│ 企业私有部署: │
│ ├── 特征：中等并发、数据安全、可控成本 │
│ ├── 需求：延迟<100ms，易维护 │
│ ├── 推荐：vLLM、TGI │
│ └── 硬件：单卡/双卡 A10/A30 │
│ │
│ 边缘/本地部署: │
│ ├── 特征：无 GPU、资源受限、离线运行 │
│ ├── 需求：内存<8GB，CPU 推理 │
│ ├── 推荐：llama.cpp │
│ └── 硬件：CPU (8-16 核) │
│ │
│ Agent/工具调用: │
│ ├── 特征：结构化输出、多轮对话、复杂推理 │
│ ├── 需求：JSON/代码输出，约束解码 │
│ ├── 推荐：SGLang │
│ └── 硬件：单卡 A100/A10 │
│ │
│ 研发/测试: │
│ ├── 特征：灵活性高、快速迭代、多模型 │
│ ├── 需求：易部署、支持多模型 │
│ ├── 推荐：vLLM、llama.cpp │
│ └── 硬件：单卡 RTX 4090/3090 │
│ │
└─────────────────────────────────────────────────┘
性能 - 成本权衡
在实际选型中，性能和成本往往是需要权衡的两个关键因素。下面的分析从四个维度展示了不同的选择方案。
高性能 + 高成本方案采用 TensorRT-LLM 配合 H100 或 A100 GPU，延迟可以达到 30-50ms，吞吐量达到 150-180 tokens/s，但硬件成本高达 $30000+/GPU。这种方案适合关键业务、高 SLA 要求的场景，如金融交易、医疗诊断等。
高性能 + 中成本方案采用 vLLM 配合 A10 或 A30 GPU，延迟 50-70ms，吞吐量 100-120 tokens/s，硬件成本 $5000-10000/GPU。这种方案适合生产环境、中等 SLA 要求的场景，如企业客服、内容生成等。
中性能 + 低成本方案采用 vLLM 配合 RTX 4090 消费级 GPU，延迟 60-80ms，吞吐量 80-100 tokens/s，硬件成本仅 $1500-2000/GPU。这种方案适合中小企业、研发测试场景，性价比很高。
低性能 + 超低成本方案采用 llama.cpp 配合 CPU，延迟 200-300ms，吞吐量 20-30 tokens/s，但硬件成本为 $0（利用已有 CPU）。这种方案适合边缘、本地、离线场景，如个人助手、隐私敏感应用等。
├─────────────────────────────────────────────────┤
│ │
│ 高性能 + 高成本: │
│ ├── 方案：TensorRT-LLM + H100/A100 │
│ ├── 延迟：30-50ms │
│ ├── 吞吐：150-180 tokens/s │
│ ├── 成本：$30000+/GPU │
│ └── 场景：关键业务、高 SLA 要求 │
│ │
│ 高性能 + 中成本: │
│ ├── 方案：vLLM + A10/A30 │
│ ├── 延迟：50-70ms │
│ ├── 吞吐：100-120 tokens/s │
│ ├── 成本：$5000-10000/GPU │
│ └── 场景：生产环境、中等 SLA │
│ │
│ 中性能 + 低成本: │
│ ├── 方案：vLLM + RTX 4090 │
│ ├── 延迟：60-80ms │
│ ├── 吞吐：80-100 tokens/s │
│ ├── 成本：$1500-2000/GPU │
│ └── 场景：中小企业、研发测试 │
│ │
│ 低性能 + 超低成本: │
│ ├── 方案：llama.cpp + CPU │
│ ├── 延迟：200-300ms │
│ ├── 吞吐：20-30 tokens/s │
│ ├── 成本：$0 (已有 CPU) │
│ └── 场景：边缘、本地、离线 │
│ │
└─────────────────────────────────────────────────┘
选型指南
经过前面的详细介绍，相信你对各推理引擎已经有了全面了解。最后，让我们通过一个决策流程来帮助你做出最终选择。
选型的核心思路是：先确定硬件条件，再根据性能需求和特殊需求进行筛选。下面的决策树将引导你完成这个过程。
决策流程
决策的第一步是确认硬件条件：你有 NVIDIA GPU 吗？如果没有，或者只有 CPU，那么 llama.cpp 是唯一选择。如果有 GPU，继续下一步。
第二步是评估性能需求：你的性能要求极高吗？如果是，TensorRT-LLM 是最佳选择，它在 NVIDIA GPU 上提供最优性能。如果性能要求中等，vLLM 或 SGLang 是更好的选择，它们在保持良好性能的同时更易用。
第三步是考虑特殊需求：你需要结构化生成吗？如果是，SGLang 是首选。你需要多语言支持吗？vLLM 和 TGI 支持更好。你需要边缘部署吗？llama.cpp 是唯一选择。你需要多 GPU 扩展吗？TensorRT-LLM 和 vLLM 都支持良好。
最后，还需要考虑团队能力和维护成本。TensorRT-LLM 虽然性能最强，但需要专业团队维护。vLLM 和 llama.cpp 则更易用，适合小团队。
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 开始 │
│ │ │
│ ↓ │
│ ┌─────────────────┐ │
│ │ 有 NVIDIA GPU? │ │
│ └────────┬────────┘ │
│ │ │
│ ┌───────────────┼───────────────┐ │
│ ↓ ↓ ↓ │
│ 是 无 仅 CPU │
│ │ │ │ │
│ ↓ ↓ ↓ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 性能要求？ │ │ 有 GPU 计划？ │ │ llama.cpp │ │
│ └──────┬──────┘ └──────┬──────┘ │ (唯一选择) │ │
│ │ │ └─────────────┘ │
│ ┌─────┴─────┐ ┌─────┴─────┐ │
│ ↓ ↓ ↓ ↓ │
│ 极高 中等 是 否 │
│ │ │ │ │ │
│ ↓ ↓ ↓ ↓ │
│ TensorRT vLLM vLLM llama.cpp │
│ -LLM 或 (提前 (临时 │
│ SGLang 部署) 方案) │
│ │
│ 特殊需求分支: │
│ ├── 结构化生成 → SGLang │
│ ├── 多语言支持 → vLLM/TGI │
│ ├── 边缘部署 → llama.cpp │
│ └── 多 GPU 扩展 → TensorRT-LLM/vLLM │
│ │
└─────────────────────────────────────────────────────────────────────┘
选型建议总结
为了帮助你快速做出选择，下面是针对不同场景的选型建议总结。
首选 vLLM 的场景包括：通用生产部署，追求性能和易用性的平衡；需要 OpenAI API 兼容，方便现有应用迁移；需要多模型支持，快速切换不同模型；团队规模小，需要易用性和良好文档支持。vLLM 是大多数场景下的安全选择。
首选 TensorRT-LLM 的场景包括：性能要求极高，延迟敏感；全 NVIDIA 栈，希望深度优化；多 GPU 大规模部署；有专业团队维护。如果你追求极致性能且有资源投入，TensorRT-LLM 是最佳选择。
首选 SGLang 的场景包括：Agent 系统，需要工具调用；结构化输出（JSON/代码）；多轮对话，需要上下文复用；复杂推理任务。SGLang 在这些特定场景下有明显优势。
首选 llama.cpp 的场景包括：无 GPU，只能 CPU 推理；边缘/本地部署；隐私敏感，数据不出域；成本极度敏感。llama.cpp 让这些场景成为可能。
不推荐的情况包括：生产环境用 PyTorch 原生（性能太差）；多 GPU 用 llama.cpp（不支持）；结构化生成用 vLLM（无原生支持）；CPU 部署用 TensorRT-LLM（不支持）。
├─────────────────────────────────────────────────┤
│ │
│ 首选 vLLM 的场景: │
│ ✓ 通用生产部署，追求平衡 │
│ ✓ 需要 OpenAI API 兼容 │
│ ✓ 多模型支持，快速切换 │
│ ✓ 团队规模小，需要易用性 │
│ │
│ 首选 TensorRT-LLM 的场景: │
│ ✓ 性能要求极高，延迟敏感 │
│ ✓ 全 NVIDIA 栈，深度优化 │
│ ✓ 多 GPU 大规模部署 │
│ ✓ 有专业团队维护 │
│ │
│ 首选 SGLang 的场景: │
│ ✓ Agent 系统，工具调用 │
│ ✓ 结构化输出 (JSON/代码) │
│ ✓ 多轮对话，上下文复用 │
│ ✓ 复杂推理任务 │
│ │
│ 首选 llama.cpp 的场景: │
│ ✓ 无 GPU，CPU 推理 │
│ ✓ 边缘/本地部署 │
│ ✓ 隐私敏感，数据不出域 │
│ ✓ 成本极度敏感 │
│ │
│ 不推荐的情况: │
│ ✗ 生产环境用 PyTorch 原生 (性能差) │
│ ✗ 多 GPU 用 llama.cpp (不支持) │
│ ✗ 结构化生成用 vLLM (无原生支持) │
│ ✗ CPU 部署用 TensorRT-LLM (不支持) │
│ │
└─────────────────────────────────────────────────┘
快速对比表
最后的快速对比表从六个维度对各引擎进行了星级评分，帮助你一目了然地看到各引擎的优势和劣势。
性能维度上，TensorRT-LLM 以五星领先，vLLM 和 SGLang 四星，llama.cpp 两星（CPU 限制）。易用性维度上，vLLM 和 llama.cpp 五星，TensorRT-LLM 和 SGLang 三星。功能丰富度上，TensorRT-LLM 和 SGLang 五星，vLLM 四星，llama.cpp 三星。模型支持上，llama.cpp 五星（支持最广泛），vLLM 四星，其他三星。社区活跃度上，vLLM 和 llama.cpp 五星，TensorRT-LLM 四星，SGLang 三星。生产成熟度上，vLLM 和 TensorRT-LLM 五星，llama.cpp 四星，SGLang 三星。
综合推荐评级上，vLLM 获得五星，是最均衡的选择。TensorRT-LLM、SGLang 和 llama.cpp 都获得四星，它们在各自的优势场景下是最佳选择。
├──────────────┬─────────────┬─────────────┬─────────────┬──────────┤
│ 维度 │ vLLM │ TRT-LLM │ SGLang │ llama.cpp│
├──────────────┼─────────────┼─────────────┼─────────────┼──────────┤
│ 性能 │ ⭐⭐⭐⭐ │ ⭐⭐⭐⭐⭐ │ ⭐⭐⭐⭐ │ ⭐⭐ │
├──────────────┼─────────────┼─────────────┼─────────────┼──────────┤
│ 易用性 │ ⭐⭐⭐⭐⭐ │ ⭐⭐⭐ │ ⭐⭐⭐ │ ⭐⭐⭐⭐⭐ │
├──────────────┼─────────────┼─────────────┼─────────────┼──────────┤
│ 功能丰富 │ ⭐⭐⭐⭐ │ ⭐⭐⭐⭐⭐ │ ⭐⭐⭐⭐⭐ │ ⭐⭐⭐ │
├──────────────┼─────────────┼─────────────┼─────────────┼──────────┤
│ 模型支持 │ ⭐⭐⭐⭐ │ ⭐⭐⭐ │ ⭐⭐⭐ │ ⭐⭐⭐⭐⭐ │
├──────────────┼─────────────┼─────────────┼─────────────┼──────────┤
│ 社区活跃 │ ⭐⭐⭐⭐⭐ │ ⭐⭐⭐⭐ │ ⭐⭐⭐ │ ⭐⭐⭐⭐⭐ │
├──────────────┼─────────────┼─────────────┼─────────────┼──────────┤
│ 生产成熟 │ ⭐⭐⭐⭐⭐ │ ⭐⭐⭐⭐⭐ │ ⭐⭐⭐ │ ⭐⭐⭐⭐ │
├──────────────┼─────────────┼─────────────┼─────────────┼──────────┤
│ 综合推荐 │ ★★★★★ │ ★★★★☆ │ ★★★★☆ │ ★★★★☆ │
└──────────────┴─────────────┴─────────────┴─────────────┴──────────┘
注：评级基于 2026 年 4 月的技术状态
总结
今天学到的内容
- ✅ LLM 推理引擎对比：vLLM、TRT-LLM、SGLang、llama.cpp
- ✅ vLLM 架构：PagedAttention 原理、系统架构
- ✅ TensorRT-LLM 架构：优化技术、性能优势
- ✅ SGLang 架构：结构化生成、RadixAttention
- ✅ llama.cpp 架构：GGUF 量化、CPU 推理
- ✅ 适用场景分析：5 类场景的引擎推荐
- ✅ 选型指南：决策流程、快速对比表
下一步
明天我们将学习 Day 15 - vLLM 部署与性能测试，深入了解：
- vLLM 安装与配置
- PagedAttention 实战
- 并发请求测试
- 性能 benchmark 与调优
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
14
0- 0
已为社区贡献15条内容
所有评论(0)