決定モデルは、長い会話とかエージェントの履歴みたいな共有状態に対して、いくつかの質問を投げて選択肢の確率を出す。でも既存の生成向けエンジンは、質問ごとに別プロンプトとして扱いがちで、共有部分を何度も計算したり読み直したりするんだ。

そう。さらにハイブリッドモデルだとGatedDeltaNetの再帰状態がブロック境界にしか保存されなくて、質問ごとに境界以降を計算し直すことがある。SGLangのmulti-item scoringみたいに質問を区切りトークン付きで連結する方法も、入力が単独時と変わって出力確率がずれる、と論文は指摘してる。

そこが動機。Flideは、リクエストの木構造とGPU上の物理実行を分ける。共有状態と複数の質問を1本のフラットなトークン列にして、各トークンにリクエスト番号、枝番号、位置みたいなメタデータを持たせる。

それがForkAttention。フルアテンションでは、同じリクエストで、共有状態か自分の質問枝に属してて、位置が後ろじゃないキーだけ見る。だから各質問は、単独でs⊕q_iを実行したときと同じ見え方になる。

GatedDeltaNet層を2回に分けて呼ぶ。1回目で各リクエストの状態部分を処理してS_Pと畳み込み窓を出して、2回目で全質問をまとめて処理する。各質問は自分の共有状態のS_Pから、コピーせずにインデックスで続きを始める。

正確な算術の因果モデルなら、Flideが各トークンで計算する隠れ状態は単独プロンプトと同じ、という命題を置いてる。ただ、通常の浮動小数点で完全にbitwise一致させるには、任意機能のbatch-invariantモードが必要で、その性能オーバーヘッドは提示本文からは確認できない。

比較はvLLMとSGLang、それにSGLangのmulti-item scoring。公開ハイブリッドモデルと決定モデルで、最大9.5倍速く、float32参照に最も近いTV距離だった、と論文は報告してる。これは原論文の評価で、僕らが追試した話じゃない。

共有状態に対して複数の質問がある、Jevみたいな決定モデルやSystem One API形式が主対象。因果モデルで、フルアテンションとGatedDeltaNetを含むハイブリッドモデル、GPU常駐メタデータとCUDAグラフで単一パス実行する構成が想定されてる。具体的なGPU機材や全対応モデル一覧は提示本文からは確認できない。

最大9.5倍は公開ハイブリッドモデルでの上限表現で、全モデル・全負荷・全並列度で同じ改善を保証するものじゃない。厳密性の命題も正確な算術での因果モデルに対してで、評価は公開ハイブリッドモデルと決定モデルに限定されてる。非因果モデルや極端な長文脈、マルチモーダルの広い条件、長期運用時のメモリ挙動は未検証。

その通り。単一パス、入力無汚染、ハイブリッド状態分岐、CUDAグラフ再実行、任意負荷下のbitwise不変モードを同時に満たす唯一のエンジンだ、とTable 1で主張してる。ただしこれも論文の主張で、独立再現はしてない。

お前の質問は枝が多すぎて、共有状態より質問の方が長い。

まず前提。LLMはパラメータがデカくてコンシューマGPUのメモリに収まらない。圧縮すると精度が落ちる。全部オフロードするとPCIeが詰まって遅い。この二択がつらいんだ。

そう。量子化誤差をLoRAっぽい低ランク行列で補正する。でも補償用パラメータは全部GPUに置けない。だから計算が重い量子化バックボーンはGPU、メモリ食いで各ステップでは一部しか触らない補償はCPUに置く。

GPUが量子化計算してる裏でCPUが補償ブランチを計算する。常駐プロセスと共有メモリで起動コストを減らす。QKVやup/gateはまとめて通信を融合して、MoEは活性エキスパートをまたいでパイプライン化する。

感度に基づく動的ランク割り当てだね。特異値の集中度、KLダイバージェンスで測る行列と層の感度、MoEのルーティング重みを組み合わせて優先度を決める。CPU計算と通信をGPUの裏に隠せる標準ランクを基準に配る。

