AuK vs AuK-Flash：32步采样还是4步，以及学生为何有时会胜出

两个检查点的体积都恰好是 6.122 GB。两者均以 MIT 许可证发布。两者都由同一个单独下载的 30 亿参数指令编码器和同一个 637 MB 的 VAE 驱动。AuK与AuK-Flash在你配置的几乎所有方面都毫无差别——除了一件你在每次调用时都能切身感受到的事：采样器运行的次数。AuK 是腾讯混元团队与上海交通大学、南洋理工大学的学术合著者于 9 月 9 日发布在 Hugging Face 上的 1.5B 开放权重语音生成与编辑基础模型，它以 2.0 的无分类器引导进行 32 次函数评估。AuK-Flash 是蒸馏学生模型，只进行 4 次评估，并且完全关闭引导，据称可获得 4.5× 的墙钟时间加速。显而易见的解读是，Flash 是你在延迟优先于质量时选择的经济座位。但这种解读是错的，而推翻它的正是厂商自己的评估表：在技术报告的逐项对比中，Flash 在 MMAE-Speech 的编辑比率指标、SpeechEditBench 的副语言列、英语指令跟随、声学编辑的说话人相似度，以及全部四项增强感知质量行上都取得了最高分。它不是降级，而是一种不同的取舍；你想要哪一边，取决于你实际运行的是这两类任务中的哪一类。

它们之间到底有什么区别？

抛开营销说辞，选择就归结为一个配置文件。AuK 的运行时是混合整流流 Transformer——双流 MMDiT 模块馈入统一单流 DiT 模块——以 bfloat16 欧拉求解器在 24 kHz 下运行，64 维潜变量在 50 Hz 下处理。AuK-Flash 运行完全相同的架构，只是附加了一个蒸馏采样器，该采样器由一致性初始化和任务路由的解耦 DMD 生成。其余所有组件均共享。

• 采样步数 — AuK：32 次函数评估，可配置。AuK-Flash：4 次，固定。

• 无分类器引导 — AuK：scale 2.0，可调。AuK-Flash：无（CFG=0）。

• 检查点大小 — AuK：auk_base.safetensors，6.122 GB。AuK-Flash：auk_flash.safetensors，6.122 GB。精确到兆字节完全相同。

• 共享运行时 — 一个 637 MB 的 VAE 加上 Qwen/Qwen2.5-Omni-3B 编码器，分别下载，两者共用。

• 宣称速度——AuK-Flash 在硬件、时长和批次大小均匹配时，比 32-NFE 教师模型快 4.5 倍。

• 许可证——两者均采用 MIT 许可，这一次总算名副其实。

检查点大小完全相同，这一细节重新定义了整个比较。蒸馏变体通常通过更小的体积来换取速度。AuK-Flash 并非更小。你不会节省磁盘空间，不会节省传输时间，而且——由于编码器和 VAE 是共享的，DiT 的宽度也相同——选择学生模型并不会显著节省显存。Flash 唯一返还给你的资源是时间。不过仍需提一个预算陷阱：模型名称中的“1.5B”描述的是扩散主干，而磁盘上的文件大小为 6.122 GB。请按该文件大小进行预留。

AuK-Flash 真正胜过完整模型的地方

这就是“蒸馏=更差”这种直觉出错的地方，而且这一点在报告表格中的多个互不相关的任务族里都成立。先从感知说起。在DNS Challenge增强集上，Flash的UTMOS为4.05，AuK为3.86；在CHiME-4上为3.91对3.72；在Libri2Mix上为4.03对3.87；在VCTKSR上为4.05对3.93。Flash还在其中四个集合的两个集合上的识别错误列中胜出：CHiME-4的WER为7.84对7.98，VCTKSR的WER为2.92对3.06。人工评分的自然度是学生模型持续领先的唯一维度，报告也明确指出了这一点：完整模型提供了更强的语言准确性和编辑保真度，而Flash“往往提供更好的感知质量”。

这些优势并不仅限于增强任务。在MMAE-Speech的编辑比率指标上——即编辑是否落在预期幅度上——Flash得分为13.85，AuK为12.44。在SpeechEditBench的副语言列上，分数为39.25对38.50。在InstructTTSEval的英文描述转语音任务上，得分为82.40对81.60，与该行最佳基线持平。在Ming-Freeform套件的声学编辑任务中，它的说话人相似度在该系列中最高，中文为0.79、英文为0.75，而基础模型分别为0.78和0.74。换句话说，保留说话人身份正是四步法带来的好处之一——报告自身的总结是，完整模型的平均识别错误率更低，而Flash能更好地保留说话人身份。如果你在做语音转换、配音或增强类工作，且音色比词错误率更重要，那么学生模型是更好的选择。

