训练让模型学会参数，推理让参数对新输入给出结果。把模型文件加载成功，只说明服务具备了开始计算的条件；能否在约定时间内给出可信结果，还取决于输入处理、运行硬件、请求调度、输出规则和异常处理。本课从公开数据集上的分类任务出发，再讨论生成式模型，把“算得出来”变成可以测量和预算的服务能力。
1 推理基础要建立什么
设想你用 UCI Bank Marketing 数据集训练了客户响应分类器。它读取年龄、职业、历史联系次数等特征，输出客户是否可能接受定期存款营销的分数。训练阶段根据已知标签调整参数；推理阶段固定参数，把新客户特征代入计算，再依据阈值给出类别。这里预测的是营销响应，不能直接把它叫作客户流失。若任务改成流失预测，就必须重新定义“在未来 30 天未续约”等标签、观察窗口和可用特征。
推理服务的输入不是任意表格。训练时年龄按什么方法缩放、职业怎样编码、缺失值如何填充，推理时就要遵守相同约定。模型若把“未知职业”映射到独立类别，服务却随手编码成 0，虽然仍能返回数字，含义可能已经改变。应把预处理规则、特征顺序、模型参数、类别映射和决策阈值作为同版产物交付，并记录版本。没有这组约定，快速返回也可能是在快速制造错误。
数据切分决定效果证据是否可信。练习可以采用训练集、验证集、测试集约 70%、15%、15% 的安排：训练集拟合参数，验证集选择阈值和配置，测试集只承担最终评估。如果同一客户有多条记录，要按客户分组切分；如果任务是预测未来响应，应优先按时间切分。标准化和类别编码的拟合只使用训练集。不要先对完整数据做统计，再声称测试集从未参与建模。
对正类稀少的任务，准确率往往不能独立说明效果。precision 是预测为正的样本中真正为正的比例，recall 是实际正类中被找出的比例，F1 综合这 2 项。ROC-AUC 衡量分数排序的区分能力，并不等于某个阈值下的正确率。正类很少时，还应查看 PR 曲线或 PR-AUC。报告应写清正类定义、阈值、样本量和类别比例，否则不同批次的指标很难比较。
同样的推理概念可以迁移到 CIFAR-10 图像分类和 AG News 短文本分类。前者要固定图像尺寸、通道顺序和归一化方法；后者要固定分词器、最大长度和截断规则。分类模型通常每次前向计算给出固定长度的分数，生成模型则会反复计算，逐步产出 token。token 是模型处理文本的单位，可能对应字、词的一部分或标点，不能直接当成汉字数。
因此，本课同时关心质量和运行表现：结果是否满足任务要求、请求是否按时完成、并发增加时资源是否可控。后文生成模型的时延结论不能直接套给表格分类器，但固定输入约定、隔离测试数据和测量完整链路的习惯对它们都成立。
2 前向计算、KV Cache 与批处理
前向计算就是把输入沿模型各层传递，得到输出。对于表格分类器，可以把它理解为“特征向量进入模型，类别分数离开模型”。模型参数在推理时通常保持不变，也通常不需要为反向传播保存梯度。真正部署时仍需指定推理模式，避免训练阶段的随机行为或统计更新影响结果；“没有调用训练函数”不一定等价于正确的推理配置。
自回归文本生成可以分为预填充和逐步解码。预填充处理整段提示词，建立后续生成需要的状态，并产生用于首个输出 token 的分数；解码根据已有上下文继续产生 token。生成 120 个 token 不是执行 1 次普通分类，而是包含重复的生成步骤。提示很长时，预填充可能成为首包瓶颈；输出很长时，解码累计时间往往更明显。
KV Cache 保存注意力计算中历史 token 的键和值，使后续步骤能够复用这些结果，减少重复工作。它保存的不是可以直接显示给用户的答案，也不是把所有计算结果都永久存起来。这里先掌握“用显存换取复用”即可，不需要展开注意力内部的矩阵运算。缓存开启后，计算仍需继续，显存占用也会随着活跃序列和上下文长度增长。
以常见、未压缩的 KV 存储方式作估算，缓存字节数约为 2 × 层数 × KV头数 × 每头维度 × 每元素字节数 × 活跃token总数。前面的 2 分别对应键和值；活跃 token 总数是所有在途序列已经保留的上下文长度之和。假设层数为 32、KV 头数为 8、每头维度为 128、每元素为 2 字节，那么每个 token 的缓存约为 128 KiB。不要把查询头数量直接代替 KV 头数量，实际值应查看模型配置。
若每条活跃序列保留 4096 个 token，它约需 512 MiB 缓存；16 条这样的序列合计约需 8 GiB。这只估算 KV 数据，不包括模型权重、工作区、缓存管理开销和内存碎片。实际实现还可能按块分配、提前预留空间，因此监控到的分配量与公式结果不会完全相等。公式用于解释增长趋势，真实峰值仍需测量。
批处理把多个输入放到同批计算中，提高硬件利用率。分类任务常把多个图像组成批次；生成任务还可能在某条序列结束后让新请求加入，这叫连续批处理。批次更大，单次工作能服务更多请求，但等待凑批会增加排队时间，更多活跃序列也会占用更多 KV Cache。调大批次不是免费的提速开关，应同时观察吞吐、延迟和显存。
3 解码策略与停止条件
模型输出下个 token 的分数后，还需要规则决定选哪个 token。贪心解码每步选择分数最高的候选，便于建立稳定的基线，但不保证整段回答最优，也不保证内容真实。采样则按候选概率随机选择，允许同样的输入得到不同表达。选择策略应围绕任务：固定类别判定通常不需要随机生成，自由文本表达则可能接受适度变化。
temperature 调整采样分布的集中程度，较低值通常更集中，较高值通常更分散；top-p 按累计概率限制候选集合。它们影响的是输出选择方式，不是知识更新开关，更不能理解为“准确率旋钮”。不同服务对边界值和默认值的处理可能不同，实验中应保存最终生效的参数。建立基线时固定采样配置和随机种子，有助于定位差异，但仍不能承诺跨硬件、跨运行库完全逐位一致。
对于 AG News 这样的短文本分类任务，直接分类模型可以输出 4 个类别的分数。如果改用生成模型输出类别名，就要限定允许的标签、验证输出格式，并记录无法解析的比例。“World”和“世界”是否都算同类，必须在评估前确定。不能把解析失败的样本删掉后再计算 F1，否则部署效果会被高估。生成式分类的延迟也通常不能与固定分类头按同样的计算步骤理解。
停止条件决定生成何时结束。常见条件包括产生结束 token、命中停止字符串、达到最大新增 token 数、超过时间预算，以及客户端取消。最大新增 token 数只限制本次输出；上下文窗口还必须容纳输入和输出。提示已经占去大部分窗口时，不能再无条件申请很长的生成长度。服务应在接收请求时检查长度，给出明确的拒绝或缩减策略。
停止不等于成功。达到长度上限可能截断结论，超时可能只生成半段内容，命中停止字符串也可能发生在示例文本中。响应应保留结束原因，业务侧据此判断结果能否使用。如果任务需要完整 JSON，应进行结构校验，并约定失败后的处理。单纯把输出 token 上限调低，虽然可能降低完成时延，却也可能提高截断率，不能只报告速度收益。
评估应把解码参数与模型版本绑定。可以固定 200 条验证输入，对同套参数记录宏平均 F1、格式通过率、平均输出长度和 p95 完成时延。宏平均 F1 对各类别的 F1 等权汇总，有助于发现少数类别被忽略。选择配置后再用保留的测试集报告效果；不要用测试集反复挑选 temperature 或提示词。对于自由问答，还需单独设计内容正确性评价，分类指标不能替代所有质量判断。
4 动手：测量一次首包与生成时延
本节测量客户端可见的流式生成过程。选择已经能正常运行的文本生成服务，准备固定长度的短文本分类提示，要求输出类别和简短依据。把输入 token 数、最大新增 token 数、模型版本、精度、批处理配置和硬件型号写入实验记录。初次加载权重、初始化计算库等属于冷启动；正式比较前先完成预热，并将冷启动结果另行报告。
记录 3 个时间点：发出请求前的 t0、收到首个非空生成内容时的 t1、收到完成事件时的 t2。首 token 时延 TTFT 约为 t1-t0，端到端完成时延为 t2-t0。HTTP 响应头、心跳或空字符串不能算首个生成内容。严格的 TTFT 需要确认事件对应首个 token；若客户端只知道首个文本块，应把指标标成“首个非空内容时延”，避免把分块协议当成分词结果。
下面用适配器伪代码表达测量边界。stream_generate 需要对接已有服务，把协议事件统一成内容事件和完成事件；它不是可直接调用的通用库接口。计时采用单调时钟，防止系统校时影响差值。正式实现还要处理超时、连接错误和用户取消。
from time import perf_counter
start = perf_counter()
first = None
finished = None
output_tokens = None
finish_reason = None
for event in stream_generate(prompt, max_new_tokens=120):
now = perf_counter()
if event.kind == "content" and event.text:
if first is None:
first = now
if event.kind == "done":
finished = now
output_tokens = event.output_tokens
finish_reason = event.finish_reason
result = {
"first_content_s": None if first is None else first - start,
"completion_s": None if finished is None else finished - start,
"output_tokens": output_tokens,
"finish_reason": finish_reason,
}假设客户端在 0.80 秒收到首个内容，在 3.18 秒收到完成事件，服务报告生成了 120 个 token。如果首个事件恰好携带 1 个 token，可粗略估算后续平均每 token 时间为 (3.18-0.80)/(120-1)，即约 20 毫秒。若文本块内含多个 token、完成事件明显滞后，这个值就只能作近似；要测真正的逐 token 间隔，需要服务提供更细的事件或内部时间戳。
先在并发 1 下执行固定样本，再逐步测试并发 4、8、16。每档使用相同输入集合，保留每次请求的长度、时间、状态与结束原因。正式比较可安排每档 200 次请求，并承认这些样本对极端尾部的估计仍有限。把 p50、p95、错误率和成功请求数一起报告，不能只展示最快的 1 次，也不能把超时请求当成缺失数据从报表里消失。
客户端时延包含网络和服务端排队；设备上的纯计算时间只是其中部分。若结果波动，应结合服务端排队时长、活跃请求数、显存峰值和计算利用率判断。对 CIFAR-10 分类服务则改测完整批次或单请求的完成时延，无需强行制造首 token 指标。测量边界跟着输出形态变化，方法仍是先定义事件，再记录时间。
5 吞吐与尾延迟取舍
吞吐表示单位时间完成多少工作。分类服务可以用每秒完成的样本数或请求数；生成服务常报告每秒输出 token 数，也应同时记录每秒完成请求数。输入长度和输出长度会改变工作量，因此“每秒 50 个请求”只有在负载分布明确时才可比较。把输出从 120 个 token 缩到 20 个以后吞吐上升，不能直接归因于硬件更快。
延迟描述单个请求等待多久，尾延迟描述较慢请求的体验。p95 为 2 秒，表示约 95% 的已计入请求时延不超过这个值，并不代表所有请求都在 2 秒内完成。p50 很好而 p95 很差，可能意味着少量长输入、调度等待或资源竞争拖慢了部分请求。若超时单独统计，应清楚说明分位数基于成功请求，并把超时率与它并列。
批处理常带来吞吐收益，但要付出等待成本。对低流量分类服务，为凑满 32 张图而等待 100 毫秒，可能超过计算本身的耗时。对生成服务，更多活跃序列可能让设备保持忙碌，却拉长每条序列的 token 间隔。用户可能更在意首个内容尽快出现，也可能更在意整段结果按时结束，应分别设定目标，不能用单个“响应速度”替代。
考虑一组仅用于说明的假设实验：批次上限从 4 提高到 16 时，输出吞吐由 220 提高到 510 token/秒，p95 完成时延从 2.6 秒升到 4.6 秒；提高到 32 后，吞吐只到 550 token/秒，p95 却升到 8.4 秒。这些数字不是任何硬件的承诺。它们说明应寻找满足延迟目标的工作区间，吞吐最高点未必适合在线交互。
还要区分并发上限、活跃批次上限和排队上限。客户端同时发来 100 个请求，不意味着设备必须同时保留 100 条序列的缓存。服务可以限制活跃请求，把其余请求放入有界队列；队列满时按约定拒绝，避免无限等待。有界队列也会把容量不足直接暴露为拒绝率，因此容量报告必须同时呈现被拒绝的请求，不能只计算已接收请求的漂亮延迟。
压力测试应记录请求到达方式。若每个测试客户端必须等上次响应结束才发下次请求，系统变慢时发压速率也随之下降，容易掩盖排队恶化。可以补充按固定到达速率发请求的实验，并明确超时和队列上限。在相同负载下，比较同时满足质量、p95、错误率与显存余量的配置，才能决定服务实际可承诺的容量。
6 常见坑：把训练算力直接当推理算力
训练和推理共享模型结构，但工作方式不同。训练通常包含前向计算、反向传播和参数更新，还可能保存梯度与优化器状态；推理一般不需要这些状态，却可能需要保存大量在途生成请求的 KV Cache。训练能用某张卡跑通，并不能证明它可以承受目标并发；训练时显存很紧，也不能直接证明固定批次分类推理一定放不下。
峰值算力是硬件在特定条件下的能力上限，服务速度还受数据搬运、算子支持、输入长度、批次与调度影响。小批次生成的某些阶段可能更受权重读取和缓存访问限制。这里不必先学复杂的硬件性能模型，只需拒绝“峰值算力翻倍，端到端延迟就减半”的直接推断。应在实际模型与负载上测量，说明测量使用的数值精度和运行配置。
降低权重精度可能减少权重占用，但不会自动按相同比例降低所有内存。KV Cache 的精度、计算工作区和运行时预留可能保持原样。精度改变也可能影响分类分数和生成结果。对营销响应分类器，应检查固定阈值下的 precision、recall 和 F1 是否变化；对类别不均衡的数据，还要查看各类别指标，避免总体变化很小却漏掉关键少数类。
另一个常见错误是把离线评估好看归因于推理平台可靠。例如 Bank Marketing 中的通话时长 duration 发生在通话之后；如果目标是在拨号前决定联系谁，该字段在决策时不可用，使用它就是信息泄漏。即使测试集分数很高、推理也只需几毫秒，实际业务仍无法复现该效果。应按决策发生时刻审查每个特征，不能只检查训练与测试文件是否分开。
类别不均衡和分布变化也会改变服务表现。营销响应正类很少时，全部预测为负也可能得到较高准确率；文本来源从规范新闻变为口语短句时，原有 F1 可能下降。图像从清晰照片变为低照度拍摄时，输入尺寸不变也不代表数据分布没变。部署后要记录可用的标签反馈、输入统计和类别分数分布，并在新标签足够后重新评估，不能把漂移告警本身当成准确率已经下降的证据。
排查时把性能与质量放在同份记录里。配置变化后，先确认输入、预处理、阈值和模型版本是否一致，再判断速度收益。如果为了提速截断了更多文本，要同时报告截断比例和质量变化；如果批次变大后发生显存错误，就回到资源模型。这样才能区分“计算配置更合适”和“任务悄悄变简单了”。
7 案例：KV Cache 撑爆显存
某团队在 24 GiB 显存的设备上部署文本生成模型。模型权重加载后约占 14 GiB，运行时与工作区计划占 2 GiB。单请求生成很顺畅，于是把活跃序列上限直接设为 32。短提示的试运行看起来正常，但一批包含长新闻材料的请求进入后，显存分配失败，部分请求报错。重启服务只能暂时恢复，因为输入长度与并发条件没有改变。
团队起初怀疑权重加载有泄漏。观察却发现，固定并发、增加上下文长度时显存持续升高；固定长度、增加活跃序列时也升高。停止接收请求并等待在途请求结束后，活跃缓存块减少，但运行时可能保留已经申请的显存池，因此设备监控中的占用不一定马上降到初始值。不能只凭“显存没有归零”判定泄漏，还应查看实际活跃缓存与可复用块。
沿用前面的假设模型，每 token 的 KV 数据为 128 KiB，每条 4096 token 序列约需 0.5 GiB。32 条序列约需 16 GiB 缓存，再加 14 GiB 权重和 2 GiB 工作区，合计约 32 GiB，明显超过 24 GiB。即使降到 16 条，总估算也已达到 24 GiB，没有留出管理开销、瞬时工作区和碎片的余量，仍不能作为安全的上线配置。
这里的 4096 应表示每条序列当前保留或按策略预留的总上下文，包含输入与已经生成的 token。只按输入长度估算，会遗漏生成期间继续增长的缓存。如果请求输入为 3800 token，还允许新增 1000 token，就不能用 3800 作为整个生命周期的峰值。服务应同时约束输入长度、最大新增长度和总上下文，并了解运行时究竟按实际长度增长还是提前预留。
修复从可验证的限制开始：先把活跃序列上限设为 8，对总上下文设置明确边界，给等待请求使用有界队列。按最坏 4096 token 估算，8 条序列约用 4 GiB KV 数据，权重与工作区合计后约为 20 GiB，剩余空间仍要通过压力测试判断是否足够。输入过长时明确拒绝或进入经过评估的截断流程，不能悄悄删去关键材料后继续承诺原有质量。
回归实验应混合短、中、长输入，并覆盖集中到达、生成到上限、客户端取消和异常结束。观察请求结束后缓存块能否复用，同时记录 p95、拒绝率和显存峰值。降低并发可能增加队列等待，因此修复标准不能只有“不再报显存错误”。应确认质量未受输入策略破坏，延迟与失败率也处于预算之内，再逐步提高活跃上限。
8 把推理预算写进服务方案
推理预算应从用户动作开始描述。比如研究人员提交新闻文本，希望先看到响应，再获得类别与依据；另一个程序提交 1000 张图片，希望批量任务在约定时间内完成。这 2 种服务的目标不同。前者要定义首个内容和完成时延，后者更关注总完成时间、单位时间处理量以及失败重试。先明确交互方式，再决定哪些指标值得承诺。
负载假设要足以复现实验。新闻分类服务可以声明输入长度分布、最大输入长度、输出上限、请求到达速率与峰值持续时间；表格服务则声明每请求样本数、特征数量和缺失值比例。平均输入长度不够，因为少量长请求可能占据大量缓存。可分别列出中位长度、p95 长度和允许的最大值，并用代表这些区间的固定样本构造压测集合。
质量预算和资源预算要联动。以 AG News 为例，可以约定测试集上的宏平均 F1 门槛、各类别召回率检查，以及生成输出的格式通过率。对于营销响应任务，可根据漏掉正类与误报的代价设定 recall 下限和 precision 目标，再确定阈值。这里的门槛应来自任务要求与验证证据，本课的演示数值不应直接变成业务承诺。数据切分方法和标签版本也应随报告保存。
服务指标可以写成可检查的条件，例如“在指定到达速率、输入长度分布和输出上限下，成功请求的 p95 首个内容时延不超过 1.5 秒，p95 完成时延不超过 5 秒，并单独限制超时与拒绝率”。这些是待验证的示例目标。若只写“平均延迟低于 5 秒”，可能掩盖长尾；若只写“成功率高”，又无法判断超时、格式错误和模型错误分别占多少。
资源部分应分开列出权重、KV Cache、工作区及预留空间的估算，并说明估算依据。记录活跃序列上限、排队上限、超时、最大上下文与输出上限，服务才能在需求变化时重新计算。预算同时需要观测入口：客户端记录整体体验，服务端记录排队与计算，设备监控记录显存和利用率。只盯设备利用率可能错过用户已经排队很久的事实。
最后明确越界行为。流量过大时是有界排队还是拒绝，长输入是否允许截断，超时后是否取消服务端计算，都要写清。重试应有次数上限并避免同时重试造成更大拥塞。模型或运行配置更新时，保留旧版结果和回退路径；若新版本吞吐提高却让少数类别 recall 跌破门槛，应停止扩大使用范围。这样推理预算才是可执行的服务约定。
9 从推理基础走向昇腾 NPU（H34）
理解推理以后，再看昇腾 NPU，问题应从“它有多少算力”转为“这个模型在这组约束下能怎样运行”。NPU 是面向神经网络计算的处理器类别。本课不讨论其内部执行结构、专用存储或底层调优；下一课关注模型如何被支持的工具链接收、哪些操作可用，以及如何得到可比较的测量结果。硬件名称本身不能代替模型适配证据。
迁移的首要材料是模型与输入契约。保存模型版本、输入形状、数据类型、预处理流程和参考输出。CIFAR-10 分类器应准备固定图像与类别映射，明确通道顺序；表格分类器应保存特征顺序与类别编码；生成模型还应保存分词器、提示格式、解码参数和上下文限制。漏掉其中任何部分，都可能出现“文件转换成功，预测含义却变了”的问题。
接着确认运行范围。某些模型包含目标运行环境暂不支持的操作，某些输入形状需要额外适配；动态批次和可变长度也不能默认与原环境完全一致。应先验证最小输入能完成正确推理，再扩大到真实形状和批次。出现不兼容时，记录具体操作、输入形状和报错位置，把它作为适配问题处理，不要直接推断整个处理器类别不适合该任务。
正确性检查应先于性能比较。对固定分类样本，比较参考环境与目标环境的分数差异、类别一致率，以及完整测试集的 precision、recall、F1 或 AUC。浮点误差可能使临近阈值的样本改变类别，所以少量分数差异也需要结合任务判断。生成模型可先固定解码条件检查格式与任务结果；跨实现得到逐字相同的文本并非所有任务的唯一验收标准。
性能比较要保持测量口径一致。相同模型版本、相同输入集合、相同输出约束、相同质量门槛，是讨论收益的基础。预处理与数据传输是否计入、是否预热、并发怎样施加，都应写入记录。可以同时报告设备计算时间与客户端端到端时间，让读者看清瓶颈是在计算、输入处理还是排队。不要把某平台的纯计算时间与另一平台包含网络的总时间直接比较。
带着本课的预算进入 H34，就有了清楚的实验顺序：先跑通固定样本，再验证任务效果，随后测量长度与批次变化，最后检查持续负载下的尾延迟和资源峰值。如果目标环境的最优批次不同，就重新寻找满足原服务约束的配置。可迁移的是输入契约、指标定义、测量边界与资源估算方法，具体的性能数字必须由目标环境重新给出。
放进方案里
在方案中为推理服务单列输入契约、质量门槛、负载边界和越界行为。以 AG News 短文本分类为例，声明类别映射、文本清洗、分词器版本、最大输入长度，以及超长文本的处理方式。公开训练集内部按 85%、15% 划分训练与验证数据，保留官方测试集作最终评估；先检查重复内容，避免相同文本跨集合出现。用验证集选择阈值或生成配置，再报告测试集宏平均 F1、各类别召回率与格式通过率。
对需要生成依据的接口，写明模型版本、输出上限与停止条件，并区分首个非空内容时延和完整结果时延。压测记录输入长度分布、到达速率、活跃序列上限和排队上限，在相同负载下报告 p50、p95、完成吞吐、超时率与拒绝率。示例目标可设为 p95 首个内容不超过 1.5 秒、p95 完成不超过 5 秒，但这些数值必须经目标设备实测后才能承诺。
资源表分列模型权重、KV Cache、工作区与预留空间，按最大总上下文估计峰值，并用混合长短请求验证。队列满时明确拒绝，客户端取消后释放对应计算与缓存，重试设置次数上限。不要通过静默截断来换取表面上的达标；如果调整输入策略，应重新验证分类效果。验收附件保留达到输出上限、命中结束标记和取消请求的记录，逐项核对结束原因、结果完整性及缓存回收；分类标签无法解析的请求必须计入格式失败。
上线后按版本保存样本、延迟、结束原因和资源峰值，结合标签反馈检查类别不均衡与分布变化。更换硬件、数值精度或运行库时，先完成正确性回归，再做同口径压测；只有质量、尾延迟和资源余量同时满足约定，才扩大使用范围。为不达标的配置保留回退步骤，让服务预算能够指导实际操作。
10 小结：下一步昇腾 NPU（H34）
推理是固定参数对新输入执行计算的过程。分类任务通常经前向计算输出分数；自回归生成还包含预填充、反复解码和停止判断。KV Cache 减少重复计算，也让上下文长度与活跃序列数成为显存预算的重要变量。吞吐、首个内容时延、完成时延和尾延迟应在固定负载下共同评估。
进入 H34 前，可以用 3 个问题检查自己的方案：为什么相同权重在单请求正常、并发时却会显存不足？为什么批次变大可能吞吐提高、p95 变差？为什么测试集 F1 很高仍不能保证部署有效？如果能分别从缓存增长、排队与资源竞争、数据泄漏及分布变化解释，就已经具备用可测量证据讨论推理平台的基础。