研究摘要
过去几年，AI 竞争的主线很清楚：更大的模型、更多的数据、更强的算力、更高的 benchmark。
但随着前沿模型能力持续逼近，AI 系统真正进入生产环境后，新的瓶颈开始出现。
企业不只是需要“一个最强模型”，而是需要一套可以稳定运行的智能基础设施：模型可替换，供应商可切换，成本可控制，调用可审计，失败可降级，结果可验证。
所以，AI 基础设施的下一层竞争，不只是：
谁训练出更大的模型？
而是：
谁能把多个模型、多个 Agent、多个供应商，编排成一个可用、可控、可进化的智能系统？
Sakana AI 发布的 Fugu，就是这个方向的一个重要信号。
但必须先把判断放准：
Fugu 不是从 0 到 1 的技术革命，也不是突然发明了多模型协作。它更像是 MoA、多模型路由、AI Gateway 和 learned orchestration 的一次高阶产品化。
它真正重要的地方，不是证明“编排模型已经超越所有大模型”，而是把一个正在发生的趋势推到了台前：
AI 基础设施正在从 Model API，走向 Model Operating Layer。
过去我们关心的是：
哪个模型最强？
接下来更重要的问题会变成：
如何把多个模型变成一个稳定、可控、可进化的系统？
大模型是能力源。 编排层是操作系统。 治理层决定能不能进入生产。 Eval 闭环决定能不能持续进化。
一、背景：为什么“更大的模型”不再是唯一答案？
大模型当然重要。
没有强模型，就没有能力上限。 没有推理能力，就无法完成复杂任务。 没有大上下文、多模态和工具调用，Agent 很难进入真实工作流。
但当模型能力越来越接近，企业真正要面对的问题会从“能力不足”转向“系统不可控”。
典型问题包括：
- 模型越来越多，如何选择？
- 模型价格变化频繁，如何控制成本？
- 不同模型擅长不同任务，如何匹配？
- 同一模型不同 provider 的稳定性不同，如何治理？
- 某个供应商限流、涨价、下架，业务如何不中断？
- 模型输出不可控，如何验证？
- 模型调用链路不透明，如何审计？
- 涉及敏感数据时，如何限制模型和 provider？
- 模型升级后，如何确认业务效果真的提升？
这些问题不是靠“接一个更强模型”就能解决的。
这意味着，AI 基础设施正在从单点模型能力竞争，走向系统治理能力竞争。
过去的 AI 产品更像：
Application → Model API
未来的 AI 产品会更像：
Application → Model Operating Layer → Router / Gateway / Orchestrator / Eval / Observability → Model Pool
也就是说，模型之上会出现一个新的操作层。
它负责模型选择、任务拆解、上下文管理、成本控制、失败降级、结果验证和审计治理。
这就是模型编排成为 AI 基础设施下一层的原因。
二、Fugu 到底是什么？
Fugu 的产品形态非常关键。
它不是一个单体能力型 LLM，也不是普通意义上的 AI Gateway，而是 Sakana 所说的：
Multi-Agent System as a Model
也就是说，Fugu 把一个多模型、多 Agent 协作系统，包装成了一个看起来像普通模型的 API。
用户不需要手动选择模型，也不需要自己写复杂 workflow。只要调用一个 OpenAI-compatible API，Fugu 在背后完成模型选择、任务拆解、角色分配、上下文传递、验证和结果综合。
Sakana 官方页面的表达是：
One Model to Command Them All
从产品体验看，它像一个普通模型。 从内部结构看，它更像一个 learned orchestrator。
这就是 Fugu 最值得讨论的地方：
它不是单纯的模型选择器，而是试图成为模型指挥层。
传统 LLM Router 解决的是：
给一个 prompt，应该选哪个模型？
Fugu 想解决的是：
给一个复杂任务，应该如何组织多个模型完成？
前者是 routing。 后者是 orchestration。
这两者不是一个层级。
三、先降温：Fugu 不是凭空冒出来的新范式
如果只看技术原创性，Fugu 不应该被高估。
多模型协作早就存在。Mixture-of-Agents 已经提出通过多层 LLM agent 协作，让后一层读取前一层多个模型的输出，再综合出更好的结果。
模型路由也早就存在。RouteLLM、Not Diamond、OpenRouter Auto Router、FrugalGPT 都在解决类似问题：不同任务应该调用不同模型，而不是每次都用最贵、最强的模型。
AI Gateway 也已经存在。LiteLLM、Portkey、OpenRouter 这类系统，已经在做统一 API、多 provider 接入、fallback、限流、负载均衡、成本控制和调用治理。
所以从外部可见能力拆解，Fugu 很像：
MoA + OpenRouter / Not Diamond + LiteLLM / Gateway + 一层 Agent 编排包装。
这不是贬低，而是更准确地定位。
Fugu 的价值，不在于它发明了多模型协作，而在于它把多模型协作、模型路由、任务拆解、角色分配、验证综合、供应商抽象，封装成了一个像基础模型一样调用的产品形态。
更准确地说：
Fugu 的信号不是“多模型协作被发明了”，而是“模型编排正在产品化”。
四、Fugu 到底先进在哪里？
Fugu 的先进性不能简单理解为“多模型协作”。
因为 MoA 已经做过多模型协作。 也不能理解为“自动选模型”。因为 OpenRouter、Not Diamond、RouteLLM 已经做过模型路由。 更不能理解为“多供应商 Gateway”。因为 LiteLLM、Portkey 已经做过统一接入、fallback 和治理。
Fugu 真正值得关注的先进性在三点。
第一，把多 Agent 编排封装成一个普通模型 API
这降低了使用复杂度。
过去开发者要自己写 workflow、自己选模型、自己设计 planner / executor / verifier，自己处理上下文传递和结果综合。
Fugu 把这一层隐藏在一个统一 API 背后。
这件事的产品意义很大：
多 Agent 系统从“开发者自己搭”，变成“像调用一个模型一样调用”。
这就是产品抽象上的先进性。
第二，把编排策略从 hand-written workflow 推向 learned orchestration
这是 Fugu 最值得研究的技术方向。
它背后的 TRINITY 和 Conductor，不只是简单做规则路由，而是尝试让系统学习：
- 什么时候拆解任务；
- 什么时候调用哪个模型；
- 谁负责规划；
- 谁负责执行；
- 谁负责验证；
- 哪些上下文应该传递；
- 什么时候继续；
- 什么时候停止。
这意味着，编排策略本身开始成为模型学习的对象。
过去是人写 workflow。 现在是模型学习 workflow。 未来可能是系统根据任务动态生成 workflow。
这就是 learned orchestration 的意义。
第三，把模型编排从技术优化推到基础设施治理
Fugu 的叙事中非常强调 single-vendor dependency、AI sovereignty、export controls。
这部分有营销成分，但击中了真实问题。
企业如果把关键业务完全绑定一个模型供应商，就会面临实际运营风险：
- 供应商限流；
- 模型涨价；
- 模型下架；
- 区域不可用；
- API 变更；
- 合规限制；
- 出口管制；
- 数据流向不可控。
所以，模型编排不只是省钱，而是生产韧性问题。
这就是 Fugu 这条信号真正有价值的地方。
它让行业意识到：
模型调用层不只是技术层，而是企业 AI 的控制层。
五、Fugu 的技术基础：TRINITY 和 Conductor
Fugu 不是纯营销包装。它背后有明确的研究基础。
Sakana 官方说明，Fugu 基于两条研究路线：TRINITY 和 Conductor。两者共同指向一个方向：
learned model orchestration
也就是让系统学习如何组装、路由和协调专家 Agent，而不是完全依赖人类手写 workflow。
5.1 TRINITY：轻量协调器
TRINITY 的核心思想是 test-time model composition。
它不修改底层模型权重，而是在推理时用一个轻量 coordinator，把多个模型的能力组合起来。
这个 coordinator 会在多轮过程中从模型池中选择 LLM，并为被调用模型分配不同角色。
这些角色包括：
- Thinker：负责思考、规划、拆解。
- Worker：负责执行、求解、生成。
- Verifier：负责验证、判断、终止。
这点非常关键。
过去我们做 Agent，经常是人类手写流程：先 Planning，再 Execution，再 Reflection。
TRINITY 的方向是：让一个协调器学习什么时候规划、什么时候执行、什么时候验证，以及调用哪个模型来做。
这就是从 prompt workflow 走向 learned orchestration。
根据 Sakana 的介绍，TRINITY 的 coordinator 不是大模型本身，而是一个轻量协调结构。它依赖 compact language model 的 hidden states 和小型 routing head，并通过 evolutionary strategy 优化。
这意味着它的研究重点不是“再训练一个大模型”，而是：
在推理时，如何用更小的协调器释放多个模型的组合能力。
这是 Fugu 技术叙事里最有价值的一点。
5.2 Conductor：让模型学会管理模型
Conductor 更接近“模型管理模型”的思路。
Sakana 的介绍非常直接：过去几年，人类一直在做 prompt engineering，试图激发不同 LLM 的最佳表现；Conductor 研究的是，如果训练一个 AI 来做这件事，会发生什么。
Conductor 是一个通过强化学习训练的模型，它不直接执行所有任务，而是输出自然语言形式的协作计划。
它会决定：
- 调用哪个 agent；
- 给它什么具体子任务；
- 让它看到哪些前序信息；
- 多个 agent 之间如何通信；
- 什么时候简单回答；
- 什么时候启动 planner / executor / verifier pipeline。
这句话非常关键：
未来的 Agent 编排，不一定是人类写 DAG，而可能是模型动态生成 DAG。
以前工作流系统是人定义节点：
第一步调用 A，第二步调用 B，第三步验证。
Conductor 的方向是模型自己判断：
这个问题需要几个角色？谁规划？谁执行？谁验证？上下文怎么传？是否需要递归修正？
这不是“多接几个模型”那么简单，而是把编排策略本身变成可学习对象。
不过，也必须保持克制：Fugu 的底层模型池、路由策略、每个模型的贡献路径、失败案例和真实成本结构并不完全透明。所以它是否形成了难以复制的技术壁垒，还需要更多第三方验证。
六、Fugu 的技术定位：不是 Router，而是 Orchestrator
为了理解 Fugu 的位置，可以把模型基础设施拆成三层。
| 层级 | 核心问题 | 代表项目 | 主要价值 |
|---|---|---|---|
| LLM Router | 这个 prompt 该发给哪个模型？ | RouteLLM / OpenRouter Auto / Not Diamond / FrugalGPT | 成本、延迟、质量平衡 |
| AI Gateway | 多模型、多 provider 如何稳定接入生产？ | LiteLLM / Portkey / OpenRouter | fallback、负载均衡、审计、成本治理 |
| Model Orchestrator | 一个复杂任务如何组织多个模型完成？ | Fugu / TRINITY / Conductor / MoA / Router-R1 | 任务拆解、角色分配、验证、上下文编排 |
Router 解决的是“选择模型”。
Gateway 解决的是“稳定调用模型”。
Orchestrator 解决的是“组织模型完成任务”。
Fugu 最接近第三层。
所以更准确的定义是：
Fugu 不是普通 model router，而是一个以协调模型为核心的 task-level orchestrator。
它把 Router 的“选择模型”提升到 Orchestrator 的“组织智能”。
七、同类项目对比：Fugu 和 MoA、OpenRouter、LiteLLM 到底有什么区别？
为了避免被 Fugu 的官方叙事带跑，必须把它和已有路线放在同一张图里看。
| 维度 | Fugu | Mixture-of-Agents | OpenRouter / Not Diamond | LiteLLM / Portkey |
|---|---|---|---|---|
| 核心问题 | 如何组织多个模型完成复杂任务 | 如何融合多个模型输出 | 一个 prompt 该选哪个模型 | 多 provider 如何稳定进入生产 |
| 技术重点 | learned orchestration / agent pool coordination | layered aggregation | model routing | gateway governance |
| 产品形态 | 单一模型 API | 论文方法 / 实验框架 | 路由服务 / 模型选择层 | AI Gateway / 基础设施 |
| 是否任务拆解 | 是，强调 task-level orchestration | 弱，主要是输出聚合 | 通常不是重点 | 不是重点 |
| 是否关注生产治理 | 部分关注，但黑箱较多 | 不关注 | 部分关注 | 强关注 |
| 先进性 | 产品抽象 + 学习型编排 | 多模型融合 | 成本/质量路由 | 稳定性治理 |
| 局限 | 模型池、路由策略、成本结构不透明 | 成本高、噪声大 | 多为 single-shot routing | 不负责复杂任务组织 |
这张表说明：
Fugu 不是完全新物种。
它更像是把 MoA 的多模型协作、Router 的模型选择、Gateway 的供应商抽象，以及 Conductor / TRINITY 的 learned orchestration 组合成一个产品形态。
所以，对 Fugu 最准确的判断是：
它不是底层技术革命，而是模型编排层产品化的代表案例。
八、为什么模型编排会成为基础设施问题？
过去模型路由主要解决三个问题：
第一，降成本。简单问题不用最贵模型。 第二，降延迟。低难度任务走快模型。 第三，提质量。复杂问题交给强模型。
但现在，模型编排正在被推到更高层：
供应商依赖、出口管制、组织韧性、AI 主权。
Sakana 在 Fugu 页面中强调，它提供的是 “frontier-level performance without single-vendor dependency”，也就是在不依赖单一供应商的情况下获得前沿能力。它还提到，用户可以从 Fugu 的模型池中排除特定模型或 provider，以满足数据、隐私、合规或组织要求。
这背后的现实背景是：前沿模型已经不再只是普通 SaaS 服务，而正在变成战略资产。
2026 年 6 月，Reuters 报道了 Anthropic 的 Mythos 和 Fable 模型出口管制事件。报道提到，美国商务部长在致 Anthropic CEO 的信中要求暂停这些模型的出口和对外国国民的转让，Anthropic 随后表示会在全球范围内关闭相关模型访问。
这件事的信号意义很强：
模型访问权可能因为监管、地缘政治或供应商政策突然变化。
对于个人开发者来说，这可能只是“今天 API 不能用了”。
但对企业、金融、关键基础设施、政府系统来说，这就是运营风险。
如果核心业务只绑定一个模型供应商，一旦出现涨价、限流、模型下架、区域限制、合规调整、出口管制，整个业务链路都会被动。
所以模型编排不再只是“省钱工具”。
它正在变成：
- 供应商风险管理
- 合规隔离层
- 成本控制层
- 可观测治理层
- 任务执行编排层
- AI 主权基础设施
这就是 Fugu 这条信号真正值得关注的原因。
九、模型编排不等于“模型越多越强”
这里必须降温。
多模型、多 Agent，并不天然更强。
很多人看到多个模型协作，就会直觉认为：模型越多，结果越好。
但真实情况不是这样。
多模型协作有成本，也有噪声。低质量模型可能拖累整体结果。不同模型之间的输出可能相互污染。复杂编排可能带来更高延迟、更高 token 成本、更难排查的问题。
所以真正高级的模型编排，不是盲目堆模型，而是知道什么时候不该编排。
一个成熟的 Orchestrator 至少要回答五个问题：
- 什么时候只用一个最强模型就够了？
- 什么时候应该先用便宜模型试探？
- 什么时候应该拆成多个子任务？
- 什么时候需要独立验证模型？
- 什么时候继续调用模型已经不值得？
这才是模型编排的核心难点。
不是“把模型放进池子里”，而是：
知道何时调用、调用谁、调用几次、如何停止。
从这个角度看，真正的壁垒不是模型数量，而是调度策略。
十、Fugu 的性能结果如何看？
Sakana 官方展示了 Fugu / Fugu Ultra 在多个 benchmark 上的结果，包括 SWE Bench Pro、TerminalBench 2.1、LiveCodeBench、LiveCodeBench Pro、Humanity’s Last Exam、GPQA-D、SciCode、Long Context Reasoning 等。
根据官方表格，Fugu Ultra 在多个 coding、reasoning、scientific 和 agentic benchmark 上达到或超过部分公开前沿模型。
但这部分必须谨慎解读。
第一，这是 Sakana 官方评测，不是完全独立第三方评测。
第二，官方脚注说明，部分 baseline 使用 model provider-reported scores。
第三，Fugu 的底层模型池、路由策略、调用轨迹并不完全公开。
第四，benchmark 表现不等于真实业务场景中的稳定收益。
所以更专业的判断是：
Fugu 的 benchmark 结果可以证明“模型编排层可能带来增益”，但不能直接证明“Fugu 已经拥有不可复制的技术壁垒”。
它展示了方向，不等于完成了定论。
十一、Fugu 的边界：它不是 AI 主权的全部
Fugu 的方向重要，但不能把它夸成“AI 主权的完整答案”。
首先，Fugu 本身也是一个商业服务，也会受到自身公司、地区、法规和服务条款影响。官方页面也说明，Fugu 暂未向 EU / EEA 提供服务，其他地区也可能因为网络条件或当地法规而无法访问。
其次，Fugu 并不公开具体调用了哪些底层模型。官方 FAQ 表示，Fugu 选择了哪些模型、如何协调它们属于 proprietary routing information，因此不会向用户暴露。
再次，Fugu Ultra 的模型池更偏固定；普通 Fugu 可以允许用户 opt out 某些模型或 provider，但这仍然不是完全可控的本地化模型治理。
这意味着它解决了一部分问题，也引入了新的黑箱。
对于普通开发者，这可能不是问题。 但对于金融、医疗、政务、国防、企业核心数据系统，仅仅知道“系统会自动编排模型”是不够的。
真正的 AI 主权至少还需要：
- 本地可部署模型
- 可控算力资源
- 数据边界控制
- 模型调用审计
- 供应商白名单 / 黑名单
- 权限与身份系统
- Eval 和回归测试
- 成本与 SLA 治理
- 故障降级策略
- 合规留痕
- 模型调用路径可解释
- 敏感数据流向可控
所以更准确的说法是：
Fugu 不是 AI 主权本身，而是暴露了 AI 主权的新维度：编排主权。
也就是说，企业不只需要模型主权和数据主权，还需要在模型失效、涨价、限流、下架、监管变化时，能够自主切换、降级、审计和恢复。
没有编排主权，多个模型只是多个供应商账号。 有了编排主权，模型池才真正变成能力池。
十二、企业应该建设什么样的模型编排层？
这部分是 Fugu 对 AI 产品团队最直接的启发。
企业不应该只问：
我们接了哪些模型？
更应该问：
我们是否拥有自己的模型治理和编排层？
一个面向生产的 Model Operating Layer，至少应该包括八个模块。
1. 模型目录
记录每个模型的基础信息：
- 模型名称
- provider
- 上下文长度
- 输入 / 输出价格
- 支持能力
- 适用场景
- 延迟水平
- 失败率
- 是否可用于敏感数据
- 是否可用于特定地区
- 是否已上线 / 灰度 / 下架
没有模型目录，就没有模型治理。
2. 路由策略
按不同维度动态选择模型：
- 任务类型
- 用户等级
- 成本预算
- 延迟要求
- 准确率要求
- 合规要求
- 数据敏感度
- provider 可用性
- 历史 Eval 表现
路由策略的目标不是“永远选择最强模型”，而是：
在当前约束下选择最合适的模型。
3. 健康检查
持续监控每个模型和 provider 的状态：
- 成功率
- 错误率
- P50 / P95 / P99 延迟
- 超时率
- 限流率
- 空响应率
- 内容过滤触发率
- provider 区域异常
- 单 key 用量和额度
没有健康检查，fallback 只是纸面设计。
4. Eval 系统
建立自己的业务任务集，而不是只看通用 benchmark。
Eval 应该覆盖：
- 真实用户任务
- 高价值业务场景
- 边界样本
- 多语言任务
- 工具调用任务
- 长上下文任务
- 代码任务
- 安全敏感任务
- 成本和延迟指标
模型升级前，必须先过 Eval。
否则模型切换就是赌博。
5. Fallback 和降级机制
当主模型失败时，系统要能自动切换：
- 强模型 → 次强模型
- 推理模型 → 普通模型
- 外部模型 → 本地模型
- 多轮 Agent → 单轮回答
- 自动执行 → 人工审批
- 高成本路径 → 低成本路径
真正的稳定性，不是没有失败，而是失败后业务不会中断。
6. 成本治理
AI 系统必须知道每一次调用花了多少钱。
需要监控：
- token 消耗
- 单任务成本
- 单用户成本
- 单模型成本
- 单 provider 成本
- 异常成本
- 预算上限
- 成本趋势
- 成本 / 质量比
没有成本治理，模型越强，账单越不可控。
7. 审计与合规
每次模型调用都应该可追踪：
- 谁调用
- 调用了哪个模型
- 输入摘要是什么
- 输出摘要是什么
- 数据是否出境
- 是否触发敏感词
- 是否调用外部工具
- 是否经过人工审批
- 是否发生 fallback
- 最终结果由哪个模型生成
高合规场景下，黑箱编排不可直接进入核心业务。
8. 可观测性
模型编排不是黑盒魔法，而应该可观测。
系统需要知道：
- 一个任务经过了哪些模型
- 每个模型做了什么
- 哪一步失败
- 哪一步最慢
- 哪一步最贵
- 哪一步改变了最终结果
- 哪个模型经常被 verifier 否定
- 哪个 provider 最近质量下降
没有可观测性，就没有持续优化。
十三、ReelOS.ai 的判断
Fugu 代表的不是一个单点产品，而是一个行业阶段变化：
AI 正在从 Model API 时代，进入 Model Operating Layer 时代。
Model API 时代的核心问题是：
哪个模型最强？
Model Operating Layer 时代的核心问题是：
如何把多个模型变成一个稳定、可控、可进化的系统？
这会带来一批新的基础设施机会：
- AI Gateway
- LLM Router
- Model Eval
- Agent Orchestrator
- Context Router
- Cost Controller
- Provider Governance
- Compliance Layer
- Model Observability
- Workflow-to-Agent Runtime
但对 Fugu 本身，要保持克制判断。
它没有证明“编排一定超过所有大模型”。 它没有证明“多模型天然优于单模型”。 它也没有完整解决 AI 主权问题。 它的底层模型池、路由策略和成本结构仍然不够透明。 它的 benchmark 结果仍需要更多第三方验证。
它真正证明的是：
当模型越来越多、能力越来越接近、价格越来越复杂、监管越来越不确定时，谁掌握模型编排层，谁就掌握 AI 系统的主动权。
未来最强的 AI 系统，可能不是一个巨大的黑箱模型，而是一个由多个模型、多个 Agent、多个工具、多个上下文层组成的协作生态。
单模型决定能力上限。 编排层决定任务完成率。 治理层决定能不能进入生产。 Eval 闭环决定系统能不能持续进化。
这就是 Fugu 这条信号的核心：
下一代 AI 基础设施，不是更大的模型，而是更强的模型操作系统。
十四、可执行原则
- 不要只接一个模型。 关键业务至少要有主模型、备选模型和降级模型。
- 不要只做模型中转。 中转层必须加入健康检查、成本统计、失败率、fallback 和审计。
- 不要盲目多 Agent。 多模型协作有成本、有延迟、有噪声，先判断是否真的需要编排。
- 不要手写死 workflow。 复杂任务要逐步引入动态路由、角色分配和验证机制。
- 不要迷信单次 benchmark。 真正的模型选择要基于自己的业务 Eval。
- 不要把 AI 主权等同于本地模型。 真正的主权是模型、数据、上下文、权限、编排和治理的组合。
- 不要把 Agent 当聊天框。 Agent 的下一层核心能力是调度、验证和可复用执行。
- 不要等供应商出问题后再治理。 模型层的韧性要在架构设计阶段完成。
- 不要把模型池当能力池。 只有经过 Eval、路由、验证和治理的模型池，才是真正的能力池。
- 不要只看产品叙事。 对 Fugu 这类系统，要同时看架构、评测、透明度、成本和可控性。
结语
Fugu 不一定是终局，也不一定有不可复制的技术壁垒。
但它把一个趋势讲清楚了：
模型中转正在升级为模型治理，模型治理正在继续走向模型编排。
过去，AI 产品的基础设施是“能不能接上模型”。 现在，AI 产品的基础设施是“能不能稳定治理模型”。 未来，AI 产品的基础设施会变成“能不能动态组织模型完成任务”。
这才是模型编排成为 AI 基础设施下一层的原因。
更大的模型依然重要。
但更大的模型之后，一定会出现更强的编排层。
因为未来的 AI，不只是生成答案，而是组织能力。
参考链接
- Sakana Fugu 官方页
- Sakana Fugu Beta 发布文章
- Sakana Fugu GitHub
- Fugu 技术报告
- TRINITY 官方介绍
- TRINITY 论文
- Conductor 官方介绍
- Conductor 论文
- Reuters 报道
- RouteLLM 官方介绍
- RouteLLM 论文
- OpenRouter Auto Router 文档
- OpenRouter Auto Router 模型页
- OpenRouter Model Routing 机制说明
- Not Diamond 官网
- Not Diamond 模型路由文档
- FrugalGPT 论文
- RouterBench 论文
- LiteLLM 官网
- LiteLLM GitHub
- LiteLLM Router 文档
- Portkey AI Gateway GitHub
- OpenRouter
- Mixture-of-Agents 论文
- Router-R1 论文
- Router-R1 GitHub