L’ANALISI
Ollama v0.35.1-rc0: capability esplicite nei Modelfile
La release candidate di Ollama dichiara e conserva le capability dei modelli: cosa cambia per creazione, export, System One e fallback.
In breve: Ollama v0.35.1-rc0 sostituisce parte del rilevamento implicito con capability dichiarate: i Modelfile possono includere CAPABILITY, le API create accettano un campo additivo e System One controlla la capability decision prima dello scheduling. È utile per runtime e orchestratori, ma va provato come prerelease.
Che cosa introduce la release
La release candidate aggiunge dichiarazioni CAPABILITY ai Modelfile e un campo capabilities additivo alle richieste di creazione. L’obiettivo operativo è rendere esplicito ciò che un modello può fare, invece di affidarsi soltanto a inferenze sull’architettura o sul renderer.
Dove vengono conservate le capability
Secondo il changelog, le dichiarazioni restano disponibili durante la creazione da GGUF e safetensors, nell’eredità tra modelli e nell’esportazione del Modelfile. Questo riduce il rischio che l’informazione si perda tra packaging, derivazione ed export.
Che cosa cambia per System One
Prima dello scheduling delle richieste System One viene ora richiesta la capability decision. Il controllo sostituisce il matching basato su metadati di architettura e renderer Qwen, rendendo il requisito più leggibile e verificabile dagli strumenti.
Impatto su runtime e orchestratori
Un catalogo locale può filtrare modelli e fallback in base a capability dichiarate, ma deve distinguere tra presenza del metadato e comportamento realmente funzionante. La dichiarazione migliora il routing; non sostituisce un test di output, tool use o compatibilità.
Condizioni e limiti
La versione è rc0 e può cambiare prima della release stabile. Lo scoring resta limitato a GGUF; il supporto MLX e le modifiche alle manifest list sono separati. Non è quindi corretto assumere parità tra tutti i runtime o formati.
Checklist di verifica
- Installare la rc0 solo in un ambiente di prova.
- Esportare un Modelfile e verificare che CAPABILITY venga conservato.
- Provare creazione da GGUF e safetensors con lo stesso set di dichiarazioni.
- Controllare eredità e override delle capability nei modelli derivati.
- Inviare un task System One a un modello con e senza capability decision.
- Misurare errori di routing, fallback e messaggi restituiti dal runtime.
- Separare i test GGUF da MLX, che non è incluso in questo cambiamento.
- Ripetere la matrice sulla release stabile prima di adottarla in produzione.