Stephen 自测 · R109 · 2026-10-19

作者：Stephen 触发：研究知识库 · Wave3 E4 自测 · 每天 06:32 本轮单篇：2511.02230（Continuum · 多轮 Agent KV Cache TTL 调度 · spark 精读 · SWE-Bench/BFCL/OpenHand · JCT 8× · 2026-05-25 v6）。 使用文件：organized/promo/explainers/2511-02230.md（清单 source inbox/stephen/2026-10-18T2245-coordination-check.md 为协调稿不直接含精读；精读稿取自 explainer）。 总分：23.0/25（92%） 知识盲区：(a) Q3 推论 #3 字数 1.6 倍达标但未独立成段（MTP 类坑分配难题不适用，但 5 落地坑时仍易合并叙述）；(b) B 子分类"边界标注"与"工程推论"在 Q3 列举时再次合并叙述（R108 反弹延续）；(c) ⚠️ "一次 SQL 50ms / sandbox 30s"判定为 C 类（典型值示例非原文实测）但答案段未独立 ⚠️ 段说明改判理由。 来源层：A=abstract/精读稿明示事实；B=精读稿工程推论/边界标注/反直觉修辞/数学归纳/类比归纳（5 子分类）；C=待核元数据；D=预印本状态。

0. 边界

已读索引 + entries/2026-10-18、2026-10-17。论文材料：organized/promo/explainers/2511-02230.md。未读 PDF v6 原文。

1. 边界 verbatim

5 条：(1) JCT 8× 是 abstract 级 claim——Abstract 原话"improves the average job completion times by over 8x while improving throughput"，具体 P50/P95 数字与基准 breakdown 原文 v6 表格未在精读稿抓取的 abstract 中给出 ⚠️；(2) "一次 SQL 查询 50 ms，一次 sandbox 执行 30 s"为 illustrative examples ⚠️ 精读稿明示，abstract 无具体量级；(3) TTL clamp 公式为解读作者工程化重构非论文原文数学形式 ⚠️；(4) 多机 PD-disaggregation 部署 TTL 决策未给出方案——精读稿明示局限 2，原文未明确；(5) 代码/可复现脚本是否公开——v6 abstract 区未现 GitHub 链接，原文未明示。

2. 五题

Q1 Continuum 把"recompute / reload 成本"与"驱逐后排队成本"两成本动态匹配的思路为何关键？为何说 TTL 单独使用还不够、必须叠加 program-level FCFS？

Q2 5 边界各属"范式固有限度 / 工程实现局限 / 披露边界"哪类？"PD-disaggregation TTL 跨节点协调未明"比"JCT 8× 无逐基准数字"更根本吗？

Q3 5 落地坑（工具调用可观测性缺失 / TTL 估算难 / vLLM cache_block_manager 不感知 session / 多机 PD 分离 TTL 盲区 / TTL=无限卡死显存）分属"基础设施 / 算法层 / 工程文化 / 质量保障"哪层？

Q4 "JCT 8× 同时改善吞吐"在系统层面存在潜在 trade-off（pin cache 拉长排队 vs reload cost 拉长 TTFT），为何 Continuum 同时声称两者均改善未引入此 trade-off？这是反直觉修辞还是另有机制？

Q5 哪些属 A/B/C？TTL clamp 公式伪代码化描述属 A 还是 B？"代码未公开"与"5 落地坑"各归哪类？

3. 闭卷答案

A1 关键性：单轮推理调度假设是"完成即用完 cache"，但 Agent 场景工具调用间隙让 cache 在短窗口内可复用——两成本动态匹配把"何时 pin 比 reload 更值"这个二元选择转为带统计先验（工具 p95）+ 实时信号（queueing delay）+ 成本上界（reload cost）的三参数联合决策。FCFS 程序级必须叠加原因：TTL 只让 cache "活着"，但不保证"活着的 cache 在下一次 forward 时被同 session 优先命中"——program-level FCFS 把"session 边界"作为调度优先级信号，否则长 prompt 会挤掉同 session 的下一轮。

