面向LLM与本地AI硬件的推理引擎（2026版）

先选推理引擎就错了。得先定硬件策略、工作负载形态和服务模型——引擎是跟着这些走的。

这是思考LLM推理引擎最实用的方式。

系列说明： 本文是我“自托管LLM/本地AI”系列教学的第3部分。

• 第1部分：LLM的GPU内存数学（2026版）。
• 第2部分：本地AI硬件的内存带宽（2026版）。

前两篇解释了硬件容量和带宽的计算逻辑。

本篇阐释将硬件转化为可用推理的软件层。

引擎

这些工具服务于不同目的 / 处于不同层次

• 本地可移植性
• 消费级CUDA
• Apple统一内存工作流
• 量化推理
• 生产级服务
• 分布式编排
• 厂商优化的数据中心执行

一个有用的思维模型：

推理引擎不是“模型”。它是交通警察、内存管理器、内核调度器、调度器、缓存会计、并行性规划师、API接口，有时还是部署框架。

最好的引擎匹配你的内存层级、互联、量化格式、延迟与吞吐量目标、模型架构和运维成熟度。

一页决策指南

• 笔记本 / 边缘 / 特殊硬件 → llama.cpp
• Mac优先工作流 → MLX / MLX-LM
• 单卡RTX本地推理 → ExLlamaV2
• 2-4+ NVIDIA / CUDA GPU → ExLlamaV3
• 通用生产服务 → vLLM
• 长上下文 / MoE / 路由 → SGLang
• NVIDIA最高性能 → TensorRT-LLM
• 集群编排 → NVIDIA Dynamo

本指南其余部分解释原因。

推理引擎到底在做什么

推理引擎加载权重、对输入进行分词、执行前向传播、采样token、维护KV缓存并流式传输结果。严肃的引擎还处理批处理、调度、前缀缓存、量化、并行执行、API服务、指标和分布式执行。

工作负载包含两个阶段：

预填充读取提示并构建初始KV缓存。它是计算密集型的。

解码每次生成一个token，反复读取权重和KV缓存。它受内存带宽限制。解码速度更依赖于内存带宽而非峰值计算能力。

这一区分几乎解释了一切：

• 短提示，长回答： 解码占主导 → 内存带宽和批处理重要。
• 长提示，短回答： 预填充占主导 → 注意力内核和分块预填充重要。
• 多用户： 调度器质量重要 → 连续批处理、缓存分页、公平性。
• 长上下文： KV缓存占主导 → 分页注意力、KV量化、卸载。
• MoE： 专家路由占主导 → 专家并行、互联、分组GEMM。
• 多节点： 互联占主导 → NVLink、RDMA、流水线并行、分离式架构。

PagedAttention解决了KV缓存碎片化问题。FlashAttention利用IO感知分块减少了HBM（高带宽内存）流量。推测性解码生成廉价token并并行验证。反复出现的主题：推理性能等于内存移动加上调度。

真正的瓶颈

1. 内存带宽，而不仅仅是显存大小。 显存决定能否装下。带宽决定解码速度。Apple M3 Ultra提供高达819 GB/s的统一内存带宽。NVIDIA H100 SXM标称3.35 TB/s的GPU内存带宽。统一内存允许你装下消费级显存装不下的模型。HBM允许你在模型装得下时更快地服务它们。装得下不等于速度快。容量不等于带宽。

2. KV缓存增长。 KV缓存随批大小和上下文长度增长。长上下文工作负载可能在权重装得下的情况下耗尽内存。PagedAttention将KV缓存划分为块，提高了利用率并支持更大批次。

3. 互联。 一旦模型跨越GPU边界（多GPU），就要付出通信代价。张量并行需要频繁的all-reduce集合操作。流水线并行在阶段边界通信。专家并行需要MoE的全对全流量。vLLM文档指出，没有NVLink时，流水线并行可能优于张量并行。

