用原始请求记录选择运行点

同一份报告，为什么能得出两个“最快”结论？

你拿到两个候选配置。一个显示更多 tokens/s，另一个成功请求的 P95 更低。追问才发现，前者输入更短，后者删掉了超时，费用都按全部成功请求计算。三个数字都可能算对，却没有回答你的业务问题。选运行点之前，先约定一次请求怎样算完成，什么输出算合格，以及测量包含哪些等待和费用。

这一课会从可以下载的逐请求记录重算结果。你要学会两种不同判断：单次请求是否合格，和一个档位是否可上线。单次 TTFT 门槛筛的是具体请求；P95 上限验收的是整个成功分布。它们可以取相同数值，但含义不同，不能共用一个不清楚的输入框。

先冻结协议，再改并发

真实基准至少固定模型与权重版本、tokenizer 与模板、精度与量化、设备和运行时、输入/输出长度分布、生成停止条件、warmup、缓存状态、到达过程、窗口、质量评估以及费用边界。若同时改模型、长度和并发，你无法把收益归给某个机制。前缀缓存预热后的结果也不能直接代表冷请求。

到达过程尤其容易漏掉。固定批量/闭环提交有限数量的请求，完成后再补入；设备变慢会反过来减少新请求的进入。开放到达按外部规定的速率到达，服务变慢后队列可能继续增长。一个闭合批次很快跑完，不证明更高持续到达率下系统稳定。两种方式都可以有用途，但报告必须分别命名。

本课 A/B 是合成的固定 100 次尝试、闭合波次：提交至并发上限，等本波全部结束或超时，再提交下一波。A 为 80% 短输入 256 tokens、20% 输入 2048；B 为 60% 输入 256、40% 输入 4096；成功输出固定为 40 tokens。各档的完整观测窗口从开始到最后结束，改变验收门槛时窗口不变。虚构成本率统一为 0.001 元/s。这些数据说明统计方法，不能作为 GPU 或云价格基准。

保留原始行，联合条件才能重新计算

每一行有 id、输入/输出 token 数、arrival、end、success、ttftSec、qualityScore 和结束原因。失败没有首 token 时，TTFT 为空，而不是 0s；若首字后才失败，也仍算一次失败。质量分数在这里是人工构造的 0–100 数值，默认达到 80 通过；它没有自动评价真实 LLM 文本。

成功 TTFT P95 先将成功行排序，再取第 ceil(0.95×成功数) 个；全部尝试的失败率=失败数/尝试数。成功质量通过率=质量通过的成功数/成功数。联合合格数则逐行检查：success=true、qualityScore≥分数门槛、ttftSec≤单次 TTFT 门槛。不能把几个比例相乘，因为质量与时延可能关联。

超时删掉以后，成功分布仍然好看，但“失败率为零”就是假的。没有成功样本时 P95 和成功质量比例未定义；没有联合合格请求时单位合格成本未定义。窗口里还在等待的请求也不能悄悄漏掉：应等待它们结束/超时来闭合这份实验，或另行明确报告未完成数和删失统计，本课计算器选择前一种方式。

两个层次的条件，分别动手修改

下载全部 800 行原始请求 JSON。A/cap8 有 99 次成功，其中 97 次质量通过；95 条成功 TTFT 不超过 2s，但一条同时质量不通过，因此联合合格数为 94。成功 P95 是第 95 个值，1.4s。窗口 38.24s，总成本 0.03824 元，单位成本≈0.406809 元/千次合格。

离线复算一次，再故意弄错分母

下载离线实验 ZIP，解压进入 infra-lab。浏览器与 Python 使用同一份 JSON，不能各自维护一张似是而非的答案表。README解释每项字段和命令。

python3 benchmark.py --scenario both --output runs/benchmark.json
python3 benchmark.py --scenario short --failure-limit 0 --output runs/strict.json
python3 benchmark.py --scenario short --failure-limit 0 --fault drop-failures --output runs/bad.json

第一行应得到 A=8、B=4。第二行要求零失败，只有 A/cap1 可行。第三行故意删除失败记录，cap8 的尝试数从 100 变成 99、失败率被伪造为零，因此错误入选。保留 fault 标签，用这个对照说明为什么“统计前过滤错误行”会改变结论。调低失败门槛是业务约束，删行是数据损坏，两者不能混用。

若浏览器与离线结果不同，先比对数据版本、qualityMinimum、deadline、分位算法、单位与失败分母，再看取整显示。若 cap4 的质量显示 97.98%，它实际是 97/99；不能仅用四舍五入后的 98% 判断一个严格的 98% 下限。

把一个并发数字，写成有条件的决策

1. 冻结协议。写清观察端、100 条固定批次的到达方式、质量分数和成本边界；指出这份实验为何没有证明开放流量的稳定容量。
2. 陌生故障。复制 JSON，将 A/cap8 的前三个成功行改成超时，保留到达与结束、窗口和成本。先预测失败率，再按 README 的自定义 --data 命令复算。
3. 写决定。提交负载、约束、被排除档位、逐行合格定义、单位成本计算及复测触发条件。若无解，说明需要补哪些证据或改变哪些资源，而不强选最低价格。