Jev e il costo di una decisione

Ho integrato Jev in molti dei miei progetti perché trovo geniale l'idea di poter inserire una valutazione probabilistica dentro il software con la stessa naturalezza con cui si richiama una funzione. Le scelte attraversano continuamente un programma: a chi assegnare una richiesta, quale elaborazione avviare, quando aspettare un'informazione in più. Spesso sono passaggi minuscoli, ma dal loro incastro dipende il comportamento di tutto il sistema.

Di solito, quando parliamo di intelligenza artificiale, guardiamo quello che il modello produce davanti a noi. Una risposta, un'immagine, una porzione di codice. Jev, il modello di TypeSafe AI, porta l'attenzione su ciò che accade un momento prima: il punto in cui il programma deve capire abbastanza della situazione da scegliere come proseguire.

Immaginiamo una richiesta arrivata a un servizio informatico: «Da stamattina l'esportazione rimane ferma, ma soltanto con i file del nuovo cliente». Prima ancora di rispondere, il sistema deve capire che lavoro c'è da fare. Potrebbe bastare una procedura conosciuta, oppure servire l'esame dei registri; forse il messaggio contiene ancora troppo poche informazioni per scegliere. Affidare tutto a un modello generativo è una possibilità, ma ciascuno di questi passaggi ha esigenze diverse e potrebbe essere svolto da un componente diverso.

È un esempio ipotetico, eppure descrive bene ciò che mi interessa di Jev. Una valutazione diventa un pezzo con cui costruire altre cose. Da lì viene abbastanza spontaneo immaginare sistemi che distribuiscono il lavoro fra codice tradizionale, piccoli modelli e servizi più potenti, usando per ogni passaggio le risorse che servono davvero.

Questo modo di progettare incontra un'altra trasformazione: capacità che qualche anno fa associavamo a un servizio remoto stanno arrivando in modelli eseguibili sulle nostre macchine. Spark-X2.5 e MiniCPM5-2B appartengono a questo movimento; Apple vende computer promuovendo esplicitamente anche l'esecuzione locale dell'AI. Il risultato merita una domanda economica: se una decisione utile diventa molto meno costosa, quanto cambiano le aspettative di chi sta investendo per vendercela?

Una risposta che il programma possa usare

Jev riceve uno stato, chiamato `state`, e un insieme di domande. Lo stato è il contesto disponibile: per esempio il testo della richiesta, le informazioni sul servizio e una descrizione delle risorse che il programma può usare. Alle domande corrispondono tipi di risposta definiti in anticipo. Il codice riceve valori strutturati e distribuzioni di probabilità, senza dover cercare dentro un paragrafo la decisione che gli interessa.

TypeSafe chiama questa famiglia System One, richiamandosi alla distinzione fra pensiero rapido e ragionamento deliberato resa popolare da Daniel Kahneman. L'azienda usa l'analogia per descrivere un approccio ai compiti circoscritti: valutare separatamente domande abbastanza precise e lasciare al programma il compito di combinarne le risposte.

Una domanda `Choice` chiede di scegliere fra opzioni descritte dallo sviluppatore. Nel nostro esempio potrebbe distinguere una richiesta di istruzioni da una segnalazione da approfondire. La risposta comprende l'opzione preferita e la probabilità assegnata alle alternative. Ricevere anche la distribuzione permette di vedere se una categoria prevale nettamente o se il modello è diviso. Le opzioni, naturalmente, devono coprire le situazioni possibili: senza una categoria per i casi non riconosciuti, anche una richiesta fuori tema finirà per assomigliare a qualcosa.

Con `Score` si definisce invece una scala attraverso livelli descritti a parole. Potremmo valutare quanto una segnalazione impedisca di lavorare, distinguendo un inconveniente aggirabile da un blocco per cui non esiste una soluzione temporanea. Il risultato può trovarsi fra due livelli e viene accompagnato dalle probabilità attribuite a ciascuno. È importante descrivere le condizioni: «grave» e «molto grave» da sole dicono poco a chiunque, anche a un modello.

