Phase 3 — Offload de expertos del backbone a RAM (M0)
Transmite las FFN de expertos MoE desde la RAM de la CPU en vez de la VRAM, y un solo coordinador de 64 GB sostiene un 122B — sin cirugía de grafo.
Las FFN de expertos no tienen que vivir en VRAM. Transmitirlas desde la RAM de la CPU permite que un coordinador sostenga un modelo cuyos expertos exceden su VRAM — la base que permite que los nodos débiles se unan a un gran MoE.
Un 122B cabe en un solo coordinador de 64 GB
Antes, el anillo colocaba pesos solo en VRAM, así que el 122B (77.6 GB) era infeasible en un GCD de 64 GB. Con las reglas de offload de expertos, el dry-run vuelve feasible:

Salida del planner — formato de reglas -ot de motor de inferencia.
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
Llevar las reglas de offload del planner a una carga real
- planner — ya emite
ot(reglas-otunidas por comas) en cada placement. - protocol.py — se añadió el campo
StageStartRequest.ot. - runtime.py — reenvía el
otdel placement a la petición de stage. - stage_service.py — el coordinador arranca con
--override-tensor. linkcpp-serverreenvía argumentos desconocidos al llama-server de serie, así que-otse aplica intacto.
# stage_service.py — coordinator branch
if request.ot:
command += ["--override-tensor", request.ot]Verificado con un test de ida y vuelta del protocolo ot más la confirmación de que el comando del coordinador emite --override-tensor; el hub se redesplegó limpio y sin regresiones. Lo que quedaba entonces: la carga completa de 77 GB en 2 nodos (coordinador con offload + un teléfono con una ventana de una capa de ~1.5 GB), a la espera de servidor. El núcleo de M0 — el offload del backbone que permite a los nodos débiles participar en un MoE grande — quedó completo a nivel de código y planner.