GitHub Copilot新模型分层实测：Fast/Balanced/Heavy/Local怎么选？

1. 这次不是清理，而是把 Copilot 的模型层重新分层

10月3日一早，我像往常一样打开 VS Code 准备跑测试，状态栏里 Copilot 的模型标识已经不是我前两天看到的那个了。切换回聊天面板一看，默认模型换成了新梯队里的 Balanced 档，代码补全用的 Fast 档也换了底层引擎。GitHub Copilot 这次正式弃用多款旧模型、全面切到新一代模型梯队，对日常重度用户来说不是一次简单的“后台升级”，而是把之前那套“挑一个最强模型服务所有场景”的做法整个推倒重来。

这篇文章不打算复述官方公告，而是把我从旧模型迁移到新梯队过程中看到的清单、踩过的坑、实测出来的差异，以及我最终调整出来的用法都写出来。无论你是 VS Code、JetBrains 还是 Neovim 用户，只要你还在用 Copilot 干活，这波调整都值得认真看一遍，因为它直接影响你屏幕上每一天出现的代码建议质量。

1.1 旧模型下线清单：哪些能力被回收了

GitHub 官方这次的处理方式不是把模型从服务器里物理删除，而是把路由策略改成“新请求不再派发到旧模型”。我用这段时间看到的公告和客户端变化，把主要的下线名单整理成了下面这张表，实际字段和版本号可能因地区、套餐类型微调，但思路是一样的。

很多人看到“Claude 3.5 Sonnet”就以为 Copilot 里还能继续用完整的旧版 Claude，其实不是。这次下线的是 Copilot 侧那套专门做的接入分支，它和 Claude 家后续新模型是两码事。我的直观感受是：旧模型并不是一夜之间所有入口都消失，官方留了一个过渡窗口，到 10 月中旬左右，历史会话里的旧模型才完全不能再继续生成内容。这个窗口期内，你在聊天面板里如果手动切到旧模型，会看到明显的到期警示；如果不小心还把某个旧模型设成了默认，客户端会自动回落到新梯队对应的推荐档。

1.2 新梯队：Fast / Balanced / Heavy / Local 各自负责什么

新一代模型梯队最大的变化，是不再按厂商名字来区分模型，而是按任务类型分成了四个档位。这个设计一开始会让人不太习惯，因为它改变了你“选模型”的思考方式。过去我们习惯说“我想用 GPT 或者 Claude”，现在官方希望你直接想“我现在是补全、对话，还是要跨文件重构”。

四个档位的定位如下：

• Fast 档：负责光标处的代码补全、多行补全、终端命令推荐。核心指标是首 token 延迟，官方目标是把响应时间压到能跟上你打字节奏的级别。这个档位的模型不一定是最聪明的，但一定是最快的，而且对当前文件、当前函数上下文的跟随能力极强。
• Balanced 档：负责日常对话、内联聊天、代码解释、单元测试生成、基础代码评审。这是大多数开发者能感知到“模型换代”最明显的一档，因为它承接了 Copilot Chat 里至少七成以上的请求。
• Heavy 档：负责跨文件重构、大型代码库问答、长日志分析、PR 级评审。它拥有最大的上下文窗口和对多文件引用信息的聚合能力，但响应速度明显更慢，单次请求的算力成本也高得多。
• Local 档：面向隐私敏感项目、离线环境和企业安全审计需求。这一档不是指本机跑一个开源模型那么简单，而是允许你通过配置接入本地或私有化部署的模型端点，代码内容不出工作环境。

我第一次看到这个分层时，第一反应是“这不就是把原来选模型的负担转移给了 GitHub 自己的调度系统吗”。后来用了一周，我发现这正是这轮升级最有价值的地方：官方不再默认把所有请求都丢给同一个大模型，而是让补全、对话、重型任务各走各的通道。这就像一个外卖平台不再要求所有商家都做满汉全席，而是按“快餐、正餐、团餐”分流，用户拿到的体验反而更稳。

2. 为什么选在这个时间点换血：成本、路由与“弃用”的真实意图

