TL;DR

InferSliceは、通信事業者の地理分散GPUとネットワークを共有基盤にし、アプリのSLOに応じてLLM推論の配置・構成・スライスを選ぶ参照アーキテクチャです。JOINER WAN上では、SLO階層ごとに遅延・スループット特性が分かれ、重みストリーミングがスケールアウト時間を短縮しました。一方、DPは配置に鈍感だがメモリ制約、PPは近〜中距離の跨拠点に耐える一方、TPとPrefill/Decode分離は単一サブネット超で失敗しました。

既存手法との違い

提示本文では、既存システムとの同一条件での直接比較結果は明示されていません。設計比較として、既存のLLM servingは密結合データセンターの高帯域・低遅延インターコネクトを前提とし、地理分散・異種資源の協調支援が限定的とされています。LLM-Sliceは無線ネットワークスライスでLLM通信を差別化しますが、推論計算の配置・オーケストレーションが主眼ではありません。InferSliceは複数のテルコ拠点を共有推論基盤とし、SLOと計算・ネットワーク状態に基づいて配置と推論構成を選ぶ点が異なります。

使える条件

想定利用は、通信事業者が運営する地理分散拠点（中央局、地域データセンター、コア網拠点など）のGPU/ネットワークを共有し、TTFT/TPOTやスループットなどのSLOを持つ複数サービスを同一基盤で扱う場合です。前提として、汎用WANで専用AIインターコネクトやRDMAを仮定しません。構成要素はネットワークスライス、GPU分割、弾性配信、観測性、TP/PP/DP/Prefill-Decode分離です。評価はJOINER UK WAN上の複数都市・複数PoPで行われています。プロンプト長・出力長・負荷・GPU種類などの詳細条件は提示本文からは確認できず、商用網や他地域への適用可否は未知です。

限界と未検証の範囲

評価はJOINER上の汎用テルコWANで、専用AIファブリックなしで実施されています。TPとP/D分離は単一サブネットホップを超えると失敗、PPは近〜中距離の跨拠点まで、DPは配置に鈍感だがメモリ制約という境界が報告されています。これらは特定のモデル・GPU・負荷・ネットワーク条件に依存し、提示本文には数値や詳細条件がないため一般化できません。商用テルコ環境、他のWAN、多様なGPU、規制・セキュリティ、コスト、障害時挙動、SLO達成率の定量的一般化は未検証です。本記事は参照アーキテクチャの論文を解説するもので、実装や追試を行ったものではありません。

解説

ねえ智也、この「InferSlice」って論文、タイトルからして難しそう。通信事業者の広域網でLLM推論を支える設計ってこと？

そう。LLM推論が中央クラウドに集まると、データ主権やコンプライアンス、遠い場所の遅延、手元の計算資源を使えない問題がある。テルコの地理分散GPUとネットワークを共有基盤にしようって発想。

なるほど。でも普通のLLM servingフレームワークじゃダメなの？

既存は密結合データセンター前提で、高帯域・低遅延インターコネクトを当然視しがち。広域で異種GPUが混ざるテルコ網は前提が違う。InferSliceはSLOに応じて配置・構成・スライスを選ぶ参照アーキテクチャ。

SLOってTTFTとかTPOT？

そう。最初のトークンまでの時間と、出力トークン間の時間。対話なら両方大事。バッチならスループット重視とか、要求が違う。だから同じ基盤で複数サービスをSLO付きで扱う。

具体的には何を組み合わせるの？

ネットワークスライス、GPU分割、弾性配信、観測性。推論側はTP、PP、DP、Prefill/Decode分離を広域配置でどう扱えるか見る。JOINER UK WANの複数PoPで評価してる。

TPとPPとDPの違い、ざっくりでいい？

TPは層内の重みを分割して頻繁に集団通信。PPは層で分割して段間で活性を渡す。DPはモデル全体の複製で推論時同期なし。P/D分離はprefillとdecodeを分けてKVキャッシュを転送する。

広域だとどれが耐えるの？

論文の報告ではDPは配置に鈍感だけどメモリ制約。PPは近〜中距離の跨拠点には耐える。TPとP/D分離は単一サブネットホップを超えると失敗した。専用AIファブリックなしの汎用WANだから、この境界が大事。

スケールアウトの話もあったよね？

あった。SLO階層ごとに遅延・スループット特性が分かれ、重みストリーミングがスケールアウト時間を短縮した、という報告。ただ数値や詳細条件は提示本文からは確認できないから、そこは一般化しない。

既存手法との比較は？ LLM-Sliceとか？

同一条件での直接比較結果は本文では明示されていない。設計比較としては、LLM-Sliceは無線ネットワークスライスでLLM通信を差別化するけど、推論計算の配置・オーケストレーションが主眼ではない。InferSliceは計算とネットワークをまとめてSLO駆動で選ぶ点が違う。

使える前提は？

テルコが運営する地理分散拠点のGPUとネットワークを共有し、TTFT/TPOTやスループットのSLOを持つ複数サービスを同じ基盤で扱う想定。中央局、地域DC、コア網拠点みたいな場所。汎用WANで専用AIインターコネクトやRDMAは仮定しない。

じゃあ商用網で何でもOKってわけではないんだ。

そう。評価はJOINER上の汎用テルコWANで、特定のモデル・GPU・負荷・ネットワーク条件に依存する。商用テルコ環境、他のWAN、多様なGPU、規制・セキュリティ、コスト、障害時挙動、SLO達成率の定量的一般化は未検証。あとこの話は論文の解説で、実装や追試をしたわけじゃない。

なるほどね。SLOで配置を選ぶって、LLM版の「空いてる店舗に賢く振る」みたいな感じ？

