推理优化

模型完成训练以后，服务面对的工作变了：参数通常保持固定，请求却会不断到达。用户关心的是预测是否可靠、多久能够收到结果，以及系统在繁忙时能否继续接住请求。本课从这些可观察的结果出发，认识推理优化的常用方法，并完成可在本地复现的吞吐测量。文中的服务指标表均为教学假设数据，不代表特定硬件或软件的性能承诺。

1 推理优化要回答什么

假设我们用公开的 Telco Customer Churn 数据集建立客户流失分类器。输入包括在网时长 tenure、月费用 MonthlyCharges、合同类型 Contract 和互联网服务类型 InternetService，输出是客户流失的概率。标签 Churn 只用于训练与评估。即使模型的验证集 AUC 已经达到可接受水平，服务仍可能因为逐条预测、重复转换字段或排队过久而表现不佳。推理优化要研究的是：在质量要求得到满足的条件下，怎样减少完成预测所需的时间和资源。

先区分训练和推理。训练通过样本调整参数；推理把新输入交给已经确定的模型。服务收到输入以后，还要解析字段、处理缺失值、完成编码、执行模型、应用阈值并返回结果。因此，模型计算耗时只是请求总耗时的组成部分。若模型只占总时间的 20%，即使把这部分缩短到原来的 1/2，总时间也只减少 10%。这能解释为什么有些模型基准很漂亮，用户却没有明显感觉。

我们用 3 类指标描述结果。延迟表示请求从到达到完成需要多久；吞吐表示单位时间完成多少项有效任务；资源成本表示为完成这些任务消耗多少算力、内存或费用。分类服务可使用样本/秒，生成服务可使用请求/秒和输出 token/秒。token 是模型处理文本的基本片段，未必对应完整汉字或单词。不同输出长度的生成任务不能只凭请求/秒判断效率。

延迟也不能只看平均值。p50 表示有 50% 的请求在该时间内完成，p95 表示有 95% 的请求在该时间内完成，p99 更关注最慢的部分。假如大多数流失预测在 20 毫秒内完成，但包含较长文本备注的请求经常超过 300 毫秒，平均值可能掩盖这类用户的等待。生成服务还要区分首包延迟与完整响应延迟，前者衡量收到第 1 段输出前的等待，后者包含后续生成时间。

优化之前应写出约束，例如“在指定峰值流量下，流失正类召回率不低于 0.80，p95 总延迟不超过 100 毫秒”。这里的召回率是实际流失客户中被找出的比例。不要为了满足延迟目标而跳过复杂输入或把失败请求从统计里删掉。超时、拒绝和预测错误都会影响服务是否真正完成任务，必须与成功请求的速度共同报告。

2 算子融合、量化与投机解码

推理优化有不同作用范围。算子融合主要改变计算的组织方式，量化主要改变数值表示，投机解码则改变生成候选文本和核验候选文本的过程。它们可以帮助同类任务减少开销，却不能脱离模型结构直接套用。判断方法是否合适，要先问它消除了什么重复工作，再问它可能改变什么输出。

算子可以理解为模型中的基本计算步骤，例如矩阵乘法、加偏置和激活函数。假设图像分类模型连续执行这 3 个步骤，分开执行时可能多次写入、读取中间结果，并多次发起计算。融合后，执行系统把兼容步骤组合起来，减少中间数据搬运和调度开销。它没有让模型少学某类图像，而是重新安排已确定的计算。具体能否融合，取决于算子形状、执行后端和设备支持。

融合通常以保持计算含义为目标，但浮点运算顺序变化仍可能产生很小的数值差异。对于远离分类阈值的样本，概率从 0.9400 变为 0.9399 通常不改变标签；对于阈值为 0.50、原概率为 0.5001 的样本，相近大小的差异就可能使判断翻转。因此需要检查输出误差与任务指标，不能仅用“数学公式相同”代替评估。若输入形状频繁变化，某些融合路径也可能无法复用。

量化把权重或中间数值从较高精度转换为较低精度的表示，例如从 32 位浮点数转换为 8 位整数。只看单个权重的原始存储，32 位到 8 位意味着所需位数降为原来的 1/4；实际模型还包含缩放参数、未量化算子和运行时开销，整体内存与速度不会自动得到同样比例的改善。执行设备还必须支持相应计算，否则额外的格式转换可能抵消收益。

