Liquid AI LFM2.5-VL-3B-DSpark accelera la decodifica visiva, ma il dato di 3,13x racconta solo metà della storia

Liquid AI ha rilasciato LFM2.5-VL-3B-DSpark, dichiarando una decodifica fino a 3,13x più veloce per il suo compatto modello vision-language. Il miglioramento riguarda la generazione di token, non l'intero processo di comprensione di un'immagine e produzione di una risposta.

Questa distinzione definisce la rilevanza di Liquid AI LFM2.5-VL-3B-DSpark. Il modello sperimentale di draft dimostra che la decodifica speculativa può funzionare su attività visive e testuali, sia in datacenter sia su hardware consumer. Tuttavia, i risultati della stessa Liquid AI collocano il miglior guadagno end-to-end a 2,62x, al di sotto del picco di decodifica.

Il rilascio spinge gli sviluppatori a riconsiderare l'ottimizzazione delle applicazioni vision-language locali. La compressione dei modelli e le architetture più piccole non sono più le uniche strade per ridurre la latenza. Un drafter separato può accelerare un modello target esistente, preservandone il comportamento in output con impostazioni di decodifica corrispondenti.

Il confronto, quindi, non è tra Liquid AI e un singolo modello rivale. È tra la decodifica speculativa e la pratica convenzionale di rendere il principale modello vision-language più piccolo, semplice o meno accurato per ottenere maggiore velocità.

Liquid AI LFM2.5-VL-3B-DSpark aggiunge un modello di draft dedicato

Il rilascio separa la qualità delle risposte da una componente importante del problema della latenza.

Liquid AI LFM2.5-VL-3B-DSpark è un modello di draft da 279,5 milioni di parametri, costruito specificamente per LFM2.5-VL-3B. Non sostituisce il modello target da 3 miliardi di parametri né risponde alle richieste in autonomia. Propone invece diversi token probabili prima che il modello più grande li verifichi insieme.

Questo processo è chiamato decodifica speculativa, un metodo che usa un predittore più piccolo per redigere token destinati alla verifica parallela da parte del modello target. I token accettati riducono il numero di costosi passaggi del modello target necessari per generare una risposta. Le proposte respinte vengono corrette dal target.

Liquid AI afferma che il drafter contiene quattro layer a full attention, una testa Markov e una testa di confidenza. Il suo blocco di addestramento contiene nove token proposti. In produzione usa blocchi da otto o nove, a seconda dell'hardware e del framework di inferenza.

L'azienda ha pubblicato il modello nei formati Safetensors e GGUF attraverso il proprio repository del modello. Supporta SGLang su GPU Nvidia, MLX-VLM su Apple silicon e llama.cpp tramite il checkpoint GGUF.

Questa copertura dei framework è rilevante perché l'accelerazione dell'inferenza resta spesso confinata a un paper o a un'implementazione di ricerca personalizzata. Qui Liquid AI ha collegato il proprio drafter a tre percorsi di deployment già utilizzati per server, Mac e modelli quantizzati locali.

SGLang richiede la versione 0.5.19 o successiva per la configurazione pubblicata. MLX-VLM richiede la versione 0.7.2 o successiva e attualmente esegue questa implementazione DSpark con campionamento greedy. Liquid AI indica agli utenti MLX di impostare la temperatura a zero.

Il modello target è arrivato prima del drafter. Liquid AI ha introdotto LFM2.5-VL-3B nell'agosto 2026 come modello vision-language open-weight destinato al deployment edge. Il modello combina un backbone linguistico con un encoder visivo per immagini, documenti, grounding, riconoscimento ottico dei caratteri e uso di strumenti visivi.

Liquid AI aveva in precedenza dichiarato che il target poteva decodificare 228 token al secondo su un M5 Max. Aveva inoltre riportato 116 token al secondo su un Ryzen AI Max+ 395 e 20 su un Galaxy S26 Ultra. Questi dati precedenti provenivano dai test dell'azienda.

Il rilascio di DSpark modifica il pacchetto di deployment, non le capacità apprese dal modello sottostante. Gli sviluppatori collegano il drafter durante l'inferenza, mentre LFM2.5-VL-3B resta responsabile dell'approvazione di ogni token generato.

