vscode无法使用deepseek本地代码补全,主因是插件未正确配置deepseek.endpoint指向本地fastapi服务(如http://localhost:8000/v1),且后端必须提供符合openai规范的/v1/chat/completions接口及标准响应格式,同时模型加载需优化device_map和dtype以避免超时。

VSCode 里用不了 DeepSeek 代码补全,大概率不是插件没装对,而是本地模型服务没跑通、或插件连的 endpoint 根本没指向你自己的 API。官方插件默认连的是 https://api.deepseek.com/v1,不改配置就永远走不了本地模型。
确认 VSCode 插件是否真的连本地模型
DeepSeek 官方插件(v2.3.1+)本身不带模型,只负责发请求;它必须通过 deepseek.endpoint 配置项对接后端服务。如果你没改这个地址,它就在调云端 API —— 和本地部署完全无关。
- 打开 VSCode 设置(
Ctrl+,),搜索deepseek.endpoint - 必须设为类似
http://localhost:8000/v1这样的本地 FastAPI 地址(注意协议是http,不是https) - 如果填了
https://api.deepseek.com/v1或留空,插件会静默 fallback 到云端,且不报错 - 验证方式:启动本地服务后,在浏览器访问
http://localhost:8000/docs,能打开 Swagger 页面才算服务就绪
FastAPI 服务必须暴露 /v1/chat/completions 接口
VSCode 插件底层用的是 OpenAI 兼容的 REST 协议,不是它自己定义的 /generate。你照着网上抄的简单 /generate 路由,插件根本认不出来。
统一LLM网关 - 一个API对接70+AI模型,使用单一API密钥即可调用GPT、Claude、Gemini、Qwen、Deepseek、Grok等主流模型。
- 接口路径必须是
POST /v1/chat/completions,不是/generate或/chat - 请求体要支持
messages数组格式(不是单个prompt字符串) - 响应体结构需严格匹配 OpenAI schema:
{ "choices": [{ "message": { "content": "..." } }] } - 推荐直接用
llama.cpp+server模式,或基于transformers+fastapi封装时复用openai-compatible-server模板(如text-generation-inference的 OpenAI adapter)
模型加载时 device_map 和 dtype 不配好,VSCode 补全会卡死或返回空
插件在编辑器里高频触发补全请求(每敲几个字符就发一次),如果模型加载没优化,第一次请求就要等 10 秒以上,VSCode 会直接超时丢弃响应。
- 务必用
device_map="auto",别硬写"cuda"—— 否则多卡或显存不足时会崩 - 强制指定
torch_dtype=torch.float16(7B 模型不加这句,显存占用翻倍) - 加
load_in_4bit=True或load_in_8bit=True(需要bitsandbytes),7B 模型可压到 6GB 显存内 - 启动服务前先在 Python 里手动跑一次
model.generate(...),确认首 token 延迟
插件侧关键配置项不能漏
除了 endpoint,还有三个配置项直接影响补全是否生效:
-
deepseek.apiKey:本地部署时可填任意非空字符串(如"local"),插件会发Authorization: Bearer local,你的 FastAPI 服务得忽略或校验这个头 -
deepseek.languageSupport:必须显式勾选语言,比如python、typescript,否则对应文件类型不会触发补全 -
deepseek.timeout:默认 5000ms,本地模型若首 token 延迟高,建议调到10000,避免频繁失败 - 检查
.vscode/settings.json里有没有项目级覆盖,它会优先于全局设置
最常被忽略的一点:VSCode 插件的补全请求是流式(streaming)的,但很多手写的 FastAPI 服务只返回完整 response,不支持 stream=True。插件收不到 chunk 就会卡住——哪怕你返回了正确 content,也得按 SSE 格式分块推送,否则补全框光标一直转圈。