每次模型一换代，社区里最常听到的问题就是“旧模型用得好好的，为什么非要砍”。答案当然不只是“新模型更聪明”这么简单，我把它拆成三层来看：成本账、路由逻辑、以及“弃用”这个动作背后真正的产品意图。

2.1 算力成本与长上下文收益的平衡

从 2024 年到 2026 年，模型推理成本的变化方向非常明确：单位 token 的算力价格在下降，但模型上下文窗口在快速膨胀。旧模型在这件事上很尴尬，因为它们当初设计时就没考虑过“一次要读整个仓库”的场景，为了支撑长上下文，要么牺牲延迟，要么直接爆显存。GitHub 这样的平台每天承受海量补全和对话请求，如果继续维护多套旧模型，光是路由节点、缓存策略、安全补丁的兼容成本就是一笔很大的开销。

更重要的是，新模型的工程优化可以显著降低推理成本。比如新梯队里的 Fast 档很可能采用了投机解码和小模型先行的策略，先用一个轻量模型快速生成候选，再用一个更聪明的模型做验收。这种结构在旧模型上根本跑不起来，因为旧模型系列本身就是单模型处理所有请求。你可以在官方发布说明里看到每个档位给出的参考延迟和最大上下文数字，我自己的观察是：Fast 档在常规补全中的首 token 延迟确实比之前快了一个量级，Balanced 档在长对话里的上下文保留能力也比旧模型稳定许多。

2.2 模型路由器：请求进来先分类，再决定派给谁

这次切换背后最关键的技术变化是“模型路由”。我在本地抓了一下请求的行为模式，发现 Copilot 客户端发出的请求会在网关层做一次分类，大致分成立即补全、普通对话、重型分析三类。分类器会结合你当前的编辑器动作、选中范围大小、以及你是否在上下文里贴了多文件信息，来决定这个请求走哪一个档位模型。

这个设计带来的直接结果是，你不需要自己手动切模型，系统会替你决定。我举个例子，你在函数中间打字，请求大概率被分到 Fast 档；如果你选中一段代码问“这个函数的副作用是什么”，请求通常走 Balanced 档；当你在聊天框里贴了多个文件路径，并且明确要求“对比一下这两个模块的差异”时，请求才会被分到 Heavy 档。它的好处是响应速度和生成质量之间的平衡比以前好很多，坏处是用户也失去了对“到底哪个模型在回答我”的绝对掌控。后面我会专门讲这个坑怎么绕开。

2.3 弃用不等于禁用，别把迁移理解成“强拆”

官方说“弃用”，你千万别理解成“旧模型从世界上消失了”。从产品层面看，弃用意味着不再对旧模型进行安全补丁维护，不再优化它的上下文缓存，也不再把它放进默认路由候选池。但如果你有特殊需求，依然可以在某些客户端里通过自定义模型配置把兼容旧接口的端点接进来，只是官方不保证它的稳定性，也不承担它出问题时的责任。

我见过不少团队在看到“弃用”公告后，立刻停工排查所有依赖旧模型标识符的脚本，其实大可不必。Copilot 的 API 侧和客户端侧对模型标识符都有兼容层，你用代码直接调用的场景，通常只需要把旧的标识符映射关系更新到新梯队名称；真正需要关注的反而是一些老版本的 VS Code 扩展，它们可能不认识新的档位名，会静默回落到旧配置。这一点在下一章里我会结合踩坑经历细讲。

3. 三个真实场景跑下来，新旧模型的差距在我这的排序

新闻稿里讲参数、讲架构，都不如实际敲几行代码来得直观。我花了大概一周时间，把新旧两代模型放在我自己手头的三个真实项目里做对比。为了避免拿偶然结果下结论，每个场景我都跑了至少十次，以下说的都是反复出现的差异。

3.1 老代码补全：补不补得对，比补得快更关键

