Ollama v0.40.12 punta sulla velocità dei prompt e sui dettagli nelle immagini piccole

Ollama ha pubblicato il candidato al rilascio Ollama v0.40.12 con quattro modifiche mirate alle prestazioni dei modelli locali, alla gestione delle immagini e alle dipendenze software sottostanti. La distinzione è importante: i miglioramenti nell'elaborazione dei prompt e quelli nella generazione derivano da modifiche separate, con limiti diversi.

Il punto centrale è la distanza tra supportare un modello ed eseguirlo bene. Un modello può caricarsi correttamente pur elaborando i documenti in modo inefficiente o perdendo dettagli utili nelle immagini. Questo rilascio affronta esempi specifici di tale divario, anziché annunciare una nuova famiglia di modelli.

Il confronto va inoltre oltre Ollama stesso. MLX, il framework di array per il machine learning di Apple, offre ai ricercatori che lavorano sulle sue operazioni sottostanti un percorso di sviluppo più diretto. Il ruolo di Ollama è integrare queste capacità in un runtime per modelli, il software che esegue i modelli. Per gli sviluppatori di applicazioni, questa integrazione determina quali miglioramenti a monte raggiungano effettivamente i loro carichi di lavoro.

Cosa cambia davvero in Ollama v0.40.12

Si tratta di un aggiornamento mirato del runtime e l'artefatto pubblicato rimane un candidato al rilascio.

Il candidato al rilascio porta il tag v0.40.12-rc0, sebbene il suo titolo visualizzato sia v0.40.12. GitHub lo contrassegna come prerelease e lo data 27 ottobre 2026. Il confronto parte da v0.40.11.

Questa differenza nella denominazione merita attenzione, perché un titolo visualizzato da solo non dimostra che sia stata distribuita una release stabile. Chi valuta un aggiornamento dovrebbe distinguere il candidato pubblicato da un eventuale artefatto stabile successivo. Le conclusioni su questa build dovrebbero conservarne il tag completo.

Le modifiche elencate riguardano la gestione delle immagini compatte di Gemma 4, gli aggiornamenti delle dipendenze MLX, il supporto DFlash2 e un aggiornamento della dipendenza llama.cpp. Tutte e quattro le voci attribuiscono il contributo a dhiltgen. Nel complesso, descrivono attività di manutenzione su diversi percorsi di esecuzione, non una singola funzionalità di accelerazione universale.

Questa portata rende il rilascio rilevante per gruppi diversi e per ragioni diverse. Gli sviluppatori che usano i modelli di immagini interessati hanno una questione di correttezza. Chi attende l'elaborazione dei prompt ha una questione di reattività. Chi prova l'accelerazione della generazione supportata ha un'altra questione di prestazioni.

Queste domande dovrebbero rimanere separate nell'interpretare l'annuncio. Un'elaborazione più rapida dei documenti non implica automaticamente una generazione di risposte più veloce. Preservare i dettagli di un'immagine non dimostra una maggiore accuratezza in ogni attività visiva. Aggiornare una dipendenza non specifica il beneficio per ogni dispositivo supportato.

L'inquadramento utile dipende quindi dal carico di lavoro. Quale operazione è cambiata, quale modello la utilizza e quale parte di un'applicazione dipende da tale operazione? Queste domande producono una lettura più operativa rispetto al trattare ogni voce del changelog come prova di un'IA locale generalmente più veloce.

Per un assistente documentale, il miglioramento più rilevante potrebbe verificarsi prima che compaia una risposta. Per un assistente per screenshot, potrebbe riguardare le informazioni mantenute dall'input. Per un'applicazione che genera risposte più lunghe, il percorso di generazione potrebbe meritare un esame più approfondito.

Si tratta di esempi analitici, non di deployment presso clienti riportati. Illustrano perché la stessa release possa avere un'importanza diversa tra applicazioni che usano un'interfaccia identica. Il prodotto visibile può rimanere familiare mentre cambia il lavoro svolto sotto la superficie.

