Perché l'IA agentica ha bisogno di un’insieme di tecnologie open source

"Oggi ogni laboratorio di IA, mentre lavora per la tua azienda, perde denaro. Lo sanno. E lo fanno apposta".

Questa è stata la riga di apertura di un articolo che è arrivato nella mia casella di posta la stessa settimana in cui tre numeri si sono cristallizzati, chiarendo perché l'inferenza aperta non è più facoltativa.

Uno sviluppatore ha creato una semplice app per appunti in un fine settimana, utilizzando un agente di programmazione open source con una chiave API diretta. Una pagina, una funzionalità. Costo: US$ 50. Il giorno successivo, una sottoscrizione da US$ 20 al mese ha fornito 50 volte più token.

Un ingegnere del nostro team di inferenza ha consumato 300 milioni di token tramite modelli open-weight in due giorni, svolgendo lo stesso lavoro che sarebbe costato migliaia di dollari tramite API proprietarie.

I primi due numeri mostrano il sussidio. Il terzo rivela la via d'uscita. Il motivo per cui abbiamo bisogno di questa soluzione sono gli agenti.

Il modello di prezzo è in fase di transizione

I fornitori di modelli di frontiera hanno fatto qualcosa di straordinario. Hanno reso l'IA di livello mondiale accessibile a milioni di sviluppatori, a prezzi che sarebbero stati impensabili due anni fa. Questa accessibilità ha portato a un'esplosione dell'adozione. Ha anche creato una struttura economica che potrebbe non essere sostenibile ai ritmi attuali.

Il sito web Is AI profitable yet? tiene traccia del quadro finanziario generale del settore dell'IA. Le aziende di IA attualmente spendono circa il 195% delle proprie entrate. Un partecipante alla discussione ha calcolato che, nell’equivalente in dollari per il 2024, la spesa in conto capitale totale per l'IA in 10 anni è stata circa tre volte i costi per il sistema autostradale interstatale degli Stati Uniti. Questi sono i tipi di investimenti che alla fine si rifletteranno nei prezzi dei servizi.

I segni di questa transizione stanno già comparendo. Sono circolate notizie secondo cui alcune grandi aziende stanno riconsiderando le licenze degli strumenti di codifica dell'IA, poiché la fatturazione basata su token sostituisce le sottoscrizioni forfettarie, con costi per ciascun ingegnere che raggiungono i US$ 500-2.000 al mese. I modelli di frontiera più recenti offrono modesti miglioramenti dei benchmark consumando il 10-25% di token in più per attività. L'offerta di GPU è già vincolata per i prossimi tre-quattro anni e diversi fornitori di cloud GPU hanno già esaurito la capacità.

Nulla di tutto questo è una critica ai fornitori. Stanno costruendo il futuro e definendo i prezzi in modo aggressivo per accelerare l'adozione. I costi unitari per token continueranno probabilmente a diminuire e Gartner prevede una riduzione del 90% entro il 2030. Tuttavia, come osserva la stessa analisi, i carichi di lavoro agentici consumano così tanti token in più per attività, che si prevede che la spesa totale per l'inferenza aziendale aumenterà nonostante le unità più economiche. Goldman Sachs prevede un aumento del consumo di token di 24 volte entro il 2030. Le aziende che pianificano per i prossimi tre-cinque anni dovrebbero prepararsi a costi aggregati più elevati, non inferiori. I modelli open source eseguiti su un'infrastruttura autogestita sono la valvola di sfogo che aiuterà a mantenere l'IA accessibile con l'aumentare dei consumi.

Figura 1: Il paradosso dei costi dell'inferenza agentica. I costi per token diminuiscono del 90% (Gartner), ma il consumo totale aumenta di 24 volte (Goldman Sachs), con un conseguente aumento della spesa aziendale aggregata, nonostante le unità più economiche.

Gli agenti hanno cambiato l'equazione