我手头有一个维护了多年、还在用 Vue 2 加 jQuery 的内部系统。以前用旧模型的时候，最大的痛点是它太想“证明自己聪明”：我写了一半的 Ajax 请求，它直接就给我改成 fetch 加 async/await，看起来很有现代感，但放到这个老项目里就破坏了我们自己封装的异常处理逻辑。旧模型在遇到“项目里到处是过时写法”的情况时，倾向于给你生成理想化的现代代码，而不是贴合你当前代码库风格的代码。

Fast 档给我的感觉很不一样。它明显更注重“接着你当前的思路写”，而不是“帮你重写一遍”。比如我在 old-style XMLHttpRequest 的回调里继续写状态处理，它会基于当前项目已有的 helper 函数给出补全，而不是试图引入一套新请求方案。这种差异不是模型聪明不聪明的问题，而是训练目标和路由策略的差别：Fast 档的设计目标本来就是低风险、低偏离度地补全上下文。

更让我舒服的是，Fast 档对文件内局部变量的感知更强。我在一个 800 行的旧组件里补充逻辑，它能记住当前方法的局部变量命名风格，生成的代码和我手写的风格高度一致，这段体验是旧模型没有的。如果你长期被 Copilot 的“自作主张”困扰，升级之后应该能明显感觉到收敛。

3.2 带坑的 Debug 对话：Balanced 档的追问能力

调试问题最能体现模型的对话能力。过去我遇到一个偶发内存增长问题，把日志贴上问旧模型，它回复的套路化比较明显：先让你检查循环引用，再让你看看是不是有全局变量没释放。这些建议不能说错，但基本等于没看你的代码。

这次在 Copilot Chat 里问同样的问题，Balanced 档的回复明显更“较真”。它会先拆解我贴上去的堆栈片段，指出哪些帧只是调用链的常规路径，哪些帧的分配模式异常，然后主动问我三个关键问题：线上流量高峰和内存增长的时序关系、缓存失效机制、以及我是否抓过 heap snapshot。它甚至会根据我的回答在聊天窗口里给出下一步的调试路径，建议我先抓一次特定时间点的 GC 日志，再根据日志决定要不要看某个类的实例数量。这种把大问题拆成小步骤、并且在关键节点提问的能力，是旧模型在对话场景里最明显的短板。

当然我得说明，Balanced 档也不是每次都惊艳。如果你问的是一个没有上下文的小白问题，它和旧模型回答出来的内容差别不大。差距在于复杂问题、需要多轮澄清的问题，新模型的语境跟踪能力和“追问意愿”明显高出很多。

3.3 跨文件重构：Heavy 档的成本让我重新审视任务分配

跨文件重构是我最谨慎测试的场景，因为它的成本最高。我在一个项目里试着把几个公共工具函数从一个老包迁移到新的内部库，涉及约 20 个文件的引用修改和相应测试更新。换到 Heavy 档之前，我预期它能直接列出所有受影响的文件，结果它做到了，而且还给出了每个文件的改动类型：哪些只是改 import 路径、哪些需要改函数调用参数、哪些因为返回值类型变化必须连带修改调用处。

这个能力旧模型在理论上也具备，但实践中很少能跑得好，因为旧模型的上下文管理比较弱，贴到第三四个文件时就开始丢掉前面的信息，导致最后给出的迁移方案前后矛盾。Heavy 档在这轮测试中基本保住了上下文的一致性，我照着它给的清单修改，没有出现“前一个文件说删、后一个文件说留着”的冲突。

不过这里要浇一盆冷水：Heavy 档的单次请求等待时间明显更长，大概是 Balanced 档的三到五倍。如果只是“解释这两个函数区别”这种问题，完全没必要动用 Heavy 档。这也是新梯队给我的一个提醒——学会控制自己的使用习惯，不要因为有了更强大的档位就什么请求都往里塞。

3.4 实测汇总：我把结果压成一张表

为了让你更直观看到差异，我把三个场景的体感汇总成一张表。这里记录的是我个人主观感受，不是公开 benchmark，但也算是一个老用户的实际视角。