Qwen-30B-A3BとLlama-3.1-8Bで評価してる。圧縮モデル比で最大5.2%の精度改善、量子化ベースライン比で2.3〜5.2%改善しつつスループット85%以上、フル精度比で最大10.4倍高速化。比較対象は量子化のみの圧縮モデル、量子化ベースライン、フル精度モデルだね。

そこは提示された本文からは確認できない。数値もモデルも論文の報告として扱うのが安全だよ。

評価は2モデルだけ。CPU性能やPCIe帯域に依存するし、標準ランクもハード依存。事前の感度プロファイリングも必要。他のモデル、量子化方式、極端な圧縮、低ランク構造が弱い誤差への一般化は未確認。全条件でフル精度同等を保証する話でもない。

その時給はPCIe帯域で払うのか？ 交通渋滞したら一気に未払いだな。

履歴を読む方もコストだけど、論文だとビーム探索のデコードが支配的だって。ビーム幅100の計測では生成時間の最大91%がビーム探索で、履歴キャッシュを共有しても残る。FlatGRとFusedGRは履歴の読み方は違うけど、候補を書く方を重いバックボーンでO(BK)回やるのが共通のボトルネック。

そう。そこでDecoは「履歴を理解する」と「SIDを綴る」を分ける。重いバックボーンが融合済み履歴を一度読んで、次アイテム概念zを作る。あとは軽量でKVキャッシュ付きのデコーダが、zと生成済みprefixだけを条件に、トライ制約付きビーム探索を全部回す。SIDもトライも自己回帰の分解も変えない。

まずクロスエントロピーだけで訓練できるDeco-CEがある。さらにフルバックボーンの教師から蒸留すると精度が上がる。教師はFusedGRで、Deco-flatならFlatGR。音楽ストリーミングみたいにリピート消費が多い領域では、履歴へのコピーポインタも足す。固定サイズの概念だけじゃ過去アイテムの同一性をたくさんは持てないからね。

SIDとSIDトライを使う生成推薦・生成検索が対象で、履歴などのインタラクションデータ、SIDトークナイザ、トライが必要。実験はe-commerce、映画、音楽ストリーミング由来の7データセット、production-style serving pipelineで、50ms p95レイテンシ予算やバッチ128、最大3BパラメータのLLMバックボーンまで言及されてる。軽量デコーダの既定は2層・幅256で、バックボーンは8層・幅640との比較。概念ベクトル数Mは1から8で同程度とされ、実験ではM=2。

7データセットで、標準の生成推薦や融合入力のフルバックボーン教師に対して同等以上精度。スループットは要旨だと50ms p95予算下で3.2–8.6倍、導入の箇条書きではバッチ128でFusedGRの2.8–5.1倍、50ms p95で3.2–7.3倍と書いてある。1000候補生成が教師の100候補生成より速い、1.5Bバックボーンが69M教師と同等スループットで精度は上、3BでFusedGR比16倍という報告もある。

そこが意義。ビーム幅やSID深さを増やしても、追加の重いバックボーン呼び出しは不要で、計算が軽量デコーダ側に寄る。概念はbf16で1KiBのサービング状態になるって話も、履歴KVキャッシュが0.4–7.8MiBなのと比べると大きい。

速度向上はビーム幅、SID深さ、バックボーン規模、履歴長に依存する。長い履歴は主にprefillとして両方に残る。評価も提示本文では7データセットとproduction-style pipelineまでで、実サービスの長期A/Bや別ドメインへの一般化は確認できない。あとリピート用途はコピーポインタ頼みで、その詳細や並列・拡散型との全比較条件は抜粋だけだと十分には分からない。

下書きが軽いとは一言も言ってない。まず履歴を読むところからだ。

