Quando si parla di eseguire modelli linguistici di grandi dimensioni in locale, il collo di bottiglia più frequente resta la memoria video. Tensor parallelism è una delle risposte più efficaci: suddivide il modello su più GPU, permettendo di caricare LLM che altrimenti non entrerebbero in una singola scheda. Fino a oggi, però, questa tecnica in llama.cpp era appannaggio quasi esclusivo delle GPU NVIDIA via CUDA. Con la pull request #25051, l’ecosistema cambia.

Piotr ‘pwilkin’ ha lavorato per rendere «decisamente più utilizzabile» il tensor parallelism su backend Vulkan. Vulkan è l’API grafica e di calcolo a basso livello supportata nativamente da AMD, Intel e anche da NVIDIA, oltre che su piattaforme mobile e integrate. Significa che ora modelli divisi su più GPU AMD o Intel Arc possono collaborare in un’unica sessione di inference, abbattendo una barriera che relegava molti acceleratori al ruolo di comprimari, se non di assenti.

Perché Vulkan e tensor parallelism sono una coppia strategica

Il vantaggio immediato è la possibilità di sommare la VRAM di schede eterogenee, anche senza NVLink o interconnessioni proprietarie. In uno scenario on-premise, dove spesso si riutilizzano workstation o server con GPU di generazioni e vendor diversi, disporre di un backend di calcolo unificato evita di dover acquistare hardware omogeneo o costosissimo. L’intero stack resta gestito da llama.cpp, il framework C++ leggero e senza dipendenze cloud che ha reso l’inference di LLM accessibile su CPU e GPU consumer.

Mentre CUDA rimane la scelta dominante in ambito enterprise, l’arrivo di un tensor parallelism funzionale su Vulkan segnala una maturazione dell’offerta cross-vendor. Non è più una questione di mero supporto “anche su AMD”, ma di un percorso che porta il calcolo distribuito su GPU a diventare un mattoncino standard per chi costruisce pipeline di inference self-hosted. Per i team che devono rispettare vincoli di sovranità dei dati e non possono appoggiarsi a servizi cloud, la diversificazione hardware si traduce in minore TCO e maggiore resilienza della supply chain.

Cosa porta la PR #25051 e quali trade-off restano

La pull request non introduce nuovi modelli o metriche, ma ripulisce e stabilizza i percorsi di comunicazione tra più dispositivi Vulkan, gestendo meglio la sincronizzazione e la divisione dei tensori. Chi segue il repository sa che l’implementazione Vulkan era spesso segnata da instabilità o crash in configurazioni multi-GPU; il lavoro di pwilkin interviene proprio sugli aspetti di affidabilità, spianando la strada a test più approfonditi da parte della community.

Naturalmente, il tensor parallelism su Vulkan non offre ancora le performance delle librerie CUDA ottimizzate con cuBLAS e NCCL. Ma per carichi di lavoro dove la priorità è poter eseguire un modello, magari con quantization aggressiva per risparmiare VRAM, piuttosto che raggiungere la massima velocità in token al secondo, il guadagno in accessibilità è enorme. È un classico trade-off tra flessibilità hardware e throughput assoluto, che si inserisce in un dibattito più ampio sulla democratizzazione dell’AI.

Il contesto che conta: on-premise reale, non da laboratorio

AI-RADAR segue da vicino le evoluzioni degli stack locali, e questa PR è un esempio di come il software open source stia progressivamente riducendo le barriere all’ingresso per il deployment on-premise. Consentire a un’organizzazione di sfruttare GPU già in inventario – o di mescolare NVIDIA e AMD nello stesso nodo – cambia i conti economici dell’inference. Invece di investire in costose soluzioni omogenee, è possibile adottare un approccio modulare, dove ogni componente viene scelto in base al rapporto costo-prestazioni, con Vulkan come strato di compatibilità.

Non a caso, progetti come llama.cpp stanno diventando il cuore di molti stack self-hosted: dalla piccola impresa che serve un chatbot interno fino ai centri di ricerca che non possono inviare dati sensibili a un cloud pubblico. L’estensione del tensor parallelism a Vulkan aggiunge un tassello decisivo per la scalabilità, avvicinando questi scenari a ciò che fino a ieri era possibile solo con CUDA. E mentre la community testerà la strada aperta da pwilkin, è lecito aspettarsi che il supporto multi-GPU eterogeneo diventi una funzionalità sempre più solida e documentata.