MiMo-V2.5-DFlash kan gjøre lokal AI raskere – men oppskriften mangler

Hvis du er ute etter raskere lokal AI på kraftig maskinvare, er MiMo-V2.5-DFlash interessant: Xiaomi har publisert offisielle vekter for en DFlash-variant som skal korte ned ventetiden uten å la en mindre modell bestemme svaret.

Hvis du kjører store språkmodeller lokalt, kjenner du problemet: Modellen kan være god, men du sitter og ser token for token komme ruslende ut som om de har all verdens tid. DFlash prøver å gjøre ventingen kortere ved å foreslå flere tokens samtidig og la hovedmodellen kontrollere dem.

Det interessante denne gangen er at dette ikke er en uoffisiell tilpasning fra en entusiast. Xiaomis egen MiMo-konto har publisert MiMo-V2.5-DFlash, komplett med hovedvekter, kode og en egen DFlash-draftmodell. Det mindre imponerende er dokumentasjonen: README-filen er i praksis tom. Vektene kom først. Bruksanvisningen får tydeligvis ta neste buss.

Hva har Xiaomi faktisk publisert?

Xiaomi har publisert et modellager på omtrent 319 GB med 311 milliarder parametere registrert av Hugging Face. Den egne DFlash-mappen inneholder blant annet en draftmodell på 2,94 GB, konfigurasjon, Python-kode og en maske-embedding. Filhistorikken viser opplasting 3. juli og siste DFlash-oppdatering 4. juli 2026.

Det er dermed rimelig å kalle dette offisielle DFlash-vekter, ikke bare en mappe med et lovende navn. Draftmodellen har fem lag og er satt opp til å jobbe med blokker på åtte tokens. Den henter dessuten mellomtilstander fra fem steder i den 48 lag dype hovedmodellen. Det er konkrete komponenter som kan brukes i en faktisk implementasjon.

Men lageret er ikke en ferdig oppskrift for vanlig lokal kjøring. Modellkortet mangler installasjonskommandoer, støttede inference-motorer, anbefalte innstillinger og målte hastigheter for denne varianten. Det finnes heller ingen offisiell tabell som forteller hva du får på to skjermkort, en arbeidsstasjon eller en server. Forskjellen mellom «vektene finnes» og «dette er lett å kjøre» er fortsatt ganske stor.

Hva er MiMo-V2.5-DFlash?

MiMo-V2.5-DFlash er Xiaomis MiMo-V2.5 med en ekstra, liten draftmodell for DFlash-basert spekulativ dekoding. Hovedmodellen er en mixture-of-experts-modell med omtrent 310 milliarder parametere totalt og 15 milliarder aktive per token, ifølge det offisielle modellkortet for MiMo-V2.5.

MiMo-V2.5 er i utgangspunktet en omnimodal modell som kan forstå tekst, bilder, video og lyd. Den vanlige modellen støtter et kontekstvindu på opptil én million tokens, mens DFlash-konfigurasjonen oppgir 262 144 posisjoner for draftmodellen. Uten dokumentasjon bør ingen derfor love at DFlash-akselerasjonen virker over hele kontekstvinduet på én million tokens.

MoE-arkitekturen betyr at ikke alle de 310 milliardene brukes for hvert token, men alle vektene må likevel lagres eller fordeles. Det er grunnen til at dette ikke plutselig blir en modell for en vanlig bærbar PC bare fordi draftdelen er 2,94 GB. DFlash kan redusere tiden det tar å generere svaret. Den tryller ikke bort hovedmodellen.

Jeg har tidligere skrevet om Xiaomis større MiMo-V2-Pro. DFlash-utgaven her gjelder den mindre MiMo-V2.5-modellen, men «mindre» bør leses med en viss sans for proporsjoner. Rundt 310 milliarder parametere er fortsatt et solid møbel i stua.

Hvordan gjør DFlash genereringen raskere?

DFlash bruker en liten block diffusion-modell til å foreslå flere tokens parallelt i én fremoverpassering. Hovedmodellen kontrollerer deretter forslagene samlet og godtar bare tokens som passer dens egen sannsynlighetsfordeling. Målet er samme svarfordeling som før, men færre kostbare, sekvensielle runder gjennom den store modellen.

En vanlig autoregressiv språkmodell lager neste token, så neste, så neste. Skjermkortet kan være svært raskt, men prosessen har en innebygd kø: token nummer åtte kan ikke beregnes før de sju første er klare. Spekulativ dekoding lar en billigere komponent gjette fortsettelsen, mens hovedmodellen opptrer som kontrollør.

Det spesielle med DFlash er at også draftingen skjer parallelt. I stedet for å la en liten autoregressiv modell gjette ett token om gangen, fyller block diffusion-modellen inn en hel blokk. DFlash-artikkelen beskriver blokker på åtte tokens og tapsfri akselerasjon, fordi hovedmodellen fortsatt verifiserer forslagene før de brukes.

Forskerne rapporterte over seks ganger raskere generering i enkelte kombinasjoner av modeller og oppgaver. Det tallet gjelder forsøkene i forskningsartikkelen, ikke MiMo-V2.5-DFlash på maskinen din. Jeg har allerede gått grundigere gjennom hvordan DFlash og spekulativ dekoding fungerer. Her er nyheten at Xiaomi nå har levert de modellspesifikke delene som manglet.

Er MiMo-V2.5-DFlash dobbelt så rask?