例えとしては近いけど、店舗ごとに厨房の大きさも回線も違うし、料理の途中で材料を運ぶ必要もある。単なる振り分けではない。

広域テルコ網が接続だけでなくAI推論基盤になれる可能性があるってのは大きいね。でもTPとP/D分離はサブネットの壁に甘くない、と。

そう。そこが一番の学び。あと「店舗」の例えはちょっと雑。

じゃあ今日は「サブネットの壁は店舗の壁より厚い」って標語で覚えるね。

標語にするには雑すぎる。

The post 通信事業者の広域網でSLO駆動LLM推論を支えるInferSlice設計 first appeared on 亜美と智也のAI論文解説.

TL;DR

PolyQは、CPU上でLLMを効率的に動かすための量子化フレームワークです。チャネルごとに2/3/4/8/16ビットを割り当て、ユーザーが指定した平均ビット予算に合わせて精度とメモリ使用量を調整します。コンパイラがビット幅の異なるチャネルを同じビット幅のブロックに並べ替え、SIMDやLUTベースのカーネルを生成することで、実行時のオーバーヘッドを抑えつつ、従来手法より2.4～32.1%のパープレキシティ改善を実現しました。

解説

ねえ智也くん、このPolyQって論文、CPUでLLM動かす話だよね？量子化ってよく聞くけど、何が新しいの？

うん。普通の量子化はモデル全体を同じビット数に落とすけど、PolyQはチャネルごとに2～16ビットを割り振れるんだ。

へー、チャネルごとに違うビット数って、めっちゃ細かく調整できそう！でもそれって実行時に遅くなったりしないの？

そこが工夫。コンパイラが異なるビット幅のチャネルを同じ幅のブロックに並べ替えて、SIMDやLUTベースのカーネルを生成するから、オーバーヘッドが抑えられる。

なるほど！それでユーザーが平均ビット予算を指定できるってのも便利だね。メモリと精度のトレードオフを自分で決められるってこと？

そう。例えば平均4ビットに設定すると、重要なチャネルは8ビット、そうでないのは2ビットって感じに自動で配分される。結果、従来の一様量子化よりパープレキシティが2.4～32.1%改善した。

32%も良くなるの？！それはすごい。でもCPUで動かすって、GPUと比べてどのくらい実用的なんだろう？

GPUほど速くはないけど、メモリ制約が厳しい環境や、GPUが使えないサーバーでは有効。特にIntelのCPUでAVX-512を使うと効率がいい。

なるほどね。でもチャネルごとにビット割り当てを決めるのって、結構計算コストかかりそう。そこはどうなの？

そこは確かに課題。割り当ての最適化自体に時間がかかるから、リアルタイム調整には向かない。あと、対応モデルがまだ限られてる。

ふーん…でも「PolyQ」って名前、なんかポリ袋みたいで親しみやすいね。中身詰め込んで軽くする感じ？

……ポリ袋にLLMは入らないよ。

The post CPUでLLMを動かすためのチャネル単位混合精度量子化フレームワーク「PolyQ」 first appeared on 亜美と智也のAI論文解説.

TL;DR

長文RAGの推論ボトルネックであるKVキャッシュの事前計算において、チャンク間の情報フローを考慮したトークン選択で再計算を行う手法を提案。クエリに対するAttention Normを指標とし、推論時と一致するRoPE配置が重要。従来手法より精度を維持しつつ効率化を実現。

解説

ねえねえ、このブログのタイトル、『長文RAGの推論を高速化する情報フローに基づくKV再計算手法』って、すごく難しそうだけど、要するに何が速くなるの？

長い文書を扱うRAGで、推論が遅くなる原因の一つに、KVキャッシュの事前計算があるんだ。全部のトークンの情報を事前に計算しておくとメモリも時間もかかる。

KVキャッシュ…？ あ、モデルが過去の単語を覚えておくためのやつだよね？ それが事前計算で大変ってこと？

そう。特に長い文書を複数のチャンクに分けて処理する時、後のチャンクは前のチャンクの情報を必要とする。従来は各チャンクを独立に計算したり、全部再計算したりで、非効率だった。

なるほど。で、この論文の方法は何が新しいの？

情報フローに基づくKV再計算、だ。チャンク間で実際に情報が流れる重要なトークンだけを選んで、KVキャッシュを再計算する。無駄な計算を省くのが目的だ。

重要なトークンって、どうやって選ぶの？

クエリに対するAttention Normを指標にする。あと、RoPEの配置が推論時と一致していることが重要だと論文で強調されている。位置エンコーディングがずれると精度が落ちるからね。

評価はどうだった？ 本当に速くて精度も落ちないの？

実験結果では、従来のフル再計算や部分的な再計算と比べて、精度をほぼ維持したまま、推論速度を向上させられた。特に長い文書で効果が大きい。

すごい！これって実用上めっちゃ意味あるね。長い資料をAIに読ませて質問する時、もっと早く答えが返ってくるようになるんだ。

そうだな。ただ、限界もある。選択するトークンの閾値の設定や、複雑な推論が必要なタスクでは、選択したトークンだけでは情報が不足する可能性も論文では言及されている。

ふーん、完璧じゃないんだ。でも、KVキャッシュを賢く節約するって発想は面白いな。私もAIとおしゃべりする時、過去の話全部を毎回思い出してたら頭がパンクしちゃうもんね！

…お前の場合は、重要なこともろくに覚えてないから、それでいいんじゃないか。

The post 長文RAGの推論を高速化する情報フローに基づくKV再計算手法 first appeared on 亜美と智也のAI論文解説.

解説