`Noul` risponde a una domanda sì/no restituendo una probabilità fra zero e uno. «Il messaggio indica una soluzione temporanea?» è una domanda di questo tipo. Un valore di 0,8 esprime la stima che l'affermazione sia vera; non significa che la soluzione funzioni all'80% o che il problema sia risolto quasi del tutto. Sono interpretazioni diverse, e confonderle cambierebbe il comportamento del programma.

Le tre forme si possono usare nella stessa chiamata. Secondo il contratto documentato, le domande vengono valutate in parallelo e separatamente sullo stato fornito. Così il sistema può ottenere più segnali senza trasformare ogni segnale in un ulteriore giro di conversazione. Aggiungere domande comporta comunque testo da elaborare e costi da considerare.

Gli LLM possono già restituire JSON e risposte vincolate a uno schema. Chi li usa per classificare documenti conosce bene questa possibilità. TypeSafe dichiara di addestrare Jev per ottenere valutazioni calibrate, e costruisce l'interfaccia attorno a esse. L'interesse sta nell'intero percorso, dalla domanda al risultato utilizzabile dal codice, e nell'efficienza che quel percorso può raggiungere sul compito scelto.

Il formato risolve una parte del lavoro. Una categoria valida può essere sbagliata, proprio come una variabile intera può contenere un numero errato. TypeSafe pubblica anche limiti del modello, fra cui difficoltà con calcoli, contesti ambigui e informazioni irrilevanti. Nell'esempio dell'esportazione, dunque, una risposta ben formata ci dice che il programma può leggerla; la verifica sul significato richiede esempi reali del nostro servizio.

Il numero arriva, poi bisogna decidere

Supponiamo che il sistema consideri probabile una richiesta risolvibile con la documentazione. Mandarla direttamente a un assistente locale può essere conveniente se l'errore si corregge con una seconda domanda. La stessa probabilità potrebbe essere del tutto insufficiente per cambiare una configurazione di produzione. Il contesto è simile, ma le conseguenze delle due azioni sono molto diverse.

La decisione deve tenere conto di questo scarto. Il modello offre una valutazione; chi costruisce il software stabilisce quanto costa sbagliare e quali passaggi sono ammessi. La possibilità di attendere, chiedere un dettaglio o coinvolgere una persona può essere parte normale del percorso, senza dover forzare ogni richiesta verso una risposta automatica.

Choice e Score includono un campo `confidence`, che sintetizza quanto la distribuzione sia concentrata. Una distribuzione raccolta su un'opzione appare più sicura di una dispersa fra molte. Quel numero descrive la risposta del modello e non certifica che l'azione successiva avrà successo. Per capirne l'utilità bisogna confrontarlo con gli esiti sul proprio materiale, possibilmente nella lingua e nelle condizioni in cui il sistema lavorerà.

Anche la calibrazione riguarda questo confronto. Se, su un insieme di casi, un modello assegna l'80% di probabilità a eventi che si verificano circa otto volte su dieci, le sue stime sono ben calibrate in quell'intervallo. La proprietà aiuta a scegliere soglie sensate, ma non permette di sapere in anticipo quali saranno i due casi sbagliati. Cambiare dominio o versione del modello richiede quindi di ricontrollare le prestazioni, invece di trattare la soglia come una costante universale.

Nel nostro servizio potremmo usare le valutazioni per separare il recupero di informazioni dalle operazioni che modificano qualcosa. La documentazione può essere consultata automaticamente; una variazione al sistema richiede ulteriori verifiche. I limiti di spesa e i permessi restano regole del programma. È una distinzione progettuale che rende possibile usare il componente probabilistico in molti punti senza affidargli tutte le responsabilità insieme.