L'aggiornamento spinge inoltre i manutentori delle applicazioni a riconsiderare vecchie ipotesi. Un confronto precedente potrebbe riflettere un percorso di esecuzione anteriore, anziché un limite duraturo del modello. Al contrario, un nuovo benchmark non dovrebbe cancellare le evidenze di un carico di lavoro in produzione senza un ulteriore confronto.

Questo è il significato pratico di una release di manutenzione come questa. Crea ragioni specifiche per rivalutare il comportamento esistente, lasciando però irrisolte le affermazioni più ampie sulla qualità del modello e sull'idoneità al deployment.

Le immagini piccole rivelano il divario tra caricamento e visione

La modifica alle immagini affronta la perdita di informazioni prima che il modello produca una risposta.

La correzione per la visione compatta riguarda le torri di visione compatte di Gemma 4, i componenti che convertono le immagini in input per il modello. Secondo la pull request, il dimensionamento dinamico poteva arrotondare la griglia delle immagini più piccole al di sotto del previsto budget di 70 token.

Qui i token sono le unità usate per rappresentare le informazioni dell'immagine durante l'elaborazione del modello. La modifica arrotonda tale griglia verso l'alto per la torre compatta, con un limite al budget supportato successivo. Il manutentore afferma che i budget espliciti e il dimensionamento esistente per le torri più grandi e unificate restano invariati.

Si tratta di una correzione circoscritta, con un'implicazione utile. Quando un input perde dettagli durante la preparazione, il ragionamento successivo non può recuperare in modo affidabile le informazioni mancanti. Anche un modello capace dipende da ciò che il runtime gli trasmette.

Si consideri un'applicazione che pone domande su un piccolo screenshot contenente un'etichetta di stato. Se la preparazione rimuove dettagli rilevanti, cambiare la formulazione della domanda potrebbe non risolvere il problema di fondo. L'applicazione ha bisogno che l'evidenza visiva sopravviva abbastanza a lungo da poter essere interpretata.

Questo scenario spiega perché la gestione delle immagini appartenga a una discussione sulle prestazioni. Gli utenti valutano l'attività completata, incluso il fatto che il sistema legga correttamente l'input. Una risposta che arriva rapidamente ma non coglie l'etichetta rilevante crea lavoro aggiuntivo.

Tuttavia, la correzione non dovrebbe trasformarsi nell'affermazione che i modelli compatti ora gestiscano con precisione ogni immagine piccola. La fonte identifica un comportamento di dimensionamento e una correzione delimitata. Non stabilisce un risultato generale per screenshot, documenti scansionati, diagrammi o fotografie.

Anche le dimensioni dell'immagine offrono una descrizione incompleta della difficoltà. Una piccola immagine contenente un simbolo evidente presenta una sfida diversa rispetto a una che contiene testo fitto. Una valutazione dovrebbe riflettere le informazioni che una vera applicazione prevede di estrarre.

Il confronto più chiaro conserverebbe l'immagine originale e la domanda tra le diverse build. Ridimensionare l'immagine in modo diverso durante una valutazione introdurrebbe un'altra spiegazione per qualsiasi cambiamento nella risposta. L'obiettivo è isolare il comportamento del runtime in esame.

Per i manutentori, questo modifica il modo in cui dovrebbero essere indagati i fallimenti. Una risposta visiva errata non nasce necessariamente dalle capacità apprese dal modello. La preparazione dell'input è un altro livello plausibile, e questa patch ne fornisce un esempio concreto.

Modifica inoltre l'interpretazione dei precedenti risultati negativi. Se una configurazione interessata scartava informazioni utili, un test precedente potrebbe sottostimare ciò che quella configurazione può offrire dopo la correzione. Questa possibilità giustifica nuovi test, non la riscrittura dei risultati precedenti come non validi.

