推理工程 是做什么的？
使用此技能，将AI产品的质量、延迟、可靠性和成本要求转化为可测量的推理系统。这是一个独立的操作综合，受Philip Kiely的《Inference Engineering》（Baseten Books，2026年出版）启发，但与作者或出版商无关联，亦未获得其认可。供应商特性、模型发布、硬件可用性和软件行为变化迅速；在做出实施决策前，请务必对照官方文档核实当前详细信息。
从工作负载开始
在选择引擎或优化方案之前，需要明确：
- 产品契约： 所需的输出质量、模态、上下文/输入大小、响应形状、流式需求以及失败行为。
- 流量特征： 请求速率、并发度、突发性、到达模式、输入/输出长度分布以及可缓存的公共前缀频率。
- 服务目标： 端到端P50/P95/P99延迟、首Token延迟（TTFT）、Token间延迟（ITL）、吞吐量、可用性和恢复目标。
- 约束条件： 预算、区域、数据驻留、隐私、许可、硬件访问和运营能力。
- 基线： 具有代表性的质量评估，以及在真实负载下的端到端性能和成本。
不要孤立地优化代理指标。定义工作单元，并在适用情况下包含客户端、队列、网络、预处理、模型和后处理时间。对于智能体（Agent）流程，需衡量包括工具调用和重试在内的整个任务。
操作工作流
- 特征化工作负载。 将交互式在线流量与离线/批处理工作区分开；识别延迟敏感型和吞吐量导向型路径。记录真实的输入/输出分布和并发度。
- 选择候选模型。 根据任务特定质量、模态、上下文、服务约束、许可和运营契合度进行筛选。仅使用公共基准来缩小候选范围；需在具有代表性的产品数据和失败案例上进行评估。
- 设定预算。 将端到端目标转化为用于排队、网络、预处理、预填充、解码和后处理环节的预算。为突发和降级情况预留余量。
- 将模型适配到硬件。 估算权重内存、运行时/激活开销、KV缓存需求以及可用余量。检查实测的内存带宽、计算能力、互连和拓扑结构；标称的加速器规格不能代表工作负载基准。
- 建立可重现的基线。 固定模型修订版本、引擎/版本、硬件、精度、配置、提示词混合、输出限制和负载模式。进行预热，运行足够数量的样本，并在相同时间报告百分位数和吞吐量。
- 定位瓶颈。 首先使用端到端测量，然后进行系统和内核分析。区分排队、预填充、解码、内存容量/带宽、计算、通信和主机开销。
- 每次只改变一个变量。 应用解决已测量瓶颈的最简单优化方案。同时重新检查质量、尾延迟、吞吐量、内存和成本。
- 验证生产行为。 测试过载、冷启动、扩展事件、故障、部署、取消、流式传输和恢复。对服务目标中使用的相同指标进行监控。
指标与诊断
- TTFT： 从明确声明的起始事件（例如客户端发送或服务器接受）到生成第一个Token的时间。在比较不同运行时需保持该边界的一致性；它对排队、提示词长度、预填充和启动效应很敏感。
- ITL： 生成Token之间的时间；反映解码响应性。报告每个请求的分布，而不仅仅是聚合的Token速率。
- 端到端延迟： 客户端观察到的完成时间；包括网络和应用层工作。
- 吞吐量： 在指定的工作负载和延迟/质量包络内，单位时间内完成的请求或Token数量。说明Token/秒是面向单个用户还是整个系统。
- 百分位数： 报告P50以及P95/P99等尾部目标；平均值可能掩盖慢速请求。
- 好吞吐量： 在满足相关延迟和质量目标的情况下完成的工作量。使用此指标来比较那些在速度与质量或尾部行为之间进行权衡的配置。
将症状解读为假设，然后通过跟踪/性能分析进行验证：
| 症状 | 建议测量的区域 |
|---|---|
| TTFT高，ITL正常 | 队列等待、长提示词、预填充计算、冷启动、预处理 |
| TTFT正常，ITL差 | 解码带宽、批处理争用、KV缓存压力、内核效率 |
| 两者随并发度升高而恶化 | 排队、内存容量、批处理策略、准入控制、饱和 |
| GPU利用率低，延迟高 | CPU/分词、数据传输、同步、网络、调度 |
| 吞吐量上升但尾延迟违反SLO | 批处理/并发策略、队列限制、工作负载隔离 |
这些是诊断线索，而非结论。在更改配置之前，请确认活跃的瓶颈。
模型与硬件决策
- 优先选择能够通过产品质量评估并具有可接受余量的最小/成本最低的模型。仅在评估识别出特定差距且生命周期成本合理时，才考虑提示工程、检索、微调或蒸馏。
- 当在线和离线部署的延迟、批处理或可用性目标冲突，且实测流量证明运营开销合理时，应将两者分开部署。
- 确保模型和运行时状态适合加速器内存，并为KV缓存、激活、碎片化和并发性预留明确的空间。仅考虑权重拟合是不够的。
- 对于自回归大语言模型，预填充和解码对硬件的压力不同：预填充通常计算密集；解码通常受内存带宽限制。需根据实际的序列和批处理组合对两者都进行测量。
- 多GPU的选择需要在内存/延迟/吞吐量与通信和复杂性之间进行权衡。张量并行可以减少分割模型的单请求延迟；专家并行可以在大规模下服务稀疏专家。务必验证互连和同步成本。多节点执行需要特别仔细的通信测量。
- 对于图像、视频、音频、嵌入和视觉-语言等工作负载，需使用特定模态的流水线和指标。包括预处理、分块、编码器/解码器和后处理成本；不要盲目应用大语言模型的Token指标。
- 在部署前检查模型和数据集许可证以及相关的安全、隐私和法规要求。
有关这些选择背后的推理，请参考模型与硬件基础。有关框架、格式和服务引擎的兼容性，请参考软件栈选择。这些参考资料提供决策方法，而非永久的排名：请务必验证对具体模型、加速器、运行时版本和功能集的支持。
优化方案
仅在建立基线并识别出兼容的瓶颈后才应用：
批处理与调度
批处理可以提高加速器利用率并分摊开销，但同时会增加排队和单请求延迟。需根据真实的到达模式调整并发度、批处理限制、等待窗口和准入控制。当交互式流量和批处理工作的目标冲突时，应保护交互式流量。
量化
将量化视为一个质量/性能的谱系，而非二元设置。根据测量到的内存、带宽、计算和质量约束，选择要更改的组件和精度。每次更改后，评估代表性的任务质量、边缘情况和回归集；在引擎允许的情况下，分别观察权重、激活、注意力和KV缓存的效果。如果未达到产品质量下限或可靠性目标，则回退更改。
推测解码
仅当草稿/提议机制的成本和接受行为能为目标工作负载带来净收益时，才使用它。测量接受率、内存开销、批处理大小影响、单用户ITL、聚合吞吐量和成本。在高并发或接受率较低的情况下，收益可能会缩小甚至逆转。
KV与前缀缓存
当公共前缀重复出现且正确性/隔离性要求允许时，重用缓存状态。测量命中率、节省的预填充工作量、存储/内存成本、逐出行为和路由局部性。定义缓存键和租户/安全边界，确保一个请求无法重用另一个租户的私有上下文。长上下文和高并发会增加KV缓存压力；需考虑放置和传输成本。
并行与分离
当模型适配、延迟或吞吐量测量结果证明通信开销值得时，引入并行。仅当工作负载足够大且稳定，能够从独立资源分配中受益，并且系统能够管理KV传输/路由时，才将预填充和解码分离。在比较时需包含网络带宽、传输延迟、故障模式和运营复杂性。
内核与运行时优化
在编写或选择专用内核之前，先进行性能分析。内核融合可以减少内存流量和启动开销，但兼容性和数值行为需要关注。使用相同的模型修订版本、硬件、提示词混合、输出长度、负载和质量检查来比较框架/运行时/引擎的候选方案。
有关量化方法、推测解码家族、缓存放置、长上下文服务和分布式执行的详细比较，请阅读优化方案手册。
基准测试与性能分析
- 使用生产轨迹或保留请求大小、到达模式和缓存特征且隐私安全的工作负载。综合测试对于受控实验很有用，但需说明其局限性。
- 分别记录冷启动和热启动行为。包括预热、足够的持续时间/样本数量、重复运行、方差以及软硬件版本。
- 扫描负载以找到饱和点以及在SLO下的最大好吞吐量。避免将轻负载运行与过载运行进行比较。
- 每次更改一个因素以进行归因；调优后，运行一个组合的端到端测试，因为优化措施可能相互影响。
- 将系统基准测试与任务质量评估相结合。如果性能提升导致输出质量低于产品阈值，则不算成功。
- 基准测试显示什么慢了；性能分析有助于解释为什么慢。使用侵入性最小的分析器来隔离活跃的瓶颈，并用新的基准测试验证建议的修复方案。
生产就绪性
- 容量与自动伸缩： 基于领先指标（队列深度、利用率、内存/KV压力、到达率）以及已完成的工作进行伸缩。考虑配置和模型加载时间；在冷启动违反目标时，需保持足够的容量或以优雅方式降级。
- 排队与过载： 限制队列和请求大小，设置超时/取消，使用准入控制，并定义明确的过载响应。无边界排队会将饱和转化为尾延迟失败。
- 可靠性： 测试健康检查、带限制的重试、必要时的事务幂等性、实例丢失、区域/提供商故障、滚动发布、回滚和容量耗尽。重试可能放大过载。
- 部署： 固定模型工件和依赖项，验证启动/就绪，灰度更改，比较质量和服务指标，并保留经过测试的回滚路径。避免在镜像、日志或基准测试工件中暴露密钥。
- 可观测性： 将请求轨迹与模型、引擎、硬件和配置版本关联起来。追踪TTFT、ITL、端到端百分位数、队列时间、吞吐量/好吞吐量、错误、缓存命中率、利用率、内存、冷启动和成本。
- 成本： 比较在所需质量和SLO下每个成功请求或有用的输出的成本，包括空闲容量、复制、网络、存储和工程/运营负担。缩归零可以减少空闲支出，但会增加冷启动延迟。
- 安全与合规： 控制模型和数据访问，隔离租户，保护日志中的提示词和输出，定义保留期限，验证依赖项和工件，并满足适用的数据驻留和法规要求。
有关容器可重现性、容量和路由、多区域运营、客户端协议和部署实践的详细信息，请阅读生产运维。有关不同模态的测量，请阅读模态特定的推理考量。
参考指南
| 任务 | 请阅读 |
|---|---|
| 构建工作负载卡片、建立基线或定位瓶颈 | 本文，然后参考优化方案手册 |
| 理解模型执行、加速器适配或硬件权衡 | 模型与硬件基础 |
| 选择框架、模型格式、内核路径或服务引擎 | 软件栈选择 |
| 调优量化、推测、缓存、并行或分离 | 优化方案手册 |
| 服务视觉、嵌入、音频、图像或视频工作负载 | 模态特定的考量 |
| 规划自动伸缩、部署、可靠性、API/客户端行为和成本 | 生产运维 |
推理任务的响应格式
在提供建议或实施时，需包含：
- 工作负载假设和缺失的测量数据。
- 目标和基线指标。
- 主要的瓶颈假设及其证明方法。
- 按优先级排序的实验计划，说明预期的权衡。
- 质量、尾延迟、可靠性、安全性和成本的验收标准。
- 当前的供应商/模型/运行时事实，并附上影响建议的官方来源链接。