选择合适的推理框架

一旦你选定了模型,下一步就是选择如何运行它。你选择的推理框架直接影响延迟、吞吐量、硬件效率和功能支持。没有放之四海而皆准的解决方案。正确的选择取决于你的部署场景、工作负载、模型和基础设施。

什么是推理框架?

推理框架是加载模型、在合适的硬件上运行并向应用程序提供输出的软件层。对于 LLM,这通常不仅仅意味着调用模型的 forward() 函数。框架还管理 token 生成、KV 缓存、批处理、流式响应、显存限制和请求处理。

你可能还会看到这些工具被称为推理运行时、推理引擎、推理后端或模型服务器。具体含义因项目而异,但核心工作是相同的:使模型执行在训练笔记本之外高效且可用。

为什么我需要推理框架?

你可以直接用 PyTorch 或 Hugging Face Transformers 中的原始模型运行推理。这对于实验、本地测试或一次处理一个请求通常已经足够。但对于生产推理来说通常不够。

训练框架围绕学习权重构建。它们支持反向传播、优化器步骤、梯度累积和大规模训练批次。推理有不同的目标:低延迟、高吞吐量、稳定的显存使用、流式输出,以及在并发流量下可预测的行为。

推理框架处理原始模型执行无法很好解决的与服务相关的工作,例如:

• 批处理与调度:合并活动请求,让 GPU 保持忙碌。
• KV 缓存管理:高效存储注意力状态,以支持长提示词和多轮对话。
• 流式输出:在生成 token 时即时返回,而不是等待完整响应。
• 显存控制:在有限的 GPU 显存中装下更大的模型和更多的并发请求。
• 生产 API:提供兼容 OpenAI 的 API或框架特定的端点。
• 多 GPU 支持:当单个 GPU 不够时,将大型模型拆分到多个设备上。

这些框架将大部分模型执行复杂性隐藏在你可以调优的服务选项之后。下面是服务 Gemma 4 31B 的一个示例。标志名称和可接受的值各不相同,但每个框架都暴露了类似的参数类别,如模型并行、显存利用率和最大序列长度。你可以直接调整这些参数,而无需改动模型本身。

MAX

max serve --model google/gemma-4-31B-it \
  --devices gpu:0,1 \
  --max-batch-size 16 \
  --device-memory-utilization 0.95 \
  --max-length 262144

vLLM

vllm serve --model google/gemma-4-31B-it \
  --tensor-parallel-size 2 \
  --gpu-memory-utilization 0.90 \
  --enable-auto-tool-choice \
  --reasoning-parser gemma4 \
  --tool-call-parser gemma4 \
  --chat-template examples/tool_chat_template_gemma4.jinja \
  --limit-mm-per-prompt '{"image": 4, "audio": 1}' \
  --async-scheduling

SGLang

sglang serve --model-path google/gemma-4-31B-it \
  --reasoning-parser gemma4 \
  --tool-call-parser gemma4 \
  --mem-fraction-static 0.9 \
  --host 0.0.0.0 --port 30000

通过抽象掉底层基础设施工作,推理框架让你专注于构建应用程序,而不是为每种模型架构重新实现推理逻辑。

好处不仅仅是便利。一个好的推理框架可以改善同一模型在同一硬件上的延迟、吞吐量和成本表现。例如,在 2023 年的基准测试中,vLLM 团队报告称,在不改变底层模型架构的情况下,吞吐量比 Hugging Face Transformers 高出 24 倍。

同样的差距也出现在不同推理框架之间,而不仅仅是与原始 Transformers 相比。在2026 年的基准测试中,Modular 报告称,在 NVIDIA B200 上使用 MAX 服务 google/gemma-4-31B-it,P99 TTFT 快 2.5 倍,吞吐量是 vLLM 的 1.5 倍。这些数字与具体工作负载相关,因此请将它们视为对自己的流量进行基准测试的理由,而不是在所有地方都成立的排名。

推理框架与工具

用于构建高吞吐量、低延迟 LLM 应用的流行推理框架包括:

