異なる会社のAIモデルを一つのチームとして組み合わせて使うと、同じ文書を何度も読む無駄が生じる。前段のモデルが長い資料を読んで整理し引き渡すと、受け取ったモデルはその資料を最初から読み直す。HeteroFoldはこの読み直しをなくす。前段のモデルが読みながら内部に作り出しておいた中間計算を、後段のモデルがそのまま引き継いで使うのだ。
まず成果から。32Kトークンの文脈において、Llama-3.1-8Bが読んだ内容をMinistral-3-14Bへ引き渡すとき、受け取る側が丸ごと読み直す方式よりも10倍以上速かった。複数のエージェントが対話しながら意思決定を下すベンチマークでは、テキストでやり取りする方式と互角の正確さを出した。トークナイザー(文章をトークンという小さな断片に分割する方式)も異なり層の数も異なる、系列がまったく違うモデル同士でこれが成立したという点が核心だ。
ところで、この研究で最も注目すべき箇所は速度ではない。キャッシュを元のものにより近く復元した手法のほうが、かえって悪い結果になったという点である。ここから解きほぐしていこう。
LLMはプロンプトを読むとき、トークンごとにキー・バリュー(KV)と呼ばれるベクトルを計算して保存しておく。続けて答えを生成する際に、前の部分を再計算しないためのメモ帳だ。このメモ帳がKVキャッシュ、受け取った文章を最初から最後まで一度ざっと読んでメモ帳を埋める過程がプリフィル(prefill)である。
問題は、送った側がすでに同じプリフィルを終えているという点だ。そのメモ帳を捨て、受け取る側が同じ文章をもう一度ざっと読む。文脈が長いほどこの重複は急速に膨らむ。マルチエージェントシステムが役割ごとに異なるモデルを使う昨今(論文では、解答・評価・統合に系列の異なるモデルを配置するX-MASを例に挙げている)、段階を引き継ぐたびにこのコストを再び払うことになる。
同じ系列のモデル同士ならそれでいい。系列が異なると三か所が食い違う。トークナイザーが異なるため同じ文章を別の断片に分割し、層の数が異なるため何番目の層の情報をどこに合わせればよいかが曖昧で、KVの数値分布や構造そのものが異なる。
翻訳者が二人で同じ本を分担して読む状況を思い浮かべればいい。一人が書き留めた注釈を引き渡そうとしても、表記法もノートのページ付けの仕方も速記の方式も違うので、そのままでは使えない。メモ帳を引き渡すには、受け取る人の方式へ翻訳することから始めなければならない。
ここで自然な考えが浮かぶ。送った側のメモ帳を、受け取る側のメモ帳にできるだけ近い形へ変えてやればいいのではないか。数字が近いほど良い翻訳ではないか、と。
そうではなかった。既存手法であるKV Ridgeは、HeteroFoldよりキャッシュをより近く復元しておきながら、肝心の受け取る側のアテンション(attention、モデルが今どのトークンに注目するかを決める仕組み)を壊してしまった。数字はより近いのに結果はより悪かったのだ。
理由はこうだ。メモ帳の数字そのものは目的ではない。その数字が受け取る側で生み出す以降の計算こそが本当の目的である。数字を平均的に近づけることに注力すると、受け取るモデルが実際に使う方式とは食い違いかねない。そこでHeteroFoldは、復元誤差を減らす代わりに、受け取る側がそのキャッシュで生み出すアテンションと出力を基準にして変換を合わせる。この方向転換がこの論文の中心である。
変換は四段階だ。
トークンを合わせる。トークナイザーが異なれば同じ文字列も違うふうに区切られる。論文の例では「unbelievable」を一方は一つのトークンにまとめるが、もう一方は「unbel / iev / able」に分割する。そこでトークン番号を1:1で合わせるのではなく、両者が共有する文字境界を基準に合わせる。受け取る側の境界にぴったり合う状態がなければ、直前の共有境界の状態を使う。重要なのは、重なる断片を平均しないことだ。モデルは文章を先頭から順に読んでいくので、「ここまで読んだ状態」を潰して平均すると意味が壊れてしまう。
層を合わせる。受け取る側が必要とする情報が、送った側の複数の層に散らばっている。そこで受け取る層一つに送った層一つだけを対応させるのではなく、深さの比率で合わせた地点の周辺にある三つの層を一緒に持ってくる。一つの層だけを使うときより、隣り合う三つの層をまとめたときのほうが受け取る側の予測が正確だった。
色を合わせる(Recolor)。トークンごとの誤差だけを減らすと、全体の分布がずれたままでアテンションが狂う。そこで受け取る側の特徴の平均と散らばりの度合い(共分散)を合わせる。写真の色補正と同じだ。トーンの異なる写真を、受け取る側のトーンに合わせて差し替える。
出力基準の補正。色まで合わせても、アテンションのパターンと最終的な出力が完全に同じになるわけではない。残った誤差を、受け取る側の実際のクエリ(query、アテンションにおいて「今何を探しているか」を表すベクトル)・アテンション・バリュー・出力を基準にして埋める。このとき全体を作り直すのではなく、重要な方向をいくつかだけ選んで足す軽い補正表を使う(低ランク、無数の数字をすべて変える代わりに、核となる方向をいくつかだけで直す方式)。キー補正とバリュー補正を分けて置いたのが核心で、出力の差は「どこに注目するか」の変化と「引き寄せてきた値」の変化に分かれ、前者はキーが、後者はバリューが担う。
最後はフォールディング(folding)だ。上で合わせた補正をそれぞれ別に置かず、最初の固定変換式一つにあらかじめ折り込む。だから実際に使うときは、受け取る層・役割ごとに固定変換を一つ通すだけでよく、補正用の追加ニューラルネットワークも、受け取る側の再プリフィルも要らない。
一つはっきりさせておこう。この過程で二つのモデルの重みはまったく触らない。新たに合わせるのはモデルではなく、キャッシュを変える変換表一つだけである。その変換表は少量のデータでオフラインで一度合わせておけば、以降はモデルをそのままにしてその表を通すだけだ。
層合わせは特徴を平らに伸ばして混ぜるので、アテンションを分担する枝(ヘッド)の数が異なっても交差マッピングが成り立つ。色合わせは二つの特徴空間をホワイトニング(元の大きさ・相関を除去)したうえでプロクラステス整列(回転で二つの集合を重ねる方法)で合わせ、受け取る側の共分散・平均を再び被せる。フォールディングが折り込む固定変換式は、線形変換に移動を加えたアフィン写像(affine map)である。
実験はLlama-3.1-8B、Qwen3-4B、Ministral-3-14Bの三つを凍結して(重みを固定して)使い、三者間の向きのある転送六通りをすべて計測した。課題は長い文脈のQA四種、短い文脈のQA五種、そして複数のエージェントがラウンドを重ねながら対話するHiddenBenchである。
まずトークン合わせがなぜ決定的なのか。トークン番号だけを無理やり合わせた手法は事実上崩壊した。二者択一問題では50%前後、でたらめに当てても出る水準で、数字の答えを要求するGSM8Kでは全般的に非常に低かった。ところがトークン合わせ(前述の1段階)を付けると多くの区間が一気に息を吹き返す。交差系列転送の最初の壁がトークナイザーだったということだ。
その上でHeteroFoldがもう一段上を行く。長い文脈の四種ではキャッシュ転送手法の中で全方向で最高、短い文脈でもほとんどで最高だった。ただし長い文脈の単一質問QAでは、テキストですべてを引き渡す基準線(TextMas)とまだ差が残る。これは数字がそのまま示している。
速度の利得は文脈が長いほど大きくなる。同じ転送方向で4Kは再プリフィル比3.75倍、32Kでは10.74倍まで開く。共有文脈が短ければ得が小さく、長いほど大きくなる構造だ。
最も興味深い逆転はHiddenBenchである。15ラウンド後の多数決の正確さで、HeteroFoldは29.2%、テキストでやり取りしたTextMasは27.7%だった(どちらも11.5%から出発)。単一質問ではテキストに及ばなかったキャッシュ転送が、肝心のエージェントが新しい情報を作ってやり取りする実際のマルチエージェント状況では、かえってわずかに上回った。先に投げかけた「復元ではなく以降の計算を合わせる」という方向が、ここで報われる。
失うものもはっきりしている。論文が自ら認めた限界が二つ。色合わせの共分散整合は数値安定化のために実際には近似であり、短い文脈をすべて勝ち切ったわけでもない。Ministral-3-14BからQwen3-4Bへ引き渡す方向の一部の課題のように、既存手法がわずかに上回るマスが残っている。
F1は答えが正解とどれだけ重なるかを0〜100で採点するスコアだ。Qwen3-4BからLlama-3.1-8Bへ引き渡す方向のQasperで、HeteroFold 29.12、KV Ridge+TA 16.06、テキスト基準線 44.64。HiddenBenchの平均正確さは30.6%(HeteroFold)対29.2%(TextMas)。遅延は中間地点の16Kで8.11倍と、4K(3.75倍)と32K(10.74倍)の間に位置する。
具体的な場面一つに絞ろう。ある顧客がプロジェクトの途中で納期を前倒ししてほしいと要請する。ONTLEのAI PMはこの要請を、受付から検討、進行へと引き継いでいく。このとき、これまで積み上がってきたプロジェクトの文脈 — 顧客仕様、添付資料の要約、前ラウンドの決定 — が、段階を越えるたびに次のモデルへ再び渡され、そのモデルは長い文脈を最初から読み直す。プロジェクトが長く積み上がるほど、この繰り返しの読み直しが大きくなる。HeteroFoldが狙うのはまさにその状況だ。
とはいえ、今すぐ差し込める部品ではない。HeteroFoldは受け取るモデルの内部(KV・層・クエリ・アテンション)に直接手を入れて補正を合わせなければならない。内部を開けられない商用クローズドAPIモデルには使えない。今のONTLEは商用APIをルーティングしているので、前提がそもそも成り立たない。だから全面導入ではなく、この一区間だけを切り出して小さなPoCで検証することを提案する。
PoCの設計はこう組む。
導入基準はあらかじめ釘を刺しておく。品質がテキスト方式と人の目で区別がつかないほど互角で、長い文脈の区間で切り替え遅延がはっきり減り、変換表の準備コストがその区間の呼び出し頻度で回収できるほどなら — その区間からオープンウェイトモデルとキャッシュ転送に切り替える。三つのうち一つでも食い違えば保留し、オープンウェイト運用戦略とともにこの技術の成熟度だけを見守り続ける。
エージェントたちが互いに対話する前に、それぞれ独立に先に投票した正確さだ。その後15ラウンドのあいだ私的な情報を交換してから再び投票し、29.2%と27.7%へと上がる。同じ出発点から比較したからこそ、対話が実際に成果を引き上げ、その引き上げがキャッシュ転送でも保たれたことを示している。
受け取る側がキャッシュをうまく引き継げないと、形式の崩れた答え、すなわち無効応答が増える。HeteroFoldは無効応答が3.2%で、テキスト方式(4.0%)より低かった。一方、キャッシュをうまく引き渡せなかったKV Ridgeのある変種は、無効が20.9%まで跳ね上がり、受け取るモデルを不安定にした痕跡がはっきり見えた。平均スコアだけでなく、受け取るモデルを壊さなかったという信号として見る。
転送は方向ごとに別々だ。モデル三つに向きのある転送が六通りあったように、モデルの数が増えれば組み合わせが増え、それぞれの組み合わせの表をオフラインで別々に合わせなければならない。モデルを多く混ぜるほど準備コストがそれだけ大きくなる。
長い文脈ではキー補正が利得の大部分を出す。一部の課題では、キー補正だけを入れたほうが、キーとバリューの両方を入れた最終版よりわずかに高いこともあった。バリュー補正は平均的には役立つが、課題によってはわずかな相殺として働きうるという意味だ。