Il server LLM locale gira da un giorno e funziona meglio del previsto. Un box noleggiato con due RTX 3090, quarantotto gigabyte di VRAM complessivi, serve un modello unico — qwen3.6 nella variante 35B-a3b quantizzata a otto bit — tenuto sempre caldo, con duecentocinquantasei mila token di contesto e una velocità di circa ottantanove token al secondo. La domanda naturale, dopo i primi giorni di uso reale, è una sola: come lo si espande. La risposta breve è che la direzione giusta non è quella che istintivamente verrebbe da prendere.
L'istinto, davanti a un modello che gira bene, è cercarne uno più grande. È un riflesso comprensibile e quasi sempre un errore di calcolo. Il salto da un modello da trentacinque miliardi di parametri a uno da settanta, in versione densa, costa il doppio di VRAM e restituisce, sui benchmark reali, un guadagno nell'ordine del dieci o quindici per cento. Si paga il doppio per sentire pochissimo. I salti di qualità veri arrivano molto più in alto, con i modelli a mistura di esperti da duecento miliardi di parametri e oltre, che però richiedono da quattro a otto volte la VRAM attuale. C'è una valle morta in mezzo, una fascia in cui si spende e non si percepisce nulla, ed è esattamente la fascia in cui cadrebbe un upgrade fatto di pancia.
La strada alternativa è orizzontale. Invece di un cervello più grande, più cervelli specializzati che collaborano: un orchestratore che smista il lavoro a esecutori dedicati, ciascuno con il proprio compito, coordinati via chiamate a funzione. È la direzione verso cui si è mossa l'intera industria degli agenti, e ha un vantaggio decisivo sul piano economico. La maggior parte del valore non richiede hardware nuovo.
Specializzare un agente significa quasi sempre dargli istruzioni e strumenti diversi, non un modello diverso. Lo stesso modello caldo, con un prompt di sistema differente, diventa un esecutore diverso. Questo è software, non ferro.
Per ragionare sull'espansione bisogna sapere cosa limita davvero la macchina, e qui si annida il primo equivoco. Il limite non è la velocità di calcolo. È la memoria video, e in particolare il modo in cui questa viene divisa tra il modello e il contesto degli utenti.
I quarantotto gigabyte disponibili ospitano tre cose insieme: i pesi del modello, la cosiddetta cache delle chiavi e dei valori — che è la memoria di lavoro del contesto, e cresce con ogni utente collegato — e un margine di servizio. Il modello attuale occupa circa quarantatré gigabyte a pieno contesto. Restano cinque gigabyte liberi. Ogni utente che si collega con una conversazione lunga si porta via la sua fetta di cache, e quella fetta, a contesto pieno, è enorme. Ne bastano uno o due per saturare tutto.
Questo cambia il senso della parola espansione. Aggiungere memoria video non serve principalmente a far girare un modello più sveglio: serve a far stare più cose contemporaneamente, che siano più modelli specializzati residenti o più utenti collegati insieme. Chi confonde i due obiettivi compra l'hardware sbagliato.
C'è un calcolo che sembra ovvio e non lo è. Se il modello produce ottantanove token al secondo, verrebbe da pensare che possa servire ottanta utenti a un token al secondo ciascuno, spartendo la velocità come si affetta una torta. È sbagliato in entrambe le direzioni, ed è utile capire perché.
In single stream, cioè con un solo utente, la macchina passa la maggior parte del tempo a caricare i pesi del modello dalla memoria, non a calcolare. È un collo di bottiglia di banda, non di potenza. Quando si servono più utenti insieme con un motore adatto, i pesi si caricano una volta sola e si calcola per tutti nello stesso passaggio. Il risultato è che la velocità complessiva aggregata sale con la concorrenza, invece di restare fissa: si possono superare di molto gli ottantanove token al secondo come somma, anche se ogni singolo utente va più piano. La torta, contro intuizione, si allarga mentre la si taglia.
Dall'altro lato, però, un token al secondo per utente sarebbe comunque inutilizzabile. Leggere comodi richiede dai cinque ai dieci token al secondo, e un agente che lavora ne vuole molti di più. E soprattutto, come già detto, il vero tetto non è la velocità ma la memoria per la cache di ciascun utente. La conclusione onesta è che ottanta stream realmente attivi e simultanei a velocità usabile non stanno su due schede da ventiquattro gigabyte. Ottanta utenti umani che ogni tanto mandano un messaggio, invece, sono plausibili — ma solo con il motore giusto e con contesti contenuti.
Prima di disegnare qualunque architettura a più agenti, una cosa andava verificata: che il modello locale sappia usare gli strumenti in modo affidabile. L'orchestrazione vive o muore su questo. Un modello che produce chiamate a funzione malformate, che inventa nomi di strumenti o che sbaglia gli argomenti rende impossibile qualsiasi coordinamento. È il punto debole tradizionale dei modelli che girano in casa.
Il test è stato fatto con scenari mirati: una catena con dipendenza, in cui il risultato del primo strumento determina la chiamata del secondo; due chiamate parallele indipendenti nello stesso turno; una sequenza aritmetica a due passaggi; e un caso in cui lo strumento non serve affatto, per vedere se il modello sa anche trattenersi. Su tutti gli scenari il modello ha risposto correttamente, senza una sola chiamata malformata e senza inventare strumenti. La latenza tipica è rimasta tra i cinque e gli otto secondi per catena completa.
Il modello locale sa incatenare strumenti, parallelizzarli, e sa quando non usarli. La capacità su cui poggia l'intera idea di orchestrazione è presente e solida.
Resta da stressare il sistema con catene più lunghe, con strumenti che restituiscono errori e con argomenti ambigui — il banco di prova vero della robustezza — ma il segnale di partenza è inequivocabile. Le fondamenta ci sono.
La prima opzione non costa nulla e va sfruttata subito: i cinque gigabyte liberi sulla macchina attuale. Un modello di embedding è minuscolo, occupa qualche centinaio di megabyte, e abilita la ricerca semantica sui documenti senza toccare il modello principale. È il classico guadagno che non aspetta nessuno.
La seconda opzione è anch'essa software: l'orchestrazione vera e propria, costruita come strato sopra il modello già caldo. Un instradatore che riconosce il tipo di compito e lo manda all'esecutore giusto, con la possibilità di dirottare verso il cloud i compiti complessi e tenere in casa quelli semplici o riservati. Qui sta gran parte del risparmio reale, perché toglie dal servizio a pagamento tutto il lavoro banale.
La terza opzione riguarda il motore di servizio. Il sistema attuale gestisce bene un modello unico ma poche connessioni parallele, e soprattutto soffre se gli si chiede di alternare modelli diversi: ogni cambio costringe a scaricare e ricaricare, con attese di mezzo minuto. Un motore pensato per la concorrenza, con gestione a pagine della memoria e accorpamento continuo delle richieste, cambia completamente questo quadro. È il passo da fare quando il carico multiutente diventa reale, non prima.
Solo a questo punto ha senso parlare di una seconda macchina. E qui va capito bene a cosa serve. Non serve a ospitare modelli più piccoli — quelli, se piccoli sul serio, starebbero anche sulla macchina attuale. Serve a spezzare un vincolo preciso: la regola per cui un box tiene caldo un solo modello senza penalità. Una seconda macchina dedicata, con un motore adatto, può tenere residenti insieme più modelli specializzati: un instradatore leggero, un modello di embedding, magari un modello dedicato alla scrittura di codice. La macchina attuale resta il cavallo da lavoro per il ragionamento e il contesto lungo; la seconda diventa il banco degli specialisti veloci. Si aggira il vincolo per architettura, non per forza bruta.
Il numero di assistenti che la macchina serve davvero insieme non è un dato fisso del ferro: è il risultato di come la si configura. La cifra spaventosa — uno o due alla volta — vale soltanto se si pretende di dare a ciascuno il contesto massimo di duecentocinquantasei mila token. Ridotto quel contesto alla misura che serve davvero, il numero cresce in fretta, perché la memoria di lavoro consumata da ogni utente cala in proporzione diretta. A centoventotto mila token gli slot raddoppiano, a sessantaquattro mila quadruplicano. Quasi nessun turno di lavoro reale ha bisogno del contesto massimo.
La leva più potente, però, è cambiare il motore di servizio. Il sistema attuale divide la memoria in modo rigido e pre-assegnato; un motore a gestione paginata la assegna dinamicamente solo a chi sta generando in quel preciso istante, e accorpa le richieste man mano che arrivano. Da solo, questo cambio raddoppia o triplica gli slot reali utilizzabili.
C'è poi un guadagno specifico per gli assistenti costruiti sul modello brain, e vale la pena spiegarlo perché è enorme. Ognuno di questi assistenti porta con sé, a ogni richiesta, lo stesso identico blocco di istruzioni di base e di definizioni degli strumenti: decine di kilobyte ripetuti uguali. Un motore capace di riconoscere il prefisso condiviso lo tiene in cache una volta sola, invece di ricalcolarlo per ciascuno. Su prompt di sistema da centosettantadue kilobyte, la condivisione del prefisso libera una quantità di memoria che si traduce direttamente in più utenti serviti.
Restano due regolazioni di rifinitura. La cache del contesto può essere compressa più aggressivamente, scendendo dalla precisione a otto bit a quella a quattro: si guadagna spazio a fronte di una perdita di qualità trascurabile. E i modelli accessori — l'instradatore leggero, il modello di embedding — possono essere spostati altrove, lasciando la macchina principale come puro budget di memoria per gli assistenti veri. Messe insieme, queste regolazioni portano la stessa macchina da una manciata di assistenti serviti a parecchie decine.
Qui serve sciogliere un equivoco comune. La memoria di sistema, quella ordinaria — sulla macchina attuale abbondante — non accelera in alcun modo l'inferenza: la velocità dipende solo dalla memoria video. Aggiungerne non rende il modello più rapido di un millisecondo.
Fa però una cosa preziosa quando il motore di servizio è quello giusto: consente di parcheggiare in memoria ordinaria le conversazioni inattive. Un assistente esiste, è collegato, ma in un dato istante non sta generando nulla — l'utente sta leggendo, sta pensando, è andato a prendere un caffè. La sua memoria di lavoro, invece di occupare la preziosa memoria video, viene scaricata in quella di sistema e richiamata in una frazione di secondo quando arriva il messaggio successivo.
Per un carico fatto di tanti assistenti che lavorano a sprazzi, questo è il guadagno migliore in assoluto. In memoria video resta solo chi genera adesso; tutti gli altri attendono parcheggiati altrove. Si estende la capacità reale senza comprare un solo gigabyte di memoria video, che costa una decina di volte tanto.
Il prezzo da pagare è minimo: richiamare una conversazione parcheggiata aggiunge qualche centinaio di millisecondi alla prima risposta. Su un assistente che lavora a intermittenza è un ritardo che nessuno percepisce. Alzare la memoria di sistema, che costa una frazione di quella video, è quindi il modo più efficiente di allargare il numero di assistenti gestibili insieme, prima ancora di pensare a una seconda macchina.
La domanda da porsi prima di ogni acquisto non è quanto sia potente il ferro, ma a cosa serva il modello migliore. Se l'obiettivo è la qualità su compiti reali, la prova sul campo viene prima del portafoglio: spesso il modello attuale basta e avanza, e spendere sarebbe denaro buttato. Se l'obiettivo è far girare in casa molti utenti che oggi passano dal cloud, l'investimento giusto è nella concorrenza — il motore e la memoria per le cache — non nella taglia del modello. Se invece servisse la qualità di frontiera, quella dei modelli commerciali più avanzati, su ferro noleggiato non ci si arriva a un costo sensato, e la scelta razionale resta tenere il cloud per i compiti difficili e il locale per quelli semplici e riservati.
Tradotto in pratica, l'ordine si scrive da solo. Prima si stressa l'uso degli strumenti con scenari più cattivi, per confermare la robustezza oltre il primo segnale verde. Poi si costruisce l'orchestrazione come software sopra il modello già presente, perché è lì che vive il novanta per cento del valore senza accendere nulla. Si infila il modello di embedding nei cinque gigabyte liberi per avere la ricerca semantica gratis. E soltanto dopo, se e solo se il carico multiutente lo giustifica, si valuta il motore concorrente, l'aumento di memoria di sistema e, in ultima istanza, la seconda macchina — decidendola su un conto preciso di costo mensile contro cosa effettivamente ci gira, mai a sentimento.
La macchina costa trecentocinquanta dollari al mese, e questa è la cifra che cambia tutto, perché è fissa. Che serva un solo assistente o cinquanta, il conto a fine mese è identico. Il costo per utente, quindi, non è altro che trecentocinquanta diviso il numero di assistenti effettivamente serviti — e tutto il lavoro di ottimizzazione descritto qui serve esattamente a far crescere quel denominatore.
Nella configurazione attuale, non ottimizzata, la macchina regge comodamente una decina di assistenti a uso intermittente: fanno trentacinque dollari a testa al mese. Passando al motore concorrente, con contesto ridotto alla misura reale e condivisione del prefisso, gli assistenti diventano venti o venticinque, e il costo scende a quattordici-diciassette dollari ciascuno. Spingendo ancora — contesto contenuto, cache compressa, parcheggio in memoria di sistema — si arriva a quaranta o cinquanta assistenti, e il costo per utente crolla a sette-nove dollari al mese.
Il costo del singolo assistente in più è praticamente nullo, finché non si tocca il muro della concorrenza. Ogni assistente aggiunto abbassa il costo di tutti gli altri. È l'esatto contrario del servizio a consumo, dove la spesa cresce in proporzione all'uso e cinquanta assistenti attivi costano cinquanta volte uno.
Il confronto con il cloud, allora, si decide sui numeri. Un assistente servito dal cloud a consumo costa, a seconda dell'intensità d'uso, dai venti ai cento dollari al mese. Il locale ottimizzato sta tra i sette e i diciassette, e soprattutto non cresce con il consumo. Sotto i dieci assistenti il cloud spesso conviene ancora, perché non ha gestione da mantenere; superati i venti, il locale prende il largo, e più si cresce più il divario si allarga a suo favore. La macchina, in fondo, non si espande per avere un modello più intelligente. Si espande per dividere lo stesso costo fisso su più teste possibili.