ねえ智也くん、この『LLMの出力の長さを予測する』っていう論文、タイトルが面白そう！AIがどれくらい喋るか、予知しちゃうってこと？

そうだね。ただの予知じゃなくて、LLMを動かすサーバーの無駄をなくして、もっと速く安く動かそうっていう真面目な研究だよ。

無駄？AIっておしゃべりしすぎると疲れちゃうの？

いや、計算リソースの話だ。複数の質問をまとめて処理する時、一番長い回答が終わるまで、短い回答の処理も終われないんだ。これを『バレル効果』って呼ぶんだけど、その間の空き時間を埋める『パディング』という無駄な計算が発生するんだよ。

あー、足の遅い子に合わせてみんなでゴールしなきゃいけないルールみたいな感じ？それは確かに時間がもったいないね！

その通り。だから、事前に出力の長さがわかれば、同じくらいの長さの質問をグループ化して、効率よく処理できる。でも、これまでの予測方法は別のAIモデルを使うから重かったり、精度が悪かったりしたんだ。

じゃあ、この論文はどうやって解決したの？

この論文が提案した『EGTP』は、LLM自身の『脳内（内部状態）』を再利用するんだ。特に『エントロピー』、つまりAIが次の言葉をどれくらい迷っているかに注目して、重要な情報を抜き出すんだよ。

エントロピー……。私が今日のランチをパスタにするかラーメンにするか、めちゃくちゃ迷ってる時のモヤモヤみたいなもの？

……まあ、概念的には近いかな。その『迷い』が大きい部分に、出力の長さを決めるヒントが隠されていることを彼らは突き止めたんだ。さらに、生成の途中で『あとどれくらいで終わるか』を何度も予測し直す『PLP』っていう仕組みも作った。

途中で予測し直すの？それって、話し始めてから『あ、やっぱり長くなるかも！』って気づく感じ？

そう。特に強化学習みたいに、同じ質問でも毎回答えが変わるような場面では、この動的な予測がすごく効くんだ。実験では、従来の方法より予測のズレを30%近くも減らせたらしいよ。

30%も！すごいじゃん！これがあれば、もっとサクサクAIが使えるようになるんだね。

そうだね。ただ、まだ非常に長い文章や、複雑な推論が必要な場合には限界もある。今後はもっと多様なモデルや状況で試していく必要があるだろうね。

なるほど〜。ねえ智也くん、この技術で智也くんの説教があと何分で終わるかも予測してほしいな！

……僕の説教は君が反省するまで終わらないから、予測するだけ無駄だよ。

要点

• LLMの推論時に出力の長さを事前に予測することで、計算資源の無駄（パディング）を減らし、処理効率を向上させる手法を提案。
• 外部の予測モデルを使わず、LLM内部の隠れ状態と「エントロピー（不確実性）」を再利用するEGTP（エントロピー誘導トークンプーリング）を開発。
• 生成の各ステップで残りの長さを動的に更新するPLP（段階的長さ予測）により、ランダム性の高い生成（強化学習のサンプリングなど）にも対応。
• 新たなベンチマーク「ForeLen」において、従来手法より予測誤差（MAE）を29.16%削減し、システム全体の処理能力（スループット）を大幅に改善した。

The post AIの「おしゃべりの長さ」を予知して爆速化！無駄を削る新技術 first appeared on 亜美と智也のAI論文解説.

解説

ねえねえ智也くん！この論文のタイトルにある『スイートスポット』って何？もしかして、AIが一番美味しく感じるお菓子のことかな？

そんなわけないだろ。これはLLMを動かす時に、一番エネルギー効率が良くなる条件のことだ。最近はAIの電気代がバカにならないから、すごく重要な研究なんだよ。

えー、AIってお腹空くの？電気をたくさん食べるんだね。でも、文字をたくさん入れればその分電気がかかるっていう、単純な話じゃないの？

そこがこの論文の面白いところだ。今までは入力と出力の長さに比例して電気が増えると思われていたけど、実際はもっと複雑なんだ。特定の長さの組み合わせで、急に効率が良くなったり悪くなったりするんだよ。

へぇー！じゃあ、どうやってその『効率がいい場所』を見つけるの？

彼らはTransformerの仕組みから、計算量の『FLOPs』と『メモリアクセス』を計算する数式を作ったんだ。FLOPsは計算回数のことで、メモリアクセスはデータの読み書きの量だね。これらを組み合わせることで、消費電力を予測するモデルを作ったんだよ。

ふろっぷす……？なんだか可愛い名前だね！その数式で計算すると、どんなことがわかったの？

実験では、NVIDIAのH100っていう最新のGPUを使って、色んなLLMで試したらしい。その結果、入力が短から中くらいで、出力が中くらいの長さの時に、一番効率が良くなる『スイートスポット』があることがわかったんだ。逆に入力が長すぎたり、出力が極端に短かったりすると、効率がガクンと落ちるんだよ。

えっ、出力が短い方が楽そうなのに、効率が悪いの？不思議だね！

そうなんだ。LLMには『プリフィル』っていう入力を読み込む段階と、『デコード』っていう文字を一つずつ作る段階がある。入力が長いと最初の読み込みにすごくパワーを使うし、出力が短すぎると準備運動だけで終わっちゃうようなものだから、効率が悪くなるんだよ。

なるほど！準備運動ばっかりして走らないのはもったいないもんね。この研究が進むと、どうなるの？

例えば、AIに質問する時に長すぎる文章を要約して短くしてから渡したり、効率の良い長さで回答を打ち切るように設定したりできる。そうすれば、同じ電気代で何倍も多くの処理ができるようになるはずだ。地球にも優しいしね。