Questo è anche il motivo per cui l'idea mi sembra così interessante per le infrastrutture. Un sistema complesso prende continuamente decisioni su dove eseguire un lavoro e con quali priorità. A volte basta una misura: se un nodo non ha memoria sufficiente, è escluso. Altre volte bisogna interpretare una richiesta poco strutturata o capire quale procedura corrisponda alla situazione descritta. Un valutatore semantico potrebbe aiutare in questi passaggi, mentre misure e vincoli continuano a essere gestiti dal codice.

Si può immaginare un livello di controllo che classifica il lavoro in arrivo e un meccanismo di allocazione che sceglie fra le risorse effettivamente disponibili. Una richiesta che richiede soltanto di riordinare un testo potrebbe restare su una macchina locale; un'analisi difficile prenderebbe un'altra strada. La politica può cambiare con il carico, con il budget o con il tempo disponibile. Perché funzioni, però, la classificazione deve prevedere abbastanza bene quale percorso riuscirà a completare il compito: chiamare una richiesta «semplice» non la rende tale.

TypeSafe documenta già il routing applicativo fra procedure, modelli e persone. L'estensione alla gestione infrastrutturale è una possibilità di progetto, da valutare sui singoli casi. Nell'inoltro ordinario ad alta velocità, attendere una chiamata remota per ciascun pacchetto sarebbe incompatibile con i tempi richiesti. Un valutatore del genere troverebbe più plausibilmente posto nel livello che interpreta una situazione e aggiorna una politica, lasciandone l'applicazione ai meccanismi della rete.

Quando si combinano molti risultati bisogna considerare anche le loro relazioni. Due domande valutate separatamente possono riguardare eventi dipendenti: se condividono una causa o se l'esito dell'una condiziona l'altra, moltiplicare semplicemente le probabilità può produrre una stima sbagliata. Chi conosce il sistema deve rappresentare queste dipendenze nel progetto, insieme alle conseguenze di ogni scelta.

Prima della chat, il filtro della posta

Siamo diventati molto bravi a discutere quale LLM risponda meglio, e questo può farci dimenticare quanto sia ampia la storia dell'intelligenza artificiale. Gli LLM fanno parte del machine learning, che a sua volta occupa una parte dell'AI. Anche un modello piccolo capace di classificare un messaggio appartiene a questa storia, pur senza avere nulla da raccontarci in una finestra di chat.

Nel 1998 Mehran Sahami, Susan Dumais, David Heckerman ed Eric Horvitz pubblicavano un lavoro sull'uso di un approccio bayesiano per filtrare la posta indesiderata. Il problema era quotidiano: stimare a quale categoria appartenesse un messaggio e decidere che cosa farne. Entravano già in gioco i costi diversi degli errori. Lasciar passare una pubblicità fastidiosa e nascondere una comunicazione legittima non producono lo stesso danno.

Il filtro ha un compito delimitato, riceve indizi e contribuisce a una decisione. Il suo successo si misura da quanto bene separa i messaggi che vogliamo leggere da quelli che ci fanno perdere tempo. Riconoscere questa continuità aiuta a guardare Jev attraverso le valutazioni che rende più facili da inserire in un programma, dentro una storia di decisioni probabilistiche che precede da molto il prodotto.

Nelle infrastrutture il machine learning lavora già da tempo su problemi altrettanto concreti. Resource Central, descritto da Microsoft Research, usa previsioni sul comportamento delle macchine virtuali per aiutare la gestione delle risorse in Azure. Sapere qualcosa sul carico atteso può migliorare le scelte di collocazione e utilizzo dei server. Una capacità predittiva diventa utile perché entra in un sistema che sa come adoperarla.

Questi esempi fanno emergere un limite del nostro modo di parlare di AI: la visibilità del risultato tende a decidere l'importanza che gli attribuiamo. Un testo sorprendente circola facilmente; una migliore assegnazione di risorse si nota soprattutto quando manca. Eppure la seconda può incidere sul funzionamento di un servizio a ogni richiesta.

