Foundry Local: Microsoft prova a rendere l’AI locale meno dolorosa

Negli ultimi anni abbiamo spostato qualunque cosa nel cloud, compresa la speranza. Con l’AI però stiamo riscoprendo un fatto banale: non sempre ha senso mandare dati, audio, documenti e contesto utente a un servizio remoto per ottenere una risposta che magari poteva essere calcolata direttamente sul dispositivo. Foundry Local nasce esattamente in questo spazio: portare modelli AI dentro le applicazioni, vicino all’utente, con un runtime pensato per gestire modelli, accelerazione hardware e inferenza locale.

Con Foundry Local, Microsoft sta provando a risolvere proprio questa parte meno glamour: non “fare AI”, ma distribuire AI locale in modo ripetibile dentro applicazioni vere.

L’annuncio pubblicato sul Microsoft Foundry Blog il 4 giugno 2026 presenta gli aggiornamenti di Foundry Local 1.2.0 e di Foundry Local on Azure Local, con un focus chiaro: portare modelli, agenti e inferenza più vicino al punto in cui i dati vengono generati, cioè device, AI PC, ambienti industriali, infrastrutture ibride e scenari disconnessi.

Perché l’AI sull’edge è ancora difficile

La promessa dell’AI locale è semplice: meno latenza, più privacy, funzionamento offline, più controllo sui dati. La realtà, come sempre, ha deciso di vestirsi da condominio.

Chi sviluppa applicazioni AI on-device deve spesso gestire:

• packaging dei modelli;
• runtime diversi;
• differenze tra CPU, GPU e NPU;
• accelerazione hardware non uniforme;
• aggiornamenti dei modelli;
• deployment su macchine diverse;
• fallback quando l’hardware non è quello sperato.

Microsoft lo dice esplicitamente: i team devono spesso risolvere frammentazione del runtime, packaging dei modelli, differenze hardware e complessità di deployment prima ancora di consegnare una singola feature affidabile.

È qui che Foundry Local diventa interessante. Non perché inventi l’inferenza locale, ma perché cerca di renderla un componente applicativo gestibile.

Che cos’è Foundry Local

Foundry Local è una soluzione per costruire applicazioni AI che girano direttamente sul dispositivo dell’utente. Secondo il repository ufficiale, include SDK nativi per C#, JavaScript, Python e Rust, un catalogo curato di modelli ottimizzati e accelerazione hardware automatica in un pacchetto leggero, indicato intorno ai 20 MB.

Il punto importante è questo: l’applicazione non deve necessariamente parlare con un servizio cloud per ogni richiesta. Il modello può girare localmente, i dati restano sul device, non c’è latenza di rete, non servono API key, non c’è un backend da mantenere e non si paga a token.

Naturalmente questo non significa che il cloud sparisca. Significa che alcune classi di funzionalità AI possono essere spostate vicino all’utente: riassunti locali, ricerca semantica, assistenti privati, trascrizione audio, automazioni leggere, classificazione, redazione, RAG su documenti locali. Cioè tutte quelle cose dove mandare ogni bit al cloud sembra un po’ come spedire una cartolina a se stessi per ricordarsi dove si abita.

Le novità della versione 1.2.0

La versione 1.2.0 di Foundry Local introduce alcune novità interessanti, soprattutto per chi vuole ragionare su scenari reali e non solo su demo da keynote.

La prima è il supporto alla trascrizione ASR multilingua con il modello Nemotron 3.5 ASR Streaming Multilingual, con supporto dichiarato per oltre 40 lingue. La versione precedente aveva già introdotto la trascrizione live, ma con la 1.2.0 Microsoft allarga il caso d’uso verso scenari vocali internazionali.

La seconda è il supporto a Linux ARM64, includendo sistemi come Raspberry Pi 5, NVIDIA Jetson, AWS Graviton e Ampere. Questo è importante perché l’edge vero non vive solo sui laptop premium da influencer tecnologico, ma anche su dispositivi piccoli, industriali, embedded e spesso molto meno eleganti.

La terza è il miglioramento del download dei modelli tramite catalogo cross-region basato su Azure Traffic Manager. L’obiettivo è ridurre il tempo del primo download del modello, che nella pratica è uno dei momenti in cui l’utente decide se la tua app è “AI-powered” o “rotellina-powered”.