• vLLM。一个为服务 LLM 优化而生的高性能推理引擎。它以高效利用 GPU 资源和快速解码能力而闻名。
• SGLang。一个用于 LLM 和视觉语言模型的快速服务框架。它通过协同设计后端运行时和前端语言,使与模型的交互更快、更可控。
• MAX。Modular 出品的高性能 AI 服务框架。它为跨 CPU 和 GPU 的 AI 计算工作负载提供一套集成的工具,并支持在模型和内核层面进行定制。
• LMDeploy。一个专注于提供高解码速度和高效处理并发请求的推理后端。它支持各种量化技术,使其适合以更低显存需求部署大型模型。
• TensorRT-LLM。一个利用 NVIDIA TensorRT(一个高性能深度学习推理库)的推理后端。它为在 NVIDIA GPU 上运行大型模型而优化,提供快速推理并支持量化等高级优化。
• TokenSpeed。LightSeek Foundation 出品的推理引擎,面向智能体(agentic)工作负载。它拥有可插拔的分层内核系统、配备安全 KV 缓存管理的精密调度器、编译器支撑的并行性,以及兼容 OpenAI 的服务 API。
• Hugging Face TGI。一个用于部署和服务 LLM 的工具包。它在 Hugging Face 生产环境中用于驱动 Hugging Chat、Inference API 和 Inference Endpoint。请注意,Hugging Face TGI 目前处于维护模式。这意味着它仍然受支持且可用,但不会再进行重大的功能开发或新的性能优化。如果你在生产环境中运行 TGI,那么随着性能和扩展需求的增长,值得规划一条升级路径。

如果你的硬件有限,或面向桌面/边缘设备,以下工具针对低资源环境进行了优化:

• llama.cpp。一个用纯 C/C++ 实现、无外部依赖的轻量级 LLM 推理运行时。其主要目标是让 LLM 推理在广泛的硬件上快速、可移植且易于运行。尽管名字如此,llama.cpp 支持的远不止 Llama 模型。它支持 Qwen、DeepSeek 和 Mistral 等许多流行架构。该工具非常适合低延迟推理,并且在消费级 GPU 上表现出色。
• MLC-LLM。一个用于 LLM 的 ML 编译器和高性能部署引擎。它构建于 Apache TVM 之上,在服务模型之前需要编译和权重转换。MLC-LLM 可用于广泛的硬件平台,支持 Linux、Windows、macOS、iOS、Android 和网页浏览器上的 AMD、NVIDIA、Apple 和 Intel GPU。
• Ollama。一个基于 llama.cpp 构建的用户友好的本地推理工具。它专为简单易用而设计,非常适合在你的笔记本电脑上以最少的设置运行模型。然而,Ollama 主要用于单请求用例。与 vLLM、SGLang 或 MAX 等运行时不同,它不支持并发请求。这一点很重要,因为许多推理优化(如分页注意力、前缀缓存和动态批处理)只有在并行处理多个请求时才有效。

其中一些框架也已经从文本生成扩展到服务扩散模型。

• SGLang Diffusion 支持 FLUX、Wan 和 Qwen-Image 等图像和视频模型。
• vLLM-Omni 将 vLLM 扩展到扩散 Transformer(DiT)和其他并行的、非自回归的生成模型,涵盖文本、图像、视频和音频。
• MAX 服务 FLUX 等扩散模型,速度比原生 PyTorch 快达 4 倍。

库模式与服务端模式

许多模型推理框架(如 vLLM 和 SGLang)支持两种部署模式。你可以将框架作为库嵌入到应用程序中,以更好地控制执行,也可以将其作为独立服务器运行,由外部客户端通过 HTTP API 调用。

将框架作为库嵌入

库模式将推理引擎加载在与应用程序相同的进程中。这对于离线批处理作业、评估流水线,以及需要直接访问引擎输出而无需额外网络跳转的自定义服务非常适用。

例如,vLLM 和 SGLang 都为这种场景暴露了进程内引擎:

vLLM

vLLM 离线推理 API暴露了一个 LLM 类:

from vllm import LLM, SamplingParams

model = "meta-llama/Llama-3.1-8B-Instruct"
llm = LLM(model=model)

outputs = llm.generate(
    ["Explain continuous batching in two sentences."],
    SamplingParams(temperature=0.2, max_tokens=64),
)

SGLang

SGLang 的离线引擎提供了类似的接口:

import sglang as sgl

model = "meta-llama/Llama-3.1-8B-Instruct"
llm = sgl.Engine(model_path=model)

outputs = llm.generate(
    ["Explain continuous batching in two sentences."],
    {"temperature": 0.2, "max_new_tokens": 64},
)

现在,应用程序拥有引擎的生命周期。崩溃、依赖冲突或 GPU 显存不足错误都可能影响整个进程,因此这种模式需要仔细的资源与并发管理。

将框架作为独立服务器运行