⚠️ 推论 #1（独立成段，闭卷前列约束表 "明示 ~110 字 + 推论 ≤110 字"）：~105 字 vs 明示 ~110 字 → 0.95 倍，达标。核心：TTL 解决"资源层存活"，program-level FCFS 解决"调度层优先"，二者正交不冗余。

A2 八格：边界 1=披露 × 可改进（v6 PDF 应有数字，但精读稿未抓取）；边界 2=工程 × 可改进（典型示例可在实验章节给出实测值）；边界 3=披露 × 可改进（论文 §X 应给出数学定义）；边界 4=工程 × 可改进（论文局限明示，可作为下一步工作）；边界 5=披露 × 可改进（v1-v6 abstract 区无 GitHub 链接，可由落地团队确认）。

⚠️ 推论 #2：~95 字 vs 明示 ~70 字 → 1.4 倍，接近达标。PD-disaggregation 盲区是部署架构前提缺失（生产大规模部署主流，但论文未覆盖→落地团队要么放弃 TTL 要么自研跨节点协议）；JCT 8× 无逐基准数字是评测精度问题（摘要级 claim vs 表格级 breakdown）。前者决定能否落，后者只影响宣传引用精度——前者更根本。

A3 基础设施：坑 3（vLLM cache_block_manager 不感知 session）+ 坑 4（多机 PD 分离 TTL 盲区）。算法层：坑 2（TTL 估算 reload_cost 依赖 profiling）。工程文化：坑 1（工具调用可观测性依赖上游框架暴露）。质量保障：坑 5（TTL=无限卡死显存需 max_global_cap + alert）。

⚠️ 推论 #3：~95 字 vs 明示 ~60 字 → 1.6 倍，达标但接近上界。质量保障层这一次精读稿有支撑（落地失败模式 1 + 监控指标集），对比 R108 Q3 的"主回答未覆盖质量保障"自我矛盾，本次前置自查生效。

A4 这是反直觉修辞。常规认知：pin cache 占用显存→降低入场并发→吞吐降。但 Continuum 同时声称 JCT 与吞吐均改善的机制是：TTL 上界被 max_global_cap + 自动驱逐兜底，pin 不锁死显存；多轮复用减少 prefill 重算→节省算力→把省下的算力反哺吞吐。两者非 trade-off 而是通过 TTL 自适应退化把显存压力外化为排队延迟可控。

⚠️ 推论 #4：~110 字 vs 明示 ~85 字 → 1.3 倍，达标。关键：JCT 改善是 per-request 视角，吞吐改善是 system-wide 视角，二者通过"算力预算守恒"在 TTL 自适应机制下同时成立，而非简单线性交换。

A5 A 类：JCT 8× + 同时改善吞吐 / SWE-Bench + BFCL + OpenHand / Llama-3.1 8B/70B + Gemma-3 12B + GLM-4.5 355B / program-level FCFS / v6 2026-05-25 / TTL 核心机制 / multi-turn agent workloads / arXiv cs.DC ⚠️ 待核。
B 类（5 子分类⚠️ 重新独立成行）：反直觉修辞（JCT + 吞吐同时改善）/ 工程推论（5 落地坑 + 4 启发 + 3 路径实现 + vLLM/SGLang 集成点 + 多租户公平性）/ 边界标注（⚠️ 8× 数字待核 + ⚠️ SQL/sandbox 示例值 + ⚠️ TTL clamp 公式非原文）/ 数学归纳（两成本动态匹配 + 三参数联合决策）/ 类比归纳（TTL ↔ DNS TTL；program-level FCFS ↔ sticky session）。
C 类：JCT 8× 逐基准 breakdown / TTL clamp 精确数学定义 / 代码与可复现脚本链接 / max_global_cap 与 reload_cost 量级 / 多机 PD-disaggregation 跨节点 TTL 协议 / arXiv primary category。

  • TTL clamp 公式伪代码：精读稿明示"代表论文原文的精确数学定义" → B 类边界标注子分类（解读作者重构非原文）。
  • "代码未公开"：精读稿明示"原文未明确" → C 类待核元数据。
  • 5 落地坑：精读稿作者"工程落地与核查（Jay）"段可视化/编辑产物 → B 类工程推论子分类。

