LLMCompiler：从 planner DAG 到受约束的并行 call pass

Primary source: An LLM Compiler for Parallel Function Calling

一句话

LLMCompiler 的可吸收部分是 ready-task scheduling：输入依赖满足的 tool call 可以立即 dispatch。论文用 LLM planner 生成 DAG；Pysolate 可以从 Python AST、tool-call metadata 和动态 occurrence 维护一个更窄的 incremental event graph，而不让另一个 planner 重写程序。

原工作做了什么

LLMCompiler 用 Planner 生成包含 dependency 的任务流，Task Fetching Unit 在依赖满足后调度工具，Executor 汇总结果。论文以 latency、cost 和任务 accuracy 评价该方案。

这套系统并不把一个已有 Python AST 做等价转换。Planner 同时决定要调用哪些工具和它们之间的依赖，因此 planner 错误会改变程序本身。

论文的 Task Fetching Unit 使用 greedy ready queue：task 一旦输入依赖满足，就交给异步 Executor。Planner 还可以流式输出 task，因此不必等完整 DAG 生成完才开始前面的 independent calls。这一点与 Pysolate “source/occurrence 看见一点，满足条件就发一个”很接近。

Pysolate 是否也需要 DAG

需要借 dependency/ready-frontier 抽象，但不需要复制 LLM planner 或完整 Python control-flow graph。

Pysolate 已经有更可靠的依赖来源：

Python def-use 与 source order；
branch、loop、try/except 等 control structure；
当前实际到达的动态 occurrence；
tool 的 side-effect、failure 和 cancellation contract。

可以动态维护一个只覆盖 Host calls 的 event graph：

call occurrence arrives
        ↓
arguments ready?
control path active?
early dispatch allowed?
resource budget available?
        ↓ yes
      dispatch
        ↓
result ready → unblock dependent resolve/call

普通 branch 内的 call 由 Python 激活后才加入 ready queue；loop 每次迭代产生新的 occurrence。只有明确允许“没有被程序使用也可以直接丢弃”的 read/pure work 才能在动态 reach 之前进入 speculative lane。因此 Host 不需要成为第二个 Python interpreter。由于 loop 会持续产生 occurrence，这个对象比“全局静态 DAG”更准确地说是 incremental event graph。

可以吸收的 pass

Pysolate 可以对一个已经存在的 straight-line region 做：

a = workspace.read_text("a.py")
b = workspace.read_text("b.py")

到一个 hidden submit / blocking materialize lowering。两个 Host-owned pseudo-future 可以同时 pending，但 Python surface 仍保持同步，也不会出现 Python Future object。Legality 至少要求：

两个 calls 不存在 data/control dependency；
arguments 和 workspace root 已确定；
只涉及 pure work 或 immutable-root reads；
source-order exception visibility 有明确实现；
cancellation 后所有 late/orphaned physical work可审计。

Correctness 与副作用

论文主要证明 benchmark accuracy没有因新的 planner/executor结构而不可接受地下降。它没有证明并行程序与某个顺序程序 observationally equivalent，也没有提供通用 rollback。

如果原程序的第一个调用失败，顺序执行不会开始第二个调用；并行化后第二个调用可能已经发生。对搜索类 read workload，这可能只是额外成本。对发邮件、写数据库或支付则是 effect leak。Planner遗漏 dependency 也会让后续任务看到错误或过早的输入。

Pysolate 结论

只吸收 ready-queue scheduling kernel，不吸收 LLM planner、task synthesis 或 planner-driven dynamic replanning。V1 只允许 pure/immutable-read operations；private workspace writes即使可以 discard，也应在 read-only semantics 稳定后单独研究。普通 external writes不进入 parallel pass。

更完整的 Pysolate 设计记在 implementation/11-split-phase-call-scheduling.md：program-derived incremental event graph、Host-owned pseudo-future 与 hidden materialization。