Cursor默认连接的是云端大模型，响应快但需要联网，且代码会上传到远程服务器。对于涉密项目或者网络环境受限的开发者来说，接入本地的Ollama是更安全的选择。然而不少人配置好之后发现，代码补全一个单词要等好几秒，对话生成更是慢得难以忍受。其实Ollama的默认配置偏保守，加上模型选择不当、上下文过长等原因，速度瓶颈大多可以解决。本文从模型选型、参数调优、Cursor配置三个层面，系统讲解如何让本地模型跑出接近云端体验的生成速度。
一、选对模型是提速的第一步
很多速度问题的根源不在配置，而在模型本身。Ollama支持的模型从几亿参数到几百亿参数不等，参数量直接决定推理所需的时间和显存占用。如果在一张8G显存的显卡上强行跑33B级别的模型，Ollama会自动把部分层卸载到CPU，速度会暴跌到每秒一两个token，这种情况下无论怎么调参数都无济于事。
选择模型的核心原则是：让模型完整装进显存，并留有余量。一般来说，7B量化模型大约需要5G左右显存，14B量化模型需要10G上下。一张8G显卡跑7B，一张16G显卡跑14B，24G显卡可以尝试32B的4bit量化版本。可以用下面的命令查看模型加载后的显存与内存分布：
ollama run qwen2.5-coder:7b # 在交互界面输入 /show info 查看模型信息 # 关注 "context length" 和参数规模
具体到代码场景，模型选型建议分成两类：自动补全用小模型，对话和重构用大模型。补全场景对延迟极其敏感，1到3B的专用补全模型（如qwen2.5-coder:1.5b）足够胜任，几百毫秒就能出结果；而解释代码、生成大段逻辑这类任务，对延迟容忍度高，可以切换到7B或14B模型换取更好的质量。这种“小模型补全、大模型对话”的分工，是提升体感速度最有效的一招。
二、Ollama服务端参数调优
Ollama默认配置有很多可以挖掘的空间。首先是keep_alive参数，默认模型在空闲5分钟后会被卸载出显存，下次请求需要重新加载权重，这个过程在机械硬盘或模型较大时可能耗时十几秒甚至更久。如果你的机器内存和显存足够，可以把keep_alive设置得长一些，让模型常驻显存：
# 启动API服务时设置模型常驻
OLLAMA_KEEP_ALIVE=24h ollama serve
# 或者在API请求中单独指定
curl http://127.0.0.1:11434/api/generate -d '{
"model": "qwen2.5-coder:7b",
"prompt": "写一个快速排序",
"keep_alive": "24h"
}'
其次是上下文窗口控制。默认的2048或4096上下文对代码补全往往不够，Cursor会把当前文件甚至多个文件塞进请求。如果上下文设置得很大，每次请求的prefill阶段要处理的token就多，首token延迟明显增加。建议根据实际需要设置num_ctx，比如补全场景4096到8192足够，不要盲目拉到32k以上。上下文越长不仅慢，显存占用也会成倍增长，一旦超出显存，KV缓存会被拆分到CPU，速度断崖式下跌。
# 创建自定义模型，固定上下文长度 ollama show qwen2.5-coder:7b --modelfile > Modelfile # 在Modelfile中添加参数后构建 # PARAMETER num_ctx 8192 ollama create my-coder -f Modelfile
另外还有几个影响吞吐的参数值得了解。OLLAMA_NUM_PARALLEL控制并发请求数，Cursor的补全和对话如果同时打到同一个模型实例，适当调大可以避免排队等待；OLLAMA_FLASH_ATTENTION开启注意力优化，在支持的模型上能降低显存占用并略微提速；OLLAMA_KV_CACHE_TYPE设置为q8_0可以压缩KV缓存，在长上下文场景下能省出可观的显存空间。
# 组合设置环境变量后启动 export OLLAMA_KEEP_ALIVE=24h export OLLAMA_NUM_PARALLEL=4 export OLLAMA_FLASH_ATTENTION=1 export OLLAMA_KV_CACHE_TYPE=q8_0 ollama serve
三、Cursor端的正确配置与网络排查
Cursor接入Ollama需要在设置中开启本地模型覆盖功能。在Cursor的Models设置页面，勾选启用本地OpenAI兼容接口的选项，将地址填为http://127.0.0.1:11434/v1，然后填入模型名称并逐一验证。这里有个常见误区：模型名称必须与Ollama中的完全一致，包括冒号后的标签，写成qwen2.5-coder而实际装的是qwen2.5-coder:7b时，验证会失败或者意外拉取默认版本。
配置完成后，建议把Tab补全功能继续留给Cursor自带的快速模型，把本地Ollama模型用于Chat、Composer等对延迟不那么敏感的功能。如果所有功能都指向本地模型，打字时的补全请求和对话请求会互相争抢GPU资源，反而整体变慢。合理的分工是保证流畅度的关键。
网络层面也有几个容易被忽略的点。即使Ollama跑在本机，Cursor发起请求仍会经过HTTP代理，如果系统配置了代理软件，127.0.0.1的请求可能被转发到远端再绕回来，白白增加几百毫秒延迟。解决办法是在代理软件中将localhost加入直连名单，或设置NO_PROXY=127.0.0.1,localhost环境变量。此外，可以用以下命令粗略测量本地接口的响应速度，排除Cursor本身的问题：
# 测试首token延迟和生成速度
time curl http://127.0.0.1:11434/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model":"qwen2.5-coder:7b","messages":[{"role":"user","content":"hello"}]}'
如果这个裸接口的速度就慢，问题在Ollama侧，回头检查模型是否超出显存、GPU是否被其他程序占用；如果裸接口快而Cursor里慢，则重点排查代理和上下文长度设置。通过ollama ps命令可以实时观察模型是否完全跑在GPU上，出现CPU占用的百分比就说明发生了层卸载，需要换更小的模型或更激进的量化版本。
四、量化精度与质量的平衡
同一个模型在Ollama中往往有多个量化版本可选，比如q4_0、q4_K_M、q5_K_M、q8_0等。量化越激进，文件越小、推理越快，但代码生成这类对精度敏感的任务，过度量化会导致括号不匹配、变量名拼错等低级错误，反而需要多次重试，整体效率下降。
实践经验是：代码模型尽量选q4_K_M或q5_K_M作为平衡点，这两档在速度和质量之间的损失比最划算。q8_0接近原始精度但体积翻倍，只在显存充裕时考虑。另外，同样参数量下，新架构的模型往往在同质量下更快，及时更新到较新的模型版本，比在旧模型上反复调参收益更大。
最后提醒一点，本地优化到极限后，如果仍然觉得对话类任务太慢，可以把重活交给云端、轻活留给本地的混合策略：自动补全和简单问答走Ollama，复杂重构走云端模型。这样既保证了敏感代码不出本机，又不牺牲关键场景的体验。经过上述几层优化，一套中等配置的显卡完全可以支撑日常开发中流畅的AI辅助编码。