Titolo per un confronto tra AuK e AuK-Flash, che recita "AuK vs AuK-Flash - 32 passi di campionamento o 4?" con un sottotitolo "Generazione e editing vocale - modello base vs studente distillato" e tre riquadri con icone che riportano 24 kHz, NFE 4 vs 32 e 6.12 GB.
Guides & Insights

AuK vs AuK-Flash: 32 passi di campionamento o 4, e perché a volte vince lo studente

Autore

Alistair Wren

Data di pubblicazione

Ultimi modelli · 20Vedi tutti i modelli
Benchmark: Artificial Analysis · aggiornato ogni giorno
Torna a tutti gli articoli

Both checkpoints weigh exactly 6.122 GB. Both ship under MIT. Both are driven by the same separately-downloaded 3-billion-parameter instruction encoder and the same 637 MB VAE. AuK and AuK-Flash differ in almost nothing you provision — and in one thing you feel on every call: how many times the sampler runs. AuK, the 1.5B open-weight speech generation and editing foundation model that Tencent's Hunyuan team and academic co-authors at Shanghai Jiao Tong and NTU put on Hugging Face on September 9, spends 32 function evaluations with classifier-free guidance at 2.0. AuK-Flash, the distilled student, spends four, with guidance switched off entirely, for a claimed 4.5× wall-clock speedup. The obvious reading is that Flash is the budget seat you take when latency outranks quality. That reading is wrong, and the vendor's own evaluation tables are what contradict it: on the technical report's head-to-head rows, Flash takes the top score on MMAE-Speech's edit-ratio metric, on SpeechEditBench's paralinguistic column, on English instruction-following, on acoustic-editing speaker similarity, and on all four enhancement perceptual-quality rows. It is not a downgrade. It is a different trade, and which side of it you want depends on which of the two tasks you are actually running.

What actually differs between them

Strip away the marketing and the choice reduces to a config file. AuK's runtime is a hybrid rectified-flow Transformer — dual-stream MMDiT blocks feeding unified single-stream DiT blocks — running a bfloat16 Euler solver at 24 kHz, 64-dimension latents at 50 Hz. AuK-Flash runs the identical architecture with a distilled sampler bolted on, produced by consistency initialization plus task-routed Decoupled DMD. Every other component is shared.

Sampling steps — AuK: 32 function evaluations, configurable. AuK-Flash: 4, fixed.

Classifier-free guidance — AuK: scale 2.0, tunable. AuK-Flash: none (CFG=0).

Checkpoint size — AuK: auk_base.safetensors at 6.122 GB. AuK-Flash: auk_flash.safetensors at 6.122 GB. Identical to the megabyte.

Shared runtime — a 637 MB VAE plus the Qwen/Qwen2.5-Omni-3B encoder, downloaded separately and used by both.

Claimed speed — AuK-Flash: 4.5× faster wall-clock than the 32-NFE teacher at matched hardware, duration, and batch size.

Licence — MIT for both, which for once means what it says.

That identical checkpoint size is the detail that reframes the whole comparison. Distilled variants usually buy their speed by being smaller. AuK-Flash is not smaller. You do not save disk, you do not save transfer time, and — since the encoder and VAE are shared and the DiT is the same width — you do not meaningfully save VRAM by picking the student. The only resource Flash returns to you is time. Worth naming one budget trap anyway: the "1.5B" in the model name describes the diffusion backbone, and the file on disk is 6.122 GB. Provision for the file.

Where AuK-Flash actually beats the full model

This is the part the "distilled = worse" instinct gets wrong, and it holds up across several unrelated task families in the report's tables. Start with perception. On the DNS Challenge enhancement set, Flash posts UTMOS 4.05 against AuK's 3.86; on CHiME-4, 3.91 against 3.72; on Libri2Mix, 4.03 against 3.87; on VCTKSR, 4.05 against 3.93. Flash also wins the recognition-error column on two of those four sets, with CHiME-4 WER of 7.84 versus 7.98 and VCTKSR WER of 2.92 versus 3.06. Human-rated naturalness is the one axis where the student is consistently ahead, and the report says so explicitly: the full model offers stronger linguistic accuracy and edit fidelity, while Flash "often offers better perceptual quality."

The wins are not confined to enhancement. On MMAE-Speech's edit-ratio metric — whether an edit lands at the intended magnitude — Flash scores 13.85 to AuK's 12.44. On SpeechEditBench's paralinguistic column it is 39.25 to 38.50. On InstructTTSEval's English description-to-speech task it is 82.40 against 81.60, which ties the best baseline on that row. On acoustic editing in the Ming-Freeform suite it holds the highest speaker similarity of the family, 0.79 in Chinese and 0.75 in English, against 0.78 and 0.74 for the base. Speaker identity preservation, in other words, is one of the things four steps buys you — the report's own summary is that the full model gives lower average recognition error while Flash better preserves speaker identity. If you are doing voice conversion, dubbing, or enhancement work where timbre matters more than word error, the student is the better model.

