TRINITY-Router: 用数据证伪 LLM 路由假设

起源2026年6月，我启动了 TRINITY-Router 项目。核心假设来自 RouteLLM、FrugalGPT 等论文：一个轻量路由器把任务分配给最擅长的模型，组合效果能超过任何单模型。这在

自然语言任务上确实有效。我想验证：在竞赛级编程这个更硬核的领域，路由还能work吗？## 技术原理### 路由器架构路由器的核心思路来自 OpenFugu 论文：用一个小语言模型（SLM）读取编程题目，提取隐藏层特征，通过一个线性头输出每个候选模型的得分，选分数最高的模型去解题。具体实现分三个部分：骨干网络：选择 Qwen3-0.6B 作为特征提取器。选它的理由是：(1) 6 亿参数，在 RTX 3080 20GB 上推理无压力；(2) 28 层 transformer，hidden size 1024，足够编码编程题目的语义；(3) 整个骨干网络冻结，不参与训练。SVF 层（Stochastic Value Function）：这是 OpenFugu 论文的核心技巧。不直接微调骨干网络的权重，而是对第 26 层（倒数第 2 层）的 9 个权重矩阵做 SVD 分解，只调整奇异值的缩放因子。U 和 V 矩阵冻结，通过缩放奇异值来改变层的行为。每个矩阵的奇异值数量等于 hidden size (1024)，9 个矩阵共 9,216 个可训练参数。缩放后做能量守恒归一化，确保梯度稳定。分解线性头：一个 1024 x 11 的无偏置矩阵（11 = 8 个 worker + 3 个角色）。接收第 26 层的倒数第二个 token 的隐藏状态，输出 11 维向量。前 8 维通过 softmax 选 worker，后 3 维选角色（solver/thinker/verifier）。11,264 个可训练参数。三部分加起来：9,216 (SVF) + 11,264 (head) = 20,480 个可训练参数，接近 OpenFugu 论文的 ~20K 设计。> 图1: 系统架构图（见下方插图）这张图展示了完整的系统层次：上层是 FuguRouter（coordinator.py），包含隐藏状态编码器、SVF 层和路由决策逻辑；中层是 WorkerPool（worker_pool.py），统一管理 8 个模型的 API 调用；底层是 Benchmark Sandbox（benchmark.py），负责代码执行和评估。右侧是 Probe 基础设施，用于跨域探测实验。### 训练方案：CMA-ES选择 CMA-ES（协方差矩阵自适应进化策略）而非反向传播，原因是：路由器的损失函数是 pass@1（代码能否通过测试），这是一个不可微分的二元信号。你无法对"代码是否正确"这件事求梯度。CMA-ES 是一种无梯度优化算法：维护一个 20,480 维的高斯分布，每代采样一批参数向量，用 pass@1 作为适应度函数排序，更新分布的均值和协方差矩阵。具体用 sep-CMA-ES 变体，只维护对角协方差，内存开销从 O(n^2) 降到 O(n)。> 图2: 训练方法图（见下方插图）这张图展示了从数据收集到训练的完整流程。上半部分是 Phase 1-2 的数据收集，产出 316x7 的 reward matrix 作为适应度信号。下半部分是计划中的 CMA-ES 训练循环：从零向量初始化，在 LCB 上评估 pass@1，通过 CMA-ES 迭代更新参数。推理路径从输入题目开始，经过 tokenize、Qwen3-0.6B 提取隐藏状态、线性头输出 worker 得分、选择最高分 worker 并调用 API。红色框标注了假设被证伪的结论。### 多轮协调机制路由器不只选 worker，还选角色。每轮对话中，3 个角色各有分工：- Solver：直接给出解法- Thinker：分析问题和已有解法，给出改进建议- Verifier：判断当前解法是否正确，输出 CORRECT 或 WRONGrun_loop() 函数编排多轮协调：路由器选择 (worker, role)，dispatch 到对应模型，累积对话历史，直到 Verifier 判定 CORRECT 或达到最大轮数。## 技术选型### 模型选择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 按量计费（估算 baseline 全跑完约 $47），用于补充非 DeepSeek 系的数据。### WorkerPool 实现worker_pool.py 用 urllib.request（标准库）做 HTTP 调用，没有引入 requests/httpx 等第三方库。原因是：worker 调用是这个系统最频繁的操作（316 题 x 7 模型 = 2,212 次 API 调用），用标准库减少一层依赖。三种 API 格式各有构建函数：_build_openai_request()、_build_anthropic_request()、_build_vertex_request()。Vertex 需要通过 google-auth 刷新 service account token。重试策略：指数退避 + 抖动，429 响应尊重 Retry-After 头，HTTP 500/502/503/504 自动重试，402（余额不足）直接放弃。> 图3: 数据流图（见下方插图）这张图从左到右展示了数据如何流经系统：三个数据源（LCB 316题、HumanEval+ 164题、DebugBench 1414题）分别进入 benchmark.py 的沙箱执行器和 probe_common.py 的共享评估循环。中间是 8 个 worker 模型按 API 格式分组。右侧是三种结果文件。## 测试选型### 为什么选 LiveCodeBenchLiveCodeBench v6 收录了 2024-2025 年各大编程竞赛平台（LeetCode、Codeforces 等）的新题，避免了训练数据污染问题。316 道题覆盖 easy/medium/hard，难度分布接近真实竞赛。每道题自带隐藏测试用例，pass@1 评估有明确的对错标准。选 LCB 而非 HumanEval 的原因：HumanEval 只有 164 道题，多数模型已经饱和到 95%+，区分度太低。LCB 的 27.5%-72.5% 分布范围更适合暴露模型间差异。### 为什么加 HumanEval+ 探测LCB 只测了"难题域"。路由假设的一个逃逸路径是：也许在简单题域，模型互补性更强？用 HumanEval+ 的 60 道题做快速探测，4 个模型，验证这个可能性。结果：简单域不是互补性更强，而是所有模型都饱和了，没有可路由的空间。### 为什么跑 DebugBenchDebugBench 测试的是调试能力而非编写能力。1414 道题包含 single-method（单函数 bug）和 design-class（设计层面 bug）两种类型。这是为了探测路由在非编写域的可行性。### 评估方式代码执行在 benchmark.py 的沙箱中进行：subprocess 启动子进程，RLIMIT_AS 限制内存，超时 30 秒自动 kill。pass@1 = 代码通过所有隐藏测试用例即为通过，否则失败。run_baseline.py 实现了可恢复运行：结果以 JSONL 格式追加写入，error=None 的条目视为已完成，重启时跳过。这在跨太平洋 API 调用（平均 TTFB 2-7 秒）和频繁的限流/超时环境下是必要的。## 数据结果### LCB: 难题域的单极碾压
7 个模型在 316 道 LCB 题上的 pass@1 成绩。每个柱子标注了百分比和通过题数。ds-pro 以 72.5% (229/316) 独占鳌头，比第二名 ds-flash 的 58.9% (186/316) 高出 13.6 个百分点。Oracle 柱（橙色）为 77.2% (244/316)，代表"任一模型解出即通过"的理论天花板，仅比 ds-pro 多 15 题。### HumanEval+: 简单域的饱和并列

