vLLM、SGLang 与 llama.cpp 深度对比
推理引擎——大模型落地的关键一环
在 LLM 的工程化落地中，模型权重仅仅是静态的参数，而推理引擎则是负责加载这些参数、构建计算图并高效执行算子的运行时环境（Runtime）。
理解推理引擎，本质上是理解如何通过极致的显存管理与算子调度，将静态的模型参数转化为动态、高并发、低延迟的流式服务。它解决的核心问题是：如何在有限的资源边界内，压榨出 LLM 生成任务的吞吐量极限。
为什么推理引擎如此重要？
- 成本控制：在多数线上 LLM 产品中，推理通常是主要成本之一
- 用户体验：首 Token 延迟（TTFT）和吞吐量直接影响产品体验
- 规模化能力：能否在目标 SLA 下支撑高并发/高 QPS（并保持 P95/P99 延迟）是商业化关键门槛
- 硬件适配：不同硬件平台需要专门的优化策略
一、技术栈决策指南：一张表看透核心取向
| 引擎 | 核心优势场景 | 关键技术亮点 | 学习曲线 | 社区活跃度 |
|---|---|---|---|---|
| Transformers | 原型验证、算法调试、学术研究 | 动态图 (Eager Execution) | ⭐ 低 | ⭐⭐⭐⭐⭐ |
| llama.cpp | 本地端侧部署 (Mac/IoT/PC) | GGUF, 量化，SIMD/Metal | ⭐⭐ 中低 | ⭐⭐⭐⭐⭐ |
| vLLM | 生产环境、高并发 API 服务 | PagedAttention, Continuous Batching | ⭐⭐ 中 | ⭐⭐⭐⭐⭐ |
| SGLang | 复杂 Agent、长多轮对话、结构化输出 | RadixAttention, 前缀复用 | ⭐⭐⭐ 中高 | ⭐⭐⭐⭐ |
| KTransformers | 单机运行超大模型 (如 DeepSeek-V3) | 异构计算 (CPU+GPU Offload) | ⭐⭐⭐ 中高 | ⭐⭐⭐ |
| MindIE | 国产化算力 (华为昇腾) 生态 | CANN, NPU 算子深度优化 | ⭐⭐⭐⭐ 高 | ⭐⭐⭐ |
💡 快速选型建议
根据你的实际场景，可以参考以下决策路径：
个人玩家 / Mac 用户：首选 llama.cpp
注：流行的 Ollama 底层基于 llama.cpp/ggml 构建。如果你追求开箱即用，Ollama 是不错的选择；如果需要更细粒度的控制，直接使用 llama.cpp。不同版本实现细节可能变动，以官方仓库/发行说明为准。
企业服务 / 高并发：首选 vLLM
vLLM 是目前生产环境部署的事实标准，拥有最成熟的 OpenAI 兼容 API、完善的监控指标和弹性扩缩容支持。
复杂 Agent / 强 JSON 约束：SGLang 是上位替代
当涉及长 System Prompt 复用或高频工具调用时，SGLang 的前缀缓存机制能带来 2-5 倍的性能提升。
显存告急跑大模型：利用 KTransformers 实现'显存不够、内存来凑'
特别适合想在消费级显卡上体验 DeepSeek-V3、Qwen-72B 等大模型的开发者。
信创/国产化路径：基于华为昇腾硬件，MindIE 是官方重点方案
MindIE 是华为 Ascend 官方重点推荐的推理引擎套件。同时社区也有 vLLM-Ascend、LMDeploy 等可选路径，可根据具体需求选择。
二、核心概念前置：理解 LLM 推理的性能瓶颈
在深入各引擎之前，我们需要先理解 LLM 推理面临的核心挑战：
2.1 KV Cache：空间换时间的经典策略
在 Transformer 的自回归生成过程中，每生成一个新 Token，都需要对之前所有 Token 计算 Attention。为避免重复计算，业界采用 KV Cache 策略：将历史 Token 的 Key 和 Value 向量缓存起来。
显存占用公式（通用形式）：
KV Cache Size = 2 × batch_size × num_layers × seq_len × (num_kv_heads × head_dim) × precision_bytes
注：对于使用 GQA（Grouped Query Attention）或 MQA（Multi-Query Attention）的模型，num_kv_heads < num_attention_heads，可大幅降低 KV Cache 占用。
若无 GQA/MQA，则 num_kv_heads = num_attention_heads，此时 kv_dim ≈ hidden_dim。
以 LLaMA-2-70B (GQA, 80 层，num_kv_heads=8, head_dim=128) 为例：
单请求 4K 上下文 (FP16) = 2 × 1 × 80 × 4096 × (8×128) × 2 ≈ 1.34 GB
对比：若无 GQA (num_kv_heads=64)，同样配置则需 ≈ 10.7 GB
这正是 GQA 技术的价值——在保持模型能力的同时，将 KV Cache 压缩约 8 倍。
这意味着：KV Cache 的管理效率，直接决定了系统能支撑的并发量。 理解 GQA/MQA 等注意力变体对 KV Cache 的影响，是进行容量规划的前提。
2.2 Prefill vs Decode：两阶段的性能特征
| 阶段 | 计算特点 | 瓶颈类型 | 优化方向 |
|---|---|---|---|
| Prefill（预填充） | 并行处理整个 Prompt | 计算密集型 | 提升算力利用率 |
| Decode（解码） | 逐 Token 串行生成 | 访存密集型 | 优化内存带宽 |
大部分推理引擎的优化，都围绕这两个阶段的特性展开。
2.3 Batching 策略演进
# 静态 Batching（传统方式）
├── 所有请求等待最长序列完成
├── 显存利用率低
└── 延迟不可控
# Continuous Batching（动态批处理）
├── 请求完成即释放，新请求立即加入
├── 显存利用率大幅提升
└── 系统吞吐量提升 2–4 倍
注：Continuous Batching（也称 In-flight Batching）并非某个引擎独创，TGI、TensorRT-LLM 等也有类似实现。vLLM 的贡献在于将 PagedAttention + Continuous Batching 做成了工程上极具影响力的开源方案，并在社区中广泛传播。
三、重点引擎深度解析：从通用到极致
3.1 Transformers：研究者的瑞士军刀
Hugging Face 的 Transformers 库在 LLM 领域的地位，类似于 Python 标准库。它强调的是通用性与易读性，而非生产环境的极致吞吐。
适用场景：
- 模型微调与训练
- 快速原型验证
- 学术论文复现
- 小规模推理任务
核心痛点：通用性优先，而非极致调度
Transformers 近年已抽象出多种 KV Cache 策略（Dynamic/Static/Quantized/Offloaded 等），并非只有简单的