推論速度最大7.8倍！Qwen3を高速化する「Orthrus」が凄すぎる

おっ、ぜひQwen3.5 9bも対応して！VRAM 16GBしかない貧弱な環境だからマジで助かる！

うん、Orthrus-Qwen-3.5-9Bも近いうちに公開するよ。

Carnice-9bの方がいいんじゃないかな。

趣味や学習用としては理想的な量だよね！これまで試してきたトリックや怪しいレポジトリが山ほどあるよ。大抵は失敗に終わるけど、少なくとも何かしらは学べるしね…。

「興味深い時代を生きよ」っていう言葉みたいだ。

まあ、実用性を求めている人にとっては、ある程度までは最悪だろうけどね（笑）

もちろん、Qwen 3.5と3.6のサポートももうすぐ来るよ！MoEモデルやその他のアテンションベースのアーキテクチャとも互換性があるから安心して。

学習用コードも公開する予定はある？

Gemma-4-31B？

最初はQwen3から始めたんだ。ドキュメントがしっかりしてて標準的なデンスモデルだし、研究のアイデアを検証するのに最適だったからね。他のモデルにも順次対応していく予定だよ！

オッケー、3.5 9bの方をお願い！

了解、Qwen3.5とQwen3.6の追加作業中だから楽しみに待ってて！よかったらレポにスターして最新情報を追ってね！

そう、カスタムカーネルのサポートが必要になる。今まさにモデル対応を広げているところで、llama.cppもロードマップに入ってるよ。コントリビューションも大歓迎！

llama.cppにPR投げてくれよ。そしたらみんな手伝えるから。

それいいアイデアだね、ありがとう！

理論上、モデルサイズが大きくなるほど高速化の恩恵もスケールするはずです。KVオーバーヘッドはモデルサイズに関係なくO(1)なので、VRAMを圧迫することはありません。唯一の追加コストは拡散モデルのパラメータ分だけですが、全体から見ればごくわずかな割合ですよ。

この原則がMistral mediumでも通用するなら、大当たりだね。

主な懸念点はこんな感じかな：

1. VRAMの使用量が増えること。実質的に2つ目のモデルを並列で動かすことになるわけだし、元のLLMと1:1のオーバーヘッドにはならないとは思うけどね。だからVRAMにかなり余裕がない環境だと、パフォーマンス向上どころか逆に負荷が大きすぎて動作が重くなる可能性がある。
2. 必要な計算量も確実に増える。例えば自分はTesla A16（実質的にA2 16GBを4枚積んだ構成）を使ってるんだけど、ハードウェア制限で60Wに抑えられてるんだ。ある程度のサイズのモデルはロードできるけど、大規模なタスクだと計算能力や電力制限に引っかかることが多いから、リアルタイム性を求めない大量のバックグラウンド処理（数百万単位のチャンクを埋め込みモデルに流し込むような作業）用に使ってる。LLMだけで電力と計算リソースをフルに食いつぶすこともあるから、今回の手法だとトータルの時間は変わらないかもしれない。まあ、後でテストしてみるつもりだけどね。
3. 投稿にもある通り、拡散モデルの性能は学習データに依存する。だからコーディングタスクだけで学習させたら、クリエイティブな文章作成とかには使い物にならなくなるだろうね。そういうケースだと、拡散モデルに費やす時間と、結果が使えないという無駄を考えると逆に遅くなるはず。だから特定のタスク向けに小さなモデルを使い分けるみたいに、複数の拡散モデルを用意して切り替えるのが現実的かもね。

CPU/RAMオフロードでも動くとは思うけど、研究段階の実装でそこまで最適化されているかは疑問。GPUとシステムRAMの間でデータが行ったり来たりするような変な動きにならないよう、レイヤーを適切に配置する調整は必要だろうけど、それでも速度向上は見込めると思うよ。

いやいや、コミュニティの中にはそれだけの計算資源を持ってる人たちもいるっしょ👀

金を持ってる連中が、計算リソースを持ってる連中に金を払うってわけか。

全く別の研究が必要だな。qwen3.6って標準的なTransformerじゃないと思うし。

