1. 从一次让人抓狂的补全延迟说起如果你正在用 Roo Code 配合本地模型写代码大概率经历过这种场景敲下几个字符等待补全的时间足够你去泡一杯咖啡光标在那里转圈风扇开始狂吼最后弹出来的建议还驴唇不对马嘴。我最初把 Roo Code 接到本地 Ollama 上跑qwen2.5-coder的时候满心以为能白嫖一个私有 Copilot结果实测下来单次补全要等 8 到 15 秒长一点的上下文直接飙到 30 秒以上体验比不用还差。这不是 Roo Code 的锅也不是本地模型不行而是整条链路上有太多默认配置在拖后腿。Roo Code 作为 VSCode 里的 AI 代理助手它的请求模式、上下文组装方式、流式解析逻辑和本地推理引擎的批处理、KV Cache、显存调度之间存在大量需要手动对齐的细节。默认状态下两边都在用最保守的策略结果就是延迟叠加、显存浪费、GPU 空转。这篇内容就是把我踩过的坑一个个摊开讲。核心目标很明确让 Roo Code 调用本地模型的速度逼近你在原生推理工具里直接对话的速度。适合已经在 VSCode 里装好 Roo Code、本地跑着 Ollama 或 LM Studio、但被卡顿折磨到想放弃的开发者。如果你还没搭好环境文中的环境准备部分也能直接抄作业。全文围绕 Roo Code、本地模型、VSCode、Ollama、卡顿优化这几个关键词展开所有参数和步骤都经过实测验证。先说结论卡顿的根源通常不在模型本身而在上下文长度失控、流式传输被阻塞、显存与内存反复换页、以及 Roo Code 的请求粒度太碎这四个地方。下面逐个拆解。2. 先搞清楚 Roo Code 到底在什么时候发请求2.1 Roo Code 的三种触发模式与请求特征很多人优化卡顿的第一步就错了——他们直接去调 Ollama 的num_ctx或者换更小的模型却没搞清楚 Roo Code 到底在什么时机、以什么频率向后端发请求。Roo Code 的请求大致分三类每类的性能瓶颈完全不同。第一类是行内补全Inline Completion。你在编辑器里打字时它会在停顿约 300 到 500 毫秒后触发一次请求把光标前后的代码片段作为上下文发出去。这类请求的特点是频率极高、上下文极短、对首 token 延迟TTFT极度敏感。如果每次都要重新加载模型或者重建 KV Cache延迟就会爆炸。第二类是对话式代理Agent Chat。你在侧边栏提问、让它改文件、跑命令时触发。这类请求上下文长、需要多轮工具调用、对吞吐量tokens/s更敏感首 token 延迟反而没那么关键。第三类是后台索引与摘要。Roo Code 会对打开的文件做轻量分析生成项目结构摘要。这类请求往往在你没注意的时候偷偷跑抢占 GPU 资源是明明没在对话却卡的元凶。提示在 Roo Code 设置里把自动补全和后台分析分开配置不要用同一套模型参数。补全用小上下文、低延迟配置对话用大上下文、高吞吐配置。2.2 为什么默认配置下每次请求都像冷启动Ollama 默认的模型加载策略是按需加载 空闲卸载。默认OLLAMA_KEEP_ALIVE是 5 分钟意味着你 5 分钟没发请求模型就从显存里被踢出去。下次 Roo Code 触发补全时Ollama 要重新把几 GB 的权重从磁盘读回显存这个冷启动过程在机械硬盘上能到 20 秒以上NVMe 上也要 3 到 5 秒。更隐蔽的问题是KV Cache 的重复计算。Roo Code 每次补全发送的上下文前缀部分比如文件开头、系统提示词往往是相同的。但如果你没开启前缀缓存Prefix CachingOllama 每次都会把这部分重新算一遍。一个 4K token 的上下文光前缀就可能占 2K等于一半的算力白烧。我实测过同一个文件、同样的补全位置开启前缀缓存前后首 token 延迟从 2.3 秒降到 0.6 秒。这个差距在连续打字时会被放大到无法忍受。2.3 用日志确认瓶颈到底在哪一环在动手改配置之前先学会看日志定位。Ollama 的日志里会打印每次请求的prompt eval duration前缀计算耗时、eval duration生成耗时、load duration模型加载耗时。Roo Code 这边则可以在输出面板里看到请求发出到收到首字节的时间。把两边的时间对齐你就能判断卡顿发生在哪现象日志特征根因方向每次补全都慢且load duration很大模型反复加载卸载KEEP_ALIVE 太短首 token 慢但生成快prompt eval duration占比高前缀缓存未开、上下文过长生成阶段一顿一顿eval duration波动大显存不足触发换页Roo Code 显示等待但 Ollama 没日志请求根本没发出去Roo Code 侧超时或队列阻塞这张表是我排查了十几个案例后总结的基本能覆盖 90% 的卡顿场景。先定位再动手比盲目调参高效得多。3. Ollama 侧的四个关键参数把冷启动和重复计算干掉3.1 KEEP_ALIVE让模型常驻显存这是最立竿见影的一刀。默认 5 分钟的卸载策略对交互式编码来说太激进了。我的建议是直接设成-1让模型永久驻留除非你手动卸载。在启动 Ollama 服务前设置环境变量# Linux / macOS export OLLAMA_KEEP_ALIVE-1 ollama serve # Windows PowerShell $env:OLLAMA_KEEP_ALIVE-1 ollama serve如果你是用 systemd 管理 Ollama就写进 service 文件[Service] EnvironmentOLLAMA_KEEP_ALIVE-1 EnvironmentOLLAMA_NUM_PARALLEL1 EnvironmentOLLAMA_MAX_LOADED_MODELS1这里顺带把OLLAMA_NUM_PARALLEL设成 1、OLLAMA_MAX_LOADED_MODELS设成 1。原因很实际Roo Code 的补全请求是串行的开并行只会让多个请求争抢同一块显存反而增加调度开销。除非你有两张卡或者显存特别富裕否则单模型单并行是最稳的。注意KEEP_ALIVE-1会让模型一直占着显存。如果你还要跑别的吃显存的任务比如本地向量模型做 RAG记得留够余量或者改用30m这种较长的有限值。3.2 num_ctx上下文不是越大越好Ollama 默认num_ctx是 2048但很多模型支持 32K 甚至 128K。不少人一看补全效果差就把num_ctx拉到 32768结果显存直接爆掉开始疯狂换页速度反而更慢。正确的做法是按用途分档。补全场景根本不需要长上下文2048 到 4096 足够覆盖当前函数和少量上文对话场景可以给到 8192 到 16384。在 Roo Code 里可以为不同模式配置不同的模型和参数。如果你用 Modelfile 自定义可以这样写FROM qwen2.5-coder:7b PARAMETER num_ctx 4096 PARAMETER num_batch 512 PARAMETER num_gpu 99num_batch是批处理大小影响 prompt 计算阶段的并行度。默认值偏保守适当调大能加快前缀计算但太大会吃显存。512 是个比较安全的起点显存充裕可以试 1024。3.3 前缀缓存省掉一半的重复算力Ollama 较新版本已经支持前缀缓存在日志里体现为cache hit。要让它生效关键是保证请求前缀稳定。Roo Code 的系统提示词、文件头部内容如果每次都变比如带了时间戳缓存就永远命中不了。检查方法连续发两次相同前缀的请求看第二次日志里prompt eval duration是否显著下降。如果没有说明前缀在变。这时候要去 Roo Code 的提示词模板里把动态内容时间、随机 ID挪到上下文末尾让前缀保持稳定。我做过一个对比实验同一个 6K token 的上下文配置首 token 延迟生成速度无前缀缓存2.8s18 tokens/s前缀缓存命中0.7s22 tokens/s前缀缓存 num_batch 10240.5s24 tokens/s差距非常明显。前缀缓存几乎是零成本的优化只要前缀稳定就能白拿。3.4 模型量化等级Q4 和 Q8 的取舍量化等级直接决定显存占用和推理速度。很多人迷信 Q8 甚至 FP16觉得精度高但在补全场景下Q4_K_M 和 Q8 的实际代码质量差异远小于它们的速度差异。我的实测数据7B 代码模型RTX 4070 12G量化显存占用生成速度补全可用度Q8_08.1G14 tokens/s高Q5_K_M5.6G21 tokens/s高Q4_K_M4.4G28 tokens/s中高Q4_04.0G31 tokens/s中补全场景追求的是快且够用Q4_K_M 基本是甜点。对话场景如果对质量要求高可以上 Q5 或 Q8。关键是别让模型把显存占满留 1 到 2G 给 KV Cache 和系统否则一旦溢出到内存速度会断崖式下跌。4. Roo Code 侧的配置请求粒度与超时才是隐形杀手4.1 补全触发延迟与请求节流Roo Code 默认的补全触发延迟偏短你打字稍微一停它就发请求。在本地模型上这意味着请求队列永远排满前一个还没算完后一个又来了。表现出来就是越打字越卡。把触发延迟从默认的 300ms 调到 600 到 800ms给模型留出喘息时间。同时开启请求节流如果版本支持让同一时间只有一个补全请求在飞。这个改动看起来是降低响应性实际体验反而更流畅因为不再有请求堆积。提示如果你用的是较新的 Roo Code 版本在设置里找 Inline Completion Delay 和 Request Throttling 两个选项。老版本可能需要改配置文件。4.2 上下文裁剪别把整个项目塞进去Roo Code 默认会把打开的文件、相关文件、甚至项目结构都塞进上下文。对云端模型来说这无所谓对本地模型就是灾难。一个 7B 模型处理 16K 上下文光 prompt 计算就要好几秒。在设置里限制上下文来源只保留当前文件和直接相关的 import关掉包含项目结构包含打开的所有文件这类选项。补全场景下当前文件的前后 100 行加少量相关符号定义效果已经足够好。我对比过不同上下文策略的补全质量上下文策略平均上下文长度首 token 延迟补全采纳率全项目12K4.2s62%当前文件import3.5K1.1s58%当前文件前后100行1.8K0.6s55%采纳率只降了几个百分点延迟却降了 7 倍。这笔账怎么算都划算。4.3 流式传输与超时设置Roo Code 和 Ollama 之间是流式传输SSE。如果超时设置太短长生成会被中途掐断太长又会让卡住的请求一直占着连接。默认超时往往不适合本地模型需要手动调。建议把连接超时设成 10 秒读取超时设成 120 秒。这样既能容忍本地模型的冷启动又不会让死掉的请求无限挂起。如果你发现 Roo Code 经常显示请求超时但 Ollama 日志显示已经算完多半是流式解析出了问题检查一下两边的 SSE 格式是否兼容。4.4 模型选择补全和对话分开配这是最容易被忽略但收益巨大的一点。Roo Code 允许为不同功能指定不同模型。补全用一个小的、快的模型比如 1.5B 或 3B 的代码模型对话用大的、强的模型7B 或 14B。补全对模型能力要求其实不高它只需要根据上下文猜下一行小模型完全够用而且速度快好几倍。对话才需要大模型的推理能力。分开配置后补全延迟能压到 300ms 以内对话质量也不受影响。{ inlineCompletionModel: qwen2.5-coder:1.5b, chatModel: qwen2.5-coder:7b, inlineCompletionNumCtx: 2048, chatNumCtx: 8192 }这种大小模型分工的思路是本地 AI 编码体验接近云端的关键。5. 硬件与系统层的隐藏瓶颈5.1 显存不足时的换页灾难本地模型卡顿最凶的情况是显存不够导致模型层被放到内存甚至磁盘。这时候每次推理都要在 PCIe 总线上来回搬数据速度能掉到原来的十分之一。判断方法跑推理时看nvidia-smi的显存占用和 GPU 利用率。如果显存接近 100% 但 GPU 利用率忽高忽低基本就是换页了。解决办法只有两个换更小的量化或者换更小的模型。别指望调参数能救物理限制就是物理限制。5.2 磁盘 IO 对冷启动的影响模型文件放在机械硬盘上冷启动加载能到 20 秒以上。放到 NVMe SSD 上同样的模型 3 到 5 秒就能加载完。如果你经常遇到第一次补全特别慢先检查模型文件在不在 SSD 上。Ollama 的模型默认存在用户目录下Windows 上通常是C:\Users\你的用户名\.ollama\models。如果 C 盘是机械盘或者空间紧张可以改存储路径# Linux / macOS export OLLAMA_MODELS/path/to/ssd/ollama/models # Windows setx OLLAMA_MODELS D:\ollama\models改完重启 Ollama 服务把原来的模型文件移过去即可。5.3 CPU 推理与 GPU 卸载比例如果你没有独显纯 CPU 推理也不是不能用但要选对模型大小。7B 模型在纯 CPU 上大概 3 到 5 tokens/s补全体验很差1.5B 到 3B 的模型能到 10 到 15 tokens/s勉强可用。有独显但显存不够时Ollama 支持部分层卸载到 GPUnum_gpu参数。把尽可能多的层放 GPU剩下的放 CPU。这个比例需要试一般让显存占用到 90% 左右比较合适留一点给 KV Cache。6. 一套可直接复现的优化配置6.1 完整的环境变量与 Modelfile把前面所有优化整合起来这是一套我实测稳定的配置。服务端环境变量export OLLAMA_KEEP_ALIVE-1 export OLLAMA_NUM_PARALLEL1 export OLLAMA_MAX_LOADED_MODELS1 export OLLAMA_MODELS/ssd/ollama/models export OLLAMA_FLASH_ATTENTION1OLLAMA_FLASH_ATTENTION1开启 Flash Attention能显著降低长上下文的显存占用和计算量前提是你的 GPU 支持。补全模型 ModelfileFROM qwen2.5-coder:1.5b PARAMETER num_ctx 2048 PARAMETER num_batch 512 PARAMETER num_gpu 99 PARAMETER temperature 0.1对话模型 ModelfileFROM qwen2.5-coder:7b PARAMETER num_ctx 8192 PARAMETER num_batch 512 PARAMETER num_gpu 99 PARAMETER temperature 0.2补全用低 temperature 保证稳定对话可以稍高一点增加灵活性。6.2 Roo Code 设置清单补全模型qwen2.5-coder:1.5b上下文 2048对话模型qwen2.5-coder:7b上下文 8192补全触发延迟700ms请求节流开启上下文来源仅当前文件 import连接超时10s读取超时120s关闭后台自动分析或改为低频6.3 验证优化效果的方法改完之后别凭感觉用数据验证。连续触发 20 次补全记录首 token 延迟和生成速度取平均值。优化前优化后各跑一遍对比才有意义。我的实测结果RTX 4070 12Gqwen2.5-coder指标优化前优化后补全首 token 延迟2.8s0.4s补全生成速度12 tokens/s26 tokens/s对话首 token 延迟5.1s0.9s对话生成速度14 tokens/s24 tokens/s连续打字卡顿明显基本无感补全延迟从接近 3 秒降到 0.4 秒这个提升是质变的。现在打字时补全几乎是即时出现和云端服务的体验差距已经很小。7. 几个我踩过的坑和反直觉发现7.1 模型不是越大越好补全尤其如此我一开始坚持用 7B 做补全觉得小模型补全质量差。后来实测发现1.5B 的代码模型在补全任务上的采纳率只比 7B 低 3 到 5 个百分点但速度快了 4 倍。补全本质是猜下一行不需要复杂推理小模型完全胜任。把大模型留给真正需要思考的对话和重构任务这才是合理的资源分配。7.2 关掉智能功能反而更快Roo Code 有些智能上下文自动相关文件功能听起来很美好实际在本地模型上就是性能杀手。它们会大幅增加上下文长度而本地模型对上下文长度极其敏感。关掉这些功能后补全质量几乎没降速度却翻倍。本地部署的核心矛盾是算力有限任何增加上下文的智能都要谨慎。7.3 显存监控要常态化优化不是一劳永逸的。你打开的文件变多、对话变长显存占用会慢慢爬升。养成看nvidia-smi的习惯一旦发现显存接近上限就清理一下对话历史或者重启 Ollama。我现在的做法是在任务栏放一个显存监控小工具超过 90% 就手动干预避免它悄悄进入换页状态。7.4 别忽视散热和功耗墙这个坑很隐蔽。笔记本跑本地模型时GPU 温度一上来就撞功耗墙频率被压下去速度直接腰斩。我有一台轻薄本前 30 秒推理飞快之后就慢下来查了半天才发现是散热跟不上。台式机或者散热好的机器上就没这个问题。如果你遇到越跑越慢先看看温度。8. 后续还能怎么继续压榨把上面这些做完Roo Code 配合本地模型的体验已经能打。如果还想继续优化有几个方向可以探索。一是用更激进的推理引擎。Ollama 胜在易用但底层是 llama.cpp还有更激进的方案比如 vLLM、TensorRT-LLM在批处理和吞吐上更强。不过它们配置复杂适合愿意折腾的人。二是投机解码Speculative Decoding。用一个小模型快速生成草稿大模型验证能在保持质量的前提下提速。部分推理引擎已经支持Ollama 生态里也有相关尝试。三是本地向量模型配合 RAG。把项目文档、历史代码做成向量索引补全时只检索最相关的片段塞进上下文而不是整个文件。这样既控制了上下文长度又提升了相关性。本地向量模型比如 bge 系列跑起来很轻和代码模型可以共存。四是多卡或者统一内存架构。如果你有 Apple Silicon 或者多张显卡可以跑更大的模型而不牺牲速度。统一内存的优势是显存和内存共享不会出现换页问题。我在实际使用中最大的体会是本地 AI 编码的体验80% 取决于配置而不是硬件。同样的显卡配置对了和配置错了体验能差一个数量级。花两个小时把参数调对比换一张更贵的卡收益更大。最后再分享一个小技巧把优化后的配置写成脚本或者配置文件换机器时直接复用别每次重新踩一遍坑。