4. 调度器质量。 好的调度器决定哪些请求进入批次，预填充和解码如何共享加速器，长提示是否会阻塞短解码，以及如何避免饥饿。支持批处理不等于具备生产级调度器的行为。

5. 运行时开销。 CUDA图、内核融合、采样开销、分词器开销、HTTP开销、LoRA切换、结构化解码等都很重要。在规模较大时，恼人的2%开销会联合起来，需要关注（无歧义）。

引擎家族

有四大类：

可移植的本地运行时： llama.cpp、MLC LLM、ONNX Runtime GenAI、OpenVINO、Ollama风格的工具。它们关心的是“让它在这里跑起来”。

Apple / 统一内存运行时： MLX和MLX-LM。它们关心的是“充分利用大共享内存和Apple的栈”。

消费级CUDA量化引擎： ExLlamaV2和ExLlamaV3。它们关心的是“让我的3090/4090/5090用低位权重飞起来”。

生产级服务引擎： vLLM、SGLang、TensorRT-LLM、TGI、LMDeploy。它们关心的是并发用户、KV缓存、批处理、并行性、可观测性和每token成本。

然后是编排层如Dynamo，位于引擎之上，协调集群、分离式预填充/解码、路由和自动扩缩。

llama.cpp：可移植性之王

当硬件是奇特的、受限的、离线的、CPU偏重的、边缘的、或者不是整齐的NVIDIA数据中心节点时，llama.cpp就是答案。

它支持Apple Silicon（通过ARM NEON、Accelerate和Metal）；x86（通过AVX/AVX2/AVX512/AMX）；RISC-V；低位量化；CUDA；AMD（通过HIP）；MUSA；Vulkan；SYCL；以及CPU+GPU混合卸载。这就是为什么llama.cpp拥有“只管让它跑起来”的车道。

HTTP服务器比“玩具式本地运行器”更强大。llama-server提供OpenAI兼容路由、Anthropic Messages API兼容、重排序、连续批处理、多模态支持、JSON schema约束、函数调用、推测性解码和Web UI。

关键限制：llama.cpp不适合严肃的多节点生产服务。其RPC后端明确文档说明是概念验证、脆弱且不安全的。

结论： 当可移植性、离线操作、GGUF或混合卸载比舰队级服务更重要时，使用llama.cpp。

不要用于多GPU。

MLX和MLX-LM：Apple Silicon的武器

MLX是Apple针对Apple Silicon的数组框架，MLX-LM是构建其上的LLM包。它是Mac优先的ML栈。

关键硬件事实是统一内存。Apple Silicon让CPU和GPU直接访问同一内存池。MLX数组存在于统一内存中，你选择设备运行操作，而不是在独立内存空间之间移动数组。

这改变了本地推理的权衡。在独立GPU系统上，问题是“它能装进显存吗？”在具有大统一内存的M系列Mac上，问题变为“它能装进内存吗？内存系统能足够快地向GPU提供数据吗？”大量化的模型可以装在消费级24GB显存不可能的机器上。

然而，它也更慢。

MLX-LM增加了Hugging Face Hub集成、量化、LoRA和全量微调、分布式推理，以及庞大的MLX Community模型生态系统。MLX不再仅限于Mac：它为Linux提供CUDA和纯CPU包。分布式通信支持MPI、基于TCP的Ring、用于Thunderbolt上RDMA的JACCL以及用于CUDA的NCCL。

MLX-LM自身的服务器也警告不推荐用于生产，因为它只实现了基本安全检查。

结论： 在Mac优先的ML和LLM工作流中使用MLX。对于高并发公共服务，请使用真正的服务栈。

ExLlamaV2和V3：消费级CUDA，调优且快速

ExLlamaV2是面向希望消费级NVIDIA GPU超常发挥的本地CUDA量化引擎。它支持分页注意力、动态批处理、提示缓存、KV缓存去重、批量生成、流式和推测性解码。需要记住的关键词是本地。它使量化模型在现代CUDA GPU上快速运行，尤其是消费级显卡。

