选择合适的推理框架

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

什么是推理框架？

推理框架是负责加载模型、在合适硬件上运行模型并向应用提供输出的软件层。对于 LLM 来说，这通常不仅仅是调用模型的 forward() 函数。框架还会管理 token 生成、 KV cache、批处理、流式响应、内存限制和请求处理。

你也可能看到这些工具被称为 inference runtime、inference engine、inference backend 或 model server。不同项目对术语的定义略有差异，但核心职责是相同的：让模型执行在训练笔记本之外依然高效且可用。

为什么我需要推理框架？

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

训练框架围绕权重学习而构建。它们支持反向传播、优化器更新、梯度累积以及大批量训练。推理的目标则完全不同：低延迟、高吞吐量、稳定的内存使用、流式输出，以及在并发流量下的可预测行为。

推理框架会处理原始模型执行难以妥善解决的服务相关工作，例如：

• 批处理与调度：合并活跃请求，让 GPU 始终保持忙碌。
• KV 缓存管理：高效存储长提示词和多轮对话所需的注意力状态。
• 流式输出：在 token 生成时即时返回，而不是等整段响应生成完毕。
• 内存控制：在有限的 GPU 内存中容纳更大的模型和更多并发请求。
• 生产级 API：暴露 OpenAI-compatible 或框架专有端点。
• 多 GPU 支持：当一张 GPU 不足以容纳模型时，将大模型拆分到多个设备上。

这些框架将大量模型执行复杂性隐藏在可调的服务选项之后。下面是一个使用 vLLM 为 DeepSeek-V4-Flash 提供服务的示例。你可以直接调节不同配置，而不必修改模型本身。vLLM 会自动为你处理这些工作。

vllm serve deepseek-ai/DeepSeek-V4-Flash \
  --trust-remote-code \
  --kv-cache-dtype fp8 \
  --block-size 256 \
  --enable-expert-parallel \
  --tensor-parallel-size 8 \
  --attention_config.use_fp4_indexer_cache=True \
  --moe-backend deep_gemm_mega_moe \
  --tokenizer-mode deepseek_v4 \
  --tool-call-parser deepseek_v4 \
  --enable-auto-tool-choice \
  --reasoning-parser deepseek_v4

通过抽象掉底层基础设施工作，推理框架让你把精力放在构建应用上，而不是为每种模型架构重复实现推理逻辑。

它带来的收益不只是便利。一个好的推理框架可以在相同硬件上显著改善同一模型的延迟、吞吐量和成本表现。例如，在 2023 年的一项基准测试中，vLLM 团队报告称，其吞吐量最高可达 Hugging Face Transformers 的 24 倍，而且无需对底层模型架构做任何改动。

推理框架与工具

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

• vLLM。一个面向 LLM 服务的高性能推理引擎，以高效利用 GPU 资源和快速解码能力著称。
• SGLang。一个面向 LLM 和视觉语言模型的高速服务框架。它通过联合设计后端 runtime 与前端语言，让你与模型的交互更快、更可控。
• MAX。Modular 推出的高性能 AI 服务框架。它为跨 CPU 和 GPU 的 AI 计算工作负载提供一体化工具套件，并支持在模型与kernel 层面进行定制。
• LMDeploy。一个专注于提供高解码速度和高效处理并发请求的 inference backend。它支持多种量化技术，适合在降低内存需求的同时部署大模型。
• TensorRT-LLM。一个利用 NVIDIA TensorRT 的 inference backend。TensorRT 是高性能深度学习推理库。该框架针对在 NVIDIA GPU 上运行大模型进行了优化，并支持量化等高级优化。
• Hugging Face TGI。一个用于部署和服务 LLM 的工具包。Hugging Face 在生产环境中用它支撑 Hugging Chat、Inference API 和 Inference Endpoint。需要注意的是，Hugging Face TGI 目前已进入 maintenance mode。这意味着它依然被支持并可继续使用，但不会再有主要功能开发或新的性能优化。如果你在生产环境中运行 TGI，随着性能或扩展需求增长，值得提前规划升级路径。

如果你的硬件资源有限，或目标是桌面端/边缘设备，那么以下工具针对低资源环境做了优化：

• llama.cpp。一个轻量级 LLM 推理 runtime，使用纯 C/C++ 实现，没有外部依赖。它的主要目标是让 LLM 推理快速、可移植，并易于在多种硬件上运行。尽管名字叫 llama.cpp，它支持的远不止 Llama 模型，还包括 Qwen、DeepSeek 和 Mistral 等多种流行架构。这个工具非常适合低延迟推理，并且在消费级 GPU 上表现良好。
• MLC-LLM。一个面向 LLM 的 ML compiler 与高性能部署引擎。它构建在 Apache TVM 之上，在为模型提供服务之前需要先进行编译和权重转换。MLC-LLM 可用于广泛的硬件平台，支持 Linux、Windows、macOS、iOS、Android 和 Web 浏览器上的 AMD、NVIDIA、Apple 与 Intel GPU。
• Ollama。一个构建在 llama.cpp 之上的本地推理工具，强调易用性和简单性，适合用最少的配置在笔记本上运行模型。不过，Ollama 主要面向单请求场景。与 vLLM 或 SGLang 这类 runtime 不同，它不支持并发请求。这一点很关键，因为许多推理优化，如 paged attention、prefix caching 和 dynamic batching，只有在并行处理多个请求时才真正有效。

这些框架中的一些也已经从文本生成扩展到了 diffusion models 的服务场景。

• SGLang Diffusion 支持 FLUX、Wan 和 Qwen-Image 等图像与视频模型。
• vLLM-Omni 将 vLLM 扩展到了 Diffusion Transformers (DiT) 以及其他并行、非自回归生成模型，覆盖文本、图像、视频和音频。
• MAX 为 FLUX 等 diffusion models 提供的服务速度最高可达原生 PyTorch 的 4 倍。

