跳到正文
Hacker News· d-ramdass·· 15 小时前AI 评分60

Modelplane 发布面向平台工程师的推理工程开放指南

An Open Field Guide to Inference Engineering

AI 导读

Modelplane 发布一份面向平台工程师的推理工程开放指南，讲解如何让模型与 GPU 配合并在生产环境运行推理。指南覆盖权重与 KV cache 的内存估算、prefill 与 decode 两阶段的不同瓶颈、TTFT 与 goodput 等指标，以及网关、超时、身份、可观测性和自动扩缩容等上线要点。

正文 · AI 翻译

译文尚不完整，完整内容请切换到原文。

注意

数字、价格和工具版本均为 2026 年 10 月的数据。

本指南面向刚接触推理的平台工程师。如果你需要了解模型和 GPU 如何协同工作，以及如何在生产环境中运行推理，本指南会有所帮助。你还会了解到可使用的工具，以及如何成长为一名推理工程师。

本指南建立在推理社区其他人的工作之上。如果你对推理工程感兴趣，可以通过以下内容继续学习：

1. 为什么是现在？

在 AI 优先的组织中，平台团队会变成推理团队。编码助手不能把源代码发送给第三方，而前沿模型的账单逐月上涨。支持工具也需要托管模型无法访问的内部数据。

组织希望自己运行这些模型，而开源模型如今让这变得可行。

Hugging Face托管着超过两百万个开源模型，其中最好的模型可以与闭源模型竞争。DeepSeek 于 2025 年 1 月发布了 R1，在 o1 发布约一个月后，它在数学和编码基准测试上就追平了 OpenAI 的 o1。当你运行自己的模型时，你可以控制延迟、正常运行时间以及数据的去向。在高负载下，你还可以将成本降低约 80%。

这项工作适合平台工程师。固定水平 AI 能力的价格大约每年下降 10 倍，而这主要来自模型的 serving 方式，而不是来自更好的 GPU。Crossplane 和 Modelplane 背后的公司 Upbound 亲眼见证了这一点。在其Project Champagne博客系列中，团队在Modelplane上运行自己的模型，发现 vLLM 和调度都能正常工作。时间花在了 TLS、身份、超时、存储、IAM 和可观测性上。

可迁移的技能

推理工程师要选择模型、把它部署到合适的 GPU 上、保持其服务运行、让它更快更便宜，并在出故障时被呼叫。这就是针对新工作负载的 SRE，你的大部分技能都可以迁移过来：

你已掌握的在推理中变成
调度和节点池使用设备选择器、污点和独占设备进行 GPU 放置
容量规划GPU 内存计算：权重、KV 缓存和运行时开销，并在运行时校验
负载均衡缓存感知路由和长连接流式传输
基于 CPU 的自动扩缩容基于队列深度和 KV 缓存使用率进行扩缩容，冷启动以分钟计
发布独占 GPU 的发布，以及模型、硬件和引擎构建的版本矩阵
SLO 和延迟百分位数首 token 时间、每输出 token 时间和有效吞吐
可观测性引擎指标、真实 GPU 活动和投机解码接受率
FinOps每百万 token 成本和每用户会话成本
身份和访问与 agent 会话生命周期相同的凭证

托管 API 在产品早期仍然是正确的选择。当 API 支出成为一项实实在在的开销、当延迟或可靠性需求超出供应商能力、或者当数据无法离开你的网络时，自托管才划算。2026 年 8 月，Chris Zeoli 统计了公共招聘板上约 58 个开放推理岗位，且职位名称尚未统一。

2. 推理入门

本节大致按照你会遇到这些概念的先后顺序进行介绍。大多数概念涉及引擎在 GPU 内存中保留了什么，或者是什么限制了它的速度。

Viktor Farcic 建议问一问每个概念从什么时候开始变得重要。有些在你部署时就很重要，另一些只有在很多人使用模型后才重要，还有一些你可能永远用不到。本节末尾的表格给出了每个概念的信号。

什么是推理引擎

推理引擎，比如 vLLM 或 SGLang，是把模型权重变成 API 的服务器。对平台工程师来说，最接近的心智模型是一台带 GPU 的有状态数据库服务器。它在启动时把大型数据集加载到内存中，并保留每个会话的状态。它还在内部调度工作，并通过 HTTP 应答。Ollama 在笔记本电脑上就是同一思路的小规模版本，而每个托管模型 API 背后都运行着一个推理引擎。

你从数据库和服务中已经了解这一点引擎的对应物
启动时把数据集加载到缓冲池把模型权重加载到 GPU 内存，这可能要花很多分钟
会话存储中的每会话状态KV 缓存，每个进行中的对话一份
查询规划器和连接池调度器，把请求批处理进每次 GPU 执行
客户端已经会说的线路协议兼容 OpenAI 或 Anthropic 的 HTTP API
重启后预热缓存冷启动：拉取大型镜像并重新加载权重

与数据库不同，引擎把工作集放在 GPU 内存中，而不是 RAM 中。GPU 内存又小又贵，所以大多数调优都是在决定每个请求能分到多少内存。

推理栈

引擎是四层中的一层。最底层，内核负责算术运算。你很少直接选择它们。它们之上是引擎。再之上是控制平面，负责部署和管理引擎，因为你迟早会运行不止一个引擎。最顶层是网关，在模型和副本之间路由流量。

Inference stack: four layers and the clients they serve

推理栈：四层及其服务的客户端

请求经过网关到达引擎，引擎在 GPU 上运行内核。控制平面部署和管理网关与引擎，但没有任何请求经过它。

Token

Token 是语言模型工作的单位，大致是一个词或词片段。上下文窗口、价格和速度都以 token 计数。当有人说每秒多少 token 时，他们指的就是这个单位。

权重与 KV 缓存

权重是固定的，而 KV 缓存随负载增长。两者都要规划容量，就像你规划数据库的占用空间和工作集一样。

权重是固定的占用空间。大多数模型以每个参数 2 字节（BF16 或 FP16）发布，所以一个 8B 模型需要约 16 GB，而且它必须放在 GPU 内存中，而不是系统 RAM 中。在 48 GB 的 L40S 上，这为其他所有内容留下了约三分之二的显卡空间。无论是一个用户还是一百个用户，这个数字都一样。

KV 缓存就是工作集。每个新 token 都要与它之前的每个 token 进行计算。引擎不会重新计算这段历史，而是保留每个在途 token 的注意力键和值。其大小随上下文长度乘以并发会话数而增长，很像一个随会话大小和用户数量同时增长的会话存储。

