TRINITY：一个0.6B参数的"AI包工头"，如何把GPT-5、Gemini、Claude拧成一股绳

> 一句话总结：Sakana AI 用了一个只有 0.6B 参数的小模型 + 10K 参数的轻量头，当起了顶级大模型们的"指挥官"，在 LiveCodeBench 上刷出 86.2% 的 SOTA——而且完全不用碰这些闭源模型的权重。

---

为什么这件事很酷

你可能听过"模型融合"（Model Merging）这个词——把几个模型的权重揉在一起，期待 1+1>2。但这条路有个硬伤：不同公司的模型架构不一样，闭源模型的 API 你根本碰不到权重。

TRINITY 的思路是：既然没法在参数层面搞融合，那就在推理时搞协同。

想象一个场景：你有一个超级难的编程题。GPT-5 代码写得好但容易漏边界条件，Gemini 数学推理强但代码风格偏学术，Claude 擅长审代码但有时候过度谨慎。

与其赌某一个模型能全对，不如让一个小"包工头"来调度——让 GPT-5 写代码，Gemini 检查数学逻辑，Claude 做最终审核。这就是 TRINITY 的核心思想。

---

架构拆解：极简主义的胜利

TRINITY 的协调器（Coordinator）长这样：

组件	参数规模	作用
主干 SLM	0.6B (Qwen3-0.6B)	提取输入的上下文表示
轻量 Head	~10K	选哪个模型 + 给它什么角色
SVD Fine-tune	<10K	微调 SLM 的奇异值尺度
总计	< 20K	全部可学习参数

你没看错。整个协调器只有不到 2万个可学习参数。相比之下，一个 GPT-4 级别的模型有上万亿参数。

但就是这么一个"小不点"，却能指挥 GPT-5、Gemini-2.5-pro、Claude-4-Sonnet 这些巨头。

关键设计：Hidden State 驱动

TRINITY 不生成任何文本。它只看 SLM 的 penultimate token 的 hidden state（倒数第二个token的隐藏状态），然后让轻量头做决策：

1. 选哪个模型（从池子里挑一个 LLM） 2. 给它什么角色（Thinker / Worker / Verifier）

论文里有个很妙的观察：penultimate token 的 hidden state 已经编码了足够的上下文信息，因为自注意力机制让它 attend 了整个序列。用最后一个 token（通常是 EOS）反而会性能暴跌——因为 EOS 的语义太稀疏了。

---

三角色协作：Thinker → Worker → Verifier

TRINITY 定义了三个角色，构成了一个完整的"思考-执行-验证"闭环：

🧠 Thinker（策略家）

• 分析当前状态
• 提出高层计划、任务分解
• 可以指定下一步该谁来做、做什么

🔨 Worker（执行者）

• 直接解决问题
• 写代码、做推导、给数值结果
• 产出可操作的中间成果

✅ Verifier（审核员）

• 检查当前方案是否正确、完整
• 输出 ACCEPT 或 REVISE
• 如果 ACCEPT，流程终止

整个对话最多进行 K 轮（论文里设的是 5 轮）。Verifier 通过 → 收工。预算耗尽 → 返回最后一轮结果。

---

为什么用进化策略（CMA-ES）而不是 RL？

这是论文里最硬核的部分。

传统的想法：这不是一个序列决策问题吗？上 REINFORCE/PPO 啊。

但 TRINITY 的作者发现，RL 在这个场景下非常难训：

1. 参数维度高（~10K），但每个参数对最终奖励的影响极小 2. 奖励稀疏（只有最终答案对/错，二值奖励） 3. 每步成本极高（每次评估要调好几个 LLM API）

结果是：REINFORCE 的梯度信噪比极低，学不动。

TRINITY 的解法是用 separable CMA-ES（可分离协方差矩阵自适应进化策略）：

• 只维护对角协方差矩阵（假设参数间弱耦合）
• 每代采样一批候选解，按 fitness 加权更新
• 无梯度， black-box 优化

论文证明了两个关键命题：

> 命题 1：在小迭代次数 regime 下，sep-CMA-ES 的改进速度与迭代次数成线性关系，而随机搜索只与 log(候选数) 成正比。 > > 命题 2：经过约 n 次迭代校准后，sep-CMA-ES 进入稳态，每步将剩余误差减少约 1/n 的比例。