Con la decodifica greedy, il target accetta un token di draft solo quando coincide con il token che avrebbe selezionato autonomamente. La risposta risultante dovrebbe quindi corrispondere alla normale generazione greedy. Con temperature diverse da zero, il campionamento corrispondente può preservare la distribuzione dell'output del modello target anziché una singola sequenza deterministica.

Questa proprietà attribuisce alla decodifica speculativa una proposta di valore diversa rispetto alla quantizzazione o alla distillazione. Queste tecniche possono modificare precisione numerica, dimensioni del modello o comportamento appreso. DSpark cerca invece di ridurre il tempo impiegato per arrivare alle decisioni originali del modello target.

Per questo il rilascio crea un confronto significativo tra due percorsi di ottimizzazione. Gli sviluppatori possono ridurre il lavoro svolto dal modello principale oppure prevederne una parte maggiore e verificare tali previsioni in modo efficiente.

Il risultato di 3,13x dipende da hardware, carico di lavoro e misurazione

Il numero più alto di Liquid AI descrive un risultato di decodifica, non un'accelerazione universale dell'applicazione.

Liquid AI ha valutato il drafter in sei categorie di MMSpec: visual question answering generale, riconoscimento del testo, didascalie per immagini, analisi dei grafici, ragionamento complesso e conversazione multi-turno. L'azienda ha testato una batch size pari a uno su hardware Apple e su una GPU H100.

Su un M5 Max con MLX-VLM, Liquid AI ha riportato guadagni di decodifica compresi tra 2,30x e 3,13x. I miglioramenti end-to-end sono andati da 1,56x a 2,62x. Il picco di 3,13x si è verificato sul carico di lavoro di image captioning COCO.

L'azienda ha testato anche un M3 Ultra con llama.cpp. La decodifica è migliorata, secondo quanto riportato, da 1,57x a 2,14x, mentre le prestazioni end-to-end sono migliorate da 1,30x a 1,77x.

Su una singola GPU H100 80GB con SGLang, Liquid AI ha misurato guadagni di decodifica tra 2,04x e 2,66x. I miglioramenti end-to-end sono variati da 1,64x a 2,27x. La dettagliata documentazione dei benchmark dell'azienda fornisce configurazioni e risultati per attività.

Questi test hanno usato elaborazione a 16 bit per l'encoder visivo e il backbone linguistico. La configurazione H100 utilizzava BF16, un blocco di draft da nove, batch size uno e temperatura zero. I test Apple usavano FP16, un blocco da otto e fino a 2.048 token generati.

La lunghezza mediana delle risposte nella valutazione Apple era di 90 token. Questo dettaglio è importante perché la lunghezza dell'output modifica la quota di una richiesta dedicata alla decodifica. Un sistema che produce una descrizione lunga offre al drafter più tempo per compensare il proprio overhead di configurazione.

Le risposte brevi creano un equilibrio meno favorevole. Se un'applicazione restituisce un'etichetta, una coordinata o una frase, la codifica dell'immagine e l'elaborazione del prompt possono dominare. La generazione più veloce incide quindi su una porzione minore dell'attesa totale.

L'accettazione del draft aiuta a spiegare l'accelerazione riportata. Liquid AI ha misurato circa 3,2-4,5 token accettati per passaggio di verifica negli stack Apple. I risultati su H100 variavano da 3,46 a 4,57 token accettati.

Una lunghezza di accettazione maggiore significa che il target convalida più output utile a ogni passaggio. Tuttavia, l'accettazione non si traduce direttamente in guadagni di velocità equivalenti. L'esecuzione del drafter, la sincronizzazione, l'accesso alla memoria e l'overhead del framework consumano comunque tempo.

I risultati variano anche in base all'attività. L'image captioning ha prodotto il massimo miglioramento MLX nella decodifica, mentre la conversazione multi-turno ha registrato 2,30x. I guadagni end-to-end sono stati rispettivamente di 2,59x e 1,91x.

Questa variazione impedisce un'interpretazione responsabile di “fino a 3,13x” come risultato atteso per ogni assistente visivo. È un limite massimo osservato in una configurazione pubblicata. Il risultato di un'applicazione dipenderà da hardware, lunghezza del prompt, lunghezza dell'output, impostazioni di campionamento e carico di lavoro visivo.

Liquid AI afferma che DSpark ha mantenuto un vantaggio a maggiore concorrenza nei propri test H100. Tuttavia, il divario si è ridotto all'aumentare della concorrenza. Ciò suggerisce che il beneficio relativo del drafter cambia quando la GPU passa dalla decodifica limitata dalla memoria a un'esecuzione limitata dal calcolo.