La disponibilità di modelli interrogabili attraverso istruzioni rende accessibili alcune di queste possibilità a chi non vuole costruire da zero un classificatore per ogni nuova esigenza. Si può provare una domanda, confrontarla con casi conosciuti e inserirla in una procedura. Per un compito stabile e molto ripetuto, un classificatore specifico o una regola possono ancora essere la scelta migliore. Il vantaggio è avere più strumenti e poterli mettere alla prova, invece di trasformare ogni problema in una conversazione con il modello più grande disponibile.

La capacità entra nel computer

Intanto si sta allargando ciò che possiamo eseguire direttamente sulle nostre macchine. Spark-X2.5 è distribuito in versioni da 1,7 e 4 miliardi di parametri, con documentazione per l'uso locale anche attraverso MLX su Apple silicon. MiniCPM5-2B, di OpenBMB, offre un altro esempio di modello compatto: il nome richiama circa due miliardi di parametri esclusi quelli degli embedding, mentre il totale è intorno a 2,5 miliardi. I pesi disponibili permettono di eseguirlo con strumenti locali compatibili.

I parametri sono valori appresi durante l'addestramento. Il loro numero dà un'indicazione delle dimensioni, ma non misura da solo quanto un modello sia bravo né quanta memoria occorrerà per un'applicazione. Contano anche il modo in cui i pesi vengono rappresentati e il contesto che il sistema deve tenere durante l'elaborazione. Un modello compatto può richiedere molta più memoria quando gli chiediamo di lavorare su testi molto lunghi.

La quantizzazione riduce la precisione numerica con cui si conservano i pesi, permettendo spesso di usare meno memoria. Il compromesso va verificato sul compito: due file che portano lo stesso nome di modello possono comportarsi diversamente se cambia questa rappresentazione. Anche il tempo dedicato al ragionamento incide sul risultato. Perciò una classifica senza le condizioni del test racconta soltanto una parte della storia.

L'impressione che oggi diventino accessibili capacità per cui poco tempo fa pagavamo ha comunque un precedente misurabile. Nell'AI Index 2025, Stanford registra un calo superiore a 280 volte del prezzo d'inferenza necessario a raggiungere una prestazione equivalente a GPT-3.5 sul benchmark MMLU, fra novembre 2022 e ottobre 2024. Si tratta di una soglia su un test, non dell'intera esperienza d'uso di un assistente. Il dato mostra però quanto rapidamente possa cambiare il prezzo di una capacità definita.

Le valutazioni pubblicate per Spark-X2.5 e MiniCPM5-2B confrontano soprattutto altri modelli aperti. Non bastano a sostenere che un piccolo modello di oggi equivalga in tutto a qualunque servizio commerciale di due anni fa. Per costruire un'applicazione, del resto, serve una risposta più circoscritta: questo modello riesce a svolgere il nostro lavoro abbastanza bene, nel tempo e con la memoria disponibili?

Se la risposta è sì, possiamo scegliere dove farlo girare. Il fatto che il modello sia piccolo e il fatto che sia locale restano proprietà diverse: un piccolo modello può essere offerto via cloud, mentre una macchina dotata di molta memoria può ospitarne uno assai più grande. Anche la specializzazione è una scelta distinta. Un modello generalista compatto e un valutatore dedicato possono trovare posto nello stesso sistema senza fare lo stesso mestiere.

In un position paper del 2025, ricercatori NVIDIA sostengono l'impiego di piccoli modelli per molti compiti ricorrenti degli agenti e di sistemi eterogenei quando servono capacità differenti. La proposta porta la discussione su come distribuire il lavoro: riservare il componente più capace ai passaggi che lo richiedono, verificando quali attività possano essere affidate agli altri. Gli autori ne argomentano i vantaggi; la convenienza va poi provata nell'applicazione concreta.