ああ、RMMはLLMの推論を速くするための手法だよ。LLMの中では行列の掛け算がたくさんあるんだけど、その計算の一部を入力に応じて省略できるんだ。

実は、LLMの推論では、入力のトークンによって重要でない部分があるんだ。RMMはその重要度を測って、行列積の縮約次元を動的に削る。つまり、計算に使う次元を減らすことで、計算量を減らすんだ。

そこがポイントで、RMMは学習不要で、保持率っていうパラメータを指定するだけで、精度と計算量のトレードオフを調整できるんだ。保持率を高くすれば精度は保たれるけど計算量は増えるし、低くすれば計算量は減るけど精度は落ちる。

うーん、学習不要なのは利点だけど、保持率の設定が難しいかもしれない。低くしすぎると精度が大きく落ちる可能性があるし、入力によって最適な値が変わるかもしれない。あと、論文では主に特定のモデルでの評価だから、他のモデルでも同じ効果があるかは要検証だね。

まあ、似たようなものだね。でも、ダイエットと違って、削りすぎるとモデルが壊れるから注意が必要だけど。

ああ、これは事前学習済みのLLMを再学習なしで高速化するフレームワークだよ。各層の入力と出力のコサイン類似度を計算して、トークンの保持率を決めてるんだ。

類似度が高い層は出力が入力と似てるから、あまり計算しなくても大丈夫って判断して、トークンを間引くんだ。逆に類似度が低い層は重要な変化があるから、多くのトークンを残す。軽量なMLPルーターがその割合を決めてくれる。

いや、限界もあるよ。ルーター自体のオーバーヘッドや、タスクによっては間引きすぎると性能が落ちる場合がある。あと、この手法は推論時の高速化に特化してて、学習時には使えない。

そう。特にNVIDIA Jetson Orin Nanoっていう小型のAIボードで、3BパラメータのLLMを動かす研究だよ。普通はメモリが足りなくて動かないんだけど、SelectInferっていう手法でそれを可能にしてる。

LLMのニューロンには、タスクに特化したものと、どんなタスクでも使われる共通のものがあるんだ。SelectInferはオフラインでタスクごとに重要なニューロンを特定して、メモリには全体の70%だけ読み込む。さらに実行時にはその中の40%だけ計算する。

実験では、4ビット量子化と比べて1.53倍、ディスクにデータを置いて逐次読み込む方式と比べて13倍以上高速化できて、精度もほとんど落ちなかったって報告されてる。タスク固有のニューロンは重要度が高いから、削っても影響が少ないんだ。

そこが課題だね。論文でも、タスクが増えるたびにオフライン解析が必要になるって指摘してる。あと、この手法は推論時の計算を減らすけど、学習には使えない。あくまで推論専用。

そうだね。特にプライバシーが重要な場面や、ネットワークが不安定な場所では価値が高い。ただ、まだ研究段階で、実際の製品に載せるにはもう少し最適化が必要だと思う。

その場合は、重要な講義だけ選んで70%出席して、40%だけレポートを書けばいいってこと？…多分単位は落ちるよ。

ああ、この論文か。拡散ベースのLLM、つまりdLLMの推論を速くする方法についての研究だよ。今のAIが文章を生成するとき、基本的には1単語ずつ順番に作っていくんだ。それがボトルネックになって、応答が遅くなる原因の一つになってる。

そう。画像生成で有名な拡散モデルの仕組みを、文章生成に応用したものがdLLMだ。特徴は、最初は全部をマスク（隠す）した状態から始めて、少しずつマスクを外しながら文章を作っていくこと。理論的には、一度に複数のマスクを外せる、つまり複数の単語を並列で生成できる可能性があるんだ。

そこがこの論文の問題提起なんだ。実際にやってみると、一度にたくさんの単語を決めようとすると、文章の質がガタ落ちしちゃうんだよ。理論と現実にギャップがある。例えば、「私は」の次に「ご飯を」と「食べた」を同時に決めようとしても、文脈がおかしくなることがある。