A two-column scoreboard comparing AuK and AuK-Flash across six dimensions. AuK: 32 configurable sampling steps, CFG scale 2.0, Seed-TTS-Eval WER 2.65 average, editing accuracy 91.83, enhancement UTMOS 3.86, checkpoint size 6.122 GB. AuK-Flash: 4 fixed sampling steps, no guidance (CFG 0), Seed-TTS-Eval WER 2.85 average, editing accuracy 87.50, enhancement UTMOS 4.05, checkpoint size 6.122 GB. Footer reads "Vendor-reported figures, AuK technical report; no independent reproduction yet."

Where the 32 steps still earn their keep

The base model's advantages concentrate in exactly the place you would expect from a diffusion model with more sampling budget: anything where the output has to be linguistically correct.

On Seed-TTS-Eval, AuK's average WER is 2.65 against Flash's 2.85, with speaker similarity at 0.795 against 0.790. The spread inside that average is more informative than the average itself. Both are effectively tied on the English test set — 1.02 and 1.03 — and separate on Chinese, 1.02 against 1.10, and again on the hard Chinese subset, 5.91 against 6.43. Chinese is where the extra steps pay.

The same pattern shows up in instruction-following. On InstructTTSEval's Chinese description-to-speech task the gap is wide: 83.37 for AuK against 78.80 for Flash, and the report notes the base model leads on all three Chinese metrics of that suite while Flash's "main advantage is its stronger English DSD result." Language, not architecture, is the dividing line.

Editing fidelity separates them hardest. SpeechEditBench content-editing accuracy is 91.83 for AuK against 87.50 for Flash — the largest single gap in the comparison. Acoustic editing is nearly as lopsided, 37.07 against 30.26. In the Ming-Freeform suite AuK reports lower WER almost everywhere that matters: 3.09 against 3.34 on full Chinese editing, and a much wider 3.96 against 4.84 on full English editing. If your product rewrites the words in someone's recording — lyric edits, content replacement, insertion and deletion — the 32-step model is the one that keeps the transcript honest, and the 8× step difference is worth paying for.

Both models are also, by the report's own numbers, still weak at emotional editing: SpeechEditBench emotion accuracy is 9.94 for AuK and 6.29 for Flash. That is not a distillation artifact. It is a task family nobody has solved, and picking the student will not make you worse at it than you already are.

The 4.5× is a sampler number, not an end-to-end number

Here is the arithmetic the headline speedup hides, and it is the single most useful thing to understand before you commit an architecture to Flash.

AuK-Flash runs 4 sampling steps where AuK runs 32. That is 8× fewer steps. The vendor reports 4.5× faster wall clock. The difference between those two figures is everything around the sampling loop, and it is dominated by the encoder: a Qwen2.5-Omni-3B multimodal model that both checkpoints load and both must run on every request. That encoder is roughly twice the size of the diffusion backbone, and its cost is fixed. Flash cannot speed it up, because Flash is not part of it.

So the honest version of the claim is this: 4.5× is what you get on the diffusion portion under matched conditions, and your end-to-end gain will be whatever share of your wall clock the sampling loop actually occupies. If you are running long-form generation where 32 steps over many latent frames dominates, you will land near the published number. If your workload is short clips with heavy instruction preprocessing, or if you are batching small requests, a larger fraction of each call sits in the shared encoder and your real speedup will be materially smaller than 4.5×. Measure your own mix before you let a latency budget depend on it. Nobody has published that end-to-end number yet — including the vendor, who reports no absolute latency figures or VRAM requirements at all.

What the distillation costs, in the authors' own words

The technical report is unusually candid about where the student breaks, and those failure modes are more useful to a deployer than the benchmark table.

Teacher guidance targets turned out to be the problem. Using CFG targets in the consistency branch "can expose the few-step student to over-saturated predictions," which the authors say causes overshoot and audible clipping. Separately, a uniform Decoupled DMD schedule "degrades multi-speaker and vocal separation," with some student outputs regressing toward the unprocessed mixture — the distillation erases the separation the model was supposed to perform. Task-routed DMD is the described fix, and it is why the report is careful to scope that particular weakness to the uniform variant. If speech separation is a core part of your pipeline, this is the paragraph to test against before you trust it.