すごい！じゃあ、このモデルを使えば完璧に省エネできるんだね！

いや、まだ課題はある。今回は特定のGPUやソフトで測った数値だから、環境が変わるとスイートスポットの場所も変わる可能性があるんだ。今後はもっと色んな環境で試す必要があるだろうね。

そっかぁ。じゃあ私も、智也くんへの質問を『スイートスポット』に合わせて短くするね！えーっと……『お腹すいた、ご飯行こう！』。これなら効率的でしょ？

それはただのわがままだろ！……まあ、俺もお腹すいたし、行くか。

要点

• LLMの推論におけるエネルギー消費は、入力と出力の長さに対して単純な比例関係ではなく、複雑な非線形性を持つ。
• Transformerの計算量（FLOPs）とメモリアクセス量に基づいた、高精度なエネルギー予測モデルを開発した。
• エネルギー効率が最大化される「スイートスポット」は、短〜中程度の入力と中程度の出力の組み合わせで発生する。
• 提案モデルは、NVIDIA H100 GPUを用いた実験で平均誤差1.79%という高い予測精度を達成した。
• この知見を利用して入力を適切に短縮したりバッチ処理を工夫したりすることで、消費電力を大幅に削減できる可能性がある。

The post AIの「省エネのツボ」を発見！電気代を劇的に減らす新理論 first appeared on 亜美と智也のAI論文解説.

解説

ねえねえ智也くん！この『DSB: Dynamic Sliding Block』っていう論文、タイトルがなんだかパズルゲームみたいで面白そう！これってAIがブロックで遊ぶ話なの？

遊びじゃないよ。これは拡散モデルっていうタイプのAIを、もっと効率よく動かすための研究だね。亜美、AIが文章を作る時に『ブロック』単位で処理することがあるのは知ってる？

うーん、レゴブロックみたいな感じ？一気に全部作るんじゃなくて、塊ごとに作るってことかな？

まあ、イメージは近いかな。拡散モデルのAIは、バラバラのノイズから少しずつ言葉を復元していくんだけど、全部一度にやると支離滅裂になりやすいんだ。だから、左から順番に一定の範囲（ブロック）ずつ確定させていく手法が一般的だったんだよ。

なるほど！順番にやれば安心だもんね。でも、それの何が問題なの？

その『固定されたブロック』が問題なんだ。例えば、今のブロックの中にまだ確信が持てない難しい単語があっても、ルールだからって無理やり決めちゃうことがある。逆に、次のブロックにすごく簡単な単語があっても、順番が来るまで待たなきゃいけない。これって非効率だろ？

あー、テストで難しい問題に詰まってるのに、次の簡単な問題に進んじゃダメって言われてるみたいな感じだ！それはイライラしちゃうね。

そう、その通り。そこでこの論文が提案したのが『DSB（動的スライディングブロック）』だ。AIが自信のあるところを見極めて、ブロックの大きさを変えたり、スルスルと先に進めたりするんだよ。

すごーい！状況に合わせて柔軟に対応するんだね。でも、ブロックが勝手に動いちゃったら、AIが混乱したりしないの？

鋭いね。ブロックが動くと、過去の計算結果を再利用する『KVキャッシュ』っていう仕組みがうまく働かなくなるんだ。計算が不安定になっちゃう。だから、この論文では『DSB Cache』っていう専用のキャッシュ術も開発したんだよ。

けーぶい……きゃっしゅ？

簡単に言うと、一度計算したことを覚えておくメモ帳みたいなものかな。DSB Cacheでは、ブロックのすぐ前に『プレフィックスウィンドウ』っていう予備の領域を作って、ブロックが動いても計算がスムーズに繋がるように工夫してるんだ。

へぇ〜、メモ帳の使い方も工夫してるんだね！それで、実際にやってみたらどうだったの？

実験の結果、従来のやり方よりも文章の質が上がったし、生成スピードも速くなった。しかも、AIを新しく学習し直す必要がないから、今あるモデルにすぐ使えるのが大きな強みだね。

追加の勉強なしで頭が良くなるなんて、私もその機能が欲しいな……。これからは、どんなことに使われるようになりそうなの？

より長文を速く、正確に作る必要がある場面で役立つはずだよ。ただ、まだ完璧じゃない。ブロックの動かし方の最適化とか、もっと複雑なタスクへの対応とか、研究の余地はまだあるね。

そっかぁ。でも、ブロックがスライドするなら、そのうちAIが机から滑り落ちてどっか行っちゃったりしない？

……それは物理的なブロックじゃないから大丈夫だよ。少しは真面目に考えてくれ。

要点

• 拡散モデルベースの言語モデル（dLLM）において、推論の品質と速度を向上させる新しいスケジューリング手法「DSB」を提案。
• 従来の固定ブロック方式では、確信度が低い単語を無理に生成したり、逆に確信度が高い単語の生成を後回しにしたりする非効率さがあった。
• DSB（Dynamic Sliding Block）は、AIの確信度や文脈の難易度に応じて、処理するブロックの範囲を動的に変化させ、スライドさせる。
• DSBに最適化されたキャッシュ機構「DSB Cache」を導入し、ブロックが動く際に発生する計算の不安定さを解消し、高速化を実現。
• 追加の学習が不要（training-free）でありながら、複数のモデルとベンチマークで生成品質と推論速度の両方を改善することに成功した。

The post AIの『思考の区切り』を自由自在に！最新AIを爆速＆高精度にする魔法のブロック術 first appeared on 亜美と智也のAI論文解説.

ねえねえ、智也くん！これ、『GPU内部のスケジューリングとリソース共有による分離型多段階MLLM推論の実現』って論文、すごく難しそうなタイトルだけど、何か面白そうなことやってるの？