Poi ci sono miglioramenti più da sviluppatori veri: cancellazione dei download e dell’inferenza, supportata nei vari SDK, progresso di download per execution provider in Python e aggiornamento a Windows ML 2.0, con l’obiettivo di semplificare l’uso di accelerazione NPU e GPU su Windows senza dipendenze aggiuntive dal Windows App SDK.

Il punto tecnico: astrazione dell’hardware

Il pezzo più interessante non è il modello specifico. I modelli cambiano di continuo, come le mode JavaScript ma con più GPU. Il punto vero è l’astrazione dell’hardware.

Foundry Local promette di rilevare automaticamente l’hardware disponibile e selezionare il miglior execution provider tra NPU, GPU e CPU. Il repository ufficiale descrive proprio questa capacità: rilevamento automatico dell’hardware e selezione del provider più adatto.

Questa cosa è molto meno appariscente di “abbiamo un modello più intelligente”, ma per chi distribuisce software è fondamentale. Se devo supportare Intel, AMD, Qualcomm, NVIDIA, magari Apple Silicon, più varianti Windows/Linux/macOS, non voglio scrivere cinque pipeline diverse solo per far partire una funzione di completamento testo.

In teoria, Foundry Local dice: tu integri l’SDK, scegli un modello dal catalogo, e il runtime si occupa di download, caching, caricamento, inferenza e accelerazione.

In pratica, andrà testato. Perché tra “automatic hardware acceleration” e “funziona bene sul portatile del cliente con driver installati da un tecnico nel 2021” c’è sempre un canyon pieno di ticket Jira.

API familiari e approccio OpenAI-compatible

Un’altra scelta intelligente è il supporto a formati compatibili con le API OpenAI. Il repository indica che Foundry Local supporta request e response format OpenAI-compatible, inclusa la Responses API, e che un’app già basata su OpenAI SDK può essere indirizzata verso un endpoint Foundry Local con modifiche minime.

Questo è strategico perché abbassa la barriera d’ingresso. Gli sviluppatori non devono imparare un paradigma completamente nuovo: possono riusare pattern già familiari, client già noti e, in alcuni casi, parte del codice già scritto.

È anche un segnale più ampio: il mondo dell’AI applicativa si sta muovendo verso interfacce comuni. Il valore non sta solo nel modello, ma nel modo in cui lo incapsuli dentro app, workflow, agenti, tool e sistemi esistenti.

Un esempio concreto: voice input in GitHub Copilot CLI

Microsoft cita un caso pratico interessante: il voice input in GitHub Copilot CLI. Quando l’utente detta un prompt nel terminale, l’audio viene catturato dal microfono, passato a una sessione di trascrizione live Foundry Local con modello Nemotron ASR Streaming, e i risultati vengono inseriti direttamente nel buffer di input della CLI. Tutto avviene on-device, senza passaggio cloud per l’audio.

Questo esempio rende bene il tipo di UX che Foundry Local abilita: non necessariamente “chatbot locale generico”, ma piccole funzionalità AI integrate dove serve immediatezza.

Voice input, captioning, comandi vocali, note automatiche, assistenti locali: sono tutti scenari in cui la latenza e la privacy contano davvero. Non per filosofia, ma perché l’esperienza utente degrada subito se ogni interazione deve fare il giro del mondo prima di tornare nel tuo terminale.

Foundry Local non è un server inference stack

È importante non confondere Foundry Local con un sistema server-side per servire modelli a tanti utenti contemporaneamente. La FAQ del repository è abbastanza chiara: Foundry Local è ottimizzato per dispositivi hardware-constrained e scenari single-user; per carichi multiutente sono più adatti stack come vLLM o Triton Inference Server.

Questa distinzione è fondamentale.

Foundry Local ha senso quando il modello gira sul dispositivo dell’utente, dentro o vicino all’applicazione. Non è pensato per rimpiazzare un’infrastruttura cloud GPU condivisa. Quindi: ottimo per app desktop, AI PC, dispositivi edge, assistenti locali, workflow privati. Meno sensato per costruire “il mio ChatGPT aziendale per 10.000 utenti” su un singolo runtime locale, perché poi piangiamo tutti, e io non ho nemmeno le ghiandole lacrimali.

Foundry Local on Azure Local: il lato enterprise/edge

L’annuncio include anche Foundry Local on Azure Local, in preview, pensato per eseguire modelli, agenti e tool su infrastrutture on-premises. Microsoft lo descrive come una piattaforma AI on-prem basata su workload containerizzati Kubernetes su Azure Local, orchestrati tramite Azure Arc.

