交付第一份 AI 系统运行报告

把分散的正确答案，放回同一个系统

你的团队在一个共享平台上做两类工作：离线训练需要可以恢复的状态，在线生成需要在质量与时延约束下处理请求。现在训练被中断，服务输入变长，平台仍只有四张卡。你要交付一份运行报告，说明哪些结论已有证据、哪些仍是假设，以及下一步怎样验证。报告的价值是别人能重复你的判断，而不是把十二课术语写进一张架构图。

核心实验不要求 GPU。本课程的线性回归在 CPU 上真实更新参数；调度与请求记录是明确规则下的合成实验；四卡安排与发布属于纸面推演。这三层证据不能互相冒充。两个参数的回归模型并不是后面 LLM trace 的生成模型；它用于验证训练状态，另一组数据用于验证服务测量方法。真实平台是否达标，仍需对应设备、模型和负载的实测。

先冻结目录、版本和预测（约 20 分钟）

下载离线实验包，解压后进入 infra-lab；需要 Python 3.11 或更新版本，无需 pip。新建自己的 runs/ 结果目录，保留 reference/ 不改。另下载运行报告模板，将命令、环境、输入文件与输出路径填在一起。网页学习记录可以导出，但不会替你保存电脑上的 JSON。

运行前记录三个预测：完整恢复是否等于连续训练；chunk 是否改善所有请求；输入变长后，原来的并发档是否仍合格。画一条包含数据、训练状态、模型制品、服务运行时、请求和共享设备的链，把测量端标清。将 CPU 实跑、合成数据和待实测项用文字标注，不能仅依赖颜色。

任务一：证明恢复了同一条训练路径（约 35 分钟）

python3 train.py --steps 19 --checkpoint runs/step19.json --output runs/step19-report.json
python3 train.py --resume runs/step19.json --steps 80 --checkpoint runs/resumed.json --output runs/resumed-report.json
python3 train.py --steps 80 --checkpoint runs/full.json --output runs/full-report.json

--steps 80 是累计目标，19 步之后再做 61 步。用完整 checkpoint JSON 比较参数、优化器、步数、样本位置、次序与 RNG。下面的比较忽略 JSON 键的排列，不忽略字段值；它只有在这份确定性 CPU 实验中支持完整相等，不能推广为所有 GPU 算子逐位可复现。

python3 -c 'import json; a=json.load(open("runs/full.json")); b=json.load(open("runs/resumed.json")); print("完整状态相等:", a == b)'

再做一个故障对照：恢复时丢掉 momentum，用 --fault drop-optimizer，在累计 31 步保存 checkpoint，与正确连续 31 步比较。可回到第 04 课了解恢复状态；31 步故障与连续对照的完整命令见 README取得。解释为什么 loss 仍下降也不能证明状态等价。若文件不一致，先查目标步数、恢复路径、配置与 fault 标签，再解释真实故障机制。

任务二：在同一 trace 中说明收益与代价（约 35 分钟）

python3 simulate.py --trace mixed --policy both --chunk 2 --output runs/mixed.json
python3 simulate.py --trace unseen --policy both --chunk 4 --output runs/unseen.json
python3 benchmark.py --scenario both --output runs/benchmark.json

用 mixed 的逐 token 时间说明 A 的最大 ITL 与 S 的 TTFT 为什么向相反方向变化。不能只报告批次总时长，也不能拿服务端执行段代替客户端排队。unseen 先手算一个请求的首字和间隔，再用结果检查；如果预测错了，把第一个不一致事件写出来。两份时间线都是虚拟设备实验，不是 vLLM 的实测成绩。

接着给 A、B 分别写有条件的运行点。默认档位约束为成功 TTFT P95≤2s、全部尝试失败率≤1%、成功质量通过率≥97%；单次合格要求成功、质量分数≥80、TTFT≤2s。注明闭合波次、完整窗口、nearest-rank 与虚构费率。复算一档的原始合格请求交集、goodput 和单位成本，避免把两项通过率相乘。

任务三：让一个原本正确的决定失效（约 25 分钟）

复制 data/workloads.json 为 runs/unseen-workload.json。只将 A/cap8 的前三个成功行改为超时：success=false、ttftSec=null、qualityScore=null、finishReason="timeout"、outputTokens=0；原始到达、结束、窗口、总成本保留。修改后先写预测，再运行：

python3 benchmark.py --scenario short --data runs/unseen-workload.json --output runs/unseen-decision.json
python3 benchmark.py --scenario both --p95-limit 0.3 --output runs/no-feasible.json

提交修改过的原始文件和 diff 说明，证明你没有通过删失败行让报告更好看。第二行会检验你能否接受“当前没有可行档位”。在无解时，写需要补什么证据、能改变什么资源或业务约束、重新验收哪些条件，不能静默放松质量门槛。

任务四：把资源和发布条件写到同一张卡（约 25 分钟）

沿用第 09 课的 N0/N1 各两张卡：t=0 为 N0[A1,C1]、N1[A2,空]；C1 在 t=10 完成，B 需要同节点双卡，计划运行 20 分钟。分别写“低峰单副本能力已验证”和“仍未验证”两条路径。前者允许 A2 用 2 分钟排空后让 B 在 N1 于 t=12 启动；后者只能保持等待或增加资源。第 08 课的合成记录不能证明 A1 真实单卡能力，所以你的报告必须保留这个未验证条件。

在允许排空的纸面路径中，t=12 的 N0 为 A1+空，可让一个新版本试验副本占用这张空卡；此时 N1 的 B 占两卡，资源已经满。写清候选制品、模板与配置不可变标识，启动/就绪/存活检查、预热、样例与受控流量、停止条件、排空和基线恢复。若 A 必须保留两个旧副本，不能凭 maxSurge=1 创建第五张物理卡。

加入一条发布扰动：新版本质量下降，而旧版在同负载正常。给出回退动作，并检查旧制品仍可取、状态兼容和恢复后的质量。再换成所有版本一起因突发流量超线，说明限流、队列与容量验证如何改变下一步。Deployment 的 Pod 模板回退不自动还原外部可变权重或配置；仅写 rollout undo 不构成完整退出路径。

交付报告，用证据状态进行验收（约 20 分钟）

将报告、输入、命令和原始输出放进一个能重新打开的目录。给每个结论标“通过、失败、未知”并附证据路径。以上六段约 160 分钟。另留 20 分钟做一次读者复查：让另一位读者，或你自己在新目录中，按报告重建一次关键实验。约 180 分钟包含这一轮复查；首次遇到环境问题可以更久，不必为了时间删掉失败记录。

CPU 恢复、逐请求复算与报告完整性是核心项目的必过项。真实设备容量、平台隔离与发布条件可以保留未知，但不能宣称已经获得上线资格。

如果想继续真实设备路径，选择一项最重要的未知，而不是同时换模型、硬件和框架。冻结第 11 课的组合清单与质量合同，在实际设备上补采端到端时间、内存、失败和恢复证据，再回到同一报告更新结论。原版长教程可用于专题深入；完成本课程的核心产出不依赖它。