Liquid AI a publicat pe 24.09.2026 un draft model experimental numit LFM2.5-VL-DSpark, construit peste vision-language model-ul LFM2.5-VL-3B. Potrivit anunțului publicat pe blogul Liquid AI și preluat pe Hugging Face, modelul adaugă o cale de decodare speculativă care crește viteza de inferență fără să modifice calitatea output-ului. Sunt raportate decodări de până la 3,13x mai rapide pe device și 2,66x pe un H100, la un cost de 280M parametri suplimentari, adică 8,9% peste modelul țintă de 3B. Este o veste tehnică, nu comercială, și exact aici trebuie făcută distincția între ce e măsurat, ce e ipoteză și ce recomandăm noi.

Ce s-a lansat, concret

Sursa citată (Liquid AI, blog, septembrie 2026) descrie un drafter de viziune cu aceeași arhitectură ca drafturile text LFM2.5-DSpark: capturează hidden states din anumite layere ale modelului țintă și generează un bloc de k tokeni candidați. Patch-urile de imagine și tokenii de text sunt proiectați într-o reprezentare comună înainte de acele layere, deci drafterul lucrează pe vectori de dimensiune identică indiferent de modalitate. Draft model-ul are 4 layere, tip attention-only, block size 9 la antrenare, cu recomandare de 8 sau 9 la inferență, în funcție de hardware. Totalul raportat este de aproximativ 279,5M parametri, din care 193,0M pe stack-ul de decodor, 21,0M pe proiecția de hidden-state, 65,5M pe capul Markov și 6,4k pe norme plus capul de confidence.

Sunt anunțate și integrări din prima zi pentru llama.cpp, MLX-VLM și SGLang, plus disponibilitate pe Hugging Face în Safetensors și GGUF. Atenție la nuanță: „din prima zi” este o afirmație din materialul sursă despre suportul de integrare, nu o garanție de stabilitate în producție. Draft model-ul este explicit etichetat „experimental”.

Ce măsoară de fapt cifrele de viteză

Cifrele raportate acoperă două planuri diferite: decodarea (token cu token) și latența end-to-end. Pe device, cu MLX pe un M5 Max, decodarea e mai rapidă între 2,30x și 3,13x, iar end-to-end între 1,56x și 2,62x. Cu llama.cpp pe un M3 Ultra, decodarea crește între 1,57x și 2,14x, end-to-end între 1,30x și 1,77x. Pe H100, decodarea ajunge între 2,04x și 2,66x, cu end-to-end între 1,64x și 2,27x. Evaluarea acoperă șase tipuri de sarcini vizuale, printre care VQA general, text VQA, captioning, chart VQA, raționament complex și conversație multi-turn, pe un bloc de 8.

Aici este capcana de citire. Cine citește doar titlul reține „3,13x mai rapid”. Cine citește tabelul vede că diferența dintre decodare și end-to-end este consistentă și semnificativă. Pe M5 Max, un 3,13x la decodare devine 2,62x end-to-end în cel mai bun caz, dar și 1,56x în cel mai slab. Pe llama.cpp pe M3 Ultra, intervalul end-to-end scade până la 1,30x. Aceeași tehnologie, rezultate diferite în funcție de hardware și de sarcină. Dacă cineva îți promite un multiplier unic pentru toate cazurile, cere-i tabelul complet.

De ce speculația nu accelerează tot pipeline-ul

Secțiunea despre limite este cea mai importantă din materialul sursă, pentru că explică de ce câștigurile nu sunt proporționale. La modelele lingvistice, prefill-ul este în mare parte limitat de compute și crește aproximativ sub-pătratic cu lungimea promptului. La VLM se adaugă un pas suplimentar: imaginea trece mai întâi prin vision encoder, iar apoi backbone-ul lingvistic procesează sute de tokeni vizuali împreună cu promptul text. Dispozitivele de tip edge au mult mai puțin compute decât GPU-urile din datacenter, deci prefill-ul ocupă o proporție mai mare din latența totală. Decodarea speculativă accelerează doar decodarea, nu encoding-ul vizual și nu prefill-ul.

Este legea lui Amdahl aplicată concret: câștigul total este plafonat de porțiunea de workload pe care nu o accelerezi. Dacă prefill-ul și encoding-ul vizual domină timpul total, o decodare de trei ori mai rapidă produce un câștig end-to-end modest. Aceasta este constatarea cea mai utilă din tot anunțul, pentru că îți spune unde să nu te aștepți la miracole. Notează și nuanța din sursă: acceleratoarele neuronale per core din M5 reduc acest decalaj, deci pe generații mai noi de chip câștigul end-to-end se poate apropia mai mult de cel la decodare. Aceasta este o afirmație a producătorului, nu o verificare independentă.

O distincție corectă de făcut: decodarea speculativă este exactă în ceea ce privește verificarea. Modelul țintă validează fiecare token propus, deci output-ul greedy este egal cu cel al modelului țintă rulat singur. Nu există un compromis de calitate ascuns. Ce poate varia este acceptanța propunerilor, care depinde de drafter și de tipul de sarcină, și care se vede în metricile per răspuns.

Ce verifici înainte să crezi că ai câștigat