Apple mostra che questa possibilità interessa anche chi vende hardware. Nel presentare il Mac Studio con M5 Max e M5 Ultra, annunciato nell'agosto 2026 e disponibile da settembre, l'azienda promuove esplicitamente l'AI sul dispositivo accanto agli altri impieghi professionali. La memoria unificata e il software per eseguire modelli entrano nell'argomento con cui vende il computer. Le workstation più capaci si rivolgono a carichi diversi da quelli di un modello da pochi miliardi di parametri, che non richiede per definizione una macchina al massimo della configurazione.

Una parte della capacità di elaborazione può così essere acquistata insieme al dispositivo, invece di essere consumata esclusivamente attraverso chiamate a pagamento. Per uno sviluppatore significa poter sperimentare con risorse che controlla; per un'organizzazione significa valutare se alcuni flussi possano restare sulla propria infrastruttura. Quando dati e modelli rimangono davvero lì, si riduce anche la necessità di trasmettere il materiale a un servizio esterno.

Il collegamento con Jev va fatto con precisione: Jev, nella forma qui descritta, è un servizio API remoto. Affiancargli un modello locale produce un sistema ibrido, non un'applicazione completamente offline. Se il router deve leggere il contenuto per scegliere la strada, quel contenuto viene inviato al router. Bisogna quindi progettare anche quali informazioni servano alla decisione, non limitarsi a spostare l'ultimo passaggio sul proprio computer.

Il prezzo della chiamata e il costo del lavoro

Possiamo tornare alla richiesta sull'esportazione bloccata. Un primo controllo esclude le risorse indisponibili. Una valutazione del messaggio aiuta a scegliere la procedura; un modello locale può formulare una domanda di chiarimento usando la documentazione pertinente. Se il caso richiede un'analisi più difficile, il programma può coinvolgere un modello remoto più potente o una persona. È una possibile architettura, la cui convenienza dipende da quanti casi ogni percorso riesce a risolvere.

Il router ha a sua volta un costo e introduce un'attesa. Se sbaglia spesso strada o manda quasi tutto al servizio più caro, il passaggio aggiunto potrebbe peggiorare il risultato. Per valutarlo bisogna contare anche i tentativi ripetuti e il lavoro necessario per correggere gli errori. Misurare il costo per compito riuscito è più utile che confrontare soltanto due prezzi per milione di token.

Il listino Jev consultato il 28 settembre 2026 indica 0,042 dollari per milione di token in ingresso, con output gratuito. Un milione di richieste da mille token fatturati ciascuna corrisponderebbe quindi a 42 dollari di sola API. È un calcolo sul listino, non il costo completo di un servizio: ci sono il software circostante, le altre elaborazioni e il tempo di chi prepara e mantiene il sistema. Le dimensioni effettive di ogni richiesta dipendono anche da quanto contesto e quante domande inviamo.

Un prezzo del genere rende interessante provare valutazioni in punti in cui prima la spesa per singola chiamata poteva scoraggiare l'esperimento. Non ci dice, però, quanto costi al fornitore produrle. Nel presentare Jev, TypeSafe ammette che servirà il lungo periodo per dimostrare la sostenibilità del prezzo e non può ancora provare che non sia sussidiato. Per chi discute di economia dell'AI, questa distinzione pesa quanto il listino.

In locale il conto cambia forma. L'hardware si acquista e si ammortizza; consuma energia, richiede manutenzione e ha un limite al lavoro che può svolgere contemporaneamente. Una macchina usata intensamente per compiti adatti può avere un'economia favorevole, mentre acquistare capacità che rimane inutilizzata per quasi tutta la giornata può costare più di un servizio remoto. Il cloud conserva un vantaggio quando serve assorbire un picco o usare occasionalmente risorse che non avrebbe senso possedere.