仮にゲート付きのDeltaNetモデルじゃなかったとしても、27Bを再現するには100GB以上のメモリが必要になるだろうな（論文には8×H200を8Bのために使ったって書いてあるし、笑えるわ）。

たぶん高速化のためじゃないかな

3.6が出ることはすでに確約されてるから、そこは問題なさそうだよ。

8BのdenseモデルでH200×8基を24時間使ったわけだよね。
27Bでもやれるはずだし、コストがかさむだけさ。もし性能向上が本物なら、みんなで出資して実現できるんじゃない？

64Kコンテキストまでテストしたけど、かなりうまくいってるよ。DFlashで長文時に性能が落ちるのは、KVキャッシュを独自に持つ外部ドラフターを別途維持してるからじゃないかな。コンテキストが伸びると分布のズレが生じるのかも。Orthrusは外部ドラフターを使わずKVキャッシュを共有してるから、その問題は起きないはず。ぜひ試してみて、結果を教えてよ！

了解！ありがとう。

PPってPrompt Processing（プロンプト処理）のこと？それともPerplexity（パープレキシティ）？

パープレキシティだよ

64Kのコンテキストまでテストして、うまく動作することを確認しています。DFlashで長文脈の際に精度が落ちるのは、おそらく外部のドラフターを別々に保持していて独自のKVキャッシュを持っているからで、文脈が長くなるにつれて分布のズレが生じるのが原因でしょう。OrthrusはKVキャッシュを外部ドラフターなしで共有しているから、その問題は起きにくいと思います。ぜひ試して、結果を教えてください！

マジですごいな。より大きなモデルを動かせる計算リソースを持ってそうな人たちにこの情報を共有しておくよ (;

ちょっと試してみたんだけど、コンテキスト長40KまでのベンチマークだとDFlashより2倍くらい速いよ（かなり長いコンテキストなら5倍いけるかも）。DFlashは長文コンテキストだとかなり遅いからね。

それと、macOSのMetalについてはどうなんだろう？

論文には「ピーク時のGPUメモリオーバーヘッドは事実上無視できる（1%未満）」って書いてあるけど、どうやってるのか不思議だな。リンクされている8Bモデルは、オリジナルのQwen3バージョンより18%も大きいんだけど。

はい、フル学習パイプラインもまもなく公開予定です。最大64Kのコンテキスト長までテスト済みで、かなりいい感じに動いていますよ。ぜひ試してみて、エッジケースなどで何かあればフィードバックをいただけると助かります。

うん

指摘してくれてありがとう。5.36倍という数値は、評価した全タスクや設定の平均スピードアップ値だから、より保守的で集約的なパフォーマンスを表してるんだ。7.8倍というのは特定のタスクや設定におけるピーク時の結果、つまり手法の効果が最大限に発揮された「最大」のスピードアップ数値だよ。

フィードバックありがとう、本当に助かるよ。サンプリング（top_p, top_k）とグリーディデコーディングの両方をサポートしてるから、実装の詳細はリポジトリをチェックしてみて。

そう、論文ではMATH-500以外にも幅広いベンチマークを評価してるよ。MATH-500は主に図をプロットするためと、他の拡散適応手法（例えばFast-dLLM-v2など）が苦戦し始めるポイントを明確に示すための例として使ったんだ。

確かにね。Math-500は最も好条件だから、最大アクセプタンスを測定するには一番きれいなデータセットが得られるんだろうね。他のデータセットもシェアしてもらえる？

追記：他のテスト手法だと大体2〜3倍増くらいに落ち着くね

はい、完全な学習パイプライン（データとコード）を近々オープンソース化する予定です。今はQwen3.5とGemma-4のチェックポイントのリリースを優先していて、それが終わり次第すぐにパイプラインも公開します。関心を持ってくれてありがとう。これを使って何を作ってくれるのか楽しみです。

64Kのコンテキスト長までテスト済みで、かなりうまく動作するよ。llama.cppに関しては、カスタムカーネルのサポートが必要になるね。現在より広範なモデルサポートに取り組んでいて、llama.cppとの統合もロードマップに入ってるよ。