ああ、この論文か。要するに、画像や動画を理解できるAIモデルを、もっと速く、たくさん処理できるようにするための仕組みについてだよ。今のシステムには大きな問題点があってね。

問題点？AIが動画を理解するのって、ただ文章を書くよりずっと大変そうだけど、具体的に何が問題なの？

そうだな。まず、動画をAIが処理できる形に変換する「デコード」という作業がとても重い。これが最初の応答までの時間を大きく遅らせている。それに、デコードの後にも「視覚エンコーダ」という別の重い処理があって、これがメインの文章生成を邪魔してしまうんだ。

えー、じゃあ動画を説明してくれるAIって、実はすごく待たされちゃうってこと？

その通り。今のシステムは二つのやり方に分かれていて、一つは全部を一つのGPUでやる「Monolithic」方式。これは全体の処理能力は高いけど、視覚エンコーダが邪魔をして文章生成が頻繁に止まってしまう。

止まっちゃうのは困るね。もう一つの方法は？

もう一つは、デコード、エンコード、文章生成をそれぞれ別のGPUでやる「Split」方式。これなら邪魔はされないけど、GPUを分け合うからリソースが無駄になって、全体として処理できる量が減ってしまうんだ。

あー、どっちも一長一短って感じ？じゃあこの論文の人たちは、どうやってこのジレンマを解決したの？

彼らは二つの新しい技術を開発した。一つ目が「FlashCodec」。これは、一本の動画を複数のGPUでバラバラにデコードしちゃうんだ。例えば4つのGPUがあれば、動画を4分割して同時にデコードする。そうすれば、一人でデコードするよりずっと速く終わる。

わあ、それは賢い！みんなで協力するってことだね。で、二つ目は？

二つ目が「UnifiedServe」。これは、デコード、エンコード、文章生成という3つの段階を、論理的には別々の仕事として扱いながら、物理的には全部のGPUを一つの大きなリソースプールとして使うんだ。文章生成が最優先で、その合間にエンコードの仕事をはさみこむイメージだね。

へえ…つまり、仕事は分業するけど、使う道具（GPU）はみんなで共有するってこと？それで邪魔もされないし、無駄もなくなるの？

そういうこと。この二つを組み合わせた彼らのシステムは、実験では既存のシステムより最大4.4倍も多くのリクエストを処理できて、しかも応答も速くなった。待ち時間と処理能力、両方で改善に成功したんだ。

すごい！これが実用化されたら、動画を説明してくれるAIサービスもっと快適になりそう！

そうだね。ただ、課題も残っている。例えば、全ての動画が均等に分割できるわけではないし、GPUの種類によってデコードエンジンの数も違う。もっと複雑な動画や、異なる種類のGPUが混在する環境でもうまく動くようにするのは、今後の研究課題だ。

なるほど…。でも、この考え方って、動画処理だけじゃなくて、他の重い処理を組み合わせるAIにも応用できそうじゃない？

鋭いね。その通りだ。音声や3Dデータなど、様々なモダリティを組み合わせるマルチモーダルAI全般で、似たような問題が起こるはずだ。この論文の「論理的に分離、物理的に共有」という考え方は、そういう分野でも役立つ可能性が高いと思う。

ふーん、AIの世界も「協力」と「共有」が大事なんだね。人間社会みたい！

…まあ、そう言えなくもないけど、比喩が安直すぎるよ。

要点

マルチモーダル大規模言語モデル（MLLM）の推論は、動画デコード、視覚エンコード、LLM推論の3段階からなるが、これらがボトルネックとなっている。

既存の推論システムには、全ての段階を1つのGPUで実行する「Monolithic」方式と、段階ごとにGPUを分離する「Split」方式があるが、それぞれ待ち時間とスループットにトレードオフがある。

本論文では、動画デコードを高速化する「FlashCodec」と、段階を論理的に分離しながらGPUリソースを物理的に共有する「UnifiedServe」という2つの技術を提案している。

FlashCodecは、1本の動画を複数のGPUやGPU内の複数のデコードエンジンで協調的にデコードすることで、待ち時間を大幅に削減する。

UnifiedServeは、3つの段階を非同期に実行しながらもGPUリソースを共有するスケジューリング方式で、段階間の干渉を減らしつつリソース利用率を最大化する。

提案システムは、既存の最先端システムと比べて最大3.0倍のリクエストを処理でき、スループットは最大4.4倍向上した。

参考論文: http://arxiv.org/abs/2512.17574v1

The post 動画AIの遅延解消！複数GPUで“協力デコード”する画期的な方法 first appeared on 亜美と智也のAI論文解説.

ねえねえ、智也くん！これ、『MEPIC: Memory Efficient Position Independent Caching for LLM Serving』って論文、すごく難しそうなタイトルだけど、何かすごいことやってるの？

ああ、亜美さん。これはLLMをサービスとして提供するときの、メモリ効率を劇的に改善する技術についての論文だよ。簡単に言うと、AIが同じ文章を何度も処理するときに、無駄な計算やメモリ使用を減らす方法だ。

同じ文章を何度も処理する？例えばどんな時？

例えば、研究アシスタントAIが同じ論文の一部を何度も参照したり、コーディングAIが同じライブラリの説明を何度も読んだりする時だ。RAGって仕組みもそうだね。多くのユーザーが同じ情報を求めるから、サーバーには似たようなリクエストがたくさん来るんだ。

なるほど！でも、それって良いことじゃない？一度計算した結果を覚えておけばいいんでしょ？

