16 + 128 = 144 GB: ha senso fare inferenza “a quattro mani” tra laptop e GX10?

L’idea

Ho due macchine che fanno inference di LLM:

• il laptop, con una GPU da 16 GB di VRAM: veloce, affamata di banda (orientativa: 700–1000 GB/s a seconda del chip), ma con poco spazio;
• il GX10 (SoC Grace Blackwell GB10), con 128 GB di memoria unificata: tanto spazio, ma banda LPDDR5x di circa 273 GB/s. Oggi ci gira llama.cpp che serve Qwen in locale.

La tentazione è ovvia: e se unissimo le due memorie in un unico “super GPU” da ~140 GB? Sul GX10 entrano modelli da 100+ GB quantizzati; sul laptop no. Ma la somma delle capacità vale davvero la somma delle prestazioni?

La legge brutale: il decode è banda, non spazio

Generare token è un’operazione memory-bound: a ogni token il modello pesa quasi tutto il suo peso quantizzato dalla RAM. La velocità massima è approssimativamente:

$$\text{token/s} \approx \frac{\text{banda memoria}}{\text{peso del modello}}$$

Da qui il primo verdetto contro-intuitivo: per molti modelli il laptop da solo è più veloce del GX10 da solo. Un Qwen da 32 GB in Q4 sul GX10 va a ~273/32 ≈ 8-9 t/s; lo stesso modello (o uno da 14 GB) sulla GPU del laptop può superare i 30-40 t/s. La capacità in più non è gratis: la paghi in banda.

Cosa succede quando le uniamo

Esistono due schemi classici:

1. Pipeline parallel (split per layer): i primi N layer sul laptop, i successivi sul GX10. Ogni token attraversa entrambe le macchine in sequenza. Il tempo per token è la somma dei tempi delle due metà (più la latenza di rete a ogni passaggio).
2. Tensor parallel (split per tensori): ogni layer è diviso a metà; le due macchine lavorano in parallelo su porzioni diverse. Qui la banda efficace si avvicina alla somma delle bande (800 + 273 ≈ 1000 GB/s in teoria) — ma richiede uno scambio di dati (all-reduce) a ogni layer, quindi è brutalmente sensibile a latenza e banda di rete.

Il caso realisticamente buono è lo split per layer con i pesi distribuiti in proporzione: sul laptop finiscono ~16 GB di layer (elaborati a ~800 GB/s), sul GX10 il resto. Per un modello da 70 GB in Q4:

• GX10 da solo: 273/70 → ~4 t/s
• GX10 + laptop: la metà GX10 impiega ~0,13 s, quella laptop ~0,02 s → ~7 t/s effettivi

Guadagno reale, ma non miracoloso — e solo se la rete non è il collo di bottiglia: serve un collegamento cablato dedicato (2.5 GbE come minimo, meglio 10 GbE o Thunderbolt/USB4 direct). Su Wi-Fi o rete condivisa i millisecondi di RTT moltiplicati per decine di strati riportano tutto sotto i 5 t/s.

Il vero caso d’oro: i modelli MoE

Il quadro cambia per i Mixture-of-Experts (Qwen3-235B-A22B e simili): pesi totali enormi, ma parametri attivi per token piccoli. Lì:

• gli expert layer (la maggior parte dei pesi, letti in modo sparso) stanno comodi sui 128 GB del GX10;
• attention, router e gli expert più caldi possono stare sulla GPU del laptop, letti ad alta banda;

Il byte-per-token effettivo è una frazione del modello, quindi la banda del laptop conta molto di più di quanto lascerebbe pensare il rapporto 16:128. È lo scenario in cui un cluster eterogeneo di due scatole fa cose che nessuna delle due da sola può fare: un 235B Q4 in Q4_K_M (~130 GB) non sta né sull’uno né sull’altro, ma sta sulla somma.

Come si fa in pratica (oggi)

• llama.cpp RPC: il più maturo. Sul GX10 si lancia un rpc-server, sul laptop si avvia llama-server con -r <ip-gx10>:50052 --n-gpu-layers 99 e si regola la ripartizione con --split-mode (layer/tensor) e --tensor-split. Nessun cambio di modello mentale: il client vede “una GPU sola” più grande.
• exo e simili: approccio più “turnkey” al tensor parallel su rete, ottimo per sperimentare, meno per la produzione quotidiana.
• Pipeline parallelo via API (un modello per macchina): non è inferenza combinata dello stesso modello, ma è la strategia noiosa e vincente per molti workflow (vedi sotto).

Le tre strategie oneste

Verdetto

Il cluster ibrido da 144 GB non è un acceleratore, è un moltiplicatore di capacità: non rende nulla più veloce di quanto farebbe la GPU locale su modelli che ci stanno, ma rende eseguibili modelli che altrimenti non girerebbero da nessuna parte delle due macchine — soprattutto MoE. Con una rete buona e llama.cpp RPC è un weekend di lavoro; con un modello fitto da 70B il guadagno è reale ma contenuto (~1,5-2x rispetto al GX10 da solo). Con il MoE giusto, è l’unica opzione sul tavolo.

E poi c’è il valore nascosto: mentre il GX10 fa il lavoro di capacità, il laptop resta libero per il prefill, per un secondo modello in parallelo, o semplicemente per non surriscaldarsi. Due scatole, due lavori.