Il 7 ottobre 2026 Microsoft ha annunciato, nell’ambito della presentazione “Building Windows for hybrid intelligence”, il supporto a llama.cpp dentro Windows ML, il runtime di inferenza AI integrato in Windows 11. È una notizia che a prima vista sembra di nicchia, ma per chi sviluppa applicazioni .NET o C++ con componenti AI locali cambia un vincolo architetturale non banale: fino a ieri, per far girare un modello su Windows ML dovevi convertirlo in formato ONNX. Da oggi, in anteprima sperimentale, puoi caricare direttamente modelli GGUF — lo stesso formato usato da Ollama, LM Studio e da gran parte dell’ecosistema open source che pubblica pesi quantizzati su Hugging Face — senza passare dalla pipeline di conversione.

Perché Windows ML esiste e cosa cambia con llama.cpp

Windows ML è diventato generalmente disponibile nel settembre 2025, distribuito a partire dalla versione 1.8.1 del Windows App SDK su Windows 11 24H2 e successivi. La sua proposta di valore è semplice da descrivere e complessa da realizzare: fare da layer di abstraction hardware tra il codice dell’app e NPU, GPU e CPU, senza che lo sviluppatore debba scrivere codice diverso per ogni fornitore di silicio.

Il meccanismo si basa su Execution Provider (EP): componenti che i partner hardware (AMD, Intel, NVIDIA, Qualcomm) costruiscono e mantengono, e che Windows ML scarica, registra e aggiorna automaticamente via Windows Update. In pratica:

• AMD espone Ryzen AI tramite il Vitis AI EP, su NPU, GPU e CPU dei processori Ryzen.
• Intel usa un EP basato su OpenVINO, con selezione automatica tra CPU, GPU integrata o NPU sui Core Ultra.
• NVIDIA offre TensorRT for RTX, che genera motori di inferenza ottimizzati per la GPU specifica installata, con un guadagno dichiarato superiore al 50% rispetto a DirectML.
• Qualcomm fornisce il Qualcomm Neural Network EP (QNN EP) per la NPU degli Snapdragon X, oltre a GPU e CPU tramite gli EP standard di ONNX Runtime.

Fino a questo annuncio, l’unico formato di modello che Windows ML sapeva eseguire era ONNX. Chi partiva da un modello PyTorch o da un checkpoint Hugging Face doveva convertirlo con l’AI Toolkit per VS Code (quantizzazione, ottimizzazione, compilazione) prima di poterlo caricare. Funziona bene per modelli di visione o per architetture stabili come ResNet, molto meno bene per l’ecosistema degli LLM open source, dove le release si susseguono settimanalmente e la community pubblica quasi sempre in GGUF, non in ONNX.

Il supporto a llama.cpp chiude questo gap: Windows ML diventa in grado di caricare GGUF nativamente, usando llama.cpp come motore di esecuzione sotto il cofano, mentre resta disponibile anche la via ONNX per i casi in cui serve il massimo controllo su quantizzazione e grafo di calcolo. Microsoft specifica che si tratta di funzionalità sperimentale (preview), insieme a un’anteprima nativa di API di inferenza Windows e a un ampliamento del supporto PyTorch e Triton, incluso su Windows Arm64. Il consiglio ufficiale è di verificare gli scenari supportati prima di usarla in produzione.

L’API di Windows ML oggi: cosa puoi già scrivere

Anche in attesa che la documentazione GGUF-specifica si stabilizzi, vale la pena capire come è strutturata l’API Windows ML attuale, perché il flusso concettuale (inizializza gli EP, carica il modello, compila una volta, esegui l’inferenza) resterà probabilmente lo stesso anche per i modelli GGUF. Il punto di ingresso è il package NuGet Microsoft.WindowsAppSDK.ML, che espone sia API WinRT sia la superficie compatibile con ONNX Runtime.

Primo passo: creare l’ambiente ONNX Runtime e lasciare che Windows ML scarichi e registri gli Execution Provider certificati per l’hardware corrente.

// Crea l'ambiente ONNX Runtime con le opzioni di logging
EnvironmentCreationOptions envOptions = new()
{
    logId = "DemoApp",
    logLevel = OrtLoggingLevel.ORT_LOGGING_LEVEL_ERROR
};
OrtEnv ortEnv = OrtEnv.CreateInstanceWithOptions(ref envOptions);

// Windows ML individua l'hardware disponibile e scarica
// gli Execution Provider certificati per quel dispositivo
var catalog = Microsoft.Windows.AI.MachineLearning.ExecutionProviderCatalog.GetDefault();
await catalog.EnsureAndRegisterCertifiedAsync();

// Configura la policy di selezione dell'EP: qui si privilegia
// il basso consumo energetico (tipicamente la NPU, se presente)
var sessionOptions = new SessionOptions();
sessionOptions.SetEpSelectionPolicy(ExecutionProviderDevicePolicy.MIN_OVERALL_POWER);