Qui il target cambia: non più solo app locale sul device dell’utente, ma ambienti enterprise, regolamentati, sovrani, industriali o disconnessi.

Le funzionalità annunciate includono un model catalog su Azure Local, agentic retrieval, tool MCP custom, template di soluzioni, GitHub Enterprise Local e supporto ad Azure Local per dispositivi small form factor.

Questo è il pezzo più “enterprise Microsoft”, quindi naturalmente arriva con Kubernetes, Arc, governance e abbastanza acronimi da far partire una stampante laser da sola. Però il problema è reale: molte aziende non possono o non vogliono mandare tutti i dati nel cloud pubblico, soprattutto in scenari industriali, finanziari, sanitari, pubblici o sovrani.

Dove può essere utile davvero

Foundry Local può avere senso in almeno cinque scenari.

Primo: app desktop AI-first, dove vuoi offrire funzioni locali anche offline.

Secondo: document intelligence privata, ad esempio riassunto, Q&A e classificazione su file locali.

Terzo: assistenti vocali e trascrizione, dove la latenza è visibile e l’audio è sensibile.

Quarto: edge industriale, dove connettività e compliance sono spesso vincoli duri.

Quinto: riduzione dei costi di inferenza, perché non tutto deve diventare una chiamata cloud fatturata a token.

Microsoft cita casi d’uso e integrazioni con realtà come Foxit, Raycast, Rakuten, PhonePe, Cephable, AnythingLLM e altri, soprattutto su privacy, portabilità hardware e riduzione della complessità di runtime.

I limiti da tenere presenti

Foundry Local è promettente, ma non è magia. Purtroppo. Sarebbe comodo, ma poi gli sviluppatori perderebbero il loro principale hobby: soffrire vicino a una console.

I limiti da valutare sono:

Catalogo curato, non universo infinito di modelli.
Foundry Local non punta a supportare qualunque modello esistente. Il catalogo è intenzionalmente curato per modelli ottimizzati e testati per l’uso on-device.

Prestazioni dipendenti dall’hardware.
L’astrazione aiuta, ma un modello locale resta vincolato da memoria, acceleratori disponibili, driver, sistema operativo e dimensione del modello.

Non è pensato per concorrenza server-side.
Per scenari multiutente serve un runtime server progettato per batching, code e condivisione GPU.

Deployment comunque da testare sul campo.
La promessa “build once, run closer to the data” è interessante, ma in produzione vanno verificati dimensioni, aggiornamenti, cold start, caching e fallback.

Perché è una mossa importante

Foundry Local si inserisce in un trend più grande: l’AI applicativa non sarà solo cloud, e non sarà solo locale. Sarà ibrida.

Il cloud resterà centrale per modelli grandi, training, orchestrazione, task complessi e capacità scalabile. Ma molte feature quotidiane possono girare vicino all’utente: più veloci, più economiche, più private e più resilienti.

La parte difficile è rendere tutto questo distribuibile. Non basta dire “usa un modello quantizzato”. Serve un runtime. Serve un catalogo. Serve hardware acceleration. Serve una strategia di aggiornamento. Serve un modo per non impazzire su ogni variante di silicon.

Foundry Local è interessante perché Microsoft sta provando a impacchettare tutto questo dentro un’esperienza da SDK, con API familiari e un approccio orientato alla produzione.

Foundry Local non va letto come “l’ennesimo modo per far girare un modello in locale”. Va letto come un tentativo di portare l’AI on-device dentro il normale ciclo di sviluppo software.

La differenza è sottile ma importante.

Far partire un modello locale è una demo.
Distribuirlo dentro un’app, gestirlo su hardware diversi, aggiornarlo, accelerarlo, cancellare inferenze, scaricare modelli, supportare più linguaggi e mantenere una UX decente: quello è prodotto.

E lì Foundry Local diventa interessante.

Per chi sviluppa applicazioni desktop, edge o enterprise con requisiti di privacy, latenza o funzionamento offline, vale la pena provarlo. Non perché risolva ogni problema, ma perché affronta il problema giusto: trasformare l’AI locale da esperimento fragile a componente applicativa gestibile.

Che è una cosa meno sexy di “agente autonomo multimodale”, ma molto più utile. Quindi naturalmente riceverà meno hype. L’umanità è coerente almeno nei suoi errori.