TL;DREMBL AI LI…
TL;DR
RACは、エッジとクラウドに分割されたLLM推論において、送受信される中間状態（アクティベーション）を圧縮する手法です。過去のプロンプトや同一ラウンド内の状態、直前のデコードステップを参照状態として利用し、残差を量子化することで通信量を削減します。TTFTとTPOTを最大2.7倍以上改善しつつ、タスク品質の低下を抑えます。
解説
ねえ智也くん、このRACって論文、タイトル見ただけで難しそうなんだけど…。分割LLM推論って何？
ああ、大きなLLMをエッジとクラウドに分けて動かすことだよ。エッジで一部の層を、クラウドで残りを計算する感じ。
へー、でもなんでそんなことするの？全部クラウドでやればよくない？
プライバシーとか遅延の面で有利なんだ。でも、エッジとクラウドの間で中間状態を送る必要があって、そこがボトルネックになる。
なるほど、通信が遅いってことか。で、RACはそれをどう解決するの？
中間状態を圧縮するんだ。具体的には、過去のプロンプトや同じラウンドの状態、直前のデコードステップを参照して、残差だけを量子化して送る。
残差？つまり、前の状態との差分だけ送るってこと？
そう。完全な状態を送るより、差分の方が情報量が少ないからね。それに、参照状態をうまく使うことで、量子化の精度も保てる。
すごい！でも、それって品質が落ちたりしないの？
実験では、タスク品質の低下を抑えつつ、TTFTとTPOTを最大2.7倍以上改善できたって報告されてる。
TTFTとTPOTって何？
最初のトークンが出るまでの時間と、その後のトークン生成の速度だよ。要するに、応答が速くなるってこと。
なるほどね。でも、参照状態ってどうやって選ぶの？全部使うの？
論文では、過去のプロンプト、同一ラウンド内の状態、直前のデコードステップの3種類を使うみたい。それぞれの利点を組み合わせてる。
ふーん、でもそれってメモリとか大変じゃない？
確かに、参照状態を保持するための追加メモリは必要だね。でも、通信コストの削減とトレードオフで、全体的には有利ってこと。
なるほど。でも、この手法ってどんなタスクで試したの？
主にテキスト生成系のタスクだよ。翻訳とか要約とか。品質はほとんど落ちなかったらしい。
すごいね！でも、限界とかはないの？
うーん、参照状態の選び方によっては効果が薄い場合もあるし、モデルが大きくなると圧縮率が下がる可能性もある。あと、エッジ側の計算能力が低いと、圧縮自体がボトルネックになるかも。
なるほどね。でも、通信量を減らせるのは大きいよね。これでエッジAIももっと実用的になるかもね。
そうだね。特にモバイルとかIoTデバイスでの応用が期待できる。
でもさ、参照状態って「過去のプロンプト」って言うけど、もしプロンプトが長すぎたら逆に重くならない？
それは良い指摘だね。実際、プロンプトが長いと参照状態の管理コストが増えるから、そこは今後の課題かもしれない。
ふふ、じゃあRACは「ラク」に通信を減らせるってこと？
…そのダジャレはやめてくれ。