Il dettaglio interessante per chi deve gestire il deployment: gli EP non vengono inclusi nel pacchetto dell’app. Windows ML li scarica a runtime in base all’hardware rilevato, con un risparmio dichiarato “da decine a centinaia di megabyte” sulla dimensione dell’installer, e la possibilità di aggiornarli indipendentemente dall’app stessa tramite Windows Update.

Secondo passo: la compilazione del modello per l’EP scelto, un’operazione one-time per dispositivo il cui risultato viene cachato localmente:

string compiledModelPath = Path.Combine(executableFolder, "model-compiled.onnx");
bool isCompiled = File.Exists(compiledModelPath);

if (!isCompiled)
{
    using var compileOptions = new OrtModelCompilationOptions(sessionOptions);
    compileOptions.SetInputModelPath(modelPath);
    compileOptions.SetOutputModelPath(compiledModelPath);
    compileOptions.CompileModel();
    isCompiled = File.Exists(compiledModelPath);
}

var modelPathToUse = isCompiled ? compiledModelPath : modelPath;

Terzo passo: l’inferenza vera e propria, con la stessa API InferenceSession familiare a chi ha già usato ONNX Runtime in altri contesti (server, Azure Functions, desktop):

using var session = new InferenceSession(modelPathToUse, sessionOptions);

var inputName = session.InputMetadata.First().Key;
var inputTensor = new DenseTensor<float>(inputData, new[] { 1, 3, 224, 224 }, false);

var inputs = new List<NamedOnnxValue>
{
    NamedOnnxValue.CreateFromTensor(inputName, inputTensor)
};

var results = session.Run(inputs);
var outputName = session.OutputMetadata.First().Key;
var outputTensor = results.First(r => r.Name == outputName).AsEnumerable<float>().ToArray();

Chi preferisce C++ trova un’API praticamente equivalente (Ort::ModelCompilationOptions, Ort::Session, Ort::Value), utile se il tuo progetto è già un’app WinRT/C++ nativa. Con il supporto llama.cpp, l’aspettativa ragionevole — in base a come Microsoft ha descritto l’integrazione — è che il caricamento di un file .gguf si inserisca in questo stesso flusso come alternativa al passaggio di conversione ONNX, piuttosto che richiedere un’API completamente separata.

Cosa significa in pratica per chi sviluppa su Windows

Il contesto in cui arriva questo annuncio non è casuale. Microsoft lo inquadra dentro una strategia più ampia di “hybrid intelligence”: Copilot su Windows comincia a combinare modelli cloud e modelli locali in base al task, e i PC Copilot+ eseguono già, secondo i dati citati da Microsoft, oltre 2.000 miliardi di inferenze locali al mese. L’apertura a llama.cpp e GGUF è il tassello che permette a chi sviluppa con questi strumenti open source — già oggi lo standard de facto per far girare LLM in locale su CPU/GPU consumer — di appoggiarsi all’infrastruttura di distribuzione e accelerazione hardware di Windows ML, invece di gestire manualmente binari di llama.cpp compilati per ogni combinazione di GPU e driver.

Per un team che oggi distribuisce un’app con un modello locale integrato tramite llama.cpp “nudo”, i vantaggi concreti del passaggio a Windows ML sono essenzialmente tre: non devi più compilare e distribuire build separate di llama.cpp per NVIDIA, AMD, Intel e Qualcomm; gli aggiornamenti delle accelerazioni hardware arrivano via Windows Update senza una nuova release della tua app; e la selezione dell’EP (NPU per basso consumo, GPU per throughput, CPU come fallback universale) diventa una policy dichiarativa (ExecutionProviderDevicePolicy) invece di logica scritta a mano per rilevare l’hardware.

Il rovescio della medaglia, va detto con chiarezza vista la natura “experimental” della feature: prima di spostare un prodotto in produzione su questa via, conviene verificare quali modelli GGUF e quali quantizzazioni sono effettivamente supportate oggi, dato che Microsoft stessa invita alla cautela. Per prototipi, tool interni e applicazioni che già puntano su Windows 11 24H2+, è però un buon momento per iniziare a sperimentare: la direzione — portare l’ecosistema open source dei modelli locali dentro un runtime gestito e accelerato dal sistema operativo — sembra ormai una scelta strategica di lungo periodo da parte di Microsoft, non un esperimento isolato.

Per iniziare

Chi vuole provare da subito Windows ML con i modelli ONNX esistenti può partire dal repository ufficiale WindowsAppSDK-Samples, che contiene il progetto completo usato come riferimento in questo articolo, e dalla AI Toolkit per VS Code per la conversione di modelli PyTorch. Per il supporto GGUF/llama.cpp, essendo ancora in fase sperimentale, la raccomandazione è monitorare la documentazione ufficiale su Microsoft Learn prima di integrarlo in un progetto destinato alla produzione.

Fonte: Windows Blog — “Building Windows for hybrid intelligence”, 7 ottobre 2026; documentazione tecnica su Microsoft Learn — Windows ML overview.