用 Roo Code 搭本地模型干活第一周我就想砸电脑。模型明明加载正常prompt 发出去要等五六秒才看到第一个字中途还动不动断流窗口卡成幻灯片。后来我把整条链路从 Roo Code 到 Ollama 一条条盘了一遍才发现所谓的“卡顿”根本不是某一个环节的锅而是服务端参数、客户端配置、系统资源三方面互相打架。这篇文章就把我踩过的坑和最终沉淀下来的优化方案完整写出来照着操作基本能把响应速度拉回接近官方 API 的“原生速度”。先说清楚我要聊的场景你大概率是在 VS Code 里装了 Roo Code然后在 Ollama 或 LM Studio 里跑一个本地模型比如 Qwen 2.5、DeepSeek、Llama 3 之类的再通过 OpenAI 兼容接口把两者串起来。这个链路听起来很简单但实际跑起来要过的关卡比想象中多。我会把每一关都拆开讲再给你可直接抄作业的配置最后附一份我实测过的调参记录。1. 卡顿从哪里来先拆链路再谈优化1.1 一次请求要过五道关很多朋友遇到卡顿第一反应是换更大的显存或者换更好的模型但我想先泼一盆冷水本地模型推理的瓶颈大概率不在显存容量而在整条链路上最慢的那个环节。一次完整的调用大概长这样第一关Roo Code 在 VS Code 里组织好上下文包括当前文件内容、历史消息、工具调用记录然后组装成一个 OpenAI 格式的请求。这一步看似不起眼但如果你的对话历史已经很长光序列化就得花几十毫秒在低配机器上甚至能拖到几百毫秒。第二关请求通过 HTTP 从 VS Code 进程走到 Ollama 或 LM Studio。本地回环延迟极小但如果端口被占用、防火墙拦截或者其他进程在抢占资源这一关也会异常慢。第三关服务端检查当前模型是否已加载。如果模型没在内存里驻留就得先从磁盘把几个 GB 的 GGUF 文件读进来这个过程称为冷加载。机械硬盘上冷加载一个 7B 模型可能要等 10 秒以上NVMe 固态大概 2 到 4 秒。如果你每次请求之间隔的时间较长模型被服务端自动卸载了那么下一次请求就像重新启动一次服务。第四关模型推理本身。这里分两个阶段先是对你输入的 prompt 做 prefilling也就是把所有上下文编码成 KV cache然后才进入逐个 token 生成阶段。第一个 token 等得久大多是 prefilling 或者在排队后面生成速度慢则是显存带宽或算力不够。第五关生成结果以流式方式返回给 Roo Code前端逐字渲染。如果流式没开或者前端渲染线程被其他插件阻塞你会看到整块文本很久才蹦出来体感就像卡死了。所以你先记住这个结论卡顿不一定都是模型在推理可能只是模型被反复加载、请求在排队、上下文太长导致 prefilling 变慢或者前端渲染卡住了。1.2 先给卡顿分个类我踩过这么多坑之后建议你遇到卡顿先做分类因为不同现象的解法完全不同甚至可能互相矛盾。第一类TTFT 高也就是你发出指令后要等很久才看到第一个字。这种最常见原因是模型冷加载、请求排队、上下文太长导致 prefill 慢或者是 CPU 推理时线程数配少了。第二类生成速度慢比如输出只有每秒 5 到 8 个 token肉眼明显能感觉到每个字蹦出来的节奏。这种问题主要卡在显存带宽、GPU offload 比例、量化等级和上下文长度上。第三类请求超时或者直接断流。这种通常不是性能问题而是 Roo Code 里的 timeout 设置太短或者模型上下文被塞满之后报错以及并发请求把服务端打崩了。相信我我遇到过不止一次把问题定位到超时而不是慢之后解决起来非常快。第四类UI 整体卡顿连界面拖动都掉帧。这种往往是流式输出没开或者 Roo Code 在渲染超长响应时 CPU 被拉满也可能是 VS Code 扩展日志刷屏导致的。这一类经常被误判为模型性能差然后白白换了好几个模型。先花两分钟判断你的问题属于哪一类再用后面的配置去调。盲调的话南辕北辙的概率极高。2. 模型服务端调优这是最大的瓶颈2.1 Ollama 环境变量并发与驻留策略如果你用的是 Ollama那服务端本身的参数就值得先改一轮。很多人装完 Ollama 就直接用了完全没看它默认的行为但 Ollama 默认配置是为多用户访问或者多人协作设计的单机调试时反而帮倒忙。最容易被忽视的是 OLLAMA_NUM_PARALLEL默认值是 4。它的意思是 Ollama 允许同时处理 4 个请求。听起来很快对吧但在 Roo Code 这种场景下你会发起一串连续的轻量请求比如读取文件、检查上下文、调用工具这些请求如果同时进来就会被并发塞进同一个模型。模型只有一个多个请求同时进来只会让 GPU 在多个任务之间来回切换反而让每个任务都变慢甚至吞掉显存。我最终把 OLLAMA_NUM_PARALLEL 设成了 1。虽然听起来像关掉了并发但对单用户交互式对话来说请求本来就是串行的不需要并发。设成 1 之后每个请求都独占模型推理资源生成速度明显变稳。第二个要改的是 OLLAMA_KEEP_ALIVE默认是 5 分钟。也就是说模型空闲 5 分钟后就会从内存卸载。如果你在做代码任务时习惯停顿一下思考或者频繁切换文件这 5 分钟很容易耗尽等到下次跟模型对话时就会触发冷加载响应时间直接飘到好几秒。我建议改成 -1表示模型永久驻留内存直到显存不够才被换出。如果你同时只跑一个模型这个配置非常香。第三是 OLLAMA_MAX_LOADED_MODELS默认是 1这个其实不用动但如果你装了多个模型并且不小心让 Ollama 自己换模型你会发现每切换一次就有一次冷加载。建议干脆固定只用一个任务模型别的模型用不上就先删掉。在 macOS 或 Linux 上设置环境变量的方式通常是在 shell 配置里加一行 export然后重启 Ollama 服务。Windows 上可以在系统环境变量里设置或者用管理员权限在 launchctl 层面改。改完记得用 ollama ps 看当前模型驻留状态和上下文长度这是最快的验证方式。2.2 LM Studio 的加载与推理设置如果你的服务端是 LM Studio优化思路差不多但入口不同。LM Studio 的好处是图形界面你能直观看到每个模型加载时的显存占用和层数分配。核心就一个确保模型绝大部分层都被 offload 到 GPU。你可以在模型加载界面的 GPU Offload 滑杆里调整滑块的位置直接决定有多少层在显卡上计算。记住一个原则只要显存允许能拉满就拉满。如果显存装不下全部层也要保证至少把大部分计算放到 GPU因为哪怕只有十几层落在 CPU 上CPU 和 GPU 之间反复搬运中间结果速度会断崖式下跌。另一个关键设置是 Thread Count也就是 CPU 线程数。如果你开了部分 offloadCPU 也会参与推理线程数设太低会导致 CPU 侧计算慢吞吞设太高又可能跟 GPU 抢占内存带宽。一般按你 CPU 物理核心数的一半来设然后慢慢往上试找到一个平衡点。我自己的经验是物理核 8 个时开 4 线程16 个时开 8 线程别贪多。然后是 Context Length。LM Studio 默认的上下文长度往往比较大比如 32K 甚至 128K。上下文越长KV cache 占的显存越多prefill 的时间也会边长。如果你只是做代码文件级任务8K 上下文基本够用了。在服务端设置里把默认上下文压下来对速度的提升非常明显。2.3 量化等级与上下文长度的平衡聊完端侧设置还得聊一个容易被误解的话题量化。每次看到有人问为什么我的 7B 模型生成这么慢我第一反应就是想看他是不是用了 Q8 或者 FP16。量化等级直接影响模型在显存里的体积而影响生成速度的很多时候恰恰是体积。我找一个公式来给你说明白生成阶段的速度理论上限约等于内存带宽除以模型大小。比如一块 RTX 4060 Laptop 的显存带宽是 256GB/s一个 7B Q4 量化的模型大约是 4.5GB那么理论输出速度大概 256 除以 4.5约 56 token/s。但如果这个 7B 模型加载的是 Q8 量化体积变成 8GB 左右理论速度就掉到 32 token/s 左右。更关键的是Q8 往往还会让 KV cache 占用变高context 一长显存不够就得往 CPU 卸载速度直接崩。所以我的建议是本地日常任务用 Q4_K_M 就够了这是速度和质量的平衡点。我知道有些人很介意量化损失但说实话在代码辅助场景下Q4_K_M 生成的结果和 Q8 差距非常小可速度差了一倍这买卖太划算。Q8 我只会在纯 CPU 推理且内存充裕的机器上跑小模型时考虑。上下文长度方面则更优先建议根据你的任务类型来定。给一个实用参考值普通的文件级代码补全4K 足够小项目级对话8K 足够大型重构或大仓库分析才需要考虑 16K 以上。每翻一倍上下文KV cache 显存占用就翻一倍prefill 时间也会接近翻倍所以别迷信长度越长越牛。3. Roo Code 客户端配置细节决定体验3.1 卡在请求参数上的那些坑服务端调完之后界面体感未必立刻变好因为 Roo Code 侧还有很多参数决定了请求怎么发。先说最容易被忽略的 base URL 和模型名匹配问题。如果你用 Ollama通常写成 http://localhost:11434/v1用 LM Studio 则是 http://localhost:1234/v1。这两者都是 OpenAI 兼容接口Roo Code 里选择 OpenAI Compatible 或者直接选自定义 provider 就可以填。填完之后注意 model name 必须和服务端实际拉取的模型名一致比如 qwen2.5:7b-instruct 或 qwen2.5-7b-instruct-q4_k_m.gguf。我见过有人填了 qwen2.5:latest 结果服务端找不到模型每次请求失败后重试两三回体感就是卡顿。所以配置完第一件事先在服务端的接口文档页做一次直接请求验证确认能返回结果再回去用 Roo Code。另一个坑是 max output tokens。Roo Code 默认的生成上限可能很高比如 8192 或者更多。这个值不是越高越好。对本地模型来说单次生成太多 token 意味着等待时间会非常长同时为了避免一次生成过长导致超时把它控制在 2048 到 4096 之间更合适。大任务完全可以拆成多次调用而不是让模型一口气输出两千行代码后者很容易超时中断。3.2 流式输出与超时时间的黄金配合下一步确认所有能开流式的地方都开了。流式输出能做到模型每生成一个 token 就立刻发送给前端这样你的体感是从等待一堆文字一起出现变成看着文字一点点出来差异巨大。就我个人经验开了流式之后哪怕实际生成速度没变主观上的卡顿感至少降低一半。同时把超时时间设置从默认值往上调一些我通常设到 300 秒以上。这听起来有点反直觉我都嫌卡了还加大超时其实逻辑是本地模型生成速度本来就跟云端有差距如果超时设太短比如 60 秒那么长一点的生成任务就会被强制中断中断后 Roo Code 通常会重试重试又增加一轮 prefill 开销如此恶性循环你会觉得永远在转圈。加大超时后一次请求哪怕生成 2000 token 也跑得完反而不会触发重试。还要注意 system prompt 的大小。Roo Code 默认带着一整套规则和说明这些都会跟每次请求一起发给模型。如果你自己再往 Rules 里塞一大堆内容每一轮 prefill 的工作量都会变大。我建议定期清理规则文件只保留真正必要的约束同时把每条规则写得尽量精简。3.3 上下文管理与请求瘦身Roo Code 在使用过程中会不断累积对话历史和文件读取记录。对话太长之后即使上下文窗口很大prefill 阶段也会越来越慢。你观察一下是不是多轮操作后速度越来越慢新开一个任务后速度又恢复正常那几乎可以断定是上下文膨胀的锅。应对方案分两种一是开启 Roo Code 的自动压缩让它定期把旧消息压缩成摘要二是手动清理无用上下文比如删掉已经没用的文件引用或者隔段时间重开一个新的任务会话。对我而言最实用的习惯是每完成一个功能模块就重开一个会话不要在同一个会话里干一整天让上下文保持短小精悍速度自然快。如果你还接了 embedding 模型或者本地向量数据库做检索增强那就要额外注意一个点embedding 模型在 CPU 上跑会比较慢尤其是用那种七八亿参数的大 embedding 模型每次检索和重排可能要吃掉一两秒。建议把 embedding 也换到 GPU 上跑或者改用更轻量的 bge-small 这类模型。另外把检索到的 top_k 调小一些比如 3 到 5 条别一次塞回 20 条文档片段给模型否则上下文被撑大得不偿失。4. 硬件与系统级优化别忽视看不见的瓶颈4.1 内存带宽、CPU 分配与电源管理很多人以为 GPU 算力高就够用但本地大模型推理有个特性生成阶段对显存带宽要求极高对算力反而没那么敏感。这就解释了为什么同样一个 7B 模型在 RTX 4090 上跟 RTX 4060 上跑起来速度差距可能没有想象中那么大但在 MacBook Air 和 MacBook Pro 之间差距却可能达到好几倍。因为推理速度很多时候取决于显存带宽而不是 GPU 每秒能执行的浮点运算次数。所以优化时先认清你的平台特性。NVIDIA 显卡用户要关注显存带宽和是否开了 GPU offload 满载。如果你用的是 AMD 显卡Ollama 默认可能走 ROCm 或 Vulkan驱动配置不到位时速度也受影响。Apple Silicon 用户则要留意统一内存分配在模型加载时尽量让系统多分点内存给 GPU 侧同时避免同时开太多大型应用抢内存带宽。CPU 参与推理的场景也要给对资源。如果你需要在最大程度利用 CPU给 Ollama 或 LM Studio 进程设置 CPU 亲和性也算一种技巧。Linux 上用 taskset 绑定物理核心Windows 上可以用进程优先级设为实时或高于标准避免它被其他进程干扰。电源管理同样重要Windows 笔记本默认可能在节能模式下限制 CPU 频率导致 CPU 推理的速度雪上加霜把插电时的电源模式改成最佳性能效果立竿见影。共享内存带宽是另一个没说透的坑。模型放在显存里和放在内存里速度差一个数量级一旦显存装不下部分层被卸载到内存每走一层都要跨总线搬运一次数据速度会掉到原来的十分之一。所以只要模型体积低于显存容量优先保证全量 offload如果超过就换更小量化版本而不是硬着头皮开着 CPU 推理模式硬跑。4.2 冷加载速度与磁盘缓存的隐藏成本最后聊一个平时很难注意到、但在实际操作中非常影响第一次请求的环节模型加载。Ollama 或 LM Studio 启动后并不会立刻把模型读进内存而是在收到第一个请求时才加载。这个冷启动过程因硬盘而异如果你把模型放在 NVMe 固态上加载一个 7B Q4 模型大约 2 到 4 秒如果放在 SATA 固态可能要 5 到 8 秒放机械硬盘的话我见过 30 秒以上的。很多用户第一反应是模型推理好卡其实等的是磁盘。解决办法有三个一是尽量把模型文件放在最快的 SSD 上二是调整 keep_alive 参数保证模型一直驻留三是如果确实经常切换模型把常用的模型放到内存盘里但这比较折腾普通用户不推荐。检验是否冷加载也很简单看 ollama ps 或者 LM Studio 的模型信息页确认模型是已加载状态再发起请求。如果模型已常驻但请求仍然慢那问题就不在加载继续往推理阶段排查。5. 实测优化实录从卡顿到原生速度5.1 一个真实项目的调参全程理论说多了还是用一个我自己的真实记录来收尾吧。我带过一个小项目用 Roo Code 配合 Ollama 跑 Qwen2.5 7B 做代码改动和测试。主机配置是 RTX 4060 Laptop 8GB 显存、16GB 内存、Windows 11模型文件放在 NVMe 固态上。最初状态是什么样呢第一次发指令后平均要等 6 到 8 秒才见第一个字后面生成速度大概 7 到 9 token/s。更离谱的是经常做到一半Roo Code 报Context length exceeded或者超时重试整个体验完全没法用。我做的第一个改动是在系统环境变量里设置 OLLAMA_NUM_PARALLEL1、OLLAMA_KEEP_ALIVE-1然后重启 Ollama。这一步把冷加载问题解决了首次等待从 7 秒降到了 2.5 秒左右因为模型常驻内存之后不用每次重新读盘。第二个改动是把模型换成 Q4_K_M 量化版本并把上下文长度从默认的 32K 压到 8K。这一步操作完生成速度从 9 token/s 跳到 16 到 18 token/s。显存占用也从接近 7GB 降到了 5GB 左右给系统留出了余量。第三个改动在 Roo Code 侧把 max output tokens 从默认的 8192 改到 3072超时时间拉到 300 秒确认流式输出勾上。最关键的是我清理了 Rules 文件把原来一长串的英文规则精简成几条中文要点每次请求的 prefill 负担立刻小了很多。做完这一步TTFT 降到了 1 到 1.5 秒体感已经非常接近我用云端 API 时的反应速度。最后一轮我在 Windows 的电源设置里把插电模式调到最佳性能同时把 VS Code 里无关插件暂时禁用。整体跑一个中等规模的代码重构任务从读文件到给出修改建议平均单轮响应时间比之前缩短了大约 70%。这就是我说接近原生速度的真实含义不是让它跟云端的顶级推理速度比拼而是把感知延迟控制到不会打断你思路的水平。切记每个硬件平台的最优参数不一样。上面的数值只代表我的环境。但调整顺序很有参考价值先解决冷加载和并发排队再改量化与上下文最后调客户端参数。按这个顺序走每一步你都能明显看到变化也知道变量是谁。5.2 不同硬件场景下的推荐配置速查为了让你少走弯路我整理了一份配置参考表基于常见硬件组合的经验值。注意这是出发表实际还要用监控工具验证。硬件场景推荐模型量化上下文关键设置预计生成速度Apple M1/M2 16GB统一内存7B 左右Q4_K_M8K开启 Flash AttentionOLLAMA_KEEP_ALIVE-118-25 token/sApple M1/M2 32GB统一内存14B 左右Q5_K_M8KGPU全量加载关掉不必要后台程序15-20 token/sRTX 3060 12GB 32GB内存7B-14BQ4_K_M8KGPU full offloadOLLAMA_NUM_PARALLEL125-35 token/sRTX 4060 Laptop 8GB7BQ4_K_M8KGPU full offload关闭其他显存占用16-22 token/s纯 CPU 16 核心 32GB内存7BQ4_K_M4K线程设为物理核心一半使用内存映射4-8 token/s纯 CPU 老笔记本3B-4BQ4_K_M4K减小模型控制任务复杂度3-6 token/s关于 Apple 设备如果你用 Ollama 在 macOS 上跑模型记得确认是否启用了闪存注意力flash attention这个在 Ollama 里可以通过环境变量打开但不同版本的默认值不一样需要自己在日志里确认。6. 高频卡顿问题排查速查表很多问题都是反复出现的我把踩过的坑整理成一张表方便你遇到问题直接对号入座。如果对不上再用性能监控工具去查。现象可能原因解决办法每次任务前都要等很久才出第一个字模型冷加载OLLAMA_KEEP_ALIVE 设为 -1确认 ollama ps 显示模型已驻留生成速度持续偏低量化等级高或上下文太长换 Q4_K_M上下文压到 8K 以内中途报错/请求中断Roo Code 超时太短超时调至 300 秒max output tokens 降到 4096 以下UI 界面卡成幻灯片流式输出未开或日志刷屏打开流式输出关闭或减少 VS Code 无关插件CPU 满载但 GPU 空闲模型 offload 比例太低在服务端增加 GPU offload 层数或换更小模型显存溢出导致报错Context 太长或模型太大缩短上下文换低量化模型关闭其他 GPU 应用请求偶尔极其慢其他进程抢占内存带宽用任务管理器关掉大型后台工具电源改最佳性能Roo Code 频繁重试模型名不匹配或接口不通直接用 curl 测试接口返回再核对 Roo Code 配置排查时我的建议是先看 ollama ps 确认模型是否加载再跑一次 prompt 直连服务端接口计时看延迟到底是发生在服务端还是客户端。这一步能帮你砍掉一半的怀疑对象。之后再结合图表基本能在几次操作内定位到问题。最后再分享一个很实用的习惯每次调整完参数别急着开跑真正的任务先在 Roo Code 里发一条简单的指令测响应时间比如回复OK连续测三次取平均值。这样才能稳定对比指标而不至于被任务本身的复杂度误导。另外建议在同一台机器上只保留一个本地推理服务进程别让 Ollama 和 LM Studio 同时运行两个服务抢显存抢内存带宽看起来没冲突实际对速度的拖累非常明显。我自己的体会是本地模型调优没有一劳永逸的万能配置每次换硬件、换模型、换任务类型至少都要重新看一遍上面的几个关键参数。但只要养成按照服务端驻留、量化与上下文、客户端参数、系统资源这个顺序排查的习惯绝大多数卡顿都能在十分钟内解决。希望这篇踩坑实录能帮你省下我当初浪费的那些周末。