AuK vs AuK-Flash: 32 samplingssteg eller 4, och varför studenten ibland vinner

Båda checkpoints väger exakt 6,122 GB. Båda släpps under MIT-licens. Båda drivs av samma separat nedladdade instruktionskodare med 3 miljarder parametrar och samma VAE på 637 MB. AuK och AuK-Flash skiljer sig åt i nästan ingenting du konfigurerar — och i en sak du känner av vid varje anrop: hur många gånger samplern körs. AuK, den grundmodell med öppna vikter och 1,5B parametrar för talgenerering och redigering, som Tencent-Hunyuan-teamet och akademiska medförfattare vid Shanghai Jiao Tong och NTU lade upp på Hugging Face den 9 september, använder 32 funktionsutvärderingar med klassificerarfri vägledning vid 2,0. AuK-Flash, den destillerade studenten, använder fyra, med vägledning helt avstängd, för en påstådd 4,5× hastighetsökning i väggklocktid. Den uppenbara tolkningen är att Flash är den budgetplats du tar när latens väger tyngre än kvalitet. Den tolkningen är fel, och det är tillverkarens egna utvärderingstabeller som motsäger den: i den tekniska rapportens head-to-head-rader tar Flash toppoängen på MMAE-Speechs edit-ratio-mått, på SpeechEditBenchens paralingvistiska kolumn, på engelsk instruktionsföljning, på talarlikhet vid akustisk redigering, och på alla fyra raderna för perceptuell kvalitet i förbättring. Det är inte en nedgradering. Det är en annan avvägning, och vilken sida av den du vill ha beror på vilken av de två uppgifterna du faktiskt kör.

Vad skiljer dem faktiskt åt?

Skala bort marknadsföringen och valet reduceras till en konfigurationsfil. AuK:s runtime är en hybrid rectified-flow Transformer — tvåströmmiga MMDiT-block som matar enhetliga enkelströmmiga DiT-block — som kör en bfloat16-Euler-lösare vid 24 kHz med 64-dimensionella latenta variabler vid 50 Hz. AuK-Flash kör den identiska arkitekturen med en destillerad sampler ditbultad, skapad genom consistency-initialisering plus uppgiftsroutad Decoupled DMD. Alla övriga komponenter är delade.

• Samplingsteg — AuK: 32 funktionsutvärderingar, konfigurerbart. AuK-Flash: 4, fast.

• Klassificerarfri vägledning — AuK: skala 2.0, justerbar. AuK-Flash: ingen (CFG=0).

• Checkpointstorlek — AuK: auk_base.safetensors på 6.122 GB. AuK-Flash: auk_flash.safetensors på 6.122 GB. Identiska ner till megabyten.

• Delad runtime — en 637 MB VAE plus Qwen/Qwen2.5-Omni-3B-encodern, som laddas ner separat och används av båda.

• Påstådd hastighet — AuK-Flash: 4,5× snabbare väggklockstid än 32-NFE-läraren vid matchad hårdvara, varaktighet och batchstorlek.

• Licens — MIT för båda, vilket för en gångs skull betyder vad det säger.

Den identiska checkpoint-storleken är detaljen som sätter hela jämförelsen i ett nytt ljus. Destillerade varianter brukar köpa sin snabbhet genom att vara mindre. AuK-Flash är inte mindre. Du sparar inte diskutrymme, du sparar inte överföringstid, och — eftersom kodaren och VAE delas och DiT har samma bredd — sparar du inte nämnvärt med VRAM genom att välja studenten. Den enda resurs Flash ger dig tillbaka är tid. Värt att nämna en budgetfälla ändå: "1.5B" i modellnamnet beskriver diffusionsryggraden, och filen på disk är 6,122 GB. Avsätt utrymme för filen.

Var AuK-Flash faktiskt slår hela modellen