Per i team di prodotto, la domanda pratica non è se il dato di picco sia reale nel test di Liquid AI. La domanda è se il loro profilo di latenza assomigli al test che lo ha prodotto. Ciò richiede di misurare ogni fase dell'inferenza, anziché copiare un moltiplicatore da titolo nei piani di capacità.

Come la decodifica speculativa di Liquid AI preserva il modello target

DSpark cerca di elaborare bozze più avanti senza trasformare gli errori di previsione nell'output finale.

La generazione autoregressiva standard produce un token dopo l'altro. Ogni nuovo token richiede un ulteriore passaggio del modello target, anche quando la continuazione è altamente prevedibile. Questa struttura seriale può lasciare l'hardware sottoutilizzato durante la decodifica limitata dalla memoria.

La decodifica speculativa inserisce un modello più piccolo in questo ciclo. Il drafter propone un blocco di token futuri e il target valuta insieme tali posizioni. Il lavoro viene risparmiato quando diverse proposte superano la verifica.

La sfida consiste nel produrre proposte abbastanza rapidamente e accuratamente da giustificare il modello aggiuntivo. Un drafter debole genera token respinti. Un drafter pesante effettua buone previsioni, ma impiega troppo tempo per produrre il proprio blocco.

DSpark combina la generazione parallela con una componente sequenziale leggera. La sua testa Markov introduce una dipendenza limitata tra le posizioni proposte, mentre la testa di confidenza stima se le proposte successive debbano essere verificate. Questo design punta a preservare la coerenza del blocco senza rendere il drafting pienamente autoregressivo.

La ricerca su DSpark descrive l'approccio come decodifica speculativa programmata dalla confidenza con generazione semi-autoregressiva. Il compromesso centrale riguarda qualità delle proposte, latenza del draft e numero di token inviati per la verifica.

Il drafting puramente parallelo può generare rapidamente un blocco, ma l'accuratezza spesso diminuisce per i token più lontani all'interno di quel blocco. Ogni posizione dipende da un contesto che include ipotesi precedenti. Gli errori possono quindi accumularsi lungo la proposta.

Un drafter pienamente autoregressivo mantiene dipendenze più forti, ma ricrea parte del collo di bottiglia seriale. La struttura ibrida di DSpark cerca di collocarsi a metà strada. Aggiunge una piccola testa sequenziale dopo l'operazione di draft parallelo.

Il meccanismo di confidenza affronta un'altra fonte di spreco. Verificare un intero blocco fisso ha poco senso quando il drafter prevede che i token successivi falliranno. Uno scheduler può accorciare il prefisso inviato prima che le posizioni a bassa confidenza consumino capacità del target.

La configurazione pubblicata di LFM2.5-VL-3B-DSpark usa una testa Markov rank-256 e una testa di confidenza separata. Il suo vocabolario contiene 128.000 token. L'architettura resta legata al modello target designato e non può fungere da drafter generale plug-and-play per ogni VLM.

Questa relazione specifica per modello è al tempo stesso un punto di forza e un limite. L'addestramento su un singolo target può migliorare l'allineamento delle proposte. Tuttavia, un team che passa a un altro modello target necessita di un checkpoint compatibile, di un processo di addestramento e di un'integrazione runtime.

Anche la descrizione “lossless” richiede un'interpretazione precisa. Con la decodifica greedy a temperatura zero, la verifica preserva le esatte scelte di token che il target compirebbe da solo. Il drafter non è autorizzato a sostituirle con un'alternativa semplicemente plausibile.

Con temperature diverse da zero, l'obiettivo passa dal riprodurre una sequenza al preservare la distribuzione del target. Il corretto campionamento speculativo può farlo con impostazioni corrispondenti, secondo la fondamentale ricerca sul campionamento. La velocità dipende comunque dalla frequenza con cui le distribuzioni di draft e target si allineano.

Liquid AI riporta che l'aumento della temperatura ha ridotto l'accettazione nei suoi esperimenti. La probabilità si distribuisce maggiormente verso token con ranking inferiore, creando più occasioni di disaccordo tra drafter e target. Di conseguenza, il campionamento creativo può offrire guadagni inferiori rispetto alla generazione deterministica.

