如果你是用 Roo Code Ollama 跑本地模型来写代码的大概率经历过这种场景在编辑器里点完“开始任务”右上角一直在转圈等上五六秒甚至十几秒才开始吐出第一个字好不容易开始输出了又像挤牙膏一样断断续续。更诡异的是你单独在终端里跑 Ollama同一个模型响应快得飞起——于是很多人会得出一个结论本地模型不行或者 Roo Code 这个工具不行。其实我在踩了很长时间的坑之后发现绝大多数“卡顿”都不是模型算不动。Roo Code 本身只是通过 HTTP 接口调用 Ollama底层推理内核和命令行完全一致。只要配置链路对齐它就能跑出接近ollama run命令行的原生推理速度。这篇文章会把我在本地模型 Roo Code 实战里遇到的三种卡顿、定位方法、服务端参数、上下文优化和最终可复制的配置清单完整写出来给正在被“卡顿”折磨的人一条直接能走通的路。1. 先判断你是哪一种“卡”三条明显不同的症状线优化最怕不看症状直接套参数。我在早期犯过的错误就是去网上翻各种“本地模型提速技巧”结果把OLLAMA_NUM_PARALLEL调大到 4速度不但没起来反而更糟。后来才发现卡顿要分类型每类卡顿对应的瓶颈完全不同修法也完全不一样。1.1 冷启动卡、首字卡、输出中断卡对应完全不同的瓶颈冷启动卡点了开始任务之后Roo Code 一直转圈十几秒甚至更久没有任何输出然后突然哗啦哗啦开始疯狂吐字。这种情况最典型的特征是“等待时间极长一旦开始就正常”。原因通常是模型在无人使用的时间段里已经被 Ollama 从显存里卸载了下一次请求要先重新加载几十 GB 的权重这个动作在普通机器上就是好几秒到十几秒。再加上请求里的 prompt 需要一次性预处理两段延迟叠加体感就是“卡死”。首字卡第一个字出来之前有明显的延迟但一旦开始输出速度还挺正常。这种情况和冷启动不一样模型其实已经驻留在显存里真正的瓶颈是上下文预填充。Roo Code 这类 agent 工具每个请求都会带上大量上下文模型要先从头把整段上下文计算一遍才能开始生成第一个 token。上下文越长首字越慢。输出中断卡字已经开始往外蹦了但中间突然停顿几秒或者速度忽快忽慢像网络不稳定一样。这个一般就不是模型推理本身的问题了而是资源被抢占、显存不够导致部分层被挪到 CPU、或者 Roo Code 的 webview 渲染跟不上。这类卡顿最隐蔽排查起来也最费劲。1.2 用 ollama serve 日志和 ollama ps 做第一轮定位先别急着改参数。把 Ollama 的日志打开连续发起几次 Roo Code 请求观察日志里类似这样的两行输出prompt eval rate: 856.32 tokens/s eval rate: 29.14 tokens/sprompt eval rate是预填充速度也就是“读题”速度eval rate是生成速度也就是“答题”速度。这两个数字直接告诉你瓶颈在哪。如果prompt eval rate只有一两百说明预填充阶段严重拖后腿如果eval rate只有十几个 token/s说明生成阶段出了问题优先怀疑显存、并发或模型是否被拆到 CPU 上跑。再配合ollama ps看模型是否常驻ollama ps如果执行完发现 UNTIL 一栏显示的是5 minutes之类的时间说明 keep_alive 机制还在起作用模型每隔一段时间就会被卸载。这是冷启动卡顿最直接、最容易被忽略的根源。症状直观感受最可能的瓶颈优先排查项冷启动卡转圈很久后突然开始输出模型未驻留、加载权重耗时OLLAMA_KEEP_ALIVE首字卡开始输出后速度正常但首个字等很久上下文预填充过重num_ctx、Flash Attention、上下文长度输出中断/忽快忽慢输出断断续续像挤牙膏显存被抢占、CPU 回退、并发过高OLLAMA_NUM_PARALLEL、显存余量、MCP 组件2. Ollama 服务端参数提速先把地基打好确认了卡顿类型之后就可以开始调 Ollama 这一侧的参数了。很多人一上来就盯着模型量化、换显卡却忽略了 Ollama 服务本身有一堆环境变量专门控制显存驻留、并发和 GPU 使用策略。这些参数不改后面做的所有优化都可能白费。2.1 模型驻留OLLAMA_KEEP_ALIVE 解决冷启动Ollama 默认的 keep_alive 只有 5 分钟。意思是你和它最后一次交互后超过 5 分钟它就会把模型从显存里卸载。对于编辑器这种“想起来就点一下、想不起来就晾半天”的使用场景5 分钟实在太短了。你上午改完代码去开会回来再点 Roo Code它又要重新加载模型自然卡顿。设置方式按系统来Windows系统环境变量里新建OLLAMA_KEEP_ALIVE-1然后完全退出 Ollama 托盘图标再启动。macOSlaunchctl setenv OLLAMA_KEEP_ALIVE -1然后重启 Ollama 应用。Linux编辑 systemd override 文件给 Ollama 服务加上EnvironmentOLLAMA_KEEP_ALIVE-1然后systemctl daemon-reload并重启服务。注意-1表示模型一直驻留直到你手动ollama stop或重启服务。显存比较小的机器建议配合后面的OLLAMA_MAX_LOADED_MODELS1使用避免它同时驻留多个模型把显存挤爆。我自己的实测是设置前每次被冷启动的请求要等 8~15 秒设置后基本是点击即有响应冷启动的体感从“完全不可用”变成了“没感觉”。2.2 并发与多模型抢占OLLAMA_NUM_PARALLEL 和 OLLAMA_MAX_LOADED_MODELS很多教程会告诉你调大OLLAMA_NUM_PARALLEL可以提升吞吐这是服务器场景下的思路。但本地编辑器场景完全相反。Roo Code 本身就可能同时发起多个子任务请求如果 Ollama 再允许多个请求并行GPU 的显存和计算资源就会被多个任务平分每个单独请求的速度都会明显下降。比如你在 Roo Code 里让它同时生成两个文件两个请求并行抢显存各自分配的 KV cache 被压缩生成速度可能从 30 tok/s 掉到 15 tok/s 左右。显存一紧张Ollama 还会把模型权重往 CPU 上搬速度直接崩盘。所以我的建议非常明确OLLAMA_NUM_PARALLEL1让单个请求独占 GPU生成速度最稳定。你的目标不是“同时服务很多人”而是让 Roo Code 正在用的这个请求以最快速度跑完。OLLAMA_MAX_LOADED_MODELS1避免多个模型同时驻留抢显存。这里多说一句如果显存特别大的机器把并行度保持默认也不是不行但对于 12GB 甚至 16GB 显存的主流配置并行带来的体验损失远大于收益。我自己的数据是关闭并行后生成速度稳定提升了 30% 以上而且中途停顿的次数明显减少。2.3 显存预留、Flash Attention 与 KV Cache 量化还有三个环境变量看起来不起眼配合起来影响巨大。OLLAMA_GPU_OVERHEAD给 Ollama 之外的程序预留显存。VS Code 的 webview 渲染、系统的桌面合成器都要吃显存如果 Ollama 把显存占得一丝不剩系统开始跟它抢最终结果就是 Ollama 被 OOM 或者被迫把部分模型层放到 CPU。建议设置 1024按你的 Ollama 版本文档确认单位一般按 MiB 计1024 即预留 1GB。OLLAMA_FLASH_ATTENTION1开启 Flash Attention能明显改善长上下文场景的预填充速度和显存占用。这个变量对“首字卡”帮助最大尤其是你在 Roo Code 里塞了好几个文件、上下文冲到上万 token 的时候。OLLAMA_KV_CACHE_TYPEq8_0默认情况下 KV cache 用 FP16 存储换成 q8 量化后显存占用直接减半质量损失非常小。它主要解决的是“上下文一长KV cache 把显存占满”的问题。FP16 的 KV cache 在 14B 模型、8K 上下文下就已经是 GB 级别上下文再往上翻倍显存立刻告急。这三个变量和前面的驻留、并发配置目标是一致的让模型权重和 KV cache 全部稳定留在 GPU 里不反复加载、不换出到 CPU、不并行抢占让单个请求以全功率跑。这一步做到了你的本地模型才算是真正“住在”显卡里。3. 上下文长度是 Roo Code 卡顿的隐形推手如果说服务端参数是地基那上下文长度就是整栋楼的结构问题。我在相当长一段时间里被“首字卡”折磨怎么调环境变量都收效甚微后来才意识到问题根本不在服务端而在 Roo Code 每次发送的请求太重了。3.1 Roo Code 的“重上下文”到底有多重Roo Code 每次调用模型时包里会装这些东西系统提示词、可用工具定义、你项目里的规则文件、当前对话的全部历史以及中途通过引用或工具读取加入的文件内容。我实际统计过一次在完全不读写任何文件、只发一句普通指令的情况下系统提示词加工具定义大约是 3000~5000 token如果再把当前打开的几个文件内容塞进去轻松过万。问题在于Ollama 对上下文长度有一个叫num_ctx的参数限制。默认值普遍在 2048/4096 这个量级一旦请求的实际内容超过限制模型要么被截断要么需要把整段上下文完整预填充一遍——而预填充耗时是和上下文长度线性增长的。于是你看到了很多人抱怨的诡异现象本地模型明明算力全在本机却比调用远程 API 还要慢。API 慢在网络本地模型慢在预填充被默认配置放大了。这里有一个反直觉的点num_ctx并不是调得越大越好。调大num_ctx后KV cache 显存占用线性增长预填充耗时也会增长。对 Roo Code 日常编码任务8K~16K 是我认为性价比最高的区间。设置太小模型会“失忆”频繁丢失早期信息导致重复操作设置太大每次请求都要白算一整段冗长的上下文得不偿失。3.2 num_ctx 具体怎么改三种改法按推荐顺序来在 Roo Code 的 Ollama Provider 配置里找 “Extra API Options” 输入框Roo Code / Cline 系扩展都有填入 JSON{ options: { num_ctx: 8192, keep_alive: 30m } }改 Modelfile 重建模型。写一个 Modelfile里面带上num_ctx 8192然后执行ollama create 你的模型名 -f Modelfile临时用ollama run里的/set parameter num_ctx 8192验证效果但这个方法不持久只适合简单测试。我的建议是先改 Extra API Options。它最直观不用动模型文件改完立刻生效。需要留意的是这个设置只对 Roo Code 发出的请求生效如果你同时用其他客户端连同一个 Ollama那边需要单独再配。3.3 模型量化与显存选型不要盲目上大模型卡顿还有一个隐变量是模型量化等级。同一个 7B 模型q4_K_M 和 q8 的显存占用与速度差距可以达到 30% 甚至更高。对 Roo Code 这种高频交互场景我的经验是速度优先于精度q4_K_M 是第一选择显存有富余再考虑 q6/q8。不要一上来就追求“看起来质量更高”生成速度慢到没法用的时候质量再好也是零。关于显存和模型规模的匹配我整理了一张经验表显卡显存推荐模型规模推荐量化上下文长度8GB7B 级q4_K_M8K12GB14B 级q4_K_M8K~16K16GB14B q8 或 32B q4按需16K24GB 以上32B q8按需16K~32K如果模型太大被拆到 CPU 上跑生成速度会直接掉到个位数那种卡顿是任何参数都救不回来的。用ollama ps看 PROCESSOR 列如果不是 100% GPU果断降量化或者换小模型。4. Roo Code 侧收敛少发送、少渲染、少等待服务端和上下文都调完之后剩下的优化就要转到 Roo Code 这一侧了。这个阶段的核心思路只有一个尽量让每次请求携带的信息更少让 Roo Code 界面上的无效渲染更少让不必要的工具调用更少。4.1 .rooignore 与精准引用控制输入规模Roo Code 的大多数延迟都和它发送的上下文体量直接相关。项目里如果存在node_modules、dist、build这类大型目录一旦被代理工具读取或索引很容易把上下文撑爆。正确做法是在项目根目录加一个.rooignore文件和.gitignore同理把大型目录排除在外node_modules/ dist/ build/ coverage/ *.lock .tmp/然后尽量用精准引用具体文件而不是整个文件夹。你喂给模型的信息越少预填充越快模型被无关代码干扰产生误判的概率也越低。另外Roo Code 的规则Rules文件也别写几百行教条式内容它每次请求都会进系统提示词规则越长等于每次请求越慢。如果你已经在某个任务里堆积了大量历史对话别犹豫直接开新任务或者清空会话历史。旧对话里的几百条消息会一直作为上下文背着跑相当于每次请求都在负重登山。4.2 关闭思维链与降低推理强度如果你用的是带推理能力的模型比如 QWQ、DeepSeek-R1 蒸馏版这类模型会在正式回答前输出一大段思考过程。Roo Code 会把这部分内容实时渲染出来看起来就像一个字数黑洞体感上和“卡住”几乎无法区分。你盯着思考链滚动以为工具坏了其实模型还在“想”。在 Roo Code 的参数配置里找 Reasoning Effort能设 None 或 Low 就直接设低如果模型本身没有这个开关最简单的方法就是换成非推理的 instruct 版本。比如你用 qwen2.5-coder 系列就直接用 7b 或 14b 的 instruct 版本别用那种专门为了“思考而思考”的推理版本。顺带一提把 Roo Code 设置里的详细日志Verbose Logging关掉。日志输出本身也有开销虽然不大但在低配机器上积少成多。4.3 MCP 是隐藏的上下文吞金兽MCP 是 Roo Code 最大的扩展点也是最容易拖慢速度的暗坑。每挂一个 MCP server它的工具定义就会在每次请求时以系统提示词的形式注入给模型。一个 MCP 几十几百 token 不觉得挂五个十个就相当可观了。更糟糕的是本地 MCP 服务启动慢、单次调用响应慢Roo Code 在工具调用环节会额外等待。我的建议是写代码场景MCP 宁缺毋滥。真需要浏览器操作、数据库查询、文件读写再启用否则全部卸载。你可以一个个关掉然后对比一次请求的首 token 时间效果非常直观。如果你像我一样接入了向量数据库或本地 embedding 类的 MCP 组件它们通常也会带很长的工具定义和额外调用链属于高重量级组件留一个够用就好别叠太多。Roo Code 里 MCP 工具数量越少整体响应越接近原生推理速度。5. 实测数据与可直接抄的最终配置清单前面讲的都是原理和方向这一节给出我反复验证后一直在用的最终配置以及一份实测前后的对比数据。你的机器可能和我的不同但优化方向和参数组合是通用的。5.1 基准测试怎么做才有参考价值我调整参数时有一个固定测试方法新建一个空任务让模型生成一个包含三个小函数的工具类同一模型、同一 prompt分别记录首 token 时间和总生成时间。测试前先执行ollama ps确认模型已经驻留关闭浏览器和其他吃显存的程序保证结果可比。这样测出来的绝对数值在每个人的机器上不同但优化前后的相对变化方向是一致的冷启动消失最明显生成速度提升其次最容易被忽视的“中途停顿”改善后整个交互会像换了一个工具。5.2 优化前后对比以下是我在 12GB 显存、qwen2.5-coder:14b-q4_K_M 的典型配置下记录的数据指标默认配置优化后备注冷启动等待10~20 秒基本 0 秒模型常驻后点击直接响应首 token 时间8~15 秒1~2 秒预填充速度和上下文长度明显改善生成速度20~25 tok/s35~45 tok/s并发设为 1GPU 独占中途停顿/断流频繁几乎不出现显存不被其他模型或进程抢占上下文“失忆”经常截断8K 内稳定num_ctx 被显式设置5.3 最终参数清单照着填就行Ollama 环境变量设置后必须完全重启 Ollama 服务OLLAMA_KEEP_ALIVE-1 OLLAMA_NUM_PARALLEL1 OLLAMA_MAX_LOADED_MODELS1 OLLAMA_GPU_OVERHEAD1024 OLLAMA_FLASH_ATTENTION1 OLLAMA_KV_CACHE_TYPEq8_0Roo Code Provider 配置OllamaBase URL: http://127.0.0.1:11434 Model ID: qwen2.5-coder:14b-instruct-q4_K_M Extra API Options: { options: { num_ctx: 8192, keep_alive: 30m } }有几个容易忽略的细节我单独列一下Base URL 优先用127.0.0.1不要用localhost避免系统把地址解析到 IPv6 造成额外延迟。如果你的 Ollama 装在 WSL 或远程机器上Roo Code 连的就不是127.0.0.1而是对应机器的局域网 IP。这种情况下先把基础网络延迟排除掉再来谈模型速度。改完环境变量后务必确认 Ollama 服务是全新启动的进程。Windows 托盘图标那个进程如果没有完全退出新环境变量就不会生效你改了等于没改。每次换模型之后重新看一眼ollama ps确认 PROCESSOR 列是 100% GPU并且显存余量充足。按这套配置走完我的实际感受是Roo Code 的输出不再像挤牙膏一样慢慢往外蹦而是和终端里直接敲ollama run一样字是顺着流出来的。这也是我把优化的目标定义成“原生速度”的原因——本地模型的原生推理速度并不差差的是它在整条链路里被各种默认配置偷偷降速了。最后再补一个个人习惯我每次调完配置都会跑一遍第 5.1 节的基准测试记录三组数字首 token 时间、生成速度、中途停顿次数。下次换模型或升级 Ollama 版本后拿同一组数字对比就能快速判断新版本有没有退化。这套“记录—对比—调整”的方法比每次凭感觉调参要有效得多。