4 个模型在 60 道 HumanEval+ 题上的表现。ds-flash 和 mimo-pro 并列 96.7% (58/60)，ds-pro 95.0% (57/60)，三者在统计上无显著差异。Oracle 98.3% (59/60) 仅多 1 题。minimax 86.7% (52/60) 相对落后。Y 轴从 80% 开始以放大差异，但实际差距只有 1-2 题。### 换道风险：路由的致命缺陷

这是证伪假设的关键图。红色柱是 lose（ds-pro 能解但目标模型不能），绿色柱是 rescue（目标模型能解但 ds-pro 不能）。从 ds-pro 切到 ds-flash（最接近的竞争者），lose 48 题、rescue 5 题，比率 1:9.6。切到其他模型更惨：mimo-pro 1:26，opus 1:31.7，minimax 1:53.5，haiku 1:72。这意味着：路由器每做对一次"不选 ds-pro"的决定，平均要付出 9.6 到 72 次错误的代价。在这种不对称下，最优策略就是永远选 ds-pro。### 独占解题：互补性分析

39 道"只有一个模型能解"的题目的归属。ds-pro 独占 26 道（67%），是其他 6 个模型总和（13 道）的两倍。ds-flash 和 mimo-pro 各独占 3 道，sonnet、opus、minimax 各 2 道，haiku 1 道。这说明 ds-pro 不仅整体最强，在独占能力上也是垄断地位。路由器几乎没有"发现被忽视的专家"的机会。## 为什么路由行不通两个域，同一个结论：难题域(LCB)：ds-pro 形成单极碾压局面。Oracle 天花板仅 77.2%，完美路由器最多提升 4.7 个百分点。但这要求路由器在 15 道题上 100% 选对，任何错误选择都会从 72.5% 的基线上扣分。实际中，一个 20K 参数的路由器不可能达到这个精度。简单域(HumanEval+)：所有强模型都接近饱和。96.7% vs 95.0% 的差距在统计上不显著，路由器没有可利用的性能梯度。核心指标是换道赢亏比。1:9.6 意味着路由器每做对一次"不选 ds-pro"的决策，平均要承受 9.6 次"本该选 ds-pro 却没选"的代价。在这种不对称下，任何非平凡的路由策略都会退化为"永远选 ds-pro"。## 残余价值虽然路由假设被证伪，项目产出了几个可复用的组件：1. worker_pool.py：8 后端、3 协议格式的统一 API 调用层，带重试、限流、密钥轮换，用标准库 urllib 实现2. benchmark.py：RLIMIT_AS 内存限制的代码执行沙箱，可用于任何编程基准测试3. probe_common.py：可恢复运行器模式，JSONL 追加 + error=None 恢复逻辑 + 配额检测 + 断路器4. 316x7 的二元矩阵数据集，可用于后续模型评估研究## 反思这个项目的核心教训：论文里的路由效果之所以显著，是因为它们选择了模型间差异大、互补性强的任务域。竞赛级编程不是这样的域，它有一个明确的胜者，其他模型要么追不上，要么已经饱和。在启动任何"1+1>2"的系统之前，先花两天跑一个 baseline + oracle 分析。如果 oracle headroom 小于 10%，或者换道赢亏比超过 1:5，路由大概率没有价值。这两天的数据收集能省下两个月的系统开发。