GitHub Copilot 走向混合推理：本地模型、MAI Code 1.1 Flash 与操作系统级沙箱

微软与 GitHub 在本周的一篇联合文章中宣布：到 2026 年 10 月底，GitHub Copilot 会自动判断一个任务更适合由设备端智能处理，还是应该交给云端规模的大模型。开发者不再需要自己管理基础设施选择——Copilot 会在后台协调本地与云端推理。首个目标平台是搭载 NVIDIA RTX Spark 的 Windows PC（例如 Surface Laptop Ultra，最高 128GB 统一内存、宣称最高 1 petaflop AI 算力）。为此微软 AI 做了一版本地化的 MAI Code 1.1 Flash：一个面向编码优化的混合专家模型，137B 总参数、6.8B 激活参数，经过量化与投机解码处理后落地运行。文章同时给出了内存账、基准数字，以及一套用 Microsoft Execution Containers（MXC）实现的操作系统级沙箱。

路由决策从你手里移到了工具里：这是本次发布的全部核心

这次改的是「谁来选」，不是「能不能离线」

把这次发布读准，关键在它的措辞。微软不是在卖「离线运行」，而是在卖「你不必再想用哪一个」。文章的原话是：Copilot 会自动协调本地与云端推理，而不是强迫开发者自己管理基础设施决策。这个定位很重要，因为它改变了评估标准：过去你评估的是本地模型的绝对质量，现在你要评估的是路由决策的质量——它有没有在该用云端的时候用云端，在该省钱的步骤上留在本地。官方把这一步描述为 Project HydraFusion 的延续，即「智能编排」不只在多个模型之间发生，还要跨越多个计算环境，包括边缘。

# The routing decision moves from you to the tool. That is the whole
# announcement: Copilot picks the environment per task.
ROUTING = {
    "who_decides": "GitHub Copilot, automatically",
    "available_when": "by the end of October 2026",
    "options": {
        "on_device": "local inference models on the laptop itself",
        "cloud":     "frontier models served remotely",
    },
    "developer_manages": "nothing - that is the point",
    "first_target_hardware": {
        "platform": "NVIDIA RTX Spark Windows PCs",
        "example":  "Surface Laptop Ultra",
        "unified_memory_gb": 128,
        "claimed_ai_compute": "up to 1 petaflop",
    },
}

# Read the framing carefully: Microsoft is not selling "run it offline".
# It is selling "stop thinking about which one to use".

内存账：先看能不能装下，再谈好不好用

本地推理首先是内存预算问题，而不是质量问题，微软给出的数字很具体：量化后模型权重 53GB，相比 BFloat16 云端版本缩减 80%；在 Surface Laptop Ultra 上以 256k 上下文运行时峰值内存 75.5GB。这个峰值足以把绝大多数开发笔记本排除在外——16GB 或 32GB 的机器装不下这套负载，无论量化后的权重看起来多小。而且权重只是账单的一部分：操作系统、你的应用、推理运行时，以及随智能体读取文件和接收工具结果而不断增长的 KV 缓存，都要额外占地方。文章还给了较短上下文下的吞吐数字：64k 上下文时提示处理 923.5 tokens/秒，128k 时 769.8。注意这是提示处理速率，不是生成速率，两者不能混着引用。

# Local inference starts as a memory budget question, not a quality
# question. Microsoft published the numbers; use them.
BUDGET_AT_256K_CONTEXT = {
    "model_weights_quantized_gb": 53,        # 80% smaller than BFloat16
    "peak_process_memory_gb":     75.5,     # measured on Surface Laptop Ultra
    "shared_pool_available_gb":   128,      # unified memory on RTX Spark
}

def fits_locally(ram_gb):
    # 75.5GB peak rules out almost every developer laptop. A 16GB or
    # 32GB machine cannot host this workload no matter how small the
    # quantized weights look on their own.
    return ram_gb >= 96

def also_reserve():
    # Weights are only part of the bill. The OS, your applications,
    # the inference runtime and the KV cache all need room - and the
    # KV cache grows as the agent reads files and takes tool results.
    return ["os", "apps", "runtime", "kv_cache"]

# Throughput at shorter contexts, per Microsoft: 923.5 tokens/sec prompt
# processing at 64k, 769.8 at 128k. Those are prompt-processing rates,
# not generation rates. Do not quote one as the other.

89 个任务上的 3.4 分 = 大约三道题

基准数字的细则

基准表藏在细则里。SWE-Bench Verified（500 个任务）上，完整精度版是 72.6%，量化设备版是 70.80%，作为对比的 GPT OSS 120B 为 32.0%。Terminal-Bench 2.1（89 个任务）上是 62.9%、66.29% 和 23.6%。诚实地读这组数字：量化让 SWE-Bench 掉了约 1.8 个百分点，幅度可信；Terminal-Bench 上量化版比完整版高 3.4 个百分点，但那个数据集只有 89 个任务，3.4 个百分点大约等于三道题——它不足以证明「量化让模型更好」。两个结果合起来支持的是一个保守结论：这个版本缩小了体积、没有损失太多能力。真正看起来有力的对比，是他们自己挑的开源权重基线：SWE-Bench Verified 上 70.8% 对 32.0%。