それが難しいんだ。今までの技術には限界があった。『プレフィックスキャッシュ』は文章の最初の部分が完全に一致する時しか再利用できない。『位置独立キャッシュ（PIC）』は文章の塊（チャンク）をどこにでも再利用できるけど…

けど？

けど、各リクエストごとに微妙に調整が必要で、結局メモリ上では別々のデータとして保存されちゃうんだ。だから、100人のユーザーが同じWikipediaの記事を参照しても、メモリ上には100個のコピーができてしまう。これがHBMっていう高価で容量の少ない高速メモリを圧迫する原因なんだ。

えー！それ超もったいない！で、このMEPICってのはそれを解決するの？

そう。MEPICは3つの重要な工夫をしている。まず、文章の塊をメモリのページ単位にきっちり合わせる。次に、再計算をトークン単位じゃなくてブロック単位で行う。最後に、位置情報をKVキャッシュに焼き込まず、計算する時に後から付けるようにするんだ。

ちょっと待って、位置情報を後から付けるってどういうこと？それで大丈夫なの？

大丈夫だよ。RoPE（ロータリーポジショナルエンべディング）っていう位置を表す技術があるんだけど、MEPICはこれをアテンションの計算カーネルの中に融合させちゃうんだ。だから、キャッシュ自体は位置情報を持たない『純粋な』状態で保存できる。これが共有可能になる鍵なんだ。

ふーん…で、実際どうなったの？実験結果は？

既存の最先端PIC技術と比べて、HBMの使用量を最大2倍削減できた。特に長いプロンプトを扱う時は5倍以上も節約できた。しかも、応答時間や精度は変わらないか、むしろ良くなった場合もあった。モデル自体をいじらなくていいから、既存のサービスに組み込みやすいのも利点だ。

すごい！これが実用化されたら、AIサービスのコストが下がったり、もっと多くの人に同時にサービス提供できたりするね！

そうだね。特にRAGを使ったサービスや、コーディングアシスタントの応答速度とコストに大きな影響を与えるだろう。将来は、もっと大規模なドキュメントセットを扱ったり、動的に変化するコンテンツへの対応も課題として残っているけど。

なるほどー。でもさ、智也くん。これって要するに、AIの『記憶』をみんなで共有する賢い図書館司書みたいなものを作ったってこと？

…まあ、そう言えなくもないけど、その比喩はちょっと安直だな。もっとシステムレベルでの精巧な設計が…

はいはい、難しい話はおいといて。とにかく、AIがもっと速くて安くてエコになるってことでしょ？それって素敵じゃん！

…まあ、そういうことだな。君の解釈でいいよ。

要点

LLMサービングにおいて、長いプロンプト履歴（RAGやコーディングエージェントなど）を繰り返し処理する際、KVキャッシュのメモリ使用量が大きな問題となる。

既存のプレフィックスキャッシュは先頭部分の一致に限定され、位置独立キャッシュ（PIC）はチャンクの再利用を可能にするが、メモリ内での重複が発生し、HBM（高速メモリ）の節約効果が限定的だった。

MEPICは、チャンクのKV表現をページ単位で整列させ、ブロックレベルでの選択的再計算とRoPE融合により、位置情報から独立した共有可能なKVブロックを作成する。

これにより、同じチャンクを参照する複数のリクエスト間でHBM内のKVキャッシュを共有でき、HBM使用量を最大2倍（長いプロンプトでは5倍以上）削減できる。

既存のvLLMシステムに統合可能で、モデル自体の変更を必要とせず、精度やレイテンシを維持しながら大幅なメモリ効率化を実現する。

参考論文: http://arxiv.org/abs/2512.16822v1

The post AIの無駄遣いをストップ！同じ知識をみんなで共有する画期的な仕組み first appeared on 亜美と智也のAI論文解説.

ねえねえ、智也くん！これ、『Dynamic Rebatching for Efficient Early-Exit Inference with DREX』って論文、すごく難しそうなタイトルだけど、何か面白そうなことやってるの？

ああ、亜美さん。これは、AIの推論、特に文章を生成するときのスピードを上げるための、とても重要な研究だよ。簡単に言うと、『賢いバッチ処理』の仕組みを作ったんだ。

バッチ処理？それって、料理をまとめて作るみたいなやつ？

うん、似てるね。複数のユーザーのリクエストを一度にまとめて処理すると、コンピュータの資源を効率的に使えるんだ。でも、ここに『Early-Exit』っていう別の技術を組み合わせると、大きな問題が起きる。

Early-Exit？それって何？

例えば、AIが『今日は晴れです』って文章を生成するとき、『今日』『は』『晴れ』『です』って単語（トークン）を順番に作るよね。Early-Exitは、『は』や『です』みたいに簡単な単語は、AIモデルの全部の層を使わずに、途中の層でさっさと生成しちゃおう、っていうアイデアなんだ。

なるほど！全部計算しなくていいから速くなるんだ！

そう。でも問題は、バッチ処理と組み合わせたとき。10個のリクエストをまとめて処理してて、そのうち3個だけが『簡単な単語だからここで終了！』ってなったら、どうする？

えっと…終了した3個は結果を返して、残り7個はそのまま計算続ける？

それが理想なんだけど、今までのシステムはバッチをバラバラにできなかったんだ。だから、『バッチ全員が終了するまで待つ』か、『1人でも終了したい人がいたら全員終了させる』か、みたいな無理やりな決め方をしてた。

それじゃあ、せっかく終了できる人が待たされたり、まだ計算が必要な人が強制終了させられたりしちゃうね。

その通り。論文では『不本意な継続』と『不本意な終了』って呼んでる。後者は特に、生成される文章の品質がガタ落ちする深刻な問題なんだ。