Il prezzo delle sottoscrizioni è stato progettato per gli esseri umani che digitano a velocità umana. Gli agenti generano un numero di chiamate API esponenzialmente più grande e nessun modello di prezzo esistente è stato creato per questo.

Un collaboratore di OpenClaw ha consumato US$ 1,3 milioni in token API OpenAI in un solo mese. Si tratta di 603 miliardi di token su 7,6 milioni di richieste provenienti da circa 100 istanze Codex gestite da tre persone. In un solo giorno, l'account ha registrato una spesa di US$ 19.985,84.

Jensen Huang ha affermato che il consumo di token degli agenti è aumentato di circa 1.000 volte rispetto all'utilizzo tradizionale dei modelli. Nel podcast Latent Space, Marc Andreessen ha affermato che il suo ambiente spende US$ 1.000 al giorno in token Claude che eseguono agenti, con una domanda latente compresa tra US$ 5.000 e US$ 10.000 al giorno per ogni agente personale completamente distribuito. Anche con un miglioramento del prezzo di 10 volte, si tratta comunque di US$ 100 al giorno. "Ancora ben oltre ciò che le persone possono pagare."

Alcuni fornitori hanno già dovuto limitare l'esecuzione di framework di agenti di terze parti con sottoscrizioni forfettarie perché le richieste di calcolo superavano ciò che il modello di prezzo poteva sostenere. I prezzi forfettari e i carichi di lavoro degli agenti autonomi sono strutturalmente incompatibili.

Il costo è solo una parte del problema. I carichi di lavoro agentici hanno requisiti tecnici che le API proprietarie non sono mai state progettate per esporre.

Frammentazione delle API. Il panorama delle API agentiche presenta diversi standard in competizione: Chat Completions (il formato stateless originale di OpenAI), Responses API (il più recente formato stateful di OpenAI con strumenti integrati e integrazione del Model Context Protocol), Messages API (il formato di Anthropic) e Interactions API (il protocollo agentico di Google). Ciascuno gestisce in modo diverso le chiamate agli strumenti, la gestione dello stato e il ragionamento. Ogni harness ne sceglie uno diverso.

Ogni famiglia di modelli racchiude inoltre la stessa chiamata allo strumento in tag completamente diversi. L'invio di get_weather(city="Seattle") a cinque modelli produce cinque formati diversi. Llama usa la sintassi Python con <|python_tag|>, Mistral usa [TOOL_CALLS] con array JSON, Gemma usa i tag <tool_code> e Hermes usa <tool_call>XML. Il motore di inferenza ha bisogno di un parser separato per ogni famiglia di modelli.

Chiamata degli strumenti. Dietro un'API proprietaria, ottieni il parser dal fornitore. Non puoi personalizzarlo. Non puoi correggere un modello che restituisce una sintassi Pythonic invece del suo formato di addestramento. Sei un passeggero.

Routing dei modelli. L'esecuzione di un singolo agente genera sotto-attività eterogenee: alcune richiedono un ragionamento approfondito, altre una classificazione rapida e altre ancora la generazione di codice. L'indirizzamento di queste attività a modelli diversi richiede il controllo del livello di distribuzione. Dietro l'API di un singolo fornitore, ogni attività va allo stesso modello allo stesso prezzo.

Ingegneria del contesto. Per gestire ciò che raggiunge il modello con diversi passaggi serve ottimizzare con al massimo. Una pipeline di contesto ben ottimizzata può ridurre l'utilizzo dei token del 60-80% migliorando al contempo la qualità dell'output. Tuttavia, un'efficace ingegneria del contesto richiede l'accesso al comportamento del modello a livello di inferenza, perché devi misurare ciò a cui il modello presta effettivamente attenzione, identificare quali token di contesto contribuiscono alla qualità dell'output e ottimizzare le strategie di riepilogo e recupero in base a modelli di attenzione reali, non in base a delle ipotesi.

Interruttori automatici. Senza il controllo sul livello di inferenza, non puoi implementare un budget per agente, il rilevamento delle anomalie o l’arresto automatico a livello di server del modello. Essendo stato dall'altra parte di un ciclo fuori controllo, posso dirti che il fornitore non ti salverà.