你可以根据模型的配置估算每个 token 的 KV 缓存：

KV bytes per token = 2 × layers × KV heads × head dimension × bytes per value

对于 FP16 的 Llama 3 70B（80 层、8 个 KV 头、头维度 128），每个 token 约为 320 KB。一次 128K token 的对话需要约 40 GB 缓存。在这种规模下，KV 缓存通常决定了单块 GPU 能服务多少用户。

注意以下容量规划错误：

  • 混合专家（MoE）模型会常驻保留全部权重。一个总参数 320B、激活参数 18B 的模型在 FP8 下仍需要约 320 GB。只有计算量随激活参数缩放。

  • 看检查点大小，而不是 dtype 表。Upbound 在为 Project Champagne 自托管自家模型时，根据 dtype 估算某个 MoE 模型约为 315 GB（第 2 部分）。实际检查点为 177.7 GB，因为专家以 4 位格式存储。

  • 为运行时开销留出空间。CUDA 图、激活值和内存碎片都会占用空间。启动时能放下的模型，几天后仍可能内存耗尽（Project Champagne，第 2 部分 ）。

两个阶段，两个瓶颈

每个请求在同一块 GPU 上分两个阶段运行，而它们受不同因素限制 。

阶段它做什么受限于它决定的指标
预填充并行读取整个输入，包括系统提示和工具定义以及对话历史。生成第一个 token 和 KV 缓存。计算首 token 时间（TTFT）
解码一次一个 token 地写出答案。每个 token 都需要一次从内存读取所有激活权重以及 KV 缓存的遍历。在长上下文下，读取缓存的成本可能高于读取权重。内存带宽每个输出 token 的时间与每秒 token 数

生成一个 token 时，每从内存读取一字节，就执行一到两次浮点运算，具体取决于权重精度。H100 需要每字节约 295 次运算才能保持忙碌。这意味着单个请求只用到芯片的一小部分，而计算单元在等待内存（Data Gravity ）。

峰值算力大约每两年增长 3 倍，而内存带宽约增长 1.6 倍。几乎每一项优化要么减少每个 token 的字节移动量，要么让每个字节分摊到更多 token 上。

由于两个阶段的瓶颈相反，加速其中一个阶段的技术往往对另一个阶段帮助不大。这就是基准测试分别报告 TTFT 和每秒 token 数的原因。

需要跟踪的指标

指标它衡量什么注意事项
首 token 时间（TTFT）排队加预填充：用户在出现任何内容前等待多久对于推理模型，引擎的第一个 token 可能是隐藏的思考内容。要测量用户看到的第一个 token。
每个输出 token 的时间，或 token 间延迟每个流的解码速度投机解码和内存带宽会体现在这里
每用户每秒 token 数交互性，即模型的打字速度随批大小增加而下降
吞吐量所有用户合计的每秒 token 数随批大小增加而上升
有效吞吐量仍能满足延迟目标的吞吐量用于规划容量时采用的数字
端到端延迟总请求时间取决于模型写多少内容。对于长生成来说，190 秒的健康回答是正常的。
百分位数每个延迟的 p50、p90、p99用户感受到的是尾部，而不是平均值
错误与拒绝失败或被拒绝的请求将拒绝计为错误，否则上下文上限可能看起来像是提速
每百万 token 成本GPU 成本除以所服务的 token 数在你实际运行的负载下进行比较

每百万 token 成本将 GPU 价格和吞吐量转换为一个可比较的数字：

Cost per million tokens = GPU cost per hour / (tokens per second × 3600) × 1,000,000

Spheron 的示例：一块每小时 2.90 美元的 GPU 维持每秒 1,200 个 token，成本约为每百万 token 0.67 美元。

延迟与吞吐量

将更多请求批处理在一起会提高总吞吐量，并减慢每个单独用户。交互式聊天和编码更看重延迟。隔夜批处理任务更看重吞吐量。

这与为事务处理或分析调优数据库是同样的权衡。在调优任何东西之前，先写下工作负载的约束条件。

何时采用每个概念

每一行给出了告诉你该采取行动的征兆，大致按团队需要的顺序排列。

概念它做什么你需要它的信号
适配权重选择模型、精度和 GPU，使权重适配且留有余量引擎无法启动，或启动后几乎没有剩余的 KV 缓存
连续批处理和分页 KV 缓存在请求之间共享每次 GPU 传递，并以小块分配缓存在 vLLM 和 SGLang 中已默认开启。检查它，不要自己构建。
量化以更少的位存储权重，并将释放的内存给 KV 缓存请求排队，而 GPU 仍有空闲算力
前缀缓存复用对重复提示开头的已完成工作在 vLLM 和 SGLang 中已默认开启。当你的客户端是代理或重发长历史的聊天应用时，关注命中率
推测解码起草多个 token 并在一次传递中验证它们即使在低负载下，单个响应流式传输也太慢
网关和控制平面在副本之间路由，并以声明式方式管理引擎你添加第二个模型、第二个副本或第二个集群
跨 GPU 分片使用张量、流水线或专家并行拆分一个模型模型无法放在一块 GPU 上。在部署前规划好这一点。
自动扩缩容根据队列深度和 KV 缓存使用情况添加和移除副本空闲 GPU 出现在账单上，或在高峰时段队列堆积
分离在单独的 GPU 上运行预填充和解码长提示在大规模下阻碍流式传输，并且你拥有 RDMA 级网络

大多数团队第一天只需要前几行。当他们的信号出现时再添加其余部分。

代理改变了什么

编码代理和其他代理工作负载对这幅图的每个部分都构成压力。Upbound 在其 Project Champagne 系列（在第 1 节中介绍）的第 5 部分中测量了这一点，其中约 10 名工程师针对自托管模型运行 Claude Code 和其他编码代理。他们的流量看起来像这样：

  • 提示很长。提示的中位数为 59K token，p90 为 125K。

  • 提示大部分是重复的。约三分之二的提示 token 命中前缀缓存，因为代理在每一轮都会重发其记录。

  • 思考是隐藏的。推理模型在第一个可见 token 之前可以思考超过一分钟。代理和模型之间的每个超时都必须考虑到这一点。

  • 负载取决于客户端。短提示会话启动子代理，并且可以比长提示会话保持更多在途请求。以在途请求而非席位来规划容量。

  • 会话会持续数小时。流式输出、工具调用和凭据都必须在这段时间内保持正常工作。

