目录 摘要1. 项目背景与核心假设2. 路由器架构设计2.1 骨干网络2.2 SVF 层Stochastic Value Function2.3 分解线性头3. 训练方案CMA-ES3.1 多轮协调机制4. 技术选型4.1 模型选择4.2 WorkerPool 实现要点5. 测试选型与评估方式5.1 LiveCodeBench主实验5.2 HumanEval跨域探测5.3 DebugBench调试域探测5.4 评估沙箱6. 实验结果6.1 LCB难题域的单极碾压6.2 HumanEval简单域的饱和并列6.3 换道风险路由的致命缺陷6.4 独占解题互补性分析7. 为什么路由行不通8. 残余价值9. 反思与建议 摘要本文介绍了TRINITY-Router项目的实验研究旨在验证轻量级路由器在竞赛级编程任务分配中的有效性。项目基于 OpenFugu 论文设计使用 Qwen3-0.6B 作为骨干网络通过 SVF 层和分解线性头实现模型选择采用 CMA-ES 进化策略进行训练。核心发现难题域LiveCodeBenchDeepSeek 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 层 transformerhidden size 1024整个骨干网络冻结不参与训练2.2 SVF 层Stochastic Value FunctionOpenFugu 论文的核心技巧。对第 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为什么不用反向传播路由器的损失函数是 pass1代码能否通过测试这是不可微分的二元信号无法求梯度。CMA-ES协方差矩阵自适应进化策略是无梯度优化算法维护一个 20,480 维的高斯分布每代采样一批参数向量用 pass1 作为适应度函数排序更新分布的均值和协方差矩阵采用sep-CMA-ES变体只维护对角协方差内存从 O(n^2) 降到 O(n)。3.1 多轮协调机制路由器不只选 worker还选角色3 个角色各有分工角色职责Solver直接给出解法Thinker分析问题给出改进建议Verifier判断解法正确性输出 CORRECT / WRONGrun_loop()编排多轮协调选择 (worker, role) - dispatch - 累积对话 - 直到 Verifier 判定 CORRECT 或达到最大轮数。4. 技术选型4.1 模型选择8 个模型覆盖三种 API 格式模型API格式位置选择理由DeepSeek V4 ProOpenAICN编程能力最强免费DeepSeek V4 FlashOpenAICNPro 的快速版对比用MiMo V2.5 ProOpenAICN小米推理模型月度计划便宜MiniMax M3AnthropicCN长上下文推理模型免费Agnes 2.0 FlashOpenAICNSapiens AI免费Claude Sonnet 4.6VertexUSAnthropic 主力编程模型Claude Opus 4.6VertexUSAnthropic 最强推理模型Claude Haiku 4.5VertexUS低成本基线对照选型策略CN 模型全部免费或极低价用于大量评估Vertex Claude 按量计费估算约 $47补充非 DeepSeek 系数据。4.2 WorkerPool 实现要点用urllib.request标准库不引入 requests/httpx三种 API 格式各有构建函数Vertex 需 google-auth 刷新 token重试指数退避 抖动429 尊重 Retry-After402 直接放弃5. 测试选型与评估方式5.1 LiveCodeBench主实验为什么选 LCBv6 收录 2024-2025 年新竞赛题避免训练数据污染。316 题覆盖 easy/medium/hardpass1 有明确对错标准。为什么不选 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 追加写入支持 errorNone 恢复适应跨太平洋 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 haiku6.2 HumanEval简单域的饱和并列关键发现前三名统计无差异ds-flash 96.7% mimo-pro 96.7% ds-pro 95.0%Oracle 98.3%仅多1 题差距只有 1-2 题路由器没有可利用的梯度6.3 换道风险路由的致命缺陷这是证伪假设的关键数据。红柱 loseds-pro 能解但目标不能绿柱 rescue目标能解但 ds-pro 不能切换方向救回丢失赢亏比ds-pro - ds-flash5481:9.6ds-pro - mimo-pro41041:26ds-pro - opus3951:31.7ds-pro - minimax21071:53.5ds-pro - haiku21441: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.py8 后端 / 3 协议格式的统一 API 层带重试、限流、密钥轮换benchmark.pyRLIMIT_AS 内存限制的代码执行沙箱probe_common.py可恢复运行器JSONL 追加 配额检测 断路器316x7 二元矩阵数据集可用于后续模型评估研究9. 反思与建议这个项目的核心教训论文里的路由效果之所以显著是因为选择了模型间差异大、互补性强的任务域。竞赛级编程不是这样的域它有一个明确的胜者其他模型要么追不上要么已经饱和。实用建议在启动任何112的系统之前先花两天跑一个 baseline oracle 分析。如果 oracle headroom 10%或者换道赢亏比 1:5路由大概率没有价值。这两天的数据收集能省下两个月的系统开发。