Gli economisti lo chiamano il paradosso di Jevons. William Stanley Jevons notò questo schema nel 1865. Con l'aumento dell'efficienza dei motori a carbone, il consumo totale di carbone è aumentato. I token IA si trovano sulla stessa traiettoria. Ogni aumento di efficienza sblocca nuovi scenari di utilizzo che consumano più del risparmio ottenuto. I risultati per token incoraggeranno le aziende ad utilizzare più IA, non meno.

I modelli aperti sono pronti per il lavoro agentico

Come accennato in precedenza, il nostro team di inferenza ha elaborato 300 milioni di token utilizzando modelli open-weight in due giorni. Nemotron 3 Super, Gemma 4 e Qwen 3.6, tutti in esecuzione sullo stack di inferenza Red Hat AI. Il risultato è stato sufficientemente valido per le revisioni delle pull request, le implementazioni di primo passaggio e le indagini mirate, alleggerendo il lavoro che altrimenti andrebbe ai modelli di frontiera, accumulando costi per i token.

Il divario di costo non è trascurabile. I benchmark sulle GPU Blackwell consumer mostrano che una GPU da US$ 500 che esegue modelli open-weight può elaborare 30 milioni di token al giorno. Con questo volume, recuperi il costo dell'hardware entro tre mesi rispetto a quanto costerebbe lo stesso carico di lavoro tramite fornitori di API di fascia economica a circa US$ 0,20 per milione di token. Rispetto ai prezzi delle API di frontiera, il periodo di ritorno sull'investimento scende a pochi giorni.

Un ricercatore ha creato un agente di codifica che ha ottenuto l'87% nei benchmark utilizzando un modello che attiva solo quattro miliardi di parametri per token. Gli agenti che utilizzano modelli da 14 miliardi di parametri hanno ottenuto il 75%. La differenza non era il modello, ma gli strumenti composti e un ciclo di feedback degli errori. È l'harness a completare il lavoro più pesante , non le dimensioni del modello.

Adattare i modelli aperti agli scenari agentici richiede una reale ingegneria, ed è esattamente ciò che l'open source consente. Una recente demo di Gemma 4 in esecuzione con OpenCode e Claude Code mostra l'aspetto pratico, con regolazioni personalizzate dei template di chat, ottimizzazione del parser delle chiamate agli strumenti per ciascuna famiglia di modelli e formattazione dei prompt su più standard API. Il modello da quattro miliardi di parametri richiedeva una gestione diversa rispetto alla versione quantizzata da 26 miliardi di parametri, che a sua volta richiedeva una gestione diversa rispetto al modello da 31 miliardi di parametri.

Questo è il tipo di lavoro che colma il divario tra le prestazioni dei benchmark e le prestazioni agentiche nel mondo reale. Comporta la traduzione tra le API per il completamento di chat, messaggi e risposte e l'analisi dell'output del modello con logica fuzzy, perché a volte ai modelli mancano i token di avvio delle chiamate agli strumenti o generano una sintassi imprevista influenzata dai prompt di sistema dell'harness.

Questo lavoro viene svolto upstream in vLLM, nei template di chat dei fornitori di modelli e nelle segnalazioni di bug degli harness. Questo può avvenire solo in modo aperto. Con un server di inferenza proprietario, non puoi inviare una correzione per un template di chat, ottimizzare un parser di chiamate agli strumenti né tantomeno osservare per capire perché l'output del tuo agente fallisce. Con l'open source, ogni correzione avvantaggia ogni utente e ogni aggiornamento del parser è permanente. Questo lavoro di integrazione upstream, che rende i modelli open-weight affidabili per i carichi di lavoro agentici nell'intero stack di distribuzione, è un obiettivo centrale di Red Hat AI.

L’insieme di tecnologie di inferenza agentica