C'è poi il costo di imparare a usare bene gli strumenti. Preparare un insieme di esempi rappresentativi, osservare gli errori e ricontrollare un aggiornamento richiede tempo anche se l'inferenza costa poco. Quando il prezzo di esecuzione scende, questo lavoro può diventare una quota maggiore della spesa complessiva. È una buona ragione per conservare semplici le parti del sistema che già funzionano, e concentrare i nuovi componenti nei punti in cui aggiungono qualcosa di misurabile.

Un'AI che funziona può cambiare la sua bolla

Nel dibattito sulla bolla AI si mescolano spesso due domande: quanto sia utile la tecnologia e quanto denaro possano guadagnare le aziende che la offrono. La diffusione dei piccoli modelli e dei componenti specializzati rende più evidente la distanza fra le due. Possiamo usare molta più AI e, nello stesso periodo, essere disposti a pagare meno per ciascuna operazione.

Se una funzione che ieri richiedeva un servizio costoso oggi viene eseguita sul computer del cliente, il lavoro continua a essere svolto. Cambia chi incassa. Il valore può passare a chi costruisce l'applicazione, integra il sistema, vende l'hardware o offre assistenza. Una parte del beneficio può restare direttamente a chi usa il software. Per il fornitore che contava di vendere quell'operazione migliaia di volte, invece, il cambiamento può ridurre lo spazio commerciale.

Anche senza arrivare al locale, un componente economico che seleziona quali richieste meritino un modello costoso può ridurre il numero di chiamate necessarie a completare un flusso. Chi offre il modello più potente deve allora dimostrare il proprio vantaggio sui passaggi difficili. Il fatto che un sistema contenga AI smette di dire quanto spesso, e a quale prezzo, debba usare un particolare fornitore.

Da qui viene l'ipotesi che trovo interessante: alcuni investimenti potrebbero trovarsi sotto pressione proprio mentre l'AI diventa più utile. Se il piano economico presuppone ricavi elevati su compiti che diventano comuni ed economici, il successo della tecnologia può modificare le condizioni su cui quel piano era costruito. Aumentare gli utenti non basta da solo; contano il ricavo per utilizzo, i costi necessari a servirli e il capitale già impegnato.

Esiste anche il movimento opposto. Un costo più basso rende sensati impieghi che prima venivano scartati, e quei nuovi impieghi possono produrre una domanda molto maggiore. Il nome Jev contiene proprio questa scommessa: TypeSafe lo fa derivare da William Stanley Jevons e richiama il rapporto fra efficienza e aumento dei consumi. I fondatori si aspettano che decisioni meno costose allarghino enormemente gli usi dell'intelligenza artificiale.

È un'aspettativa economica da verificare. Il risparmio su ogni compito e l'aumento del numero dei compiti possono procedere insieme, senza che il secondo compensi sempre il primo nella stessa misura. Inoltre, un'espansione della domanda complessiva non garantisce che il guadagno vada alle aziende che avevano investito contando su una certa distribuzione del mercato.

Anche il discorso energetico richiede di guardare all'insieme. Nel rapporto Key Questions on Energy and AI del 2026, l'IEA descrive guadagni di efficienza e una crescita della domanda elettrica dei data center. Compiti meno onerosi possono convivere con sistemi usati più spesso e per lavori più lunghi. Il prezzo di una chiamata Jev o il numero di parametri di un modello non permettono, da soli, di calcolare i consumi finali.

Distribuire una parte dell'inferenza sui dispositivi lascia inoltre aperto il problema dell'addestramento. Un modello che utilizziamo comodamente in locale è stato costruito attraverso un altro processo, con altre necessità di calcolo. E continueranno a esistere applicazioni che richiedono modelli più capaci, grandi quantità di memoria o una gestione centralizzata del carico. Il loro peso relativo è ciò che dovremo osservare, invece di presumere che ogni progresso locale cancelli un data center.

