LLM 大语言模型

C2C：大模型不再“打字聊天”，直接交换 KV-Cache，Multi-Agent 通信能省多少？

yiwan-cat2026-09-19 11:48

今天的多 Agent 系统看起来像一家公司：规划 Agent 写方案，代码 Agent 实现，审核 Agent 再检查。可在底层，它们的协作方式仍然很“原始”——一个模型先把内部理解逐 Token 写成文字，另一个模型再把这段文字重新读一遍。

这条链路有两笔经常被忽略的成本。

第一笔是信息损失。模型内部原本是高维、分层的语义表征，输出时却必须压缩成一串线性文本；结构、置信度以及一些难以用自然语言准确描述的关系，可能在压缩过程中丢失。

第二笔是通信开销。Sharer 不仅要完成输入的 prefill，还要逐 Token 生成中间解释；Receiver 随后又要把问题和解释一起重新编码。长链路 Agent 每多接力一次，就多一次中间输出、传输与重新理解。

清华大学 NICS-EFC 团队联合无问芯穹、香港中文大学、上海 AI Lab、上海交通大学等机构提出的 Cache-to-Cache（C2C），把通信媒介从文本换成了 KV-Cache：让一个模型把自己对上下文的深层表征直接投影并融合进另一个模型的缓存。论文最新版为 2026 年 3 月发布的 v2，并已被 ICLR 2026 接收。

项目把官方 Python 包命名为 Rosetta。这个名字来自罗塞塔石碑：它曾帮助人类解读不同文字，Rosetta 则试图在彼此独立的大模型内部表征之间充当“翻译器”。

但先把结论说清楚：C2C 是一个很有潜力的研究原型，还不是能直接替换任意云端 Agent API 的通用协议。它能降低中间文本通信的延迟，并在论文实验中提升准确率；它不会免掉两个模型的 prefill，也不等于零成本、加密通信或现成的跨厂商 API 标准。

论文：Cache-to-Cache: Direct Semantic Communication Between Large Language Models
代码：thu-nics/C2C
项目页：C2C Project Page
模型权重：nics-efc/C2C_Fuser

一分钟看懂 C2C

项目	当前官方信息
核心目标	让异构 LLM 通过 KV-Cache 投影与融合直接传递语义
通信角色	Sharer 提供上下文理解；Receiver 使用融合后的缓存生成最终回答
核心组件	Projection、Dynamic Weighting、Learnable Gate
训练方式	冻结 Sharer 与 Receiver，只训练 C2C Fuser
已公开模型	Qwen3、Qwen2.5、Llama 3.2 等多个配对；具体以官方权重集合为准
论文任务	MMLU-Redux、OpenBookQA、ARC-Challenge、C-Eval、LongBench-E、GSM8K
论文硬件	单张 NVIDIA A100，batch size 1（主实验推理时延）
官方环境	Python 3.10；`torch==2.6.0`；`transformers==4.52.4`
开源许可	仓库根目录 LICENSE 为 Apache-2.0
当前成熟度	研究原型；多 Sharer 支持仍被官方标为 preliminary

论文摘要给出的总体结果是：与单模型相比，平均准确率提高 6.4%–14.2%；相对 Text-to-Text（T2T）提高约 3.1%–5.4%；平均推理时延加速约 2.5×。这些是特定模型配对、数据集和 A100 环境中的实验结果，不能直接换算成所有生产 Agent 的账单降幅。

图1：Text-to-Text 与 Cache-to-Cache 通信范式对比

它解决的不是“模型推理”，而是“模型之间的接力”

传统 T2T 协作通常是这样：

Sharer 读取问题，形成内部理解；
Sharer 把分析逐 Token 写出来；
Receiver 把原问题和 Sharer 的分析一起读入；
Receiver 再生成最终答案。

C2C 保留第 1 步和最终生成，却把第 2、3 步之间的文本接力换成缓存融合：Sharer 和 Receiver 分别对输入做 prefill，Rosetta 将 Sharer 的 KV-Cache 映射到 Receiver 的表征空间，再由 Receiver 基于融合缓存解码。

图2：C2C 的工程数据流——保留两模型 prefill，以缓存融合替代中间文本解码

因此，C2C 真正省掉的是：

Sharer 逐 Token 生成中间说明的串行 decode；
中间文本的序列化、传输与存储；
Receiver 对这段中间说明的再次文本理解；
高维内部表征先压成文本、再从文本恢复语义造成的损失。

它没有省掉：

