Inside Inkling: Audio Design

Thinking Machines Lab が初のオープンウェイトモデル Inkling を公開しました。総パラメータ 975B（有効 41B）の Mixture-of-Experts Transformer で、最大 100 万トークンの文脈を扱い、重みは Apache-2.0。テキスト・画像・音声・動画からなる 45 兆トークンでゼロから事前学習されています。小型版の Inkling-Small（有効 12B）のプレビューも同時公開されました。著者らは、これが最強のモデルではないと率直に述べています。広くカスタマイズ可能な基盤として、そして音声と視覚でリアルタイムに対話する interaction models の背後で推論を担うモデルとして作られたものです。そう読むと、興味深い問いは「SOTA か」ではなく、「どこに容量を割き、どこに割かないと決めたか」になります。

音声はその最も鋭い答えであり、音声研究者としての私が一番気になる部分でもあります。Inkling には音声エンコーダがありません。音は離散化して埋め込むフロントエンドによって毎秒およそ20トークンになり、あとはテキストを読むのと同じデコーダがすべての「聴く」仕事をします。本稿はこの判断を3部構成で追います。音声をどうモデル化するか、それが実際どれだけ機能するか、そしてその結果生じるインターリーブ推論をどう配信するか。voice agent や omni モデルを作る人なら、各部に持ち帰れるアイデアが1つずつあるはずです。

本稿の内容はすべて一次情報に基づきます。アーキテクチャとベンチマークは Thinking Machines のモデル記事とモデルカード、配信は LMSYS Org の SGLang & Thinking Machines 解説、音声レートは SGLang PR #31358、ファインチューニングの数値は Tinker cookbook の音声レシピです。図は出典をその場で明記します。

Part 1 · モデル化特徴量ではなくトークンとしての音声

言語モデルに耳を与える普通のやり方は、音声エンコーダを後付けすることです。波形を畳み込みと Transformer ブロックの積み重ね（数千万から数億パラメータ）に通し、得られた特徴を言語モデルの埋め込み空間へ射影します。Inkling はこれを全部やめました。モデル記事は、マルチモーダル入力がエンコーダフリーだと明言しています。音声は dMel スペクトログラム（Bai et al., 2024）として入力され、「軽量な埋め込み層を介して変換され、テキストトークンと一緒に処理される」。要するに、音声はテキストと同じようにトークン化されます。

以下がパイプライン全体です。一歩ずつ追ってみてください。この設計の眼目は、これ以上重い処理が何も起きないことです。

具体的には、16 kHz モノラル音声が、ホップ 800 サンプル（50 ms）・窓 1600 サンプル（100 ms）の 80 チャネル log-mel スペクトログラムになります。1 フレーム内の 80 個のメルエネルギーはそれぞれ 16 段階に量子化されます。これが dMel の「d」です。音声「エンコーダ」の全体は、たった1枚の埋め込み層です。

nn.Embedding(n_mel_bins × mel_vocab_size = 80 × 16 = 1280 → 6144)

各（ビン, レベル）ペアがテーブルの1行を所有します。フレームの 80 本の行は1本の 6144 次元ベクトルに総和され（任意で RMSNorm）、そのベクトルが音声トークンです。パラメータコストは 1,280 × 6,144 ≈ 790 万。典型的な音声エンコーダのチェックポイントより2桁小さい規模です。

なぜこれが妥当な賭けなのか

80 個のルックアップを総和するだけで、なぜ機能するのでしょうか。観察を3つ挙げます。

• ビンの識別はテーブルが担い、位置は担わない。 各メルビンは自分専用の 16 行のブロックを持つため、どのビン由来のレベルかは埋め込み自体に焼き込まれています。総和はビン・レベルごとのベクトルの学習された線形結合、つまり 1280 個の原子からなる固定語彙の bag-of-bins です。フレーム内の位置管理は不要です。
• 離散化は音声をテキストのように見せる。 連続特徴ベクトルをテキスト埋め込みと並べるには、射影と入念な正規化が要ります。ビンあたり 16 段階なら、各ビンはサブワードと同じように埋め込める離散シンボルになります。トークナイザは「理解」を一切しません。テキストのトークナイザと同じです。
• 知覚は共有デコーダに押し込まれる。 975B の MoE ならスペクトログラムを意味に変えるのは十分可能で、専用の知覚タワーは冗長な容量だ、という賭けです。視覚は 40×40 パッチ上の 4 層 hMLP で同じ賭けをし、音声はさらに推し進めて実質ゼロ層にしています。