Detta är den del där instinkten att "destillerad = sämre" har fel, och det håller i sig över flera orelaterade uppgiftsfamiljer i rapportens tabeller. Börja med perception. På DNS Challenge-förbättringssetet uppnår Flash UTMOS 4,05 mot AuK:s 3,86; på CHiME-4, 3,91 mot 3,72; på Libri2Mix, 4,03 mot 3,87; på VCTKSR, 4,05 mot 3,93. Flash vinner också kolumnen för igenkänningsfel på två av dessa fyra set, med CHiME-4 WER på 7,84 jämfört med 7,98 och VCTKSR WER på 2,92 jämfört med 3,06. Mänskligt bedömd naturlighet är den enda axeln där studentmodellen konsekvent ligger före, och rapporten säger det uttryckligen: den fulla modellen erbjuder starkare språklig noggrannhet och redigeringsprecision, medan Flash "ofta erbjuder bättre perceptuell kvalitet".

Vinsterna är inte begränsade till förbättring. På MMAE-Speech:s edit-ratio-mått – huruvida en redigering hamnar på den avsedda magnituden – får Flash 13.85 mot AuK:s 12.44. På SpeechEditBench:s paralingvistiska kolumn är det 39.25 mot 38.50. På InstructTTSEval:s engelska beskrivning-till-tal-uppgift är det 82.40 mot 81.60, vilket matchar den bästa baslinjen på den raden. På akustisk redigering i Ming-Freeform-sviten innehar den högsta talarlikhet inom familjen, 0.79 på kinesiska och 0.75 på engelska, mot 0.78 och 0.74 för basmodellen. Med andra ord är bevarande av talaridentitet en av de saker som fyra steg köper dig – rapportens egen sammanfattning är att den fulla modellen ger lägre genomsnittligt igenkänningsfel medan Flash bättre bevarar talaridentitet. Om du arbetar med röstkonvertering, dubbning eller förbättringsarbete där klangfärg betyder mer än ordavvikelser, är studentmodellen den bättre modellen.

Där de 32 stegen fortfarande gör skäl för sig

Basmodellens fördelar koncentrerar sig exakt där man skulle förvänta sig av en diffusionsmodell med större samplingsbudget: allt där resultatet måste vara språkligt korrekt.

På Seed-TTS-Eval är AuK:s genomsnittliga WER 2,65 mot Flash:s 2,85, med talarlikhet på 0,795 mot 0,790. Spridningen inom det genomsnittet är mer informativ än genomsnittet i sig. Båda är i praktiken lika på den engelska testuppsättningen — 1,02 och 1,03 — och skiljer sig på kinesiska, 1,02 mot 1,10, och igen på den svåra kinesiska delmängden, 5,91 mot 6,43. Kinesiska är där de extra stegen lönar sig.

Samma mönster återkommer i instruktionsföljning. På InstructTTSEvals kinesiska beskrivning-till-tal-uppgift är gapet brett: 83.37 för AuK mot 78.80 för Flash, och rapporten konstaterar att basmodellen leder på alla tre kinesiska mätvärdena i den sviten medan Flashs "främsta fördel är dess starkare engelska DSD-resultat." Språk, inte arkitektur, är skiljelinjen.

Redigeringsprecision skiljer dem åt mest. SpeechEditBench:s träffsäkerhet för innehållsredigering är 91.83 för AuK mot 87.50 för Flash – den största enskilda skillnaden i jämförelsen. Akustisk redigering är nästan lika ojämn: 37.07 mot 30.26. I Ming-Freeform-sviten rapporterar AuK lägre WER nästan överallt där det betyder något: 3.09 mot 3.34 vid fullständig kinesisk redigering, och en betydligt större skillnad: 3.96 mot 4.84 vid fullständig engelsk redigering. Om din produkt skriver om orden i någons inspelning – sångtextredigeringar, innehållsersättning, infogning och borttagning – är 32-stegsmodellen den som håller transkriptionen tillförlitlig, och 8× stegskillnaden är värd att betala för.

Båda modellerna är även, enligt rapportens egna siffror, fortfarande svaga på emotionell redigering: SpeechEditBench emotion accuracy är 9,94 för AuK och 6,29 för Flash. Det är inte en destillationsartefakt. Det är en uppgiftsfamilj som ingen har löst, och att välja studentmodellen kommer inte göra dig sämre på den än du redan är.

4.5×:et är ett provtagningsnummer, inte ett end-to-end-nummer.