可以把量化想成用有限刻度记录连续测量值。刻度越粗，表示误差可能越大；范围选得过窄，较大的数值可能被截断。训练后量化常用校准样本估计合适的数值范围。校准集应来自训练侧或专门保留的数据，覆盖真实输入的范围，不能拿测试集不断调配置。对短文本分类器，如果校准样本全部是长度小于 20 的句子，部署后遇到长度为 300 的文本，就可能出现不符合原先评估的误差。

投机解码适用于逐步生成文本的模型。通常由较小的草稿模型先提出若干候选 token，再由目标模型集中核验；被接受的部分可以直接推进，遇到拒绝则按规定处理并继续生成。目标是把部分串行等待变为更高效的核验。这里的关键不是“跳过检查”，而是用较便宜的候选过程帮助目标模型完成工作。

在满足相应采样与校正规则时，投机解码可以保持目标模型定义的输出分布；随意接受草稿或省略校正则没有这个保证。入门阶段不必推导接受概率，但要知道“有目标模型核验”与“任意近似生成”是不同承诺。收益还受草稿接受率影响：领域变化、提示风格变化或草稿质量不足，都可能使拒绝增多，额外草稿成本反而拖慢响应。固定输出标签的图像分类器不需要这条生成路径。

下面的交互把这 3 种方法放回共同的评估过程：先确认适用条件，再检查输出，最后比较资源和时间。方法名称本身不能作为验收证据。

3 连续批处理与缓存复用

模型计算很快时，服务仍可能把大量时间花在等待与重复准备上。批处理把多个输入合成批次，让模型集中执行，摊薄固定开销。对于流失分类，可以把多名客户的特征组成矩阵；对于图像分类，可以把多张同尺寸图像组成张量。批次增大时，设备利用率可能提高，但输入准备、结果拆分和额外内存也会增加，吞吐不保证持续上升。

批处理还引入等待。若服务规定凑齐 32 个请求才计算，在低流量时，第 1 个请求可能等很久。实际系统常同时设置最大批量和最长等待时间，例如最多 16 个请求、最多等待 4 毫秒，任意条件满足就发出当前批次。这里的 4 毫秒只是教学参数，是否合适要由服务延迟预算决定。离线任务可以接受更长等待，面向交互的请求通常更敏感。

固定批次的生成服务还会遇到请求长度不同的问题。假设同时生成的 4 个请求分别需要 20、30、100、200 个 token，短请求结束后，若位置一直保留到整批结束，设备就可能出现空闲容量。连续批处理允许已完成请求退出，并在合适的调度边界让新请求进入。它提高了利用率，也要求系统持续管理不同请求的进度、缓存和等待队列。

连续批处理不是所有请求都能立即开始。活跃请求已经占满可用内存时，新请求仍需排队；过度接纳长输入，还可能挤压短请求的执行机会。因此至少要观察排队时间、活跃请求数和每类长度的延迟。若总体吞吐提高，但长文本等待不断增加，调度策略仍未满足服务目标。可以给等待时间设上限，或按长度与优先级安排队列，但具体算法留待后续课程。

缓存复用则减少已经做过的工作。表格分类可以缓存固定类别编码表，短文本分类可以缓存不变的分词配置；生成模型还常缓存当前请求已有上下文的注意力键和值，通常称为 KV 缓存，避免每生成 1 个 token 都重复计算全部历史。某些服务允许不同请求复用完全相同的前缀，但需要核对模型版本、分词方式和前缀内容是否一致。

缓存有容量和有效期。相同文本在不同模型版本下可能产生不同结果，结果缓存键若遗漏版本就可能返回过期预测。前缀复用还应保持用户与权限边界，不能让本应隔离的输入互相可见。命中率高并不等于内存足够：长上下文越多，缓存占用越大，可能使可同时处理的请求数下降。服务应分别记录冷缓存、热缓存和混合流量的表现。

4 动手：测量一次优化前后吞吐

现在完成范围明确的实验：比较同个模型逐条预测与每批 64 条预测的离线吞吐。使用 scikit-learn 自带的公开 Digits 手写数字数据集，共 1797 张 8×8 灰度图，每张图展开为 64 个像素特征，目标是 0–9 的数字类别。这个实验测量批量调用带来的变化，不实现连续批处理，也不包含网络与真实请求排队。