La lezione più ampia riguarda i confini dei confronti tra modelli. Il solo nome di un modello non descrive l'intero sistema valutato. Preparazione delle immagini, software di esecuzione e comportamento dell'applicazione contribuiscono tutti a determinare la risposta che raggiunge l'utente.

Le prestazioni MLX di Ollama migliorano prima che inizi la risposta

La modifica alla velocità dei prompt accelera la lettura della richiesta, mentre il manutentore riporta esplicitamente una velocità di decoding invariata.

L'aggiornamento dell'elaborazione dei prompt aggiorna MLX e MLX-C, la sua interfaccia per il linguaggio C. Utilizza l'attenzione nativa a finestra scorrevole, che limita le operazioni di attenzione rilevanti a una finestra mobile degli input del modello.

Il manutentore riporta miglioramenti del prefill su un Apple M5 Max. Il prefill è la fase che elabora l'input prima di generare nuovo output. Con un prompt di 2.048 token, il throughput riportato aumenta del 9,2% per Gemma, del 14,5% per Flint e del 24,1% per Laguna.

Con un prompt di 6.144 token, i guadagni riportati corrispondenti sono del 7,5%, 14,3% e 27,0%. Si tratta di misurazioni del manutentore per configurazioni di modello specificate. La pull request afferma che la velocità di decode, ossia il ritmo di generazione dell'output, rimane invariata.

Questa precisazione definisce l'ambito dell'affermazione sulle prestazioni MLX di Ollama. Un utente che aspetta la lettura di un documento lungo ha un collo di bottiglia diverso da chi aspetta una risposta lunga. Migliorare il primo non dimostra un miglioramento del secondo.

Questo è particolarmente rilevante quando una richiesta include molto materiale di supporto e chiede una risposta breve. In quel carico di lavoro ipotetico, l'elaborazione dell'input può rappresentare una parte significativa dell'esperienza. Una preparazione più rapida può essere importante anche se l'output successivo arriva allo stesso ritmo.

La situazione inversa richiede un'interpretazione diversa. Un'applicazione con una richiesta breve e un output generato esteso potrebbe trascorrere relativamente poco tempo nell'elaborazione del prompt. La sua esperienza complessiva non dovrebbe essere prevista dal solo throughput di prefill.

Le percentuali descrivono inoltre il throughput, non una riduzione universale del tempo di attesa. La latenza end-to-end, il tempo trascorso per l'intera richiesta, include più della sola fase di elaborazione misurata. Caricamento, overhead dell'applicazione e altre attività complicano qualunque traduzione diretta.

Questa distinzione evita un errore di reporting comune: presentare un miglioramento in un componente come un miglioramento equivalente nell'attività completata. Un benchmark può descrivere accuratamente il componente lasciando aperto il risultato dell'applicazione.

La release offre agli sviluppatori una ragione più specifica per esaminare i carichi di lavoro con input lunghi. Non impone loro di concludere che la propria applicazione sia diventata più veloce prima di averla misurata. Sono standard di evidenza diversi.

Per i team che assemblano contesto documentale, le implicazioni si estendono anche alla progettazione della valutazione. Gli input in cache, che riutilizzano lavoro calcolato in precedenza, dovrebbero essere distinti dagli input nuovi. Altrimenti, richieste ripetute possono oscurare quale lavoro di elaborazione sia interessato dall'aggiornamento.

Un confronto credibile tra applicazioni dovrebbe pertanto descrivere ciò che l'utente ha inviato e ciò che il sistema ha riutilizzato. Senza questa distinzione, una differenza apparentemente piccola potrebbe nascondere un miglioramento, oppure una differenza apparentemente grande potrebbe avere un'altra causa.

Le prestazioni MLX di Ollama sono più utili come affermazione ingegneristica precisa. La fase interessata, la configurazione del modello, l'hardware e la lunghezza dell'input offrono ai lettori qualcosa da testare. Rimuovere questi confini renderebbe l'affermazione più ampia ma meno informativa.

Il supporto Ollama DFlash2 punta a un collo di bottiglia diverso