Ci sono otto livelli che devono collaborare per l'inferenza agentica su scala aziendale. Ogni livello interagisce con tutti gli altri.

Figura 2: Lo stack di inferenza agentica, da agente e harness, in alto, passando per la traduzione delle API, il gateway, i guardrail, la distribuzione disaggregata, la configurazione del server dei modelli, il motore di inferenza e infine l'hardware, in basso. I bordi rossi evidenziano i due livelli in cui risiede la maggior parte del lavoro di compatibilità agentica. Il riquadro tratteggiato della sandbox racchiude il livello dell'agente dove l'esecuzione del codice e i controlli di sicurezza sono più rigorosi.

Assemblare questi livelli da singoli progetti open source è possibile, ma operativamente costoso. Il vantaggio di una piattaforma di inferenza autogestita come Red Hat AI è dato dal fatto che i livelli sono integrati in uno stack testato e supportato che viene eseguito sulla tua infrastruttura, così i tuoi dati non lasciano mai il tuo perimetro di sicurezza e tu controlli il ciclo di aggiornamento, la selezione del modello e la policy di routing.

Il livello delle API agentiche

Il problema della diversità delle API è reale. Gli harness utilizzano Chat Completions, Responses, Messages API o Interactions API e non è detto che il server del modello alla base le supporti tutte. Il livello delle API agentiche si colloca tra l'harness e l'infrastruttura, per aiutare a colmare questa lacuna. Progetti come OGX (precedentemente noto come Llama Stack) forniscono implementazioni aperte delle API agentiche stesse: Chat Completions, Responses, Messages API e Interactions API, insieme a funzionalità supplementari come vector store, gestione dei file ed esecuzione di strumenti, il tutto sopra qualsiasi livello di model serving in esecuzione.

Al momento, nessuno standard API si sta affermando come vincitore, nonostante il vantaggio iniziale di alcune API. L'importante è avere implementazioni open source di tutte, così puoi abbinare qualsiasi harness a qualsiasi modello ogni volta che ne hai bisogno. Quando il livello di traduzione è aperto, preserva l'intero contratto di chiamata dello strumento e ti consente di vedere esattamente cosa succede alla tua richiesta. Quando un fornitore proprietario gestisce la traduzione, non saprai mai cosa va perso.

llm-d: Scala l'inferenza agentica

vLLM a istanza singola funziona per un ingegnere che esegue agenti, ma non funziona per cento ingegneri che utilizzano contemporaneamente gli stessi modelli. llm-d è il livello di distribuzione disaggregato che suddivide l'inferenza in fasi separate di prefill e decodifica, consentendo di sfruttare la scalabilità indipendentemente su hardware diversi. Per i carichi di lavoro agentici, dove molte richieste brevi si intrecciano con lunghe catene di ragionamento, questa architettura è sempre più essenziale.

Guardrail e sandboxing

Anche la sicurezza dei contenuti fa parte di questo stack e deve essere consapevole degli agenti. I framework di guardrail che operano come proxy devono preservare l'intero contratto delle API agentiche, incluse le definizioni e la scelta degli strumenti e i parametri di ragionamento, altrimenti rischiano di deteriorare silenziosamente il comportamento dell'agente.

Guardrail agentici efficaci richiedono anche l'accesso a dati a livello di inferenza che il semplice filtraggio del testo di input/output non può fornire, come tracce di ragionamento per valutare se la catena di pensiero del modello contiene passaggi non sicuri prima dell'output finale, parametri di chiamata dello strumento per convalidare che gli strumenti e gli argomenti richiamati siano conformi alla policy, probabilità logaritmiche a livello di token (logprobs) per rilevare il rischio di allucinazione e output a bassa confidenza, e metadati di generazione per audit trail e log di conformità. Questo è un altro motivo per cui il livello di inferenza dovrebbe essere aperto. I guardrail che vedono solo il testo in entrata e in uscita sono insufficienti per i carichi di lavoro agentici. 