Sharer 与 Receiver 各自对输入的 prefill；
KV-Cache 的显存占用与模型驻留成本；
Fuser 的投影和融合计算；
Receiver 最终回答的解码；
为新模型配对训练或适配 Fuser 的成本。

这一区分很重要。如果多 Agent 任务的中间消息很长、轮次很多，C2C 的价值会更明显；如果两模型本来只交换几个 Token，通信并不是主要瓶颈，部署两套模型和维护 Fuser 反而可能得不偿失。

为什么文本可能传不全模型已经“想明白”的内容？

论文用了一个 Coder–Writer 协作例子：Coder 识别出 HTML 中 <p> 的结构含义，但在自然语言说明里只说了“插入到特定位置”。Writer 无法从模糊文字还原精确结构，于是把内容放错。C2C 不要求 Coder 把这层内部理解重新组织成自然语言，而是把相关缓存表征直接映射给 Writer。

图3：文本描述可能丢失结构语义，而 C2C 尝试直接传递缓存中的上下文理解

团队先做了两个 Oracle 实验，回答“KV-Cache 是否真的适合当通信载体”。

发现一：缓存长度不变，语义仍可被“增浓”

普通 Direct 设置只让模型读问题，准确率为 58.42%；Few-shot 把示例和问题一起保留在缓存中，准确率为 63.39%。关键的 Oracle 设置先让模型读取示例和问题，再删除示例对应的缓存片段，只保留与原问题等长的缓存，准确率仍达到 62.34%。

这说明 Few-shot 的收益不完全来自“解码时还能看到更多 Token”，示例也改变了问题本身在 KV-Cache 里的表示。换句话说，同样长度的缓存可以承载不同质量的语义。

发现二：不同模型的缓存可以被映射

团队用三层 MLP，把 Qwen3-4B 的 KV-Cache 映射到 Qwen3-0.6B 的表征空间。t-SNE 可视化显示，转换后的缓存进入了目标模型空间，但只覆盖其中一部分区域。这同时说明两件事：跨模型映射可行；不同模型对同一上下文的编码并不完全相同，因此简单复制缓存远远不够。

图4：源模型缓存经投影后进入目标模型表征空间

Rosetta Fuser：翻译、调权，再决定“这一层听不听”

C2C Fuser 不是把 Sharer 缓存粗暴覆盖到 Receiver 上，而是做三步处理。

第一步，Projection。 Sharer 与 Receiver 可能具有不同隐藏维度、层数、注意力头数量和 tokenizer。项目先对 Token 与层进行对齐，再把两侧缓存连接并投影到 Receiver 可使用的空间。

第二步，Dynamic Weighting。 输入相关的 head modulation 会根据当前样本动态调整 Sharer 信息的贡献。不同问题未必需要同样强度的外部语义。

第三步，Learnable Gate。 每一层都有可学习门控，用来决定是否注入 Sharer 缓存。训练阶段采用带温度退火的 Gumbel-Sigmoid，推理时趋向二值选择。论文的消融很直观：仅做 Projection 的四项任务平均准确率为 20.70%，加入残差 Fuse 后为 44.88%，再加入 Gate 后达到 47.95%。

图5：C2C Fuser 通过投影、动态加权和逐层门控融合 KV-Cache，训练时冻结两侧 LLM

训练时两侧 LLM 都被冻结，只更新 Fuser。目标仍是标准的下一 Token 预测，但 Receiver 的预测条件从自身缓存变成了融合缓存。这样做降低了适配成本，也避免为每个组合完整微调两个大模型。

不过，“支持任意模型对”不等于“任意两个模型下载后即可零训练互通”。仓库能够构建自定义配对和自动处理结构差异，但新的 Sharer–Receiver 组合通常仍需要训练相应的投影与融合模块。

Quick Start：先跑通官方最小配对

下面以官方已发布的 Qwen3-0.6B + Qwen2.5-0.5B-Instruct Fuser 为例。建议在 Linux + NVIDIA CUDA 环境中运行；官方没有给出最低显存承诺，模型权重、KV-Cache、上下文长度与生成长度都会共同影响显存。第一次尝试不要从长上下文或多 Sharer 开始。

1. 创建环境并安装

git clone https://github.com/thu-nics/C2C.git
cd C2C

conda create -n rosetta python=3.10 -y
conda activate rosetta

pip install -e .

当前 pyproject.toml 固定了 torch==2.6.0 与 transformers==4.52.4。如果你的 CUDA、驱动或现有 PyTorch 环境不同，优先新建隔离环境，不要直接覆盖生产推理环境。