レート自体は1つの定数から導かれます。配信コードで InklingAudioEncoderParams が audio_token_duration_s = 0.05 と window_size_multiplier = 2.0 を設定し、ここから hop = 0.05 × 16000 = 800、window = 1600、そしてフレームのスタッキングもプーリングもなく 16000 / 800 = 20 フレーム（トークン）/秒になります。公開された config が示すのは audio_mode: "dmel"、n_mel_bins: 80、mel_vocab_size: 16、そして量子化のクランプ範囲（dmel_min_value: −7.0、dmel_max_value: 2.0）です。レートはコードにあります。

レートが固定で低いため、文脈予算の見積もりは自明です。モデルカードは 16 kHz の WAV を求め、クリップは 20 分以内を推奨しています。これは学習分布の話であって、文脈長の上限ではありません。24k トークンは 100 万に対して丸め誤差です。

Part 2 · 性能ルックアップテーブルは音声品質を犠牲にするのか

エンコーダを捨て、メルビンを 16 段階に量子化することへの当然の懸念は、忠実度を失うのではないか、というものです。証拠を見る限り、ほとんど失っていません。モデル記事自身の評価テーブルから音声の部分を引きます（thinking effort 0.99、比較対象は各種 omni モデル）。

数値はモデル記事より（effort 0.99）。太字は行ごとのオープンウェイト最高値。出典の脚注を2つ添えます。AudioMC の他モデルのスコアは公式リーダーボードに無いため Inkling チームが内部評価したもの。VoiceBench はハードコードされた文字列一致で採点するため、期待される回答形式に従うようシステムメッセージを追加して評価。Kimi K2.5 / K2.6 は音声の数値を報告していません。

率直に読むと: Inkling は AudioMC でオープンウェイト勢を大差でリードし、VoiceBench では Qwen3.5 Omni-Plus に1ポイント差まで迫り、MMAU では同モデルに劣ります。クローズドの Gemini 3.1 Pro は3つとも首位です。毎秒 20 回の埋め込みルックアップで聴く初回リリースとして、「最も強いオープンウェイト音声モデルの一つ」はマーケティングではなく、テーブルがそのまま示す事実です。

リーダーボードよりも私が有用だと思うのは、再現可能な下流の結果です。Tinker cookbook には 3 つの音声ファインチューニングレシピがあり、その報告値はエンコーダフリー表現が何を運べるかを素直に示します。

いくつか引き出しておきます。

• クリーンな音声はゼロショットで既に解けている。 LibriSpeech WER ~0.06 が素の状態で出るということは、dMel フロントエンドが正確な書き起こしに十分な信号を保っているということです。レシピの著者らは、ベースモデルが既に上手すぎて LibriSpeech では GRPO のグループがほぼ定数報酬になると述べています。嬉しい悩みです。
• LoRA で速く適応する。 医療の口述（薬品名が密なインド訛りの英語）は、単一の SFT で WER をほぼ半減（0.157 から 0.072）し、医療エンティティの再現率を「5 個に 1 個を落とす」から「11 個に 1 個未満」へ引き上げ（0.806 から 0.915）、エンティティの文字誤り率も 0.102 から 0.037 へ下げます。学習 split に無い oxcarbazepine や somatropin のような薬品も書き起こします。暗記ではなく、汎化した書き起こしです。
• パラ言語情報が離散化を生き延びる。 ここは私なら逆に賭けたところです。ビンあたり 16 段階は韻律には粗く思えます。しかし Expresso レシピは話し方スタイルを 0.852 の精度（マクロ F1 0.861）で分類します（ベースは 0.361）。SFT 単体で 0.757 に達し、報酬 \( 0.5\cdot\mathbb{1}[\text{style}] + 0.5\cdot\max(0, 1-\text{WER}) \) の GRPO が残りを積み増し、しかも WER は 0.044 へ改善します。表現は「何を」言ったかと「どう」言ったかの両方を運びます。16 段階で十分なようです。

