Una singola DGX Spark è più che sufficiente per servire Ling-3.0-flash nella sua quantization INT4 ufficiale. Ma appena si lancia il modello con la configurazione ingenua, le prestazioni crollano a 20.8 tok/s, un valore che non rende giustizia all'hardware. Bastano due flag per ribaltare la situazione e arrivare a 38.7 tok/s, superando anche la variante GGUF che molti adottano su questa macchina. I numeri non sono ipotetici: vengono dal repository pubblicato da sudoingX, che ha eseguito tutti i test sulla propria Spark e ha condiviso la ricetta con il permesso del team Ling di inclusionAI.

I due interventi sono un classico esempio di quanto l'ottimizzazione del software incida sull'inference on-premise. Il primo è la rimozione di --enforce-eager, un flag che blocca l'esecuzione dei cudagraph e che spesso viene lasciato per abitudine o per compatibilità. Senza di esso, i kernel CUDA possono essere compilati e riutilizzati in modalità grafo, riducendo drasticamente il overhead di lancio. Il secondo è l'attivazione della decodifica speculativa MTP (Multi-Token Prediction) con un singolo token speculativo, usando il metodo bailing_hybrid_v3_mtp. Il modello include già il draft layer nel checkpoint, quindi l'abilitazione è istantanea: basta passare a vLLM la configurazione --speculative-config '{"method": "bailing_hybrid_v3_mtp", "num_speculative_tokens": 1}'. Il risultato è un incremento di oltre l'80% sulla velocità di generazione, ottenuto senza toccare l'hardware né cambiare il formato del modello.

C'è però un avviso che pesa più dei numeri. La versione stock di vLLM non supporta il modello V3: lo esegue comunque, ma instrada l'attenzione su un percorso sbagliato. Non produce errori espliciti, non crasha. Genera output fluente che sembra corretto — finché non si accorge che non lo è. È l'incubo classico del self-hosted: un modello che mente con autorevolezza. Per evitarlo, bisogna usare il fork inclusionAI/vllm-ling-v3, branch ling_3_0, che corregge il meccanismo di attenzione. Il repository di sudoingX include gli script di serving, un watchdog per gestire i freeze a freddo durante lo sharding, il metodo di benchmark e un file FINDINGS.md con ogni dettaglio tecnico.

La nota dolente arriva quando si allunga il contesto. L'INT4 si comporta da velocista: sotto i 30.000 token di contesto è la scelta più rapida, ma oltre quella soglia la variante Q5 in formato GGUF degrada in modo più graduale, risultando più stabile per sessioni maratona. Questo trade-off è cruciale per chi sta decidendo quale quantization adottare in produzione: non esiste una risposta univoca, ma dipende dal profilo di carico.

La vicenda mette in luce alcuni meccanismi più profondi del deployment LLM on-premise. Innanzitutto, la distanza tra le prestazioni "out of the box" e quelle raggiungibili con una configurazione attenta può essere abissale, e spesso i default dei framework di serving sono pensati per la massima compatibilità, non per la massima velocità. In secondo luogo, la necessità di un fork specifico per supportare correttamente un modello è un campanello d'allarme sulla fragilità della catena di tooling: chi fa self-hosting deve essere pronto a mantenere rami personalizzati, con i costi di aggiornamento e verifica che ne conseguono.

Per chi sta valutando il passaggio dall'API cloud al ferro locale, questo caso è istruttivo. Una workstation come la DGX Spark diventa molto più interessante se si può estrarre oltre 38 tok/s su un contesto pieno di 256K token senza pagare a richiesta. Ma l'investimento in hardware è solo metà della storia: serve competenza per mettere a punto la pipeline e la consapevolezza che un modello può generare testo fluente pur essendo in errore silenzioso. Il confine fra risparmio e disastro è sottile.

Il repository di sudoingX è pubblico e ogni dettaglio è documentato. La trasparenza della ricetta è un passo avanti per la comunità, ma restano aperte le domande su quanto i vendor di hardware e i maintainer dei framework possano ridurre l'attrito per chi sceglie di tenere l'inference in casa.