3. 在生产环境中运行推理

在生产环境中，每个选择都要在延迟、吞吐量、成本和质量之间相互权衡，而且通常 GPU 数量不足。某项实践若源自 Project Champagne，第 5 节有详细说明。

3.1 从用例出发，而不是从硬件出发

每个用例都有不同的要求。在 Project Champagne 中：

  • 编码智能体需要长上下文且不损失质量、可靠的工具调用解析、流式输出、持续数小时的会话，以及供 Claude Code 使用的 Anthropic 兼容 API。

  • 聊天需要低首 token 时间、真正的并发能力，以及供现有工具使用的 OpenAI 兼容 API。

  • 平台需要在真实主机名上启用 TLS，并将身份与公司域名绑定。它还需要可观测性，以区分引擎是健康还是繁忙，以及无需人工照看即可正确放置。

将交互式工作负载与批处理工作负载分开。它们需要不同的目标，而且往往需要不同的部署。在测试任何东西之前，先把通过和失败的标准写下来。

3.2 有意识地选择模型

  • 在你自己的任务上评估。公开基准测试衡量的是别人的工作负载。第 3.11 节介绍了具体做法。

  • 从小开始，再逐步扩大。一个活跃参数只有几十亿的小型 MoE 模型能更快积累运维经验，试错成本也更低。

  • 最新的模型不一定就是合适的。模型发布的速度快于硬件规划。一个新的“小型”旗舰模型可能需要好几张最大的卡，而你当前的模型可能只运行在其支持上下文的一半。最便宜的收益可能根本不需要新模型。

  • 检查你的引擎是否真的能加载它。发布说明中列为支持的模型，在你的硬件和引擎构建上仍可能加载失败。

  • 检查许可证。大多数开放模型使用宽松许可证，但有些限制商业使用。

  • 检查聊天模板和解析器。工具调用和推理输出取决于每个模型在引擎中所需的设置。设置错误会破坏工具使用，而每个请求仍然返回 200。

3.3 按运行时而非启动时来规划容量

一个在启动时能放下的模型，在真实流量下仍可能因碎片化超出分析峰值而耗尽内存。这可能发生在几天之后，而且是在请求处理过程中。

  • 为全部三项成本做预算：权重、KV 缓存，以及 CUDA 图和激活值等运行时开销。

  • 了解你的引擎内存设置覆盖了哪些内容，并在每次升级时重新检查。vLLM 根据启动时对其他所有内容的估算来确定其 KV 缓存大小，包括 CUDA 图池，而真实流量可能超出该估算。如果在负载下出现内存不足错误，稍微降低内存比例，启用可扩展段并限制并发序列数，然后再次测量空闲内存。

  • 限制每个请求。在每次调用上设置最大输出长度。否则，任何请求都可能让模型对所有人不可用，而且被放弃的请求在客户端放弃后仍会继续生成。

  • 谨慎缩短上下文。更短的最大上下文能为更多用户释放 KV 缓存。但它也会拒绝所有更长的对话，因此要把这些拒绝计为错误。

3.4 了解优化技术

大多数引擎默认开启连续批处理和分页 KV 缓存。其余则是你针对每个模型和工作负载所做的选择。

技术它改善了什么成本或风险何时使用
连续批处理吞吐量。Orca 报告称，在相同延迟下比静态基线快 36.9 倍。随着批次增大，单用户速度下降始终使用。它是现代引擎中的默认设置。
分页 KV 缓存（PagedAttention）并发能力。vLLM 将 KV 缓存浪费从 60% 到 80% 降至 4% 以下。实践中影响很小始终使用。它是 vLLM 中的默认设置。
前缀缓存重复打开时的 TTFT 和预填充成本仅在直到第一个不同 token 之前有效系统提示、RAG、多轮聊天和智能体
权重量化解码始终受益，而预填充仅在激活值也被量化时才受益，例如使用 FP8。AWQ 和 GPTQ 等仅权重量化格式只能加速解码。精度降低一档通常快 30% 到 50%（Inference Engineering）。质量损失，必须进行测量使用你的硬件原生支持且你的评估可接受的最低精度。FP8 在 Ada、Hopper 和 Blackwell GPU 上原生运行。
KV 缓存量化可容纳更多缓存，且运行更快误差会逐 token 累积当 KV 缓存成为瓶颈时
推测解码、多 token 预测低批次大小下的每秒 token 数猜测被拒绝时浪费计算。随着负载上升、空闲算力耗尽，其价值会缩小。延迟重要且输出可预测
张量并行容纳大模型，提升单用户速度需要 NVLink 等快速 GPU 间链路单节点内的大模型
专家并行MoE 模型的吞吐量专家之间的路由MoE 模型，包括跨节点
流水线并行通过普通网络跨节点容纳模型为每次传递增加延迟模型无法放入单个节点
预填充与解码分离消除阶段间的干扰。DistServe 报告称在延迟限制内请求数提升 7.4 倍。需要 RDMA 级网络来传输 KV 缓存大规模、长提示、快速互连

几条经验法则：

  • 为缓存组织提示结构。 前缀缓存在第一个不同的 token 处停止。将系统提示和工具定义等共享内容放在最前面，将可变的用户输入放在最后。托管 API 对缓存输入按新输入价格的 10% 到 50% 收费（截至 2026 年），原因相同）。

  • 从最不敏感的部分开始量化。 线性权重对量化的容忍度最高，其次是激活值，最后是 KV 缓存。注意力层最敏感，因为小误差会在长序列中累积。将最敏感的部分保持较高精度，直到你的评估表明可以进一步降低。FP8 等浮点格式比整数格式更能处理异常值。

  • 关注推测解码的接受率。 接受率取决于温度、主题和草稿模型。如果接受率骤降，每次传递仍要为猜测付出代价，模型会变慢，而其他面板看起来正常。

  • 应用多种技术时注意相互作用。 量化 KV 缓存有助于分离。更大的批次留给推测的空闲算力更少。一位 Baseten 工程师尝试了 77 种配置，才找到一种能为客户将吞吐量翻倍的配置（Inference Engineering）。一次只改一项并测量（第 3.10 节）。

  • 避免长提示词阻塞其他流。分块预填充（chunked prefill）将长提示词拆分到多次处理中，从而让其他请求的解码持续进行。当前 vLLM 默认开启该功能，每次处理的 token 预算是在考虑分离部署（disaggregation）之前需要调整的设置。