数据按类别分层切成约 60% 训练、20% 验证和 20% 测试。标准化器只在训练集拟合，逻辑回归的正则化参数只根据验证集宏平均 F1 选择。宏平均 F1 先分别计算各类别 F1，再对类别取平均，使每类权重相同。测试集在选择结束后用于最终质量报告与固定负载计时，不根据测试结果反复挑批量。生产环境也应把性能调优负载与最终验收负载分开。

下面的代码需要安装 numpy、scikit-learn 和 threadpoolctl。它限制主要数值计算库的线程数，减少线程配置变化带来的干扰；仍应记录 Python、依赖、处理器与操作系统版本。首次调用可能包含初始化开销，因此计时前先预热。多轮结果报告中位数，以降低偶发调度噪声的影响。

from time import perf_counter
import numpy as np
from sklearn.datasets import load_digits
from sklearn.model_selection import train_test_split
from sklearn.pipeline import make_pipeline
from sklearn.preprocessing import StandardScaler
from sklearn.linear_model import LogisticRegression
from sklearn.metrics import precision_recall_fscore_support
from threadpoolctl import threadpool_limits

X, y = load_digits(return_X_y=True)
X_train, X_rest, y_train, y_rest = train_test_split(
    X, y, test_size=0.4, stratify=y, random_state=45
)
X_val, X_test, y_val, y_test = train_test_split(
    X_rest, y_rest, test_size=0.5,
    stratify=y_rest, random_state=45
)

def predict_batches(model, data, batch_size):
    return np.concatenate([
        model.predict_proba(data[i:i + batch_size])
        for i in range(0, len(data), batch_size)
    ])

def benchmark(model, batch_size):
    for _ in range(3):
        predict_batches(model, X_test, batch_size)
    elapsed = []
    for _ in range(7):
        start = perf_counter()
        for _ in range(10):
            predict_batches(model, X_test, batch_size)
        elapsed.append(perf_counter() - start)
    seconds = float(np.median(elapsed))
    return len(X_test) * 10 / seconds

with threadpool_limits(limits=1):
    candidates = []
    for c in [0.1, 1.0, 10.0]:
        model = make_pipeline(
            StandardScaler(),
            LogisticRegression(C=c, max_iter=3000)
        )
        model.fit(X_train, y_train)
        _, _, f1, _ = precision_recall_fscore_support(
            y_val, model.predict(X_val),
            average="macro", zero_division=0
        )
        candidates.append((f1, model))
    _, chosen = max(candidates, key=lambda item: item[0])
    prob_1 = predict_batches(chosen, X_test, 1)
    prob_64 = predict_batches(chosen, X_test, 64)
    np.testing.assert_allclose(prob_1, prob_64, rtol=1e-6, atol=1e-8)
    prediction = chosen.classes_[np.argmax(prob_64, axis=1)]
    p, r, f1, _ = precision_recall_fscore_support(
        y_test, prediction, average="macro", zero_division=0
    )
    print({"precision_macro": p, "recall_macro": r, "f1_macro": f1})
    for batch_size in [1, 64]:
        print({"batch": batch_size,
               "samples_per_second": benchmark(chosen, batch_size)})

计时区域包含切片、标准化、概率预测和结果拼接，排除了数据读取与训练。两种配置的输入内容、模型和线程限制相同，最后不足 64 条的批次也正常处理。输出概率的近似相等检查用于发现批处理实现错误；若检查失败，应先解释差异，不能只保留更快的数字。测试集的宏平均指标描述质量，但不能据此推断其他图像来源也有相同表现。

记录结果时写明“样本/秒”，并计算加速比为批量吞吐除以逐条吞吐。不要把每批耗时直接当成每个在线请求的延迟，也不要把吞吐的倒数当成 p95。这个实验所有输入已在内存中，系统无需等待请求到齐；在线压测必须补上实际到达间隔、并发量和排队。若第 2 次测量明显更快，可以交换配置顺序再做预先约定的重复实验，以排查温度、频率和后台任务的影响。

5 精度与成本取舍

