GitHub Copilot 将自动决定采用本地还是云端运行

GitHub 正准备为 GitHub Copilot 增加自动定向功能，以确定编程任务是在本地模型上执行，还是发送至云端模型，预计该功能将于 2026 年 10 月底前推出。这项计划留下了一个关键问题：在选择云端路径时，有多少聊天记录和仓库上下文可能会传输到云端？

Microsoft 在一篇由 GitHub 产品经理 Patrick Nikoletich 和 Windows 平台合作伙伴关系工程师 Stuart Schaefer 共同撰写的文章中披露了这一计划。该公告发布之际，GitHub Copilot 的新沙箱控制功能也已公开提供，但保护级别会因所使用的工具而异。

基于任务及其上下文的定向

GitHub 正扩展 HydraFusion 项目。该项目会为编程任务选择合适的模型，现在还将确定推理的运行位置。据公司介绍，Copilot 在本地推理与云端推理之间切换时，会考虑任务上下文和缓存状态，包括在多轮会话期间。

Copilot CLI、Copilot 应用和 Visual Studio Code 中的开发者将能够使用 Auto 模式，也可以手动选择本地模型。可选项包括通过 Windows ML 运行的 MAI Code 1.1 Flash 模型，以及兼容 OpenAI 的本地端点。

哪些问题仍不明确？

Microsoft 承认，“本地推理并不会使会话脱离互联网”。公司尚未说明 Auto 模式会向云端模型发送多少仓库上下文或聊天记录，也未说明开发者是否能够检查定向决策，或完全禁止使用云端。

对于执行严格代码和数据处理政策的团队而言，这种模糊性十分重要。选择本地模型可以让推理过程保留在设备上，但并不能阻止代理访问外部服务，或通过其工具执行网络请求。要获得完全本地的会话，开发者还需要限制这些工具的权限。

大型本地模型与较高的硬件要求

本地路径依赖 MAI Code 1.1 Flash。这是一个混合专家模型，总计包含 1370 亿个参数，其中 68 亿个参数处于激活状态。Microsoft 使用每个权重约 3.3 比特的混合精度量化，将模型缩减至 53 GB，比采用 bfloat16 格式的云端版本少 80%。公司还使用 speculative decoding 来加快本地推理。

首批发布面向配备 NVIDIA RTX Spark 处理器的 Windows 设备，例如 Surface Laptop Ultra；这些设备可提供最高 128 GB 的统一内存。在 25.6 万个 token 的上下文下，测得的内存消耗峰值为 75.5 GB。该数值并不只包括模型本身；系统、应用、运行时环境和 KV cache 还需要额外空间，而文件读取和工具结果接收会使缓存不断增长。

性能与安全隔离

量化模型在 SWE-Bench Verified 上取得了 70.8%，而全精度版本为 72.6%。在 Terminal-Bench 2.1 上，量化模型取得 66.29%，原始模型为 62.9%；该测试集包含 89 项任务，也就是说，在这一规模较小的测试中，差距相当于约三项任务。

Copilot 使用开源的 Execution Containers（MXC）库来实施隔离策略：Windows 上使用 ProcessContainer 的 BaseContainer 层，macOS 上使用 Seatbelt，Linux 上使用 bubblewrap。Shell 命令、部分本地 MCP 服务器和语言服务器（在获得支持的情况下）均受到操作系统施加的限制，无论使用的是本地模型还是云端模型。

而内置文件工具在代理进程内部运行，并依赖运行时环境检查；远程 MCP 服务器则不受本地隔离约束。即使是 Microsoft 称为离线工作流的演示，也没有明确其中使用的 GitHub 数据是通过网络获取的，还是已存储在本地。

为什么这条消息很重要？

这项变化并不只是让开发者设备运行一个更小的模型；它还将一个与代码处理位置有关的敏感决策交给自动定向机制。实际上，开发者将在云端模型的速度与本地执行的隐私性之间获得更大的灵活性，但在 GitHub 说明 Auto 模式发送哪些数据、是否可以审计其决策，以及是否能够强制使用本地运行之前，各团队都无法全面评估风险。因此，该公告尚不能证明 Copilot 真正提供了离线本地会话，也不能证明当前的内存要求适合大多数开发设备。