3.5 获取 GPU，并正确放置它们

  • 配额并不保证容量。配额只允许你请求实例。每种实例规格都有独立的容量池，即使使用相同的 GPU 也是如此，而且没有任何云 API 会告诉你实际能启动什么。

  • 针对你能拿到的 GPU 进行设计。不要指望总能拿到计划中的 GPU。模型可能最终被拆分到不同区域中较小的节点上，通过普通网络使用流水线并行。允许使用多区域池，并让模型定义与实例类型和节点数量保持独立。

  • 将模型与硬件显式匹配。Kubernetes 动态资源分配（DRA）设备选择器可以将模型固定到特定 GPU 架构或最低内存大小。请根据 GPU 驱动发布的信息验证放置结果，而不是依据回显你所声明内容的 status 字段。

  • 关注云平台，而不只是控制器。托管节点组可能报告失败，而云平台仍在尝试启动实例；数小时后才到达的 GPU 可能因之后对池的更改而被关闭。跟踪实例和节点加入情况，并在更改池之前列出池中的实例。

  • 了解你的互连。SXM 数据中心 GPU（如 H100、H200 和 B200）通过 NVLink 连接 GPU。L40S 和 RTX PRO 6000 等 PCIe 卡则不具备此能力，因此多 GPU 通信需经由 PCIe 和主机内存。这会改变哪些并行策略更有效。

  • 系统池也要规划容量。GPU 节点被标记为仅用于推理。监控、控制器和网关会争抢剩余的一般容量。

3.6 网关、路由与超时

  • 不要使用轮询。一个副本可能已缓存某段对话的前缀，而另一个副本从未见过它。请使用缓存感知或前缀感知的路由，例如 Gateway API Inference Extension 中的端点选择器。

  • 按模型名称路由。一个主机名可以服务多个模型，根据请求的 model 字段进行路由。

  • 同时支持两种常见 API。大多数工具期望 OpenAI API。Claude Code 期望 Anthropic Messages API，vLLM 原生提供该 API，包括流式传输和工具调用。

  • 提高链路上的所有超时设置。长生成和推理模型会突破默认值，因为每一跳的默认超时都是按 Web 请求设定的，而不是按持续数分钟的生成设定的。常见问题包括：限制整个响应的网关路由超时、负载均衡器空闲超时，以及会成倍增加等待时间的重试。请检查路由、每个负载均衡器、网关、客户端以及客户端发起的任何辅助调用。

  • 检测被截断的流。被切断的流可能返回 HTTP 200 和有效 token，然后停止。对客户端来说，这看起来像是一个已完成的答案。

  • 按调用方计量用量。在网关处实施基于 token 的速率限制和配额，可防止单个重度用户或失控的 agent 耗尽其他所有人的资源。

3.7 安全与身份

  • 切勿暴露开放端点。在网关获得地址之前应用你的认证策略，并在拆除时最后移除。

  • 在真实主机名上使用真正的 TLS，并制定证书签发和续期的方案。

  • 为三类客户端做好规划。人是最简单的情况。浏览器无法在页面加载或预检请求中附带 bearer token，因此要在网关处用 OIDC 处理浏览器登录。Agent 会运行数小时，并且只读取一次凭据，所以 60 分钟的身份令牌会让它们在会话中途失效。给 Agent 提供长期有效的 API key，或可自动刷新的凭据。

  • 不要叠加两个会过期的会话。在自带登录的应用前面再加一层网关登录，当外层会话过期时就会导致服务中断。

  • 测试哪些请求应当被拒绝。构建一个探测矩阵，覆盖网关必须拒绝的请求，例如缺失、乱码、未签名、已过期或已吊销的 key，或伪造的调用方请求头。同时包含必须保持可达的路径，例如健康检查。按计划运行，并在变更期间循环运行。

  • 将身份信息带入用量记录，这样你就能看到谁发送了什么。覆盖客户端试图伪造的任何调用方请求头。

  • 像对待代码一样对待模型权重。优先使用 safetensors 而非基于 pickle 的检查点，不要启用来自你未读过的模型仓库的远程代码，并将每个模型固定到特定修订版本。

3.8 可观测性

  • 抓取引擎指标。引擎会暴露详细的 Prometheus 指标。除非设置了抓取机制（例如 ServiceMonitor 和命名端口），否则没有任何组件会收集它们。

  • 构建核心面板：受并发上限约束的运行中请求数、等待中的请求数、KV 缓存使用率、TTFT、每个输出 token 的耗时、每个请求的输出 token 数、前缀缓存命中率、投机解码接受率、按状态码分类的错误，以及取消数。

  • 在服务端衡量质量。损坏的工具调用、被截断的回答和空响应通常以用户投诉的形式到达你这里，而服务仪表盘看起来一切正常。改为在服务端统计它们，包括解析失败的工具调用、因长度限制被截断的响应、空输出、拒答，以及每个请求的隐藏推理 token 数。网关能看到每一个响应，因此可以统计引擎未导出的任何内容。

  • 不要只看 GPU-Util。它报告的是是否有任务在运行，而不是芯片有多少部分在工作。GPU 可能报告接近 100% 的 GPU-Util，而 SM 活动只有大约一半，张量核心大部分处于空闲状态。同时绘制 SM 活动和张量活动。

  • 区分不同类型的慢。当请求排队时，运行数处于上限、等待数大于零且 KV 缓存已满。当模型在思考时，TTFT 看起来正常，但每个请求会写入大量隐藏 token。当生成缓慢时，每个输出 token 的耗时上升。

  • 监控监控者。监控栈之外的某个组件必须检查数据是否新鲜，以及新指标是否从每个集群到达。指标适配器可能报告其 API 可用，却返回空结果。

  • 保留可用于调试的日志。指标抓取可能占据保留的引擎日志的几乎全部内容。保留带调用方信息的每请求访问日志，将其发送到日志存储，并记住崩溃后的 kubectl logs --previous。

  • 跨引擎统一指标名称，这样 vLLM 部署和 SGLang 部署就能基于相同的信号来评判。

基于用户实际感受设置 SLO，在前门按请求测量：

  • 响应迅速：用户实际看到第一个 token 的时间低于阈值。

  • 足够快：每个输出 token 的时间低于阈值。

  • 已应答：请求完成且没有错误，其中的任何工具调用都 解析成功。

