A–F并行调度与云端工具端优化报告
在不减少A–F、不减少重复次数、不更换模型、不改变Gold隔离与五项指标的前提下，大幅压缩单城实际等待时间。
方案冻结 · 2026-08-05之后实施01 · 核心判断
当前约83–99分钟/城的根因不是Module，而是12次Answerer与6次Primary Judge基本串行。六组独立分支并行后，目标为30–40分钟；校准六路并发后目标20–25分钟。
18完整调用保持不变
60%–80%目标墙钟时间下降
≈1.49M平均reported tokens/城，预计不因并行明显下降
02 · 两城实测基线
| 城市 | Module 1–4 | Answerer×12 | Judge×6 | 模型累计时间 | Reported tokens |
|---|---|---|---|---|---|
| Livermore | 约0.7秒 | 59.2分钟 | 40.2分钟 | 99.4分钟 | 1,475,207 |
| Fremont | 约11秒 | 55.6分钟 | 27.0分钟 | 82.6分钟 | 1,503,954 |
| 平均 | 可忽略 | 57.4分钟 | 33.6分钟 | 91.0分钟 | 1,489,580 |
超过99%的累计耗时来自模型边界。Module缓存、CSV生成与Fusion不是当前主瓶颈。
03 · 并行DAG
A: Answer A1 + Answer A2 → Judge A B: Answer B1 + Answer B2 → Judge B C: Answer C1 + Answer C2 → Judge C D: Answer D1 + Answer D2 → Judge D E: Answer E1 + Answer E2 → Judge E F: Answer F1 + Answer F2 → Judge F 六条分支相互独立；每组Judge只等待本组两份冻结答案。
| 模式 | 调用与指标 | 目标墙钟时间 | 预期下降 |
|---|---|---|---|
| 当前串行 | 18次完整调用 | 83–99分钟 | 基线 |
| 并发3 | 完全不变 | 30–40分钟 | 约55%–65% |
| 并发6 | 完全不变 | 20–25分钟 | 约70%–80% |
04 · 不降低指标的硬约束
- A–F定义、12 Answerer、6 Judge与两次独立重复保持不变。
- Question、Gold、Evidence Pack、Prompt、Schema、模型和参数保持一致。
- Answer先冻结Hash，Judge后读sealed Gold；Gold exposure必须为false。
- 五项指标、严格N/A、first-pass/repair与逐次Token回执保持不变。
- 禁止复用其他组答案、跳过Judge、缩小Required Items、降低Top-k或更换小模型。
05 · 云端五账号Worker
统一A100/Linux节点建立五个隔离Codex Worker。每个城市作为原子任务分给一名成员；共享Qwen作为本地对照，中央Judge保持固定模型与配置，中央归档器验签后上传Drive。
5隔离Codex Plan Worker
1共享Qwen服务
1固定中央Judge
GUI关闭后任务继续运行；个人电脑仅负责账号连接、任务审查和报告查看。
06 · 无损附加优化
- Evidence Pack内容寻址去重：正文只存一次，A–F保存引用、排序、slot与Gate。
- B–F禁止仓库漫游：只读冻结任务包，不重新扫描PDF或运行Module；A保留全文自主定位。
- 程序Worker预热：复用Python与Schema环境，但每次模型调用仍为独立新会话。
- 城市间流水线：Judge、Answerer、CPU Module与Qwen使用独立并发池。
- 节点级checkpoint：失败只恢复对应节点，不重跑已完成分支。
07 · 验收门
- 18 calls齐全：Answerer=12、Judge=6。
- 串行/并行Evidence Pack与Question Hash一致。
- 无跨组读取、无输出覆盖、无Gold泄漏。
- Required-Item Coverage不得因调度或竞态丢项。
- 模型存在随机性，不要求逐字输出一致；若出现系统性指标下降则停止推广。
- 同一节点连续失败两次、Hash漂移或Gold暴露时立即回退串行模式。
08 · 论文可视化
| 图 | 用途 |
|---|---|
| 串行/并行甘特图 | 证明调度降低墙钟时间，而非减少调用。 |
| A–F×五指标热力图 | 比较证据条件与Module更新影响。 |
| Required-Item点矩阵 | 显示每题、每slot的正确/缺失/错误/N/A。 |
| Slot闭合漏斗 | 定位Required→Retrieved→Answered→Correct在哪层损失。 |
| 准确率—Token—墙钟散点图 | 比较Codex、Qwen、并发与Evidence方案。 |
| Module 2/4前后配对斜率图 | 证明队友更新是否真正改善Coverage和Correctness。 |
09 · 8月5日后实施顺序
01 冻结基线合并Module 2/4，保留两城旧run。
02 Scheduler异步DAG、Semaphore、checkpoint。
03 协议验收fake provider验证18-call与失败恢复。
04 两城实测并发3，再校准并发6。
05 产品化五账号、Drive、GUI和论文图集。
10 · 决策
2026-08-05之前只冻结方案，不修改正式Scheduler、不重跑两城、不改变A–F协议。Module 2/4合并并验收后开始实施。