Roo Code 是很多人接本地模型的首选我自己也是从 Cline 时代一路用过来的。刚开始把 Ollama 或 LM Studio 的模型接进去兴奋劲儿没过就被现实打脸在 Roo Code 里点一个任务转圈半分钟才蹦出第一个字生成速度比直接敲 API 慢了好几倍遇到长文件甚至直接 Request timed out。折腾了一个多星期翻了不少 issue最后把整条链路从模型选择、推理引擎参数到扩展侧配置全部理了一遍才算把速度拉回到接近原生调用的水平。这篇就把我踩过的坑和最终验证可用的优化方案完整写出来给同样被本地模型卡到怀疑人生的朋友一个参考。1. 先搞清楚卡顿发生在哪一层Roo Code 调本地模型的完整链条很多人一遇到卡顿就怀疑是模型不行或者直接怪 Roo Code 垃圾其实问题往往没那么简单。Roo Code 调用本地模型不是一条直线中间隔了好几个环节每个环节都可能成为瓶颈。1.1 为什么选择 Roo Code 加本地模型以及这个组合的天然短板Roo Code 是目前 VS Code 和 Cursor 生态里比较活跃的 Agent 编程扩展前身是 Roo Cline从 Cline 分支出来之后在工具调用和任务规划上做得更加激进。它可以让 AI 自己决定读哪些文件、改哪些代码、执行什么终端命令适合做多步骤的编码任务。而本地模型的好处不用多说数据不出机器、没有按 token 计费、隐私文件随便喂、离线也能写代码。但本地模型跑 Roo Code 有一个天然短板Roo Code 是 Agent 形态每一轮决策都要把完整对话历史、文件内容和上次工具执行的结果重新发给模型。这意味着对话轮次越深请求体越大模型每次都要先重新读一遍所有上下文这就是延迟的根源之一。我在后面会细讲这里先把整个链路拆开。1.2 一次请求的完整旅程扩展发起、API 转发、引擎推理、结果回流我给一个实际请求画一条路径你就能理解哪里会慢了。当你在 Roo Code 里说帮我把这个模块改造成异步实现发生的是这几件事Roo Code 把系统提示词、历史对话、相关文件内容和你的新指令拼成一个完整的 Prompt通过 OpenAI 兼容的 API 格式POST 到本地推理引擎比如 Ollama 或 LM Studio的/v1/chat/completions接口推理引擎把 Prompt 切分成 token先做一次 Prefill预填充然后开始逐 token 生成回复生成过程按流式方式把 token 逐步返回给 Roo Code如果配置了流式的话Roo Code 收到完整回复后解析出工具调用执行工具把结果又拼进下一轮请求的上下文里继续循环这个链路里任何一个环节掉链子都会表现为卡顿第 2 步可能是网络或端口问题第 3 步是模型和引擎的推理性能问题第 4 步是流式配置问题第 1 步和第 5 步则是 Roo Code 自身的上下文管理问题。1.3 卡顿分两类首字延迟高和生成速度慢解决方案完全不同我踩坑之后最大的体会是卡顿不是一种病而是两种完全不同的病搞混了你永远调不好。第一类是首字延迟高就是点了发送之后要等很久才看到第一个字。问题几乎都出在 Prefill 阶段——模型要把你塞给它的所有 token 都算一遍。塞的上下文越多、模型越大、硬件越弱首字越慢。Roo Code 这类 Agent 工具非常容易触发这个问题因为它的 Prompt 总是很长。第二类是生成速度慢就是第一个字出来了但后续每个字都像挤牙膏一样。这是 Decode 阶段的问题也就是逐 token 生成的吞吐量上不去。罪魁祸首通常是模型没有完全加载进显卡CPU 在硬算或者用了非常高的量化精度、内存带宽不足等。搞清楚你卡的是哪一类再去调参数才不会南辕北辙。我自己一开始就犯了这个错拼命调上下文长度结果真正的问题是模型压根没跑在 GPU 上。2. 源头优化模型选型、量化档位和上下文长度怎么定很多人兴致勃勃接上本地模型第一个坑就栽在模型选择上。Roo Code 是编码 Agent它对模型的能力要求比单纯聊天高得多不是随便拉一个聊天的模型就能干活的。模型没选对后面再怎么调参都是白搭。2.1 编码场景下的模型尺寸选择7B、14B 还是 32B先给结论Roo Code 日常使用最舒服的档位是 14B 级别的编码专用模型其次是 7B32B 及以上要看你的显卡。以我现在的主力模型 Qwen2.5-Coder-14B 来说它在代码理解和工具调用上的能力明显比 7B 强一个档次尤其在多文件修改、复杂重构任务上不会频繁乱来。7B 模型跑得是快但 Roo Code 这种 Agent 场景模型经常会自作聪明地跳过关键步骤反而让整个任务来回折腾体感上更慢。32B 的模型理论上能力更强但瓶颈很现实显存。Qwen2.5-Coder-32B 即使量化到 Q4_K_M也需要大概 20GB 左右的显存这还没算上下文 KV Cache。普通玩家的 12GB 或 16GB 卡根本塞不下塞不下就会发生部分层 offload 到 CPU速度直接断崖式下跌体感还不如老老实实用 14B。我给一个直观的选型优先级参考显存大小推荐模型档位推荐量化期望速度RTX 40系8GB7BQ4_K_M35-50 token/s12GB14BQ4_K_M25-35 token/s16GB14BQ5_K_M22-30 token/s24GB32BQ4_K_M15-20 token/s24GB32BQ8_0难以完全驻留谨慎2.2 量化档位的速度质量平衡Q4、Q5、Q6、Q8 的实测感受量化是本地模型的必修课。同一个模型从 Q8_0 降到 Q4_K_M文件体积能缩小将近一半推理速度提升明显显存占用也大幅降低。但在 Roo Code 场景下我要提醒一句别盲目追高精度。我的实测体感是Q4_K_M 在代码生成质量上和 Q8_0 的差距远远没有想象中那么大。现在的 K-quant 方法对重要权重做了保护代码任务本身又比较机械化Q4_K_M 完全够用。Q5_K_M 是个比较折中的选择如果显存有富余可以上。Q8_0 我觉得是给有钱任性的朋友准备的速度损失明显收益却微乎其微。还有一个容易被忽略的点量化不仅影响 Decode 速度还影响 Prefill 速度。上下文越长这个差距越明显。我自己用 Q4_K_M 之后长上下文下的首字延迟比 Q8_0 快了差不多一半。2.3 上下文长度不是越大越好KV Cache 会吃掉显存和速度这个坑我印象最深。刚开始用 Ollama 调用 Qwen2.5-Coder-14B按照官方默认设置了很长的上下文。结果是模型加载进去之后显存直接爆了Ollama 自作主张把一部分层挪到 CPU速度掉到每秒钟三四个 token。当时我还以为是模型太大差点把卡卖了。后来才明白上下文长度直接影响 KV Cache 的大小。KV Cache 是模型在推理过程中缓存历史 token 计算结果的地方上下文设得越长KV Cache 占用的显存越多。32K 上下文的 KV Cache 可以轻松吃掉好几 GB 显存。Roo Code 这种工具单轮请求很少需要超过 8K 上下文。我自己实测把上下文限制在 8K 之后显存占用大幅下降模型可以完全驻留 GPU生成速度从个位数直接拉回 30 token/s。如果你的任务确实需要处理很长的文件再按需往上加但默认不要开太大。3. 推理引擎侧优化Ollama、LM Studio、llama.cpp-server 的关键设置模型选对了接下来要看推理引擎。这一步我折腾的时间最长也是一般教程里写的最不清楚的地方。其实核心就三件事让模型完全跑在 GPU 上、把引擎参数调到适合 Agent 场景的状态、以及搞明白你的硬件到底卡在哪。3.1 GPU Offload 必须拉满让显卡干活而不是 CPU 硬扛本地推理引擎的默认行为不一定是全 GPU 推理。有些情况下它会根据显存余量自动决定多少层放 GPU、多少层放 CPU一旦模型层被分配到 CPU 上速度就会瞬间崩盘。在 Ollama 里可以通过 Modelfile 或者环境变量强制模型加载到 GPU。我建议直接写一个 Modelfile简单粗暴FROM qwen2.5-coder:14b PARAMETER num_ctx 8192 PARAMETER num_gpu 999 PARAMETER temperature 0num_gpu 999这个参数就是在告诉 Ollama能放 GPU 的都放 GPU不要犹豫。temperature 0是做代码 Agent 时强烈建议的设置代码任务需要确定性温度太高模型会自己发挥生成的代码前后逻辑对不上。保存成Modelfile之后执行ollama create qwen-coder-repo -f Modelfile就能创建一个自定义模型。用这个自定义模型去接 Roo Code比直接调原始模型更稳。我之前有一次排查半天最后发现就是 temperature 没锁 0模型偶尔会编造工具调用结果导致 Roo Code 反复重试体感上非常卡。LM Studio 的操作更直观启动 Local Server 之前有一个 GPU Offload 滑块直接拉到最大档位。注意看界面上的显存余量提示如果显示需要 12.4GB可用 10.3GB说明你的模型没法完全驻留要么换更小的量化要么换更小的模型别硬上。3.2 引擎参数详解stream、batch、flash attention 和保持驻留这里有几个关键参数直接决定 Agent 场景的体验我逐个说一下我的调法。第一是 stream流式输出。这个必须开启。Roo Code 默认会开启流式但如果你在某些 Provider 配置里把它关掉了就会变成等模型生成完整段回复再一次性返回长回复时体验极其难受看起来就像卡死了。显式开启方式我放在后面 Provider 配置里写。第二是 flash attention。这是把注意力计算重新组织的优化方案能显著减少显存带宽压力对长上下文提升很大。llama.cpp 系的引擎基本都支持Ollama 在较新版本默认开启LM Studio 里是一个单独的勾选项记得打开。开之前长上下文 Prefill 可能需要十几秒开了以后能压缩一半以上。第三是 keep-alive 和并行度。在 Ollama 里每次切换模型权重都要重新加载到显存这本身就是一个巨慢的过程。如果你平时会切换模型或者同时挂了好几个不同的本地模型Roo Code 每次调用都要等权重加载完体感也是卡。设置一个较长的 keep-alive 时长让模型常驻显存或者用OLLAMA_MAX_LOADED_MODELS 1限制同时加载的模型数量减少切换。LM Studio 里对应的是在 Server 设置中调大模型保持加载的时间原理一样。3.3 内存带宽才是真瓶颈双通道、频率与插法这一点很少人提到但真实情况是即使模型全 GPU 推理内存带宽也会影响速度尤其是在纯 CPU 推理或部分 offload 的情况下。我之前一台旧机器用 CPU 推理 7B 模型单通道内存和双通道内存的速度差距接近一倍。原因是推理过程中需要不断读取模型权重和中间结果内存带宽直接决定了数据搬运速度。如果你打算用纯 CPU 或集成显卡跑本地模型请确保内存是双通道也就是插了两根内存条而不是一根。再就是内存频率尽量高一点别让低频内存拖后腿。还有一类情况显卡显存不够部分层在 GPU、部分层在 CPUGPU 和 CPU 之间通过 PCIe 总线搬运数据。这种模式下哪怕 PCIe 3.0 x16 的带宽都可能成为瓶颈。所以我说选型是第一位的你的硬件决定模型档位模型档位决定后续所有体验。4. Roo Code 扩展侧配置Provider 设置、流式开关与上下文瘦身引擎跑顺了Roo Code 这边还有几个坑。很多人配置完能连通就急着用其实扩展侧有几个设置不调速度照样上不去。4.1 Provider 配置的坑baseURL、timeout、stream 开关Roo Code 里添加本地模型走的是 OpenAI Compatible Provider。我踩过第一个坑是 Base URL 填错。Ollama 的 OpenAI 兼容端点地址是http://localhost:11434/v1不是根地址。LM Studio 默认是http://localhost:1234/v1。如果你填错了或者填成根地址要么报 404要么反复重试看起来就像卡死。第二个坑是 API Key。本地引擎不校验 key但 Roo Code 的 Provider 表单又不允许留空随便填一个ollama或者lm-studio就行别真的去配置一个本地 key 校验服务纯属给自己找事。第三个是 timeout 设置。这是最容易忽略的。Roo Code 默认的请求超时时间在部分版本里比较短Agent 场景一个请求可能持续一分钟以上一旦触发 timeout扩展会中断请求然后重试重试意味着重新 Prefill来回折腾两次体感就是卡顿。我直接把 timeout 调到 500000 毫秒也就是差不多 8 分多钟。第四个是流式开关。在配置里明确开启 stream否则很多请求要等全部生成完才返回。Roo Code 的设置项名称在不同版本有差异但我建议你在自定义配置里找stream字样确认是 true。4.2 上下文瘦身和工具循环让 Roo 不把自己卡死这是 Roo Code 特有的问题也是我花了最多时间理解的地方。Roo Code 每一轮都会把完整的历史、工具结果、文件内容重新发送给模型。这意味着任务的第 5 轮请求可能比第 1 轮大了好几倍。如果一开始就把大文件读进来了后面每轮都要重新 Prefill 一遍几万 token 的上下文速度自然飞流直下。我做了两件事来缓解第一通过.rooignore文件排除不必要的文件。和.gitignore类似把 node_modules、dist、构建产物、日志文件都排除掉避免 Roo Code 扫描和读取无关内容。本来 Roo Code 在探索阶段会自己读一堆文件里面的无关 token 全部都在拖慢请求。第二调整自定义指令要求 Roo Code 只在必要时读取文件不要做无意义的全局扫描。我在 Roo Code 的 Custom Instructions 里加了一句读取文件前先判断是否真的需要能用文件路径推断内容就不要再把整个文件读一遍。这听起来很微妙但实测对减少上下文膨胀非常有效。还有一个隐藏很深的坑Roo Code 执行终端命令后会把完整的输出塞进上下文如果某个命令输出了几百行日志下一轮请求就得全部重新 Prefill。遇到这种情况尽量让 Roo Code 执行的命令带上head -50之类的输出截断或者直接要求它只汇报结果摘要。这个习惯养成之后长任务的流畅度提升非常明显。4.3 实用配置示例一份可直接套用的 Roo Code 配置以我目前的配置为例Ollama 作为引擎Roo Code 里选 OpenAI Compatible Provider关键字段如下{ apiProvider: openai, baseUrl: http://localhost:11434/v1, apiModelId: qwen-coder-repo, apiKey: ollama, stream: true, requestTimeoutMs: 500000, temperature: 0 }有个细节模型 ID 填的是我前面用 Modelfile 自定义创建的名字qwen-coder-repo不是原始模型名。这样所有参数都在引擎侧控制好了Roo Code 这边不用重复设置。如果你用 LM Studio模型 ID 就是你下载并加载的那个模型文件名字比如qwen2.5-coder-14b-instruct-q4_k_m.gguf。这里还要提醒一句别在 Roo Code 同时挂多个本地模型 Provider。我一度挂了三四个模型想切换对比结果每次切换都要重新加载权重来回折腾的时间比写代码还长。锁定一个主力模型把参数调好比你同时备着十个模型有用得多。5. 一次完整的卡顿排查链路实录30 秒首字到 2 秒首字的全过程光讲理论不够我把我个人最惨烈也最有代表性的一次排查完整写出来。这个案例基本覆盖了所有新手会踩的坑你顺着这个思路去看自己的环境能少走很多弯路。5.1 症状描述与环境信息那天的环境是这样的台式机CPU 是 i5-12490F内存 32GB 双通道显卡是 RTX 3060 12GB系统是 Windows 10。引擎用 Ollama模型是 Qwen2.5-Coder-14B 的 Q4_K_M 版本Roo Code 是最新版本Base URL 确认无误API Key 填了ollama。症状是在 Roo Code 里新建一个任务让模型修改一个大约 300 行的 Python 文件。点击发送之后界面上的加载动画转了将近 30 秒才跳出第一个字之后每个字大约 0.4 到 0.6 秒一个完整回复生成完大约花了 40 多秒。第二三轮对话之后等待时间更长甚至出现过两次 Request timed out 报错。5.2 排查步骤一先绕过 Roo Code直接用引擎验证我的排查原则是先确认问题出在 Roo Code 这一层还是引擎这一层。方法非常简单直接用 curl 调用引擎 API模拟 Roo Code 发一个同样大小的请求。我用了一段和 Roo Code 当时差不多长度的 Prompt 去测curl http://localhost:11434/api/generate -d {\model\: \qwen-coder-repo\, \prompt\: \系统提示词和任务描述略\, \stream\: false}结果非常意外即便是几千 token 的 Prompt模型的响应速度也很快输出 500 字左右的代码大约只花了 10 秒出头。这说明引擎本身没有问题模型也在 GPU 上。问题几乎可以确定出在 Roo Code 这一层或者 Roo Code 发给引擎的请求有异常。5.3 排查步骤二抓 Roo Code 发给引擎的请求内容接下来要搞清楚 Roo Code 到底给引擎发了什么。Ollama 有日志输出我把日志打开看到了每个请求的 token 数统计。不看不知道一看吓一跳Roo Code 发出的请求Prompt 里包含的 token 数从第一轮的八千多迅速涨到了第二轮的将近两万第三轮直接超过三万。而且请求里有一段非常明显的大块内容——上一次工具调用的完整输出是一大段文件读取结果占了将近一万 token。这就是为什么第二轮开始卡得越来越明显。但这里有个奇怪的点即便三轮后有三万 token 的 PromptQwen2.5-Coder 在 3060 上 Prefill 三万 token 也不至于要 30 秒。我继续往下挖发现 Ollama 日志里模型的实际运行状态有问题模型确实加载了但上下文窗口设置远大于模型实际加载的 KV Cache 分配量导致每次 Prefill 时都要做动态扩容缓存反复重算浪费了大量时间。这一下就清楚了Roo Code 发来的 Prompt 越来越大而我对 Ollama 的num_ctx设置只在 Modelfile 里设了 8192理论上超出会被截断。但实际表现是引擎在超长 Prompt 下做了性能和显存的折中反而拖慢了。5.4 排查步骤三定位到上下文膨胀和 KV Cache 配置冲突进一步验证的方法很简单我直接用很长的 Prompt 调用引擎 API观察响应时间和显存占用然后逐渐缩短 Prompt看响应时间的变化曲线。数据显示Prompt 超过一万 token 后每增加一千 token首字延迟增加约 1.5 秒超过两万后增加得更多。这很反常。我后来判断是 KV Cache 的分配策略问题。Ollama 在某些版本下如果模型的num_ctx设置和实际显存余量不匹配会采用一种比较保守但效率较低的缓存策略导致 Prefill 速度远低于应有水平。我没有去深挖 Ollama 内部实现而是直接做了一个组合操作把 Modelfile 里的num_ctx明确设为 8192然后给 Roo Code 的 Custom Instructions 里加了一条每次处理文件时只读取关键片段避免把整个文件塞进上下文。同时用.rooignore把项目里的大文件和无关目录全部屏蔽掉。最关键的一步是把 Roo Code 侧requestTimeoutMs调大到 500000避免长请求被中途掐断重试。5.5 修复后的数据对比与仍然存在的隐患修复之后我重新测了同一任务指标修复前修复后第一轮首字延迟28-32 秒2-3 秒后续轮次首字延迟40 秒以上3-5 秒生成速度2-5 token/s25-35 token/stimeout 报错频繁极少发生整个体验直接从没法用变成了能日常用。但我也要说一句只要还用 Roo Code 这种 Agent 做长任务上下文膨胀问题就不可能完全消失。你给它的任务越复杂它需要调用的工具和读取的文件越多上下文就会越长。我只能通过持续优化指令和使用习惯来控制但没法根除。这也决定了本地模型跑 Roo Code 的体验上限——32B 及以上的大模型在上下文膨胀之后依然会力不从心这也是现实。6. 验收优化成果实测数据、量化指标与几个常被忽略的经验优化做得对不对嘴上说没用得有数据支撑。我自己是用几个硬指标来评估是否已经接近原生速度的方便清楚优化到了什么程度、还有没有继续榨取的空间。6.1 怎么客观判断优化程度token/s、首字延迟、交互体感三件套量化本地模型性能主要有三个指标我会分别测试组合起来判断第一个是生成速度单位 token/s。这个可以直接看 Ollama 或 LM Studio 的统计信息也可以用脚本计时。对于 14B 模型在 RTX 3060 上跑到 25 到 35 token/s 基本就是接近原生速度了。如果是个位数肯定有环节不对。第二个是首字延迟。这个用流式请求来测从发起请求到收到第一个 token 的时间。优化后短 Prompt 应该在 1 到 3 秒长 Prompt 在 5 到 10 秒。超过这个范围就要检查上下文是不是塞爆了或者模型是否没完全上 GPU。第三个是交互体感这是最真实的指标。我自己的标准是在 Roo Code 里发起一个修改任务转圈超过 5 秒就开始烦躁超过 10 秒就想放弃。优化到原生速度意味着大多数普通任务从发起到开始响应不超过 3 秒。达不到这个标准就继续排查。测试方法也简单写个 Python 脚本分别测短 Prompt 和长 Prompt或者直接在 Roo Code 里点几个高频任务感受一下。我一般两种都做脚本测数据真实任务测体感。6.2 几个古灵精怪但确实有效的偏方优化做到位之后我还积累了几个非主流但确实有用的经验。第一个是重启 Ollama 进程。听起来很傻但这个真的管用。Ollama 运行时间长了之后显存碎片和缓存策略会越来越差偶尔一个任务突然变慢重启一下进程立刻恢复。我在 Windows 上遇到过好几次给它加一个定时的重启计划基本上能规避。第二个是给 Ollama 设置环境变量调低并行度。Roo Code 本身是串行调用模型的同一时间只会有一个请求。但如果你电脑上还跑了其他用到 Ollama 的东西就可能产生并发请求引擎为了处理并行会拆分子批每个请求变慢。我设置了OLLAMA_NUM_PARALLEL 1强制串行处理反而整体更顺畅。第三个是关闭 LM Studio 的重型界面。LM Studio 装了模型之后启动 Server那个图形界面本身会占用不少资源。我之前有段时间总感觉速度比预期慢后来发现是 LM Studio 的界面动画和模型预览占了一些 CPU 资源。如果机器性能一般启动完 Server 后把界面最小化或者用更轻量的 llama.cpp-server 替代。6.3 我最想强调的三条经验折腾完这一整套我最想对后来者说的三句话是第一模型能不能完全塞进显存是一切速度的地基。模型大于显存的那一刻带宽和 CPU 计算就成了瓶颈不管你怎么调 Roo Code、怎么调上下文都是治标不治本。看到卡顿第一反应应该是查显存占用而不是一头扎进参数堆。第二Agent 工具的上下文管理能力比模型推理速度更影响体感。本地模型再快也架不住每次请求都重新读一遍几万 token 的历史。Roo Code 这种工具你必须在自定义指令和忽略文件上花心思压住它的上下文膨胀才能真正享受本地模型的速度优势。第三把引擎侧参数和扩展侧参数一次配置到位不要用默认值裸奔。num_ctx、num_gpu、flash_attention、temperature、timeout、stream这些参数我上面给的配置是我验证过能直接工作的组合。你可以在它基础上微调但别跳过。每跳过一步都可能埋一个你看不见的性能地雷。6.4 如果你的环境跟我的不一样从这几个方向自适应调整我的配置是基于 Windows N 卡 Ollama 的环境如果你环境不同照着思路平移就行几个对应关系如下Mac 用户尤其是 Apple Silicon情况反而更友好。统一内存架构让 CPU 和 GPU 共享内存只要内存够大大部分模型都能直接驻留 GPU。关注点是别同时开太多其他吃内存的应用给模型留足空间。如果用的是 LM Studio核心差异在于 GPU Offload 滑块和 Context Length 输入框。把这两个弄明白就行其他的配置逻辑和 Ollama 一致。还有 LM Studio 的 Auto 选项有时候会自动选择非最优的 offload 策略我建议你手动拉满 GPU 比例。如果显卡显存特别小比如 8GB 以下直接死心别碰 14B 以上的模型。老老实实用 7B 的 Q4 量化Roo Code 日常小改改也够用。强行跑大模型换来的是额外的加载时间和频繁的 offload体验只会更差。这套优化做完之后我现在在 Roo Code 里做日常重构、写单测、解释历史代码基本上跟用远程的 API 服务没有明显体感差异了。有时候甚至觉得本地模型反而更顺手因为隐私文件随便喂不用担心中间环节泄露。如果你也在折腾 Roo Code 接本地模型被卡顿折磨按我这条链路把模型选型、引擎配置、扩展设置全部捋一遍大概率也能从 30 秒等待里解脱出来。 
长河君 · 2026/10/5 5:02:16 · 阅读 1.2k Roo Code 本地模型卡顿？从模型选型到引擎配置的全链路优化指南
Roo Code 是很多人接本地模型的首选我自己也是从 Cline 时代一路用过来的。刚开始把 Ollama 或 LM Studio 的模型接进去兴奋劲儿没过就被现实打脸在 Roo Code 里点一个任务转圈半分钟才蹦出第一个字生成速度比直接敲 API 慢了好几倍遇到长文件甚至直接 Request timed out。折腾了一个多星期翻了不少 issue最后把整条链路从模型选择、推理引擎参数到扩展侧配置全部理了一遍才算把速度拉回到接近原生调用的水平。这篇就把我踩过的坑和最终验证可用的优化方案完整写出来给同样被本地模型卡到怀疑人生的朋友一个参考。1. 先搞清楚卡顿发生在哪一层Roo Code 调本地模型的完整链条很多人一遇到卡顿就怀疑是模型不行或者直接怪 Roo Code 垃圾其实问题往往没那么简单。Roo Code 调用本地模型不是一条直线中间隔了好几个环节每个环节都可能成为瓶颈。1.1 为什么选择 Roo Code 加本地模型以及这个组合的天然短板Roo Code 是目前 VS Code 和 Cursor 生态里比较活跃的 Agent 编程扩展前身是 Roo Cline从 Cline 分支出来之后在工具调用和任务规划上做得更加激进。它可以让 AI 自己决定读哪些文件、改哪些代码、执行什么终端命令适合做多步骤的编码任务。而本地模型的好处不用多说数据不出机器、没有按 token 计费、隐私文件随便喂、离线也能写代码。但本地模型跑 Roo Code 有一个天然短板Roo Code 是 Agent 形态每一轮决策都要把完整对话历史、文件内容和上次工具执行的结果重新发给模型。这意味着对话轮次越深请求体越大模型每次都要先重新读一遍所有上下文这就是延迟的根源之一。我在后面会细讲这里先把整个链路拆开。1.2 一次请求的完整旅程扩展发起、API 转发、引擎推理、结果回流我给一个实际请求画一条路径你就能理解哪里会慢了。当你在 Roo Code 里说帮我把这个模块改造成异步实现发生的是这几件事Roo Code 把系统提示词、历史对话、相关文件内容和你的新指令拼成一个完整的 Prompt通过 OpenAI 兼容的 API 格式POST 到本地推理引擎比如 Ollama 或 LM Studio的/v1/chat/completions接口推理引擎把 Prompt 切分成 token先做一次 Prefill预填充然后开始逐 token 生成回复生成过程按流式方式把 token 逐步返回给 Roo Code如果配置了流式的话Roo Code 收到完整回复后解析出工具调用执行工具把结果又拼进下一轮请求的上下文里继续循环这个链路里任何一个环节掉链子都会表现为卡顿第 2 步可能是网络或端口问题第 3 步是模型和引擎的推理性能问题第 4 步是流式配置问题第 1 步和第 5 步则是 Roo Code 自身的上下文管理问题。1.3 卡顿分两类首字延迟高和生成速度慢解决方案完全不同我踩坑之后最大的体会是卡顿不是一种病而是两种完全不同的病搞混了你永远调不好。第一类是首字延迟高就是点了发送之后要等很久才看到第一个字。问题几乎都出在 Prefill 阶段——模型要把你塞给它的所有 token 都算一遍。塞的上下文越多、模型越大、硬件越弱首字越慢。Roo Code 这类 Agent 工具非常容易触发这个问题因为它的 Prompt 总是很长。第二类是生成速度慢就是第一个字出来了但后续每个字都像挤牙膏一样。这是 Decode 阶段的问题也就是逐 token 生成的吞吐量上不去。罪魁祸首通常是模型没有完全加载进显卡CPU 在硬算或者用了非常高的量化精度、内存带宽不足等。搞清楚你卡的是哪一类再去调参数才不会南辕北辙。我自己一开始就犯了这个错拼命调上下文长度结果真正的问题是模型压根没跑在 GPU 上。2. 源头优化模型选型、量化档位和上下文长度怎么定很多人兴致勃勃接上本地模型第一个坑就栽在模型选择上。Roo Code 是编码 Agent它对模型的能力要求比单纯聊天高得多不是随便拉一个聊天的模型就能干活的。模型没选对后面再怎么调参都是白搭。2.1 编码场景下的模型尺寸选择7B、14B 还是 32B先给结论Roo Code 日常使用最舒服的档位是 14B 级别的编码专用模型其次是 7B32B 及以上要看你的显卡。以我现在的主力模型 Qwen2.5-Coder-14B 来说它在代码理解和工具调用上的能力明显比 7B 强一个档次尤其在多文件修改、复杂重构任务上不会频繁乱来。7B 模型跑得是快但 Roo Code 这种 Agent 场景模型经常会自作聪明地跳过关键步骤反而让整个任务来回折腾体感上更慢。32B 的模型理论上能力更强但瓶颈很现实显存。Qwen2.5-Coder-32B 即使量化到 Q4_K_M也需要大概 20GB 左右的显存这还没算上下文 KV Cache。普通玩家的 12GB 或 16GB 卡根本塞不下塞不下就会发生部分层 offload 到 CPU速度直接断崖式下跌体感还不如老老实实用 14B。我给一个直观的选型优先级参考显存大小推荐模型档位推荐量化期望速度RTX 40系8GB7BQ4_K_M35-50 token/s12GB14BQ4_K_M25-35 token/s16GB14BQ5_K_M22-30 token/s24GB32BQ4_K_M15-20 token/s24GB32BQ8_0难以完全驻留谨慎2.2 量化档位的速度质量平衡Q4、Q5、Q6、Q8 的实测感受量化是本地模型的必修课。同一个模型从 Q8_0 降到 Q4_K_M文件体积能缩小将近一半推理速度提升明显显存占用也大幅降低。但在 Roo Code 场景下我要提醒一句别盲目追高精度。我的实测体感是Q4_K_M 在代码生成质量上和 Q8_0 的差距远远没有想象中那么大。现在的 K-quant 方法对重要权重做了保护代码任务本身又比较机械化Q4_K_M 完全够用。Q5_K_M 是个比较折中的选择如果显存有富余可以上。Q8_0 我觉得是给有钱任性的朋友准备的速度损失明显收益却微乎其微。还有一个容易被忽略的点量化不仅影响 Decode 速度还影响 Prefill 速度。上下文越长这个差距越明显。我自己用 Q4_K_M 之后长上下文下的首字延迟比 Q8_0 快了差不多一半。2.3 上下文长度不是越大越好KV Cache 会吃掉显存和速度这个坑我印象最深。刚开始用 Ollama 调用 Qwen2.5-Coder-14B按照官方默认设置了很长的上下文。结果是模型加载进去之后显存直接爆了Ollama 自作主张把一部分层挪到 CPU速度掉到每秒钟三四个 token。当时我还以为是模型太大差点把卡卖了。后来才明白上下文长度直接影响 KV Cache 的大小。KV Cache 是模型在推理过程中缓存历史 token 计算结果的地方上下文设得越长KV Cache 占用的显存越多。32K 上下文的 KV Cache 可以轻松吃掉好几 GB 显存。Roo Code 这种工具单轮请求很少需要超过 8K 上下文。我自己实测把上下文限制在 8K 之后显存占用大幅下降模型可以完全驻留 GPU生成速度从个位数直接拉回 30 token/s。如果你的任务确实需要处理很长的文件再按需往上加但默认不要开太大。3. 推理引擎侧优化Ollama、LM Studio、llama.cpp-server 的关键设置模型选对了接下来要看推理引擎。这一步我折腾的时间最长也是一般教程里写的最不清楚的地方。其实核心就三件事让模型完全跑在 GPU 上、把引擎参数调到适合 Agent 场景的状态、以及搞明白你的硬件到底卡在哪。3.1 GPU Offload 必须拉满让显卡干活而不是 CPU 硬扛本地推理引擎的默认行为不一定是全 GPU 推理。有些情况下它会根据显存余量自动决定多少层放 GPU、多少层放 CPU一旦模型层被分配到 CPU 上速度就会瞬间崩盘。在 Ollama 里可以通过 Modelfile 或者环境变量强制模型加载到 GPU。我建议直接写一个 Modelfile简单粗暴FROM qwen2.5-coder:14b PARAMETER num_ctx 8192 PARAMETER num_gpu 999 PARAMETER temperature 0num_gpu 999这个参数就是在告诉 Ollama能放 GPU 的都放 GPU不要犹豫。temperature 0是做代码 Agent 时强烈建议的设置代码任务需要确定性温度太高模型会自己发挥生成的代码前后逻辑对不上。保存成Modelfile之后执行ollama create qwen-coder-repo -f Modelfile就能创建一个自定义模型。用这个自定义模型去接 Roo Code比直接调原始模型更稳。我之前有一次排查半天最后发现就是 temperature 没锁 0模型偶尔会编造工具调用结果导致 Roo Code 反复重试体感上非常卡。LM Studio 的操作更直观启动 Local Server 之前有一个 GPU Offload 滑块直接拉到最大档位。注意看界面上的显存余量提示如果显示需要 12.4GB可用 10.3GB说明你的模型没法完全驻留要么换更小的量化要么换更小的模型别硬上。3.2 引擎参数详解stream、batch、flash attention 和保持驻留这里有几个关键参数直接决定 Agent 场景的体验我逐个说一下我的调法。第一是 stream流式输出。这个必须开启。Roo Code 默认会开启流式但如果你在某些 Provider 配置里把它关掉了就会变成等模型生成完整段回复再一次性返回长回复时体验极其难受看起来就像卡死了。显式开启方式我放在后面 Provider 配置里写。第二是 flash attention。这是把注意力计算重新组织的优化方案能显著减少显存带宽压力对长上下文提升很大。llama.cpp 系的引擎基本都支持Ollama 在较新版本默认开启LM Studio 里是一个单独的勾选项记得打开。开之前长上下文 Prefill 可能需要十几秒开了以后能压缩一半以上。第三是 keep-alive 和并行度。在 Ollama 里每次切换模型权重都要重新加载到显存这本身就是一个巨慢的过程。如果你平时会切换模型或者同时挂了好几个不同的本地模型Roo Code 每次调用都要等权重加载完体感也是卡。设置一个较长的 keep-alive 时长让模型常驻显存或者用OLLAMA_MAX_LOADED_MODELS 1限制同时加载的模型数量减少切换。LM Studio 里对应的是在 Server 设置中调大模型保持加载的时间原理一样。3.3 内存带宽才是真瓶颈双通道、频率与插法这一点很少人提到但真实情况是即使模型全 GPU 推理内存带宽也会影响速度尤其是在纯 CPU 推理或部分 offload 的情况下。我之前一台旧机器用 CPU 推理 7B 模型单通道内存和双通道内存的速度差距接近一倍。原因是推理过程中需要不断读取模型权重和中间结果内存带宽直接决定了数据搬运速度。如果你打算用纯 CPU 或集成显卡跑本地模型请确保内存是双通道也就是插了两根内存条而不是一根。再就是内存频率尽量高一点别让低频内存拖后腿。还有一类情况显卡显存不够部分层在 GPU、部分层在 CPUGPU 和 CPU 之间通过 PCIe 总线搬运数据。这种模式下哪怕 PCIe 3.0 x16 的带宽都可能成为瓶颈。所以我说选型是第一位的你的硬件决定模型档位模型档位决定后续所有体验。4. Roo Code 扩展侧配置Provider 设置、流式开关与上下文瘦身引擎跑顺了Roo Code 这边还有几个坑。很多人配置完能连通就急着用其实扩展侧有几个设置不调速度照样上不去。4.1 Provider 配置的坑baseURL、timeout、stream 开关Roo Code 里添加本地模型走的是 OpenAI Compatible Provider。我踩过第一个坑是 Base URL 填错。Ollama 的 OpenAI 兼容端点地址是http://localhost:11434/v1不是根地址。LM Studio 默认是http://localhost:1234/v1。如果你填错了或者填成根地址要么报 404要么反复重试看起来就像卡死。第二个坑是 API Key。本地引擎不校验 key但 Roo Code 的 Provider 表单又不允许留空随便填一个ollama或者lm-studio就行别真的去配置一个本地 key 校验服务纯属给自己找事。第三个是 timeout 设置。这是最容易忽略的。Roo Code 默认的请求超时时间在部分版本里比较短Agent 场景一个请求可能持续一分钟以上一旦触发 timeout扩展会中断请求然后重试重试意味着重新 Prefill来回折腾两次体感就是卡顿。我直接把 timeout 调到 500000 毫秒也就是差不多 8 分多钟。第四个是流式开关。在配置里明确开启 stream否则很多请求要等全部生成完才返回。Roo Code 的设置项名称在不同版本有差异但我建议你在自定义配置里找stream字样确认是 true。4.2 上下文瘦身和工具循环让 Roo 不把自己卡死这是 Roo Code 特有的问题也是我花了最多时间理解的地方。Roo Code 每一轮都会把完整的历史、工具结果、文件内容重新发送给模型。这意味着任务的第 5 轮请求可能比第 1 轮大了好几倍。如果一开始就把大文件读进来了后面每轮都要重新 Prefill 一遍几万 token 的上下文速度自然飞流直下。我做了两件事来缓解第一通过.rooignore文件排除不必要的文件。和.gitignore类似把 node_modules、dist、构建产物、日志文件都排除掉避免 Roo Code 扫描和读取无关内容。本来 Roo Code 在探索阶段会自己读一堆文件里面的无关 token 全部都在拖慢请求。第二调整自定义指令要求 Roo Code 只在必要时读取文件不要做无意义的全局扫描。我在 Roo Code 的 Custom Instructions 里加了一句读取文件前先判断是否真的需要能用文件路径推断内容就不要再把整个文件读一遍。这听起来很微妙但实测对减少上下文膨胀非常有效。还有一个隐藏很深的坑Roo Code 执行终端命令后会把完整的输出塞进上下文如果某个命令输出了几百行日志下一轮请求就得全部重新 Prefill。遇到这种情况尽量让 Roo Code 执行的命令带上head -50之类的输出截断或者直接要求它只汇报结果摘要。这个习惯养成之后长任务的流畅度提升非常明显。4.3 实用配置示例一份可直接套用的 Roo Code 配置以我目前的配置为例Ollama 作为引擎Roo Code 里选 OpenAI Compatible Provider关键字段如下{ apiProvider: openai, baseUrl: http://localhost:11434/v1, apiModelId: qwen-coder-repo, apiKey: ollama, stream: true, requestTimeoutMs: 500000, temperature: 0 }有个细节模型 ID 填的是我前面用 Modelfile 自定义创建的名字qwen-coder-repo不是原始模型名。这样所有参数都在引擎侧控制好了Roo Code 这边不用重复设置。如果你用 LM Studio模型 ID 就是你下载并加载的那个模型文件名字比如qwen2.5-coder-14b-instruct-q4_k_m.gguf。这里还要提醒一句别在 Roo Code 同时挂多个本地模型 Provider。我一度挂了三四个模型想切换对比结果每次切换都要重新加载权重来回折腾的时间比写代码还长。锁定一个主力模型把参数调好比你同时备着十个模型有用得多。5. 一次完整的卡顿排查链路实录30 秒首字到 2 秒首字的全过程光讲理论不够我把我个人最惨烈也最有代表性的一次排查完整写出来。这个案例基本覆盖了所有新手会踩的坑你顺着这个思路去看自己的环境能少走很多弯路。5.1 症状描述与环境信息那天的环境是这样的台式机CPU 是 i5-12490F内存 32GB 双通道显卡是 RTX 3060 12GB系统是 Windows 10。引擎用 Ollama模型是 Qwen2.5-Coder-14B 的 Q4_K_M 版本Roo Code 是最新版本Base URL 确认无误API Key 填了ollama。症状是在 Roo Code 里新建一个任务让模型修改一个大约 300 行的 Python 文件。点击发送之后界面上的加载动画转了将近 30 秒才跳出第一个字之后每个字大约 0.4 到 0.6 秒一个完整回复生成完大约花了 40 多秒。第二三轮对话之后等待时间更长甚至出现过两次 Request timed out 报错。5.2 排查步骤一先绕过 Roo Code直接用引擎验证我的排查原则是先确认问题出在 Roo Code 这一层还是引擎这一层。方法非常简单直接用 curl 调用引擎 API模拟 Roo Code 发一个同样大小的请求。我用了一段和 Roo Code 当时差不多长度的 Prompt 去测curl http://localhost:11434/api/generate -d {\model\: \qwen-coder-repo\, \prompt\: \系统提示词和任务描述略\, \stream\: false}结果非常意外即便是几千 token 的 Prompt模型的响应速度也很快输出 500 字左右的代码大约只花了 10 秒出头。这说明引擎本身没有问题模型也在 GPU 上。问题几乎可以确定出在 Roo Code 这一层或者 Roo Code 发给引擎的请求有异常。5.3 排查步骤二抓 Roo Code 发给引擎的请求内容接下来要搞清楚 Roo Code 到底给引擎发了什么。Ollama 有日志输出我把日志打开看到了每个请求的 token 数统计。不看不知道一看吓一跳Roo Code 发出的请求Prompt 里包含的 token 数从第一轮的八千多迅速涨到了第二轮的将近两万第三轮直接超过三万。而且请求里有一段非常明显的大块内容——上一次工具调用的完整输出是一大段文件读取结果占了将近一万 token。这就是为什么第二轮开始卡得越来越明显。但这里有个奇怪的点即便三轮后有三万 token 的 PromptQwen2.5-Coder 在 3060 上 Prefill 三万 token 也不至于要 30 秒。我继续往下挖发现 Ollama 日志里模型的实际运行状态有问题模型确实加载了但上下文窗口设置远大于模型实际加载的 KV Cache 分配量导致每次 Prefill 时都要做动态扩容缓存反复重算浪费了大量时间。这一下就清楚了Roo Code 发来的 Prompt 越来越大而我对 Ollama 的num_ctx设置只在 Modelfile 里设了 8192理论上超出会被截断。但实际表现是引擎在超长 Prompt 下做了性能和显存的折中反而拖慢了。5.4 排查步骤三定位到上下文膨胀和 KV Cache 配置冲突进一步验证的方法很简单我直接用很长的 Prompt 调用引擎 API观察响应时间和显存占用然后逐渐缩短 Prompt看响应时间的变化曲线。数据显示Prompt 超过一万 token 后每增加一千 token首字延迟增加约 1.5 秒超过两万后增加得更多。这很反常。我后来判断是 KV Cache 的分配策略问题。Ollama 在某些版本下如果模型的num_ctx设置和实际显存余量不匹配会采用一种比较保守但效率较低的缓存策略导致 Prefill 速度远低于应有水平。我没有去深挖 Ollama 内部实现而是直接做了一个组合操作把 Modelfile 里的num_ctx明确设为 8192然后给 Roo Code 的 Custom Instructions 里加了一条每次处理文件时只读取关键片段避免把整个文件塞进上下文。同时用.rooignore把项目里的大文件和无关目录全部屏蔽掉。最关键的一步是把 Roo Code 侧requestTimeoutMs调大到 500000避免长请求被中途掐断重试。5.5 修复后的数据对比与仍然存在的隐患修复之后我重新测了同一任务指标修复前修复后第一轮首字延迟28-32 秒2-3 秒后续轮次首字延迟40 秒以上3-5 秒生成速度2-5 token/s25-35 token/stimeout 报错频繁极少发生整个体验直接从没法用变成了能日常用。但我也要说一句只要还用 Roo Code 这种 Agent 做长任务上下文膨胀问题就不可能完全消失。你给它的任务越复杂它需要调用的工具和读取的文件越多上下文就会越长。我只能通过持续优化指令和使用习惯来控制但没法根除。这也决定了本地模型跑 Roo Code 的体验上限——32B 及以上的大模型在上下文膨胀之后依然会力不从心这也是现实。6. 验收优化成果实测数据、量化指标与几个常被忽略的经验优化做得对不对嘴上说没用得有数据支撑。我自己是用几个硬指标来评估是否已经接近原生速度的方便清楚优化到了什么程度、还有没有继续榨取的空间。6.1 怎么客观判断优化程度token/s、首字延迟、交互体感三件套量化本地模型性能主要有三个指标我会分别测试组合起来判断第一个是生成速度单位 token/s。这个可以直接看 Ollama 或 LM Studio 的统计信息也可以用脚本计时。对于 14B 模型在 RTX 3060 上跑到 25 到 35 token/s 基本就是接近原生速度了。如果是个位数肯定有环节不对。第二个是首字延迟。这个用流式请求来测从发起请求到收到第一个 token 的时间。优化后短 Prompt 应该在 1 到 3 秒长 Prompt 在 5 到 10 秒。超过这个范围就要检查上下文是不是塞爆了或者模型是否没完全上 GPU。第三个是交互体感这是最真实的指标。我自己的标准是在 Roo Code 里发起一个修改任务转圈超过 5 秒就开始烦躁超过 10 秒就想放弃。优化到原生速度意味着大多数普通任务从发起到开始响应不超过 3 秒。达不到这个标准就继续排查。测试方法也简单写个 Python 脚本分别测短 Prompt 和长 Prompt或者直接在 Roo Code 里点几个高频任务感受一下。我一般两种都做脚本测数据真实任务测体感。6.2 几个古灵精怪但确实有效的偏方优化做到位之后我还积累了几个非主流但确实有用的经验。第一个是重启 Ollama 进程。听起来很傻但这个真的管用。Ollama 运行时间长了之后显存碎片和缓存策略会越来越差偶尔一个任务突然变慢重启一下进程立刻恢复。我在 Windows 上遇到过好几次给它加一个定时的重启计划基本上能规避。第二个是给 Ollama 设置环境变量调低并行度。Roo Code 本身是串行调用模型的同一时间只会有一个请求。但如果你电脑上还跑了其他用到 Ollama 的东西就可能产生并发请求引擎为了处理并行会拆分子批每个请求变慢。我设置了OLLAMA_NUM_PARALLEL 1强制串行处理反而整体更顺畅。第三个是关闭 LM Studio 的重型界面。LM Studio 装了模型之后启动 Server那个图形界面本身会占用不少资源。我之前有段时间总感觉速度比预期慢后来发现是 LM Studio 的界面动画和模型预览占了一些 CPU 资源。如果机器性能一般启动完 Server 后把界面最小化或者用更轻量的 llama.cpp-server 替代。6.3 我最想强调的三条经验折腾完这一整套我最想对后来者说的三句话是第一模型能不能完全塞进显存是一切速度的地基。模型大于显存的那一刻带宽和 CPU 计算就成了瓶颈不管你怎么调 Roo Code、怎么调上下文都是治标不治本。看到卡顿第一反应应该是查显存占用而不是一头扎进参数堆。第二Agent 工具的上下文管理能力比模型推理速度更影响体感。本地模型再快也架不住每次请求都重新读一遍几万 token 的历史。Roo Code 这种工具你必须在自定义指令和忽略文件上花心思压住它的上下文膨胀才能真正享受本地模型的速度优势。第三把引擎侧参数和扩展侧参数一次配置到位不要用默认值裸奔。num_ctx、num_gpu、flash_attention、temperature、timeout、stream这些参数我上面给的配置是我验证过能直接工作的组合。你可以在它基础上微调但别跳过。每跳过一步都可能埋一个你看不见的性能地雷。6.4 如果你的环境跟我的不一样从这几个方向自适应调整我的配置是基于 Windows N 卡 Ollama 的环境如果你环境不同照着思路平移就行几个对应关系如下Mac 用户尤其是 Apple Silicon情况反而更友好。统一内存架构让 CPU 和 GPU 共享内存只要内存够大大部分模型都能直接驻留 GPU。关注点是别同时开太多其他吃内存的应用给模型留足空间。如果用的是 LM Studio核心差异在于 GPU Offload 滑块和 Context Length 输入框。把这两个弄明白就行其他的配置逻辑和 Ollama 一致。还有 LM Studio 的 Auto 选项有时候会自动选择非最优的 offload 策略我建议你手动拉满 GPU 比例。如果显卡显存特别小比如 8GB 以下直接死心别碰 14B 以上的模型。老老实实用 7B 的 Q4 量化Roo Code 日常小改改也够用。强行跑大模型换来的是额外的加载时间和频繁的 offload体验只会更差。这套优化做完之后我现在在 Roo Code 里做日常重构、写单测、解释历史代码基本上跟用远程的 API 服务没有明显体感差异了。有时候甚至觉得本地模型反而更顺手因为隐私文件随便喂不用担心中间环节泄露。如果你也在折腾 Roo Code 接本地模型被卡顿折磨按我这条链路把模型选型、引擎配置、扩展设置全部捋一遍大概率也能从 30 秒等待里解脱出来。