Llama.cpp V1.0.0 definisce le regole di stabilità delle API per gli strumenti di IA locali

ggml-org ha annunciato llama.cpp v1.0.0 il 13 novembre 2026, definendo un accordo formale di compatibilità per gli sviluppatori che utilizzano a valle il progetto di inferenza locale dell’IA in C/C++. Anche la libreria di tensori ggml sottostante ha raggiunto la versione 1.0.0; il progetto dichiara di supportare oltre 150 varianti di architetture di modelli e tutti i principali metodi di decodifica speculativa.

Il controllo delle versioni diventa un impegno pubblico

Entrambi i progetti segnaleranno le future incompatibilità delle API a livello di codice sorgente e dell’ABI, l’interfaccia binaria utilizzata dalle applicazioni compilate, incrementando il numero di versione principale. Le modifiche incompatibili alle API pubbliche in C comportano un aumento della versione principale. Le funzionalità compatibili con le versioni precedenti, gli aggiornamenti dei backend, il supporto dei modelli e le aggiunte alle API comportano un aumento della versione secondaria, mentre le correzioni di bug che non modificano le API comportano un aumento della versione di patch.

La politica arriva dopo 3,5 anni di sviluppo e una crescente dipendenza dalle interfacce delle librerie del progetto. llama.cpp offre l’inferenza multimodale degli LLM attraverso libllama, mentre ggml fornisce il livello di tensori per l’apprendimento automatico attraverso libggml. Il software utilizza la quantizzazione, backend ottimizzati e codice C/C++ portabile per funzionare su hardware che va dai computer degli utenti ai server aziendali.

Questo offre ai responsabili della manutenzione dei pacchetti e agli sviluppatori di applicazioni un’indicazione sulla versione per valutare se un aggiornamento possa compromettere la loro integrazione. La discussione del 7 agosto 2026 dei responsabili del progetto sul processo di rilascio aggiunge una misura di protezione correlata: viene creato un tag ufficiale di rilascio di llama.cpp solo quando la copia interna di ggml è identica a quella rilasciata. La condizione mira a mantenere le build associate ai tag di rilascio compatibili con un’installazione di ggml a livello di sistema, come avviene nei pacchetti Debian e Homebrew descritti nel documento.

Modifiche a runtime, modelli e server

Le note di rilascio di llama.cpp v1.0.0 accompagnano questo impegno con un’importante opera di pulizia. La versione rimuove le API pubbliche deprecate, comprese 35 funzioni, e promuove l’API di decodifica speculativa NextN dall’ llama-ext.h header di estensione all’header pubblico llama.h header. Questo passaggio inserisce l’interfaccia di decodifica speculativa nelle API pubbliche coperte dalle nuove regole di versionamento.

Le nuove funzionalità di inferenza includono cache key-value (KV) in virgola mobile a 8 bit OCP (FP8), una cache nella memoria host per i modelli mixture of experts (MoE) con una quota di CPU configurabile e il caricamento di dati PLE o engram esterni da shard GGUF separati. Le aggiunte ai modelli comprendono le architetture testuali Kimi-K3.1-Pro, Ripple e xing4_0, la sintesi vocale drama-3 e il supporto della visione per MageVL-Cowork e Kimi-K3.1.

Per llama-server, la versione affronta i problemi di richiesta contraffatta lato server (SSRF), condivisione delle risorse tra origini diverse (CORS) e riassociazione DNS, e limita l’accesso HF_TOKEN agli host huggingface.co. Le chiamate agli strumenti MCP vengono annullate quando un client si disconnette o scade il timeout, con una notifica al server MCP. Un nuovo endpoint compatibile con OpenAI /v1/audio/speech estende l’interfaccia audio del server.

La nuova interfaccia web aggiunge gruppi di chat con nome e un editor Markdown con anteprima in tempo reale. Le interfacce per dispositivi mobili si adattano alle aree sicure dei dispositivi e utilizzano finestre di dialogo a schermo intero, mentre l’editor di chat per Android può aprire la tastiera virtuale.

Backend hardware e infrastruttura di rilascio

La versione 1.0.0 di ggml, rilasciata insieme, rimuove le API deprecate e le operazioni DIAG_MASK legacy, aggiunge il troncamento YaRN configurabile e il supporto FP8, ed evita di caricare input dello scheduler che non vengono letti. CUDA e Metal introducono la moltiplicazione di matrici quantizzata per un numero ridotto di righe e miglioramenti alla fusione MoE. Le altre aggiunte ai backend includono un kernel FlashAttention di prefill per Intel Vulkan, uno scheduler MoE SYCL eseguito sul dispositivo, FlashAttention Adreno scomposta in OpenCL, nuovi kernel WebGPU e un supporto più ampio delle operazioni Hexagon.

Ogni backend ggml può essere compilato come libreria dinamica e, facoltativamente, caricato durante l’esecuzione, consentendo alle installazioni di selezionare codice specifico per l’hardware. Gli artefatti preliminari coprono Linux, macOS, Windows, Android e iOS; Docker, Debian, Homebrew, conda-forge, MacPorts, Winget e XCFramework offrono ulteriori canali di distribuzione, con una copertura delle piattaforme che varia da un canale all’altro.

Per sostenere il ritmo di sviluppo, il team afferma che Hugging Face Buckets e Jobs stanno ampliando la capacità di integrazione continua per le modifiche che confluiscono nei rami master. Il supporto hardware di NVIDIA, AMD, Qualcomm, Arm, IBM e Intel consente inoltre di utilizzare più runner autogestiti sulle principali piattaforme hardware. Anche i responsabili del progetto stanno integrando gli LLM nel ciclo di sviluppo e indicano come priorità la qualità del codice, il controllo dell’architettura e la comprensione dei dettagli di implementazione.

Per i progetti che utilizzano la libreria a valle, il rilascio trasforma la compatibilità in un obbligo esplicito di sviluppo per una libreria open source in rapida evoluzione. Le regole di versionamento possono segnalare le modifiche incompatibili; l’ampliamento dell’integrazione continua e del programma di runner hardware aiuta a verificare se i rilasci ordinari restano affidabili sui modelli e sull’hardware utilizzati da questi progetti.