TL;DR
Flideは、決定モデルへの問い合わせを「共有状態＋複数質問」の木として扱い、GPU上では1本のフラットなトークン列として実行する推論エンジンです。ForkAttentionにより全注意層とGatedDeltaNet層の状態を分岐させ、各質問を単独実行時と同じ計算に保ちながら、共有状態の再計算を避けます。論文では公開ハイブリッドモデルと決定モデルでvLLM/SGLangより最大9.5倍高速かつfloat32参照に最も近いTV距離と報告しています。
既存手法との違い
原論文はvLLMやSGLangなどの生成向け推論エンジンと比較しています。既存手法では各質問を独立プロンプトとして扱うため共有状態を繰り返し計算・再読み込みし、ハイブリッドモデルではGatedDeltaNetの再帰状態がブロック境界にしか保存されないため再計算が発生します。SGLangのmulti-item scoringは質問を区切りトークン付きで連結するため、入力が単独時と変わり出力確率がずれると論文は指摘します。Flideは共有状態と全質問を単一パスで実行し、ForkAttentionで各質問を厳密に分岐させます。Table 1では、単一パス・入力無汚染・ハイブリッド状態分岐・CUDAグラフ再実行・任意負荷下のbitwise不変モードを同時に満たす唯一のエンジンと主張されています。論文報告の最大9.5倍高速化とfloat32参照へのTV距離は原論文の評価であり、本記事で追試したものではありません。
使える条件
対象はJevなどの決定モデルやSystem One API形式の「共有状態と複数質問」を持つリクエストです。因果モデルを前提に、全注意層とGatedDeltaNet層を含むハイブリッドモデル（Qwen3.5など）で、GPU常駐メタデータとCUDAグラフを用いて単一パス実行する構成が想定されています。厳密性の命題は「正確な算術」での因果モデルに対するもので、実数演算の完全一致には任意のbatch-invariantモードが必要です。評価は公開ハイブリッドモデルと決定モデル、1文書1質問から記事・エージェント軌跡の複数質問までとされています。具体的なGPU機材、対応モデルの全一覧、メモリ使用量、商用環境での運用条件は提示本文からは確認できません。
限界と未検証の範囲
最大9.5倍高速化は公開ハイブリッドモデルでの上限表現であり、すべてのモデル・負荷・並列度で同じ改善を保証するものではありません。厳密性は正確な算術での因果モデルに対する命題で、通常の浮動小数点実行ではfloat32参照に最も近いTV距離という評価にとどまります。bitwise不変モードは任意機能で、その性能オーバーヘッドや全モデルでの動作は提示本文からは確認できません。評価範囲は公開ハイブリッドモデルと決定モデルに限定され、非因果モデル、極端な長文脈、マルチモーダル入力の広範な条件、長期運用時のメモリ挙動は未検証です。本記事は独立再現を行っていません。
解説
ねえ智也くん、このFlideって論文、決定モデルの推論を速くする話らしいけど、そもそも何がそんなに困るの？
決定モデルは、長い会話とかエージェントの履歴みたいな共有状態に対して、いくつかの質問を投げて選択肢の確率を出す。でも既存の生成向けエンジンは、質問ごとに別プロンプトとして扱いがちで、共有部分を何度も計算したり読み直したりするんだ。
同じ前置きを何回も読む感じ？ それは遅いし、もったいないね。
そう。さらにハイブリッドモデルだとGatedDeltaNetの再帰状態がブロック境界にしか保存されなくて、質問ごとに境界以降を計算し直すことがある。SGLangのmulti-item scoringみたいに質問を区切りトークン付きで連結する方法も、入力が単独時と変わって出力確率がずれる、と論文は指摘してる。
速くするために確率が変わっちゃうのは、決定モデルだとけっこう怖いかも。しきい値で判断するんでしょ？
そこが動機。Flideは、リクエストの木構造とGPU上の物理実行を分ける。共有状態と複数の質問を1本のフラットなトークン列にして、各トークンにリクエスト番号、枝番号、位置みたいなメタデータを持たせる。
木をバラバラにしないで、平らに並べるんだ。じゃあ、質問同士が混ざらないようにする仕組みが必要だね。
それがForkAttention。フルアテンションでは、同じリクエストで、共有状態か自分の質問枝に属してて、位置が後ろじゃないキーだけ見る。だから各質問は、単独でs⊕q_iを実行したときと同じ見え方になる。
GatedDeltaNetはマスクで分けられないって話だったけど、そこはどうするの？
GatedDeltaNet層を2回に分けて呼ぶ。1回目で各リクエストの状態部分を処理してS_Pと畳み込み窓を出して、2回目で全質問をまとめて処理する。各質問は自分の共有状態のS_Pから、コピーせずにインデックスで続きを始める。
なるほど。共有状態は1回だけ計算して、質問は自分の枝だけを正確に続ける感じか。論文では厳密性をどう言ってるの？
正確な算術の因果モデルなら、Flideが各トークンで計算する隠れ状態は単独プロンプトと同じ、という命題を置いてる。ただ、通常の浮動小数点で完全にbitwise一致させるには、任意機能のbatch-invariantモードが必要で、その性能オーバーヘッドは提示本文からは確認できない。
評価は何と比べてるの？
比較はvLLMとSGLang、それにSGLangのmulti-item scoring。公開ハイブリッドモデルと決定モデルで、最大9.5倍速く、float32参照に最も近いTV距離だった、と論文は報告してる。これは原論文の評価で、僕らが追試した話じゃない。
条件はけっこう大事だね。どんなリクエストなら効くの？
共有状態に対して複数の質問がある、Jevみたいな決定モデルやSystem One API形式が主対象。因果モデルで、フルアテンションとGatedDeltaNetを含むハイブリッドモデル、GPU常駐メタデータとCUDAグラフで単一パス実行する構成が想定されてる。具体的なGPU機材や全対応モデル一覧は提示本文からは確認できない。
じゃあ、どこでも9.5倍ってわけじゃないんだ。制限も教えて。
最大9.5倍は公開ハイブリッドモデルでの上限表現で、全モデル・全負荷・全並列度で同じ改善を保証するものじゃない。厳密性の命題も正確な算術での因果モデルに対してで、評価は公開ハイブリッドモデルと決定モデルに限定されてる。非因果モデルや極端な長文脈、マルチモーダルの広い条件、長期運用時のメモリ挙動は未検証。
でも意義は大きいよね。論理的な木と物理的な実行を分けるから、共有状態を1回で済ませつつ、各質問は単独時と同じ計算に保てる。決定モデルをたくさん走らせるエージェント向けの基盤って感じ。
その通り。単一パス、入力無汚染、ハイブリッド状態分岐、CUDAグラフ再実行、任意負荷下のbitwise不変モードを同時に満たす唯一のエンジンだ、とTable 1で主張してる。ただしこれも論文の主張で、独立再現はしてない。
じゃあ私の質問も木に分けて、共有部分だけ頭良くしてくれないかな。答えは枝ごとに違うけど。
お前の質問は枝が多すぎて、共有状態より質問の方が長い。