# The benchmark table is where the fine print lives.
BENCH = {
    # dataset_size: (MAI Code 1.1 Flash, GPT OSS 120B, quantized on device)
    "SWE-Bench Verified": (500, (72.6, 32.0, 70.80)),
    "Terminal-Bench 2.1": (89,  (62.9, 23.6, 66.29)),
}

def read_it_honestly():
    return [
        # Quantization cost 1.8 points on SWE-Bench Verified.
        "SWE-Bench: 72.6 -> 70.8 when quantized. Small, believable.",
        # Terminal-Bench: 89 tasks. A 3.4-point gap is about three tasks.
        "Terminal-Bench 2.1 has 89 tasks. 66.29 vs 62.9 is roughly three "
        "tasks - not evidence that quantization made the model better.",
        "Both results support 'shrank without much loss'. Neither supports "
        "'quantization improved quality'.",
    ]

# The comparison that does look strong is against the open-weight
# baseline they chose: 32.0% vs 70.8% on SWE-Bench Verified.

沙箱：本地和云端一视同仁

对安全团队来说，最值得关注的是沙箱设计。Copilot 使用微软开源的 Microsoft Execution Containers（MXC）来执行沙箱策略：Windows 上用 ProcessContainer 后端的 BaseContainer 层，macOS 上用 Seatbelt，Linux 上用 bubblewrap。启用后，Copilot 对 shell 命令施加操作系统级限制，并在受支持的情况下覆盖本地 MCP 服务器与语言服务器——而且这些限制无论任务跑在本地模型还是云端模型上都一样生效。这是正确的默认姿态：安全边界不该因为模型换了物理位置而改变。但有两处缝隙要提前知道。第一，Copilot 内置的文件工具运行在智能体进程内部，那里由 harness 对照沙箱策略做检查，而不是依赖操作系统强制隔离。第二，远程 MCP 服务器位于本地沙箱之外，只有在启用 MCP 沙箱控制时，Copilot 才会检查它们的连接策略。

# Sandboxing is the part that will matter to security teams, and it is
# applied identically to local and cloud runs.
SANDBOX = {
    "library": "Microsoft Execution Containers (MXC), open source",
    "default_tier": "BaseContainer of the ProcessContainer backend",
    "per_os": {
        "windows": "BaseContainer / ProcessContainer",
        "macos":   "Seatbelt",
        "linux":   "bubblewrap",
    },
    "scope": [
        "shell commands get OS-enforced restrictions",
        "local MCP servers, where supported",
        "language servers, where supported",
    ],
    "applies_to": "local and cloud models alike",
}

# Two gaps to note before you rely on it:
#   1. Copilot's built-in file tools run inside the agent process, where
#      the harness checks requests against sandbox policy instead of
#      relying on OS-enforced isolation.
#   2. Remote MCP servers sit OUTSIDE the local sandbox; Copilot checks
#      their connection policies when MCP sandbox controls are enabled.

HydraFusion 与编排的下一步

往上一层看，这次发布是 HydraFusion 的自然延伸。GitHub 已经有一个编排器，可以在任务级别选择一个或多个模型，在性能、成本与延迟之间取得平衡；现在这个编排扩展到了计算环境这一维度。它同时解释了为什么微软要自己做一版本地模型：如果路由层只能在「自家云端模型」和「别人的模型」之间选，那么「本地」这个选项根本不存在，边缘这条路就走不通。对企业来说，这意味着可评估的东西变多了——不只要问模型得分多少，还要问路由策略是否可审计、能否固定、出错时能否回放。

编排从「跨模型」扩展到「跨计算环境」

推进前该问的六个问题

《The New Stack》的报道指出了公告里最明显的空白：微软没有说明哪些上下文会离开本机、送往云端，也没有说如何阻止它。此外有一个演示细节值得标记：官方那个被描述为「离线工作流」的示例，用的是 GitHub issue 和 pull request 元数据，而不是文章前文提到的本地仓库与测试；文章没说这些元数据是从网络获取还是本地缓存，因此「离线」这个说法无法从已公开的材料里得到验证。推进前建议把六个问题写进评估清单：哪些上下文会离开本机、能否阻止；用量导出里能否逐请求看到是否本地执行；每条 shell 命令与 MCP 调用是否记录在你能读取的地方；设备在任务中途休眠时本地运行怎么办；能否为合规要求把某个工作负载固定到纯本地或纯云端；HydraFusion 的路由能否审计。

# What to ask before you turn this on for a regulated team.
BEFORE_ENABLING = [
    "Which context leaves the machine, and can we stop it? Microsoft has "
    "not specified what is sent to the cloud or how to prevent it.",
    "Does the usage export show, per request, whether it ran locally?",
    "Is every shell command and MCP call recorded where we can read it?",
    "What happens to a local run when the device sleeps mid-task?",
    "Can we pin a workload to local only, or cloud only, for compliance?",
    "How does HydraFusion route across models, and can we audit it?",
]

# The demo detail worth flagging: Microsoft's offline workflow example
# used GitHub issue and pull request metadata rather than the local
# repositories and tests. It did not say whether that metadata was
# fetched over the network or read from cache, so the "offline" claim
# is not verifiable from the published material. Ask the question.