能跑通但默认配置易卡在“加载中”或补全延迟超2秒，核心问题在于ollama服务未常驻启动、模型名与ollama list输出不一致、tabautocompletemodel配置错误。
能跑通，但默认配置大概率卡在“加载中”或补全延迟超2秒——核心问题不在插件本身，而在ollama serve后台服务是否真正就绪、模型名是否和ollama list输出完全一致、以及tabAutocompleteModel没配对。
确认Ollama服务已启动且端口可访问
Ollama不是装完就自动提供API服务的。双击图标或运行ollama run xxx只启动单次对话，Continue需要的是常驻的HTTP API服务（默认http://localhost:11434）。
- 终端执行
ollama serve，看到Listening on 127.0.0.1:11434才算真正就绪；Windows用户若提示端口被占，改用OLLAMA_HOST=127.0.0.1:11435 ollama serve并同步更新Continue配置里的baseUrl - 用
curl http://localhost:11434/api/tags测试，返回JSON含"models": [...]才说明API通了；返回Connection refused就是服务没起来 - Mac/Linux用户注意：如果用
brew install ollama安装，可能需先brew services start ollama，否则ollama serve前台运行时关掉终端就断了
Continue配置里model字段必须和ollama list输出严格一致
常见错误是写codellama:7b但ollama list显示的是codellama:7b-q4_K_M（量化后的真实标签），或漏掉:latest导致匹配失败。
- 先运行
ollama list，复制完整NAME列内容（包括冒号后缀），例如deepseek-coder:6.7b-q8_0 - 在
~/.continue/config.json中，models和tabAutocompleteModel的model字段必须粘贴这个完整名称，不能简写 - 如果模型名含特殊字符（如
/），比如qwen2.5-coder:latest，确保JSON字符串用双引号包裹，不加额外转义 - Windows路径要注意反斜杠：
"configPath": "C:\Users\xxx\.continue\config.json"，但model名本身不用改
补全延迟高？重点调这三个参数
代码补全卡顿90%源于模型加载策略和请求节流，不是CPU不够。
-
ollama run命令启动模型时加--gpu-layers 20（NVIDIA显卡）或--numa（Intel CPU），能显著降低首token延迟；无GPU时--no-gpu反而更稳 - 在
config.json的tabAutocompleteModel块里加"temperature": 0.15，避免模型“思考过久”；设"maxTokens": 128限制输出长度，防止补全截断 - Continue设置里开启
prefillCache（需v1.0.20+），并把debounceDelay从默认300ms降到120，让按键松开后更快发请求
模型选错会导致补全乱码或拒绝响应
不是所有Ollama模型都适合代码补全，llama3或phi3这类通用模型在函数签名生成上容易出错，而deepseek-coder或qwen2.5-coder专为代码训练，补全准确率高一倍以上。
- 16GB内存机器优先选
deepseek-coder:6.7b-q6_K（量化后约4.2GB显存/内存占用），比原生13b更稳 - Java项目别硬套
codellama，实测starcoder2:15b对Spring Boot注解补全更准，但需--ctx-size 4096启动 - Go项目慎用
codellama，tinyllama这种小模型反而因上下文短、响应快，在简单函数补全场景体验更好
最易被忽略的点：每次改完config.json或重装模型，必须重启VS Code（不只是重载窗口），否则Continue仍读旧缓存；另外ollama ps能查当前运行中的模型实例，残留进程占着GPU时新请求会直接超时。