不要对总请求时间设置 SLO，因为它取决于模型写了多少内容。低流量模型需要全集群范围的 SLO、更长的窗口或 合成流量。数据缺失会被读作 100% 良好，因此要为停止上报的 指标单独设置告警。开源工具如 Sloth 和 Pyrra 可将 SLO 定义转换为燃烧率 告警。背景知识参见 Observability Engineering 。

3.9 自动扩缩容与冷启动

  • 基于推理信号扩缩容，例如队列深度、KV 缓存使用量和在途 请求数。CPU 使用率在这里几乎说明不了什么。

  • 结合流量与负载。流量让你能提前于需求扩缩容，而负载 滞后于需求。这些设置就是你在任何自动扩缩器上已经调过的那些。 设置最小和最大副本数以及指标窗口长度。然后 设置缩容延迟以及每个副本应承载的并发请求数。Kiely 的书 针对推理场景 深入讲解了每一项。

  • 为缓慢的冷启动做好规划。新的 GPU 节点必须启动、拉取大型引擎 镜像并加载权重。仅加载权重，对于大型模型就可能需要半小时。 在每个集群的共享存储上缓存权重，这样新副本 就不必再次下载。

  • 谨慎使用缩容到零。等到节点就绪时，流量尖峰可能 已经过去，而稀缺的 GPU 容量可能无法恢复。

  • 为大规模多集群做好规划。超过几百块 GPU 后，容量 会推动工作负载跨区域和跨供应商迁移。一个将 独立资源池视为一个整体的控制平面，可以避免一个资源池容量闲置而另一个 容量不足。

3.10 变更管理

  • 跟踪三方版本矩阵：模型、硬件和引擎构建。新 模型在第一天往往需要 nightly 构建或针对模型定制的引擎构建。

  • 为独占 GPU 规划发布。GPU 占用是独占的，因此在单副本部署上做滚动 更新会死锁：新 Pod 无法调度， 旧 Pod 永远不会退出。使用 Recreate 策略或允许一个不可用， 并为停机预留时间。

  • 就绪并不意味着可路由。网关可能比就绪副本滞后一两 分钟。

  • 像对待代码一样测试服务变更。让每项变更都成为一个 pull request，并一次只改 一件事。先写下达标标准。逐步提高负载，直到某一步 未达标，并以一个数字加置信区间来报告容量。

  • 先测试测试装置。测试装置的 bug 可能浪费一个稀缺的 GPU 窗口，而 在笔记本上花几分钟本可以提前发现。

  • 在自己的硬件上、用类似自己的流量进行测试。Agent 提示词很长 且大部分被缓存。对简短、全新提示词做基准测试，测量的是另一个 系统。

让每项服务变更逐级通过各层级。每一层都比前一层成本更高，并能捕获不同类型 的故障，因此大多数问题会在用户看到之前暴露：

  • 离线。验证配置并运行测试装置自身的检查。这只需 在笔记本上花几分钟，且不需要 GPU。

  • 演练。针对假网关或小模型端到端运行完整测试， 这样测试装置的 bug 就不会浪费 GPU 窗口。

  • 冒烟测试。 在目标硬件上发送几个真实请求。包括一个长提示词、一次工具调用和一个流式回答，外加一个应当被拒绝的请求。

  • 带评测的负载测试。 在评测套件同时运行的情况下，将并发数逐步提升到你的标准，并与同一流量下的当前版本进行对比。评测可能一次一个请求都能通过，而工具调用在并发负载下却会崩溃，同时服务仪表盘上毫无变化。

  • 金丝雀发布。 将一小部分真实流量发送到新版本，并将其服务端信号与当前版本进行对比：TTFT、每个输出 token 的时间、错误、工具调用解析失败和长度限制停止。按模型名称路由的网关可以按权重拆分流量。在开始之前写下回滚触发条件。

  • 全量发布。 保持旧版本随时可以接管流量，直到新版本的信号在流量高峰期间始终保持在标准之内。

3.11 质量与评测

当一个开源模型得分较低时，在归咎于模型之前先检查三个地方：

  1. 测试框架。 模型是唯一发生变化的东西吗？先运行你当前的托管模型。如果它的得分低于一个更弱的模型，那么测试框架就是有问题的。

  2. 基础设施。 模型有机会回答吗？超时、过期凭证和路由错误会表现为模型失败。将这些运行标记为“未测量”。

  3. 评分器。 检查是否衡量了你所关心的结果？对最终状态评分，而不是对智能体对它的描述评分，并用人们已经接受或拒绝的答案来测试你的评分器。

还要固定正确答案所依赖的数据，并给每个模型相同的上下文。将测试标记放在模型无法读取的位置。每个测试运行不止一次，并优先使用确定性检查，而不是用模型作为评判者。批处理服务器即使在温度 0 下也可能对同一请求返回不同的 token，因此除非引擎以较慢的批处理不变模式运行，否则要预期存在一些方差。

3.12 事故与调试

  • 预期静默失败。 代价高昂的问题往往不会抛出错误：被截断的流返回 200，指标 API 报告可用，节点组报告就绪。平台的部分工作就是让这些失败变得显眼。

  • 查看持续时间。 在整数秒处失败就是超时。它的倍数，例如四次 60 秒尝试后的 239 秒，指向重试。

  • 绕过一层。 从路径中去掉一跳，看看问题是否转移。

  • 对照现实验证状态。 状态是一个组件对自身工作的看法。检查磁盘、实例或路由本身。

  • 以增量的方式工作，并将修复上游化。 将变通方案放在平台旁边，并标记为待拆除，而不是编辑控制器拥有的对象。

首批用户之前的检查清单

  • 用例已定义，并写明了首 token 时间、每用户速度和错误率的标准

  • 基于你自己的评测选择模型，并以你当前的托管模型作为基线

  • 确认引擎构建能在你的硬件上加载模型

  • 内存预算涵盖权重、KV 缓存和运行时开销，并设置了最大输出 token 数和最大并发序列数

  • 已对照驱动验证 GPU 放置，并有备用的实例规格或区域

  • 在网关获得地址之前应用认证策略，并在真实主机名上启用 TLS

  • 凭证的有效期与智能体会话一样长

  • 每一跳都提高了超时：路由、负载均衡器、网关重试、客户端和辅助调用

  • 抓取引擎指标，绘制 GPU SM 和 tensor 活动图表，并在指标停止到达时发出告警

  • 服务端统计工具调用解析失败、长度限制停止和空响应，这样用户不会成为你的第一个告警

  • 一个探测矩阵，包含必须被拒绝的请求和必须保持开放的路径

  • 独占 GPU 的发布策略，并预留停机时间预算

  • 崩溃后保留之前的容器日志

  • 服务变更按层级推进，在并发负载下进行评估，并带有书面回滚触发条件的金丝雀发布

  • 变通方案保留在平台旁边，标注待拆除，并将修复提交上游