Questo è importante per la progettazione delle applicazioni. L’estrazione di documenti, l’ancoraggio visivo, la lettura di grafici e le risposte vincolate usano spesso temperature basse. Le conversazioni aperte sulle immagini possono usare un campionamento maggiore, rendendo i risultati greedy pubblicati meno rappresentativi.

La decodifica speculativa di Liquid AI si adatta quindi particolarmente bene a output prevedibili. Didascalie di immagini di prodotto standardizzate, lettura di ricevute, descrizione di schermate di interfacce ed estrazione di fatti strutturati rappresentano carichi di lavoro plausibili. I guadagni effettivi richiedono comunque misurazioni locali.

Una Decodifica Più Rapida Non Elimina il Collo di Bottiglia Vision-Language

La principale incertezza è quanto di una richiesta reale rimanga al di fuori della fase di decodifica accelerata.

Una richiesta vision-language comporta più lavoro della generazione di testo. Il sistema deve codificare l’immagine, trasformarla in rappresentazioni visive, elaborare quei token visivi insieme al prompt e poi decodificare la risposta.

DSpark accelera soltanto la fase finale. Non rende più rapida la codifica delle immagini. Inoltre, lascia invariato il prefill, il che significa che il target continua a elaborare il prompt e il contesto dei token visivi prima di produrre il suo primo token di risposta.

Questo confine spiega il divario tra i risultati di decodifica e quelli end-to-end. Liquid AI ha riportato una decodifica fino a 3,13x più veloce su M5 Max, ma il suo miglioramento totale massimo è stato di 2,62x. Altre attività hanno mostrato differenze più ampie.

Su TextVQA, l’azienda ha misurato un miglioramento della decodifica di 2,69x e un guadagno end-to-end di 1,56x su M5 Max. Il risultato implica che l’elaborazione delle immagini e il prefill assorbivano una porzione sostanziale del tempo originario della richiesta.

Il limite segue la legge di Amdahl, che pone un tetto all’accelerazione complessiva quando una parte del carico di lavoro resta invariata. Se la decodifica rappresenta metà della latenza di base, persino un decoder infinitamente veloce non può migliorare l’intera richiesta oltre 2x.

L’hardware edge rende questo vincolo particolarmente rilevante. I dispositivi consumer offrono meno capacità di calcolo delle GPU da datacenter per la codifica visiva e il prefill con contesti lunghi. Un’immagine grande o un prompt con più immagini può ritardare il primo token prima che la decodifica speculativa inizi a contribuire.

L’indipendente benchmark MMSpec rafforza la necessità di un’interpretazione prudente. I suoi autori hanno valutato 600 campioni in sei categorie di attività e dieci metodi di decodifica speculativa. Hanno rilevato che il solo aumento della velocità di throughput non rappresentava in modo affidabile le prestazioni di latenza.

MMSpec ha inoltre rilevato che le tecniche progettate per modelli linguistici solo testuali possono degradare in contesti multimodali. Le dipendenze cross-modali cambiano quali proposte hanno probabilità di essere accettate. La consapevolezza visiva diventa più importante all’aumentare delle dimensioni dei batch.

Liquid AI ha seguito le categorie di attività di MMSpec, migliorando l’ampiezza della propria valutazione interna. Tuttavia, Liquid AI ha eseguito e pubblicato autonomamente i test prestazionali di DSpark. Le repliche indipendenti su dispositivi comuni e prompt di produzione restano limitate.

Anche il benchmark di confronto merita pari attenzione. I moltiplicatori pubblicati confrontano lo stesso target LFM2.5-VL-3B con e senza il suo drafter nei framework specificati. Non dimostrano che il sistema combinato superi ogni VLM concorrente.

Inoltre, non confrontano il sistema con strategie alternative di latenza. Gli sviluppatori possono quantizzare il target, ridurre la risoluzione delle immagini, memorizzare nella cache gli embedding visivi, accorciare i prompt, raggruppare le richieste o selezionare un modello più piccolo. Queste modifiche agiscono su parti diverse del budget di latenza.

La memoria è un’altra considerazione operativa. Il drafter è piccolo rispetto al target da 3 miliardi di parametri, ma non è gratuito. I suoi pesi, la cache, lo stato di runtime e l’integrazione consumano capacità che conta sui dispositivi con risorse limitate.

