LLM 推理部署完全指南（第一部分）

LLM 推理部署完全指南（第一部分） | 前端进阶之旅

Full translation

完整中文译文

你好，我是 Shrijith Venkatramana。我正在开发 git-lrc——一个会在每次 commit 时运行的 AI 代码审查工具。欢迎为我们点亮 Star，帮助更多开发者发现这个项目。也请亲自试用，并分享你的反馈，帮助我们改进产品。

训练模型和部署模型，是两个截然不同的问题。

完成一套 PyTorch 教程后，人们很容易认为最终生成的 .pt 文件就是最重要的产物。然而在生产环境中，挑战会从训练转向 serving：接收请求、加载模型、调度推理、管理 GPU，并以可预测的延迟返回响应。

随着 LLM 的规模不断增大，serving 基础设施本身已经成为一个重要的工程问题。John Hennessy 在 2023 年曾表示，运行一次 LLM 请求的成本可能约为传统关键词搜索的十倍，因此推理成本成为生产系统必须重点考虑的问题。

本文将介绍模型 serving 的基础知识：从一个已部署模型究竟由什么组成，到 vLLM 和 Triton 这类框架为何会出现。

1. 模型不只是一份权重文件

人们通常会把训练好的模型简单地理解为一大组学习得到的权重。

但在实践中，一个已部署的模型由三个不同的部分组成：

模型架构——定义神经网络结构的代码。

模型数据——学习得到的权重、偏置和配置。

执行代码——负责加载模型并执行推理的 runtime。

书中将模型描述为可执行程序，而不是被动的数据文件。仅有权重还不够——它们必须配合模型架构和执行 runtime，才能生成预测结果。

这种设计带来的一个实际结果是，许多项目会分别存储模型架构和权重。这样一来，在部署过程中就可以持续演进模型架构，同时部分加载仍然兼容的权重，而不必从头重新训练模型。

2. 训练与 Serving 的目标不同

训练和 serving 针对的是不同的工作负载，因此优化目标也不同。

训练期间，目标是通过反向传播更新模型参数。为了最大化吞吐量，通常会使用非常大的 batch，并在多块 GPU 上运行。

Serving 只执行前向传播。它关注的不是如何提高训练速度，而是：

可预测的运营成本

Serving stack 需要处理从寥寥几个到数百万个请求，同时保持一致的响应时间。在评估不同部署方案时，单次服务成本会成为最重要的指标之一。

3. 模型 Serving 实际是什么样的

生产环境中的模型 serving，远不只是暴露一个 generate() endpoint。

一个典型请求在抵达 GPU 之前，会流经多个组件：

Client
    ↓
API Gateway
    ↓
Load Balancer
    ↓
Inference Server
    ↓
Continuous Batch Scheduler
    ↓
GPU

传统 Web 基础设施负责身份验证、路由和负载均衡。ML 专用基础设施则负责 tokenization、调度、将多个请求合并成 batch、执行推理，并将响应以流式方式返回客户端。书中展示的架构明确地拆分了这些职责。

4. 容器化是基础

生产环境中的大多数推理任务都在容器内运行。

一个 serving 容器通常包括：

推理 backend

模型存储的访问能力

容器对外暴露 HTTP 或 gRPC 接口，同时在内部处理模型初始化、执行和资源管理。这样，同一套部署就能在开发、测试和生产环境中保持一致运行。

简化后的请求流程如下：

Request
    ↓
Serving API
    ↓
Inference Backend
    ↓
Model Runtime
    ↓
Prediction

5. 为什么需要专门的 Serving 框架

通用 ML 库主要面向实验和训练而设计。要高效地 serving 大语言模型，还需要额外的优化。

vLLM、TensorRT-LLM 和 SGLang 等框架，正是专门为推理工作负载构建的。

例如，一个典型的 vLLM 部署会暴露 GPU 显存利用率、最大并发序列数、张量并行规模以及最大 batch token 数等调优参数：

python -m vllm.entrypoints.openai.api_server \
  --model openai/gpt-oss-20b \
  --dtype bf16 \
  --gpu-memory-utilization 0.9 \
  --max-num-seqs 16 \
  --max-num-batched-tokens 16384 \
  --tensor-parallel-size 2

这些设置控制着请求如何被调度，以及如何分配到可用硬件上。

《Hands-On LLM Serving and Optimization》中复现的 benchmark 表明，在测试所采用的配置下，vLLM 的 serving 吞吐量显著高于标准的 Hugging Face serving。

6. Serving 多个模型

许多生产应用依赖的不是单个 LLM，而是多个模型。

一个典型应用可能会组合使用：

用于语义搜索的 embedding 模型

用于生成内容的语言模型

分别管理每个模型，很快就会让运维变得十分复杂。

NVIDIA Triton Inference Server 通过提供统一的 serving 平台来解决这个问题。它能够加载 PyTorch、ONNX、TensorRT 和 TensorFlow 等不同格式的多个模型，还可以通过统一 API 管理模型加载、缓存和路由。

7. 为什么 Serving 的经济性很重要

LLM 的 serving 成本并不只由 GPU 价格决定。

其中很大一部分问题在于利用率。

即便 GPU 长时间处于空闲状态，仍然会产生相同的基础设施成本。共享推理平台可以聚合众多客户的请求，使硬件保持较高的利用率，从而降低每个请求的平均成本。

这些笔记将最终形成的成本层级总结为：

通用推理服务提供商

企业自托管部署

GPU 容量利用得越充分，serving 每个 token 的成本通常就越低。

模型 serving 位于机器学习与分布式系统的交汇处。

模型本身只是生产部署中的一个组件。Serving stack 负责调度请求、管理硬件、暴露 API、处理故障，并控制推理成本。

理解这些组成部分，可以帮助我们更准确地评估 serving 框架和部署架构，以及延迟、吞吐量与运营成本之间的取舍。

你目前正在使用哪种 serving 框架或部署架构？是什么样的权衡促使你作出了这个选择？

*AI Agent 写代码很快，但它们也会悄无声息地删除逻辑、改变行为并引入 bug——却不会告诉你。你往往要到生产环境中才会发现问题。

git-lrc 可以解决这个问题。它会接入 git commit，在每个 diff 落地之前进行审查。60 秒即可完成设置，完全免费。*

欢迎提供任何反馈，也欢迎贡献者加入！它已在线开放、源代码可用，任何人都可以立即使用。

在 Git Commit 时运行的免费微型 AI 代码审查

🇩🇰 丹麦语	🇪🇸 西班牙语	🇮🇷 波斯语	🇫🇮 芬兰语	🇯🇵 日语	🇳🇴 挪威语	🇵🇹 葡萄牙语	🇷🇺 俄语	🇦🇱 阿尔巴尼亚语	🇨🇳 中文	🇮🇳 印地语

在 Commit 时运行的免费微型 AI 代码审查

如今的 GenAI 就像一辆没有刹车的赛车。它加速极快——你只需描述想要的东西，大段代码便会瞬间出现。但 AI Agent 也会悄无声息地破坏系统：删除逻辑、放宽约束、引入昂贵的云服务调用、泄露凭据，以及改变程序行为——却不会告诉你。你往往要到生产环境中才会发现问题。

git-lrc 就是你的制动系统。它会接入 git commit，在每个 diff 落地之前执行 AI 审查。60 秒即可完成设置，完全免费。

简而言之，git-lrc 可以在事故发生之前，帮助你防止服务中断、安全泄露和技术债。

概览：10 类风险 · 跟踪 100 多种故障模式 · 覆盖每一次 commit……

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。