那32级台阶仍然物有所值

基础模型的优势恰恰集中在你会从采样预算更多的扩散模型中预期到的地方：任何输出必须在语言上正确的内容。

在Seed-TTS-Eval上，AuK的平均WER为2.65，而Flash为2.85，说话人相似度为0.795对0.790。该平均值内部的离散程度比平均值本身更具信息量。两者在英文测试集上几乎持平——1.02和1.03——而在中文上则有差距，1.02对1.10；在困难中文子集上再次拉开，5.91对6.43。中文正是额外步骤发挥作用的地方。

同样的模式也出现在指令跟随中。在InstructTTSEval的中文描述到语音任务上，差距很明显：AuK为83.37，而Flash为78.80，报告指出基础模型在该套件的全部三项中文指标上领先，而Flash的“主要优势在于其更强的英文DSD结果。”划分界限的是语言，而非架构。

编辑保真度最能区分两者。在 SpeechEditBench 上，AuK 的内容编辑准确率为 91.83，而 Flash 为 87.50——这是对比中最大的单项差距。声学编辑的差距也几乎一样悬殊：37.07 对 30.26。在 Ming-Freeform 套件中，AuK 在几乎所有关键指标上都报告了更低的 WER：全文中文编辑为 3.09 对 3.34，全文英文编辑差距更大，为 3.96 对 4.84。如果你的产品需要改写录音中的文字——歌词编辑、内容替换、插入和删除——32 步模型才是让转录文本保持准确的之选，8 倍的步数差异值得为此买单。

根据报告自己的数据，两个模型在情感编辑方面仍然薄弱：SpeechEditBench 的情感准确率，AuK 为 9.94，Flash 为 6.29。这并非蒸馏产物。这是一个尚未有人解决的任务族，选择学生模型不会让你在这项任务上比你本来的水平更差。

4.5× 是一个采样数值，不是端到端数值。

这就是标题中的加速数字所掩盖的算术，也是你在将架构投入 Flash 之前需要理解的最有用的一点。

AuK-Flash 运行 4 个采样步骤，而 AuK 运行 32 个。也就是说，步骤数量只有原来的 1/8。厂商报告的挂钟时间则快了 4.5 倍。这两个数字之间的差异来自采样循环周围的一切，而占主导地位的是编码器：一个 Qwen2.5-Omni-3B 多模态模型，两个检查点都会加载它，并且每个请求都必须运行它。该编码器的规模大约是扩散主干的 2 倍，其成本是固定的。Flash 无法加速它，因为 Flash 并不是它的一部分。

所以，这个说法的诚实版本是这样的：在匹配条件下，4.5× 只是扩散部分的加速，而你的端到端收益取决于采样循环实际占用你多少墙钟时间。如果你运行的是长序列生成，对大量潜在帧进行 32 步计算占主导，那么你会接近已公布的数字。如果你的工作负载是带有繁重指令预处理的短视频片段，或者你在批量处理小请求，那么每次调用中有更大比例的时间花在共享编码器上，你实际获得的加速将明显小于 4.5×。在让延迟预算依赖这个数字之前，先衡量你自己的实际负载组合。目前还没有人公布端到端的数字——包括供应商在内，他们根本没有报告任何绝对延迟数据或 VRAM 需求。

蒸馏的代价，用作者自己的话说

技术报告异常坦诚地说明了学生模型在何处失效，而这些失效模式对部署者来说比基准测试表更有用。

问题最终出在教师指导目标上。在一致性分支中使用 CFG 目标“会让少步学生模型接触到过度饱和的预测”，作者称这会导致过冲和可闻的削波。另外，统一的解耦 DMD 调度“会降低多说话人和人声分离的质量”，部分学生输出会向未处理的混合音频退化——蒸馏抹除了模型本应执行的分离。任务路由式 DMD 是文中描述的修复方案，这也是报告特意将该弱点限定在统一变体上的原因。如果语音分离是你处理流程中的核心部分，那么在你信任它之前，这段就是需要对照测试的段落。