这里的“精度”有 2 层含义。数值精度描述 32 位浮点、8 位整数等表示方式，预测质量则由精确率、召回率、F1、AUC 等任务指标描述。降低数值精度可能保持预测质量，也可能破坏少数关键样本。不要仅凭模型文件缩小，就认为任务效果没有变化；也不要把数值位数直接解释成分类准确率。

以流失预测为例，精确率表示被判为流失的人中实际流失者的比例，召回率表示实际流失者中被识别者的比例。F1 综合精确率与召回率，ROC AUC 则描述跨多个阈值的排序能力。若流失客户占比较低，整体准确率可能很高，却漏掉大多数正类；这时应结合正类召回率、精确率和 PR AUC 判断。阈值必须在验证集上按业务约束确定，不能在测试集上反复调整以掩盖量化损失。

假设原模型在固定测试集的正类召回率为 0.84，量化版本为 0.83，看起来只下降 0.01。但进一步分组后发现，短在网时长客户的召回率从 0.82 降到 0.73。总体指标可能被人数更多的稳定客户稀释。是否接受这种变化，要看事先约定的分组质量底线，也要检查该组样本数量，避免把极少样本的偶然波动当成可靠结论。

成本比较需要固定工作量和计价边界。假设相同资源每小时成本为 3.6 个计价单位，配置甲完成 1000 项任务需要 2 秒，配置乙需要 1 秒，那么对应计算费用约为 0.002 与 0.001 个计价单位。实际服务还存在空闲、预留容量、数据处理和失败重试的成本，不能只用满载吞吐估算整月账单。若为了批处理等待而导致大量超时，名义上的单位预测成本更低也没有意义。

可以把候选配置放在“延迟、吞吐、质量、内存、单位成本”的表格里。先剔除违反硬约束的配置，再比较余下方案。滑块用于展示这种筛选逻辑：批量提高时，吞吐先增长后趋缓，等待与内存持续变化；这些曲线是教学示意，真实服务必须以测量替换。不存在适合所有流量的固定最佳批量，低负载和高负载可能需要不同的选择。

6 常见坑：优化后关键长尾变差

“关键长尾”既可能指最慢的请求，也可能指样本较少却重要的人群或输入类型。平均吞吐提高，不能证明这些部分得到改善。短文本分类服务中，常见短句占据大多数流量，长文本和少数类别只占很小部分；若优化减少了可支持的长度或改变了数值范围，总体指标变化很小，长文本的 F1 却可能明显下降。应同时按输入长度、类别和业务相关分组评估。

排查时先辨别服务变慢还是预测变差。若质量指标基本稳定，而 p99 突然上升，优先查看队列、批次等待、内存和缓存失效；若延迟稳定而某类召回率下降，就检查数值变化、预处理、截断与阈值。两类故障也可能同时出现，例如长文本占用更多缓存，既造成排队，又被错误截断。只有把请求的输入特征、阶段耗时和输出结果关联起来，才能缩小原因范围。

数据泄漏会让质量比较失去可信度。例如对全部流失数据先拟合标准化器，再划分训练与测试，就把测试分布提前带入了流程。把流失后才产生的销户状态当成输入，问题更严重，因为服务预测时根本拿不到该字段。文本数据中重复或近似重复的消息跨越训练与测试，也可能让模型表现虚高。应按真实预测时点定义可用字段，并在合适的客户、来源或时间边界划分数据。

类别不平衡会放大“总体无损”的误导。假设 95% 的请求属于普通类，少数类召回率大幅下降，整体准确率仍可能只变化很小。比较优化版本时，应保留每类混淆矩阵、精确率、召回率与样本数，并对相同输入进行配对比较。若某类只有 12 条测试样本，减少 1 个正确结果就有明显影响；此时需要更多代表性样本或报告不确定性。

分布漂移则意味着线上输入与离线评估逐渐不同。例如上线后新增合同类型、月费用范围变化，或文本出现更多缩写。缓存命中下降和草稿接受率降低可能是漂移的性能信号，分类质量也可能同时变化。监控可以先跟踪字段缺失率、长度分布、类别频率和超出训练范围的比例；真实标签延迟到达后，再补充质量评估。代理指标只能提示风险，不能直接证明召回率保持不变。

