AuK vs AuK-Flash: 32サンプリングステップか4か、そしてなぜ生徒が時々勝つのか

どちらのチェックポイントも、サイズは正確に6.122 GBです。どちらもMITライセンスで配布されています。どちらも、別途ダウンロードされる同じ30億パラメータの命令エンコーダーと、同じ637 MBのVAEによって駆動されます。AuKとAuK-Flashは、プロビジョニングするほとんどすべての点で違いませんが、呼び出しのたびに感じる点が1つあります。それはサンプラーが実行される回数です。AuKは、TencentのHunyuanチームと上海交通大学およびNTUの学術共著者らが9月9日にHugging Faceに公開した、15億パラメータのオープンウェイト音声生成・編集基盤モデルで、classifier-free guidance 2.0で32回の関数評価を行います。AuK-Flashは、蒸留された生徒モデルであり、ガイダンスを完全にオフにして4回の関数評価を行い、主張されている4.5倍のウォールクロック高速化を実現します。当然の解釈は、Flashはレイテンシが品質よりも優先される場合に選ぶ格安の選択肢であるというものです。しかし、その解釈は誤りです。それを否定しているのは、ベンダー自身の評価表です。テクニカルレポートの直接比較の行では、FlashはMMAE-Speechの編集率指標、SpeechEditBenchのパラ言語的な列、英語の指示追従、音響編集における話者類似性、そして音声強調の知覚品質に関する4つの行すべてにおいて最高スコアを獲得しています。これはダウングレードではありません。これは異なるトレードオフであり、どちらの側を選ぶかは、実際に実行している2つのタスクのどちらかに依存します。

実際にそれらの間で何が違うのか

マーケティングを剥がせば、選択は設定ファイルの問題に帰着する。AuKのランタイムは、ハイブリッド型整流フローTransformerである——デュアルストリームのMMDiTブロックが統合型シングルストリームDiTブロックへ供給する構成——24kHzでbfloat16オイラーソルバーを実行し、50Hzで64次元の潜在変数を処理する。AuK-Flashは、蒸留サンプラーを追加した同一アーキテクチャを実行し、これは整合性初期化とタスクルーティング型Decoupled DMDによって生成される。その他のすべてのコンポーネントは共通である。

• サンプリングステップ — AuK: 32回の関数評価、設定可能。AuK-Flash: 4回、固定。

• 分類器フリーガイダンス — AuK: スケール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の幅も同じため、学生モデルを選んでもVRAMを実質節約できない。Flashが返してくれる唯一のリソースは時間だけだ。それでも、予算の落とし穴を一つ挙げておく価値はある。モデル名の「1.5B」は拡散バックボーンを指し、ディスク上のファイルは6.122GBある。そのファイルに備えよう。

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はまた、これら4つのセットのうち2つで認識エラー列でも勝利しており、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です。言い換えれば、話者同一性の保持こそが、4ステップで得られるものの一つです——レポート自身の要約によれば、完全版モデルは平均認識エラーが低く、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である。レポートは、そのスイートの3つの中国語指標すべてでベースモデルがリードしている一方、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ステップ実行します。つまり、ステップ数は8分の1です。ベンダーは、ウォールクロック時間で4.5倍高速であると報告しています。この2つの数値の差は、サンプリングループの周囲のすべての処理に相当し、その大部分はエンコーダによるものです。エンコーダとはQwen2.5-Omni-3Bマルチモーダルモデルであり、両方のチェックポイントがロードし、すべてのリクエストで必ず実行しなければならないものです。そのエンコーダは拡散バックボーンの約2倍のサイズで、コストは固定です。Flashはそれを高速化できません。Flashはその一部ではないからです。

つまり、この主張を正直に言い換えるとこうなります：4.5倍というのは、条件を揃えた場合の拡散部分で得られる数値であり、エンドツーエンドの高速化率は、サンプリングループがウォールクロックのどの程度の割合を占めるかによって決まります。多数の潜在フレームにわたる32ステップが支配的な長尺生成を実行しているなら、公表されている数値に近い結果になるでしょう。一方、命令の前処理が重い短いクリップがワークロードの場合や、小さなリクエストをバッチ処理している場合は、各呼び出しのより大きな割合が共有エンコーダに費やされるため、実際の高速化率は4.5倍よりも大幅に小さくなります。レイテンシ予算をそれに依存させる前に、自分のワークロード構成を測定してください。そのエンドツーエンドの数値を公表した人はまだ誰もいません — ベンダーも含めてです。ベンダーは絶対的なレイテンシ数値やVRAM要件を一切報告していません。

蒸留のコストを、著者自身の言葉で

技術報告書は、学生がどこでつまずくかについて異例なほど率直であり、その失敗モードはベンチマーク表よりもデプロイ担当者にとって有用である。

教師ガイダンスのターゲットが問題であることが判明した。一貫性ブランチでCFGターゲットを使用すると、「数ステップの学生モデルが過飽和な予測にさらされる可能性があり」、著者らによれば、これがオーバーシュートと耳に聞こえるクリッピングを引き起こすという。別途、均一なDecoupled DMDスケジュールは「マルチスピーカーおよびボーカルの分離を劣化させ」、一部の学生出力は未処理のミクスチャに向かって退行する — 蒸留によって、モデルが実行するはずだった分離が消し去られる。タスクルーティングDMDが説明された修正策であり、レポートがその特定の弱点を均一なバリアントに限定しているのはそのためである。音声分離がパイプラインの中核部分であるなら、これを信頼する前にテストすべき段落はこれである。

