先画系统，再定义快慢

先画出任务经过的系统

你负责一套模型系统。训练报告说每秒样本数提高了，客服却说回答更慢；平台监控显示 GPU 很忙，错误率也在上升。三个观察都可能是真的，因为它们观察的对象不同。先别把它们合成一句“性能变好”或“设备不够”。这门课从任务路径开始：谁在提交工作，哪些状态要留下，哪个结果才算完成？

训练用数据计算输出和损失，再通过反向传播与优化器更新参数；反复更新后得到可交付的模型状态。推理用已经确定的参数处理新输入，生成结果，通常不进行梯度更新。二者都会执行设备计算、读写内存、等待数据或通信，但训练要关注学习质量与恢复进展，在线推理要关注每个请求的等待、失败和输出质量。

沿图中的路径，把系统分成四层看：设备层决定计算、内存与传输的限制；训练层处理数值、数据和并行更新；推理层管理请求状态、调度与容量；平台层管理资源、版本、交付和故障。后面的单元按这个依赖顺序展开。你现在不需要背出所有产品名字，先能把一个异常放回正确的任务路径。

从客户端时间轴定义“慢”

用户先等第一段内容，再看后续内容是否连续。对一次流式请求，记客户端发起时刻为 t₀，第一次有效输出到达为 t₁，后续输出到达为 t₂…tₙ，结束时刻为 t_end。首字时延 TTFT=t₁−t₀，端到端时延 E2E=t_end−t₀。本课把相邻输出 token 的到达间隔称为 ITL；若一个网络事件带来多个 token，就要注明你实际记录的是事件间隔。

TTFT 包括客户端路径、排队、处理输入和首次生成等阶段，具体边界由采集点决定。引擎内部的 prefill 时间只是其中一部分。服务器日志与客户端日志可以一起帮助归因，但不同机器的时钟未经校正时，不能直接相减。一次请求的首字已经到达，后面遇到长暂停不会改写历史 TTFT；应检查 ITL、输出长度和 E2E。

同一份 trace，要保留不同的分母

先定义一次“尝试”：本课以客户端发起的一次请求为单位；重试会成为另一次尝试，因此还应保留原始业务请求 ID 来识别重试。定义成功也要完整：收到 HTTP 成功码但生成流中途断开，不属于本课的完整成功。超时请求可能根本没有首 token，这时 TTFT 是缺失，不是 0s，也不能当作一个漂亮的成功样本。

下面是固定 10s 窗口的 10 次尝试，所有结果都已收齐，窗口内不留下未知的在途请求。质量通过表示满足预先确定的量表，合格则要求完整成功、质量通过、单次 TTFT≤1s同时成立。全部数值是教学构造，用来演示统计方法，不代表任何引擎性能。

P95 是排序位置，不是最慢 5% 的均值，也不是对下一位用户的保证。只有 8 个成功样本时，它正好等于最大值，仍不足以支持稳定的尾延迟结论。实际报告应写明分位算法、样本数、窗口、成功条件和失败分母；不同工具的插值方式可能给出不同数值。

删除 R9、R10 后，成功延迟分布的 P95 仍是 2s，但你会把“成功请求中失败率为零”错写成“服务失败率为零”。另一个错误是把训练 samples/s、输出 token/s 和合格请求/s 放在一起排高低。它们的单位和验收对象不同；更长的回答能提高输出 token 数，却可能让用户完成一次任务更晚。

把监控数字变成能复查的实验

本课的浏览器实验是逐行读 trace、复算和改条件；它不请求模型 API，也不需要 GPU。先在纸上或笔记中复算上表，再只把单次门槛从 1s 改为 0.5s。R5 本来质量不合格，门槛变化不会修复它；R6 则因为 0.8s 超线退出。新的合格数是 4，goodput 是 0.4 次/s，单位合格成本是 5 元/千次。失败率与成功分布 P95 都保持不变，因为原始请求结果没改。

如果你的计算不同，先检查三件事：是否把“≤”写成“<”；是否把质量失败的 R5 算进合格；是否将失败请求加进成功延迟排序并用 0 替代缺失。不要急着调整模型参数，统计口径错误会让下一次性能试验从一开始就比较错对象。

准备真实测量时，先固定模型和版本、输入/输出长度分布、到达过程、超时策略与窗口。先预热再采集，记录是否存在前缀复用；热缓存与首次加载的结果回答不同问题。开放到达负载按计划持续发请求，闭环客户端则等待上一次结束后再发；后者会随服务变慢自动降低到达率，二者不能只凭一个“并发数”互换解释。

最终保留逐请求 ID、起止和流式时间点、结果状态、质量判断、输入/输出长度以及条件清单。汇总数可以重算，丢掉的失败与时间戳通常补不回来。第 08 课会在更大的 trace 中同时筛选质量、时延、失败和成本，现在先确保这张小表能被别人复算。

交付：一张系统地图与指标卡

1. 画路径。任选训练或推理任务，画至少四个步骤，标出数据、设备、输出与失败点。说明你在哪个点采样，不能只写“平台监控”。
2. 复算表格。记录原门槛与 0.5s 门槛下的 P95、失败率、联合合格数、goodput 和成本。每个比值写明分子、分母和单位。
3. 设计反证。“GPU 很忙所以用户一定很快”需要什么额外证据？写出至少一个能够推翻这句话的请求结果或时间线。