DFlash2 riguarda la generazione delle risposte, quindi i suoi risultati dovrebbero rimanere separati dai miglioramenti nell'elaborazione dei prompt.

L'implementazione DFlash2 aggiunge un approccio di generazione speculativa, in cui l'output proposto viene controllato dal modello di destinazione. Il manutentore descrive un selettore di candidati che condiziona le scelte successive alle selezioni precedenti.

Secondo le note di implementazione, una sessione elabora sette token per ciclo e li verifica tramite il meccanismo di rollback esistente. Il contributore afferma che la verifica preserva la distribuzione dell'output di destinazione. Si tratta di un'affermazione sull'implementazione, non di una validazione indipendente presentata qui.

La pull request confronta DFlash2 con una testa integrata di previsione multi-token, un meccanismo che propone più token futuri. Per qwen3.8:27b, utilizzando la configurazione a precisione ridotta elencata, il manutentore riporta guadagni di generazione su sistemi M5 Max, M5 Pro e M2 Ultra.

Su M5 Max, la velocità di generazione riportata passa da 57,0 a 71,0 token al secondo con il prompt di test più breve. Il confronto ha utilizzato la stessa build, anziché misurare la release precedente rispetto a questa candidata.

Questa distinzione finale è importante. I risultati confrontano metodi di generazione all'interno di una build. Non dovrebbero essere riportati come un incremento misurato dell'upgrade per ogni utente che passa dalla release precedente.

Il supporto a Ollama DFlash2 aggiunge quindi un ulteriore percorso di valutazione, anziché fornire una promessa generale di velocità. Una configurazione supportata crea l'opportunità di confrontare i comportamenti. Non indica a ogni applicazione quale metodo di generazione produrrà il risultato migliore.

Il compromesso generale nella generazione speculativa è semplice. Le proposte aiutano quando un numero sufficiente di esse è utile da giustificare il lavoro necessario per produrle e verificarle. Valutare solo la fase delle proposte non terrebbe conto del costo della verifica.

Per uno sviluppatore di applicazioni, l'output completato conta più di quanti token candidati siano stati proposti internamente. Un metodo che genera bozze in modo aggressivo deve comunque produrre output accettato in modo efficiente. Il risultato rilevante è una generazione utile nelle condizioni reali dell'applicazione.

Il comportamento dell'output merita attenzione insieme alla velocità. I team che usano risposte strutturate dovrebbero verificare che l'applicazione continui a ricevere il formato previsto. I team che valutano risposte fattuali dovrebbero mantenere i controlli di correttezza esistenti quando introducono un ulteriore percorso di esecuzione.

Si tratta di priorità di valutazione, non di prove che questa implementazione causi problemi di formato o qualità. La fonte descrive salvaguardie pensate per preservare il comportamento. I test indipendenti dell'applicazione sono il modo con cui un team determina se i propri requisiti continuano a essere rispettati.

C'è anche una distinzione da fare tra supporto e comportamento predefinito. Una nota di rilascio che annuncia una funzionalità non stabilisce, da sola, che ogni modello installato la utilizzi. I lettori devono identificare la configurazione effettiva alla base di qualsiasi risultato osservato.

Questo punto collega la funzionalità al resto della release. I miglioramenti del runtime diventano utili attraverso una catena di decisioni di compatibilità e integrazione. L'utente vede una risposta, ma il modello scelto e il metodo di esecuzione determinano quali cambiamenti hanno contribuito.

Per i carichi di lavoro con risposte lunghe, il meccanismo di generazione merita attenzione nei suoi stessi termini. Combinare i miglioramenti riportati con percentuali non correlate di elaborazione dei prompt creerebbe una stima non supportata. Ogni miglioramento necessita di un carico di lavoro corrispondente prima di poter sostenere una conclusione a livello applicativo.

L'aggiornamento della dipendenza mantiene i confronti con i piedi per terra

Una dipendenza più recente identifica una base modificata, ma non stabilisce un risultato prestazionale universale.