实验也证实了这一点：sep-CMA-ES 显著优于 REINFORCE、SFT 和随机搜索。

---

实验结果：SOTA + 零样本泛化

In-Distribution（训练时见过的任务）

任务	TRINITY	第二名	相对误差降低
MATH500	0.91	Gemini 2.5 Pro (5x预算)	11.76%
MMLU	0.88	-	-
RLPR	0.45	MoA	-
LiveCodeBench v6	0.862	GPT-5 (0.838)	新SOTA

TRINITY 在 LiveCodeBench 上刷出 86.2% 的 pass@1，超过了 GPT-5、Gemini 2.5 Pro 和 Claude-4-Sonnet。

Zero-Shot Transfer（完全没见过的任务）

任务	TRINITY	最好单模型
AIME2025	50.00	40.00
BigCodeBench	35.80	32.00
MT-Bench	9.60	9.20
GPQA-D	76.82	69.00

全部碾压单模型。这说明 TRINITY 学到的不是"哪个任务用哪个模型"这种简单路由，而是更本质的协作策略。

---

核心洞见：两个"可分性"

1. 表示空间的可分性（Representation Separability）

论文用 SVM 和 t-SNE 分析了 SLM 提取的 hidden states：

• 线性 SVM 在任务类型上达到完美分类（远超随机水平 0.25）
• t-SNE 显示出清晰分离的聚类

这说明不同任务的 hidden state 在表示空间中是高度可分的——这正是轻量 head 能做出有效决策的基础。

2. 优化目标的可分性（Objective Separability）

作者设计了不同结构的 head 来测试：

Head 类型	参数量	性能
Linear (默认)	~10K	最佳
Sparse	~10K	几乎持平
Block-diagonal-10	~1K	中等

最惊艳的是 block-diagonal-10：只有 1K 参数（10 倍减少），性能依然保持竞争力。这说明协调目标的参数结构具有强烈的 block-ε-separability——每个 agent/role 的决策相对独立，交叉干扰极小。

---

消融实验：每个组件都必要

变体	MATH500	RLPR	LiveCodeBench
TRINITY (完整)	0.91	0.45	0.61
去掉 SVD fine-tune	↓	↓	↓
去掉 Thinker 角色	0.85	-	-
去掉所有角色	0.82	0.40	-
用 last token (EOS)	-	-	暴跌 10+ 分
去掉 agent 选择	显著下降	显著下降	显著下降

几个关键发现：

• EOS token 是陷阱：用最后一个 token 的 hidden state 性能暴跌，因为 EOS 语义稀疏
• 角色分工很重要：去掉 Thinker 角色，MATH500 掉 6 分
• Agent 选择 + 角色分配缺一不可

---

这论文为什么重要

1. 证明了"小脑指挥大脑"是可行的：0.6B 参数的 coordinator 可以调度 GPT-5 级别的模型，而且调度策略是通过进化自己学出来的 2. 给模型协作提供了新范式：不是 router（简单路由），而是有状态的、多轮的、角色化的协作 3. 进化策略在高维稀疏奖励场景下的胜利：这是一个方法论的突破，可能对 RL 社区有启发 4. 对闭源 API 用户极其友好：你不需要模型权重，只要 API 就能构建 TRINITY 系统

---

局限与思考

• 成本问题：每次 query 要调多个 LLM，token 成本比单模型高。论文说 token 效率优于其他协调方法，但绝对成本 still 不低
• 延迟问题：多轮 API 调用意味着更高的延迟，实时场景可能不适用
• 闭源模型的黑盒性：如果被调用的模型输出分布变了（比如 OpenAI 悄悄更新），coordinator 的决策可能失效
• 训练数据的覆盖：论文只在代码/数学/推理任务上验证，创意写作、对话等任务的泛化能力未知

---

参考

• 论文: Trinity: Evolutionary Large Language Model Coordination via Lightweight Hidden-State Routing
• 作者: Jinglue Xu, Qi Sun, Peter Schwendeman, Stefan Nielsen, Edoardo Cetin, Yujin Tang (Sakana AI)
• arXiv: https://arxiv.org/abs/2512.04695
• 机构: Sakana AI (日本), University of Michigan, Institute of Science Tokyo

#论文 #AI #LLM #多智能体 #SakanaAI #智柴 #小凯