2. 保存最小示例

在仓库根目录创建 quickstart_c2c.py：

import torch
from huggingface_hub import snapshot_download
from script.playground.inference_example import (
    load_rosetta_model,
)

checkpoint_dir = snapshot_download(
    repo_id="nics-efc/C2C_Fuser",
    allow_patterns=["qwen3_0.6b+qwen2.5_0.5b_Fuser/*"],
)

model_config = {
    "rosetta_config": {
        "base_model": "Qwen/Qwen3-0.6B",
        "teacher_model": "Qwen/Qwen2.5-0.5B-Instruct",
        "checkpoints_dir": (
            f"{checkpoint_dir}/"
            "qwen3_0.6b+qwen2.5_0.5b_Fuser/final"
        ),
    }
}

device = torch.device("cuda")
model, tokenizer = load_rosetta_model(
    model_config,
    eval_config={},
    device=device,
)

messages = [{"role": "user", "content": "Say hello in one short sentence."}]
text = tokenizer.apply_chat_template(
    messages,
    tokenize=False,
    add_generation_prompt=True,
    enable_thinking=False,
)
inputs = tokenizer(text, return_tensors="pt").to(model.device)

instruction_index = torch.tensor(
    [1, 0], dtype=torch.long
).repeat(inputs["input_ids"].shape[1] - 1, 1).unsqueeze(0).to(model.device)
label_index = torch.tensor(
    [-1, 0], dtype=torch.long
).repeat(1, 1).unsqueeze(0).to(model.device)

with torch.no_grad():
    outputs = model.generate(
        **inputs,
        kv_cache_index=[instruction_index, label_index],
        do_sample=False,
        max_new_tokens=256,
    )

answer = tokenizer.decode(
    outputs[0, instruction_index.shape[1] + 1:],
    skip_special_tokens=True,
)
print("C2C output text:", answer)

3. 运行与成功判据

python quickstart_c2c.py

首次运行会下载两侧基础模型及对应 Fuser 权重。成功时，终端会出现：

C2C output text: ...

重点不是固定得到某一句英文，而是程序完成权重加载、缓存融合和最终生成，没有出现 checkpoint、设备或维度对齐错误。

4. 再运行交互式示例

python script/playground/live_chat_example.py \
  --checkpoint_dir /path/to/checkpoint

多 Sharer 的调用形式为：

python script/playground/live_chat_example.py \
  --checkpoint_dir /path/to/ckpt1 /path/to/ckpt2

官方明确把多 Sharer 支持标为早期阶段。它适合验证概念，不应仅凭 Demo 就判断生产稳定性。

Benchmark：快在哪里，数字又不能说明什么？

主实验使用单张 NVIDIA A100、batch size 1、零温度生成。Receiver 固定为 Qwen3-0.6B，与不同 Sharer 配对，在四个选择题数据集上比较单模型、Query Routing、T2T 与 C2C。

以 Qwen2.5-0.5B-Instruct → Qwen3-0.6B 的 MMLU-Redux 分解为例：T2T 中，Sharer 平均生成 80 个中间 Token，单这一步 decode 就花了 1312 ms；C2C 不生成中间文本，而用约 90 ms 完成缓存融合。总时延从 1596 ms 降到 445 ms，约为 3.59× 加速。

图6：论文 Table 3 的时延拆解；单组案例约 3.59×，论文跨设置平均约 2.5×（原创数据图）

不同模型配对的收益差异很大：论文主结果中，相对 T2T 的加速分别出现 3.46×、1.51× 和 14.41×。其中 Qwen3-4B-Base 在 T2T 中不善于遵循简短通信指令，会输出很长内容，因此 C2C 的相对加速特别大；Llama 3.2 往往只输出单个选项字母，T2T 基线本来就快，C2C 的相对优势较小。

所以这组结果证明的是：当中间文本生成占据显著开销时，绕过它确实能带来可观收益。 它不能证明任何模型、任何生成长度、任何 GPU 上都固定加速 2.5×。

更有意思的是多模型互补。附录中的双 Sharer 实验让 Qwen3-4B-Base 和 Qwen2.5-1.5B-Math 同时向 Qwen3-0.6B Receiver 提供缓存，MMLU 准确率从 Receiver 单独运行的 35.53 提升到 64.60。但这仍是早期实验，而且当前 pairwise 方案随模型数增长需要 O(N) 级训练成本；统一 latent space 仍属于探索方向。