L'aggiornamento di llama.cpp porta la dipendenza di Ollama dalla build b11845 alla b11901. llama.cpp è un motore di inferenza, un software che esegue modelli addestrati per produrre output. La pull request è stata unita il 26 ottobre.

La pull request visibile collega il confronto upstream senza presentare un benchmark applicativo corrispondente. Ciò supporta la segnalazione del cambio di versione. Non supporta l'attribuzione di uno specifico miglioramento di velocità o qualità a ogni carico di lavoro che utilizza quel percorso.

Questo è importante perché gli aggiornamenti delle dipendenze possono essere facilmente sovrainterpretati. Un numero di build più recente descrive la genealogia del software. Non identifica quali operazioni siano cambiate per una particolare applicazione né stabilisce se il suo collo di bottiglia esistente si sia spostato.

Il confronto con l'uso diretto del framework aiuta a chiarire la posizione di Ollama. Il framework MLX espone direttamente agli sviluppatori interfacce di programmazione e operazioni di machine learning. Ollama integra le capacità sottostanti in un ambiente per l'esecuzione dei modelli.

Questi approcci soddisfano esigenze sovrapposte con diversi livelli di responsabilità. Un ricercatore che lavora direttamente con le operazioni del framework può analizzare da vicino le scelte di implementazione. Un team applicativo che usa un runtime integrato si affida ai percorsi di esecuzione supportati dal runtime.

Nessuno dei due approcci vince ogni confronto per definizione. L'accesso diretto offre controllo, mentre l'integrazione può ridurre il lavoro necessario per utilizzare un modello supportato. Una valutazione equa dovrebbe chiedersi quali responsabilità il team applicativo desideri assumersi.

La candidata illustra anche perché i risultati upstream e downstream dovrebbero rimanere distinti. Una funzionalità del framework necessita di un'integrazione appropriata prima che un'applicazione ne tragga vantaggio. Viceversa, un miglioramento integrato non dovrebbe essere attribuito a un nuovo modello quando il modello stesso non è cambiato.

Questa distinzione influenza le affermazioni competitive. Un risultato ottenuto con un modello, un dispositivo e un percorso di esecuzione non stabilisce che Ollama superi generalmente i runtime alternativi. Stabilisce un risultato per il sistema testato, includendo i confini di quel sistema.

Le prove disponibili provengono principalmente dai manutentori del progetto. Supportano l'esistenza delle modifiche e le relative misurazioni riportate. Non forniscono un consenso indipendente sull'adozione in produzione, l'affidabilità o la superiorità tra le opzioni di distribuzione.

Non è necessario inventare una controversia pubblica per rendere significative queste prove. La questione irrisolta è pratica: se i cambiamenti offrano vantaggi utili nelle applicazioni al di fuori delle misurazioni dei manutentori. Questa domanda è abbastanza sostanziale senza sostenitori o critici inventati.

Per gli acquirenti aziendali, la giusta pressione ricade sulla qualità delle prove. Un'ampia dimostrazione di IA locale è meno utile di risultati che corrispondono al compito previsto. Le decisioni di approvvigionamento richiedono che modello, hardware, carico di lavoro e requisiti operativi siano allineati.

Anche gli sviluppatori traggono vantaggio dal mantenere il contesto alla base dei propri confronti. I team che documentano le valutazioni possono utilizzare una base di conoscenza ricercabile per conservare i risultati insieme a configurazioni ed esempi. Un archivio utile include fallimenti e limitazioni, non solo l'esecuzione più veloce.

Tre segnali mostreranno quanto conta questa candidata

Le prossime prove significative sono l'avanzamento della release, tempistiche riproducibili e comportamento verificato sul compito, in quest'ordine.

Per prima cosa, osservate cosa accade alla candidata pubblicata. Un artefatto stabile, una candidata successiva o una release correttiva chiarirebbero il software disponibile per un'adozione più ampia. Questi eventi non stabilirebbero automaticamente la qualità dell'applicazione, ma risolverebbero parte della questione sullo stato della release.