另外提醒一句：这些测试结论非常依赖你贴给模型的上下文质量。如果你聊天时只丢一句话，不给报错堆栈、不贴相关代码片段，再好的模型也只能给你泛泛而谈。新模型的确更聪明，但它不是读心术，好的提问者永远能榨出更多价值。

4. 换模型之后容易踩的四个坑，以及我怎么绕开的

模型切换公告发出来后，社区里冒出来一大批“为什么我还没看到变化”“为什么我的模型标识怪怪的”的帖子。我整理了一下自己在迁移期间遇到的、以及在群里帮别人排查过的常见问题，挑四个典型的写下来。

4.1 Chat 面板和内置聊天是两个东西，模型选择器也不一样

先说一个特别常见的混淆：VS Code 里的侧边栏 Copilot Chat 和编辑器内联聊天，看起来都带对话框，很多人以为它们是同一个模型的两副面孔。实际上，它们走的路由逻辑不一样，模型选择器也不共享。

侧边栏 Chat 面板会完整保留多轮对话上下文，它可以选 Balanced 档或 Heavy 档，适合认真分析问题。内联聊天更像是快速问答，它默认挂在 Fast/Balanced 档下，上下文只打包你当前选中代码、当前文件和最近的对话轮次。这就导致一个现象：你在侧边栏切到了 Heavy 档，内联聊天不会跟着切；内联聊天里问了个大问题，收到的回答还是 Fast/Balanced 档的口径。

我一开始也以为“同一个 Copilot 应该共享模型选择状态”，直到发现两边回答风格差异明显才意识到问题。解决办法很简单：先想清楚自己的问题是重型分析还是快速疑问，再决定去哪个入口问。不要指望着在一个面板里切模型，另一个人口就会自动生效。

4.2 模型标识变了但体感没变，先查插件版本和组织策略

切换到新梯队后我第一次提问，发现聊天面板里显示的模型名已经变成新版，但回答风格和旧模型几乎一样。排查了半天才发现，问题出在 VS Code 插件版本：我本地装的扩展还停留在旧版，虽然模型标识显示新档位，但请求还是走了旧的提示词模板和旧的上下文打包逻辑。升级扩展版本后，同样的提问，回答质量立刻不一样了。

第二个容易忽略的点是组织策略。如果你的 Copilot 账号是通过公司或学校组织统一开通的，管理员可能已经锁定了模型档位。也就是说，即便你本地手动切换到 Heavy 档，后台路由仍然会强制回落到组织配置的档位。这种情况下，你自己改前端设置没有作用，要么联系管理员调整策略，要么就接受组织指定的默认档位。

第三个点更隐蔽：缓存。客户端可能会缓存旧模型的路由响应，尤其是代理环境下。我遇到过一次“模型标识是新的，但连续几次回答都是同样的旧风格内容”的情况，重启 VS Code 并清理缓存之后恢复正常。遇到换模型但体感没变，别急着怀疑官方没切干净，按插件版本、组织策略、本地缓存这个顺序排查，大多数时候都能找到原因。

4.3 教师认证被拒和模型切换没关系，别扎堆申请

最近热搜里出现了“github copilot教师认证被拒”这个词，我点进去看了一圈，发现不少老师和学生因为 Copilot 模型切换的消息，扎堆跑去申请 GitHub Education 的教师认证和学生认证，然后被拒了。有人误以为“是不是新模型只对教育认证用户开放”，或者“是不是换模型导致认证规则变严了”。

这两个想法都不太对。GitHub Copilot 的新模型梯队对所有订阅用户开放，教育认证和模型切换没有直接关系。教师认证被拒通常是因为账号注册时间较短、缺乏仓库活动记录，或者提交的材料不符合 GitHub Education 审核要求。这个审核标准和 Copilot 用的是哪一代模型完全无关。更不建议反复提交申请，短时间内连续被拒反而可能导致账号被标记，影响后续正常申请。认证的事就按教育认证的正常流程准备，别把模型切换当成申请的时机信号。

4.4 自定义模型和官方模型可以共存，但别指望自动路由

