最近在捣鼓 Roo Code 接本地模型一开始的体验可以用四个字形容生不如死。明明ollama run跑模型的时候速度尚可代码补全响应也还行但只要切到 Roo Code 里让它干活每次发送指令都要在“Planning”阶段转圈半天再到“Reading File”等文件读取最后真正出代码的时候已经过去两三分钟运气不好直接弹超时。网上搜了一圈发现抱怨 Roo Code 配本地模型卡顿、甚至直接断定“本地模型带不动 Roo Code”的人不在少数。我自己从“卡成 PPT”调到“接近原生速度”中间踩了不少坑也搞清楚了很多配置项背后的真实含义。这篇就把完整的排查思路、参数调优过程和一些反直觉的结论写出来给还在折腾 Roo Code 本地模型的朋友一个可复现的优化路径。先说结论Roo Code 调用本地模型卡顿至少有一半的锅不在模型本身而在默认配置。Ollama 默认的上下文窗口、keep-alive 策略、Roo Code 的 provider 超时设置都会让一次本该 1 秒出首字的请求硬生生拖到 15 秒以上甚至超时。UI 界面卡顿是另一回事那多半是长对话上下文爆炸和渲染层的问题跟推理速度完全是两个维度的坑。1. 卡顿的假象先把“模型慢”和“界面卡”分开看1.1 转圈很久才开始流式输出不等于模型推理慢很多人在 Roo Code 里点了发送之后界面一直处于“加载中”/“thinking”状态几十秒都不见第一个字。第一反应就是“本地模型太弱了”然后开始埋怨自己的显卡不行。但实际上如果你在终端里用curl直连本地推理服务同样的模型可能首 Token 只要一两秒。差别在哪大概率卡在 Roo Code 和本地服务之间的通信参数上而不是算力。Roo Code 调用本地模型的完整链路大致是VS Code 的 Webview 界面 → 扩展进程 → HTTP 请求到本地推理服务Ollama 或 LM Studio→ 模型推理 → 流式返回 → 界面渲染。任何一个环节出现线性等待都会表现为“卡顿”。尤其是工程类任务里Roo Code 不是一个简单的一问一答工具它会根据用户指令规划步骤、读取文件、修改代码、调用 shell 命令每一阶段都会发起新的模型请求。如果每个请求都要在网络上磨蹭几秒钟整个流程就会累积成“卡成 PPT”的观感。所以第一步不是去换更大的模型或换更好的显卡而是先判断卡在“第一个 Token 开始之前”还是“流式输出过程中tokens/s 慢”。前者大部分是配置问题后者才需要认真考虑模型量化、灰度层数、上下文长度这些硬指标。1.2 UI 渲染卡顿的典型表现和判定方法另一种卡顿是“推理其实很快但界面滚动像掉帧”。典型表现是代码块一次性输出结束后整个 Webview 要卡一下才能恢复响应鼠标滚轮滑动时明显迟滞在长对话中连输入框打字都会掉字。这种情况基本与模型无关是 Roo Code 的 Webview 在渲染长 Markdown、大量语法高亮代码块、以及极长的对话历史时产生的渲染压力。我判断 UI 卡顿的方法很简单打开 VS Code 的开发者工具Help → Toggle Developer Tools看 Console 里有没有大量报错同时观察 Performance 面板。如果模型请求早就返回了但 Webview 还在不断重新布局和重绘那就属于渲染瓶颈。此时需要缩小对话上下文、清理会话历史、减少同时打开的代码预览窗口。还有一个反直觉但很有效的操作把 VS Code 的减少动画开启editor.smoothScrolling: false或直接关闭 VS Code 动画效果在某些机器上能显著减少滚轮卡顿感。1.3 快速定位瓶颈的请求链路拆解为了不靠猜建议花十分钟做一次链路测量第一步直接在终端敲curl http://localhost:11434/api/generate -d {model:qwen2.5-coder:7b,prompt:say hi,stream:false}记录从发起到拿到响应的时间。第二步在 Roo Code 里用同样模型发一条极短的指令比如“回复 OK”用计时器记录从发送到开始输出第一个字的时间。第三步如果第一步只需要 1-2 秒第二步却需要 10 秒以上问题几乎可以确定在 HTTP 请求配置、认证方式、超时设置或上下文参数上。我用这个方法实测发现在默认配置下 Roo Code 发出的请求居然会带上巨大的上下文历史而且没有显式设置num_ctx导致模型侧的 KV cache 被反复重算。这两点叠加后首 Token 时间直接翻了好几倍。2. 本地推理服务端的配置才是大头Ollama 和 LM Studio 到底该怎么调2.1 模型选型什么时候用 7B什么时候别碰 13B 和 32B优化 Roo Code 体验第一个绕不开的问题是用什么模型。我见过特别多人拿着 32B 或 70B 的量化模型硬跑CPU 和内存全部打满然后得出“本地模型废了”的结论。其实 Roo Code 这种 agentic 工具对模型的要求和纯写代码补全完全不同——它要频繁做 planner、tool calling、文件读写、多轮修正每一步都依赖足够大的上下文窗口和稳定的指令遵循能力。选模型的优先级应该是可靠性和速度 代码生成质量 参数规模。以我自己实测的经验16GB 显存左右的机器跑qwen2.5-coder:7b-instruct-q4_K_M是性价比很高的起点如果显存到 24GB可以考虑qwen2.5-coder:14b或者deepseek-coder-v2:16b的量化版本。至于 32B 以上除非你有一张 48GB 以上的大卡否则在 Roo Code 这种高频交互场景下很容易变成“思考两分钟写代码三十秒”的慢速体验完全不符合“原生速度”的目标。同样重要的是不要选纯 base 模型。Roo Code 依赖工具调用一定要用带 instruct 或 chat 后缀的版本否则 agent 经常“听不懂指令”反复跳出任务流程造成逻辑上的低效。这个低效看起来不像是模型计算慢但体感上就是 Roo Code 一直在“返工”非常磨人。2.2 Ollama 的环境变量才是隐藏的加速开关很多人以为 Ollama 只要装好、拉好模型、Roo Code 里配个地址就能跑。确实能跑但默认配置是为“一次性交互”设计的不是为 agentic 工具设计的。我踩得最深的一个坑是keep_aliveOllama 默认在模型空闲 5 分钟后会自动卸载显存。如果你不是高频连续使用每次 Roo Code 发起新请求模型都要重新从 CPU 加载权重加载 7B 量化模型到显存可能就要 10 到 20 秒。这个时间被错以为是“推理慢”其实只是“重新加载慢”。解决方式是设置环境变量# 保持模型常驻显存避免频繁卸载加载 export OLLAMA_KEEP_ALIVE-1 # 一次只加载一个模型避免显存被多个模型瓜分后反复换入换出 export OLLAMA_MAX_LOADED_MODELS1 # 如果只是给 Roo Code 单客户端使用并发建议设为 1 export OLLAMA_NUM_PARALLEL1这三个变量解释一下。OLLAMA_KEEP_ALIVE-1是让模型在服务进程结束后仍长驻显存OLLAMA_MAX_LOADED_MODELS1是避免你在 Ollama 里既拉过千问又拉过 Llama 之后系统在多个模型之间反复 swapOLLAMA_NUM_PARALLEL1是明确告诉 Ollama 单个模型一次只处理一个请求因为 Roo Code 这类工具并发请求机制并不成熟遇到并行反而出错和占满显存。还有一个容易被忽略的num_ctx。Ollama 默认的上下文长度只有 2048这意味着超出 2048 token 的对话内容会被系统做截断或重算。Roo Code 动辄把整个文件内容塞进上下文2048 根本不够用。不调整的话会出现两种现象一是模型“失忆”聊到后面完全忘记前面的指令二是性能骤降因为每次请求的 prompt 内容大而 context 反复重建。正确做法是创建一个带参数的 ModelfileFROM qwen2.5-coder:7b PARAMETER num_ctx 8192 PARAMETER temperature 0.2 PARAMETER top_p 0.9然后创建并运行ollama create roo-qwen -f Modelfile ollama run roo-qwennum_ctx 8192是比较稳妥的起步值。如果你显存足够且任务经常涉及大文件分析可以再往上调但注意显存占用和推理延迟是显著增长的。7B 模型在 4bit 量化下8192 上下文大约额外占用几 GB 显存如果你卡在 8GB 显存的边缘可能得折中到 4096。2.3 LM Studio 的 Server 设置别让默认配置拖后腿如果你用的是 LM Studio 而不是 Ollama核心调整点在 Local Server 面板里。重点关注几个选项GPU Offload尽量把层数拉到你能拉到的最大值让推理主要在显卡上完成。如果 offload 层数太少部分层在 CPU 上跑速度会断崖式下跌。我实测发现同样是 7B 模型GPU 全量加载和 GPU/CPU 各一半的tokens/s 差距能到 3 倍以上。Context Length同样别用默认值至少拉到 4096能到 8192 更好。JIT / 内存优化类选项如果版本里有类似“Flash Attention”的开关建议打开对长上下文有可见收益。启动参数里还可以加--no-webui之类的方式省略不必要的界面进程减轻系统资源争抢。不过这不是必须项如果你的内存压力不大界面留着也无妨。LM Studio 使用的也是 OpenAI 兼容的/v1接口Roo Code 里配置 base URL 为http://localhost:1234/v1即可。和 Ollama 的区别主要在于 LM Studio 将模型保持加载的策略相对保守如果你希望模型常驻记得在 Server 面板里把模型卸载策略设为“Keep loaded”或类似选项否则同样会出现首 Token 慢的问题。3. Roo Code 端的配置那些一眼带过的设置项其实都是坑3.1 Provider 配置Base URL、模型 ID 和超时时间的相互作用Roo Code 的 Provider 配置界面里第一眼看到的是 Base URL 和 API Key很多人填完就跑从来没点开过更底层的折叠项。这里面的“超时时间”就是个大坑。默认超时经常只有几十秒而 agent 任务中一个请求可能包含很长的上下文和复杂的规划过程尤其是模型质量一般时思考时间很容易超过超时阈值。一旦超时Roo Code 会判定请求失败然后走重试分支或直接报错用户体感就是“无故卡住”“转半天没反应”。建议把超时时间至少调到 180 秒或更高同时检查是否有“Streaming”开关。流式输出开着的情况下服务端每生成一个 token 就会推送到客户端界面能持续感觉到“在动”即便模型整体速度一般心理上的卡顿感也会小很多。如果关闭流式客户端必须等到完整生成结束才渲染长任务基本就是干等几百 token 也能让人以为死机了。3.2 上下文窗口与 num_ctx默认 2048 是万恶之源前面提到 Ollama 默认num_ctx2048但这个坑还有另一半即使你在 Ollama 服务端设置了较大的num_ctxRoo Code 依然可能在自己的配置里把请求的上下文“改小”。我在排查时用日志发现Roo Code 发出的请求中 model 参数会被透传但 options 不一定包含num_ctx这时候服务端就会回退到默认值。解决办法有两个一个是在模型侧通过 Modelfile 固话num_ctx另一个是在 Roo Code 的 API 配置里找到 “Request Options” 一类的字段显式传{ num_ctx: 8192, temperature: 0.2 }注意别把 Roo Code 界面里的某种“上下文长度”滑块理解成最终值它可能只影响客户端发送 prompt 时截断策略真正决定 KV cache 大小的是服务端收到的num_ctx。两边都设置好后才有一个稳定的基础。顺带说一个很隐蔽的体验问题当对话历史非常长时每次请求发送的 prompt 体积也会飞速膨胀。Roo Code 本地模型使用 OpenAI 兼容接口时并没有自动压缩历史消息的机制积累几百条消息之后一次请求的 prompt 可能几千甚至上万 token。即便num_ctx够大这些历史纯粹是“上下文填充”而不是“有效推理”会显著拉长 prefill 时间表现就是越来越慢。定期开新会话、清理历史是日常使用的必要习惯后面我会展开说。3.3 并发请求和重试策略别让 Roo Code 自己打死自己Roo Code 在完成一个任务时可能同时发起多个子请求比如读多个文件、生成多段代码。对于本地模型并发请求不一定是好事Ollama 默认的并发处理机制在OLLAMA_NUM_PARALLEL不调整时会尝试同时处理多个序列显存和计算资源一争抢反倒每个请求都变慢。在 Roo Code 侧尽量在设置里找到类似“禁用并发”或“串行处理”的选项并打开。另一个相关项是重试策略。Roo Code 对失败的请求有自动重试机制但本地模型的失败模式往往不是“网络错误”而是“超时”或“内容不完整”。如果重试时又把整个历史重新发送一遍等于雪上加霜。我在实际使用中把应用级重试次数调低转而提高超时上限让一次请求走完明显减少了“卡住后连续重试”的死循环体验。3.4 别让 Roo Code 一次干太多活任务拆解与 Auto 模式的正确姿势这是最容易被忽略的配置层问题Roo Code 作为 agent会按 Plan/Act 两级去拆解任务。你给它一个“把整个项目重构一遍”的指令它会在 planning 阶段调用大量工具每个工具调用都可能是新的推理请求。当这些请求全部堆积在本地模型上时排队和显存争抢就让整个流程看起来极端卡顿。更合理的做法是把任务拆小。比如从“帮我改这个接口”变成“先读取文件分析问题再给出修改方案我确认后你再执行”。Roo Code 本身有这个交互模式允许用户在关键节点确认。虽然少了一键自动的爽感但对于本地模型任务粒度越小单个请求的 prompt 越短prefill 越快整体效率反而更高。我还发现把 Roo Code 的 auto-approve自动批准功能全部打开未必是好事尤其是使用本地模型时错误的 tool call 会被自动执行随后在修正阶段产生大量额外的模型请求。合理的做法是敏感的、高成本的 tool比如文件编辑、shell 命令保留手动确认只对搜索、读取这类低风险操作开启自动。4. 一次完整的性能排查实战从“卡成 PPT”到接近原生速度4.1 用日志、curl 和资源监视器确定瓶颈排查的第一步不是盲目改参数而是明确瓶颈。我自己整理了一个排查表格建议你也照着走一遍症状优先检查项判断方法点击发送后长时间无响应Base URL 是否可达、超时时间、keep_alivecurl 直连本地 API测响应时间首 Token 很慢但后续 tokens/s 尚可num_ctx 偏小、上下文 history 过长比较长短 prompt 的首 token 时间输出过程跌宕起伏、忽快忽慢显存是否打满、CPU 是否在持续高负载任务管理器/资源监视器观察 GPU 利用率曲线整个 UI 滚动、打字都卡Webview 渲染压力大开发者工具看 DOM 节点数和性能面板中途报错或超时provider 超时时间、重试策略查看 Roo Code 输出面板错误码我遇到的最典型场景是curl http://localhost:11434/api/generate测出来的首 token 约 0.8 秒生成速度 45 tokens/s在终端里非常顺。但 Roo Code 里发同样的指令首 token 要 12 秒而且一旦打开长文件后整个请求基本瘫痪。这就很明确了推理服务本身没问题问题出在 Roo Code 发送的 prompt 尺寸、上下文设置和超时机制。4.2 分步优化过程实录从 15 秒首token 到接近 1 秒按时间顺序记录我当时做的几步优化先改 Ollama 环境变量和 Modelfile。设置OLLAMA_KEEP_ALIVE-1、OLLAMA_MAX_LOADED_MODELS1、OLLAMA_NUM_PARALLEL1重启 Ollama 服务。再用 Modelfile 创建roo-qwen固定num_ctx 8192。这一步之后Roo Code 里第一个请求的首 token 从 12 秒降到了 3 秒左右。调大 Roo Code 里的超时时间从默认改到 300 秒同时确认流式输出开着的。这一步解决的是长任务做到一半因为超时而中断、然后反复重试的问题。给 Roo Code 的请求 options 显式传num_ctx避免服务端回退到默认值。完成后首 token 进一步降到 2 秒内。清理 TAS 会话历史。把之前的“千年老对话”清空新建会话再测试首 token 进入 1 秒以内整体流式输出稳定在 35-45 tokens/s已经和终端 curl 的体验非常接近。你不能跳过前面任意一步只做最后一步因为“清理历史”只是优化了 prompt 长度如果前面num_ctx、keep_alive 这些基础打不好依然是治标不治本。4.3 一个容易被忽略的“隐性拖慢”安全软件拦截 localhost你可能想不到我优化到最后发现还有一个“隐形杀手”杀毒软件和系统防火墙会对 localhost 的某些请求做实时扫描。VS Code 扩展进程发起 HTTP 请求到本地端口时这些安全组件一样会逐包过滤数据量一大延迟就会显著增加。我是在关掉某安全软件的“网络防护增强”功能和内核级流量扫描后发现整体流畅度又上了一个台阶。如果你把所有配置都调好了但总觉得“差一口气”可以临时关闭安全软件对开发工具的防护再对比一次。我提醒一句这个操作有风险适合自己的实际使用环境和安全策略别为了速度牺牲安全找到平衡点才是理性的做法。5. 把优化成果固化下来配置管理、启动脚本和隐性技巧5.1 写一个启动脚本让环境变量持久化环境变量在终端里 export 只能管当前会话重启电脑就没了。推荐在 Ollama 的服务配置或系统环境变量里固化。Linux 下常见的做法是编辑systemdservice 文件或/etc/environmentWindows 下直接在“高级系统设置 → 环境变量”里添加即可macOS 如果是通过 Homebrew 启动 Ollama也要把环境变量写进launchctl的 plist 里。# Linux systemd 示例 sudo systemctl edit ollama.service # 加入如下内容后重启服务 [Service] EnvironmentOLLAMA_KEEP_ALIVE-1 EnvironmentOLLAMA_MAX_LOADED_MODELS1 EnvironmentOLLAMA_NUM_PARALLEL1这样固化之后即使你不开终端服务也能以优化后的参数常驻Roo Code 随时调用都是“预热”状态。5.2 把自己的最佳配置写成一个可复用的 Modelfile / YAML每次重新拉模型后重新调参很麻烦我后来把自己用的模型参数都存成了一组配置文件放在项目目录或者固定的工具配置目录下。Ollama 用 ModelfileLM Studio 可以用它自己的 YAML 或 JSON 配置。这样无论是换机器还是重置环境一条命令就能重建出同样手感的本地模型。以 Ollama 为例我的roo-qwenModelfile 内容如下FROM qwen2.5-coder:7b-instruct-q4_K_M PARAMETER num_ctx 8192 PARAMETER temperature 0.2 PARAMETER top_p 0.9 PARAMETER repeat_penalty 1.1repeat_penalty放在这里是为了减少 agent 重复输出或陷入循环对话。本地模型没有全局指令微调那么强偶尔会有复读机行为这个参数能压一压。你不用完全照抄关键在于把“适合你自己任务”的参数固化下来而不是每次手敲。5.3 什么时候该理性放弃本地模型切回云端 API虽然这篇文章一直在讲如何优化到“原生速度”但我必须说句实话本地模型的优化天花板是存在的。如果你用 70B 级别模型、跑超大代码库、要求极低的延迟和极高的一致性本地模型很难和云端 API 抗衡。Roo Code 的优势在于它是一个自由的工具链它同时支持外部模型。我的建议是形成一个“分级策略”日常小任务、私人代码、不需要反复读大量文件的轻量开发用本地模型跑响应快、零成本、隐私好重活、大文件分析、重构类任务配一个云端 API 的 provider 作为备胎。Roo Code 里可以配置多个 provider 并随时切换这不是什么妥协而是聪明地利用资源。在切换的时候记住一件事不同 provider 的模型擅长点不一样不要因为“本地模型干不了某个任务”就全盘否定同样也不要因为“云端 API 快”就一直让本地模型吃灰。每种资源都有自己的适用场景用对了才是真正的“原生速度”。6. 关于“原生速度”的一些补充思考和实验心得6.1 流式输出、长对话管理和 UI 渲染三者的最终平衡把这几个因素放在一起看其实是一个资源分配的平衡问题显存被模型占用CPU 预留给了 prefill 计算GPU 的编码器在渲染 Webview而内存的大小决定了对话历史能撑到多长。如果你的内存和显存都紧巴巴就要有一个取舍思路。我个人的倾向是宁可降低一点num_ctx也不要把显存全部占满。因为一旦显存接近上限Ollama 会开始使用 CPU fallback速度断崖式下降那才是真正的“一脚踩进沼泽”。初次使用时可以先用ollama ps看当前显存占用用资源监视器确认还有多少余量再决定上下文窗口的大小。不要盲目学网上拉满 16384 或 32768除非你能明确负担这个代价。6.2 Roo Code 日志和 Ollama 日志配合定位问题的方法在实际定位问题中最有效的不是反复试配置而是看日志。Ollama 的日志默认输出在终端或者日志文件里启动时如果你看到了“OLLAMA_NUM_PARALLEL set to 1”这样的打印说明环境变量生效了。Roo Code 的输出面板里也可以检查每次请求实际发送给模型的 prompt 长度、HTTP 状态码和耗时。两边日志的时间戳对齐后就能一眼看出延迟是发生在请求排队、prompt 传输还是 token 生成阶段。这里有一个小操作在 Roo Code 中每次请求时日志里会显示模型的名称以及它收到的基础 URL。如果模型名称和你预期的不一致就说明配置里模型 ID 写错或者没有生效。这是一个很多人忽略的细节但它能解释不少“明明改过配置却不生效”的疑惑。6.3 四个我没写进前文但很实用的“土办法”最后分享四个零散但实用的技巧不要同时开很多 VS Code 窗口。每个窗口的 Roo Code 扩展都会发心跳请求和同步状态多个窗口叠加后本地模型的请求会被无意义地分散。把 VS Code 的自动保存、自动补全、代码透镜等对资源敏感的功能关掉。它们不直接拖慢 Roo Code但会占用编辑器主进程的 CPU 和 IO间接降低整体响应。给本地模型的 QPS 加一个温和的限制。如果你的使用模式是疯狂的批量提交Ollama 会排队但队列太长时模型根本处理不过来这时与其一直等不如在 Roo Code 侧把任务拆小一些。这条和上面的“任务拆解”是一体两面。留意模型文件所在的磁盘类型。第一次把模型从磁盘加载进显存时磁盘读取速度非常关键。NVMe 固态和机械硬盘的加载时间差距可能在一倍以上。如果你的模型文件在机械硬盘上换个 NVMe 位置往往立竿见影。6.4 最后的一个小提点别被“原生速度”误导成“绝对速度”很多人追求“原生速度”以为目标是无脑快。但 agentic 工具真正要的其实是“稳定的、可预测的响应节奏”。有时候模型快速吐出整段代码但 Roo Code 需要重新读文件、校验结果整体时间依旧不短。我更愿意把目标定位在“每个请求的响应都可预期不会突然卡死不会超时重试”而不是盲目追求极限 tokens/s。当你的请求不会因为上下文溢出和配置错误而反复重试时实际体验的提升比单次推理速度的提升要真实得多。我在调整完这些配置后Roo Code 配合本地 7B 模型的流畅度已经足以应付日常开发任务。如果你也在折腾 Roo Code 和本地模型的组合建议不要急着换更大的模型先把服务端环境变量、num_ctx、超时和会话历史这几个基本面打磨好。绝大多数“卡顿”不是算力不够而是配置不对路。等到这些全部调顺之后如果仍然觉得有瓶颈再考虑换模型或者混合调用云端 API也不迟。