已完成
大模型推理系统全景
推理系统不是“谁更快”的问题，而是“分工协作、各司其职”。理解三层架构，才能选对工具。
大模型推理的三层架构
大语言模型（LLM, Large Language Model）推理系统可以精确划分为三层架构。下图展示了各主流方案在三层中的定位与关系：
三层职责定义如下：
| 层级 | 名称 | 解决的问题 |
|---|---|---|
| L0 模型层 | 模型结构 + 权重 | 网络结构、参数、算子实现 |
| L1 推理引擎层 | vLLM / SGLang / TensorRT / MLC | 如何让推理更快、更省显存、更高吞吐 |
| L2 服务层 | TGI / Infery / KServe | 如何把模型变成稳定的 API 服务 |
理解这三层后，所有工具的关系一目了然。
推理引擎层（L1）：定位与主流方案
推理引擎层是大模型的 Runtime（运行时），负责高效调度、内存管理和批处理。不同方案各有侧重：
- vLLM：GPU 显存分页、动态批处理、KV Cache 管理、FlashAttention。适合高并发 API 服务、多模型共存、长上下文、SaaS 场景。
- TensorRT-LLM：GPU 编译器，极致吞吐，支持 FP8/INT8/INT4 量化，适合企业级大规模服务。缺点是灵活性差、编译复杂。
- SGLang：在 vLLM 基础上强化结构化输出（JSON/函数调用）、树状并行执行，适合 Agent 系统和工具调用。
- MLC LLM：跨后端编译器，支持 WebGPU、移动端、边缘设备，追求“Anywhere LLM”。
- llama.cpp：轻量级 CPU/本地推理引擎，GGUF 量化，适合本地 App、插件、嵌入式场景。
- PyTorch / HF Transformers：研究和原型开发的基础框架，性能不及专用推理引擎。
下面的雷达图对比了五大流行的推理框架：
以下是雷达图各能力项的解释：
- 模型兼容性：衡量推理系统支持的模型数量和架构类型，兼容性越强，适配范围越广。
- 性能吞吐：指每秒生成 Token 的能力，以及连续批处理的效率，直接影响服务响应速度和并发能力。
- KV-Cache 技术深入度：评估 KV-Cache（键值缓存）机制的优化程度，如 PagedAttention、RadixAttention 或缓存复用，决定推理效率和显存利用率。
- 量化支持丰富度：量化算法的多样性，包括 INT8、INT4、GGUF、AWQ、GPTQ 等，影响模型在不同硬件上的部署灵活性和性能。
- 部署灵活性：支持本地、云端、边缘设备、Kubernetes 等多种环境，越灵活越易于集成到不同业务场景。
- API 兼容性：与 OpenAI API 的对齐程度，决定能否无缝替换或集成到现有应用。
- 多卡扩展性：分布式推理能力，支持多 GPU 或多节点扩展，适合大规模服务部署。
- 本地化能力：在 CPU、ARM、Mac 或边缘端的可用性，决定是否能在本地或低资源环境运行。
- 可观测性：监控、追踪和日志功能的完善程度，便于运维和故障排查。
- 社区活跃度：项目更新频率、社区讨论热度、生态规模，反映工具的持续发展和支持力度。
vLLM：推理 OS（操作系统级调度器）
vLLM 的核心能力包括：
- PagedAttention（显存分页）
- 动态 Batching（并发处理）
- 高效 KV Cache 管理
- FlashAttention
一句话总结：
vLLM = 把 GPU 显存做成了“虚拟内存 + Kubernetes 调度器”。
适用场景：
- 高并发 API 服务
- 多模型共存
- 长上下文、请求随机
- SaaS / 产品级推理后台
vLLM 是目前开源推理的事实标准。
SGLang：结构化输出场景的最强推理引擎
SGLang 在 vLLM 的并发模型上进一步优化，专注于结构化输出和多阶段推理：
- Sub-Query Tree（树状并行执行）
- Structured Output（JSON/函数调用）
- FlashInfer + Kernel Fusion
一句话总结：
SGLang = vLLM + 多阶段结构化推理优化 = 结构化输出第一。
适用场景：
- 需要 JSON / 函数调用的 Agent 系统
- 工具调用 / 多轮模式
- 高并发 API 服务
TensorRT-LLM：企业场景吞吐量王者
TensorRT-LLM 以极致吞吐为目标，专为 NVIDIA GPU 优化：
- FP8 / INT8 / INT4 量化加速
- CUDA Kernel 编译优化
- 企业级 GPU 集群
一句话：
TensorRT-LLM = GPU 编译器，极限优化吞吐，牺牲灵活性。
适用场景：
- 大规模在线服务（每秒上千 RPS）
- 企业 GPU 集群
- NVIDIA Triton 等产品体系
缺点：
- 建模/编译复杂
- 动态性差
- 非 NVIDIA GPU 基本无法使用
MLC LLM：跨后端推理编译器
MLC LLM 追求“Anywhere LLM”，让模型能在任何设备上运行：
- WebGPU 推理（浏览器）
- 移动端 iOS/Android
- LLVM/TVM 编译器体系
适用场景：
- 移动端应用
- 浏览器推理（安全/隐私）
- 边缘设备（无 GPU）
llama.cpp：轻量级 CPU/本地推理引擎
llama.cpp 是边缘设备和本地推理的首选：
- CPU 高性能
- GGUF 量化
- 便携、简单
- 全平台可用（树莓派也能跑）
适用场景：
- 轻量模型
- 本地 App
- 插件、扩展、桌面软件等嵌入式场景
Accelerate：HuggingFace 的训练/推理统一层
Accelerate 是 PyTorch 的多 GPU 封装层，训练和推理通用 API，适合研究和快速验证，不关注推理性能。
服务编排层（L2）：模型 API 化与网关
服务层负责模型 API 化、扩容、负载均衡、限流、日志监控、多模型路由等。典型方案有：
- HuggingFace TGI (Text Generation Inference)：工程性好，自动 batching，支持多模型管理，适合企业 API 服务。
- Infery：前端 + 后端一体的推理网关，自动路由、监控、模型/版本管理，更偏向产品化和企业可用。
- OpenAI-Style Gateway、Ray Serve、KServe：多样化的 API 网关和服务编排方案。
工具对比表
下表总结了主流推理系统的分类、最擅长场景与局限：
| 工具 | 分类 | 最擅长的场景 | 不适合做什么 |
|---|---|---|---|
| vLLM | 推理引擎 | 高并发 API 服务 | 浏览器/移动端 |
| SGLang | 推理引擎 | 结构化输出 + Agent 系统 | 极端吞吐优化 |
| TensorRT-LLM | 编译器级推理引擎 | 企业级吞吐、FP8、NVIDIA GPU | 多模型频繁切换 |
| MLC LLM | 编译器/跨平台 | WebGPU / 移动端 | 大规模服务端 |
| llama.cpp | 轻量运行时 | CPU 推理 / 本地软件 | 大吞吐场景 |
| HF Transformers | 框架 | 研究 / 原型开发 | 性能要求高的服务 |
| TGI | 服务层 | 模型 API 化 | 推理性能优化 |
| Infery | 服务层 | 企业多模型管理 | 底层算子优化 |
下图对比了大模型推理系统的五大框架，清晰展示每个框架的专场链路。
为便于快速选型，以下表格补充主流推理框架的核心特性横向对比：
| 特性/框架 | vLLM | SGLang | TGI | llama.cpp |
|---|---|---|---|---|
| 模型兼容性 | 支持主流自回归模型，兼容 OpenAI API | 支持多种开源模型，结构化输出 | 支持主流大模型，分布式部署 | 专为 LLaMA 系列设计，兼容 OpenAI API |
| 量化支持 | 支持多种量化（AutoAWQ、bitsandbytes） | 依赖后端，量化支持有限 | 丰富量化方案，支持多格式 | 原生 GGUF，多种低比特量化 |
| KV-Cache 管理 | PagedAttention 分页，Prefix 复用 | 跨请求缓存，RadixAttention | 分页缓存，流水线并行 | 基础缓存，独立请求 |
| 并发与吞吐 | 连续批处理，高并发高吞吐 | 动态拼批，多线程并发 | 批处理，分布式并发 | 并发有限，适合低并发 |
| 本地/云端部署 | GPU/CPU，支持容器化 | 多平台，K8s/Docker | 多后端，企业级云原生 | 轻量级，跨平台本地部署 |
| 接口兼容性 | 完全兼容 OpenAI API | 类 OpenAI/结构化输出 | RESTful API，社区适配 OpenAI | OpenAI API，Python 嵌入 |
推理框架选型简要流程
下面是推理框架选型流程图：
实际选型时，可结合以下关键维度快速判断：
- 硬件环境：CPU/Apple Silicon 优先 llama.cpp，GPU 场景优先 vLLM、TGI、SGLang。
- 模型规模：7B 以下本地优先 llama.cpp，大模型推荐 vLLM/TGI。
- 接口需求：OpenAI API 兼容优先 vLLM/llama.cpp，结构化输出优先 SGLang。
- 吞吐并发：高并发优先 vLLM/TGI，低并发本地优先 llama.cpp。
- 量化需求：极致量化优先 TGI/llama.cpp，vLLM 量化能力持续增强。
- 部署方式：云端容器化优先 TGI/vLLM/SGLang，本地轻量优先 llama.cpp。
容量与成本粗略估算公式
- 显存需求 ≈ 模型参数量 + 并发 × 每请求显存
- 最大并发 ≈ (GPU 显存总量 - 模型占用) / (输入长度 × 隐层维度 × 8 bytes)
- 吞吐量 ≈ 并发 × 平均输出 Token 数 / 平均响应时间
- 成本 ≈ 使用时长 × 单价 × 实例数 + 存储成本
以上公式仅供初步规划，实际需结合模型和硬件实测。
选型指南
根据实际需求选择合适的推理系统：
- 本地开发 / 桌面应用：llama.cpp / MLC
- Web App（浏览器）：MLC LLM (WebGPU)
- 企业级高并发 API 服务：vLLM 或 SGLang
- Agent / 工具调用 / JSON 输出：SGLang
- 极限吞吐（上千 QPS）：TensorRT-LLM + Triton
- 简单部署：TGI
- 多模型管理、面向企业：Infery / AI Gateway
云原生工程师视角的终极类比
下表用云原生组件类比主流 LLM 推理系统：
| LLM 推理系统 | 云原生组件类比 |
|---|---|
| vLLM | kube-scheduler + Kubelet（调度 + 运行时） |
| SGLang | kube-scheduler + Envoy Filter（结构化控制） |
| TensorRT-LLM | LLVM + GPU Driver（底层编译器） |
| MLC | WASM / Cross compiler（跨后端编译） |
| llama.cpp | containerd（轻量本地运行时） |
| TGI | Istio Gateway / APIServer（统一入口、路由） |
| Infery | 企业 API Gateway + ModelOps |
通过这些类比，可以快速定位每个系统的工程角色。
总结
大模型推理生态不是“谁更好”，而是“职责不同、场景不同”。
- vLLM = 大模型推理的 Linux + Kubelet
- SGLang = 结构化推理的 Envoy Filter
- TensorRT-LLM = GPU 编译器（极限优化）
- MLC = 跨平台运行时（WebGPU / 移动端）
- llama.cpp = 本地轻量引擎
- TGI/Infery = AI Gateway + Serving 层