最后检查测量口径。只统计成功请求会隐藏超时；只测热缓存会夸大稳定收益；闭环压测在服务变慢时自动减少发送速度，可能掩盖队列积压。应说明请求到达方式，并同时报告发送量、完成量、失败量和排队趋势。发生退化时先保留证据、退回已验收配置，再逐项缩小变量，不要同时修改批量、阈值、模型和预处理。

7 案例：批处理抬高首包延迟

某团队用公开 AG News 新闻分类数据准备短文本分类任务，再把标签生成包装为交互演示：用户提交新闻标题，服务返回类别名称。原始 AG News 的训练部分进一步划分训练集与验证集，官方测试部分保留作最终评估。类别包括世界、体育、商业与科技，输入长度分组由验证集提前确定。这个场景的标签很短，因此长时间等待首包尤其容易被用户察觉。

团队为了提高设备利用率，把最大批量从 4 改为 16，并允许调度器等待最多 40 毫秒收集请求。以下数据为案例演示值，均来自相同输入长度分布与指定到达流量下的假设测量。吞吐表示包含约定余量、且满足表中完成状态口径的已完成请求速率；表格没有证明更大流量下仍能保持相同延迟。

如果只看吞吐，第 2 行似乎最成功；若服务约定首包 p95 不超过 60 毫秒，它已经不合格。宏平均 F1 相同也不能补偿等待违约。团队拆分链路后发现，模型执行时间有所下降，但批次等待明显增加。尤其在稀疏流量时，批次难以凑满，请求经常接近等待上限才开始计算。

修正方案保留较大批量上限，把等待限制收紧到 4 毫秒，并允许未满批次按时发出。这样繁忙时仍能合批，低流量时不会为了凑满持续等待。团队还为长文本单独报告 p95，防止总体数据被短文本主导。若内存成为瓶颈，仅修改等待时间仍然不够，还需限制同时活跃请求或输入长度，并把限制明确告知调用方。

这个案例还有测量上的特殊性：分类标签通常可以作为完整结果直接返回，因此首包与完整响应很接近。对于长篇生成服务，两者应分别统计，不能照搬此处的延迟关系。输出长度、提示长度和生成设置都要保持可比，否则吞吐上升可能只是生成内容变短。

8 把推理优化写进服务方案

方案应从具体负载开始描述。对流失分类器，列出特征字段、缺失值处理、输出概率与阈值，说明请求是实时单条还是夜间批量；对短文本分类器，写出输入长度分布、类别范围与峰值到达速率。不要仅写“支持高并发”，因为并发数是某时刻系统内的请求数，到达速率才表示单位时间进入多少请求，两者受延迟共同影响。

接着明确优化发生在哪段链路。若采用算子融合，记录执行后端和可兼容的输入形状；若采用量化，记录数值格式、校准集来源与未覆盖部分；若采用连续批处理，记录批量上限、最长等待与活跃请求限制。缓存方案则需要键的组成、失效条件和容量限制。写清这些信息，后续才能解释模型相同而服务结果不同的原因。

证据应分成质量与性能两部分。质量部分给出训练、验证、测试的划分方法，固定阈值，并报告总体与关键分组指标。性能部分给出硬件、软件版本、线程或设备配置、预热规则、请求到达方式，以及从请求进入到响应完成的计时边界。若只测模型进程内预测，就明确称为进程内基准，不将其替换为在线总延迟承诺。

验收条件最好直接写成可判断的句子，例如“在约定负载下，p95 总延迟不超过 100 毫秒，超时率不超过 0.5%，正类召回率下降不超过 0.01，关键分组不低于各自底线”。这些数值是方案示例，真实阈值需结合任务损失确定。比较时保留样本量与重复测量波动，避免对微小差别作出过强结论。

上线安排需要有版本对应关系：模型、预处理、阈值、执行配置和缓存命名应形成完整记录。先让有限流量进入新配置，观察延迟、失败率与内存；标签到达后继续核对任务质量。出现关键分组退化、持续积压或资源异常时，应能切回已验收版本。缓存也要跟随版本隔离或失效，防止回退后仍返回新版本结果。

最后给出容量与成本的适用范围。低流量下可能主要为空闲资源付费，高流量下则可能受队列或内存限制。说明预测峰值、余量和增长假设，比提供脱离负载的单个“最低成本”数字更有用。优化方案交付的是可解释、可复测、可回退的服务行为，而不是某个方法名称。