Det vet vi ikke ennå. Xiaomi har ikke publisert hastighetsmålinger for MiMo-V2.5-DFlash, og modellkortet inneholder foreløpig ingen resultater. Påstander om dobling eller bestemte tokens per sekund må derfor behandles som forventninger fra miljøet, ikke som dokumentert ytelse.

Farten avhenger av hvor ofte hovedmodellen godtar de foreslåtte tokenene. Hvis draftmodellen treffer godt, kan flere tokens godkjennes i hver kontrollrunde. Hvis den bommer tidlig i blokken, må hovedmodellen gjøre mer av jobben på vanlig måte. Prompt, temperatur, svarstil og oppgave påvirker dermed gevinsten, i tillegg til skjermkort og inference-motor.

Maskinvareoppsettet betyr også mye. En modell på rundt 319 GB må gjerne fordeles mellom flere GPU-er, systemminne og eventuelt rask lagring. Når deler av modellen flyttes mellom minneområder, kan båndbredden bli flaskehalsen. En raskere dekoder hjelper, men den kan ikke løpe fra en treg dataflyt for alltid.

Det finnes likevel gode grunner til å følge med. I tidligere praktisk arbeid med ExLlamaV3 og DFlash har teknikken gitt rundt 2,5 ganger raskere lokal inferens i et konkret oppsett. Det viser at ideen kan fungere utenfor en forskningsfigur. Det beviser bare ikke at Xiaomi-varianten gir samme resultat.

Kan modellen kjøres på to skjermkort med 24 GB VRAM?

Ikke med hele modellen liggende i VRAM. To kort med 24 GB gir 48 GB videominne, mens det offisielle modellageret er rundt 319 GB. Resten må kvantiseres kraftig, fordeles til systemminne eller håndteres gjennom en annen form for avlasting. Det kan være mulig, men det er en helt annen påstand enn at modellen «passer på to kort».

En GGUF-kvantisering kan gjøre modellen mer tilgjengelig for llama.cpp-baserte oppsett, men Xiaomi har foreløpig ikke lagt ut en offisiell GGUF. Det må også finnes støtte for DFlash-komponentene. En vanlig kvantisering av hovedmodellen gir ikke automatisk akselerasjon fra draftmodellen, koden og de ekstra tilstandene.

Det mest realistiske første publikummet er derfor folk med mye systemminne, flere GPU-er eller servermaskinvare – og utviklere som er villige til å koble delene sammen før dokumentasjonen er på plass. For alle andre er dette foreløpig mer et tegn på hva som kommer enn en modell du laster ned etter middag og har i gang før kaffen er kald.

Hvorfor er den innebygde MTP-delen viktig?

MiMo-V2.5 har allerede multi-token prediction, ofte forkortet MTP. Det offisielle modellkortet oppgir tre MTP-lag med 329 millioner parametere totalt, og modellageret inneholder også en egen MTP-fil. MTP trener modellen til å forutsi flere kommende tokens, og slike mellomtilstander kan gi en draftmodell bedre informasjon enn bare teksten som allerede er skrevet.

DFlash-konfigurasjonen for MiMo-V2.5 peker på lag 0, 11, 23, 35 og 47 i hovedmodellen. Det tyder på at draftmodellen får signaler fra flere nivåer i nettverket, fra tidlige representasjoner til det siste laget. Poenget er å lage bedre forslag uten å bygge en nesten like tung ekstramodell ved siden av.

Dette er interessant fordi spekulativ dekoding lever og dør på kvaliteten til forslagene. En mikroskopisk draftmodell er rask, men ubrukelig hvis hovedmodellen avviser nesten alt. En stor draftmodell treffer bedre, men spiser opp tidsgevinsten. DFlash prøver å finne balansen med fem lag, blokkstørrelse åtte og kunnskap hentet direkte fra målmodellen.

Jeg har også sett samme grunnidé fra en annen kant i arbeidet med MTP og TurboQuant i llama.cpp. Flere tokenforslag er ikke magi. Gevinsten kommer når forslag, verifisering, minnebruk og maskinvare faktisk spiller på lag.

Hva mangler før dette blir praktisk?

Først mangler en offisiell oppskrift. Xiaomi bør dokumentere hvilken inference-motor og versjon som støttes, hvordan DFlash lastes sammen med hovedmodellen, hvilke kommandoer som brukes og hvilke begrensninger som gjelder. En tom README ved siden av 319 GB med vekter er teknisk sett minimalistisk. Den er bare ikke særlig hjelpsom.

Deretter trengs reproduserbare målinger. Tokens per sekund bør oppgis med maskinvare, tallformat, batch-størrelse, kontekstlengde, temperatur og graden av CPU- eller RAM-avlasting. Uten det blir et hastighetstall omtrent like informativt som å si at en bil er «rask» uten å nevne om den kjørte nedoverbakke.

Til slutt må verktøyene rundt modellen ta igjen vektene. Kvantisering, GGUF, llama.cpp, SGLang eller andre motorer må forstå både hovedmodellen og DFlash-flyten. Den gode nyheten er at Xiaomi har lagt ut selve draftmodellen, koden og konfigurasjonen under MIT-lisens. Miljøet slipper altså å gjette seg frem til de modellspesifikke vektene.

MiMo-V2.5-DFlash er derfor en reell og interessant utgivelse, men ikke et ferdig forbrukerprodukt. Det viktigste er ikke et udokumentert løfte om dobbelt fart. Det er at en svært stor, åpen modell nå har fått en offisiell DFlash-komponent som utviklere kan undersøke, kvantisere og bygge støtte rundt. Nå mangler bare den lille detaljen som kalles instruksjoner.

Ofte stilte spørsmål