うわ、それは困る。で、この論文のDREXってのはそれを解決するの？

そう。DREXの核が『Dynamic Rebatching』だ。早期終了の判断ポイントで、バッチを動的に仕分けし直すんだ。終了組はすぐに結果を返す。継続組は一旦バッファに待機させて、ある程度溜まったら新しいバッチを組んで、深い層に送り込む。

すごい！まるで高速道路のランプみたい！でも、仕分けたりバッチを組み直したりするのに、余計な時間かからないの？

鋭いね。そこがDREXのすごいところ。まず、データを物理的にコピーするんじゃなくて、インデックス（目次）を書き換えるだけの『コピーフリー』バッファを使って、オーバーヘッドをほぼゼロに近づけてる。

目次を書き換えるだけ…？すごい技だ！

それだけじゃない。『このタイミングでバッチを分けたら、得するのか損するのか』を、リクエストの状態やコンピュータの負荷から分析的に予測するスケジューラも持ってる。損するなら無理に分けない、って賢い判断ができるんだ。

へえ〜！で、実際に速くなったの？実験結果はどうなったの？

既存の方法と比べて、スループット、つまり単位時間あたりに処理できる量が2%から12%向上した。しかも、一番重要な『不本意な終了』を完全にゼロにできた。文章の品質を保ちながら、確実に速くできることが証明されたんだ。

すごい成果だね！これが実用化されたら、AIのサービスもっと速く、安く使えるようになるかも？

そうだね。クラウドでAIを提供する会社は、同じハードウェアでより多くのユーザーをさばけるようになる。ユーザーは待ち時間が減る。環境負荷も減らせるかもしれない。すごく意義のある研究だと思う。

でも、何か課題とか、これからやることってあるの？

うん。例えば、複数のGPUにまたがって計算する超大規模モデルへの適用は、まだ完全には検証されてない。あと、Early-Exitの判断そのものが間違ってしまう可能性は、この研究の範囲外だけど、現実にはある問題だ。DREXのようなシステムが普及すれば、今度はEarly-Exitの判断をより正確にする研究もさらに進むだろうね。

ふむふむ…つまり、DREXは、Early-Exitという素晴らしいアイデアを、現実のシステムでちゃんと働かせるための『最後のピース』みたいなものなんだね！

…まさにその通りだ。うまくまとめるね、亜美さん。

えへへ。じゃあ、この技術が使われたら、私がAIに『今日の天気は？』って聞いたら、もっと一瞬で『晴れ』って返ってくるってこと？

…『晴れ』は確かに簡単な単語だから、Early-Exitの対象かもね。でも、君が聞くのはいつも『晴れ』じゃなくて、『今日の天気は？傘いる？洗濯物外に干せる？』みたいに長いから、全部が速くなるかは微妙だよ。

あ、そっか！智也くん、そういうとこマジメすぎるって言われるよ！

要点

大規模言語モデルの推論を高速化する技術「Early-Exit（早期終了）」は、簡単なトークンはモデルの一部の層だけを使って生成することで計算コストを削減する。

しかし、複数のリクエストをまとめて処理する「バッチ処理」とEarly-Exitを組み合わせると、バッチ内の一部のリクエストだけが早期終了の条件を満たす「分割決定」が発生し、効率化が難しくなる。

既存の手法は、バッチ全体で一括して早期終了を判断するため、本来終了できるリクエストが無駄に計算を続ける「不本意な継続」や、終了すべきでないリクエストが強制的に終了させられる「不本意な終了」が発生し、効率や出力品質が低下する。

本論文では「Dynamic Rebatching（動的リバッチング）」を提案。早期終了ポイントでバッチを動的に再編成し、各リクエストが最適な実行パスを取れるようにする。

提案システム「DREX」は、物理的なデータ移動を伴わないコピーフリーのバッファと、リバッチングの採算性を分析的に予測するスケジューラを実装し、オーバーヘッドを最小化する。

DREXは「不本意な終了」を完全に排除しつつ、スループットを2〜12%向上させ、出力品質を維持する。また、スキップされた層のKVキャッシュを効率的に扱うことで、メモリ使用量も最大18.3%削減する。

参考論文: http://arxiv.org/abs/2512.15705v1

The post AIのスピード革命！「賢い仕分け」で文章生成がもっと速く、賢くなる first appeared on 亜美と智也のAI論文解説.

ねえねえ、智也くん！これ、『xGR: Efficient Generative Recommendation Serving at Scale』って論文、なんかすごそうなタイトルだね！生成型推薦って何？なんで効率化が必要なの？

ああ、この論文か。生成型推薦（GR）っていうのは、最近注目されてる新しい推薦システムの形なんだ。簡単に言うと、ユーザーが今まで見たり買ったりしたアイテムの長いリスト（履歴）を、LLMに読み込ませて、次におすすめしたいアイテムを直接「生成」させる方式なんだ。

ふーん、LLMが推薦もするんだ！でも、それって普通のLLMの使い方と何が違うの？

そこが重要なポイントだ。普通のチャットボットは短い質問に対して長い返答を生成するだろ？でもGRは逆なんだ。ユーザーの行動履歴って、何百、何千ものアイテムIDになるから、入力（プロンプト）がすごく長い。でも出力は「次に買うアイテムはこれです」っていう短い固定長なんだ。

なるほど、入力が長くて出力が短いんだ。それだけ？

それだけじゃない。推薦は1個だけじゃなくて、複数の候補をランキングして出したいだろ？そのために「ビームサーチ」っていう技術を使うんだけど、GRでは推薦の精度と多様性を出すために、このビームサーチの規模がめちゃくちゃ大きいんだ。ビーム幅が128とか512とか。