最佳适用场景：单张RTX 3090/4090/5090盒子、本地编码助手、本地聊天、EXL2量化模型、发烧友工作站。

ExLlamaV3将理念扩展到多GPU和MoE本地推理。它增加了基于QTIP的EXL3量化格式、针对消费级硬件的灵活张量并行和专家并行推理、通过TabbyAPI提供的OpenAI兼容服务器、连续动态批处理和多模态支持。

当你有2-4+张消费级NVIDIA GPU或想要本地MoE时，V3很有吸引力。需注意：某些模型在ExLlamaV3中不支持张量或专家并行。

结论： ExLlamaV2是发烧友的本地CUDA引擎。ExLlamaV3是多GPU（2-4）本地设置的前沿。以更具粗糙的边缘换取更好的能力。

vLLM：默认的开源生产服务器

vLLM是大多数团队在严肃开源LLM服务中应首先评估的引擎。

它提供基于PagedAttention的KV内存管理、连续批处理、分块预填充、前缀缓存、CUDA/HIP图、广泛的量化（FP8、MXFP8/MXFP4、NVFP4、INT8、INT4、GPTQ、AWQ、GGUF）、优化的注意力和GEMM/MoE内核、推测性解码、torch.compile以及分离式预填充/解码/编码。

它也很灵活：张量/流水线/数据/专家/上下文并行、流式输出、结构化输出、工具调用、OpenAI兼容和Anthropic Messages API、gRPC、多LoRA，并支持NVIDIA、AMD、x86/ARM/PowerPC CPU，以及TPU、Gaudi、昇腾、Apple Silicon等的插件。

vLLM文档指出，多节点部署通常使用Ray，没有NVLink时，流水线并行可能优于张量并行。陷阱是假设vLLM消除了系统思考的需要。你仍然需要调优批处理、上下文长度、GPU内存利用率、并行布局和路由。vLLM提供了非常好的引擎；它仍然需要良好的系统设计。

结论： 如果有人问“我们需要在生产中服务开放模型”，vLLM是默认起点。

SGLang：vLLM的系统思维表亲

SGLang是当服务工作负载变得丑陋时的选择：结构化输出、长上下文、MoE、分离和路由。

它提供RadixAttention前缀缓存、预填充-解码分离、推测性解码、连续批处理、分页注意力、张量/流水线/专家/数据并行、结构化输出、分块预填充和多LoRA批处理。它支持NVIDIA、AMD、Intel Xeon、Google TPU、昇腾NPU等。

SGLang的差异化在于服务架构。其预填充-解码分离将计算密集的预填充与内存密集的解码分离到专用实例，并在它们之间传输KV缓存。这防止了长预填充批次中断解码并导致token延迟飙升。

结论： SGLang适用于那些瓶颈不再是“我们能跑模型吗？”，而是“我们能在恶劣流量下跑模型而不烧毁延迟、内存和成本吗？”的团队。

TensorRT-LLM：最高NVIDIA性能

TensorRT-LLM是NVIDIA最高性能的栈。它是优化的、专业的、强大的，并且不假装可移植。

它提供Python API来构建TensorRT引擎，包含最先进的优化，以及Python和C++运行时。它包括用于注意力、GEMM和MoE的自定义内核；预填充-解码分离、宽专家并行、推测性解码；以及集成NVIDIA Dynamo和Triton推理服务器的高级Python API。

B200 GPU可以加载FP4权重并使用优化内核。H100及更高版本支持FP8量化，相比16位可将性能翻倍并将内存消耗减半，同时精度损失极小。

其闪光点：H100/H200/B200/GB200/GB300级别的集群、纯NVIDIA数据中心、FP8/FP4部署、多节点服务和大规模MoE。尴尬之处：AMD、Apple或Intel的可移植性；快速变化的实验模型；小型本地设置；以及需要“到处都能跑”的团队。