4. 技术栈

深入引擎。你已经了解 Kubernetes、网关和可观测性，所以要学习推理场景下有哪些变化。对于内核，读一份 profile 就够了。大多数推理工程发生在技术栈的更高层。

按层划分的工具

层需要了解的工具优先掌握
Kubernetes 上的 GPUNVIDIA GPU Operator 、Dynamic Resource Allocation 及其 NVIDIA driver 、DCGM exporterGPU 如何被声明、请求和放置
内核与库CUDA 、PyTorch 、Triton 、FlashAttention 、torch.compile内核基础、内核融合，以及如何阅读 profile
推理引擎vLLM 、SGLang 、TensorRT-LLM ；本地工作用 Ollama 和 llama.cppvLLM 的核心标志：--gpu-memory-utilization、--max-num-seqs、--max-model-len、张量并行大小、量化、前缀缓存、分块预填充
分布式服务NVIDIA Dynamo 、llm-d 、KServe 、LeaderWorkerSet多 GPU 和多节点布局，以及预填充和解码分离
网关与路由Envoy Gateway 、Agent Router （原 Envoy AI Gateway）、Gateway API Inference Extension流式传输、超时、认证策略、模型名称和缓存感知路由
控制平面Modelplane ，构建于 Crossplane跨环境声明集群、硬件类别、部署和缓存
可观测性Prometheus 、Grafana 、OpenTelemetry 、Loki 、Sloth 或 Pyrra引擎指标、真实 GPU 活动，以及面向用户延迟的 SLO
基准测试vLLM 的基准测试工具 、NVIDIA AIPerf 、GuideLLM 、SemiAnalysis AgentX 追踪在真实提示下的并发扫描和延迟百分位数
评估英国 AI 安全研究所的 Inspect ；Hugging Face upskill 用于跨模型测试技能对任务最终状态的确定性评分器
模型Hugging Face Hub 、safetensors 检查点阅读模型配置中的层数、头数和上下文，并检查实际文件大小

选择引擎

引擎控制批处理、内存管理、内核选择和 API 兼容性。它对成本和吞吐量的影响往往比硬件升级更大。

引擎团队选择它的原因运维成本
vLLM最广泛的模型覆盖，开箱即用的 OpenAI 和 Anthropic API，因此通常是首次部署的选择。由 PyTorch 基金会托管。频繁发布新标志。固定版本并在每次升级时重新基准测试。
SGLang一个基数树前缀缓存和一个调度器，优先处理共享缓存前缀的请求，这适合智能体和长多轮会话。Upbound 在此处测得了最大的单项收益（Project Champagne，第 5 部分，2026 年）。社区规模较小，新模型可能需要 nightly 构建才能在正式发布版中正常工作。
TensorRT-LLM针对 NVIDIA 硬件调优的内核，包括 Blackwell 上的 FP4仅限 NVIDIA 硬件，这会将你的服务栈绑定到单一供应商。
NVIDIA Dynamo位于引擎之上的一层，用于协调多个节点，包括分离式预填充和解码又是一个需要运行的分布式系统，因此仅在多节点规模下使用。
Ollama , llama.cpp用于学习和原型设计的本地服务并非为大量并发用户设计

Hugging Face 的 TGI 曾是常见选择，现已进入维护模式，因此在确定采用前请检查发布节奏、维护者和基金会支持。引擎每隔几周就会添加新标志。升级时请重新运行基准测试，而不是相信上一季度的数字。

Upbound 在 Project Champagne，第 5 部分 中的自身对比显示了这一点。该团队在两个 8-GPU 节点上为约 10 名工程师提供编码模型服务，并测试了如何扩展到 15 人的团队。在相同硬件和相同智能体流量下，从 vLLM 切换到 SGLang 是其测得的最大单项收益。在此基础上添加 SGLang 的主机内存缓存并未带来可测量的收益，因为 KV 缓存从未填满。

Modelplane 的定位

Modelplane 是 Upbound 的一个开源项目，构建于 Crossplane 之上，以 Apache 2.0 许可证发布。它通过 Kubernetes 风格的声明式 API，跨云、新云和你自己的 GPU 编排模型、推理引擎和 AI 基础设施。它可配置推理集群，或使用你自带的集群。文档位于 docs.modelplane.ai 。

Modelplane 将工作划分为三层归属。即使使用不同的工具，你也可以将同样的划分作为心智模型。

谁拥有Modelplane 资源
平台团队集群、硬件类别和网关InferenceCluster、InferenceClass、InferenceGateway
模型运维人员或推理工程师模型：部署、服务和权重缓存ModelDeployment、ModelService、ModelCache
Modelplane介于两者之间的一切，由上述两者组合而成ModelEndpoint、ModelReplica

该层级结构将核心 Kubernetes 向上提升了一个作用域。ModelDeployment → ModelReplica → ModelService → ModelEndpoint 与 Deployment → Pod → Service → Endpoint 平行，跨越整个集群而非单个集群内部。你提供引擎容器及其标志，Modelplane 围绕它们塑造拓扑。人员和智能体从不创建这些资源。它们按模型名称调用 InferenceGateway。

Modelplane 开箱即用地将 vLLM 和 SGLang 指标映射到通用名称，而 MetricMapping 可添加任何其他引擎，因此不同引擎基于相同信号进行评判。

对于平台工程师来说，第二层是学习新知识的地方。Upbound 在 Project Champagne，第 1 部分 开始自托管时也发现了同样的情况： 集群和网关工作是熟悉的，而模型运维层则包含未知数。