Prima verificare: ce parte din latența ta totală este decodare și ce parte este prefill plus encoding vizual. Dacă nu ai aceste două numere, nu poți estima câștigul real, oricât de bun ar fi drafterul. A doua: ce hardware folosești efectiv. Intervalele raportate diferă mult între M5 Max cu MLX, M3 Ultra cu llama.cpp și H100. A treia: ce tip de sarcină domnește în traficul tău. Un flux de captioning pe imagini simple și un flux de raționament complex pe charturi nu se comportă identic. A patra: cum arată acceptanța pe datele tale, nu pe benchmark-ul publicat. A cincea: dacă versiunile de llama.cpp, MLX-VLM și SGLang pe care le folosești includ deja suportul necesar.

Un punct de metodă pe care îl repetăm constant: o verificare incompletă nu dovedește absența unei funcții. Dacă un test rapid nu arată câștig, concluzia corectă este „nu am măsurat corect încă”, nu „nu funcționează”. Abia după ce separi decodarea de prefill și encoding vizual poți spune ceva.

Scenarii ipotetice, marcate ca atare

Următoarele sunt scenarii de lucru, nu rezultate măsurate. Dacă rulezi un VLM local pe un laptop pentru asistent de documente vizuale, iar timpul tău este dominat de generarea răspunsului, nu de procesarea imaginii, atunci un câștig de decodare de două-trei ori s-ar putea traduce într-o latență perceptibil mai bună. Invers, dacă fiecare cerere trimite imagini mari, cu multe patch-uri, iar răspunsul este scurt, prefill-ul și encoding-ul domină și câștigul end-to-end va fi mic. Dacă ai un pipeline batch offline de analiză de imagini, unde timpul total de rulare contează mai mult decât latența per cerere, atunci economia de timp la decodare se cumulează pe volum și devine vizibilă. Toate acestea sunt ipoteze care trebuie testate pe datele tale.

Ce înseamnă pentru tine, ca antreprenor sau marketer român

Dacă ai un magazin online sau rulezi campanii și te uiți la Google Merchant Center AI Performance: ce vezi în raport, întrebarea legitimă este: de ce mă interesează un draft model pentru VLM? Răspunsul scurt: costul și viteza analizei vizuale. Dacă folosești sau intenționezi să folosești modele care înțeleg imagini pentru clasificarea produselor, extragerea de atribute din fotografii, moderarea conținutului vizual sau citirea de capturi și grafice din rapoarte, atunci viteza și costul de inferență contează direct în bugetul tău operațional. Un model mai rapid la decodare, fără pierdere de calitate, înseamnă mai multe cereri procesate pe aceeași infrastructură. Nu înseamnă automat CPA mai mic sau vânzări mai mari. Nu avem date pentru a susține așa ceva și nu o vom face.

Pentru un antreprenor mic, relevanța practică este că inferența locală pe hardware modest devine mai viabilă pentru volume mici. Dacă ai un flux de lucru care nu poate pleca spre un API extern din motive de cost sau de confidențialitate a datelor, un VLM mai rapid la decodare îți permite să rulezi mai multe imagini pe același laptop sau pe același server mic. Pentru un marketer care lucrează cu conținut vizual generat, vestea nu schimbă strategia, dar schimbă calculul de cost pe volum dacă folosește modele deschise.

Un alt context util: tranziția spre AI Search și citare LLM, detaliate în Gemini 3.8 Live cu Live Avatar: ce schimbă pentru business, arată că tot mai mult conținut comercial trece prin pipeline-uri care combină text, imagine și, uneori, video. Costul per unitate de conținut procesat devine o variabilă de business, nu doar o curiozitate tehnică.

Limitele pe care trebuie să le spui cu voce tare

Sursa nu oferă date despre preț, despre stabilitatea în producție, despre comparații independente cu alte metode de accelerare sau despre comportamentul la volume mari. Raportările sunt ale producătorului, pe benchmark-uri proprii, nu ale unei terțe părți. Formatul este etichetat experimental de către creator. Orice integrare ar trebui tratată ca atare: testată pe datele tale, cu baseline măsurat corect, înainte să intre în producție pe un flux critic.

FAQ

Se schimbă calitatea răspunsului dacă folosesc LFM2.5-VL-DSpark? Nu, conform materialului sursă. Decodarea speculativă este exactă, modelul țintă validează fiecare token propus, iar output-ul greedy este egal cu cel al modelului țintă rulat singur.

Cu cât e mai rapid, de fapt? Depinde de hardware și sarcină. Sunt raportate creșteri la decodare de până la 3,13x pe device și 2,66x pe H100, dar câștigul end-to-end este mai mic, până la 2,62x pe M5 Max și 2,27x pe H100, pentru că decodarea speculativă nu accelerează encoding-ul vizual și prefill-ul.

Ce trebuie să verific înainte de a-l folosi? Cât din latența ta totală este decodare și cât este prefill plus encoding vizual, ce hardware rulezi, ce tip de sarcini vizuale ai și ce versiuni de llama.cpp, MLX-VLM sau SGLang folosești, pentru că suportul este anunțat pentru build-uri specifice.

Concluzie

Uneltele de tip LFM2.5-VL-DSpark ajută la partea de analiză, planificare și dimensionare a infrastructurii, pentru că îți permit să estimezi unde se duce timpul într-un pipeline vizual. Dar decizia de a muta un flux în producție și execuția măsurătorii corecte rămân umane, adică ale media buyer-ului sau ale omului de operațiuni care răspunde de cost și de latență. Pasul concret, de la „am citit un anunț” la „am un baseline măsurat și o decizie documentată”, este cel pe care îl facem noi la ALLSoft Agency, pe datele tale, nu pe promisiuni de multiplicator.