さらに2つの制約は、統計的なものではなく運用上のものです。パイプラインのPrompt Enhancerは、速度、音量、ピッチに関する口語的な表現を、サポートされている固定の値セットにマッピングし、音響推論が実行される前にマッピングできないものを拒否します。したがって、サポートされていないリクエストは、グレースフルに劣化するのではなく、早期に失敗します。また、リポジトリはエンコーダーパスとしてQwen/Qwen2.5-Omni-3Bのみを受け入れます。READMEにはQwen3-Omniは現在サポートされていないと記載されているため、新しいエンコーダーはドロップインアップグレードではありません。ComfyUI統合には、ソースとターゲットのシーケンスに対して30秒の制限があります。

両方を実行することが意図された構成です。

このリポジトリ自身のマルチGPUサンプルは、AuKを一方のデバイスに、AuK-Flashを別のデバイスに配置しています — {{1}}cuda:0とcuda:1{{/1}} — これは、Tencentがこれらを競合させるのではなく共存させることを想定している、明確なシグナルです。これはまた、ほとんどの本番向け音声スタックにとっての正解でもあります。{{2}}この2つのモデルは得意分野が重ならない{{/2}}からです。{{3}}編集中心のリクエストと中国語のリクエストはAuKに振り分け、拡張処理・分離処理・英語の指示追従・インタラクティブな処理はすべてAuK-Flashに振り分けます。{{/3}}どちらのモデルも{{4}}同じエンコーダーと同一のVAE{{/4}}を読み込むため、この共有ランタイムのコストを一度支払うだけで、その背後のチェックポイントを切り替えられるのです。

それはモデル層でのルーティング判断であり、OrcaRouterがホスト型モデルに対してAPI層で適用するものと同じ形です。両者が現在交わるのは、AuK自身のパイプラインの継ぎ目です。プロンプトエンハンサーは、大まかな指示をモデルの対応語彙に変換するためにOpenAI互換のチャットエンドポイントを必要とし、オプションのASRフォールバックには文字起こし経路が必要です。どちらをOpenAI互換のチャットエンドポイントに向けても、200以上のモデルで1つのキーを利用でき、プロバイダーのリスト価格が0%マークアップでそのまま適用され、バックエンドが落ちた場合の自動フェイルオーバーも得られます。これは、公開からまだ2日しか経っていないリリースであり、ホスト型APIも独立した再現も存在しないからこそ重要です。未実証の依存関係をハードコードされたエンドポイントに固定したままにしておくのは避けたいものです。

ただし、利用できないものを明確にしておく必要があります。AuKもAuK-Flashも、ホスト型推論プロバイダーでは提供されておらず、Hugging Faceのカードにもその旨が直接記載されています。また、現在どちらもOrcaRouter経由ではルーティングできません。これは、エンドツーエンドでのセルフホスティング判断です。

まだ未知のこと

このリリースに関するほぼすべてがベンダー報告によるものです。4.5倍の高速化、WERの数値、SpeechEditBenchの各列、UTMOSの各項目はすべて、AuKチーム自身のテクニカルレポート（arXiv 2609.08936、9月8日提出）に由来しています。独立した再現実験も、第三者によるリーダーボードへの登録も、中立なハーネスでの検証結果もありません。採用シグナルも同様に乏しく、9月10日時点で2つのHugging Faceリポジトリは直近1か月で30ダウンロード、それぞれ約2ダースのいいねを記録している一方、GitHubリポジトリは217スター、12フォーク、3人のコントリビューターです。これは研究発表であって、流行に乗ったものではありません。

img src="4.png" alt="Tencent-Hunyuan AuK GitHub リポジトリのREADMEのスクリーンショット。2026年9月9日のオープンソース化のお知らせと、AuKおよびAuK-Flashのバリアント表を示しています"> p>このリリース自体は、過剰に解釈されがちなだけに、率直に述べる価値のある静かなリリースだった。Hunyuanからのアナウンスも、ブログ記事も、料金ページも、ローンチイベントもなかった。ベンダーの日付入りの声明は、リポジトリのREADMEに書かれた1行だけだ——[2026/09/09] AuKをオープンソース化します。Hugging Faceリポジトリのメタデータによると、スペースはそれより前の8月中旬に作成され、ウェイトが最後に更新されたのは9月9日と10日だった。つまり、パッケージングはアナウンスより前に行われていた。リポジトリから確認できるのは、両バリアントのMITライセンスのウェイト、技術レポート、Hugging FaceとModelScopeで動作するダウンロード手順、そして文書化されたタスクリストだ。確認されていないのは、報告された数値のいずれかが独立したハーネスで再現できるかどうか、ホステッドエンドポイントが登場するかどうか、そして他の人が実行した後もFlashチェックポイントが推奨デフォルトのままかどうかだ。

どちらを選ぶべきですか

コンテンツや歌詞の編集を構築している場合、または何らかの形で中国語の音声を扱う場合は、AuKを採用し、32のステップを受け入れてください。そこでの利点は大きく、2つの独立した編集スイートにわたって一貫しており、まさにユーザーがすぐに気づく種類の正確性の失敗——文字起こしの単語の誤り——です。

エンハンスメント、分離、音声変換、または出力を人間が待つような何かを構築しているなら、AuK-Flash を採用してください。サンプリングループでは圧倒的に速く、知覚品質の指標でも文句なしに勝っており、蒸留元のモデルよりも話者同一性をよく保ちます。実際に存在する品質の差は、おそらく実行していないタスクに集中しています。

両方にまたがる音声製品を構築しているなら、両方を実行してください。同じディスク、同じエンコーダー、同じライセンス、設定の違いは1つだけ——そしてリポジトリが既に示しているデプロイパターンも同じです。待つ価値があるのは、ご自身のエンドツーエンドのレイテンシー測定だけです。4.5倍は現実ですが、それはサンプラーに起因するものであり、どれだけそれがユーザーに届くかは、あなたのワークロード構成だけが教えてくれます。