TRINITY-Router: 用数据证伪LLM路由假设 - 8模型316题实验报告

目录

    • [📋 摘要](#📋 摘要)
    • [1. 项目背景与核心假设](#1. 项目背景与核心假设)
    • [2. 路由器架构设计](#2. 路由器架构设计)
      • [2.1 骨干网络](#2.1 骨干网络)
      • [2.2 SVF 层(Stochastic Value Function)](#2.2 SVF 层(Stochastic Value Function))
      • [2.3 分解线性头](#2.3 分解线性头)
    • [3. 训练方案:CMA-ES](#3. 训练方案:CMA-ES)
      • [3.1 多轮协调机制](#3.1 多轮协调机制)
    • [4. 技术选型](#4. 技术选型)
      • [4.1 模型选择](#4.1 模型选择)
      • [4.2 WorkerPool 实现要点](#4.2 WorkerPool 实现要点)
    • [5. 测试选型与评估方式](#5. 测试选型与评估方式)
      • [5.1 LiveCodeBench(主实验)](#5.1 LiveCodeBench(主实验))
      • [5.2 HumanEval+(跨域探测)](#5.2 HumanEval+(跨域探测))
      • [5.3 DebugBench(调试域探测)](#5.3 DebugBench(调试域探测))
      • [5.4 评估沙箱](#5.4 评估沙箱)
    • [6. 实验结果](#6. 实验结果)
      • [6.1 LCB:难题域的单极碾压](#6.1 LCB:难题域的单极碾压)
      • [6.2 HumanEval+:简单域的饱和并列](#6.2 HumanEval+:简单域的饱和并列)
      • [6.3 换道风险:路由的致命缺陷](#6.3 换道风险:路由的致命缺陷)
      • [6.4 独占解题:互补性分析](#6.4 独占解题:互补性分析)
    • [7. 为什么路由行不通](#7. 为什么路由行不通)
    • [8. 残余价值](#8. 残余价值)
    • [9. 反思与建议](#9. 反思与建议)

📋 摘要

本文介绍了 TRINITY-Router 项目的实验研究,旨在验证轻量级路由器在竞赛级编程任务分配中的有效性。项目基于 OpenFugu 论文设计,使用 Qwen3-0.6B 作为骨干网络,通过 SVF 层和分解线性头实现模型选择,采用 CMA-ES 进化策略进行训练。

核心发现

  1. 难题域(LiveCodeBench):DeepSeek V4 Pro 以 72.5% 的通过率单极碾压其他模型,领先第二名 13.6 个百分点
  2. 简单域(HumanEval+):强模型性能接近饱和(96.7% vs 95.0%),没有可利用的性能梯度
  3. 换道风险极高:路由器每做对一次"不选 ds-pro"的决定,平均付出 9.6 到 72 次错误的代价
  4. 互补性有限:39 道独占题中,ds-pro 独占 26 道(67%),其他模型互补机会极少

结论:在竞赛级编程领域,路由策略无法超越"永远选最强模型"的简单策略,因为该领域存在明确的性能胜者,模型间缺乏有效的互补性。项目虽证伪了路由假设,但产出了可复用的技术组件和数据集。

1. 项目背景与核心假设

2026年6月,我启动了 TRINITY-Router 项目。

核心假设:一个轻量路由器把编程任务分配给最擅长的模型,组合效果能超过任何单模型。这个想法来自 RouteLLM、FrugalGPT 等论文,在自然语言任务上确实有效。

要验证的问题:在竞赛级编程(LiveCodeBench)这个更硬核的领域,路由还能 work 吗?


2. 路由器架构设计

路由器的核心思路来自 OpenFugu 论文:用一个小语言模型读取题目,提取特征,通过线性头选择最佳模型。

2.1 骨干网络

选择 Qwen3-0.6B 作为特征提取器:

  • 6 亿参数,RTX 3080 20GB 推理无压力
  • 28 层 transformer,hidden size 1024
  • 整个骨干网络冻结,不参与训练

2.2 SVF 层(Stochastic Value Function)

OpenFugu 论文的核心技巧。对第 26 层(倒数第 2 层)的 9 个权重矩阵做 SVD 分解,只调整奇异值的缩放因子

  • U 和 V 矩阵冻结,仅缩放奇异值
  • 每个矩阵 1024 个参数,9 个矩阵共 9,216 个可训练参数
  • 缩放后做能量守恒归一化,确保训练稳定

2.3 分解线性头

一个 1024 x 11 的无偏置矩阵(8 worker + 3 角色):

  • 前 8 维通过 softmax 选 worker
  • 后 3 维选角色:solver / thinker / verifier
  • 11,264 个可训练参数

总计可训练参数 :9,216 (SVF) + 11,264 (head) = 20,480,接近 OpenFugu 论文的 ~20K 设计。


3. 训练方案:CMA-ES

为什么不用反向传播? 路由器的损失函数是 pass@1(代码能否通过测试),这是不可微分的二元信号,无法求梯度。

CMA-ES(协方差矩阵自适应进化策略) 是无梯度优化算法:

  1. 维护一个 20,480 维的高斯分布
  2. 每代采样一批参数向量
  3. 用 pass@1 作为适应度函数排序
  4. 更新分布的均值和协方差矩阵

采用 sep-CMA-ES 变体,只维护对角协方差,内存从 O(n^2) 降到 O(n)。

3.1 多轮协调机制

路由器不只选 worker,还选角色,3 个角色各有分工:

角色 职责
Solver 直接给出解法
Thinker 分析问题,给出改进建议
Verifier 判断解法正确性,输出 CORRECT / WRONG

run_loop() 编排多轮协调:选择 (worker, role) -> dispatch -> 累积对话 -> 直到 Verifier 判定 CORRECT 或达到最大轮数。


4. 技术选型

4.1 模型选择

8 个模型覆盖三种 API 格式:

模型 API格式 位置 选择理由
DeepSeek V4 Pro OpenAI CN 编程能力最强,免费
DeepSeek V4 Flash OpenAI CN Pro 的快速版,对比用
MiMo V2.5 Pro OpenAI CN 小米推理模型,月度计划便宜
MiniMax M3 Anthropic CN 长上下文推理模型,免费
Agnes 2.0 Flash OpenAI CN Sapiens AI,免费
Claude Sonnet 4.6 Vertex US Anthropic 主力编程模型
Claude Opus 4.6 Vertex US Anthropic 最强推理模型
Claude Haiku 4.5 Vertex US 低成本基线对照

选型策略:CN 模型全部免费或极低价用于大量评估;Vertex Claude 按量计费(估算约 $47),补充非 DeepSeek 系数据。

4.2 WorkerPool 实现要点

  • urllib.request(标准库),不引入 requests/httpx
  • 三种 API 格式各有构建函数,Vertex 需 google-auth 刷新 token
  • 重试:指数退避 + 抖动,429 尊重 Retry-After,402 直接放弃

5. 测试选型与评估方式

5.1 LiveCodeBench(主实验)

为什么选 LCB? v6 收录 2024-2025 年新竞赛题,避免训练数据污染。316 题覆盖 easy/medium/hard,pass@1 有明确对错标准。

为什么不选 HumanEval? 只有 164 题,多数模型已饱和到 95%+,区分度太低。LCB 的 27.5%-72.5% 分布更适合暴露差异。

5.2 HumanEval+(跨域探测)

验证一个逃逸路径:也许在简单题域,模型互补性更强?60 题 x 4 模型快速探测。

结果:不是互补性更强,而是所有模型都饱和了,没有可路由的空间。

5.3 DebugBench(调试域探测)

1414 题,测试调试能力(single-method + design-class bug),探测路由在非编写域的可行性。

5.4 评估沙箱

代码在 benchmark.py 沙箱中执行:subprocess + RLIMIT_AS 内存限制,超时 30 秒自动 kill。

结果以 JSONL 追加写入,支持 error=None 恢复,适应跨太平洋 API 的限流环境。


6. 实验结果

6.1 LCB:难题域的单极碾压

关键发现

  • ds-pro 72.5% (229/316) 碾压第二名 ds-flash 58.9% (186/316),领先 13.6 个百分点
  • Oracle 77.2% (244/316),仅比 ds-pro 多解 15 题
  • 从最强到最弱:ds-pro > ds-flash > sonnet > opus > mimo-pro > minimax > haiku

6.2 HumanEval+:简单域的饱和并列

关键发现

  • 前三名统计无差异:ds-flash 96.7% = mimo-pro 96.7% > ds-pro 95.0%
  • Oracle 98.3%,仅多 1 题
  • 差距只有 1-2 题,路由器没有可利用的梯度

6.3 换道风险:路由的致命缺陷

这是证伪假设的关键数据。红柱 = lose(ds-pro 能解但目标不能),绿柱 = rescue(目标能解但 ds-pro 不能):

切换方向 救回 丢失 赢亏比
ds-pro -> ds-flash 5 48 1:9.6
ds-pro -> mimo-pro 4 104 1:26
ds-pro -> opus 3 95 1:31.7
ds-pro -> minimax 2 107 1:53.5
ds-pro -> haiku 2 144 1:72

结论:路由器每做对一次"不选 ds-pro"的决定,平均付出 9.6 到 72 次错误的代价。

6.4 独占解题:互补性分析

39 道只有单一模型能解的题中,ds-pro 独占 26 道(67%),其他 6 个模型总共只独占 13 道。

路由器没有"发现被忽视的专家"的机会。


7. 为什么路由行不通

两个域,同一个结论:

难题域(LCB):ds-pro 单极碾压。Oracle 天花板 77.2%,完美路由器最多提升 4.7pp,但需要在 15 道题上 100% 选对。一个 20K 参数的路由器不可能达到这个精度。

简单域(HumanEval+):强模型都接近饱和。96.7% vs 95.0% 统计不显著,没有可利用的性能梯度。

核心指标:换道赢亏比 1:9.6 意味着,任何非平凡的路由策略都会退化为"永远选 ds-pro"。


8. 残余价值

虽然路由假设被证伪,项目产出了可复用的组件:

  1. worker_pool.py:8 后端 / 3 协议格式的统一 API 层,带重试、限流、密钥轮换
  2. benchmark.py:RLIMIT_AS 内存限制的代码执行沙箱
  3. probe_common.py:可恢复运行器,JSONL 追加 + 配额检测 + 断路器
  4. 316x7 二元矩阵数据集:可用于后续模型评估研究

9. 反思与建议

这个项目的核心教训:论文里的路由效果之所以显著,是因为选择了模型间差异大、互补性强的任务域。竞赛级编程不是这样的域,它有一个明确的胜者,其他模型要么追不上,要么已经饱和。

实用建议:在启动任何"1+1>2"的系统之前,先花两天跑一个 baseline + oracle 分析。如果 oracle headroom < 10%,或者换道赢亏比 > 1:5,路由大概率没有价值。这两天的数据收集能省下两个月的系统开发。

相关推荐
FriendshipT1 小时前
Ultralytics:解读PSABlock模块
人工智能·pytorch·python·深度学习·目标检测
fl1768311 小时前
苹果成熟度检测数据集VOC+YOLO格式2039张4类别
深度学习·yolo·机器学习
大象说1 小时前
在线AIGC检测的底层逻辑与技术落地误区
人工智能
科技林总3 小时前
EWC/KD/ILR/PL
人工智能
100个铜锣烧10 小时前
高级提示技术:Chain-of-Thought与ReAct——让大模型学会“思考”和“行动”
人工智能·大模型·提示词工程
JackHCC10 小时前
快手OneRetrieval:可编辑生成式电商召回
人工智能·机器学习
前端之虎陈随易10 小时前
编程语言级别的Skill市场,AI Agent 的未来形态
前端·vue.js·人工智能·typescript·node.js
QiLinkOS11 小时前
第三视觉理解徐玉生与他的商业活动(30)
大数据·c++·人工智能·算法·开源协议
武汉唯众智创11 小时前
当汉字成为心理CT:AI汉字联想投射分析的技术实现与心理评估价值
人工智能·ai心理健康·ai心理评估·本土化心理测评·校园心理健康解决方案·ai心理监测·多模态情绪模型