Se il tuo proxy di guardrail è una scatola nera che rimuove i parametri di chiamata degli strumenti, quando i tuoi agenti falliscono, non puoi diagnosticarne il motivo. I guardrail open source (come l'endpoint /v1/guardrails/checks non basati su proxy di NVIDIA NeMo Guardrails) applicano la sicurezza dei contenuti senza violare il contratto delle API agentiche.

Il sandboxing è un altro fattore. Gli agenti eseguono codice, scrivono file e richiamano strumenti. La difesa in profondità richiede un isolamento stratificato, che includa confinamento a livello di container, policy di rete, restrizioni sul file system e applicazione del runtime. Mettere un agente in un container non è sufficiente. Il confine della sandbox nel diagramma dello stack racchiude l'agente e l'harness, perché è lì che può avvenire l'esecuzione di codice arbitrario e dove i controlli di sicurezza devono essere più rigorosi.

Perché l'open source vince

Non puoi testare uno stack di otto livelli se ciò che succede nella metà dei livelli non è visibile. Non puoi eseguire il debug di chiamate agli strumenti fallite se non puoi vedere il parser. Non puoi garantire la sicurezza se il proxy dei guardrail scarta silenziosamente i parametri necessari agli agenti. Lo stack presenta dipendenze molto strette perché i singoli livelli siano offuscati. Red Hat AI è stato creato per integrare e rafforzare insieme questi livelli, in modo che le aziende non debbano assemblare lo stack da sole.

Oltre alle motivazioni tecniche, l'inferenza aperta è necessaria per ragioni strutturali che vanno oltre il costo.

Figura 3: Inferenza aperta rispetto alle API proprietarie per i carichi di lavoro agentici. Le API proprietarie sono all'avanguardia per facilità di configurazione e qualità dei modelli di frontiera. L'inferenza aperta è superiore nelle sette funzionalità da cui dipendono i carichi di lavoro agentici in produzione: routing del modello, debugging delle chiamate agli strumenti, personalizzazione del dominio, budget per agente, residenza dei dati, indipendenza dal fornitore e guardrail a livello di inferenza.

L'istruzione accelera l'intero settore. L'open source offre due cose: software libero e conoscenza libera. DeepSeek R1 lo ha mostrato chiaramente. I modelli proprietari disponevano di capacità di ragionamento già mesi prima che la community più ampia potesse replicarle. A partire dalla pubblicazione del codice e del documento da parte di DeepSeek, ogni grande laboratorio ha acquisito capacità di ragionamento entro tre mesi. L'effetto della diffusione della conoscenza è più prezioso del modello stesso. Applicata all'inferenza agentica, ogni correzione del parser delle chiamate agli strumenti, ogni miglioramento del template di chat e ogni patch dell'harness compone un'infrastruttura condivisa in tutto l'ecosistema.

La fiducia richiede trasparenza. Non tutte le organizzazioni sono disposte a instradare tutti i propri dati e flussi di lavoro attraverso diversi fornitori di modelli cloud. Per alcune è una questione di rigorosa conformità. Settori come la sanità e la finanza devono affrontare rigidi requisiti normativi in materia di privacy e residenza dei dati. Per altre è una scelta strategica, per evitare il vendor lock-in e mantenere la piena proprietà della proprietà intellettuale.

L'open source offre alle organizzazioni la scelta di eseguire i modelli alle proprie condizioni, entro i propri perimetri di sicurezza, con piena visibilità sul funzionamento del sistema. Per i settori regolamentati, la pubblica amministrazione e i carichi di lavoro sensibili alla sicurezza, questo è un requisito. La regolamentazione si sta muovendo nella stessa direzione: gli obblighi di trasparenza dell'EU AI Act, applicabili da agosto 2026, richiedono una documentazione tecnica che copra l'architettura del modello, le procedure di addestramento e le caratteristiche prestazionali. I modelli open source che già pubblicano queste informazioni hanno diritto a esenzioni che i modelli chiusi non hanno.

La personalizzazione richiede pesi. Dietro un'API chiusa, ogni organizzazione esegue lo stesso modello. Quando possiedi i pesi sulla tua infrastruttura, puoi eseguire il fine tuning per il tuo dominio, i tuoi strumenti interni e le convenzioni del tuo codebase senza inviare dati proprietari all'esterno. Le organizzazioni sanitarie eseguono il fine tuning per la terminologia clinica e i formati delle cartelle cliniche dei pazienti. I team legali adattano i modelli al linguaggio e alle strutture contrattuali specifiche della giurisdizione. Gli istituti finanziari addestrano i modelli sui propri modelli di rischio e framework di conformità proprietari. Per i carichi di lavoro agentici, questa è la differenza tra un agente generico e uno che capisce già come funzionano i tuoi sistemi.

L'open source crea gravità nell'ecosistema. Quando i fornitori di hardware investono in software di inferenza open source, modelli più accessibili favoriscono una più ampia adozione dell'hardware. Gli investimenti nelle ottimizzazioni di vLLM (il runtime di inferenza) e i miglioramenti allo stack di serving open source rendono ogni GPU più capace di gestire carichi di lavoro agentici e consentono il riutilizzo dell'hardware. Il risultato è un circolo virtuoso in cui i miglioramenti del software open source si estendono a tutto l'ecosistema.

La fase successiva favorisce i modelli distribuiti Il modello emergente è "incentrato sul contesto condiviso", con molti modelli che lavorano su knowledge graph e store di contesto condivisi. Questo sposta l'attenzione da un singolo modello massiccio a un ecosistema di modelli specializzati, coordinati da un harness intelligente. Non hai necessariamente bisogno di un modello in grado di fare tutto. Più spesso, avrai bisogno di molti modelli specializzati, ognuno dei quali fa bene ciò che deve fare, lavorando insieme come un sistema composto. Tale architettura è intrinsecamente più aperta e distribuita.

Le architetture di agenti emergenti come Pi e OpenClaw, tra le altre, sono già costruite in questo modo. Il loro design è minimale e spesso include un modello linguistico di grandi dimensioni (LLM), una bash shell, un file system, file di stato markdown e un ciclo cron. Lo stato vive nei file, non nei pesi, quindi puoi scambiare l'LLM senza perdere la memoria dell'agente. Questi agenti funzionano con qualsiasi modello, chiuso o aperto. Ma quando l'intero stack è aperto, dai pesi del modello attraverso l'infrastruttura di serving, ogni vantaggio strutturale si somma: esegui il fine tuning per il tuo dominio, instradi tra modelli che controlli, osservi con strumenti di tua proprietà e scambi qualsiasi livello senza interrompere il resto. Questo è ciò che rende l'inferenza aperta una base naturale per l'IA agentica e Red Hat AI la piattaforma che la alimenta. 

Come prepararsi

Tre cose da fare ora, prima che vengano introdotte modifiche ai prezzi.

Figura 4: Tre azioni per prepararsi all'inferenza agentica aperta, ognuna con strumenti specifici dello stack Red Hat AI. La timeline mostra un passaggio, in 12 mesi, dalla portabilità delle API all'infrastruttura agentica completa e autogestita.

Crea un harness indipendente. Il modo in cui progetti il tuo harness agentico e i tuoi agenti conta quanto il modello che esegui, se non di più. Se i tuoi agenti sono codificati rigidamente sull'API di un singolo fornitore, ti troverai nel vincolo prima che arrivino le modifiche ai prezzi. Dovresti puntare alla portabilità dei modelli e delle API. È qui che si inseriscono progetti come OGX, disponibili tramite Red Hat AI, che forniscono il livello di traduzione aperto tra le Chat Completions, Responses, Messages API e Interactions API. In questo modo, i tuoi agenti manterranno la portabilità, indipendentemente dal modello o dal fornitore alla base.

Ospita autonomamente il volume su infrastruttura gestita. Una singola GPU che esegue un modello Gemma 4 o Qwen quantizzato può già gestire revisioni delle pull request, documentazione e riepilogo del codice. Usa le sottoscrizioni API per i carichi di lavoro che necessitano realmente di un ragionamento di frontiera, o dove i modelli di frontiera mantengono ancora un chiaro vantaggio qualitativo, e ospita autonomamente il resto sull'infrastruttura che controlli. Una piattaforma di inferenza autogestita gestisce la complessità operativa di model serving, scalabilità, routing e osservabilità, per consentire al tuo team di concentrarsi sulla creazione di agenti anziché sulla manutenzione dello stack di serving. 

Poiché i modelli open source continuano a colmare il divario con le capacità di frontiera, i carichi di lavoro che puoi ospitare autonomamente non faranno che aumentare. Iniziare ora crea la prontezza operativa di cui avrai bisogno quando i modelli aperti copriranno l'intero stack. La ricerca sul routing dei modelli mostra che indirizzare la maggior parte delle richieste a modelli più piccoli o ospitati autonomamente, passando alle API di frontiera solo per i compiti complessi, può ridurre i costi del 60-85% con una perdita di qualità minima.

Esegui test end-to-end su tutto lo stack agentico. Un modello che supera i benchmark può comunque fallire quando l'harness lo sollecita in modo errato, il parser degli strumenti interpreta male l'output o il gateway instrada i compiti sbagliati. Testare le combinazioni modello-harness-configurazione è l'approccio corretto.

Includi anche il budgeting dei token nel tuo processo. Limiti per agente. Attribuzione per funzionalità. Rilevamento delle anomalie. MLflow Tracing , già inserito nello stack Red Hat AI, acquisisce prompt, passaggi di ragionamento, invocazioni di strumenti e costi dei token con la piena compatibilità OpenTelemetry. È meglio avere gli avvisi relativi al budget prima che diventino necessari.

Costruisci per il futuro

L'hardware normalmente si deprezza. Nel caso delle GPU per l'inferenza aperta succede il contrario. I chip non cambiano, ma il software che vi gira sopra continua a migliorare. Batching e attention kernel migliori in vLLM consentono di gestire più token al secondo con lo stesso hardware. Le scoperte nella quantizzazione permettono di far stare in 20 GB modelli che un tempo richiedevano 80 GB, con una qualità paragonabile. Il serving disaggregato suddivide i carichi di lavoro in modo che lo stesso cluster gestisca più agenti simultaneamente. Una GPU enterprise acquistata tre anni fa produce oggi un'inferenza più utile rispetto a quanto facesse il giorno dell'installazione, perché lo stack open source è migliorato attorno ad essa.

Questo effetto cumulativo è il filo conduttore di tutto questo ragionamento. I parser delle chiamate agli strumenti aperti migliorano per tutti. I template di chat aperti risolvono la compatibilità una volta per tutte, in modo permanente. I guardrail aperti che preservano il contratto delle API agentiche proteggono ogni distribuzione, non solo i clienti di un singolo fornitore. Il serving disaggregato aperto si estende all'hardware che già possiedi.

Ecco a cosa serve una piattaforma IA open source. Non solo a servire modelli, ma a possedere l'intero stack di inferenza agentica sulla propria infrastruttura, dal livello API che traduce tra harness e modello, attraverso il gateway che instrada e misura, fino al motore di serving e all'hardware su cui gira, quello che chiamiamo "dai componenti fisici agli agenti". I tuoi dati rimangono entro il tuo perimetro di sicurezza. I tuoi modelli lavorano dove scegli tu. I tuoi costi sono prevedibili perché controlli ogni livello. Ogni livello è aperto. Su ogni livello è possibile eseguire il debugging. Ogni miglioramento è condiviso.

I modelli sono validi (e migliorano ogni giorno). Lo stack sta prendendo forma. L'aspetto economico è chiaro. Non dobbiamo chiederci se l'inferenza agentica aperta avverrà (è già una realtà), ma se saremo pronti quando arriverà il conto.