01 Perché non è uno scoreboard
La tentazione era mettere i due studi in una tabella affiancata e vedere chi porta i numeri migliori. Non si può fare, e vale la pena essere espliciti sul perché prima di qualsiasi altra cosa.
Non c'è una metrica in comune. Lo Studio A misura accuratezza di classificazione, MRR di retrieval, punteggi di rubrica su riassunti e risposte. Lo Studio B misura token al secondo, tempo di prefill, occupazione VRAM, hit rate della cache, euro al mese. Nessuna delle due liste contiene un elemento dell'altra.
Non c'è un modello in comune. Lo Studio A ha provato GPT-5.2, Qwen3.5-122B e GLM-5.2. Lo Studio B ha provato qwen3.6-35b-a3b, qwen3-30b-a3b, llama3.3-70b, qwen3-235b-a22b e Mistral Large 123B. Famiglie diverse, taglie diverse, quantizzazioni diverse.
Non c'è un'infrastruttura in comune. Lo Studio A ha girato su API di inferenza europea a noleggio. Lo Studio B ha girato su box GPU noleggiati e amministrati direttamente, con lo stack di serving montato a mano.
Le due domande sono ortogonali. "Quale modello produce output migliore" e "cosa costa farlo girare e cosa si rompe" sono problemi diversi, e nessuno dei due studi tocca il territorio dell'altro. Questo documento li mette in fila.
Questo documento è stato prodotto con l'intelligenza artificiale, a partire dai dati reali dei due studi. Le verifiche sono sommarie: le misure dello Studio B sono di giugno 2026 e i prezzi cambiano in fretta, quindi vanno riviste prima di prenderci una decisione sopra. Da leggere come base di discussione, non come istruttoria chiusa.
02 Cosa ha misurato ciascuno
Studio A — il cervello
- Domanda
- Un modello a pesi aperti regge il confronto con un frontier proprietario su un carico documentale reale?
- Oggetto
- ~600 ticket reali di assistenza post-vendita, multilingue, dominio singolo.
- Pipeline
- Arricchimento semantico (riassunto per indicizzazione + metadati strutturati) e assistente RAG sopra il corpus arricchito.
- Metriche
- Accuratezza di classificazione, MRR e hit@k di retrieval, rubrica 1-5 a doppio giudice cieco su riassunti e risposte, verifica deterministica delle citazioni.
- Non misura
- Costo in euro. Ferro. Concorrenza. Latenza sotto carico. On-premise.
Studio B — il ferro
- Domanda
- Cosa serve per far girare un modello open al servizio di un carico agentico reale, e quanto costa?
- Oggetto
- Box GPU noleggiati: 2×3090 (48GB) a canone mensile in produzione, 8×3090 (192GB nominali) a ore per il benchmark dei modelli grandi.
- Pipeline
- Serving con Ollama dietro proxy autenticato, agente completo con prompt di sistema da ~40K token e 26 tool, in uso reale da utente.
- Metriche
- Token al secondo, prefill, riuso della KV cache, VRAM per modello e per contesto, latenza aggregata a N utenti, euro/mese ed euro/ora.
- Non misura
- Qualità dell'output con rigore. Nessuna rubrica, nessun giudice cieco, nessun corpus annotato.
Sulla qualità, lo Studio B non ha dati opponibili. Le sue valutazioni sono aneddotiche — un modello è stato scartato perché "sparava fatti sbagliati", giudizio a occhio di una persona sola, non una misura. Sul terreno della qualità i numeri buoni sono quelli dello Studio A e vanno presi per buoni. Il contrario vale sul costo e sul serving.
03 Studio A — la qualità
Tre modelli sulla stessa pipeline, stessi prompt, stessa tassonomia. Cinque dimensioni, misura oggettiva dove possibile e giudizio cieco a doppio revisore dove la misura diretta non c'era.
| Dimensione | GPT-5.2 frontier | Qwen3.5-122B open | GLM-5.2 open | Lettura |
|---|---|---|---|---|
| Classificazione (macro-categoria) | 96,0 % | 90,2 % | 88,6 % | L'unico terreno dove il frontier stacca. ~6-7 punti. |
| Retrieval (MRR, 563 query) | 0,365 | 0,357 | 0,385 | Nessuna differenza statisticamente significativa. |
| Retrieval (hit@5) | 46 % | 45 % | 49 % | Idem. Misura oggettiva, senza giudici. |
| Riassunti (rubrica 1-5) | 4,57 | 3,99 | 4,38 | Frazioni di punto, salvo la fedeltà di Qwen (3,44). |
| Risposte (rubrica 1-5) | 4,89 | 4,19 | 4,47 | Voto assoluto al frontier. |
| Risposte (testa a testa) | 6 / 20 | — | 14 / 20 | Vincitore opposto rispetto al voto assoluto. |
| Citazioni inventate (su 131) | 0 | 0 | 0 | Proprietà dell'architettura, non del modello. |
| Latenza risposta | 54 s | 15 s | 67 s | Unico dato di performance dello studio. |
Conclusione dello Studio A: parità sostanziale salvo la classificazione rigorosa in tassonomia, che è l'unico compito dipendente dal modello. E soprattutto: la qualità finale non è emersa dalla scelta dell'LLM, è emersa dall'ingegneria dell'impianto — prompt, validazione strutturata dei metadati, grounding, architettura di retrieval.
Il claim più rumoroso poggia sul campione più piccolo. Il "14 su 20" del testa a testa sono 10 domande per 2 giudici. n=10.
C'è una contraddizione interna che lo studio nota e non spiega. Stessi giudici, stesse risposte: il frontier vince il voto assoluto e perde il testa a testa 6-14. Uno dei due numeri sta misurando qualcos'altro.
La parità sul retrieval è reale ma su un livello assoluto modesto. hit@5 al 46% in known-item — cioè cerchi un documento usando la sua stessa descrizione originale e lo ritrovi nei primi cinque meno di una volta su due. O l'impianto è migliorabile, o la metrica è inadatta a un corpus di ticket quasi-duplicati, dove pescare il caso gemello non è un errore. Lo studio non distingue.
04 Studio B — il ferro
I modelli, misurati sullo stesso ferro
| Modello | Generazione | Riuso cache | VRAM | Note |
|---|---|---|---|---|
| qwen3.6 35b-a3b q8 · MoE ibrido | 88 tok/s | sì, a prefisso stabile | 43 GB @ 256K | Il produzione. Attenzione ibrida: 256K di contesto costano pochi GB. |
| qwen3 30b-a3b q8 · MoE full-attn | 138 tok/s | sì · 0,06 s | 42,8 GB @ 160K | Più veloce, ma scartato: 3B attivi, sbagliava i fatti. |
| llama3.3 70b q4 · dense | 18,7 tok/s | sì · 0,06 s | 52 GB | Qualità buona, troppo lento su 2×3090. |
| qwen3 235b-a22b q4 · MoE | 46,1 tok/s | sì · 0,02 s | 145 GB | 2,5× il 70b dense. Richiede 8 GPU sane. |
| Mistral Large 123B · dense | 11,6 tok/s | — | 106 GB @ 48K | Unico a entrare comodo su 7 GPU col prompt agentico da 40K. |
Il risultato che conta: un nonce da cinque caratteri valeva 10× l'esperienza utente
Il carico reale è un agente completo: prompt di sistema da ~40.000 token (istruzioni, contesto, 26 definizioni di tool) identico a ogni turno. Su un prefisso così, il riuso della KV cache non è un'ottimizzazione: è la differenza tra usabile e inusabile.
Per settimane la diagnosi è stata sbagliata. I log dicevano forcing full prompt re-processing due to lack of cache data (likely due to SWA or hybrid/recurrent memory) e la conclusione — scritta e riscritta per nove revisioni — era: limite architetturale del modello, non patchabile. Ogni turno pagava ~19 secondi fissi di re-prefill.
La causa vera era altrove. Catturando e diffando due prompt reali consecutivi, divergevano al carattere 79 su 27.000:
# prompt turno 1 x-anthropic-billing-header: cc_version=...; cc_entrypoint=sdk-cli; cch=1ead0;... # prompt turno 2 — identico ovunque tranne qui x-anthropic-billing-header: cc_version=...; cc_entrypoint=sdk-cli; cch=fb051;...
Un nonce di cache-control iniettato dall'SDK client in testa al prompt, che cambia a ogni richiesta. Serve alla prompt-cache del suo provider originale; dirottato su un'inferenza self-hosted diventa un cache-killer perfetto, perché invalida tutto il prefisso a valle. Una riga per normalizzarlo:
body = re.sub(rb"cch=[0-9a-f]+", b"cch=00000", body)
Stesso modello, stesso ferro, stessa quantizzazione. La differenza era interamente fuori dal modello.
Gli altri modi in cui l'impianto ti tradisce
- Health-ping clobber. Il gateway faceva un ping di salute ogni ~6 secondi, e quel ping era una micro-inferenza. Su uno slot singolo ogni ping sovrascriveva la KV cache della conversazione in corso. Un controllo di monitoraggio che distruggeva la cosa che monitorava.
- Thrashing da modello. In 48GB ci sta un modello. Qualunque client chiedesse un modello diverso ne provocava lo sfratto e un reload da 30-78 secondi. Risolto con un proxy che forza modello e contesto centralmente, invece di inseguire la configurazione di ogni client.
- Concorrenza. Sul 235b a slot singolo: 1 utente 33,8 tok/s con 3,0 s di latenza; 4 utenti 41,8 tok/s con 6,2 s; 8 utenti 43,5 tok/s con 10,5 s. Il throughput aggregato tappa intorno ai 43 tok/s, la latenza per utente cresce lineare. Va bene per bassa concorrenza; per decine di utenti simultanei serve un engine con continuous batching.
- Lotteria hardware. Su un box da 8 GPU, una era guasta (
RmInitAdapter failed). Non degradava: avvelenava l'inizializzazione CUDA dell'intero gruppo, sotto il livello dove si possono escludere i device per indice. Il reboot non risolveva. La soluzione è stata staccarla fisicamente dal bus PCI, restando con 7 GPU su 8 pagate. - Il vincolo che decide la taglia. Il 235b q4 pesa 142GB. Su 7 GPU (165GB) restano ~20GB di KV: a contesto 8K gira, ma il prompt agentico ne vuole 40K+ e la VRAM satura fino all'impallamento. Non è un limite del modello, è aritmetica.
- Provisioning. Il flag "Available now" del listino ha significato mezza giornata di attesa reale.
05 La convergenza
Qui i due studi, che non condividono una metrica, dicono la stessa cosa.
Studio A
«La qualità finale non è emersa dalla scelta dell'LLM: è emersa dall'ingegneria dell'impianto.»
Le prove: lo stesso modello con lo stesso costo produce risultati radicalmente diversi a seconda del prompt. La validazione strutturata protegge i dati indipendentemente dal modello. Zero citazioni inventate su 131 per tutti e tre — il grounding è una proprietà dell'architettura di retrieval, non del modello più potente.
Studio B
«Stesso modello, stesso ferro: 19 secondi a turno o 102 millisecondi, a seconda di cinque caratteri nel prefisso.»
Le prove: il nonce del client valeva 10× l'esperienza percepita. Il ping di monitoraggio distruggeva la cache. Il thrashing dipendeva dalla configurazione dei client, non dal modello. Nessuno di questi problemi si risolve cambiando modello, e nessuno si vede guardando i benchmark.
Lo Studio A trova che l'impianto semantico domina il modello: prompt, validazione, grounding, retrieval. Lo Studio B trova che l'impianto di serving domina il modello: stabilità del prefisso, cache, thrashing, VRAM. Due gruppi, due domini, nessuna metrica condivisa, stessa risposta: il modello non è il collo di bottiglia.
Ed è una convergenza utile, non una coincidenza retorica: il punto cieco di ciascuno è la specialità dell'altro. Lo Studio A conclude "conta l'impianto" senza aver mai amministrato il serving. Lo Studio B lo dimostra sul serving senza aver mai misurato la qualità con rigore.
06 L'economia, e un'ammissione
Questo è il territorio dove lo Studio A tace — la sua tabella dei costi ha tre celle: "alto / basso / basso", senza una cifra — e dove lo Studio B ha numeri veri, perché le fatture le ha pagate.
Cosa costa il ferro (listino reale, giugno 2026)
| Configurazione | VRAM | Costo | Cosa ci gira |
|---|---|---|---|
| 2×3090 · canone mensile | 48 GB | 349-350 €/mese | 35B q8 a 256K di contesto, 88 tok/s. Il produzione noto. |
| 1×A6000 · canone mensile | 48 GB | 499 €/mese | Stessa VRAM su scheda datacenter (ECC, niente tensor-parallel). |
| 8×3090 · a ore | 192 GB | 4,80 €/ora | 235B q4. Test effimero: ~7-14 € il benchmark completo. |
| 8×3090 · canone mensile | 192 GB | 999-1.600 €/mese | 235B con margine di contesto. Fuori budget. |
Affittare o comprare
A 350 €/mese, una scheda equivalente comprata (~9-10.000 € operativi) pareggia in tre o quattro anni. Su un orizzonte finanziario puro affittare vince. Comprare ha senso per una ragione sola, e non è il costo: la sovranità del dato, cioè non far transitare informazioni personali su ferro di qualcun altro. Va detto che anche il box noleggiato è ferro di qualcun altro — è un miglioramento rispetto al mandare tutto a un provider di frontier, non una privacy assoluta.
Self-host o cloud: il break-even
L'analisi economica dello Studio B, scritta a giugno prima che questa discussione esistesse, conclude testualmente: «sotto ~200 utenze stabili il cloud vince; oltre, il self-host si ripaga e porta sovranità.»
Il che significa che a 20 utenti un box da 48GB a 350-400 €/mese non si ripaga. È abbondantemente sotto la soglia degli ~80 che servono solo a pareggiare. Chi sostiene che a volumi bassi un piano flat su inferenza a noleggio convenga rispetto al ferro dedicato, ha dalla sua i numeri dello Studio B — non solo la propria intuizione.
Sarebbe stato più comodo non scriverlo. Ma un confronto che seleziona i propri dati non è un confronto, è una brochure.
07 La domanda che decide
Il break-even qui sopra ha un presupposto che nessuno dei due studi ha messo in discussione: è calcolato su richieste interattive. Utenti che scrivono, aspettano, leggono. A quel regime, un box dedicato passa la maggior parte del tempo acceso a non fare niente, e il costo per richiesta utile esplode.
Ma un box a canone fisso ha una proprietà che il consumo a token non ha: il costo marginale del lavoro aggiuntivo è zero. Le ore notturne sono già pagate. Un arricchimento semantico in batch su decine di migliaia di documenti — esattamente il carico dello Studio A — su cloud a consumo si paga token per token, su ferro a canone è gratis.
Nessuno dei due studi ha calcolato il break-even includendo il batch a costo marginale zero. Lo Studio A non tocca il costo. Lo Studio B ha modellato solo il traffico interattivo. Eppure è lì che si decide: se il carico è 20 utenti e basta, il noleggio a token vince e la discussione è chiusa. Se sono 20 utenti più un batch notturno pesante, il canone fisso può ribaltare il conto — e nessuno ha ancora messo i numeri.
La variabile decisiva non è quale modello, e non è nemmeno quanto costa un token. È quanto lavoro non interattivo hai da buttare nelle ore che paghi comunque.
08 Il metodo, due volte
C'è un ultimo parallelo, ed è il più onesto dei due studi: entrambi hanno preso una cantonata, e l'hanno presa allo stesso modo.
Studio A
Un campione preliminare di 50 query suggeriva un vantaggio del frontier sul retrieval. Sul campione completo di 563 query, il vantaggio è svanito.
E prima ancora: un panel di giudici che leggevano i testi aveva pronosticato un vantaggio per i riassunti più ricchi. La misura oggettiva ha ribaltato il pronostico.
Da lì il principio dichiarato: dove una metrica si può misurare, si misura; il giudizio solo dove la misura non è possibile.
Studio B
Nove revisioni consecutive di teoria sull'attenzione ibrida per concludere che il modello non poteva riusare la cache: limite architetturale, non patchabile, documentato con tanto di issue upstream.
Poi tre richieste byte-identiche, dieci righe di script: 2,072 s → 0,054 s → 0,047 s. Cachava eccome. L'invalidazione era legittima — il prefisso cambiava davvero, per via del nonce del client.
Un test controllato da tre secondi valeva più di nove revisioni di teoria.
Entrambi hanno costruito una conclusione plausibile su un'evidenza insufficiente, e in entrambi i casi è stata una misura banale a demolirla — non un'analisi più sofisticata. Un campione più grande da una parte, un test a prefisso controllato dall'altra.
È il motivo per cui questi due studi meritano di stare nella stessa pagina anche senza una metrica in comune: condividono l'unica cosa che li rende utilizzabili, cioè la disponibilità a smentirsi con un esperimento invece di difendersi con un argomento.
In sostanza
- I due studi non si confrontano: nessuna metrica, nessun modello, nessuna infrastruttura in comune. Chi li mette in tabella sta costruendo il risultato.
- Sulla qualità i dati buoni sono dello Studio A: i modelli open sono in parità sostanziale col frontier, salvo la classificazione rigorosa in tassonomia.
- Sul costo e sul serving i dati buoni sono dello Studio B: il ferro ha un listino, la cache ha un prezzo, l'hardware noleggiato arriva rotto una volta su otto.
- Entrambi concludono, da strade opposte, che il modello non è il collo di bottiglia. È l'impianto — semantico per l'uno, di serving per l'altro.
- Sull'economia a volumi bassi, i numeri dello Studio B danno ragione allo scetticismo, non all'entusiasmo per il ferro dedicato: sotto ~200 utenze stabili il noleggio vince.
- La sola variabile che può ribaltare il conto — il batch a costo marginale zero — non è stata misurata da nessuno dei due. È lì che va fatto il prossimo esperimento.