结论： 如果你隶属于NVIDIA并关心绝对性能，TensorRT-LLM值得加入对比测试。你用可移植性换取性能。专业性带来的功能较少。

其他引擎

TGI是Hugging Face的生产服务器，提供追踪、指标、张量并行和连续批处理。当HF集成和简单性重要时使用。

MLC LLM是以编译器优先的通用部署引擎，提供跨REST、Python、JavaScript、iOS和Android的OpenAI兼容API。最适合“到处部署LLM”，尤其是浏览器、移动端和原生应用。

ONNX Runtime GenAI在ONNX Runtime上实现了完整的生成循环，驱动着Foundry Local、Windows ML和VS Code AI Toolkit。它支持CPU、CUDA、DirectML、TensorRT-RTX、OpenVINO、QNN、WebGPU和AMD GPU。最适合应用部署和ONNX工作流。

OpenVINO GenAI是面向Intel的优化故事，支持Xeon CPU、Arc GPU、Core Ultra和NPU。它提供OpenAI兼容服务，带有连续批处理和分页注意力。最适合Intel硬件。

LMDeploy是一个以CUDA为中心的工具包，使用TurboMind实现性能，使用PyTorch实现易用性。对希望替代vLLM/SGLang/TensorRT-LLM的CUDA用户最有趣。

NVIDIA Dynamo是一个位于引擎（如vLLM、SGLang和TensorRT-LLM）之上的分布式编排层，支持分离、智能路由和多层KV缓存。当单引擎服务不再足够时使用。

注意：不要使用Ollama。

硬件策略配方

• 纯CPU服务器： 首选llama.cpp。Intel Xeon用OpenVINO。应用/ONNX部署用ONNX Runtime GenAI。
• MacBook / Mac Studio： Mac原生工作流用MLX / MLX-LM。GGUF可移植性用llama.cpp。
• 单张RTX 3090 / 4090 / 5090： EXL2本地推理用ExLlamaV2。GGUF或可移植性用llama.cpp。多用户服务用vLLM。
• 双卡或四卡消费级RTX盒子： 多GPU量化推理或MoE用ExLlamaV3。服务行为重要时用vLLM。测试路由或长上下文模式用SGLang。
• 8×H100 / H200节点： 从vLLM或SGLang开始。如果纯NVIDIA且性能调优合理，则对比TensorRT-LLM。需要多节点编排时使用Dynamo。
• B200 / GB200 / GB300级别基础设施： 对比TensorRT-LLM、SGLang和vLLM。加入Dynamo实现集群级编排、KV感知路由和自动扩缩。
• AMD MI300 / MI325 / MI350 / MI355： 从ROCm上的vLLM或SGLang开始。避免假设NVIDIA基准测试能直接迁移。
• Intel Xeon / Core Ultra / Arc： OpenVINO GenAI或OpenVINO Model Server。应用嵌入重要时用ONNX Runtime GenAI。
• 浏览器、移动端、应用原生： MLC LLM / WebLLM或ONNX Runtime GenAI。

基准测试：测量什么

糟糕的基准测试：“我得到了180 tok/s。”

好的基准测试包括：

模型： 确切模型、架构、参数数量、激活MoE参数。

权重： 数据类型、量化格式、分组大小、校准。

引擎： 版本、提交、后端、标志。

硬件： GPU型号、内存容量、带宽、互联、CPU、RAM。

工作负载： 输入/输出长度分布、并发、流式、共享前缀、结构化输出。

指标： TTFT、TPOT、端到端延迟、p50/p95/p99、每秒token数、每秒请求数、GPU内存使用、KV缓存命中率、预填充吞吐量、解码吞吐量、每百万token成本。

基准测试规则：

• 永远不要仅使用单用户的每秒token数来比较引擎。