消費級硬件上的 LLM 第 6 部：為何更大的協調器無法修正控制迴圈

Part 6 of a series. Previously: Part 5 — Distributing the Workers and the Memory Budget.

Part 5 ended with the 77 GB coordinator finally running as it should — resident, no thrashing, the memory problem resolved by moving the workers to a second machine. That made it possible to answer a question Part 4 had deferred: now that the big model can actually run, does a bigger coordinator fix orchestration? The answer was no, and the reason reshaped how the team was run.

The ceiling persists on the big model

With memory no longer the bottleneck, the coordinator's orchestration could be judged on its own merits. It sequenced delegations more reliably than Gemma had — but it did not escape the same failure modes. On longer plans it still dropped steps, issuing some delegations and silently omitting others before writing its summary. It still, on occasion, emitted a delegation as text rather than executing it — Part 4 showed one such case, a hand-off printed as raw JSON and then abandoned. And it periodically returned nothing at all after a tool call, requiring an automatic nudge to continue:

⚠ Model returned empty after tool calls — nudging to continue

That warning recurred often enough to be diagnostic. These were not the mistakes of a weak model; they were the mistakes of a capable model asked to do something it is structurally poor at — hold a long control loop in its head while also doing the reasoning inside it.

The diagnosis: the ceiling is the loop, not the model

The decisive observation was that all three failure modes — dropped steps, commands narrated instead of executed, empty turns — appeared on the large model exactly as they had on the small one. The common factor was not model size. It was the agentic loop itself.

Asking a language model to orchestrate is asking it to be, simultaneously, the planner that decides the steps, the dispatcher that issues each delegation, the bookkeeper that tracks which delegations are still outstanding, and the evaluator that judges the results as they return. That is a great deal of state to carry across many turns, and carrying state across turns is precisely what these models are weakest at. A bigger model raises the ceiling a little; it does not remove it.

The fix: take the loop away from the model

If the loop is the problem, the loop should not be the model's job. The resolution was deterministic orchestration: a small script owns the control loop. It holds the list of tasks, dispatches each delegation, waits for and collects the result, and decides what runs next. The model is invoked only for the two things it is genuinely good at — planning (what are the steps?) and evaluating (is this result acceptable?) — and never has to remember what it has already dispatched, because the script does that.

The improvement was immediate and measurable. A task sequence that the model-driven loop had stalled on partway through — completing three of five steps before losing the thread — ran all five to completion when the same plan was executed by the script. The model had not become more capable. It had simply been relieved of the one job it could not reliably do.

The lesson

The instinct, when an agent loop is unreliable, is to reach for a bigger model. That instinct was wrong here, and expensively so — it was the reasoning behind the whole coordinator search of Part 4, and the memory wall of Part 5, and in the end it did not solve the problem it was chasing. Orchestration reliability is not a model capability that can be bought in larger quantities; it is a property of how the loop is structured. The durable fix was architectural: move the deterministic part — the loop, the bookkeeping, the dispatch — into deterministic code, and reserve the model for the parts that genuinely require judgment. A control loop is a job for a program, not for a language model, and the sooner that division is drawn the more reliable the system becomes.

What follows

Deterministic orchestration made the team's execution reliable: a plan was now carried out without dropped steps or invented progress. But it did nothing for the moment a plan meets a wall — when the right next step is not in the plan at all, and someone has to rethink the approach rather than merely execute it. Reliable execution and good judgment are different capabilities, and the next entry is about supplying the second without compromising the first.