GitHub Copilot 不再纯云端：Surface Laptop Ultra 本地推理吞吐量最高每秒 63 个词元

GitHub Copilot 不再纯云端 AI 模型：Surface Laptop Ultra 本地推理吞吐量最高每秒 63 词元 — ithome.com · 49 分钟前 · 🛠 工具 / 开源

微软在旧金山发布会上宣布，GitHub Copilot 将在本月底前支持设备端本地推理，开发者可以在云端与本地之间自动或手动切换，这打破了该编程助手长期以来完全依赖云端托管权重的形态。Copilot 目前由协调器按性能、成本与准确性路由请求，扩展后该机制将同时覆盖云端与本地两种执行位置，用户可在 Copilot CLI、Copilot 应用与 Visual Studio Code 中设定偏好，选择自动编排或强制走设备端。本地侧提供两条路径：通过 Windows ML 调用微软自家的 MAI Code 1.1 Flash，或接入兼容 OpenAI 接口的本地端点并使用其暴露的权重。MAI Code 1.1 Flash 采用混合专家架构，总参数 1370 亿、活跃参数 68 亿，借助量化与推测解码压低内存占用并提升响应速度。官方在 Surface Laptop Ultra 上的实测显示，复杂任务中的峰值内存使用率、词元利用率与处理速度均有明显改善；当提示长度从 2K 扩展到 256K 词元时，解码吞吐维持在每秒 40 至 63 个词元之间。作者认为，本地推理让代码补全在离线、低延迟与数据不出设备等场景下更可用，但实际体验取决于终端算力与内存，云端仍会在复杂任务上承担主要角色。

核心信息

功能与时间点：微软计划在本月底前让 GitHub Copilot 支持本地推理，开发者可在 Visual Studio Code、Copilot CLI 与 Copilot 应用中设置偏好，选择由后台自动编排，或强制使用设备端执行；云端一侧仍由协调器根据性能、成本与准确性来路由请求，本地执行只是被纳入同一套调度逻辑之中。
权重规格：MAI Code 1.1 Flash 为混合专家架构，总参数 1370 亿、活跃参数 68 亿，通过量化与推测解码优化响应速度与内存占用。开发者可通过 Windows ML 选择它，也可以连接兼容 OpenAI 接口的本地端点，并选用该端点暴露出来的权重，等于把选择权同时交给微软自家方案与第三方实现。
实测数据：在 Surface Laptop Ultra 上，复杂任务中的峰值内存使用率、词元利用率与处理速度均显著提升；解码吞吐量测试覆盖 2K 到 256K 词元的提示长度区间，结果介于每秒 40 至 63 个词元之间，说明即使上下文拉长，速度也没有出现断崖式下滑。
权衡与边界：本地执行让补全在断网、弱网或数据不能出设备的场景下依然可用，延迟也更可控，但吞吐与可承载的上下文长度受终端算力、内存与功耗限制；在超长上下文重构这类重任务上，云端方案在速度与效果上仍有优势，两种位置更可能是分工而非替代。

💡 为什么值得读: 它给出了端侧编程助手少见的硬指标——参数规模、活跃参数与真实吞吐区间，能帮你判断本地补全离日常可用还有多远。

✍️ 小编看法: 小编看法：把推理搬到笔记本上，最直接的意义不是省下那点订阅成本，而是让补全摆脱网络往返。写代码时最烦的往往不是答案不够聪明，而是等待——云端一次请求动辄几百毫秒，连续补全时这种延迟会被放大成节奏的断裂。每秒 40 到 63 个词元的速度，已经接近人类阅读代码的节奏，放在行内补全和短函数生成上完全够用，但别指望它在超长上下文的重构任务里替代云端。真正值得关注的是 1370 亿总参数、68 亿活跃参数这个组合，它说明端侧走的仍然是稀疏激活路线，用较小的活跃计算量换取更大的知识容量，代价是权重仍需占用可观的内存与显存，所谓本地运行其实是把成本从订阅费转移到了硬件购置和电池续航上。对企业用户而言，代码不出设备这一条可能比速度更有吸引力，尤其是受合规约束的行业，但这也带来新的管理问题：终端上的权重版本如何统一、审计日志放在哪里、员工离职后本地缓存怎么清理，都不是发布会会讲的内容。下一步值得观察的是三条线：一是自动编排的判定逻辑是否透明可调，二是长上下文场景下端侧的实际衰减曲线，三是硬件换代周期会不会因为端侧推理需求而被压缩。

🏷️ GitHub Copilot, local inference, LLM, on-device AI