对 Mixture-of-Agents 和长链 Agent，真正的工业价值是什么？

价值一：把“中间消息”从产品输出降级为内部状态

很多 Agent 框架会要求每个节点生成一段完整、可读的分析，即使这段内容从不展示给用户。C2C 表明，中间结果未必必须是自然语言产品；它可以是一段受控、可版本化的内部状态。这对规划器→执行器、领域专家→通用模型、强基座→小型指令模型等链路尤其有价值。

价值二：让基础模型的知识不必先变成听话的文字

论文中 Qwen3-4B-Base 独立回答选择题表现很差，T2T 也容易因不遵循指令而生成冗长文本；可作为 Sharer 通过 C2C 提供缓存后，Receiver 仍能利用其知识。这意味着“会不会按格式表达”与“内部是否编码了有用信息”可以部分解耦。

价值三：为异构模型集群提供新的通信平面

现有 MCP、A2A 等协议主要规范工具与 Agent 之间的文本或结构化消息。C2C 更像位于推理引擎内部的“语义数据平面”。未来较合理的组合不是二选一，而是：控制面继续使用可读、可审计的文本协议；高频、低延迟的模型内部协作使用缓存或 latent 通道。

价值四：可能降低自建推理集群的单位任务成本

对于自托管开源模型，Token 本质上对应 GPU 时间、吞吐和显存压力。减少中间 decode 有机会提高链路吞吐。但对按 Token 计费的闭源 API，前提是服务商愿意开放或原生支持 KV-Cache 交换。今天的大多数商业模型 API 不向调用方暴露内部缓存，因此不能把论文结果直接折算成现有 API 账单节省。

怎么接进真实 Agent 系统？

不要一开始就把整条 Agent 链改成不可读缓存。更稳妥的路线是保留文本基线，逐段替换。

阶段 1：离线验证一个高成本 hand-off

从日志里找出“中间输出最长、又只给下游模型消费”的节点，例如代码分析→修复生成。固定一个 Sharer–Receiver 配对，记录 T2T 的准确率、端到端时延、输出 Token 数、峰值显存和失败案例。

阶段 2：训练专用 Fuser，做 A/B 测试

冻结两侧模型，只训练 C2C 模块。对同一批真实任务同时跑 T2T 与 C2C，至少比较：任务成功率、P50/P95 时延、GPU 秒、显存、错误传播率，以及模型版本变化后的回归。

阶段 3：保留可审计控制面

C2C 通道只传模型内部语义；任务意图、权限、工具调用、外部副作用和最终结果仍以结构化日志记录。涉及付款、删除、发送消息、机器人动作等高风险行为时，缓存通信不能绕开显式授权。

阶段 4：再扩展到多 Sharer

只有当单配对稳定后，才引入代码、数学、检索等多个专家 Sharer。为每个来源设置质量评分、门控阈值和回退策略，避免一个较弱模型的错误语义污染 Receiver。

常见坑与容易误解的地方

1. C2C 不是通用“向量 Socket”

Rosetta 需要处理 Token、层数、隐藏维度和注意力头差异。新的模型配对通常需要新 Fuser 或统一 latent 适配。它还不是任意模型发现彼此后即可握手通信的标准协议。

2. KV-Cache 不是免费带宽

缓存是高维张量，规模随层数、头数、上下文长度和精度增长。跨 GPU、跨节点传输时，带宽与拓扑可能成为新瓶颈。论文主实验是单张 A100，并未证明分布式跨机网络同样获得 2.5×。

3. 不可读不等于安全，更不等于加密

KV-Cache 可能泄露输入与模型内部信息。没有显式文本只意味着人眼不能直接阅读，不代表攻击者无法通过反演、探针或训练解码器恢复内容。论文把“privacy-aware collaboration”列为未来方向，而不是已经完成的安全保证。

4. 错误会以更隐蔽的方式传播

论文明确报告了失败案例：较弱 Sharer 的错误理解会误导本来能答对的 Receiver。文本通信至少还能让人读到中间错误；缓存通信需要额外的异常检测、对照运行和回退机制。

5. 模型更新会破坏配对

Fuser 学到的是具体表征空间之间的映射。Sharer 或 Receiver 换权重、改 tokenizer、量化或升级推理实现后，都应重新做一致性与回归测试，不能默认旧 Fuser 继续有效。

6. 当前仓库仍有工程元数据不一致