Per valutare le aspettative sul mercato bisognerà allora osservare quali attività continuino a richiedere un servizio remoto e quanto i clienti siano disposti a pagare per il suo vantaggio. Jev e i modelli locali aggiungono alternative con cui fare il confronto. Chi costruisce un sistema usando risorse diverse può cambiare fornitore per una parte del lavoro senza dover abbandonare l'intera applicazione: è una possibilità che incide anche sulla forza contrattuale di chi vende i modelli.

Tornare a progettare le scelte

Il mio entusiasmo per Jev viene anche da qui. Mi interessa poter costruire un programma in cui l'AI interviene in passaggi precisi, e sapere perché ciascun intervento è stato messo lì. Posso usare una probabilità per smistare una richiesta e conservare nel codice i limiti entro cui eseguire il lavoro. Quando le esigenze cambiano, so quale parte riesaminare e con quali risultati confrontarla.

La richiesta sull'esportazione, alla fine, deve arrivare a qualcuno o a qualcosa che sappia risolverla. All'utente interessa riprendere il proprio lavoro, non sapere quanti modelli abbiamo coinvolto. Per chi progetta, invece, quella differenza conta: usare meno risorse per ottenere un risultato affidabile lascia spazio ad altre funzioni, ad altri progetti e a persone che prima non potevano permetterseli.

Vorrei giudicare l'AI anche da questo spazio che riesce ad aprire. Se una capacità diventa abbastanza economica da poterla usare ogni giorno sul nostro hardware, oppure abbastanza semplice da inserirla in una parte ben delimitata del codice, abbiamo guadagnato una possibilità concreta. Quanto varrà in borsa è un altro conto. Nel programma, intanto, possiamo cominciare a decidere dove ci serve.

Bibliografia e documentazione

• TypeSafe AI. Introduction; Choice; Score; Noul; Confidence; AI primer; Intent routing. Documentazione tecnica, consultata il 28 settembre 2026. Contratto delle domande, distribuzioni, calibrazione e composizione del software.
• TypeSafe AI. Models; Jev 1.13 jaggedness. Documentazione corrente, consultata il 28 settembre 2026. Versione, listino e limiti dichiarati.
• Almeida, Diogo. Introducing System One Models & Jev. TypeSafe AI, 15 settembre 2026. Presentazione del prodotto, origine del nome e precisazioni sui risultati e sulla sostenibilità economica.
• Sahami, Mehran; Dumais, Susan; Heckerman, David; Horvitz, Eric. A Bayesian Approach to Filtering Junk E-Mail. AAAI Workshop on Learning for Text Categorization, luglio 1998. Classificazione della posta e costi diversi degli errori.
• Microsoft Research. Machine Learning for Systems and Tiered AIOps, sezione Resource Central. Pagina del progetto, consultata il 9 ottobre 2026. Machine learning applicato alla gestione delle risorse cloud.
• XHToken/SparkLLM. Spark-X2.5. Repository e documentazione ufficiali, consultati il 28 settembre 2026. Versioni del modello, valutazioni pubblicate ed esecuzione locale.
• OpenBMB. MiniCPM5-2B. Scheda ufficiale del modello, consultata il 28 settembre 2026. Dimensioni, distribuzione dei pesi e valutazioni.
• Apple. Apple introduces new Mac Studio with M5 Max and M5 Ultra, 25 agosto 2026; The new Mac mini and Mac Studio are available today, 22 settembre 2026. Posizionamento del prodotto anche per l'AI sul dispositivo.
• Stanford Institute for Human-Centered Artificial Intelligence. AI Index 2025: State of AI in 10 Charts. 7 aprile 2025. Andamento storico del prezzo d'inferenza a una soglia di prestazione definita.
• Belcak, Peter, e colleghi. Small Language Models are the Future of Agentic AI. arXiv 2506.02153, 2 giugno 2025; versione 3 del 22 settembre 2026. Position paper su piccoli modelli e architetture eterogenee.
• International Energy Agency. Key Questions on Energy and AI. 16 aprile 2026. Efficienza per compito, domanda aggregata e condizioni economiche dell'espansione dei data center.