Copilot Fusion 开始路由本地模型：MAI Code 1.1 Flash 可被编排进同一次会话
GitHub 于 2026-10-28 把 Copilot Fusion 的本地模型路由推入实验性预览：Windows 可托管下载 MAI Code 1.1 Flash，CLI 与自建 OpenAI 兼容服务也能接入。
2026-10-30 · GitHub Changelog（官方一手，2026-10-28）
发布 2026-10-30核实 2026-10-30要点
- 2026-10-28，GitHub 把「本地模型智能路由」推入 experimental preview。官方原文："Today we are shipping intelligent routing for local models into experimental preview. GitHub Copilot Fusion can now choose between supported on-device models and cloud models."
- 覆盖三端：GitHub Copilot CLI、GitHub Copilot app、Visual Studio Code。这是一个 opt-in 的实验性预览，不是默认行为。
- Windows 托管下载：受支持的 Windows 设备可通过 Windows ML provider 下载并配置 MAI Code 1.1 Flash。三端的开启路径不同——CLI 需先开 experimental mode 再进
/model跟随提示；app 需在 Settings > Model providers 配 Windows ML provider、在 Settings > Experiments 打开 Local model auto routing，然后新开一个会话；VS Code 需设置chat.copilot.localModel.enabled。 - 官方称 Windows 上 Windows ML local models 已默认启用（"Windows ML local models is enabled by default on Windows."）。
- 怎么用：在 Copilot Fusion 里选 Standard 档，让 Copilot 在合规的本地模型与云模型之间自行选择；也可以直接指定本地模型跑整个会话。
- 自带模型（BYO）：托管下载仅限 Windows，但 CLI 侧的本地 Fusion 路由在 Windows / macOS / Linux 上都可用——自己起一个 OpenAI 兼容的本地服务，配置 MAI Code 1.1 Flash 或 Qwen3.8 Flash Next，模型下载与推理运行时由你自己负责，设备须有足够资源。
- 两条硬边界必须记住：① 通过 BYOK 添加或发现的模型，不会自动获得 Copilot Fusion 的路由资格（"Adding or discovering a model through bring your own key (BYOK) configuration doesn't automatically make it eligible for Copilot Fusion."）；② 本地推理不等于离线——"Copilot Fusion still makes routing decisions in the cloud, and local models may have different safety protections from Copilot-provided cloud models."
- app 侧的范围更窄：app 支持通过 BYOK 连接并直接选中兼容的本地模型，但其智能路由目前只支持托管的 Windows ML 模型。
背景与分析
「本地 vs 云」从两个入口变成路由器的一个分支
这条变更要放在 Copilot Fusion 转正 的上下文里看：Fusion 的定义是「你选的不是一个模型，而是一个为每个任务路由与编排模型的系统」。在 Fusion 之前，本地模型是一个需要自己切换、自己承担编排成本的平行入口；在 Fusion 之后，本机算力变成了路由可达的一种资源。
这也是官方把它叫 intelligent routing 而不是「支持本地模型」的原因：决策权在系统，不在你。 你只决定要不要把本地算力交给这个系统调度（Standard 档），或者绕过调度直接钉死本地模型。
三种接入姿势的边界完全不同
| 接入方式 | 平台 | 是否参与智能路由 | 谁负责模型 |
|---|---|---|---|
| 托管下载（Windows ML provider） | 受支持的 Windows 设备 | 是 | Windows ML 管下载与配置 |
| BYO 本地 OpenAI 兼容服务 | Windows / macOS / Linux（CLI 侧） | 是（CLI 侧） | 你自己管下载与运行时 |
| BYOK 直连（app） | app | 不自动获得资格 | 你自己管 |
这张表里最容易踩的是第三行：很多人以为「BYOK 里已经能看到的模型」就能被 Fusion 自动调度，官方明确说不行。 这条只对 app 侧写明，CLI 侧 BYOK 与路由资格的关系官方未逐条说明，本站不作推断。
「本地」这个词在这里有三重折损
官方自己就把话说明白了，值得逐条拆开：
- 不离线。推理在本机，但路由决策在云端——哪些任务该下放、哪些必须上云，是云侧判断的。网络不通时，本地模型不会自动接管。
- 不对等。本地模型的安全防护（safety protections）可能与 Copilot 提供的云模型不同。这意味着同一条提示词走本地与走云，可能被拒的边界不一样，对有合规要求的团队的审计口径是个新增变量。
- 不普惠。本地推理要吃本机资源，官方只说「设备须有足够资源」，未给最低配置清单。
AI 之家 观点
值得肯定的方向是：把「本机算力」纳入统一路由，比再做一个本地模式入口要正确得多。 对大量低风险、可重试的编码任务（格式化、批量改名、样板生成），把推理下放到本机在成本与延迟上都成立；而把复杂推理留给云，也正是 Fusion 分层设计的本意。
但要泼两盆冷水。第一，MAI Code 1.1 Flash 的具体规格本站未能逐字核对官方原文——媒体转引称其为 MoE、总参 1370 亿 / 激活 68 亿，并称微软报告 Surface Laptop Ultra 上 256k 上下文峰值内存 75.5GB。这些数字本站列为待核实，不作为选型依据。 第二，这是 opt-in 的实验性预览，官方连「受支持的 Windows 设备」清单都没在 changelog 里给出，团队落地前应先在一台机器上验一遍再推广。
最实际的风险是认知错位：一旦开了本地路由，团队里很可能有人以为「代码不出本机了」。按官方原文，路由决策在云、本地与云的安全策略也不一致，这个口径要先在团队里对齐，再谈隐私收益。
相关阅读
来源
- GitHub Copilot Fusion now supports selection of local models（GitHub Changelog，2026-10-28，官方一手）
- Route and orchestrate models with GitHub Copilot Fusion（GitHub Changelog，2026-10-28，官方一手）
待核实
- MAI Code 1.1 Flash 的官方参数（MoE 结构、总参 / 激活参数、上下文长度、峰值内存）：本站未读到微软官方原文，媒体转引数字不作为结论。
- 「受支持的 Windows 设备」清单与 Windows ML provider 的版本要求：changelog 未给出。
- Qwen3.8 Flash Next 的获取渠道与许可：官方仅列名，未给链接。
- 本地路由对 AI credits / 计费的影响：官方未说明本地推理是否计费。
- CLI 侧 experimental mode 的具体开启方式：官方只说 "enable experimental mode"，未给命令或配置项名。
- CLI 侧 BYOK 模型是否参与 Fusion 路由：官方只在 app 侧写了「不自动获得资格」，CLI 侧未明说。
本文由 AI 之家 编辑部依据 GitHub 官方 changelog 一手整理，未做安装与实测；功能状态与可用性以官方页面为准。