学习该技术栈的建议顺序

  1. 在单个 GPU 上运行 vLLM，通过其 OpenAI 兼容 API 访问，并读取其指标端点。

  2. 使用 NVIDIA GPU Operator 将其部署到 Kubernetes 上，并通过设备选择器进行放置。

  3. 在它前面放一个网关，配置 TLS、认证和针对长流调整的超时。

  4. 将引擎和 GPU 指标抓取到 Prometheus，并依据第 3.8 节构建核心面板。

  5. 用并发扫描对它做基准测试，同时运行一套小型评测套件。

  6. 在 SGLang 上服务同一个模型，并基于你自己的流量做对比。

  7. 用张量并行和流水线并行把更大的模型拆分到多块 GPU 上，然后尝试分布式服务层。

  8. 学习足够的 CUDA 和性能剖析知识，以理解为什么某个内核或某项设置带来了差异。

关于运行推理，你需要了解的很多内容都来自那些把故障写下来的团队。学会批判性地阅读这些记录，并写下你自己的（第 6 节）。

如何阅读案例研究

  • 找到配置。模型、硬件、引擎版本和流量形态。注意日期，因为数字很快就会过时。

  • 找到标准。什么算足够好，以及由谁决定。

  • 追踪故障。什么坏了，团队如何发现，以及检测花了多长时间。

  • 检查方法。他们是否一次只改一件事，并在自己的流量上测量？

  • 区分可迁移的部分。超时教训到处适用，但某个具体标志值只对那台硬件上的那个引擎版本成立。

案例研究：Project Champagne（2026）

Crossplane 和 Modelplane 背后的公司 Upbound，用 Modelplane 在开放模型上自托管聊天、编码智能体和修复 CVE 的构建智能体，跨 AWS 和 Nebius GPU。团队用五部分系列发布了故障记录。以下为亮点，数字截至 2026 年：

  • 服务是较小的问题。vLLM 和调度都正常。TLS、身份、超时、存储和可观测性占用了时间。（第 2 部分）
  • 配额不等于容量。768 个 vCPU 的 H100 实例配额获批后从未产出过一台，计划中的 GPU 大约只有一半时间能到位。一个模型最终被拆分到两个区域的两个节点上。（第 2 部分）
  • 启动时能装下还不够。一个能干净装下的聊天模型在四天内九次耗尽内存。将内存比例从 0.92 降到 0.88、启用可扩展段并将并发序列上限设为 16，释放了 4.6 GiB。（第 2 部分）
  • 代价高昂的故障是静默的。一个被截断的流返回了 200，一个指标 API 报告可用但没有数据，监控处于待处理状态长达六天。（第 2 部分）
  • 超时层层叠加。先是 15 秒的路由默认值，然后是 60 秒的负载均衡器空闲超时，切断了仍在流式输出的回答。（第 2 和第 3 部分）
  • 智能体是最难处理的客户端。长达一小时的会话超过了其令牌 60 分钟的生命周期，而一个推理模型在第一个可见令牌之前思考了一分多钟。（第 2 和第 3 部分）
  • 低分往往不是模型的错。测试框架中的一个假 shell 让 Claude 得了 0 分。60 秒的空闲超时让一个模型失败，而一旦提高限制，它每次运行都能完成。（第 3 部分）
  • 缓慢有多个原因。一位工程师的“哇，好慢”追溯到隐藏的最大努力推理，而所有仪表盘看起来都正常。一块 GPU 显示 99% GPU-Util，而张量核心只有约 10% 的时间在忙。（第 4 部分）
  • 负载取决于客户端。智能体提示的中位数为 59K 令牌，约三分之二命中前缀缓存，而短提示会话通过启动子智能体让更多请求保持在进行中。（第 5 部分）
  • 引擎比预期更重要。在同样的两个 8-GPU 节点上，从 vLLM 切换到 SGLang 是最大的单项收益。128K 上下文上限看起来更快，只是因为它拒绝了长对话。（第 5 部分）

阅读完整系列

Upbound 博客上的每篇文章都详细讲述了这些故事，并附有背后的配置、查询和数字：

6. 实现职业转型

你不需要从头开始。把推理概念加入你已有的平台技能中，并公开展示你的工作。这个领域还很年轻，所以新人可以快速赶上。

选择一个方向

选择与你当前工作最接近的方向。大多数平台工程师从最初两个方向起步，然后向第三个方向发展。

方向重点适合你，如果
推理平台集群、GPU 调度、网关、自动扩缩容、多云容量喜欢 Kubernetes 和分布式系统
推理可靠性SLO、可观测性、容量规划、发布、事件响应承担过值班并实践过 SRE
运行时性能引擎调优、量化、推测解码、并行、内核喜欢性能分析并贴近硬件工作

遵循学习路径

Vishakha Sadhwani 的 AI Inference Engineering Roadmap 2026 是该领域一份详尽的 13 阶段路线图。从平台工程转过来，你可以更快地走完它，因为你已经掌握了大部分基础设施方面的内容。一条更短的路径：

  1. 学习模型，而不仅仅是容器。Transformer 基础、注意力和 KV 缓存、稠密模型与 MoE 模型，以及如何阅读模型配置。目标是在五分钟内估算任何模型所需的内存。

  2. 深入学习一个引擎。选择 vLLM，了解每个核心标志会牺牲什么，并亲自测量首 token 时间和每 token 延迟。

  3. 将你的平台技能迁移到 GPU。设备分配、承载长流的网关、基于推理信号的自动扩缩容，以及引擎的可观测性。

  4. 学会判断质量和成本。构建评估、运行容量扫描并计算每百万 token 的成本。这是平台工程师最常存在差距的地方，也是该角色最能增值的地方。

构建能证明这一点的项目

下面的每个项目都适合在一两块租用的 GPU 上运行，并且每个都会产出一个带有真实数字的仓库。在两次运行之间关闭实例，并对批量实验使用竞价容量。

项目它证明了什么要发布什么
在一块 GPU 上用 vLLM 服务一个 8B 模型。扫描 1、10 和 50 个并发用户。你能准确测量 TTFT、每输出 token 时间和吞吐量配置、负载脚本、图表和每百万 token 成本
预测你的 GPU 能容纳多少个 32K token 会话，然后进行测试你理解权重、KV 缓存和运行时开销你的预测、结果以及它们为何不同
比较 FP16 和 FP8，如果可以的话，再比较一种 4 位格式你可以用证据在质量与速度之间做权衡评估分数与延迟和吞吐量并列展示
先运行共享内容在前的相同提示词，再运行共享内容在后的你理解前缀缓存和提示词结构每一项的缓存命中率和 TTFT
在 Kubernetes 上使用 GPU Operator 部署，网关带 TLS 和认证，按队列深度自动扩缩容，并配置仪表盘你能把推理作为平台来运行清单或组合，以及仪表盘定义
在类智能体流量上比较 vLLM 和 SGLang，一次只改一个变量你基于数据做出引擎选择基准、方法和带置信区间结果
为一个智能体任务构建评估框架，使用确定性评分器你能区分模型失败和框架失败任务、评分器和阴性对照
复现一个故障：超时、内存溢出崩溃或卡住的发布你能运维它，而不只是部署它一份简短的事后复盘和运行手册