彼らが提案した方法は「DiCo」って名前で、要は「分割統治」作戦だ。まず、マスクされた単語列を眺めて、安全に同時に決められそうな単語のグループ（クラスタ）を見つける。これが「分割」フェーズ。

モデルがその単語をどれだけ自信を持って予測しているか（確信度）や、単語同士の距離、それに注意機構のパターンを見るんだ。論文によると、生成の初期や中期は、離れた位置の単語同士はあまり影響し合わないから、離れたクラスタは同時に処理できる。

次が「統治」フェーズだ。見つけた複数のグループに対して、それぞれのグループ内で単語を決めていく作業を、並列で一気にやる。この「分割」と「統治」を繰り返して、だんだんマスクを減らしていく。最後に少しだけ残った、お互いに強く影響し合う単語は、慎重に1つずつ処理する「最終化」フェーズで仕上げる。

実験結果によると、既存のdLLMにDiCoを組み込むことで、推論速度を最大で約2.4倍まで向上させられて、しかも文章の質（正解率や一貫性）はほとんど落とさずに済んだんだ。特に数学の問題を解くようなタスクで効果が大きかった。

そうだね。大きな意義は、モデル自体を再学習させなくても、デコードの仕方を工夫するだけで性能を引き出せる「学習不要」な手法だってことだ。でも課題もある。クラスタをどう分割するかの判断が完全ではなく、複雑な文章ではまだ限界がある。あと、本当に理想的な並列化を実現するには、ハードウェアやライブラリのサポートも必要かもしれない。

そうだね。並列処理がボトルネックになっている様々な生成タスクに応用できる可能性はあると思う。今後の研究で、もっと賢い分割の仕方や、他の種類のモデルへの応用が進むんじゃないかな。

…それはただの効率的な作業計画だよ。論文の内容をそういう風に応用するんじゃない。

ああ、それはLLMの推論を効率化する研究だね。簡単に言うと、AIの「記憶」を賢く節約して、動くスピードをめちゃくちゃ速くしようっていう技術だよ。

物忘れというか、長い文章を作るときに、それまでに話した内容を「KVキャッシュ」っていう場所に一時保存しておくんだ。でも、文章が長くなればなるほど、このキャッシュが巨大になってメモリを使い果たしちゃうのが今の大きな課題なんだよ。

例えは悪くないね。そこで「量子化」っていう技術を使って、その書類をギュッと圧縮するんだ。ただ、これまでの圧縮方法は、GPUっていう計算機にとって少し効率が悪かったんだよ。

一番のポイントは「インナー次元グルーピング」だ。これまでの手法はデータの並びを無視して圧縮してたから、計算するときに何度もメモリを読み直す必要があった。InnerQはGPUが一度に読み込むデータの塊に合わせて圧縮するから、無駄な動きが減って速くなるんだ。

……まあ、整理整頓の仕方をハードウェアに最適化したって意味では合ってるよ。これで従来の圧縮方法より22%も速くなったんだ。

そこも工夫されてる。「ハイブリッド量子化」といって、データのバラつき具合を見て、グループごとに最適な圧縮ルールを自動で選ぶんだ。さらに、文章の最初の方にある重要な言葉と、直近の言葉だけは圧縮せずにそのまま残しておく「高精度ウィンドウ」っていう仕組みも使ってる。

Llamaっていう有名なモデルで数学の問題を解かせたんだけど、圧縮してない時とほとんど変わらない正解率を出したよ。それでいて速度は爆速。かなり実用的だね。

そうだね。メモリが少ないデバイスでも長い文脈を扱えるようになるから、スマホのAIアシスタントがもっと賢くなる可能性がある。将来的には、もっと少ないビット数で圧縮しても精度が落ちないようにするのが課題かな。

君の場合は圧縮する前に、まず情報を脳内に「インプット」するところから始めなよ。

