数据生产卡点与提效进展 · 吞吐诊断

当前先解决“没有在生产”

最近已验证库存仍为 96 来源、1,190 行、477,235 有效 token；最近一批 10,901.50 token/h 是历史完整产率，不能表述为现在正在生成的速度。03:03 派发的 Flake8 工程操作在 03:33 返回 TARGET_TIMEOUT，说明等待回传超期，不能据此判执行停止或失败；应按已有收据与原回合对账，不重派同一修复。

建议顺序：交付当前工程补丁与已有测试结果 → 明确一次实容器资格验收的范围 → 建立新有界试生产窗口并计完整墙钟。自动汇总已能在约 0.14 秒内读取结果，逐批 Agent 汇报不再是必需阶段；此时继续优化亚秒派发或清理未经确认的空闲进程，不能补出可运行的新批次。

此前本会话误停共享服务增加了恢复工作，02:46 的恢复收据已闭环；不把该清理计为已证实的提速。当前结论依据只读账本、工程收据与资源快照；未新开生产。详细本地证据：storage/audits/e2-throughput-diagnosis-20261104/current-status.json。

历史五批对照：产出变化与等待分开看

完整耗时＝验收收据的结束时间−开始时间；有效产率＝Σ verified_releases[].effective_tokens × 3600 ÷ 完整耗时；求解槽利用率＝Σ solve.execution_seconds ÷ (2 × 完整耗时)。阶段耗时互相重叠，不能相加当墙钟，槽利用率也不是 GPU 利用率。

b01 比恢复四题少耗 101.7 秒，但有效 token 少 60.2%，主要是产出减少。medium→high 完整产率升 2.76%，且 high 的 84.6% 有效 token 来自单一来源，不能据此判断模型优劣或稳定提速。来源、窗口与部分策略不同，这五批不是受控对照，也并非每批都更换策略。

三项主要损耗，按优先级处理

1. 启动、工程与恢复占用完整墙钟

   证据：GLM high 完整 2,794 秒，其中首个执行作业创建前 1,959.8 秒，占 70.1%；首个创建到最后一个作业结束仅 402 秒。工程实现跨度 1,138.9 秒、公开 probe review 跨度 946.7 秒，二者可重叠。medium 一次准入失败到重新提交同一来源间隔 613.1 秒。

   动作：在下一获授权的对照窗口固定 producer、教师策略、预算与准备脚本，连续两批只更换来源；分别记录选题→冻结选择、冻结→首个执行作业、环境就绪→批准、批准→finish 提交。批准可与镜像拉取并行，资格硬门不变。

   验收看启动段是否可复算、批准等待是否减少。准备驱动的 ready_to_finish_submit_seconds 从环境、批准等条件全部就绪才计时，不含等待批准；不能用约 1 秒的提交延迟代表全部准备成本。控制面遍历历史收据的成本尚未证明是主瓶颈，先测 tick 时长。

2. 超时与质量失败消耗求解和请求

   证据：旧 stability b02 两个来源各求解约 320.5 / 325.6 秒后记录 pi-ai stream idle timeout after 300000ms，合计占该批求解执行时间 79.36%。high 的质量失败来源消耗 18/45＝40% 正式请求，贡献 0 有效 token。

   动作：后续 budget_proxy 已有传输修复，GLM medium 报告未再次出现该超时；下一步验证修复后的稳定性、终态记录与既有对账恢复是否闭环，保留 infra-invalid 与质量失败分类。不能把旧超时继续写成尚未修补，也不能以增加超时或请求预算替代终态诊断。

   验收看真实超时是否复发、失败是否有完整执行与用量收据、恢复是否沿原身份续接。质量失败仍可能零产出，不设“同源必有产出”或无依据的转化率保证。正常失败与网络观测异常分开处理，不笼统要求所有失败都继续派发。

3. 局部后处理排队，需要补齐归因证据

   证据：b02 一个 postprocess 排队 586.1 秒，两项合计 603.8 秒，实际执行仅 51.1 秒。该批最大 ready→submit 为 83.2 秒，其余四批最大仅 0.92–1.01 秒；提交响应不是普遍的首要瓶颈。

   动作：先补齐对应资源门、可用内存和暂停区间，再决定是否在现有执行容量内让 finish、后处理、准入优先于新准备；不增加求解数。Coordinator.claim 统一计入 max_jobs 并按 created,id 领取，内存门为 free_mb = available_mb − Σ未释放作业 − floor，这些是候选机制，尚不能证明 586 秒全由共享槽造成。

   验收要求逐段解释排队与暂停，若调整优先级，验证轻量阶段等待减少且求解不新增饥饿。五批求解槽利用率仅 5.72%–20.42%，本诊断没有扩槽依据；这也不能替代对具体资源门的核验。

当前自动准入约定

prepare → solve → postprocess → automatic-admission；异步抽检走独立队列。五批均记录 semantic_review_of_all_decisions=false，逐题 Agent Review 不是这组记录的串行阻塞点。

来源、家族与近重复隔离、公开 probe、真实执行、独立官方判分、去重、token 对齐、角色与 loss mask 硬门继续保留。输入、工具观察与 P2 学生前缀不监督；监督边界不确定则待处理。抽检缺席或超时不阻塞其他正常来源自动发布；未抽检不写成已语义审查，确认问题沿原撤销入口保留更正链。

批次身份须冻结并匹配：来源、producer 源码、教师与学生策略、预算、配置及准入策略等变化，均按既有绑定规则判断是否使原 P0 失效；需要时取得新冻结身份和 P0 收据。e2_queue.start 会复用 campaign 的冻结 acceptance 执行 --validate-only，不是每来源重做 P0；也不能把“只有源码变化才需 P0”当通用规则。

旧批次按原协议与原收据解释。正式执行使用当前请求授权和显式来源、时间上限；本页不提供默认生产命令或恢复授权，不改变暂停状态。工程通过、真实准入与训练收益分别取证。

证据口径与追溯

本页保留五批收据的诊断数字，不更新库存、不新增实测、不重跑生产。完整墙钟包含所选窗口内的准备、工程修复、等待和收尾；工程调用单列，不计有效监督产出。恢复窗口与原六题完整链路的差异必须保留，阶段累计时间不冒充墙钟。