公开展示你的工作

许多推理岗位在进入招聘网站之前就通过人脉网络招满了。2026 年 8 月，Zeoli 发现一家估值 175 亿美元的推理服务公司没有列出任何专门的推理性能职位。公开的工作成果正是让网络之外的人被发现的方式。

  • 像写实验报告一样写 README。 说明问题、设置（模型、GPU、引擎版本和参数）、方法、带数字的结果、让你意外的地方，以及如何复现。

  • 公开失败的东西。 对失败进行清晰的说明比干净的演示更能体现能力。

  • 固定版本并展示成本。 没有引擎版本和价格的结果很难让人信任，更难被复用。

  • 写出来、讲出来。 把每个项目变成一篇短文。向聚会、CNCF 活动和社区直播提交演讲。

为开源做贡献

推理项目仍然需要的很多是平台工作。Upbound 自己来自 Project Champagne 的上游清单读起来就像一份平台待办事项：可配置的负载均衡器、证书签发、针对独占设备的 Recreate 发布、诚实的 Ready 信号、开箱即用的引擎指标抓取，以及适合长时间运行的智能体的认证。

值得关注的项目包括 vLLM、SGLang、llm-d、KServe、NVIDIA Dynamo、Agent Router（前身为 Envoy AI Gateway）、Gateway API Inference Extension、Modelplane 和 Crossplane。不错的首次贡献：

  • 运行它并报告哪里出了问题， 附上复现步骤和数字。Champagne 就是这样贡献最多的。

  • 编写运维文档： 根据你自己的运行经验撰写部署、调优和故障排查指南。

  • 添加指标、仪表盘和告警，让静默故障变得显眼。

  • 改进清单、Helm chart 和组合，使其适用于真实环境。

  • 为你手头的硬件贡献基准测试配方和测试。

阅读每个项目的贡献指南，从小改动开始，在接手大任务之前先在 issue 上评论。

持续学习

引擎每隔几周就会新增参数，研究在几个月内就会进入生产环境。

  • 阅读发布说明，针对你运行的引擎，每个版本都要读，并在升级时重新运行你的基准测试。

  • 阅读核心论文： Orca 关于连续批处理，PagedAttention ， DistServe 关于分离式部署，以及最初的 推测解码 论文，还有 FlashAttention 。

  • 阅读 Philip Kiely 的Inference Engineering 。这本电子书由 Baseten 免费提供。

  • 关注从业者。诸如 The Pragmatic Engineer 、 ByteByteGo 和 Data Gravity 这样的通讯很好地覆盖了这一领域。加入你所使用引擎的社区频道。

  • 学习评估。一个开放模型能否取代托管模型，取决于评估，而很少有工程师能构建好的评估。从 Anthropic 的 Demystifying evals for AI agents 以及 Hamel Husain 和 Shreya Shankar 的 评估 FAQ 开始。

  • 学习经济学。要能够向财务伙伴解释每百万 token 的成本和每用户会话的成本。

找到相关职位

不要指望目前会有一致的职位名称。同样的工作会以推理工程师、性能工程师、模型服务工程师或 ML 基础设施工程师的身份出现，有时也以 AI 平台工程师的身份出现，所以要把这些全都搜一遍。薪资反映了这些技能的稀缺程度：2026 年 8 月，Zeoli 发现 Anthropic 一个推理性能岗位的薪资标为 350,000 至 850,000 美元，OpenAI 的同类岗位为 295,000 至 555,000 美元。

不过，你也许不需要换工作就能开始。如果你的公司正计划首次自托管模型，请主动举手。你的团队很可能最终会负责那个项目，而运行它则是你能获得的最直接经验。

为面试做准备

练习回答这些问题。每一题都指向本指南中涵盖它的章节。其中几题改编自 Lamhot Siagian 关于高效推理的面试口袋笔记（第 7 节）。

  • 预填充与解码。为什么解码通常受内存带宽而非计算限制，而在长上下文时又会发生什么变化？（第 2 节）

  • 硬件趋势。如果计算的增长速度持续快于内存带宽，推理会很快变成计算受限吗？（第 2 节）

  • 内存计算。在给定的上下文长度和并发量下，一个模型及其 KV 缓存需要多少内存？（第 2 节）

  • 有效吞吐量。什么是有效吞吐量，为什么用它来规划容量？（第 2 节）

  • 前缀缓存。哪些应用从前缀缓存中受益最大？（第 2 节）

  • 精度。你需要在两块 80 GB GPU 上服务一个 70B 模型。你会选择什么精度，为什么？（第 2 节和第 3.4 节）

  • 量化。仅权重量化何时能加速，何时不能？（第 3.4 节）

  • 推测解码。什么情况下你不会使用推测解码？（第 3.4 节）

  • 分块预填充。长提示词如何拖慢其他用户的流式输出，分块预填充又改变了什么？（第 3.4 节）

  • Parallelism. Which parallelism strategy would you pick for a given model and GPU type, and when does tensor parallelism beat pipeline parallelism? (Sections 3.4 and 3.5)

  • Profiling. How would you tell whether a workload is limited by compute or by memory bandwidth? (Section 3.8)

  • Debugging “slow.” p99 time to first token just spiked. How do you tell queueing, hidden reasoning and slow generation apart? (Section 3.8)

  • Cost. What does a million tokens cost on your GPUs, and how does that compare with a hosted API? (Section 2)

  • Capacity planning. Your user count will grow 10x in six months. How do you plan capacity? (Section 3.10)

  • Rollouts and SLOs. How would you roll out a new model version safely, and what SLO would you set for the service? (Sections 3.8 and 3.10)

  • Failure stories. Describe one failure with real numbers. Cover what broke and how you found it, then what you changed.

7. Sources and further reading

Upbound and Modelplane

Books and articles

Evals and benchmarks

Papers

来源：Hacker News · docs.modelplane.ai

推理能力开源生态部署工程教程实践#教程/实践#部署/工程#推理#开源生态