ポップコーンじゃないよ。これは「Partition-guided Online Pruning」の略で、AIの推論を効率化する技術の話だね。

例えとしては合ってる。AIのモデルは巨大すぎて動かすのに時間がかかるから、計算にあまり使われていない「無駄な部分」を削って速くするんだ。それを構造的剪定（ストラクチャラル・プルーニング）って呼ぶんだよ。

そこがこの論文のポイントなんだ。今までの手法は、推論を始める前に「ここを切る」って固定しちゃうものが多かった。でも、AIが文章を作っている最中って、その時々の言葉（文脈）によって大事な場所が変わるんだよ。

そう。このPOPは、推論の途中で「オンライン」で動的に切る場所を変える。しかも、計算が重くならないように工夫されているんだ。

POPは、モデルの通り道を3つのエリアに分けるんだ。「絶対使うエリア（保持）」、「たぶん使わないエリア（削除）」、そして「状況に応じて使うか決めるエリア（候補）」の3つだね。

……。最初の入力（プリフィリング）の時に、ざっくりとこの3つのエリアを決める。で、実際に1文字ずつ文字を作っていく（デコーディング）時に、「候補」エリアの中からその瞬間に必要な分だけをサッと選ぶんだ。全部をチェックし直すと遅くなるけど、この「候補」だけに絞るから速いんだよ。

実験では、Llama2-7Bっていう有名なモデルで、精度をほとんど落とさずに1.29倍も速くなったらしい。しかも、事前の特別な訓練もいらないから、いろんなAIにすぐ使える「プラグアンドプレイ」なのも強みだね。

スマホとかの性能が低いデバイスでも、巨大なAIがサクサク動くようになるかもしれない。ただ、今はまだ特定の計算ブロック（FFN）が中心だから、今後はモデル全体をもっと効率よく削る研究が必要になるだろうね。

亜美さんの場合は、まず「削除」エリアが多すぎるのをなんとかしないとね。

これはVLM、つまり画像と文字を同時に扱うAIを、もっとサクサク動かすための研究だよ。画像って、AIが処理するときに「トークン」っていう小さなパズルのピースみたいに分解されるんだけど、その数が多すぎて計算が大変なんだ。

そう。それを「プルーニング（枝切り）」って言うんだ。でも、適当に減らすと大事な情報まで消えちゃう。そこでこの論文は、人間が物を見るときのやり方を真似しようって提案してるんだよ。

それがまさに最初のステップの『Focus（フォーカス）』だね。この手法では、まず「質問に関係があるか」と「画像の中で目立っているか」の両方を見て、大事なピースを絞り込むんだ。これを「デュアルパスウェイ・スコアリング」って呼んでいるよ。

鋭いね。だから2番目のステップが『Scan（スキャン）』なんだ。Focusで選んだピースとは全然違う場所にあるピースを、画像全体からパラパラと拾い集める。これで、背景とかの全体的な状況も把握できるようにするんだよ。

……まあ、例えはともかく、情報の偏りを防ぐわけだ。そして最後が『Refine（リファイン）』。これは、捨てちゃう予定のピースに残っている細かい情報を、残すことに決めたピースにギュッと混ぜ合わせる作業なんだ。

言い方が悪いな。似ている特徴を持つピース同士を「重み付きマージ」で統合するんだよ。これによって、ピースの総数は増やさずに、情報の密度を上げることができるんだ。これがこの研究の賢いところだね。

実験の結果、他の最新手法よりもずっと少ないトークン数で、高い正解率を出せたんだ。特に、画像の中の複数の物体の関係を答えるような難しい問題で、大きな効果があったみたいだよ。

その通り。メモリの節約にもなるから、デバイスへの負担が減る。将来的には、リアルタイムで動画を解析するような技術にも応用できるはずだよ。ただ、まだ「どのくらい削るのがベストか」を完全に自動で決めるのは難しいっていう課題もあるけどね。

テストは全部大事なんだから、勝手にプルーニングするなよ。