La compatibilità crea ulteriore attrito. SGLang, MLX-VLM e llama.cpp offrono ora percorsi pubblicati, ma i team che usano altri sistemi di serving non possono presumere un supporto immediato. L’adozione in produzione richiede caricamento stabile, osservabilità, comportamento dei batch e gestione dei guasti.

L’attuale percorso DSpark solo greedy di MLX-VLM restringe i suoi casi d’uso immediati. Le applicazioni che dipendono dalla generazione campionata necessitano di un altro stack supportato oppure devono attendere un supporto più ampio al sampling. Anche in quel caso, temperature più alte possono ridurre l’accettazione delle bozze.

Il rilascio va quindi valutato come un’ottimizzazione di sistema credibile con limiti chiaramente dichiarati. Non dimostra che l’inferenza visiva sia diventata 3,13x più rapida in ogni senso significativo.

La Vera Competizione È Tra Previsioni Migliori e Meno Lavoro del Modello

DSpark rafforza un approccio in cui gli sviluppatori mantengono intatto il target e ottimizzano quanto spesso debba essere eseguito.

La risposta standard dell’edge AI alla latenza è stata ridurre il carico di lavoro del modello target. I team usano meno parametri, minore precisione, prompt più brevi, immagini più piccole o distillazione specifica per attività. Ogni tecnica può migliorare la reattività, ma ciascuna può introdurre compromessi in termini di qualità o flessibilità.

Liquid AI LFM2.5-VL-3B-DSpark propone un’altra strada. Mantenere il target esistente e prevedere diversi passaggi futuri con un accompagnatore specializzato. Lasciare che il target verifichi queste ipotesi senza rinunciare al controllo sull’output finale.

Questo percorso diventa interessante quando un team accetta già le capacità del modello target. Sostituirlo richiederebbe nuove valutazioni, modifiche ai prompt, controlli di sicurezza e ottimizzazioni del prodotto. Collegare un drafter può preservare una parte maggiore di quell’investimento.

L’approccio è adatto anche al deployment locale, dove la larghezza di banda della memoria limita frequentemente la generazione dei token. Verificare un blocco può usare l’hardware in modo più efficiente rispetto al caricamento ripetuto dello stato del modello per un singolo token. I risultati Apple di Liquid AI rendono concreta questa possibilità.

Tuttavia, i modelli più piccoli conservano dei vantaggi. Semplificano il packaging, riducono l’uso totale di memoria e accelerano fasi che un’ottimizzazione del solo decoder non può toccare. Un encoder visivo compatto può migliorare il tempo al primo token, mentre DSpark non può farlo.

La quantizzazione può anche combinarsi con la decodifica speculativa anziché competere esclusivamente con essa. Liquid AI fornisce un drafter GGUF abbinato al proprio target GGUF. Uno stack locale può quindi ridurre la precisione e aggiungere il drafting, a condizione che il runtime supporti correttamente la coppia.

Questa combinazione sposta la questione ingegneristica dalla scelta di una singola tecnica all’assegnazione di ogni tecnica al collo di bottiglia corretto. La quantizzazione riduce la dimensione dei pesi e il costo aritmetico. Il preprocessing delle immagini modifica il costo visivo. La speculazione punta alla generazione autoregressiva.

Per questo il profiling a livello di fase diventa essenziale. Un assistente documentale che analizza pagine ad alta risoluzione potrebbe trascorrere la maggior parte del tempo prima della decodifica. Uno strumento di chat visiva che produce descrizioni dettagliate potrebbe invece dedicare molto più tempo alla generazione dell’output.

La stessa distinzione si applica all’esperienza utente. Il tempo al primo token determina se un’applicazione sembra reattiva all’avvio. I token al secondo determinano se una risposta lunga sembra fluida dopo l’inizio della generazione.

DSpark migliora direttamente la seconda misura. Migliora la latenza totale quando la decodifica occupa una quota sufficiente della richiesta. Non garantisce un miglioramento proporzionale della prima.

Gli sviluppatori dovrebbero inoltre distinguere la velocità per singolo utente dal throughput dell’intera infrastruttura. Liquid AI ha osservato un vantaggio a tutti i livelli di concorrenza H100 misurati, ma la differenza si è ridotta sotto carico maggiore. L’economia di produzione dipende dai mix di richieste, dal batching e dagli obiettivi di livello di servizio.

