数週間前にここで AVP について投稿しました – エージェントがテキストの代わりに KV キャッシュを互いに渡します。良い議論で、実際にどのベンチマークを使ったのか、前置キャッシュがどのように適合するかについて多くの質問がありました。

それ以降、私は A100 で適切なベンチマークを実行しました（HumanEval、GSM8K、MATH、DebugBench、HotpotQA – n=164-500）、クロスモデルの動作を確認し、実際に試せる Colab ノートブックを作成しました（無料の T4、約8分）。

ご注意 – 現在これは HuggingFace Transformers + GPU のみで動作します。llama.cpp、Ollama、クラウド API は使えません。モデル内部へ直接アクセスする必要があります。量子化モデルは未検証。次に取り組んでいるのは vLLM latent サポート です。もしそれがあなたのスタックでない場合でも、以下の結果は少なくともこの方向性を示しています。

同じモデル、2つのエージェント（Qwen2.5-7B、A100、seed=42、T=0.7）

ベンチマーク	サンプル数	潜在表現 (AVP)	テキスト連鎖	高速化
HumanEval	164	67.1%	53.0%	1.2x
GSM8K	200	90.5%	87.0%	2.0x
DebugBench	100	51.0%	49.0%	3.0x
MATH	500	66.8%	66.6%	–
HotpotQA	200	52.5%	50.5%	5.8x

コード生成の結果には驚きました – テキスト連鎖より +14.1pp（p=0.004、McNemar's）。私はさらに 4 つのシードを T=0.01 で実行して確認しました：潜在 70.0%±0.3%、テキスト 57.6%±0.3%。両方の温度でギャップは維持されます。Llama 3.2-3B でも同じパターンを確認しました（潜在 54.3%、テキスト 44.5%）。GSM8K は 3 シードで中立、その他はすべて p>0.1。

したがって、コード生成は実質的な精度向上を得て、他は同じままで 2-6x の高速化。これで十分です。

正直に言えば – これらは単一リクエストの数値で、実運用のスループットではありません。vLLM の継続的なバッチ処理では、GPU はリクエスト全体で既に飽和しているため、速度向上の話は異なる形になります。連続的な HuggingFace パイプラインでは 2-3x が現実的です。

速度の源泉：エージェント A の 20 潜在ステップは 0.9s、テキストのデコードには 15.6s – それは 17x。とはいえ、エージェント B は自分の回答をデコードする必要があるため（いずれにせよ約 5.5s）、エンドツーエンドでは 2-3x、17x にはなりません。アムダールの法則。

LatentMAS の上に構築され、同一モデルの潜在通信が機能することを証明した LatentMAS の上に構築しています。

クロスモデル

異なるモデル同士で隠れ状態を共有できるようになりました。学習なし、学習済みパラメータなし。クロスモデルはオプトインです – cross_model=True を渡し、source= connector を指定します。そうしない場合、通信はテキストモードへフォールバックします。

1つのモデルの最後の隠れ状態を共有語彙を介してもう一方のモデルの空間へ投影します。Qwen と Llama は約 85% の BPE トークンを共有します（バイトレベルの正確な一致）– 「return」「function」「+=」のようなトークン。つまり: ソースモデルは - 隠れ状態を抽出 - ソース出力ヘッドを介して投影 - 共有トークンでのソフトマックス - ターゲット入力埋め込みを介して投影 - 注入。全体は 約100行、学習済みパラメータはゼロ。投影技法自体は新しくない（クロスリンガル埋め込みが同じアイデアを使う）が、クロスモデルエージェント間の通信に用いられるのを見たことはありません。

同じファミリー (Qwen 7B -> Qwen 3B、共有トークナイザー) – 投影は何も壊さない。GSM8K: 82.5% ロゼッタ 対 82.5% 3B 自身の獲得。HumanEval: 66.5% ロゼッタ vs 61.0% ダイレクト、ただし信頼区間が重なるためノイズの可能性。

クロスファミリー (Qwen ↔ Llama、単一シード=42、T=0.7、A100):

方向	GSM8K ロゼッタ	GSM8K テキスト	HumanEval ロゼッタ	HumanEval テキスト
Qwen 7B → Llama 3B	77.0%	86.5%	47.0%	57.9%
Llama 3B → Qwen 7B	90.0%	82.0%	79.3%	61.6%

方向のパターンは興味深いです。弱いモデルが解くとテキストが勝つ – 明示的な推論が必要だからです。これを逆転させるとロゼッタが大勝します（GSM8K +8pp、HumanEval +17.7pp）。強力な解決者は推論方向で機能しますが、弱い解決者には全ての説明を明示する必要があります。

参考のためのソロベースライン: Qwen 7B = 91.0% / 58.5%、Llama 3B = 76.0% / 50.6%。

実際にいつ使いますか？ 役割の異なるモデルを動かしていて、それらの間で全てをテキストへ直列化したくない場合。あるいは VRAM の予算が 3B と 7B を同時に収められるが 2 台の 7B には足りない場合。

クロスモデルには両方のモデルを読み込む必要があります（7B+3B で約 20 GB）。それより多くの latent とテキストの VRAM は不要です。

壊れる箇所

クロスモデルの理解は乏しい – HotpotQA は 7.5%。1つの隠れ状態は「この数学問題をこの方法で解く」能力を持つが、段落レベルの事実（名前、日付、複数の推論）を運ぶことはできません。これを直そうと多くの時間を費やしました – 複数埋込み、離散トークン、最大 29M パラメータの訓練済み翻訳、ハイブリッド手法。9 回試みましたが、何も機能しませんでした。問題は inputs_embeds の注入自体であり、投影ではありません。

ファンアウト（並列の専門家が1つのエージェントに統合されること）も劣化します – 複数ソースからの逐次 KV 注入はアグリゲータを混乱させます。

潜在ステップ数: 20 が最適です。40 は悪化し、80 は garbage。ノイズが蓄積します。

前回挙がった話題なので – prefix キャッシュと AVP は異なる問題を解決します。Prefix キャッシュは同一のテキストに対して KV を再利用します。AVP は異なるプロンプトを持つエージェント間で計算を転送します。 両方を使うべきです.

試してみる

Colab ノートブック – 無料の T4、約8分、セットアップ不要。10 問題で Qwen2.5-1.5B を使用。ご注意: 1.5B では全モードの精度はほぼ同じです（テキストがわずかに勝る場合あり – 出力は通常 60%、潜在 60%、テキスト 70%）。ノートブックはエージェント間でトークンを渡す様子を示すだけで、全スケールの利得を示していません。HumanEval の優位性は 7B+ で現れます。

from avp import HuggingFaceConnector // 同一モデルコネクタ = HuggingFaceConnector.from_pretrained("Qwen/Qwen2.5-7B-Instruct") context = connector.think("分析: 24 * 17 + 3", steps=20) answer = connector.generate("段階的に解く: 24 * 17 + 3", context=context) // クロスモデル researcher = HuggingFaceConnector.from_pretrained("Qwen/Qwen2.5-7B-Instruct") solver = HuggingFaceConnector.from_pretrained("meta-llama/Llama-3.2-3B-Instruct") ctx = researcher.think("分析: 24 * 17 + 3", steps=20) answer = solver.generate("解く: 24 * 17 + 3", context=ctx, source=researcher, cross_model=True) 

LangChain/CrewAI アダプターはまだありません – AVP は推論レイヤーで動作します。フレームワーク統合はロードマップ上です。

• GitHub: github.com/VectorArc/avp-python
• Benchmarks: BENCHMARKS.md

質問には喜んでお答えします。