9 从推理优化走向MoE（A46）

本课的方法主要在模型表示、计算执行和请求组织上减少开销。接下来可以问：当模型变得很大时，每次请求是否必须使用全部参数？MoE，即混合专家模型，为这个问题提供了不同方向。它让路由机制根据输入选择部分专家参与计算，从而在模型总容量与每次实际计算之间建立新的关系。

入门时先抓住 3 个概念：模型可以有多个专家，路由决定输入交给哪些专家，最终把选中专家的结果组合起来。这里的专家是模型内部的可训练部分，不是人工填写的业务规则。总参数多不表示每次都使用全部参数，每次激活参数较少也不表示部署时只需存放这些参数。资源需求仍与专家存储、路由和请求分布有关。

这与本课的批处理存在联系。若很多输入被路由到相同专家，该处可能繁忙；其他专家却未充分利用，系统就出现负载不均。即使平均计算量下降，热点专家上的排队仍可能拉高长尾延迟。量化与缓存也可能继续有用，但必须重新观察实际执行路径，不能把普通模型的吞吐数字直接移植到 MoE。

还要注意质量证据的连续性。路由改变后，不同类别、文本长度或来源的数据可能受到不同影响。前面建立的独立测试、分组评估和分布漂移监控，仍然是判断收益的基础。若某类请求经常走向拥挤路径，或者少数类的预测更不稳定，就要同时解释资源和质量表现，不能只报告平均激活参数量。

在进入 A46 前，可以检查自己能否回答：逐条预测改成批处理后，为什么吞吐提高而单个用户可能等得更久？8 位权重为什么不能保证整体速度提高 4 倍？总体 F1 稳定时，为什么还要检查少数类？如果能分别从等待、执行支持与分组评估解释原因，就已经具备继续理解 MoE 的基本视角。路由如何训练、专家如何分配到设备等内部细节，留到后续展开。

放进方案里

我们为基于公开 Telco Customer Churn 数据的流失预测原型建立推理优化方案。输入包括在网时长、月费用、合同类型与互联网服务类型，标签为是否流失。按客户划分约 60% 训练、20% 验证、20% 测试，预处理只在训练集拟合，阈值在验证集确定。若用于未来客户预测，再补充按时间划分的验证，排除预测时点之后才产生的字段。

候选方案采用支持的算子融合与最多 16 条的批处理，最长合批等待设为 4 毫秒；量化作为独立候选评估，避免同时修改多项因素。校准样本从训练侧保留，覆盖缺失字段、短在网时长及费用边界。缓存键包含模型与预处理版本，版本切换时失效。所有配置与模型文件共同登记，以便复测和回退。

验收在约定硬件、软件版本与到达流量下进行，覆盖冷启动、稳定流量和突发请求。目标为 p95 总延迟不超过 100 毫秒、超时率不超过 0.5%，并报告吞吐、内存峰值与每 1000 次有效预测成本。固定测试集上正类召回率下降不超过 0.01，同时核对精确率、F1、ROC AUC、PR AUC及关键分组结果，保留各组样本数。

批处理验收固定同一组请求及到达时间，分别记录合批等待和模型执行耗时，确认吞吐收益没有耗尽延迟预算。量化候选另附概率误差与阈值两侧标签翻转的样本数；若低精度算子回退导致转换开销增加，即使文件变小也不判定优化成功。

发布先接入有限流量，持续观察排队、失败、缓存命中与字段分布；真实标签到达后补充质量检查。关键分组跌破预定底线、队列持续积压或内存异常时，切回已验收配置并处理缓存。上述数值均为原型目标，正式服务需结合业务损失与代表性负载重新确认，结论附带测量边界和适用流量范围。

10 小结：下一步MoE（A46）

推理优化从明确约束开始，以可复测的结果结束。算子融合减少部分执行开销，量化改变数值表示，投机解码优化生成过程，批处理与缓存改善请求组织和重复工作。每项收益都需要同时接受质量、延迟、吞吐与资源成本的检查。

下一步进入 MoE（A46），把问题从“怎样更高效地执行现有计算”推进到“每次输入选择哪些计算”。继续保留相同的证据习惯：固定比较条件，检查关键分组，并让服务拥有可执行的回退路径。