Här är aritmetiken som rubrikens utlovade snabbhet döljer, och det är det enskilt mest nyttiga att förstå innan du binder en arkitektur till Flash.

AuK-Flash kör 4 samplingssteg medan AuK kör 32. Det är 8× färre steg. Leverantören rapporterar 4,5× snabbare väggtid. Skillnaden mellan dessa två siffror är allt runt samplingsloopen, och den domineras av encodern: en Qwen2.5-Omni-3B multimodal modell som båda checkpoints laddar och som båda måste köra för varje begäran. Den encodern är ungefär dubbelt så stor som diffusionens ryggrad, och dess kostnad är fast. Flash kan inte snabba upp den, eftersom Flash inte är en del av den.

4,5×{{1}} är vad du får på diffusionsdelen{{/1}} under matchade förhållanden, och din end-to-end-vinst blir den andel av din väggklockstid som samplingloopen{{2}} faktiskt upptar{{/2}}. Om du kör långformsgenerering där 32 steg över många latenta bildrutor dominerar, hamnar du nära det publicerade värdet{{3}}.{{/3}} Om din arbetsbelastning är korta klipp med tung instruktionsförbehandling, eller om du batchar små förfrågningar, sitter en större del av varje anrop i den delade enkodaren{{4}} och din verkliga hastighetsökning blir avsevärt mindre än 4,5×.{{/4}} Mät din egen blandning{{5}} innan du låter en latensbudget bero på den{{/5}}. Ingen har publicerat den siffran för end-to-end ännu — inte ens leverantören, som inte rapporterar några absoluta latenssiffror{{6}} eller VRAM-krav alls.{{/6}}

Vad destilleringen kostar, med författarnas egna ord

Den tekniska rapporten är ovanligt öppenhjärtig om var eleven brister, och dessa feltillstånd är mer användbara för en driftsättare än benchmarktabellen.

Lärarstyrda mål visade sig vara problemet. Att använda CFG-mål i konsistensgrenen "kan utsätta studentmodellen med få steg för övermättade förutsägelser", vilket enligt författarna orsakar översvängning och hörbar klippning. Separat sett "försämrar ett enhetligt Decoupled DMD-schema separationen av flera talare och vokalseparation", där vissa studentutdata regredierar mot den obearbetade mixen — destillationen raderar den separation som modellen skulle utföra. Uppgiftsdirigerad DMD är den beskrivna lösningen, och det är därför rapporten är noga med att avgränsa just den svagheten till den enhetliga varianten. Om talseparation är en central del av din pipeline är detta det stycke du bör testa mot innan du litar på det.

Ytterligare två begränsningar är operativa snarare än statistiska. Pipelinens Prompt Enhancer mappar vardagliga formuleringar om hastighet, ljudstyrka och tonhöjd till en fast uppsättning värden som stöds, och avvisar allt den inte kan mappa innan akustisk inferens körs — så icke-stödda förfrågningar misslyckas tidigt snarare än att försämras gradvis. Och repot accepterar endast Qwen/Qwen2.5-Omni-3B som encoder-sökväg; README anger att Qwen3-Omni för närvarande inte stöds, så en nyare encoder är inte en drop-in-uppgradering. ComfyUI-integrationen har en 30-sekundersgräns för käll- plus målsekvenser.

Att köra båda är den avsedda konfigurationen.

Repots eget multi-GPU-exempel placerar AuK på en enhet och AuK-Flash på en annan — cuda:0 och cuda:1 — vilket är en tydlig signal om att Tencent förväntar sig att dessa samexisterar snarare än konkurrerar. Det är också rätt svar för de flesta talstackar i produktion, eftersom de två modellerna är starka inom olika områden. Dirigera redigeringstunga och kinesiskspråkiga förfrågningar till AuK; dirigera förbättring, separation, instruktionsföljning på engelska och allt interaktivt till AuK-Flash. Båda laddar samma encoder och samma VAE, så du betalar för den delade runtime en gång och växlar mellan checkpoints bakom den.