率直な注意。 これらのレシピは小規模（数百から数千クリップ）で、SOTA を狙うものではなくパイプラインの実演が目的です。Expresso の著者はハイパーパラメータを調整していないと述べています。存在証明として読んでください。エンコーダフリーの dMel 表現はクリーン音声でゼロショットに正確で、安価に適応でき、パラ言語的な詳細を保持します。

Part 3 · 推論インターリーブされた音声の配信と、そのために要したカーネル

Inkling のデコーダは標準レシピから 3 つ逸脱しています。そのどれもが標準的なデコーダ専用サーバの前提を壊すため、day-0 サポート（RadixArk と共に SGLang・Miles 上で構築）には専用カーネルが必要でした。

• 短い畳み込み。 幅 \(W=4\) のチャネルごとの因果畳み込みを 2 箇所に適用します。K/V 射影の後と、注意・MLP の残差ブランチ出力です: \( y_{t,c} = x_{t,c} + \sum_{d=0}^{W-1} w_{c,d}\,x_{t-d,c} \)。安価な短距離混合ですが、通常の注意プロローグが想定しない層あたり 4 つの追加演算になります。
• RoPE ではなく相対位置。 logits に加える学習済み相対バイアス（Shaw et al., 2018; Huang et al., 2018）。著者らは長い系列へ RoPE より外挿すると報告しています。スライディングウィンドウ層と全域層は 5:1、KV ヘッドは 8 です。
• 共有エキスパート・シンク。 MoE は概ね DeepSeek-V3 に倣います（256 ルーテッド + 2 共有、top-6、補助損失なし負荷分散の sigmoid ルーター）。ひねりが1つ: 選ばれたルーテッドと共有のスコアを一緒に正規化します。\( (w_{\text{routed}}, w_{\text{shared}}) = \operatorname{normalize}(\log \sigma(s_{\text{routed}} \Vert s_{\text{shared}})) \)。共有エキスパートは常時オンの加算ではなく、確率質量を奪い合うのです。

音声が配信パスに触れる場所

配信時、1 つの音声アイテムは \(f\) 個の d-mel フレーム位置に展開される単一のセンチネルトークンです。dMel の特徴量化はレンダリング時の CPU 作業で、サーバは実現したフレーム数を応答ごとに meta_info["audio_tokens"] として返します。ここから 2 つの帰結が生じます。第一に、MoE のルーティングはこの展開後に記録されるため、Miles のロールアウト・ルーティングリプレイ（R3）はメディア展開後の系列上でエキスパート ID を索引します。毎秒 20 個の音声フレームが具体的なトークン位置として現れる場所です。第二に、ShortConv ブランチはリクエストごとに小さな畳み込み状態を保持するため、配信中のリクエストは3 種類の異種状態を管理することになります。全注意 KV、スライディングウィンドウ KV、ShortConv 畳み込み状態です。

この 3 状態の形こそが面白い配信上の問題です。SGLang は型付きコンポーネント（FULL, SWA, MAMBA。畳み込み状態は Mamba 系レイヤー向けのプールを再利用します。Inkling に SSM は無いにもかかわらず）を単一の UnifiedRadixCache で扱い、HiCache の階層化とプリフィル・デコード分離が 3 つすべてを転送します。MXFP8 KV は Blackwell 上でキャッシュ容量をほぼ倍増させます（量子化 ≈4.7 µs、デコードのペナルティ約 5%）。投機的デコードは完全に同期フリーなデコードラウンドで 8 層 MTP チェーンを単一 CUDA グラフに収め、加えて任意の DFlash ドラフトモデル（Modal チームと学習）を用います。

