数据生产卡点与提效进展
双机各两个 worker 已投入运行。首条真实求解与独立判分已完成，后续按最多 8 个来源的小批次继续生产。
01 · 时间与产出损耗发生在哪里
窗口：2026-11-01 09:56:58Z 至 11-02 02:46:28Z；事件截止 1421。暂停后的时间不计入速度。
从触达到入库
113 条在模型调用前阻断。156 次启动中，154 条有结果，另有 jupyter 旧中断和 puremagic 未知终态。有效判分 115 条中，47 条拒绝；67 条通过 judge / probe / alignment 后，31 条在完整语义审查后隔离。
各阶段耗时
准备占用车道执行会话的串行时间。各阶段跨任务重叠，不能将这些分位数相加为墙钟。Judge 与 alignment 的常见时延较短。
执行组织仍有大量空隙
Lane B 在最后 10.55 小时没有新启动，仍有 1,129 条 pending。原因未确定，不能归因于 OOM 或驱动死亡。常驻调度、阶段状态与超时可见性针对这一运维缺口。
学生数据供给不足
| 组 | 尝试 | prefix 截止 | 完成 | 入库 / tokens |
|---|---|---|---|---|
| P2 | 12 | 9 | 2 | 1 / 2,408 |
| P3 | 12 | 12 | 0 | 0 / 0 |
P2 另有 1 条预算耗尽。新策略可按有效监督产出选择 P2/P3，并保留有限探索；它不修复 15K prefix 上限，也不改变自然接管规则。修改协议需要新 run。
02 · 当前多机业务接线
阶段由持久 SQLite 控制器接续；Windows 保留执行和发布权威，Mac 接收经过筛选并绑定 hash 的审查材料。
每 lane 最多 1 条准备、全局资格数受限；双机均为 max_jobs=2，并各运行两个独立 worker。是否启动仍由实时余量和未释放预留决定。
先落盘 intent，再派发；固定幂等键。执行不明则停止派发并留待对账，不能用新会话重复付费。
E2 halted 或框架 paused 都禁止新生产作业启动。Agent 完成只说明传输闭环，原独立准入才决定 admitted。
机械层此前已通过双机探针；本轮增加池转换、产物传递和发布回写。新业务流的生产作业仍为 0，不能把测试通过称为生产加速。
03 · 持续维护的卡点台账
固定编号，不因改名或状态变化重建条目。展开查看事实、实现和下一步验收。
04 · 已验证到哪一层
| 层次 | 证据与范围 | 结论 |
|---|---|---|
| 队列与调度 | 预领、全局准备容量、独占 owner、幂等提交、重启、暂停、负向阻断、超时状态 | 隔离 CPU 测试通过 |
| 六阶段传输 | 真实本地 HTTP coordinator、worker 子进程、artifact 上传 / 下载 / SHA 校验；模型与业务结果为合成样本 | 链路通过，不代表真实模型通过 |
| 独立审查导入 | 原 packet / 源 hash、精确 Lody session / user turn、机器与角色绑定、完整审查 flags | 错误身份与不完整结果被拒绝 |
| 发布加载 | 既有正向测试：合成非空监督 → release → 隔离 SQLite → 真实 CPU Arrow；复用已安装 datasets | 原发布门仍可用 |
| B07 阶段资源观测 | 资源 5 项、worker 46 项、控制器 30 项定向测试通过；双机实机 CPU 采样通过。真实 P1 求解 / 后处理的 Windows 进程树采样峰值为 285.76 / 370.52 MiB，耗时 118.36 / 15.81 秒 | 已有单来源实测；不外推全部任务 |
| 真实生产首条 | jsonrpcclient：1 次正常尝试、5 次教师调用、3,535 输出 token。独立 judge 正常执行且 fresh_before / cleanup 核验通过；alignment 与公开 probe 通过，官方判分未通过 | 按原负向门隔离，0 条入库；不重采样 |
| 准备基础设施错误 | pyOpenSSL：editable .pth 指向已移除的旧源码，OpenSSL 导入失败。保留基础设施分类、清理及 0 模型调用证据，隔离该来源后恢复其他已合格来源 | 候选修复 7525f6b，7 项 CPU 测试通过；待真实容器与新 P0 验证 |
| 当前资源配置 | Windows floor 1 GiB、Mac 512 MiB；每节点 2 worker / 2 作业。准备、求解、后处理、发布各预留 2 GiB，审查 1.5 GiB，审查打包 1 GiB。容器原上限、模型与 token 协议保持不变 | 按用户授权调整；当前批次上限 8 个来源 |
| 生产收益与训练收益 | 生产已恢复，后续来源正在准备；当前已结算来源尚无新增有效监督。未启动训练 | 尚无吞吐增益或训练收益结论 |
首轮准备期间 Windows 可用内存低水位为 2,947 MiB；采集到的容器 OOM 计数为 0。求解阶段 25 次资源探测合计约 610 ms。RSS 可能重复计入共享页或漏过短进程；Windows 余量、WSL 工作集与容器 cgroup 有重叠，不相加。已测到真实 Docker 阶段，Mac 真实语义审查与正向发布仍待来源进入对应阶段。
证据入口：本轮工程验收与历史口径 · 原多机框架验收。原始生产账本、审查材料和私有 judge 留在本地，不随本页发布。
计数口径与已纠正的结论
- 新增 36 条 / 109,340 tokens；seed 16 条 / 74,104 tokens；总计 52 条 / 183,444 tokens。速度只使用新增量。
- 31 条语义隔离：26 条有 core 索引但遮罩 / 长度后无存留 core；5 条空 core 且有明确隔离原因。不能把它们称作免费可挽回池，也不能将 26 / 5 直接标成结构性 / 语义性损失。
- 155 条登记用量来自 154 条结果加 jupyter 旧中断；puremagic 仅 7 次捕获，用量字段 NULL，不混入已结算数。
- 9 条 completed 因 fresh_before 未核实属于 infra-invalid。单个合成 metadata 复现不能证明这 9 条的历史原因。
- 剩余 2,152 条候选需贡献 1,948 条来源才能到 2,000 总目标，要求转化率 90.5%；这是算术约束，不是无偏预测或绝对不可达证明。
- 不同 tokenizer 的 API 输入 token 与监督 token 不直接比较；槽占用率不解释为 GPU 利用率。
05 · 维护与下一次验收
同一份台账持续更新
每次触及相关卡点，更新对应 B 编号的状态、证据和剩余工作；保留历史基线，不用新 run 覆盖旧分母。
只有真实生产收据支持时，才把“已实现待生产验证”改为“生产验证完成”。更新时同步文件名日期、README 入口与 Cloudflare 页面；不启动周期性生产任务。
下一次生产窗口应测量
每 lane 启动间隔、双槽同空闲比例、每小时有效监督 token、零调用预筛时间、prefix cutoff、判分 infra-invalid、节点可用内存与 OOM、每来源付费输出成本。
控制器入口
python storage/e2_pipeline.py --config PIPELINE.json dry-run
python storage/e2_pipeline.py --config PIPELINE.json status
python storage/orchestration_manage.py start-pipeline \
--config PIPELINE.json --runtime-dir RUNTIME当前有界生产配置位于 eval/work/e2-real-acceptance-20261102/pipeline.json，批次总上限为 8 个来源（包括已结束的 2 个）；双机各两个独立 worker。达到上限或出现未对账的基础设施错误时停止新派发。
start-pipeline 不解除 E2 / 框架暂停。运行前仍需满足节点内存、既有 student / renderer 服务和冻结执行收据条件。