Det är ett routingbeslut på modellagret, och det har samma form som det OrcaRouter tillämpar på API-lagret för värdbaserade modeller. Där de två möts idag är skarven i AuK:s egen pipeline: Prompt Enhancer kräver en OpenAI-kompatibel chatt-endpoint för att omvandla en grov instruktion till modellens stödda vokabulär, och den valfria ASR-fallbacken behöver en transkriptionsväg. Peka endera mot en OpenAI-kompatibel chatt-endpoint så får du en enda nyckel för över 200 modeller, leverantörens listpris förs vidare med 0 % påslag, och automatisk failover om en backend går ner — vilket är viktigt just eftersom detta är en två dagar gammal release utan värdbaserat API och utan oberoende reproduktion, och du vill inte ha ett obeprövat beroende som förlitar sig på en hårdkodad endpoint.

Var dock tydlig med vad som inte är tillgängligt. Varken AuK eller AuK-Flash tillhandahålls av någon värdbaserad inferensleverantör – Hugging Face-korten säger det direkt – och ingen av dem kan dirigeras via OrcaRouter idag. Detta är ett självhosting-beslut från början till slut.

Vad är fortfarande okänt?

Nästan allt med den här releasen är leverantörsrapporterat. Den 4,5× snabbheten, WER-siffrorna, SpeechEditBench-kolumnerna och UTMOS-raderna kommer alla från AuK-teamets egen tekniska rapport, arXiv 2609.08936, inlämnad den 8 september – det finns ingen oberoende reproduktion, ingen tredjepartsleaderboard-post och inget neutralt testresultat. Adoptionssignalen är lika tunn: per den 10 september visar de två Hugging Face-repositories 30 nedladdningar den senaste månaden och ungefär två dussin gillanden vardera, medan GitHub-repositoryt visar 217 stjärnor, 12 forks och tre bidragsgivare. Det är en forskningssläpp, inte en modevåg.

img src="4.png" alt="Skärmdump av README för Tencent-Hunyuan AuK:s GitHub-repo som visar open source-meddelandet från 9 september 2026 och tabellen över varianterna AuK och AuK-Flash"> p>Själva releasen var tyst på ett sätt som är värt att säga rakt ut, eftersom det är lätt att läsa in för mycket. Det fanns inget Hunyuan-tillkännagivande, inget blogginlägg, ingen prissida och inget lanseringsevent. Leverantörens enda daterade uttalande är en enda rad i repoets README — [2026/09/09] Vi släpper AuK som open source. Metadata för Hugging Face-repot visar att Spaces skapades tidigare, i mitten av augusti, och att vikterna senast rördes den 9 och 10 september, så packningen skedde innan tillkännagivandet. Vad som går att veta från repot: MIT-licensierade vikter för båda varianterna, en teknisk rapport, fungerande nedladdningsinstruktioner för Hugging Face och ModelScope, och en dokumenterad uppgiftslista. Vad som inte är bekräftat: huruvida några av de rapporterade siffrorna överlever en oberoende testmiljö, huruvida en värdbaserad slutpunkt kommer att dyka upp, och huruvida Flash-checkpointen förblir den rekommenderade standarden när andra har kört den.

Vilken ska man välja?

Om du bygger innehåll eller textredigering, eller tillhandahåller kinesiskspråkigt tal i någon form, ta AuK och acceptera de 32 stegen. Dess fördelar där är stora, konsekventa över två oberoende redigeringssviter, och exakt den typ av korrekthetsfel — ett felaktigt ord i transkriptionen — som användare omedelbart märker.

Om du bygger förbättring, separation, röstkonvertering eller något annat där en människa väntar på resultatet, ta AuK-Flash. Den är betydligt snabbare i samplingsslingan, den vinner helt klart på raderna för perceptuell kvalitet, och den bevarar talarens identitet bättre än modellen den destillerades från. Den kvalitetsskillnad som faktiskt finns är koncentrerad till uppgifter som du förmodligen inte kör.

Om du bygger en talprodukt som omfattar båda, kör båda. Samma disk, samma kodare, samma licens, en konfigurationsskillnad — och det distributionsmönster som repositoryt redan demonstrerar. Det enda som är värt att vänta på är din egen mätning av end-to-end-latens: 4,5× är verkligt, men det tillhör samplern, och bara din arbetslastmix avgör hur mycket av det som når dina användare.