アーキテクチャ固有のカーネルにこそ、測定された効果があります。

B200 ノードで 8192 入力 / 1024 出力のエンドツーエンド:

同じアーキテクチャは Miles を通じて RL で学習されます。精度整合済みの ShortConv・相対注意・FP32-MoE カーネルとルーティングリプレイが学習と推論の一貫性を保ちます。アダプタのみを同期する LoRA は低ランク差分だけを CUDA IPC 経由で転送し、重み更新のレイテンシを 49.4 秒から 2.5 秒へ短縮します。これが Part 2 の速い音声ファインチューニングの背後にある仕組みです。

Codaまだ分かっていないこと

精読とは、埋まっていない箇所の棚卸しでもあります。曖昧に済ませず、検証できる形でここに記録しておきます。

• 「flow」音声モード。 配信 config は audio_mode を Literal["dmel", "flow"] と型付けしていますが、「flow」はどの文書にも登場しません。モデルカードはこのリリースの出力がテキストのみだと明記しているので、私の推測はコードベースに存在するが公開されていない音声出力パス（flow-matching デコーダやボコーダ）です。本当なら、Inkling はいずれ聴くだけでなく話せることになります。ただしこれは推測であり、本稿で最も価値の高い未解決の問いです。
• 量子化の正確な仕様。 log-mel 値が 16 段階へどう写像されるか（クランプ範囲上の一様？µ-law？学習？）は文書化されておらず、公開 config の dmel_min_value: −7.0 は配信コードのデフォルト −1.5 と食い違います。チェックポイント側が優先のはずですが、確認の価値があります。埋め込みテーブルの行の並びも、仕様から読んだのではなく慣習として仮定したものです。
• 適用範囲。 20 分の推奨を超える長尺音声、多言語・雑音下の音声、話者の重なり、ストリーミングの挙動はいずれも公開情報では未特性化です。45 兆トークン中の音声の割合も同様です。また、プロダクションの RL レシピは post-training 中、視覚・音声のフロントエンドを凍結したままにします。これらを学習させるのは実験的な扱いです。

一言でいう設計

Inkling は音声をテキストと同じように扱います。トークン化し、埋め込み、知覚は共有デコーダに任せる。dMel スペクトログラム、約790万パラメータのルックアップテーブル、毎秒20トークン、エンコーダなし。ベンチマークのテーブル、ゼロショットの WER、そして ASR・医療口述・感情タスクの適応の速さを見る限り、その代償はごくわずかです。通常はもっと高くつく能力に対して、ささやかな仕掛けです。

出典・参考文献

• Thinking Machines Lab Inkling モデル記事・モデルカード（重みは Hugging Face）: アーキテクチャ、モダリティ、音声ベンチマークのテーブル（AudioMC, MMAU, VoiceBench）。
• SGLang & Thinking Machines Lab「SGLang and Miles Add Day-0 Support for Inkling」LMSYS Org（2026）: 配信最適化と性能図。
• SGLang PR #31358: 音声 d-mel レート、特徴抽出器、センチネル展開。
• Tinker cookbook の音声レシピ（asr, medical_asr, emotion）: Part 2 のファインチューニング数値。
• R. He Bai ほか「dMel: Speech Tokenization Made Simple」2024: 離散メル方式。
• P. Shaw ほか「Self-Attention with Relative Position Representations」2018; C.-Z. A. Huang ほか「Music Transformer」2018。

音声モデル化の数値（20 トークン/秒、50ms ホップ、約 790 万パラメータの埋め込み）はリンク先の SGLang ソースから導出しました。ベンチマーク数値はモデル記事の評価テーブルから、下流の数値は Tinker cookbook のレシピ README から引用しています。埋め込まれた性能図は SGLang / Thinking Machines の著者らに帰属し、出典を明記して転載しています。インタラクティブなパイプライン図・インターリーブ推論図・共有シンク図はオリジナルです。本稿は Claude Code の助けを借りて起草し、掲載前にすべての主張を一次情報と照合しました。