用 Copilot 却只能用官方预置的那几个模型这事儿已经困扰我很久了。GitHub 官方给的模型虽然够用但想接 DeepSeek 的高性价比模型或者自己私有化部署的模型时很多人的第一反应是去装各种第三方转发插件——绕一圈回来不但多了一层维护成本Copilot 的原生体验也被破坏了。其实 VSCode 的新版本里已经内置了自定义模型供应商的注册机制不需要额外插件只要改一处配置就能让 Copilot 直接走 DeepSeek、GPT 或者其他任意兼容 OpenAI 接口的模型。这篇文章就从 Copilot 的模型接入原理说起把配置步骤、参数含义、踩坑链路一次讲清楚适合所有在用 VSCode 和 Copilot、又想换模型试试的开发者。1. 为什么要把 Copilot 从官方模型换成自己的模型1.1 官方预置模型的限制与真实换模型需求先说一个很多人的共同感受官方 Copilot 的模型选择看起来不少但实际上都集中在 GitHub 和 OpenAI、Anthropic 合作的几条产品线上。模型好不好用是一回事够不够用是另一回事。当你面对的代码库用了比较特殊的框架或者团队内部有自己微调过的模型官方那几个通用模型往往不是最优解。我自己的场景就很典型。一方面我常年要处理大量重复性的样板代码DeepSeek 这类模型的输入输出价格比官方模型低一大截用来跑批量任务非常划算另一方面有些项目涉及内部接口细节我更想把模型完全换成自建服务数据不出内网。这些需求凑到一起就必须让 Copilot 能接任意符合 OpenAI 接口规范的模型。标题里强调的无需额外插件其实就是指VSCode 本身已经提供了模型供应商的注册入口不需要再装一个中间代理插件来把 Copilot 的请求转发到别的模型服务上。1.2 Copilot 的自定义能力到底在哪一层很多人有个误区觉得 Copilot 是个黑盒模型是焊死在 GitHub 服务里的。实际上 VSCode 里的 Copilot 只是客户端负责把编辑器上下文、用户输入、文件内容组装成请求发给模型服务。只要模型服务暴露的接口格式对得上客户端根本不关心对面跑的是 GPT 还是 DeepSeek。从架构上看这里有两层第一层是 Copilot 扩展本身负责 UI、上下文收集、命令交互这些编辑器侧的能力第二层是模型通信层VSCode 原生通过 Model Provider 的注册机制来决定请求发到哪个 baseUrl用哪个模型名。第三方便利之处就在这里不碰第一层只改第二层的配置就能把模型从官方默认换成自定义的。这也是无需额外插件这句话的底气来源——你不需要去改 Copilot 扩展的行为只需要在它的原生配置里多加一个模型供应商。2. 不装插件的底气模型供应商注册机制是怎么工作的2.1 OpenAI 兼容协议是这座桥既然要对接任意模型就必须有一个大家都认的接口标准。目前事实上的标准就是 OpenAI 的 chat/completions 接口客户端发一个 POST 请求到{baseUrl}/chat/completions带上model、messages、stream这些参数服务端返回补全结果。DeepSeek、通义、本地部署的 Ollama 服务几乎全都实现了这套协议。这里要特别注意的是 baseUrl 的取值。以 DeepSeek 官方 API 为例请求地址是https://api.deepseek.com完整接口路径是/chat/completions很多教程让人写https://api.deepseek.com/v1其实 DeepSeek 兼容了/v1这个前缀两种写法都能通。但你换成其他模型服务时这个路径就不一定了必须去看对应服务商的文档。VSCode Copilot 的自定义模型配置之所以能一套通吃就是因为它在客户端侧只认 OpenAI 兼容协议。你把任意一个提供 OpenAI 兼容 API 的服务地址填进去剩下的事就只剩填模型名和 API Key。2.2 对话接口与补全接口的差异真正容易忽略的是Copilot 不是一个单一接口在干活。它至少有两套请求逻辑Chat 对话侧边栏对话、内联聊天走的是标准的/chat/completions接口行内补全灰色幽灵文本那种走的是 FIMfill-in-the-middle格式这种格式会在请求里额外塞prefix和suffix让模型根据光标前后的代码来补中间的部分。这就解释了为什么很多人换完模型以后发现一个诡异现象Chat 窗口里模型回答得挺好但编辑器里的行内补全却迟迟不出现或者补出来的东西明显不连贯。原因是模型不支持 FIM。DeepSeek 官方 API 的deepseek-chat模型对代码补全的 FIM 支持只能说一般本地部署的小参数模型更常见的情况是完全不认 FIM 字段。所以配置自定义模型时一定要把对话链路和补全链路分开评估别指望一个模型把两件事都干得漂亮。3. 配置步骤把 DeepSeek 设成 Copilot 的默认模型3.1 前置准备动手之前先把三样东西准备好。第一一个模型服务的 API Key。以 DeepSeek 为例去开放平台注册后在控制台创建一个 API Key形如sk-开头的一串字符。注册时一般会送一点体验额度足够做完这套测试。第二确认你的 VSCode 版本。自定义模型供应商入口在 1.99 之后的版本里才比较完整建议直接用最新的稳定版。老版本不是不能用但可能找不到图形化入口只能手改配置。第三备份现有配置。VSCode 的设置文件是settings.json在命令面板里输入 Preferences: Open User Settings (JSON) 就能打开。改动之前把原文件内容复制一份避免配置写崩了还要凭记忆恢复。3.2 图形界面通过 Manage Models 添加私有模型多数人不知道 VSCode 其实提供了图形化的模型管理入口。打开命令面板CtrlShiftP输入 Chat: Manage Model Providers或者在新一点的版本里叫 Manage Models回车进入。在模型管理界面里能做三件事查看当前已经注册的模型供应商和模型列表添加新的供应商需要填供应商 ID、baseUrl、API Key对已注册的模型做启用或停用。以 DeepSeek 为例在添加供应商界面里填Provider IDdeepseekBase URLhttps://api.deepseek.comAPI Key你的sk-开头的密钥保存之后界面上会让你勾选可用的模型。DeepSeek 官方目前主要提供两个模型名deepseek-chat对应 V3 系列对话模型deepseek-reasoner对应 R1 系列推理模型。两个都勾上等会儿在模型下拉框里能直接切换对比。这个图形化入口的底层逻辑就是往配置里写入模型供应商字段所以如果你用的是老版本 VSCode 找不到这个界面也可以跳过这步直接改 settings.json。3.3 settings.json 的完整配置模板图形界面操作完配置文件里会自动多出类似下面的内容。我自己更习惯直接手写配置因为可控性更强。下面是完整的模板{ chat.modelProviders: [ { id: deepseek, baseUrl: https://api.deepseek.com, apiKey: ${env:DEEPSEEK_API_KEY}, models: [ { id: deepseek-chat, name: DeepSeek Chat }, { id: deepseek-reasoner, name: DeepSeek Reasoner } ] } ] }几个关键点需要解释。baseUrl不要带/chat/completions这个尾巴Copilot 会自动拼接。如果你填了/v1最好先确认服务商是否兼容这个前缀否则会出现 404。apiKey字段我用的是${env:DEEPSEEK_API_KEY}。这种写法是让 VSCode 从环境变量里读取密钥而不是把 API Key 明文写在配置文件里。尤其当你开了配置同步或者会把settings.json提交到公司仓库时明文密钥等于裸奔。设置环境变量的方式取决于你的操作系统Windows 可以用setx DEEPSEEK_API_KEY sk-xxxmacOS/Linux 在 shell 配置文件里 export 即可。models数组里id是请求时会发送给服务端的模型名必须跟服务商的模型命名完全一致不能自己发明名字。name只是显示名随便取模型下拉框里展示用。3.4 验证模型是否生效配置写完之后重启 VSCode 让配置生效。怎么确认真的接上了先看 Copilot Chat 面板的模型切换下拉框正常情况下会出现 DeepSeek Chat 和 DeepSeek Reasoner 两个选项。随便选一个发一句测试消息比如用 Python 写一个读取 CSV 并统计每列空值的函数。如果模型回答了说明对话链路已经通。接下来还要验证行内补全是否正常随便打开一个代码文件写一行注释然后换行看有没有灰色补全出现。如果对话正常但补全不出现不用慌这不是配置失败是模型对 FIM 的支持问题后面第五节我会单独说。还有一个排查利器打开 VSCode 的输出面板查看 - 输出下拉框里选择 GitHub Copilot Chat所有请求日志都会打在这里。配置有没有生效、请求报了什么错基本都能从这里看到。4. 实测中的拦路虎认证失败、模型名不合法、补全失灵4.1 401 认证失败先看环境变量有没有进来我见过最多的报错是 401 Unauthorized。配置明明填了 Key但请求就是过不去。排查链路是这样的第一步打开输出面板里的 GitHub Copilot Chat 日志看请求实际发出的 API Key 是什么。如果日志里显示 Key 是空的或者显示的是${env:DEEPSEEK_API_KEY}这串字面量说明环境变量没有被 VSCode 识别第二步检查你是不是在配置完环境变量之后才启动的 VSCode。环境变量的读取发生在进程启动时改完环境变量不重启编辑器新值不会生效第三步验证 Key 本身能不能用。不要猜直接在终端里用 curl 测一下curl https://api.deepseek.com/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-your-key \ -d { model: deepseek-chat, messages: [{role: user, content: ping}], stream: false }这条命令能通说明 Key 和服务端都没问题问题一定出在 VSCode 侧的密钥读取上。能通且返回了内容再回来看配置里的 apiKey 字段是不是写成了字面量而非环境变量引用。4.2 400 模型名不存在命名必须跟服务商对齐第二个高频报错是 400 Bad Request日志里通常会跟着一条 model not found 或类似的提示。这个坑十有八九出在模型名上。有些服务商的模型名带有版本后缀比如gpt-4o-2024-08-06有些则像 DeepSeek 这样用deepseek-chat这种比较抽象的名字。你在配置里填的 id 必须和服务商 API 文档里写的完全一致大小写也不能错。以 GPT 为例如果你用的是 OpenAI 官方接口模型名要填gpt-4o这类官方命名如果你是通过 Azure OpenAI 接入模型名规则又不一样通常是自己部署时给模型起的 deployment name。遇到 400 不要猜直接拿上面那条 curl 命令把 model 字段改成你的配置值请求一遍。curl 能过就是 VSCode 配置里写错了curl 报错就照着错误提示去改模型名。4.3 流式响应中断回复到一半就断掉还有一个比较隐蔽的问题模型回复到一半突然停住转圈圈转一会儿然后报错。这类问题在日志里往往看不出明显异常或者只有一个 stream 相关的错误。这多半是流式响应SSE连接的问题。Copilot 默认走流式输出服务端会一段一段地往客户端推数据。如果中间网络抖动或者有超时限制连接就会断开。我的实测经验是如果接的是本地模型比如 Ollama先确认模型完整加载到内存里了再试很多本地推理框架在冷启动时会因为模型加载慢导致超时如果接的是远端 API检查公司网络里有没有超时很短的代理拦截SSE 长连接是重灾区个别模型服务端对流式输出的实现不严格偶尔会漏发结束标记这在日志里表现为响应结束了但状态是异常。这种问题只能换模型服务端版本客户端侧无解。4.4 行内补全失灵FIM 接口是个隐形门槛第三节末尾我留了个悬念对话通但补全不来。这里展开说说。Copilot 的行内补全用的是 FIM 格式请求体里除了普通的 messages还会包含prefix和suffix两类字段。并不是所有 OpenAI 兼容接口都实现了这套扩展。DeepSeek 官方 API 对 FIM 是有一定支持的但我实测下来deepseek-chat的补全质量和 GPT-4o 这类原生的差距还是明显的偶尔会出现补一个重复的括号或者把注释当代码补完的情况。本地部署的小模型更直接——很多 7B、13B 参数的模型根本不认 FIM 格式请求打过去要么报错要么返回空。所以我在项目里的实际做法是拆开配置Chat 窗口用 DeepSeek 省成本行内补全保持官方默认模型。配置里把两种模型供应商都注册上用的时候在模型下拉框里手动切。虽然没办法做到同一屏同时用两个模型但日常使用已经够顺畅了。5. 进阶玩法本地模型与多模型切换的日常5.1 接 Ollama 本地模型数据不出内网如果你对数据隐私敏感或者想离线使用可以把自己的本地模型接到 Copilot 上。最常见的方案是 Ollama。Ollama 安装并启动后默认会监听127.0.0.1:11434。新版 Ollama 对 OpenAI 兼容协议做了支持http://127.0.0.1:11434/v1可以直接当作 baseUrl 用。在 settings.json 里再加一个供应商{ chat.modelProviders: [ { id: local-ollama, baseUrl: http://localhost:11434/v1, apiKey: ollama, models: [ { id: qwen2.5-coder:7b, name: Qwen Coder 7B Local } ] } ] }注意两个细节apiKey字段本地服务不校验随便填一个非空字符串占位就行但别留空有些版本留空会直接跳过这个供应商模型 id 要用你本机实际拉取过的模型名ollama list命令可以查看当前有哪些可用模型。本地模型最大的限制是上下文长度。像 7B 这种小参数量模型配置里最好把上下文窗口调小一点别让 Copilot 把超大文件整个塞进去。上下文越长显存占用越高推理越慢还容易报显存不足。5.2 多模型分工建议别指望一个模型通吃把整个链路跑通之后你手上可能已经有 2 到 3 个可用的模型供应商官方默认、DeepSeek、本地 Ollama。我的建议是给它们分工而不是每次手动换来换去。日常写业务代码行内补全用官方默认模型因为 FIM 支持最成熟补全速度和质量最稳做批量重构、写单元测试这种一次性大任务切到 DeepSeek成本低上下文窗口大涉及敏感代码或者断网环境才切本地模型。切换的路径很顺手Copilot Chat 面板的模型下拉框点一下就能换行内补全的模型在设置里指定默认项不需要每一次都改配置文件。5.3 团队共享配置的成本控制如果你是在团队里推广这套方案还有一个容易踩的坑API Key 共享。不要把个人 Key 直接写进团队共享的 settings.json 里。正确做法是把apiKey字段全部改成${env:XXX_API_KEY}然后在团队文档里写清楚每个人需要自己配置哪些环境变量。这样就算有人离职只需要吊销他自己的 Key不会影响别人。成本控制也要提前想好。DeepSeek 虽然便宜但 Copilot 的请求频率很高尤其是行内补全几乎打字就触发。如果所有请求都走付费 API一个月的账单可能超出预期。我个人的经验是个人开发场景用 DeepSeek 完全没问题团队高频场景优先切回按席位付费的官方模型把自定义模型用在特定任务上成本才能压得住。最后再分享一个小技巧。整套配置跑通之后建议把常用的模型供应商配置整理成一份自己的配置笔记每次换电脑或者升级 VSCode 后直接照着配。配置本身不复杂真正花时间的反而是对照日志排查那几类错误——401 查 Key、400 查模型名、补全失灵查 FIM。把这套排查顺序记下来下次接新模型基本十分钟内能搞定不用再被各种第三方插件绑架。
VSCode Copilot 免插件接入 DeepSeek：自定义模型供应商配置指南
用 Copilot 却只能用官方预置的那几个模型这事儿已经困扰我很久了。GitHub 官方给的模型虽然够用但想接 DeepSeek 的高性价比模型或者自己私有化部署的模型时很多人的第一反应是去装各种第三方转发插件——绕一圈回来不但多了一层维护成本Copilot 的原生体验也被破坏了。其实 VSCode 的新版本里已经内置了自定义模型供应商的注册机制不需要额外插件只要改一处配置就能让 Copilot 直接走 DeepSeek、GPT 或者其他任意兼容 OpenAI 接口的模型。这篇文章就从 Copilot 的模型接入原理说起把配置步骤、参数含义、踩坑链路一次讲清楚适合所有在用 VSCode 和 Copilot、又想换模型试试的开发者。1. 为什么要把 Copilot 从官方模型换成自己的模型1.1 官方预置模型的限制与真实换模型需求先说一个很多人的共同感受官方 Copilot 的模型选择看起来不少但实际上都集中在 GitHub 和 OpenAI、Anthropic 合作的几条产品线上。模型好不好用是一回事够不够用是另一回事。当你面对的代码库用了比较特殊的框架或者团队内部有自己微调过的模型官方那几个通用模型往往不是最优解。我自己的场景就很典型。一方面我常年要处理大量重复性的样板代码DeepSeek 这类模型的输入输出价格比官方模型低一大截用来跑批量任务非常划算另一方面有些项目涉及内部接口细节我更想把模型完全换成自建服务数据不出内网。这些需求凑到一起就必须让 Copilot 能接任意符合 OpenAI 接口规范的模型。标题里强调的无需额外插件其实就是指VSCode 本身已经提供了模型供应商的注册入口不需要再装一个中间代理插件来把 Copilot 的请求转发到别的模型服务上。1.2 Copilot 的自定义能力到底在哪一层很多人有个误区觉得 Copilot 是个黑盒模型是焊死在 GitHub 服务里的。实际上 VSCode 里的 Copilot 只是客户端负责把编辑器上下文、用户输入、文件内容组装成请求发给模型服务。只要模型服务暴露的接口格式对得上客户端根本不关心对面跑的是 GPT 还是 DeepSeek。从架构上看这里有两层第一层是 Copilot 扩展本身负责 UI、上下文收集、命令交互这些编辑器侧的能力第二层是模型通信层VSCode 原生通过 Model Provider 的注册机制来决定请求发到哪个 baseUrl用哪个模型名。第三方便利之处就在这里不碰第一层只改第二层的配置就能把模型从官方默认换成自定义的。这也是无需额外插件这句话的底气来源——你不需要去改 Copilot 扩展的行为只需要在它的原生配置里多加一个模型供应商。2. 不装插件的底气模型供应商注册机制是怎么工作的2.1 OpenAI 兼容协议是这座桥既然要对接任意模型就必须有一个大家都认的接口标准。目前事实上的标准就是 OpenAI 的 chat/completions 接口客户端发一个 POST 请求到{baseUrl}/chat/completions带上model、messages、stream这些参数服务端返回补全结果。DeepSeek、通义、本地部署的 Ollama 服务几乎全都实现了这套协议。这里要特别注意的是 baseUrl 的取值。以 DeepSeek 官方 API 为例请求地址是https://api.deepseek.com完整接口路径是/chat/completions很多教程让人写https://api.deepseek.com/v1其实 DeepSeek 兼容了/v1这个前缀两种写法都能通。但你换成其他模型服务时这个路径就不一定了必须去看对应服务商的文档。VSCode Copilot 的自定义模型配置之所以能一套通吃就是因为它在客户端侧只认 OpenAI 兼容协议。你把任意一个提供 OpenAI 兼容 API 的服务地址填进去剩下的事就只剩填模型名和 API Key。2.2 对话接口与补全接口的差异真正容易忽略的是Copilot 不是一个单一接口在干活。它至少有两套请求逻辑Chat 对话侧边栏对话、内联聊天走的是标准的/chat/completions接口行内补全灰色幽灵文本那种走的是 FIMfill-in-the-middle格式这种格式会在请求里额外塞prefix和suffix让模型根据光标前后的代码来补中间的部分。这就解释了为什么很多人换完模型以后发现一个诡异现象Chat 窗口里模型回答得挺好但编辑器里的行内补全却迟迟不出现或者补出来的东西明显不连贯。原因是模型不支持 FIM。DeepSeek 官方 API 的deepseek-chat模型对代码补全的 FIM 支持只能说一般本地部署的小参数模型更常见的情况是完全不认 FIM 字段。所以配置自定义模型时一定要把对话链路和补全链路分开评估别指望一个模型把两件事都干得漂亮。3. 配置步骤把 DeepSeek 设成 Copilot 的默认模型3.1 前置准备动手之前先把三样东西准备好。第一一个模型服务的 API Key。以 DeepSeek 为例去开放平台注册后在控制台创建一个 API Key形如sk-开头的一串字符。注册时一般会送一点体验额度足够做完这套测试。第二确认你的 VSCode 版本。自定义模型供应商入口在 1.99 之后的版本里才比较完整建议直接用最新的稳定版。老版本不是不能用但可能找不到图形化入口只能手改配置。第三备份现有配置。VSCode 的设置文件是settings.json在命令面板里输入 Preferences: Open User Settings (JSON) 就能打开。改动之前把原文件内容复制一份避免配置写崩了还要凭记忆恢复。3.2 图形界面通过 Manage Models 添加私有模型多数人不知道 VSCode 其实提供了图形化的模型管理入口。打开命令面板CtrlShiftP输入 Chat: Manage Model Providers或者在新一点的版本里叫 Manage Models回车进入。在模型管理界面里能做三件事查看当前已经注册的模型供应商和模型列表添加新的供应商需要填供应商 ID、baseUrl、API Key对已注册的模型做启用或停用。以 DeepSeek 为例在添加供应商界面里填Provider IDdeepseekBase URLhttps://api.deepseek.comAPI Key你的sk-开头的密钥保存之后界面上会让你勾选可用的模型。DeepSeek 官方目前主要提供两个模型名deepseek-chat对应 V3 系列对话模型deepseek-reasoner对应 R1 系列推理模型。两个都勾上等会儿在模型下拉框里能直接切换对比。这个图形化入口的底层逻辑就是往配置里写入模型供应商字段所以如果你用的是老版本 VSCode 找不到这个界面也可以跳过这步直接改 settings.json。3.3 settings.json 的完整配置模板图形界面操作完配置文件里会自动多出类似下面的内容。我自己更习惯直接手写配置因为可控性更强。下面是完整的模板{ chat.modelProviders: [ { id: deepseek, baseUrl: https://api.deepseek.com, apiKey: ${env:DEEPSEEK_API_KEY}, models: [ { id: deepseek-chat, name: DeepSeek Chat }, { id: deepseek-reasoner, name: DeepSeek Reasoner } ] } ] }几个关键点需要解释。baseUrl不要带/chat/completions这个尾巴Copilot 会自动拼接。如果你填了/v1最好先确认服务商是否兼容这个前缀否则会出现 404。apiKey字段我用的是${env:DEEPSEEK_API_KEY}。这种写法是让 VSCode 从环境变量里读取密钥而不是把 API Key 明文写在配置文件里。尤其当你开了配置同步或者会把settings.json提交到公司仓库时明文密钥等于裸奔。设置环境变量的方式取决于你的操作系统Windows 可以用setx DEEPSEEK_API_KEY sk-xxxmacOS/Linux 在 shell 配置文件里 export 即可。models数组里id是请求时会发送给服务端的模型名必须跟服务商的模型命名完全一致不能自己发明名字。name只是显示名随便取模型下拉框里展示用。3.4 验证模型是否生效配置写完之后重启 VSCode 让配置生效。怎么确认真的接上了先看 Copilot Chat 面板的模型切换下拉框正常情况下会出现 DeepSeek Chat 和 DeepSeek Reasoner 两个选项。随便选一个发一句测试消息比如用 Python 写一个读取 CSV 并统计每列空值的函数。如果模型回答了说明对话链路已经通。接下来还要验证行内补全是否正常随便打开一个代码文件写一行注释然后换行看有没有灰色补全出现。如果对话正常但补全不出现不用慌这不是配置失败是模型对 FIM 的支持问题后面第五节我会单独说。还有一个排查利器打开 VSCode 的输出面板查看 - 输出下拉框里选择 GitHub Copilot Chat所有请求日志都会打在这里。配置有没有生效、请求报了什么错基本都能从这里看到。4. 实测中的拦路虎认证失败、模型名不合法、补全失灵4.1 401 认证失败先看环境变量有没有进来我见过最多的报错是 401 Unauthorized。配置明明填了 Key但请求就是过不去。排查链路是这样的第一步打开输出面板里的 GitHub Copilot Chat 日志看请求实际发出的 API Key 是什么。如果日志里显示 Key 是空的或者显示的是${env:DEEPSEEK_API_KEY}这串字面量说明环境变量没有被 VSCode 识别第二步检查你是不是在配置完环境变量之后才启动的 VSCode。环境变量的读取发生在进程启动时改完环境变量不重启编辑器新值不会生效第三步验证 Key 本身能不能用。不要猜直接在终端里用 curl 测一下curl https://api.deepseek.com/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-your-key \ -d { model: deepseek-chat, messages: [{role: user, content: ping}], stream: false }这条命令能通说明 Key 和服务端都没问题问题一定出在 VSCode 侧的密钥读取上。能通且返回了内容再回来看配置里的 apiKey 字段是不是写成了字面量而非环境变量引用。4.2 400 模型名不存在命名必须跟服务商对齐第二个高频报错是 400 Bad Request日志里通常会跟着一条 model not found 或类似的提示。这个坑十有八九出在模型名上。有些服务商的模型名带有版本后缀比如gpt-4o-2024-08-06有些则像 DeepSeek 这样用deepseek-chat这种比较抽象的名字。你在配置里填的 id 必须和服务商 API 文档里写的完全一致大小写也不能错。以 GPT 为例如果你用的是 OpenAI 官方接口模型名要填gpt-4o这类官方命名如果你是通过 Azure OpenAI 接入模型名规则又不一样通常是自己部署时给模型起的 deployment name。遇到 400 不要猜直接拿上面那条 curl 命令把 model 字段改成你的配置值请求一遍。curl 能过就是 VSCode 配置里写错了curl 报错就照着错误提示去改模型名。4.3 流式响应中断回复到一半就断掉还有一个比较隐蔽的问题模型回复到一半突然停住转圈圈转一会儿然后报错。这类问题在日志里往往看不出明显异常或者只有一个 stream 相关的错误。这多半是流式响应SSE连接的问题。Copilot 默认走流式输出服务端会一段一段地往客户端推数据。如果中间网络抖动或者有超时限制连接就会断开。我的实测经验是如果接的是本地模型比如 Ollama先确认模型完整加载到内存里了再试很多本地推理框架在冷启动时会因为模型加载慢导致超时如果接的是远端 API检查公司网络里有没有超时很短的代理拦截SSE 长连接是重灾区个别模型服务端对流式输出的实现不严格偶尔会漏发结束标记这在日志里表现为响应结束了但状态是异常。这种问题只能换模型服务端版本客户端侧无解。4.4 行内补全失灵FIM 接口是个隐形门槛第三节末尾我留了个悬念对话通但补全不来。这里展开说说。Copilot 的行内补全用的是 FIM 格式请求体里除了普通的 messages还会包含prefix和suffix两类字段。并不是所有 OpenAI 兼容接口都实现了这套扩展。DeepSeek 官方 API 对 FIM 是有一定支持的但我实测下来deepseek-chat的补全质量和 GPT-4o 这类原生的差距还是明显的偶尔会出现补一个重复的括号或者把注释当代码补完的情况。本地部署的小模型更直接——很多 7B、13B 参数的模型根本不认 FIM 格式请求打过去要么报错要么返回空。所以我在项目里的实际做法是拆开配置Chat 窗口用 DeepSeek 省成本行内补全保持官方默认模型。配置里把两种模型供应商都注册上用的时候在模型下拉框里手动切。虽然没办法做到同一屏同时用两个模型但日常使用已经够顺畅了。5. 进阶玩法本地模型与多模型切换的日常5.1 接 Ollama 本地模型数据不出内网如果你对数据隐私敏感或者想离线使用可以把自己的本地模型接到 Copilot 上。最常见的方案是 Ollama。Ollama 安装并启动后默认会监听127.0.0.1:11434。新版 Ollama 对 OpenAI 兼容协议做了支持http://127.0.0.1:11434/v1可以直接当作 baseUrl 用。在 settings.json 里再加一个供应商{ chat.modelProviders: [ { id: local-ollama, baseUrl: http://localhost:11434/v1, apiKey: ollama, models: [ { id: qwen2.5-coder:7b, name: Qwen Coder 7B Local } ] } ] }注意两个细节apiKey字段本地服务不校验随便填一个非空字符串占位就行但别留空有些版本留空会直接跳过这个供应商模型 id 要用你本机实际拉取过的模型名ollama list命令可以查看当前有哪些可用模型。本地模型最大的限制是上下文长度。像 7B 这种小参数量模型配置里最好把上下文窗口调小一点别让 Copilot 把超大文件整个塞进去。上下文越长显存占用越高推理越慢还容易报显存不足。5.2 多模型分工建议别指望一个模型通吃把整个链路跑通之后你手上可能已经有 2 到 3 个可用的模型供应商官方默认、DeepSeek、本地 Ollama。我的建议是给它们分工而不是每次手动换来换去。日常写业务代码行内补全用官方默认模型因为 FIM 支持最成熟补全速度和质量最稳做批量重构、写单元测试这种一次性大任务切到 DeepSeek成本低上下文窗口大涉及敏感代码或者断网环境才切本地模型。切换的路径很顺手Copilot Chat 面板的模型下拉框点一下就能换行内补全的模型在设置里指定默认项不需要每一次都改配置文件。5.3 团队共享配置的成本控制如果你是在团队里推广这套方案还有一个容易踩的坑API Key 共享。不要把个人 Key 直接写进团队共享的 settings.json 里。正确做法是把apiKey字段全部改成${env:XXX_API_KEY}然后在团队文档里写清楚每个人需要自己配置哪些环境变量。这样就算有人离职只需要吊销他自己的 Key不会影响别人。成本控制也要提前想好。DeepSeek 虽然便宜但 Copilot 的请求频率很高尤其是行内补全几乎打字就触发。如果所有请求都走付费 API一个月的账单可能超出预期。我个人的经验是个人开发场景用 DeepSeek 完全没问题团队高频场景优先切回按席位付费的官方模型把自定义模型用在特定任务上成本才能压得住。最后再分享一个小技巧。整套配置跑通之后建议把常用的模型供应商配置整理成一份自己的配置笔记每次换电脑或者升级 VSCode 后直接照着配。配置本身不复杂真正花时间的反而是对照日志排查那几类错误——401 查 Key、400 查模型名、补全失灵查 FIM。把这套排查顺序记下来下次接新模型基本十分钟内能搞定不用再被各种第三方插件绑架。
