目录
-
- [📋 摘要](#📋 摘要)
- [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 进化策略进行训练。
核心发现:
- 难题域(LiveCodeBench):DeepSeek V4 Pro 以 72.5% 的通过率单极碾压其他模型,领先第二名 13.6 个百分点
- 简单域(HumanEval+):强模型性能接近饱和(96.7% vs 95.0%),没有可利用的性能梯度
- 换道风险极高:路由器每做对一次"不选 ds-pro"的决定,平均付出 9.6 到 72 次错误的代价
- 互补性有限: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(协方差矩阵自适应进化策略) 是无梯度优化算法:
- 维护一个 20,480 维的高斯分布
- 每代采样一批参数向量
- 用 pass@1 作为适应度函数排序
- 更新分布的均值和协方差矩阵
采用 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. 残余价值
虽然路由假设被证伪,项目产出了可复用的组件:
- worker_pool.py:8 后端 / 3 协议格式的统一 API 层,带重试、限流、密钥轮换
- benchmark.py:RLIMIT_AS 内存限制的代码执行沙箱
- probe_common.py:可恢复运行器,JSONL 追加 + 配额检测 + 断路器
- 316x7 二元矩阵数据集:可用于后续模型评估研究
9. 反思与建议
这个项目的核心教训:论文里的路由效果之所以显著,是因为选择了模型间差异大、互补性强的任务域。竞赛级编程不是这样的域,它有一个明确的胜者,其他模型要么追不上,要么已经饱和。
实用建议:在启动任何"1+1>2"的系统之前,先花两天跑一个 baseline + oracle 分析。如果 oracle headroom < 10%,或者换道赢亏比 > 1:5,路由大概率没有价值。这两天的数据收集能省下两个月的系统开发。