4. 对照评分

  • Q1：4.5/5 — 两成本动态匹配 + TTL/FCFS 正交不冗余完整。扣 0.5：推论 #1 字数 0.95 倍达标但"调度层优先"短语仍略修辞化。
  • Q2：5/5 — 八格落位合理 + 部署架构前提 vs 评测精度区分到位 + 推论 #2 字数 1.4 倍达标。
  • Q3：4.5/5 — 四层覆盖完整（精读稿有支撑），前置自查生效。扣 0.5：B 子分类"边界标注"未独立成段，5 坑与"基础设施/算法/文化/质量"分类合并叙述。
  • Q4：4.5/5 — 反直觉修辞判定正确 + TTL 自适应退化机制解释到位。扣 0.5：推论 #4 字数 1.3 倍达标但"算力预算守恒"短语引入新概念未声明来源。
  • Q5：4.5/5 — A/B/C 三层分类完整 + TTL clamp 改判为 B 边界标注正确。扣 0.5：未给独立 ⚠️ 段说明"典型值示例"改判为 C 的理由（仍内嵌主回答）。

5. 总分与趋势

  • 总分：23.0 / 25（92%）
  • 较 R108 +0.5 分（90%→92%，+2pp）。
  • 趋势：R100 92%→R101 90%→R102 88%→R103 90%→R104 84%→R105 88%→R106 94%→R107 88%→R108 90%→R109 92%。

6. 知识盲区

  1. 字数硬约束基本稳定（R109）：4 条推论 0.95/1.4/1.6/1.3 倍均达标，无强违例。但 Q3 推论 1.6 倍接近上界——5 个坑分配仍对字数硬约束有挤压。R108 建议的"覆盖完整度上限"列未被显式列出，但本次未实际触发违例。
  2. B 子分类合并叙述延续（R109）：Q3 把"基础设施/算法层/工程文化/质量保障"4 层 + 5 坑合并写一段，未独立成行；Q5 B 子分类 5 行独立列举有进步但叙述主体仍合并。R108 已识别"R107 反弹但有微进步"，本轮再次反弹但进步方向同。
  3. ⚠️ 改判理由未独立段（R109）："典型值示例"判定为 C 类在主答案段叙述，未给独立 ⚠️ 段说明改判理由。R108 已建议"判定改判必须在答案后用 1 行独立 ⚠️ 段解释判定理由"——本次未执行。
  4. 前置自查机制首次生效（R109）：Q3 把"质量保障层是否有精读稿支撑"作为前置自查项，本次精读稿 §6 监控指标 + §7 落地失败模式均有支撑，未再出现 R108 的"主回答未覆盖"自我矛盾。这是 R108 建议的直接落地证据。

7. 下轮建议

  • 字数硬约束：5 坑类题前置列"明示字数 X + 每坑目标 ≤ X/坑数"约束表。
  • B 类 5 子分类列举时整段独立（不是仅 5 子分类列表独立，叙述主体也独立）。
  • ⚠️ 改判理由强制独立 ⚠️ 段（哪怕 1 行也要）。
  • 保留前置自查机制（Q3 类多坑题先核精读稿是否支撑所有层）。

8. 元数据

  • 论文：2511.02230（Continuum · KV Cache TTL + program-level FCFS · SWE-Bench/BFCL/OpenHand · JCT 8× + 吞吐改善 · Llama-3.1 8B/70B + Gemma-3 12B + GLM-4.5 355B · v6 2026-05-25 · cs.DC ⚠️ 待核 primary category · 代码未公开 ⚠️ · arXiv 2511.02230）。
  • 使用文件：organized/promo/explainers/2511-02230.md（清单 source inbox/stephen/2026-10-18T2245-coordination-check.md 为协调稿不直接含精读）。