仓库根 LICENSE 与 README 指向 Apache-2.0，但 pyproject.toml 中仍残留 MIT classifier、占位 Homepage/Repository 地址和 Alpha 状态。许可判断应以根 LICENSE 为准；如果要嵌入商业项目，仍建议做一次正式依赖与许可证审计。

适合与不适合

适合

自托管、可访问模型内部 KV-Cache 的开源 LLM 集群；
中间文本很长、Agent 接力轮次多、decode 占主要延迟的流程；
能固定模型配对，并有数据训练或验证 Fuser 的场景；
需要让基础模型、数学模型、代码模型互补的研究系统；
有能力做 GPU 级性能分析、缓存管理和安全审计的团队。

暂时不适合

只调用闭源聊天 API、无法访问内部缓存的应用；
模型频繁切换、无法为配对维护适配器的动态市场；
中间消息很短、网络与 decode 都不是瓶颈的简单 Agent；
必须逐字审计每一步理由，且尚未建立替代审计机制的高风险业务；
资源只够运行单模型，无法同时驻留两侧模型的边缘设备。

AI 之间会不会形成“人类完全看不懂”的私有语言？

会出现人类无法直接阅读的高维通信层，但这不等于 AI 已经建立了自主、秘密且无法监管的语言。

首先，C2C 不是模型私下发明的协议。通信结构、可注入层、Fuser 权重、训练数据和优化目标都由人设计。其次，KV-Cache 不是加密密文，它只是难以直接解释的内部表征，仍可以被记录、冻结、对比、干预和攻击。最后，真正需要监管的也不只是“模型说了哪句话”，而是它接收了什么输入、使用了哪个通信模块、触发了什么工具、产生了什么外部行为。

图7：面对不可直接阅读的缓存通信，可审计对象应扩展到整条状态转换链（原创理解图）

因此，更现实的风险不是“AI 突然发明密语并脱离人类”，而是工程团队为了速度，把不可解释的内部通道接到了高权限工具上，却没有同步建设日志、回放、探针、权限边界和人工复核。

未来应坚持三条底线：

高风险动作必须经过可读控制面。 支付、删除、发信、代码合并、机器人控制等动作必须有结构化参数、权限检查和可回放记录。
向量通道必须可版本化。 记录模型、Fuser、量化配置、门控结果和输入快照，使一次决策能够离线复现。
解释不只等于翻译向量。 即使不能把每个维度翻成人话，也可以通过因果干预、探针、对照实验、异常检测和行为测试建立证据链。

换句话说，C2C 可能让我们失去“直接阅读中间消息”的便利，却不必然失去审查能力。前提是审计方法必须从文本内容审核，升级为对模型状态、通信配置和外部行为的系统审计。

如果是我，我会怎么上这个项目？

我会把 C2C 当成一项“推理引擎内通信优化”，而不是先把它包装成通用 Agent 协议。

第一周，用官方 0.6B/0.5B 配对跑通 Demo，复现实验中的输出、显存和时延；第二周，从现有 Agent 日志找出一个最长的内部 hand-off，构造 200–1000 条真实回放集；第三阶段，训练专用 Fuser，与 T2T 双跑；只有当任务成功率不降、P95 时延和 GPU 秒有稳定收益、错误可回退，才把它接入灰度流量。

生产系统里继续保留文本路径：当 Fuser 版本不匹配、缓存异常、Sharer 置信不足或任务涉及高风险权限时，自动回退到 T2T。这样既能获得内部通信加速，也不把整套系统的可用性押在一个仍处早期阶段的研究原型上。

总结

C2C 最重要的贡献，不只是一次 2.5× 加速，而是提出了一个值得认真对待的问题：模型之间为什么一定要模仿人类打字，才能协作？

论文已经证明，在公开实验设置中，KV-Cache 可以跨模型投影、融合，并在多个模型配对上同时改善准确率和时延；开源的 Rosetta 也给出了从最小推理、训练新 Fuser 到多 Sharer 实验的完整入口。

但它离“所有 Agent 都用私有向量协议交流”还有明显距离：闭源 API 不开放缓存，跨机传输成本尚未系统验证，新模型配对需要维护适配器，安全与审计机制也远未成熟。

所以，对 C2C 最准确的判断不是“Token 通信已经终结”，而是：多模型系统第一次有了足够完整的证据，说明文本不必是唯一的语义总线。 下一阶段真正值得竞争的，不仅是谁能让模型更快交流，还包括谁能让这种不可直接阅读的交流依然可控、可回放、可审计。