世界を動かす技術を、日本語で。

Orthrus-Qwen3: Qwen3で最大7.8×トークン/フォワード、同一の出力分布

概要

  • Orthrusは 並列トークン生成損失なしの精度 を両立する新型LLMフレームワーク
  • Qwen3バックボーンを採用し、 最大7.8倍の生成高速化 を実現
  • 余分なメモリ消費ゼロ で既存モデルと同一の予測分布を保証
  • パラメータ効率を維持しつつ 推論速度と精度 を両立
  • 既存手法より 高い受理率・高速推論 を実現

Orthrus: メモリ効率型並列トークン生成フレームワーク

  • Orthrusは autoregressive LLMの忠実な生成diffusionモデルの高速並列生成 を統合したデュアルアーキテクチャ
  • Qwen3シリーズ をベースモデルとして利用し、 厳密な損失なし生成 を保証
  • サポートモデル例
    • Orthrus-Qwen3-1.7B(4.25倍高速化)
    • Orthrus-Qwen3-4B(5.20倍高速化)
    • Orthrus-Qwen3-8B(5.36倍高速化)
  • 公式実装・モデルチェックポイントは HuggingFace で配布

インストール手順

  • uv による高速依存解決を推奨
    • uv pip install -e .
    • uv pip install ninja packaging
    • uv pip install flash-attn --no-build-isolation(もしくはpip install "flash-attn-4[cu13]"

クイックスタート例

  • Pythonでの基本利用例
    • AutoModelForCausalLMAutoTokenizerを利用
    • attn_implementation="flash_attention_2"を指定(対応環境ならflash_attention_4も可)
    • use_diffusion_mode=Trueで並列生成を有効化
    • トークン生成ストリーミングもサポート

Orthrusの主な利点

  • 推論高速化 :従来の逐次デコードのボトルネックを解消し、最大7.8倍の速度向上
  • 厳密な損失なし生成 :モデル内で厳密な合意機構を持ち、ベースモデルと全く同一の分布で出力
  • 余分なメモリオーバーヘッドなし :デュアルビューが同一の高精度KVキャッシュを共有し、O(1)のメモリ増加のみ
  • パラメータ効率 :並列生成能力は全体の16%パラメータ微調整で注入、ベースLLMは完全凍結
  • Speculative Decodingとの比較 :EAGLE-3やDFlashに対して、KVキャッシュ共有により冗長メモリ回避・高受理率・高速推論を実現

SOTA拡散モデルとの比較

  • 従来のdiffusion LLM(dLLM)は 並列生成可能 だが、 条件ドリフトや精度劣化 が顕著
  • Orthrusは 並列生成と逐次制約を分離 し、 高忠実度・高精度 を両立
  • MATH-500ベンチマークで Qwen3-8B比約6倍高速化、Fast-dLLM-v2等の精度劣化なし

今後の展望

  • vLLMSGLang とのネイティブ統合を近日公開予定

論文引用情報

  • Orthrus関連研究を利用する場合は、以下の論文を引用

    @misc{vannguyen2026orthrusmemoryefficientparalleltoken,
      title={Orthrus: Memory-Efficient Parallel Token Generation via Dual-View Diffusion},
      author={Chien Van Nguyen and Chaitra Hegde and Van Cuong Pham and Ryan A. Rossi and Franck Dernoncourt and Thien Huu Nguyen},
      year={2026},
      eprint={2605.12825},
      archivePrefix={arXiv},
      primaryClass={cs.LG},
      url={https://arxiv.org/abs/2605.12825},
    }
    

Hackerたちの意見

論文: https://arxiv.org/abs/2605.12825 ; コードとモデル: https://github.com/chiennv2000/orthrus ; 開示: 共著者。アイデア: 固定されたARトランスフォーマーの各層に学習可能な拡散注意モジュールを組み込む。両方のヘッドは1つのKVキャッシュを共有。拡散ヘッドはK=32のトークンを並列で投影する。ARヘッドは2回目のパスで検証し、最も長い一致する接頭辞を受け入れる。出力分布は基本モデルと証明上同一。結果: - MATH-500で最大7.8倍のTPF、約6倍の実行時間。 - パラメータの16%を訓練、トークン数は1B未満、8xH200で24時間。 - 拡散LM(Dream、Fast-dLLM-v2、SDAR、Mercury、Gemini Diffusion)と比較すると、基本の重みを変更して精度を失う(Fast-dLLM-v2: MATH-500で-11ポイント)。Orthrusはバックボーンを固定しており、精度はQwen3-8Bと完全に一致。 - 投機的デコーディング(EAGLE-3、DFlash)と比較すると、外部ドラフターなし、別のキャッシュなし、TTFTペナルティゼロ(初期化/同期するドラフターなし)。KVオーバーヘッドはO(1)(約4.5 MiB)。MATH-500での受け入れ長さ: 11.7対7.9(DFlash)対3.5(EAGLE-3)。 - 単一ステップのデノイジングがマルチステップを上回る(6.35対3.53 TPF)。KL蒸留が受け入れ率でCEを上回る。制限: 固定された基本モデルによって厳密に制約されている(バイアス、幻覚、知識のギャップを引き継ぐ);Qwen3専用の評価;貪欲法+拒否サンプリングのみ。

すごい!これってQwen 3.6 27Bでもできるのかな?量子化にも対応するのかな?

つまり、D-Flashを各トランスフォーマー層に適用して、元のモデルのKVキャッシュを共有するってこと?めっちゃ賢い!

トレーニングコードを公開する予定はあるの?

すごく面白い研究だね!トレーニングデータの予算はモデルのサイズに応じてスケールするの?Gemma 4のドラフトモデルは、ベースのkvキャッシュと統合されてるけど、どう比較する?

ところで、論文にはこう書いてあるよね。「トレーニング中に更新されるのは(Qdiff,Kdiff,Vdiff)だけなので、トレーニング可能なパラメータの総数はフルモデルの約16%です。」でも、コードではq_proj_diff、k_proj_diff、v_proj_diff、o_proj_diffが定義されてて、O項を含めると16%にしかならないんだ。

制限についてだけど、これってもっとパラメータが多い大きなトランスフォーマーモデルにスケールすると思う?MOEモデルやスパースモデルだとどうなるんだろう?

このアイデアで一番面白いのは、今まで試されてなかったことだね。理にかなってると思う。論文は読んでないけど、もちろんDTreeのトリックもここで使えるよね。

これって計算量の削減につながるの?何か裏があるの?

これって計算量の削減につながるの? いいえ、実際にはその逆です。投機的デコーディングと同様に、このモデルはより多くのトークンを計算し、無効なものを捨てます。 > 何か裏があるの? LLMはメモリのレイテンシに制約されていて、計算には制約されていません。トークンを一つずつ処理するため、GPUレジスタからVRAMに重みをロードしたりアンロードしたりするのにかかる時間の方が、計算を待つ時間よりも長くなります。こういった技術は、トークンを一つずつ処理するのではなく、並列で複数のトークンを処理できるようにし、グラフィックカードの計算能力をより活用します。例えば、前のトークンが「こんにちは」の場合、通常の自己回帰型LLMは「こんにちは」=>「!」、次に「こんにちは!」=>「どう」...と一つずつ計算します。これだとGPUメモリから計算ユニットに重みを5回もロードしなきゃいけません。投機的デコーディング(これは厳密には投機的デコーディングではないけど、同じ原理のバリエーションです)を使うと、全体の文が「今日はどう?」になると予測して、LLMは「こんにちは」=>「!」、「こんにちは!」=>「どう」...と並列で生成できます。最終的なトークンは捨てられますが、接頭辞「今日はどう?」が実際に生成されたものと一致しないからです。この例では、純粋な自己回帰推論よりも5トークンを5倍早く取得できますが、6番目のトークンが生成されてすぐに捨てられるという代償があります。つまり、トークンのスループットは5倍ですが、トークンごとの計算コストは20%増加します。[1]: 自己回帰型LLM、つまりみんなが使っている最もパフォーマンスの高いものです。[2]: 低バッチサイズで自分のコンピュータで個人用に実行した場合に限ります。データセンターでは、多くの同時ユーザーがいると、GPUは実際には計算に制約されます。

ボトルネックを移動させることが全てです。プロンプト処理中はすべてを並列で計算できますが、トークン生成中は一度に1つのトークンを作成します。例えば、RTX 4000 Adaを使うと、プロンプト処理で2700 t/s、8Bクラスモデルでトークン生成は48 t/sです。彼らのアプローチは、複数のトークンを同時に予測してから検証する投機的デコーディングのアプローチです。これにより、プロンプト処理速度に近いスピードでより多くのトークンが生成されます。彼らのアプローチは、基本モデルと同じ出力分布を得られる特別なもののようで、追加のメモリもごくわずかです。主な注意点は、プロンプト処理速度がすでに悪い場合、あまり効果がないことです。例えば、MシリーズのMac(M4まで)は、プロンプト処理速度に対して生成速度が相対的に高いです。つまり、あまり恩恵を受けない(全く受けないかもしれない)ということです。M5ではプロンプト処理速度が4倍に増加したので、良い向上が期待できるでしょう。

誰かがこれをGGUFやQuantized Qwen 3.6、Deepseek 4でうまく動かせたら、ローカルモデルの運用がすごく楽になると思う。

マルチトークン予測は今利用可能だよ。まだセットアップ中だけど、大きいモデルだと1.5倍か2倍になるみたい。

よくわからないな。これはQwen3から拡散トランスフォーマーを抽出してるんだよね。確かに同じっていうのはいいけど、フルの拡散トランスフォーマーの方がまだ速いと思う。

フルの拡散トランスフォーマーはもっとフォワードパスが必要になるから(その分遅くなる)、もしくは出力が悪くなる可能性があるんだよね(トークンを独立して並列で生成する時に依存関係を正しく考慮できないから)。オートレグレッシブのベースラインと出力を同じに保つことで、スピードアップが品質の劣化を伴わないようにしてるんだ。

うちの@antirezはこれをどう思うかな。

それじゃあ、OpenAIやAnthropicが似たようなことを実装したら、午後の混雑が緩和されるのかな?

いや、逆に悪化すると思うよ。これだと計算が増えて、スループットを犠牲にしてシリアルな単一ユーザー生成のレイテンシを改善することになるから。大規模なプロバイダーは、レイテンシを犠牲にしてスループットを上げるために、バッチ処理で推論を行ってるんだ。