还有两个约束属于操作层面，而非统计层面。该流水线的 Prompt Enhancer 将关于速度、响度和音高的口语化措辞映射到一组固定的受支持值上，并在声学推理运行之前拒绝任何无法映射的内容——因此，不支持的请求会提前失败，而不是优雅降级。此外，该仓库只接受 Qwen/Qwen2.5-Omni-3B 作为编码器路径；README 中指出目前不支持 Qwen3-Omni，因此更新的编码器并不是一种可直接替换的升级。ComfyUI 集成对源序列与目标序列的总时长有 30 秒的限制。

同时运行两者是预期的配置。

该仓库自带的多GPU示例将AuK放在一个设备上，将AuK-Flash放在另一个设备上——cuda:0和cuda:1——这清楚地表明腾讯希望这两者共存而非竞争。对于大多数生产级语音栈来说，这也是正确的答案，因为这两个模型在互不重叠的领域各有优势。将编辑密集型和中文本地化请求路由到AuK；将增强、分离、英文指令跟随以及任何交互式任务路由到AuK-Flash。两者加载相同的编码器和相同的VAE，因此您只需为这份共享运行时支付一次费用，即可在其后切换检查点。

那是一个模型层的路由决策，与 OrcaRouter 在 API 层对托管模型应用的路由决策形态相同。两者今天交汇的地方正是 AuK 自身流水线中的接缝：Prompt Enhancer 需要一个兼容 OpenAI 的聊天端点来将粗略指令转换为模型支持的词汇表，而可选的 ASR 回退则需要一条转录路径。将任一者指向兼容 OpenAI 的聊天端点，即可用一个密钥访问 200 多个模型，按提供商列表价传递且零加价，并在后端宕机时自动故障转移——这之所以重要，恰恰是因为这是一个发布仅两天的版本，没有托管 API，也没有独立复现，你不会想让一个未经验证的依赖挂在硬编码端点上。

不过，要把不可用之处说清楚。AuK 和 AuK-Flash 目前都不由任何托管推理提供商提供服务——Hugging Face 的模型卡上直接写明——二者目前也都无法通过 OrcaRouter 路由。这从头到尾都是一个自托管决策。

仍然未知的是什么

关于这次发布的几乎所有内容都是供应商自行报告的。4.5倍的加速、WER数据、SpeechEditBench各列以及UTMOS各行，全部来自AuK团队自己的技术报告（arXiv 2609.08936，提交于9月8日）——没有独立的复现、没有第三方排行榜条目、也没有中性基准测试结果。采用信号同样薄弱：截至9月10日，两个Hugging Face仓库在过去一个月内只有30次下载，且各约二十余个点赞；而GitHub仓库显示217颗星、12个fork和3位贡献者。这更像是一次研究发布，而不是什么大势所趋。

img src="4.png" alt="腾讯混元 AuK GitHub 仓库 README 的截图，显示 2026 年 9 月 9 日开源公告以及 AuK 和 AuK-Flash 变体表格"> p>这次发布本身很低调，这一点值得明说，因为这类事件很容易被过度解读。没有混元公告，没有博客文章，没有定价页面，也没有发布会。该厂商唯一带日期的声明是仓库 README 中的一行——[2026/09/09] 我们开源了 AuK。Hugging Face 仓库的元数据显示，这些空间创建得更早，在八月中旬，权重最后修改时间为 9 月 9 日和 10 日，因此打包发生在公告之前。从仓库可知：两个变体的 MIT 许可权重、一份技术报告、适用于 Hugging Face 和 ModelScope 的有效下载说明，以及一份记录在案的任务列表。尚未确认的是：所报告的数字能否经得起独立测试框架的检验、是否会出现托管端点，以及一旦其他人运行过后，Flash 检查点是否仍然是推荐的默认选项。

该选哪一个

如果你正在构建内容或歌词编辑，或以任何形式提供中文语音服务，请采用 AuK 并接受这 32 个步骤。它在那里的优势很大，在两个独立编辑套件中表现一致，而且恰恰是那种正确性失败——转录稿中的一个错词——用户会立即注意到。

如果你正在构建增强、分离、语音转换，或任何需要人类等待输出的应用，请选择 AuK-Flash。它在采样循环上速度遥遥领先，在感知质量指标上完胜，并且比它所蒸馏自的模型更好地保留说话人身份。确实存在的质量差距集中在那些你很可能不会运行的任务上。

如果你正在构建一个横跨两者的语音产品，那就两者都跑。相同的磁盘、相同的编码器、相同的许可证，只有一个配置差异——以及仓库已经展示过的部署模式。唯一值得等待的是你自己对端到端延迟的测量：这4.5倍是真实的，但它属于采样器，只有你的工作负载组合才能告诉你其中有多少会到达你的用户。