GitHubCopilot Fusion 将多模型路由引入 IDE

GitHub 使 Copilot Fusion 普遍可用，将多模型路由从基础设施问题转移到日常编码工作流程中。 Fusion 可以根据请求选择和编排一个或多个模型，而不是要求开发人员选择一种固定模型。

此次发布的重要性超出了GitHub副驾驶的范围。它演示了用户如何在服务做出多项基础模型决策的同时提交一项任务，从而可能生成多个单独计费的呼叫。这改变了开发人员、管理员和计费系统需要了解的有关请求的信息：界面中显示的模型不再一定是工作执行方式的完整描述。

融合可以选择、级联或批评

GitHub 记录了 Fusion 的三种执行模式。请求可能会发送到单个选定的模型，在一系列模型中移动，或者使用一个模型来批评另一个模型的输出。用户还可以选择标准、高或最大工作量级别，从而对应用的编排量进行一定程度的控制。

这是一个重大的产品转变，因为路由正在成为最终用户体验的一部分，而不是提供商背后的隐形优化API。用于团队的多模型API网关可以在应用层执行类似的选择，但 Fusion 将决策置于主要开发环境中，并将工作量控制直接公开给开发人员。

这种方法可以减少用户了解每种可用模型的优点的需要。它还产生了新的诊断问题。当答案缓慢、成本高昂或不正确时，团队需要知道结果是来自一个模型、级联还是涉及多个模型的批评传递。

GitHub 表示 Fusion 使用的每个型号均按该型号的标准费率计费。它还宣布对付费计划的 Fusion 模型成本提供 30% 的临时折扣，但审核后的公告并未具体说明该折扣何时结束。

这种计费设计使得执行跟踪在商业上非常重要。即使编排产生了更好的结果，单个开发人员操作也可能比直接调用一个模型消耗更多的资源。因此，评估 Fusion 的团队需要比较每个已完成编码任务的成本，而不仅仅是所涉及的第一个模型的列出代币价格。

同样的问题也适用于统一 AI API 结算。使用记录应识别每个底层模型调用，同时保留与原始用户请求的连接。如果没有这种关系，管理员可能会看到模型费用，但很难解释哪些任务产生了这些费用，或者工作量设置是否增加了成本。

企业和组织管理员可以通过 GitHub 的现有模型政策来限制 Fusion 可以使用哪些模型。这为公司提供了一种排除不符合内部要求的模型的方法，但这也意味着相同的 Fusion 请求可能会在组织之间以不同的方式路由。

对于工程领导者来说，模型政策和预算政策现在需要一起考虑。允许目录中存在昂贵的模型可能会允许 Fusion 将其作为多模型序列的一部分进行调用，而不仅仅是当开发人员明确选择它时。因此，实用的 AI API 团队支出控制应考虑到编排深度、工作量水平以及与任务相关的所有调用的总成本。

网关运营商面临相关的报告要求。日志应将用户请求的模型或模式与实际服务该请求的每个模型区分开来。当路由行为随时间变化时，这种区别支持成本归因、事件调查和可重复的评估。

GitHub 还推出了一个实验性预览版，可以在符合条件的本地模型和云模型之间进行路由。本地推理可能为成本、延迟或数据处理提供另一种选择，但“本地”一词本身并不能描述完整的处理路径。团队仍然需要清楚哪些路由决策、提示、元数据或后续模型调用保留在 GitHub 的云服务中。

有几个细节尚未确定。 GitHub 未指定 30% 折扣的持续时间，其发布的与 Claude 代码的成本和性能比较取决于特定的基准配置。这些结果不应被视为对每个存储库或工作负载的通用估计。

持久的变化是架构方面的：模型编排正在成为开发者工具的标准功能。此时，透明的路由记录、策略感知模型选择和任务级成本报告将成为产品的必要组成部分，而不是可选的可观察性功能。