服务端模式在单独的进程中运行推理引擎,并暴露 REST 或流式 API。当多个应用程序共享一个模型、客户端使用不同的编程语言,或服务层需要独立扩展和部署时,这通常是更好的边界。

启动一个兼容 OpenAI 的服务器:

MAX

max serve --model meta-llama/Llama-3.1-8B-Instruct

vLLM

vllm serve --model meta-llama/Llama-3.1-8B-Instruct

SGLang

sglang serve --model-path meta-llama/Llama-3.1-8B-Instruct

由于这些服务器暴露了兼容 OpenAI 的 API,应用程序代码可以使用相同的客户端接口,如下所示:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="EMPTY",
)

response = client.chat.completions.create(
    model="meta-llama/Llama-3.1-8B-Instruct",
    messages=[
        {"role": "user", "content": "Explain continuous batching in two sentences."}
    ],
    temperature=0.2,
    max_tokens=64,
)

print(response.choices[0].message.content)

服务器边界增加了网络和序列化开销,但将推理运行时与应用程序代码隔离开来。这使得路由、身份验证、可观测性和独立扩展更容易实现。在两种模式下,框架仍然负责模型执行、批处理和 KV 缓存管理。具体的选择取决于你的用例以及应用程序如何与该引擎集成。

为什么需要多个推理运行时?

在真实世界的部署中,没有哪个单一运行时对所有场景都是完美的。以下是 AI 团队最终经常使用多个运行时的原因:

不同的用例有不同的需求

模型、硬件和工作负载各不相同。最佳性能通常来自将每个用例与量身定制的运行时匹配。

• 高吞吐量、批处理:vLLM、SGLang、MAX、LMDeploy、TensorRT-LLM(需要调优以获得更佳性能)
• 边缘/移动端部署:MLC-LLM、llama.cpp
• 本地实验或单用户场景:Ollama 和 llama.cpp
• 扩散模型服务(图像/视频、多模态):SGLang Diffusion、vLLM-Omni、MAX

工具链和框架发展迅速

推理运行时不断更新。今天最好的工具,下个月可能就缺少某些功能。此外,有些模型在发布时只针对特定的运行时进行了优化(或支持)。

为了保持灵活性,你的基础设施应该与运行时无关。这让你可以结合每个工具的优势,而不会被锁定在单一技术栈中。

从本地 LLM 扩展到分布式推理

许多团队在扩展 LLM 推理时遵循相同的总体路径。

他们通常从 Ollama 等工具开始,在笔记本电脑或小型工作站上本地运行模型。这对于快速演示和早期原型开发非常有效。它简单且私密,但仅限于单用户工作负载,没有真正的并发或批处理。

从那里,团队转向高性能服务器运行时,这些运行时提供连续批处理、KV 缓存优化,并在数据中心 GPU 上提高 GPU 利用率。然而,这些运行时大多缺乏内置的多区域路由、自动故障转移和真正的水平扩展。GPU 供应、性能调优和容错能力实现起来也仍然复杂且耗时。

当团队需要跨多个 GPU 集群、区域或云运行和扩展推理时,他们通常会采用分布式推理平台,以在生产规模下处理自动扩展、路由、可观测性和合规性要求。这些平台开箱即用地提供高级功能,这意味着你的工程团队可以专注于产品创新,而不是构建和维护基础设施。

常见问题

所有推理框架都兼容每个 LLM 吗?

不总是。有些框架会优先支持特定的架构。其他的则需要时间才能添加多 GPU 支持、投机解码和自定义注意力后端等高级功能。在选择运行时之前,请务必检查特定于模型的兼容性。

哪些推理框架支持 LLM 的分布式推理?

有些模型太大,无法装入单个 GPU,因此你需要分布式推理。vLLM、SGLang 和 MAX 等框架提供了预填充-解码分离或跨多个工作节点的 KV 感知路由等高级优化。它们让你能够运行更大的模型、处理更长的上下文窗口,并在不触及显存限制的情况下服务更多的并发流量。

开始尝试推理框架的最佳方式是什么?

一个好的路径是从小处着手,然后循序渐进。许多人从 Ollama 开始,因为它在笔记本电脑上几乎不需要设置就能运行。它非常适合快速测试、提示词调试,或了解不同模型的行为。一旦你理解了基础知识,并想评估真实的生产性能,就可以转向 vLLM、SGLang 或 MAX。这些框架是为生产级工作负载而构建的,因此你可以在真实环境中衡量延迟、吞吐量、批处理行为和 GPU 效率。

其他资源

• LLM 性能基准测试