L'avanzamento più informativo manterrebbe collegamenti chiari tra tag e modifiche. Ciò permetterebbe agli sviluppatori di identificare se un risultato successivo riguarda questa candidata o una build modificata. Senza tale continuità, le discussioni possono combinare risultati di software diversi sotto lo stesso nome di versione abbreviato.

Una correzione successiva non annullerebbe automaticamente il lavoro descritto qui. Il suo significato dipenderebbe dal comportamento interessato. I lettori dovrebbero cercare una relazione concreta tra qualsiasi problema segnalato, la sua portata e la configurazione che utilizzano.

In secondo luogo, cercate tempistiche applicative riproducibili che separino l'elaborazione dell'input dalla generazione dell'output. Questo verificherebbe se i miglioramenti dei componenti riportati resistono al di fuori delle condizioni di misurazione originali. I risultati dovrebbero identificare la configurazione effettiva del modello e l'hardware.

Le prove provenienti da un carico di lavoro corrispondente rafforzerebbero il caso per adottare la modifica rilevante. Un confronto che mostrasse pochi vantaggi end-to-end restringerebbe tale caso senza necessariamente contraddire il benchmark del componente. L'applicazione potrebbe semplicemente impiegare il proprio tempo altrove.

I rapporti sulle tempistiche diventano più informativi quando descrivono sia input nuovi sia riutilizzati. Dovrebbero inoltre distinguere un modello già caricato da una richiesta che deve caricarlo. Queste condizioni rispondono a domande diverse sull'uso quotidiano.

In terzo luogo, cercate verifiche a livello di compito sulla gestione delle immagini e sulla generazione accelerata. La correzione delle immagini necessita di esempi che testino il mantenimento delle informazioni visive. Il percorso di generazione necessita di controlli sull'output insieme alle tempistiche, soprattutto quando le applicazioni dipendono da una struttura prevedibile.

Rapporti utili includerebbero l'input originale, il comportamento previsto e il risultato di ogni configurazione confrontata. Ciò permetterebbe ad altri di esaminare l'affermazione anziché affidarsi a una dichiarazione secondo cui una risposta appariva migliore.

Per i compiti sulle immagini, una risposta corretta su un esempio semplice fornirebbe prove limitate riguardo agli input difficili. Per i compiti di generazione, una risposta rapida fornirebbe prove limitate sulla compatibilità dell'applicazione. La forza di ciascun risultato dipende da ciò che effettivamente verifica.

Questi segnali dovrebbero essere letti insieme senza comprimerli in un unico punteggio. L'avanzamento della release riguarda l'artefatto. Le tempistiche riguardano l'esecuzione. Le verifiche dei compiti riguardano il fatto che l'applicazione completi correttamente un lavoro utile.

Nei prossimi mesi, il seguito più prezioso collegherà questi livelli. Un risultato riproducibile legato a una release specifica e a un compito rappresentativo rafforzerebbe il caso pratico. Generalizzazioni non supportate attirerebbero attenzione senza risolvere la questione della distribuzione.

Per i lettori che valutano Ollama v0.40.12, iniziate dal carico di lavoro che già vi interessa. Conservate il relativo input, la configurazione del modello e l'output previsto prima di confrontare le build. Registrate separatamente il tempo impiegato per elaborare la richiesta da quello impiegato per generare la risposta. Se le immagini sono importanti, conservate i file originali e ispezionate i dettagli necessari alla vostra applicazione. Se la generazione accelerata è importante, verificate le risposte completate insieme alla velocità. Conservate il tag completo della candidata con i vostri risultati affinché i confronti successivi restino interpretabili. Quindi prendete la decisione di aggiornamento in base a un risultato concreto: il percorso di esecuzione modificato ha migliorato il compito che i vostri utenti svolgono effettivamente, nelle condizioni che la vostra applicazione affronta realmente?