库模式 vs. 服务器模式

许多模型推理框架，如 vLLM 和 SGLang，都支持两种部署模式。你可以将框架作为库嵌入应用中，以获得更高的执行控制；也可以将它作为独立服务器运行，由外部客户端通过 HTTP API 调用。

将框架作为库嵌入

库模式会在与你的应用相同的进程中加载推理引擎。这种方式很适合离线批处理任务、评测流水线，以及那些需要直接访问引擎输出、又不想多一次网络跳转的自定义服务。

例如， vLLM offline inference API 暴露了一个 LLM 类：

from vllm import LLM, SamplingParams

model = "Qwen/Qwen2.5-0.5B-Instruct"
llm = LLM(model=model)

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

SGLang's offline engine 提供了类似接口：

import sglang as sgl

model = "Qwen/Qwen2.5-0.5B-Instruct"
llm = sgl.Engine(model_path=model)

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

此时，应用需要自行负责引擎生命周期。崩溃、依赖冲突或 GPU out-of-memory 错误都可能影响整个进程，因此这种模式要求更谨慎的资源和并发管理。

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

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

启动一个 OpenAI-compatible 的 vLLM 服务器：

vllm serve Qwen/Qwen2.5-0.5B-Instruct \
  --host 0.0.0.0 \
  --port 8000

或者启动一个 SGLang 服务器：

python -m sglang.launch_server \
  --model-path Qwen/Qwen2.5-0.5B-Instruct \
  --host 0.0.0.0 \
  --port 30000

由于两个服务器都暴露 OpenAI-compatible API， 应用代码可以像下面这样使用相同的客户端接口：

from openai import OpenAI

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

response = client.chat.completions.create(
    model="Qwen/Qwen2.5-0.5B-Instruct",
    messages=[
        {"role": "user", "content": "Explain continuous batching in two sentences."}
    ],
    temperature=0.2,
    max_tokens=64,
)

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

服务器边界会引入网络和序列化开销，但它把推理 runtime 与应用代码隔离开来。这使得路由、鉴权、可观测性和独立扩缩容更容易实现。无论采用哪种模式，框架都会负责模型执行、批处理和 KV 缓存管理。具体选择取决于你的用例以及应用与该引擎的集成方式。

为什么你会需要多个推理 runtime？

在真实部署中，没有任何一个 runtime 能完美覆盖所有场景。AI 团队最终往往会同时使用多个 runtime，原因如下：

不同用例有不同需求

模型、硬件和工作负载都不同。最佳性能往往来自为每个用例匹配最适合其环境的 runtime。

• 高吞吐、批处理：vLLM、SGLang、MAX、LMDeploy、TensorRT-LLM （为了获得更好的性能，通常需要调优）
• 边缘/移动端部署：MLC-LLM、llama.cpp
• 本地实验或单用户场景：Ollama 和 llama.cpp
• Diffusion model serving（图像/视频、多模态）：SGLang Diffusion、vLLM-Omni、MAX

工具链和框架变化很快

推理 runtime 持续在更新。今天最好的工具，下个月可能就会缺失某些关键特性。此外，一些模型在发布初期只会优先针对特定 runtime 做优化（或仅被其支持）。

为了保持灵活性，你的基础设施应尽量做到 runtime-agnostic。这样你就可以组合各类工具的最佳能力，而不会被锁定在单一技术栈中。

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

许多团队在扩展 LLM 推理时，都会走过相似的路径。

他们通常从 Ollama 之类的工具开始，在笔记本电脑或小型工作站上本地运行模型。这种方式适合快速演示和早期原型开发，简单且私密，但仅限于单用户工作负载，几乎没有真正的并发或批处理能力。

接下来，团队会迁移到 vLLM 这样的高性能服务器 runtime。这类框架提供 continuous batching、KV 缓存优化，以及在数据中心 GPU 上更高的利用率。不过，这些 runtime 中的大多数缺乏内建的多区域路由、自动故障切换和真正的横向扩展能力。GPU 资源配置、性能调优以及容错实现依然复杂且耗时。

当团队需要跨多个 GPU 集群、区域或云来运行和扩展推理时，通常会采用distributed inference平台来处理生产规模下的自动扩缩容、路由、可观测性与合规需求。这些平台开箱即提供高级能力，这意味着你的工程团队可以把重点放在产品创新上，而不是构建和维护基础设施。

常见问题

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

不一定。有些框架会优先支持特定架构。另一些框架则需要时间才能补齐多 GPU 支持、speculative decoding 和自定义 attention backend 等高级能力。在选择 runtime 之前，始终要先检查模型的特定兼容性。

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

有些模型太大，无法装入单张 GPU，因此你需要分布式推理。vLLM 和 SGLang 等框架提供了 prefill-decode disaggregation 或跨多个 worker 的 KV-aware routing 等高级优化。它们可以帮助你运行更大的模型、支持更长的上下文窗口，并在不触碰内存上限的前提下服务更多并发流量。

开始试验推理框架的最佳方式是什么？

一个较好的路径是从小规模起步，然后逐步升级。很多人从 Ollama 开始，因为它几乎不用配置就能在笔记本上运行。它很适合快速测试、prompt 调试，或先感受不同模型的行为差异。一旦你掌握了基础，并希望针对生产环境评估真实性能，就可以转向 vLLM、SGLang 或 MAX。这些框架面向生产级工作负载而设计，因此你可以在更贴近真实的环境中衡量延迟、吞吐量、批处理行为和 GPU 效率。

更多资源

• LLM performance benchmarks