Phase 3 — Backbone-Experten-RAM-Offload (M0)
Streame die MoE-Experten-FFNs aus dem CPU-RAM statt der VRAM, und ein einzelner 64-GB-Koordinator hält einen 122B — ohne Graph-Chirurgie.
Experten-FFNs müssen nicht in der VRAM leben. Sie aus dem CPU-RAM zu streamen lässt einen Koordinator ein Modell halten, dessen Experten seine VRAM übersteigen — das Fundament, das schwachen Knoten den Beitritt zu einem großen MoE überhaupt erlaubt.
Ein 122B passt auf einen einzelnen 64-GB-Koordinator
Zuvor platzierte der Ring Gewichte nur in VRAM, der 122B (77.6 GB) war auf einem 64-GB-GCD also infeasible. Mit Experten-Offload-Regeln kommt der Dry-Run feasible zurück:

Planner-Ausgabe — Inferenz-Engine -ot-Regelformat.
node 0 layers [0,48] vram=62.6 ram=14.2 ot_rules=10 sample: blk\.38\.ffn_(up|down|gate)_(ch|)exps=CPU # inference engine -ot format
Die Offload-Regeln des Planners in einen echten Load tragen
- planner — emittiert bereits
ot(kommagetrennte-ot-Regeln) in jeder Platzierung. - protocol.py — Feld
StageStartRequest.othinzugefügt. - runtime.py — leitet das
otder Platzierung in die Stage-Anfrage weiter. - stage_service.py — der Koordinator startet mit
--override-tensor. linkcpp-serverreicht unbekannte Argumente an den unveränderten llama-server durch,-otgreift also unangetastet.
# stage_service.py — coordinator branch
if request.ot:
command += ["--override-tensor", request.ot]Verifiziert mit einem ot-Protokoll-Roundtrip-Test plus der Bestätigung, dass das Koordinator-Kommando --override-tensor emittiert; der Hub wurde sauber und regressionsfrei neu deployt. Was damals blieb: der volle 2-Knoten-77-GB-Load (Koordinator mit Offload + ein Smartphone mit einem ~1.5-GB-Ein-Layer-Fenster), gated auf Serververfügbarkeit. Der Kern von M0 — das Backbone-Offload, das schwache Knoten an einem großen MoE teilnehmen lässt — war auf Code- und Planner-Ebene abgeschlossen.