Copilot Fusion 本地模型预览怎样划分云端与设备端选择

Copilot Fusion 这次本地模型预览最容易被误解的地方，是把“模型在设备上运行”和“任务完全不经过云端”当成了同一件事。实际边界可以先记成一句话：设备端负责符合条件的本地推理，Copilot Fusion 仍负责云端的路由与编排判断。因此，选择 Standard 并不等于强制所有请求都在本机完成。

GitHub 在 2026 年 10 月 28 日的 Changelog 中宣布，Copilot Fusion 开始支持选择本地模型的实验性预览。它覆盖 GitHub Copilot CLI、Copilot app 和 Visual Studio Code，但不同接入方式的操作系统、硬件和配置要求并不相同。

官方公告：https://github.blog/changelog/2026-10-28-github-copilot-fusion-now-supports-selection-of-local-models/

Fusion 文档：https://docs.github.com/en/copilot/concepts/models/copilot-fusion

这次更新到底改变了什么

Copilot Fusion 不是一个单独下载到电脑里的模型，而是一个运行时路由与编排系统。它会根据任务、可用模型和所选 effort level，决定使用哪种执行模式与模型。现在，符合条件的本地模型也可以进入这张候选表。

公告给出的典型体验是：在 Copilot Fusion 中选择 Standard，系统可以在合适的任务上选择本地模型；如果任务需要更强能力，也可能继续使用云端模型。读者需要区分两个动作：

• 选择 Copilot Fusion：选择的是一个负责路由和编排的系统，不是某一个固定模型。
• 选择本地模型：表示当前客户端已经配置了可用的本地模型，或使用了符合条件的托管本地模型。

所以这项更新的价值不是“把 Copilot 变成离线软件”，而是让本地计算资源也能参与 Fusion Standard 的模型选择。

云端路由和设备端推理不是同一件事

可以把一次请求拆成两个概念层：第一层是 Copilot Fusion 对任务和候选模型的路由判断，第二层是被选中的模型在哪里完成推理。GitHub 文档明确说明，Fusion 会根据能力信号、任务复杂度和实时可用性选择执行模式；本地模型只是在满足条件时成为候选。

这会带来三个实际结论：

1. 开启本地模型后，仍然不能把 Copilot Fusion 当作网络隔离方案。
2. 本地模型可用不代表每个请求都会被它接管，Standard 仍然保留云端模型选择空间。
3. 如果组织策略、订阅计划或模型能力不满足要求，模型可能不会出现在 Fusion 的可选范围内。

如果你的目标是“尽量减少本地代码离开设备”，需要单独评估 Copilot 的数据、策略和离线能力边界；不能只看模型名称里出现了 local。

Windows 托管模型适合什么场景

Copilot CLI 和 Copilot app 都提供了 Windows 上的托管下载路径。官方资料列出的本地模型包括 MAI Code 1.1 Flash，另有 Flint NVFP4；具体可用项仍受客户端、硬件和预览状态影响。

Windows 托管路径的特点是：模型下载、提供商和运行时入口由客户端引导，但设备需要满足要求。以 MAI Code 1.1 Flash 为例，官方文档列出了 Windows、NVIDIA GPU、至少 96 GB 可用组合内存、至少 60 GB 存储以及相应版本的 llama.cpp 等条件。不要把“能打开模型选择器”误认为“设备已经满足运行条件”。

在 Copilot app 中，入口是设置里的 Model providers，选择 Windows ML；下载完成后，还要在 Experimental 中开启 Local model auto routing。对于 Copilot Fusion，要选择 Fusion Standard，系统才会在适合时考虑已经安装的本地模型。

BYOK 和跨平台本地模型怎么理解

另一条路径是自己管理模型和推理运行时，再通过兼容接口交给客户端使用。GitHub Copilot CLI 支持手动配置模型提供商，也能发现本机运行的 Ollama；公告还提到，CLI 的本地 Copilot Fusion 路由可以使用通过 OpenAI-compatible server 配置的模型，覆盖 Windows、macOS 和 Linux。

这条路径的责任边界更清楚：你负责模型下载、推理服务、资源占用和接口兼容性，Copilot 负责识别配置并在符合条件时参与路由。BYOK 配置成功也不自动意味着模型具备 Fusion 资格，文档特别提醒了“已添加或发现的模型”与“可被 Fusion 选中”是两个层次。

如果团队主要使用 macOS 或 Linux，CLI 加本地兼容服务更接近可行路径；如果团队使用满足硬件条件的 Windows 设备，并希望减少手工配置，Windows ML 托管路径更省心。两者都不等于完全离线，也都需要关注模型的安全保护、资源占用和组织策略。

三个客户端分别从哪里开启

这次预览在不同表面上的入口不完全相同。下面的命令和路径用于说明官方入口，不能替代你所在组织的策略配置。

Copilot CLI

CLI 需要启用实验性功能，再通过模型选择器处理本地模型或提供商配置：

# 启动 Copilot CLI 的实验性功能，用于体验本地模型路由预览
copilot --experimental

# 已经进入交互会话时，也可以为当前会话开启实验性功能
/experimental on

# 打开模型选择器，查看本地模型、云端模型和 Fusion 入口
/model

如果使用 Ollama 或手动配置的 OpenAI 兼容服务，先确认模型能提供工具调用和流式输出；这些能力是 Copilot CLI 使用自定义模型时的官方要求。

CLI 配置文档：https://docs.github.com/en/copilot/how-tos/copilot-cli/customize-copilot/add-llm-models

Copilot app

在 Copilot app 中，可以从 Settings > Model providers 添加提供商；Windows 托管模型使用 Windows ML。随后在 Settings > Experiments 中打开 Local model auto routing，再启动新会话并从模型选择器选择 Standard。

app 的 BYOK 适合已经有本地或云端兼容接口的团队，但凭据管理、模型服务可用性和客户端策略仍由使用者承担。

Copilot app 文档：https://docs.github.com/en/copilot/how-tos/github-copilot-app/add-llm-models

Visual Studio Code

VS Code 的官方公告入口是启用 chat.copilot.localModel.enabled，之后在模型选择器中使用 Copilot Fusion。由于这项本地自动路由能力仍处于实验性预览，设置名称、可用模型和入口可能随版本调整。

采用前先做这张边界清单

如果你的目标是减少云端推理、利用闲置硬件或试用本地代码模型，这次预览值得关注；如果目标是强制离线、统一企业审计或保证每个请求都使用同一个模型，则还需要单独设计网络、策略和模型治理方案。

相关问题

Copilot Fusion 选择的是模型还是路由系统？

选择的是路由与编排系统。Fusion 会根据任务和 effort level 选择模型与执行模式，用户不需要为每一步手工切换模型。

本地模型能否在 macOS 上参与 Fusion？

Copilot CLI 通过本地兼容服务配置的模型可以覆盖 macOS；Windows ML 的托管下载则是 Windows 专属路径。具体是否进入 Fusion，还要满足官方支持条件。

为什么已经发现本地模型，却看不到它参与 Fusion？

模型被客户端发现只是配置完成的一步，还可能受到实验性开关、模型能力、平台、订阅和组织策略影响。先区分“可直接选择”与“可被 Fusion 自动路由”这两个状态。