Two more constraints are operational rather than statistical. The pipeline's Prompt Enhancer maps colloquial wording about speed, loudness, and pitch onto a fixed set of supported values, and rejects anything it cannot map before acoustic inference runs — so unsupported requests fail early rather than degrade gracefully. And the repository only accepts Qwen/Qwen2.5-Omni-3B as the encoder path; the README states that Qwen3-Omni is not currently supported, so a newer encoder is not a drop-in upgrade. The ComfyUI integration carries a 30-second limit on source-plus-target sequences.

Running both is the intended configuration

The repository's own multi-GPU example puts AuK on one device and AuK-Flash on another — cuda:0 and cuda:1 — which is a fair signal that Tencent expects these to coexist rather than compete. It is also the right answer for most production speech stacks, because the two models are strong in disjoint places. Route editing-heavy and Chinese-language requests to AuK; route enhancement, separation, English instruction-following, and anything interactive to AuK-Flash. Both load the same encoder and the same VAE, so you pay for that shared runtime once and switch between checkpoints behind it.

That is a routing decision at the model layer, and it is the same shape as the one OrcaRouter applies at the API layer for hosted models. Where the two meet today is the seam in AuK's own pipeline: the Prompt Enhancer requires an OpenAI-compatible chat endpoint to turn a rough instruction into the model's supported vocabulary, and the optional ASR fallback needs a transcription path. Point either at an OpenAI-compatible chat endpoint and you get one key across 200-plus models, provider list price passed through with 0% markup, and automatic failover if a backend drops — which matters precisely because this is a two-day-old release with no hosted API and no independent reproduction, and you do not want an unproven dependency sitting on a hardcoded endpoint.

Be clear about what is not available, though. Neither AuK nor AuK-Flash is served by any hosted inference provider — the Hugging Face cards say so directly — and neither is routable through OrcaRouter today. This is a self-hosting decision end to end.

A decision card headed "Which AuK checkpoint should you run?" with two columns. Pick AuK: content and lyric editing, Chinese speech generation, edit and transcript fidelity, best raw WER 2.65. Pick AuK-Flash: enhancement and separation, voice conversion and dubbing, English instruction TTS, 8x fewer sampling steps. A bar beneath both reads "Same encoder, same VAE, same 6.122 GB - run both."

Cosa è ancora sconosciuto

Almost everything about this release is vendor-reported. The 4.5× speedup, the WER figures, the SpeechEditBench columns, and the UTMOS rows all come from the AuK team's own technical report, arXiv 2609.08936, submitted September 8 — there is no independent reproduction, no third-party leaderboard entry, and no neutral harness result. The adoption signal is equally thin: as of September 10 the two Hugging Face repositories show 30 downloads in the last month and roughly two dozen likes each, while the GitHub repository shows 217 stars, 12 forks, and three contributors. That is a research drop, not a bandwagon.

img src="4.png" alt="Screenshot of the Tencent-Hunyuan AuK GitHub repository README showing the September 9 2026 open-source notice and the AuK and AuK-Flash variant table"> p>The release itself was quiet in a way worth stating plainly, because it is easy to overread. There was no Hunyuan announcement, no blog post, no pricing page, and no launch event. The vendor's only dated statement is a single line in the repository README — [2026/09/09] We open-source AuK. The Hugging Face repository metadata shows the spaces were created earlier, in mid-August, and the weights were last touched on September 9 and 10, so the packing happened before the announcement did. What is knowable from the repo: MIT-licensed weights for both variants, a technical report, working download instructions for Hugging Face and ModelScope, and a documented task list. What is not confirmed: whether any of the reported numbers survive an independent harness, whether a hosted endpoint will appear, and whether the Flash checkpoint stays the recommended default once other people have run it.

Screenshot of the Tencent-Hunyuan/AuK repository on GitHub, captured September 10 2026, showing the README News entry dated 2026/09/09 reading "We open-source AuK. Code and model weights are publicly available.", the README headline "AuK: An Open-Source Foundational Model for Speech Generation and Editing", and repository counts of 217 stars, 12 forks and 3 contributors.

Quale scegliere?

If you are building content or lyric editing, or serving Chinese-language speech in any form, take AuK and accept the 32 steps. Its advantages there are large, consistent across two independent editing suites, and exactly the kind of correctness failure — a wrong word in the transcript — that users notice immediately.

If you are building enhancement, separation, voice conversion, or anything with a human waiting on the output, take AuK-Flash. It is faster by a wide margin on the sampling loop, it wins the perceptual-quality rows outright, and it preserves speaker identity better than the model it was distilled from. The quality gap that does exist is concentrated in tasks you are probably not running.

If you are building a speech product that spans both, run both. Same disk, same encoder, same licence, one config difference — and the deployment pattern the repository already demonstrates. The one thing worth waiting on is your own end-to-end latency measurement: the 4.5× is real, but it belongs to the sampler, and only your workload mix tells you how much of it reaches your users.