L’aspetto più rilevante del rilascio è quindi architetturale. Liquid AI ha confezionato la decodifica speculativa come parte di una famiglia di modelli visivi distribuibile, anziché presentarla soltanto come ricerca.

Se questo schema si diffonderà, i rilasci di modelli potrebbero includere sempre più spesso un target, più quantizzazioni e drafter specifici per hardware. L’ottimizzazione dell’inferenza diventerebbe parte dell’artefatto del modello anziché una decisione di serving successiva.

Questa direzione esercita pressione sugli altri sviluppatori di modelli open-weight. Pubblicare soltanto un checkpoint lascia ai team downstream la responsabilità dell’accelerazione. Distribuire un drafter abbinato offre una storia di latenza più completa, anche quando i guadagni misurati restano dipendenti dal carico di lavoro.

Tre Segnali Mostreranno Se l’Accelerazione Conta Davvero nella Pratica

Test indipendenti, supporto più ampio al sampling e profili di applicazioni reali determineranno se DSpark diventerà un modello di deployment ripetibile.

Il primo segnale è la replica indipendente su hardware accessibile. Gli sviluppatori dovrebbero osservare i test su Mac della serie M, GPU consumer e sistemi edge che usano prompt identici con e senza il drafter.

I report utili devono indicare dimensioni delle immagini, lunghezza del prompt, lunghezza dell’output, temperatura, quantizzazione e versione del runtime. Un singolo valore di token al secondo non può spiegare se la risposta completa dell’applicazione sia diventata significativamente più rapida.

Repliche vicine agli intervalli di Liquid AI rafforzerebbero il caso dell’azienda. Guadagni inferiori o incoerenti suggerirebbero che i carichi di lavoro pubblicati favoriscono il drafter più di quanto facciano le applicazioni quotidiane.

Il secondo segnale è un supporto più ampio per runtime e sampling. MLX-VLM limita attualmente il percorso DSpark pubblicato alla generazione greedy, mentre SGLang punta al deployment Nvidia e llama.cpp copre i casi d’uso GGUF.

Il supporto in ulteriori motori di inferenza ridurrebbe il costo di integrazione. Un sampling stabile a temperatura diversa da zero renderebbe inoltre il metodo più rilevante per gli strumenti di chat visiva e descrizione creativa.

Gli sviluppatori dovrebbero esaminare i tassi di accettazione al variare del sampling. Liquid AI afferma che temperature più alte hanno ridotto accettazione e throughput nei propri esperimenti. I test di produzione dovrebbero rivelare se tali cali restino accettabili per i prodotti conversazionali.

Il terzo segnale è se i team riportino guadagni a livello di fase da applicazioni reali. Le metriche decisive sono tempo al primo token, velocità di decodifica, latenza end-to-end, memoria di picco e throughput alla concorrenza prevista.

Un assistente visivo per contenuti lunghi può trarre vantaggio in modo sostanziale perché la generazione domina la sua sessione. Un flusso OCR che restituisce pochi campi può guadagnare molto meno perché la codifica visiva e il prefill occupano la maggior parte della richiesta.

I team che valutano Liquid AI LFM2.5-VL-3B-DSpark dovrebbero iniziare dalle tracce, non dai moltiplicatori in evidenza. Misurare la quota di base assorbita da codifica delle immagini, prefill e decodifica. Quindi collegare il drafter e ripetere lo stesso carico di lavoro.

Verificare l’equivalenza dell’output con decodifica greedy e il comportamento distribuzionale con il sampling supportato. Misurare separatamente avvii a caldo e a freddo. Includere pressione sulla memoria e termiche sostenute quando si testano laptop o sistemi di classe mobile.

Il rilascio fornisce dettagli di implementazione sufficienti per rendere possibili queste valutazioni. Ricorda inoltre utilmente agli sviluppatori che la capacità del modello e il comportamento dell’inferenza sono problemi ingegneristici distinti.

La cifra di 3,13x di Liquid AI va interpretata soprattutto come prova che un drafter abbinato può accelerare materialmente una fase dell’inferenza multimodale locale. I numeri end-to-end mostrano sia il valore sia il limite di questa affermazione.

I modelli draft abbinati diventeranno compagni standard dei VLM open-weight, oppure resteranno ottimizzazioni specializzate per carichi di lavoro a output lungo? La risposta verrà da tracce applicative riproducibili, non da un singolo benchmark di picco.