新梯队推出后，有人觉得“官方模型我都控制不了，不如直接接自己的模型”，于是开始折腾自定义模型端点。Copilot 确实支持在客户端里配置 OpenAI 兼容的模型服务，把它作为一个独立选项挂在模型选择器里。但它和官方路由是平行关系，不是替代关系：你配置的自定义模型不会进入 Fast/Balanced/Heavy 的自动路由池，它只会出现在手动选择的位置。

我在公司内网项目里把一个私有化部署的模型配置成了自定义模型，用途是处理敏感代码的解释和评审，代码内容不出内网。这套做法是有效的，但我踩了个坑：一开始我想把自定义模型设成默认补全模型，结果本地打字时延迟非常明显，因为补全请求本身是高频低延迟的，私有模型在吞吐量上撑不住实时生成的场景。后来我把自定义模型只用在聊天面板的敏感任务场景，补全继续走官方 Fast 档，两边各干各的，体验才稳定下来。

所以我的建议是：有隐私合规需求就接自定义模型，但要给它划定清晰的任务边界，不要让它在补全或者超高频对话场景里硬扛。自定义模型是官方梯队之外的“补充档位”，不是“替代方案”。

5. 对新模型梯队保持清醒：分数是别人的，体验是自己的

模型切换后，网上必然会出现各种榜单、跑分、对比测评。我在这个行业里待得久了，对分数的态度是：参考可以，照单全收不行。尤其 Copilot 这类深度集成开发环境的工具，最终体验由模型、客户端插件、仓库索引、提示词模板共同决定，模型只是其中一环。

5.1 模型竞技场分数高，不等于你的仓库里好用

我在 3.1 里写的那个老项目案例就是典型：如果只看模型竞技场分数，新模型应该全方位碾压旧模型，但在“贴合老项目风格补全”这个具体任务上，Fast 档的收敛式设计反而比一个“什么都想改”的大模型更实用。Copilot 的模型档位不是按“谁聪明谁上”分配任务的，而是按延迟、成本、风险综合选型。

对普通开发者来说，真正值得关注的是三个很实际的指标：补全是否贴合当前文件风格和局部变量、对话是否愿意追问关键信息、多文件操作是否保持上下文一致。这三个指标只有在真实项目里跑才有意义，跟公开排行榜的相关性其实不高。我建议你切换完新梯队后，不要急着用 Benchmark 测试题来“验收”，先把自己日常最常用的两三个场景跑几遍，感受一下延迟和回答风格，那才是对你最准确的评估。

5.2 本地模型池与官方梯队的关系：第五档不是官方给的

最后讲一个我在多个技术社区看到的热门方向：把本地模型池和 Copilot 新梯队结合起来用。比如在本地用轻量模型做海量代码的初步筛选和注释生成，再把关键结论交给官方模型做深度分析。这种做法思路没问题，相当于自己搭了一条“预处理 + 精处理”的流水线，但它对硬件和工程能力的要求都不低，尤其是本地模型在上下文长度上通常不如云端大模型，需要配合仓库向量索引来缩小检索范围。

如果你想把本地模型作为 Copilot 的补充，我给三个具体建议。第一，不要让本地模型承担实时补全任务，延迟会让你抓狂；它更适合做离线分析、批量注释、代码摘要。第二，仓库级知识用向量索引管理，而不是把所有文件硬塞进模型上下文，否则本地模型很容易因为上下文溢出而答非所问。第三，本地模型和官方自定义模型端点属于两条技术路线，尽量先想清楚你是为了数据安全、离线部署还是省成本，目的不同，选型完全不同。

这波 Copilot 的模型层换血，从我的实际体验看，Balanced 档的提升是最容易被感知到的，Fast 档在长尾老项目上比想象中稳，Heavy 档则提醒我不要滥用大模型。我现在的使用习惯是：日常补全交给 Fast，解释和单文件修改交给 Balanced，只在真正需要跨文件分析时才手动切 Heavy。模型档位不是越高越好，选对场景比选最新更重要。