TL;DR
J-COMMは、LLMエージェント間でテキストではなく潜在表現を渡す通信フレームワークです。送信側はGEARで候補トークン埋め込みを埋め込み空間の幾何的合意により再重み付けし、消費した分布（H）と中間状態のヤコビアン読み出し（J）を受信側へ送ります。受信側は自分の辞書で再構成し、prefill時に中間層へ注入します。Qwen3-8B→Qwen3-4Bの7ベンチマークで最高平均を報告し、TextMAS比で改善と生成テキストトークン削減を示しますが、モデルペア・校正・語彙前提などの限定があります。
既存手法との違い
原論文の主比較はTextMASです。TextMASは送信側が生成したテキスト計画を渡すのに対し、J-COMMはGEARによる幾何合意フィードバックとH+J二経路の潜在メッセージを使い、KVキャッシュ共有や同一隠れ幅を要求しません。Qwen3-8B→Qwen3-4Bの7ベンチマークでJ-COMM（GAF+H+J26）が最高平均を報告しています。TextMAS比の改善は、GSM8K 1.29、MATH500 1.60、GPQA-Diamond 8.59、MedQA 1.97、MBPP+ 5.56ポイント（Abstractおよび5.2）。生成テキストトークンは19.2–74.8%削減（Abstract）。ほかにReceiver-only、Identity40/Identity(TGAF)、H/H+Jアブレーション、Null-slot、J-only、Shuffled-Jなどの対照があります。比較条件は受信バックエンドと出力上限を揃え、TextMASはHFキャッシュまたはvLLM生成計画を使用します。関連手法として、Coconutは最終隠れ状態を次入力にし、Soft Thinkingは候補埋め込みの確率平均を使い、StateBridgeは閉形式写像、CIPHERは受信側埋め込み構築を用います。J-COMMは候補集合の幾何的合意を確率に乗算する点と、分布と中間状態を二経路で送る点が異なります。数値は原論文の報告で、追試ではありません。
使える条件
原論文の主設定は、凍結したQwen3-8B送信側→Qwen3-4B受信側です。共有トークン語彙を持つ設定で、隠れ幅が異なってもよい。KVキャッシュは共有せず、各モデル内で保持します。受信側の事前校正済みJacobianレンズ辞書が必要で、主設定はブロック26で読み書き、P=32アンカー、λ=1e-3、α=1、送信側は最低40潜在ステップ後に適応停止、通信する末尾はM=400です。連続推論はHugging Face、受信はvLLM 0.10.2 V0、bfloat16。評価はGSM8K、MATH500、GPQA-Diamond、MedQA-USMLE、MBPP+、AIME2024+2025、ALFWorldです。語彙が異なる場合の拡張は付録B.1に言及されますが、提示本文では詳細は確認できません。計算資源の具体量やレイテンシは提示本文からは確認できません。
限界と未検証の範囲
評価は主にQwen3-8B→Qwen3-4Bの1組と7ベンチマークに限定されます。他モデルペアへの一般化は、転移評価への言及はあるものの提示本文だけでは十分に確認できません。共有語彙前提で、語彙が異なる拡張は付録参照であり本文未確認です。Jacobian辞書の校正・固定レンズ・層選択・アンカー数・注入強度など複数の設計依存があり、校正コストや遅延・メモリの定量比較は提示本文からは確認できません。テキストトークン削減はTextMAS比較の範囲で、潜在ステップの計算コストは別会計です。安全性・多言語・長期間運用・本番環境での頑健性は提示本文では未検証です。数値は原論文の報告で、独立追試ではありません。
解説
ねえ、LLMエージェント同士がテキストじゃなくて潜在表現をやり取りするJ-COMMって論文、どういう発想なの？
問題意識は、テキスト交換は読めるけどトークン生成が重いってこと。潜在通信は計算を渡せるけど、受信側がその中間計算をどう使うかが難しい。J-COMMは送信側の連続推論と受信側へのインターフェースを一緒に設計してる。
送る側も受け取る側も工夫が必要なんだ。
そう。送信側のGEARは学習なしで、各ステップの候補トークン埋め込みを、候補同士の埋め込み空間での幾何的合意で再重み付けする。確率だけの平均より、近い方向の候補を支持するイメージ。凍結モデルの既存埋め込み表を使う。この幾何合意フィードバックをGAFって呼ぶ。関連手法だとCoconutは最終隠れ状態を次入力にし、Soft Thinkingは候補埋め込みの確率平均を使う。J-COMMは幾何合意を確率に乗算する点が違う。
なるほど、確率だけでなく候補の向きも見るんだ。
メッセージはHとJの二経路。Hは送信側が実際に消費したフィードバック分布を、受信側の埋め込みで構成して入力として渡す。Jは中間状態をJacobianレンズ座標で読み出し、共有トークンIDのアンカーIDと符号付き読み値を送る。受信側は自分の辞書で再構成して、prefill中の中間層に注入する。
自分の辞書で再構成するから、隠れ幅が違ってもいいんだ。KVキャッシュ共有も不要ってこと？
その通り。主設定はQwen3-8BからQwen3-4Bで、ブロック26を読み書き、P=32アンカー、M=400、送信側は最低40潜在ステップ後に適応停止。bfloat16で、送信側はHugging Face、受信側はvLLM 0.10.2 V0。共有語彙が前提で、語彙が違う場合の拡張は付録B.1に言及があるけど、提示本文では詳細は確認できない。
評価は？ TextMASと比べてるんでしょ？
原論文の主比較はTextMAS。TextMASは送信側が生成したテキスト計画を渡すのに対して、J-COMMはGEARの分布とH+Jの潜在メッセージを渡す。7ベンチマークでJ-COMMのGAF+H+J26が最高平均スコア。MATH500 94.80%、GPQA-Diamond 54.55%、AIME2024+2025 73.33%、ALFWorld 62.93%成功。TextMAS比ではGSM8K 1.29、MATH500 1.60、GPQA 8.59、MedQA 1.97、MBPP+ 5.56ポイント改善で、生成テキストトークンは19.2〜74.8%削減。ただしこれは原論文の報告で、追試ではない。
トークン削減も大きいね。でも万能ではない？
限定はある。評価の中心はQwen3-8B→Qwen3-4Bの1組と7ベンチマーク。共有語彙前提、校正済みJacobian辞書、層選択、アンカー数、注入強度みたいな設計依存がある。校正コストや遅延・メモリの定量比較は提示本文からは確認できない。テキストトークン削減はTextMAS比較の範囲で、潜在ステップの計算は別会計。安全性、多言語、長期運用、本番環境の頑健性は未検証。
じゃあ、読むときは『幾何合意で送信側を整えて、HとJで受信側に渡す』って押さえればいいんだ。
あとは対照も見るといい。Receiver-only、Identity40、H/H+Jアブレーション、Null-slot、J-only、Shuffled-Jがあって、比較条件は受信バックエンドと出力上限を揃えてる。J-COMMはKV共有なしで、各モデルのKVキャッシュをローカルに持つ設計。
なるほどね。じゃあ私の考えも潜在通信で智也に直接伝わったりして？
語彙も校正も共有してないから、まずテキストで頼む。