用 Roo Code 跑本地模型，我前前后后折腾了小半个月。最早是被“代码不出机器”这点吸引，想着反正在 VS Code 里写点小功能、重构一下老项目，没必要每次都把代码丢到远程 API，于是装了 Roo Code，接了 LM Studio 里的 qwen2.5 7B 量化模型。结果刚上手就被教做人了：指令发出去，UI 先卡住两三秒，模型开始吐字以后又一顿一顿的，编辑器里滚动都掉帧。这哪是写代码，简直是给 IDE 上刑。
这篇文章就专门聊这件事——Roo Code 调用本地模型的卡顿到底卡在哪、怎么一步步优化到接近原生速度。我会把问题拆成“模型推理、API 通信、插件 UI”三层，每一层给出可复现的配置参数和操作流程。适合正在用 Roo Code 接 LM Studio、Ollama 这类 OpenAI 兼容服务的开发者，也适合准备入坑本地编程助手、但被性能吓退的新手。先说结论：本地 AI 编程助手的“原生速度”不是靠单一参数拉满得来的，而是把各个环节的隐性瓶颈逐个拆掉。
1. 优化之前，先把“卡”这件事定位清楚
1.1 三种卡顿，三种病因
很多人一卡就给 Roo Code 换配置、换模型，折腾半天没效果，因为压根没分清卡顿是哪个环节产生的。我根据体感把卡顿分成了三类：
第一种是 UI 卡。鼠标转圈、字符输入有延迟、代码高亮半天才反应过来、滚动页面像在翻幻灯片。这种问题多半出在 VS Code 本身的渲染，或者 Roo Code 扩展进程与模型进程抢资源。
第二种是推理卡。体现在模型已经接收请求，但生成 token 的速度特别慢，或者首 token 等很久。这种要查模型选型、量化等级、GPU offload 配置和上下文长度。
第三种是通信卡。表现为请求发出去之后长时间没有任何响应，要么一直转圈，要么最后直接报 timeout。这种要查 Roo Code 到本地模型的 HTTP 链路，包括地址解析、流式响应、超时参数和并发问题。
打个比方：UI 卡是店面服务员打瞌睡，推理卡是后厨出菜慢，通信卡是传菜跑堂的在半路丢了单。三种问题虽然都表现为“卡”，但处理方式完全不同。所以优化的第一步不是调参，而是先判断到底卡在哪一环。
1.2 三分钟定位瓶颈的具体操作
我自己常用的定位手段有三个，按顺序做一遍基本就能锁定范围。
第一个是看 VS Code 自带性能面板。在 VS Code 里按 Ctrl+Shift+P，输入“Developer: Open Performance”，回车，会弹出界面事件耗时列表，每次操作对应的 UI 延迟多少毫秒一目了然。再输入“Developer: Toggle Developer Tools”，切到 Network 面板，能看到 Roo Code 发出请求的排队时间和等待时间。如果 UI 事件耗时很高，那就是 VS Code 渲染层的问题；如果 Network 里的请求状态一直挂起，那就是跟模型服务之间的通信问题。
第二个是直接测本地模型服务的裸响应速度。打开终端，手动发一个请求到 LM Studio 的 API：
time curl http://127.0.0.1:1234/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5-7b-instruct-q4_k_m", "messages": [{"role": "user", "content": "say hi"}], "stream": true, "max_tokens": 50 }'重点看两个数字：curl 总耗时，以及从发出请求到输出第一个 token 的时间。如果 curl 本身就慢，说明瓶颈在模型推理；如果 curl 秒回，但 Roo Code 里还是卡，问题就在插件层。
第三个是看任务管理器。Windows 上打开任务管理器，切到性能页，盯着 GPU 利用率、显存占用和 CPU 占用。LM Studio 加载模型并生成文本时，GPU 利用率应该稳定在一个较高水平；如果你发现 GPU 几乎没动静而 CPU 爆满，说明模型没有正常走 GPU 推理。如果 GPU 占用很高而 Roo Code 的 UI 也在同一张显卡上渲染，两者就会互相抢资源。
1.3 先把基线数据记下来
定位之前，建议先把优化前的数据记录下来，后面才能量化优化效果。可以记一张表：
| 指标 | 优化前实测值 | 说明 |
|---|---|---|
| 首 token 延迟 | 3.2 秒 | 从发指令到模型开始输出 |
| 生成速度 | 21 tokens/s | 持续输出时的平均速度 |
| UI 操作延迟 | 800 ms | 在 Roo Code 里点击界面到响应 |
| 单次任务总耗时 | 4 分 30 秒 | 一次简单重构任务的完整时间 |
有了这个基线，后面的每一步优化是否有效就非常清楚。我在第二轮的实测里，首 token 延迟从 3.2 秒降到 0.8 秒，UI 操作延迟从 800 毫秒降到 150 毫秒，都是靠对比基线判断出来的。
2. 模型层优化：把推理速度的底子打好
2.1 模型选型：不是越大越好
本地模型的选择直接决定速度上限。Roo Code 调用本地模型做编码任务，最常用的模型规模大致分三档：7B/8B 级别、14B 级别、32B 级别。以 Qwen2.5 系列为例，7B 量化后大概需要 6GB 显存，14B 需要约 10GB，32B 需要 20GB 以上。
很多人的误区是“模型越大越聪明，所以我要上最大的”，但在本地编程助手的场景里，模型效果和速度的平衡远比“绝对聪明”重要。
先说结论：跑编码 agent 任务，入门选 7B/8B Q4 量化，显存有富余再上 14B。32B 虽然理解能力更强，但生成速度通常会掉一半以上，而且长上下文时 KV Cache 的显存占用会让 24GB 的显卡也捉襟见肘。对于日常代码补全、文件重构、bug 修复这类任务，7B 模型配上好的提示词编排，效果完全够用。
2.2 量化级别和上下文长度怎么选
量化级别直接关系到显存占用和推理速度。我推荐 Q4_K_M，这是速度和质量的折中选择。Q8_0 会更准一些，但显存占用提升约 30%，而且生成速度会下降 10% 到 20%。在 LM Studio 里下载模型时，尽量选 GGUF 格式的 Q4_K_M 版本。
上下文长度是最容易被忽略的杀手。Roo Code 这类 agent 工具会在对话中持续累积信息，包括指令、文件内容、工具返回结果和历史消息。你如果给 LM Studio 设置了 32K 或更大上下文，KV Cache 会吃掉大量显存，而且每轮请求的 prefill 阶段计算量也会暴增。
prefill 可以理解为模型“读题”的过程。读的题越长，出第一个字就越慢。很多人反馈“本地模型半天不说话，然后突然刷出一大段”，就是这个原因。我一开始也把上下文拉到 16K，结果首 token 延迟 5 秒起步。后来老老实实改回 8K，首 token 降到 1 秒以内。
在 LM Studio 里，加载模型时需要手动设置 Context Length。编码任务用 8K 完全够，除非你明确要让它分析超长文件，再临时调大。
2.3 LM Studio 推理参数调优记录
LM Studio 是最常用的本地推理工具之一，它把 llama.cpp 的底层能力包成了一个带图形界面的服务，并能提供 OpenAI 兼容 API。我在 Roo Code 里就是通过这个 API 跟模型通信的。
先说 GPU offload。LM Studio 加载模型时在右侧“GPU Offload”滑块里设置要卸载给 GPU 的层数。原则是：尽可能多地把层放给 GPU，但不要 100% 吃满显存。因为除了模型权重，KV Cache 和计算缓冲区也需要显存，全部塞满会导致内存交换，反而拖慢速度。我自己用 16GB 显存跑 7B 模型，GPU Offload 拉到 99%，留出约 0.5GB 余量，实测很稳。
Flash Attention 选项建议开启。这个功能能显著降低长上下文的显存占用，并轻微加速推理。在 LM Studio 的模型加载选项里勾上就行。
线程数要按 CPU 的物理核心数设置，不要无脑拉满。线程过多会导致 CPU 资源争抢，反而让速度下降。
“Keep model loaded”这个选项务必开启，否则每次 Roo Code 发一个请求，LM Studio 都要先把模型加载到内存再推理，第一次请求可能要等十几秒。开启了之后，模型常驻显存，后续请求才能达到正常速度。
2.4 上下文膨胀：最隐蔽的元凶
Roo Code 这类 agent 的工作方式跟普通的聊天不同。它每执行一步，都会把新的观察结果、文件内容、工具输出追加到对话历史里。这些内容不断地累积，上下文就越撑越大。
原本 2K 上下文就够一个简单请求，跑了几个回合之后，上下文可能已经悄悄膨胀到 10K 甚至更多。模型每处理一个新请求，都要把整个历史重新“读一遍”，这个成本随 token 数量线性增长，所以你会发现同一个 Task 执行越往后越慢。
我的办法是把任务拆小。大需求先让 Roo Code 用 Plan 模式读完项目结构，给出执行方案，然后我在确认方案之后，开一个新的 Task 让它执行具体步骤。这样每个 Task 的上下文都很干净，不会越跑越重。
3. 通信层优化：API 链路里的隐形瓶颈
3.1 Roo Code 到本地模型的完整链路
Roo Code 是 VS Code 里的扩展，它的逻辑跑在扩展宿主进程里，一个 Node.js 环境。你发出一条指令，Roo Code 会构造一个 HTTP 请求，发送给 LM Studio 的本地服务，模型推理完成后把结果流式返回。
这条链路其实有四个环节：Roo Code 代码逻辑 → Node.js 网络请求 → LM Studio HTTP 服务 → 模型推理。任何一环有阻塞，都会表现为卡顿。所以模型层调优之后，下一步要看通信层。
3.2 流式输出：必须开启，没有商量
我第一次配置时走了弯路，以为 OpenAI 兼容 API 默认就会流式返回，后来才发现 Roo Code 的请求体里需要显式带上 stream 参数。不开流式输出的话，LM Studio 会等整段回复全部生成完再一次性返回，体验就是长时间空白，然后突然爆出一大段代码。开了流式输出之后，模型每生成一个 token 就立刻推送过来，界面上的内容是逐字滚动出现的，体感会好非常多。
如果你用的是 Roo Code 自带的 OpenAI Compatible 端点配置，一般默认就带 stream。但如果自己写脚本、或者用某些第三方转发层，一定要检查请求体里有没有"stream": true。关闭流式输出时，不仅卡顿明显，遇到长回复还特别容易触发超时。
3.3 地址、超时和重试的细节
API 地址我强烈建议写http://127.0.0.1:1234/v1，不要写http://localhost:1234/v1。在部分系统上，localhost 可能被解析为 IPv6 的::1，而 LM Studio 默认只监听 IPv4，这会导致请求延迟甚至失败。虽然多数时候可以自动回退，但没必要赌这个。
超时参数也很关键。在 Roo Code 里的“API 配置”或设置项里，请求超时默认值可能只有 60 秒或 120 秒。本地模型在上下文很长、任务很复杂时，单次请求超过 60 秒很常见。我建议把超时设到 300 秒，给模型留足思考空间。注意，设了超时不是让你真的等五分钟；如果经常超过 60 秒才返回，说明上下文快爆了或显存不够，要去查前面的配置。
重试机制方面，LM Studio 本身服务很稳定，一般不需要额外设置太多重试。但如果你的任务经常中途断掉，检查一下是不是 VS Code 扩展进程的自动休眠策略在捣乱。
3.4 并发和资源抢占问题
本地模型服务在处理请求时是串行的，也就是说 LM Studio 一次只处理一个推理请求。如果你同时让 Roo Code 开多个 Task，或者浏览器、视频播放器、其他 AI 工具也在占用显存，模型就必须排队，速度直接减半。
我当时就踩过这个坑。一边开着 Roo Code 写代码，一边开着浏览器看视频教程，结果模型的生成速度从 25 tokens/s 掉到 12 tokens/s。把浏览器里的视频关掉之后速度立刻回来一半。后来又发现 Windows 的系统桌面窗口管理器（DWM）也在用 GPU 渲染，这个没法关，但可以通过开启 VS Code 的硬件加速来优化整体资源调度。
4. VS Code 和 Roo Code 插件层的治理
4.1 给 VS Code 减负：关掉不必要的扩展
VS Code 本身的扩展越多，扩展宿主进程占用的资源就越多。而 Roo Code 的运行依赖扩展宿主进程，它一旦被其他扩展阻塞，UI 卡顿自然就来了。
我的做法是给本地模型开发单独建一个 Profile，只保留必要的扩展：Roo Code、语言基础插件、Git 相关插件。其他像 C#、Java、Python 的重型语言扩展，如果当前项目用不到，就全部禁用。实测最明显的提升来自禁用那些后台扫描类扩展，它们会在你打开项目时不断索引文件，白白吃掉大量 CPU。
另外可以在 VS Code 设置里调整一些细节。“files.watcherExclude” 把 node_modules、.git、dist 等目录加入排除列表，文件监视的数量就会大幅减少。"search.followSymlinks": false也能降低搜索时的开销。“workbench.editor.limit” 限制同时打开的编辑器数量，避免标签页爆炸。
4.2 把 GPU 渲染调顺畅
VS Code 默认的渲染策略有时候不够激进。在我的机器上，手动开启 GPU 加速后，UI 的滚动流畅度明显提升。在 settings.json 里加：
{ "terminal.integrated.gpuAcceleration": "on", "window.titleBarStyle": "custom", "editor.renderWhitespace": "none" }第一行让终端走 GPU 加速；第二行用自定义标题栏，这能减少窗口系统的一些额外开销；第三行是为了降低编辑器渲染工作量。这三个选项不直接影响 Roo Code 的推理，但对整体 UI 手感改善明显。
4.3 Roo Code 的使用习惯比配置更影响速度
性能问题有时候不是配置不好，是用法太浪费。Roo Code 提供了 Plan、Act、Architect 等模式，很多人不管什么任务都直接开 Act 对话，结果上下文越滚越大。
我的习惯是：新任务一律从新 Task 开始。老任务结束后，打开 Roo Code 侧的会话历史，清理掉那些完成度不高的旧对话。说得直白点，这就像给模型换了一个干净桌子，不要让上一道菜的残渣影响下一道菜。
还有一个关键习惯是不要让 Roo Code 随便读大文件。它经常拿着文件路径就整文件读进来，一读就是几千行。如果只改一个函数，那大部分代码都是干扰项。我会在任务描述里明确说“先 grep 找到相关函数再读”，这样可以控制送入模型的 token 量，速度自然就上去了。
4.4 用规则文件约束模型行为
Roo Code 支持自定义规则，在项目里的.roo/rules或者全局规则里写清楚项目的代码风格、目录结构、输出要求。这些规则会让模型更少做试探性操作。
比如我在规则里写了两步操作原则：先分析再改、改完必须跑测试、脚本输出保持简洁。这样模型就不会每轮都生成一大段无关分析，请求长度和生成长度同时缩短，任务总耗时下降非常明显。
优化到这个阶段，一次简单的函数重构任务，从发出指令到提交改动，总耗时能从 4 分半降到 1 分半左右。
5. 常见问题与排查技巧实录
5.1 高频问题速查表
| 症状 | 可能原因 | 解决方向 |
|---|---|---|
| UI 卡顿，点击无反应 | VS Code 扩展过多，扩展宿主被占满 | 新建专用 Profile，禁用大插件，开启 GPU 加速 |
| 长时间无响应后突然输出大段文字 | 未开启流式输出 | 确认请求体带 stream: true |
| 首 token 延迟越来越长 | 上下文膨胀，KV Cache 占用持续增加 | 拆 Task，限制 context length，避免读整文件 |
| 输出速度突然减半 | 显存被其他应用抢占 | 关闭浏览器视频、其他模型应用，检查 LM Studio 显存占用 |
| 请求总是超时 | 模型负载过高，或超时阈值太短 | 超时调到 300 秒，检查上下文长度，降低并发任务数 |
| 用 localhost 时偶发连接失败 | IPv4/IPv6 解析问题 | 统一改 127.0.0.1 |
| 第一次请求特别慢 | 模型未常驻内存 | 开启 Keep model loaded，预热一次 |
5.2 我的标准排查顺序
优化踩坑多了之后，我总结了一套固定流程，每次卡顿都按这个顺序来：
先跑一遍 curl 测裸 API 速度，把通信层和推理层单独隔离出来。如果 curl 本身都慢，再去看 LM Studio 的 GPU offload、上下文长度和模型量化。如果 curl 正常但 Roo Code 里还是卡，再去看 VS Code 的扩展进程和渲染设置。最后才考虑是不是模型选型问题，不要一上来就换大模型。
这套顺序帮我避开了一个很大的坑：有一次我以为是模型太笨，连续换了三个模型，最后发现是 VS Code 里装的一个 C# 扩展在后台做持续索引，把 CPU 吃满了，跟模型一点关系都没有。
5.3 压箱底的小技巧：录屏回放对比
最后分享一个我很常用的笨办法。优化前后各录一段屏幕视频，录的时候不要看界面，只做同一个操作，比如让 Roo Code 重构某个函数。然后回放录像，用秒表数出从“回车确认”到“界面开始输出代码”的耗时，再数出“输出全部完成”的耗时。这个办法虽然土，但能排除掉很多主观体感的干扰。实际对比出来的数据，往往比你凭感觉判断的准确得多。
我最后一次优化前，录像是首 token 2.8 秒，总量 21 tokens/s；优化后是首 token 0.9 秒，总量 32 tokens/s。如果没有录像回放，我可能只会觉得“好像快了一点”，而不是清楚地知道每一步改了什么产生了多少收益。
说到最后，我现在跑 Roo Code 的固定组合是：qwen2.5 7B Q4_K_M、8K 上下文、GPU offload 99%、开启 Flash Attention、流式输出、超时 300 秒，配合一个几乎空白的 VS Code Profile。在这个配置下单次简单任务的首 token 延迟能压到 1 秒以内，生成速度稳定在 30 tokens/s 上下，日常写代码已经完全能接受，也确实把本地模型跑出了接近原生速度的手感。遇到卡顿别急着降需求，按文章里的顺序从上到下过一遍，绝大多数问题都能解决。