ビームサーチ？幅が128？なんか難しそう…。

そうだな…例えば、次に来る単語を予測するゲームを128人で同時にやるイメージだ。それぞれが少しずつ違う予測をして、その中から毎回一番良さそうな128人の予測を残していく。それを繰り返すんだ。でも、この128人全員が、最初に与えられた長い物語（ユーザー履歴）を毎回読み直さなきゃいけないとしたら、すごく無駄だよね？

あー！確かに！みんな同じ話を何度も読むのは時間の無駄だね。それで効率が悪くなるの？

その通り。これが論文で言う最初の課題だ。既存のシステムは、この128本のビーム（経路）を独立して扱っちゃうから、同じ長いプロンプトの計算結果（KVキャッシュって呼ぶ）を128回もメモリから読み直すことになる。それに、ビームが分岐する時にメモリのコピーが大量発生したり、128×128=16384個もの候補から毎回トップ128を選ぶソート処理も重たい。しかも、オンライン推薦は遅延にすごく敏感で、200ミリ秒以内に答えを返さなきゃいけないんだ。

うわ、大変！200ミリ秒ってあっという間だよ！で、このxGRってシステムはどうやって解決するの？

主に3つの工夫がある。まず「xAttention」。長いプロンプト部分のKVキャッシュを分離して、ビームが共通で使えるようにするんだ。そうすれば、128回読み直す必要がなくなる。計算も段階的に割り振って効率化する。

おー、賢い！で、2つ目は？

2つ目は「xBeam」。ビームサーチのソートとフィルタリングを速くする。全部の候補を最後までソートしなくても、早い段階で打ち切っても大丈夫な場合があるから、そこで計算をやめる「早期ソート終了」。あと、商品IDの組み合わせで、実際には存在しない無効な候補がたくさんできるから、マスクを使って最初から除外する「アイテムフィルタリング」をする。データ構造も再利用して無駄を減らす。

なるほど、無駄な計算をそもそもしないようにするんだね！3つ目は？

3つ目は「xSchedule」。システム全体のパイプラインを見直すんだ。ホスト（CPU）でする準備と、デバイス（GPUとか）でする計算をうまく重ね合わせて、待ち時間を減らす「オーバーラップ」。それから、複数のストリームを使って並列に処理する「マルチストリーム並列性」を活用する。

すごい…全部組み合わせたんだ。で、実際に速くなったの？

実験結果によると、厳しいレイテンシ制限を守りながら、従来の最先端システムと比べて少なくとも3.49倍の処理能力（スループット）を達成した。実際のサービスでも3ヶ月動いていて、数億ユーザーに、ピーク時でも200ミリ秒以内で推薦を返せているらしい。

すごい実用的な研究だね！これが広まると、私たちが使う動画サイトやショッピングサイトの推薦が、もっとパーソナライズされて、しかも速くなるってこと？

そうだね。生成型推薦そのものが、従来のシステムよりユーザーの長い履歴を深く理解できる可能性がある。でも、そのためにはxGRのような効率的な推論システムが不可欠なんだ。遅かったら実用にならないから。

未来は明るいね！でも、何か課題とか限界はあるの？

もちろんある。この研究は主に推論の効率化に焦点を当てている。モデル自体の精度向上や、どうやってユーザーの複雑な意図をより正確に捉えるか、っていう根本的な課題は別問題だ。あと、ビームサーチの規模がさらに大きくなった時や、モデルパラメータがもっと増えた時にも同じように効率的かは、また検証が必要だと思う。

ふむふむ…。じゃあ、これからはAIの推薦がどんどん賢くなって、私が次に食べたいお菓子まで当ててくれたりするのかな？

…その前に、お菓子の食べ過ぎを推薦しないようにするアルゴリズムの研究が必要なんじゃないか？

えー！そんなのいらないよ！智也くんはそういうとこ、つまんないんだから！

要点

生成型推薦システム（GR）は、大規模言語モデル（LLM）を活用してユーザーの長い行動履歴を理解し、次に推薦するアイテムを直接生成する新しいアプローチである。

従来の推薦システムとは異なり、GRは「長いプロンプト（ユーザー履歴）に対して短い固定長の出力（推薦アイテム）」を生成するという独特のワークロード特性を持つ。

GRの推論では、推薦の精度と多様性を確保するために大規模なビームサーチ（例：ビーム幅128）が必須であり、これが計算コストとメモリアクセスのボトルネックとなっている。

既存のLLM推論システムはGRのワークロードに最適化されておらず、特にビームサーチにおける共有プロンプト部分のKVキャッシュの冗長なロードや、大量の候補ソート処理が非効率である。

本論文では、GRに特化した推論システム「xGR」を提案している。xGRは、KVキャッシュの分離と段階的計算による効率化（xAttention）、早期ソート終了とマスクベースのアイテムフィルタリング（xBeam）、ホスト-デバイス間のオーバーラップとマルチストリーム並列性の活用（xSchedule）という3つの主要な最適化を実装している。

実世界の推薦サービスデータセットを用いた実験では、xGRは厳しいレイテンシ制約下で、最先端のベースラインと比較して少なくとも3.49倍のスループットを達成した。

xGRは既に実際のサービスに3ヶ月間デプロイされ、数億ユーザーにサービスを提供し、ピーク時でもP99レイテンシを200ミリ秒以内に維持している。

参考論文: http://arxiv.org/abs/2512.11529v1

The post AIがあなたの好みを先読みする！「生成型推薦」を爆速で実現する技術の秘密 first appeared on 亜美と智也のAI論文解説.