本地模型跑在 Roo Code 里最让人抓狂的不是它答得不好而是明明显卡没吃满、显存也没爆敲下回车之后光标就在那儿转圈等个十几秒才吐字。我前后在三台机器上折腾过这套组合——一台 3060 12G 的台式、一台 4060 8G 的笔记本、还有一台纯 CPU 的办公机——踩过的坑基本能凑齐一本错题集。这篇就把我从卡到想砸键盘到基本追平原生推理速度的完整过程拆开讲包括怎么判断卡在哪一环、参数怎么调、上下文怎么管、以及那些文档里不会写的细节。不管你是刚在 VS Code 里装上 Roo Code 的新手还是已经配好本地模型但被延迟劝退的老哥应该都能从里面找到能直接抄的配置。1. 先搞清楚卡顿到底卡在哪一环很多人一遇到卡顿就本能地去调模型参数结果调了半天没变化。问题在于 Roo Code 调用本地模型的链路比想象中长从你敲下回车到屏幕上出现第一个字中间至少经过四五个环节任何一环拖后腿都会表现为卡。不先定位后面全是瞎调。1.1 完整调用链路拆解把这条链路摊开看大概是这么个顺序Roo Code 插件侧接收你的输入组装系统提示词、历史对话、工具定义、当前文件上下文拼成一个巨大的 prompt。HTTP 请求发出通过 OpenAI 兼容接口把 prompt POST 给本地推理服务比如 Ollama、LM Studio、llama.cpp server 等。推理服务预处理对 prompt 做 tokenize然后进入 prefill 阶段——这一步是把整个输入序列一次性算完生成 KV Cache。逐 token 解码prefill 完成后开始一个 token 一个 token 地往外吐这就是 decode 阶段。流式回传与渲染token 通过 SSE 流式返回给插件插件再渲染到聊天面板里。卡顿可能发生在 1、3、4、5 任何一处。prefill 慢表现为按下回车后长时间没反应然后突然一大段字冒出来decode 慢表现为字是一个一个蹦但每个字之间间隔明显渲染慢表现为模型其实早就返回完了但界面还在卡。1.2 用日志和计时把瓶颈钉死别靠感觉直接看数据。Ollama 的话启动时带上环境变量能看到每个请求的耗时分解OLLAMA_DEBUG1 ollama serve请求日志里会打印类似prompt eval count、prompt eval duration、eval count、eval duration这样的字段。前者对应 prefill后者对应 decode。两个一对比瓶颈立刻现形。如果是 llama.cpp server启动参数里加--verbose日志会给出prompt processing和generation的分段耗时。LM Studio 则在开发者面板里有实时的 tokens/s 显示。我自己的经验是Roo Code 这种带大量工具定义和文件上下文的场景prefill 往往是重灾区。因为它的系统提示词本身就长再加上你打开的文件、项目结构、历史消息prompt 轻松上万 token。prefill 是 O(n) 甚至更复杂的计算输入越长越慢而且这部分是一次性的用户感知就是卡住不动。1.3 一个快速判断的小实验想快速区分是 prefill 还是 decode 的问题可以做这么个对照实验新建一个空对话只问一句你好看响应速度。然后在同一个项目里打开几个大文件再问同样的问题。如果空对话很快、带上下文就卡那基本是 prefill 和上下文长度的问题如果两者都慢那可能是 decode 速度本身就不行或者模型太大跑不动。这个实验我做过不下十次结论非常稳定大部分人的卡顿其实是上下文管理没做好而不是模型本身慢。这一点后面会专门展开。2. 推理服务端的参数才是提速主战场定位完瓶颈接下来就是动手调。Roo Code 插件侧能调的东西其实不多真正的杠杆在推理服务端。下面这些参数是我反复试出来的按收益从高到低排。2.1 上下文长度别一上来就拉满这是最容易被忽视、但影响最大的一项。很多人为了让模型记住更多直接把 num_ctx 设成 32k 甚至 128k。结果就是每次请求的 prefill 都要处理这么长的窗口速度断崖式下跌。正确的做法是按需设置。Roo Code 的实际使用中单次对话真正需要的上下文往往在 8k 到 16k 之间。Ollama 里可以这样设ollama run qwen2.5-coder:7b --parameter num_ctx 8192或者在 Modelfile 里固化PARAMETER num_ctx 8192llama.cpp server 对应的是-c 8192。LM Studio 在模型加载设置里有 Context Length 选项。提示num_ctx 设小了会导致长对话被截断模型失忆。建议从 8192 起步如果发现经常丢上下文再往上加到 12288 或 16384每次加完测一下速度找到你能接受的那个平衡点。我实测下来把 num_ctx 从 32768 降到 8192prefill 时间能砍掉一大半首字延迟从七八秒降到两三秒。这个收益比换模型还明显。2.2 GPU 层数让该上显卡的都上显卡如果你有独立显卡一定要确认模型的所有层都跑在 GPU 上。Ollama 默认会尽量用 GPU但有时候因为显存不够会偷偷把一部分层放到 CPU速度直接掉一个数量级。检查方法ollama ps输出里会显示100% GPU或者xx%/yy% CPU/GPU。如果是后者说明有层跑在 CPU 上了。解决办法有两个一是换更小的量化版本比如从 Q5 换到 Q4_K_M二是减小 num_ctx 腾出显存。llama.cpp 里用-ngl 99强制所有层上 GPU数字不够就往上加。这里有个反直觉的点量化等级对速度的影响其实没有想象中大但对显存占用影响很大。Q4_K_M 和 Q5_K_M 的速度差距通常在 10% 以内但显存能差出 1-2G。显存紧张的时候降量化换来的全部上 GPU远比保留高精度但部分跑 CPU 划算。2.3 批处理与并行prefill 的加速器prefill 阶段是可以并行计算的关键参数是 batch size。llama.cpp 里对应-b逻辑批大小和-ub物理批大小。默认值偏保守适当调大能明显加快 prefill。./llama-server -m model.gguf -c 8192 -ngl 99 -b 2048 -ub 512-b 2048表示一次处理 2048 个 token 的批-ub 512是实际计算的微批。这两个值要根据显存调调太大反而会 OOM。我的 3060 12G 上-b 2048 -ub 512是个比较稳的组合。Ollama 这边对批处理的暴露比较少但可以通过OLLAMA_NUM_PARALLEL控制并发请求数。注意这个参数是同时处理几个请求不是单个请求的批大小别搞混了。单用户场景设成 1 就行设大了反而抢资源。2.4 一个容易被忽略的坑模型加载与卸载Ollama 默认会在模型空闲一段时间后卸载下次请求再重新加载。模型加载动辄几秒到几十秒如果你隔一会儿问一句每次都赶上重新加载那体验就是每次都卡。解决办法是设置 keep_aliveOLLAMA_KEEP_ALIVE-1 ollama serve-1表示永不卸载。或者在 API 请求里带keep_alive参数。代价是显存一直被占着如果你还要跑别的吃显存的任务就得权衡。我自己是设成30m既避免频繁重载又不至于一直占着。这个细节看起来小但对间歇性使用的场景体验提升巨大。3. Roo Code 插件侧的上下文管理才是隐藏大头服务端调完很多人以为就完事了。但我踩过最大的坑其实在插件侧——Roo Code 默认会往 prompt 里塞大量东西如果不加控制再快的模型也扛不住。3.1 系统提示词与工具定义的体积Roo Code 是个 agent 型插件它内置了大量工具定义读写文件、执行命令、搜索等这些定义会作为系统提示词的一部分发给模型。工具越多prompt 越长prefill 越慢。在设置里可以关掉一些你用不到的工具。比如你只是拿它做代码问答不需要它执行命令那就把命令执行相关的工具禁用。每关掉一个工具系统提示词就短一截。我数过一次全量工具定义大概能占到三四千 token。关掉一半不用的prefill 时间能省下两三成。这个收益是白捡的。3.2 自动上下文与文件读取策略Roo Code 有个很贴心但也很坑的行为它会自动把当前打开的文件、项目结构、甚至相关文件的内容塞进上下文。项目小的时候无所谓项目一大光文件内容就能把上下文撑爆。建议在设置里调整关闭自动包含打开的文件改成手动引用需要的文件。限制单次读取文件的大小超过阈值的文件不要整个塞进去。项目结构树的深度限制一下别把整个 node_modules 都扫进去。注意如果你发现模型经常答非所问或者忘记前面说的话很可能不是模型笨而是上下文被无关内容挤爆了真正重要的信息被截断。这时候该做的是精简上下文而不是换更大的模型。3.3 对话历史的滚动与压缩长对话是 prefill 的另一个杀手。每多一轮对话prompt 就长一截而且这个增长是累积的。聊到二三十轮光历史就上万 token。几个应对策略及时开新对话一个任务做完就新开别在一个对话里干所有事。利用摘要功能Roo Code 支持对历史做摘要压缩开启后旧消息会被浓缩成简短摘要。手动清理把不相关的历史消息删掉。我自己的习惯是一个功能开发完就新开对话需要之前的上下文就手动引用关键文件。这样每轮对话的 prompt 都控制在合理范围内速度一直很稳。3.4 流式渲染与界面卡顿还有一种卡是界面层面的。模型其实已经返回了但聊天面板渲染跟不上尤其是返回内容里带大量代码块、表格的时候。这种情况可以关掉一些视觉效果如果有的话。检查 VS Code 本身是不是装了一堆插件在抢资源。更新 Roo Code 和 VS Code 到较新版本渲染性能通常有优化。VS Code 的Developer: Open Process Explorer命令能看到各个进程的 CPU 占用如果发现扩展宿主进程吃满 CPU那多半是插件侧的问题而不是模型。4. 硬件与系统层面的那些隐形杀手软件调完还有瓶颈就得往硬件和系统上看了。这一层的问题最隐蔽因为表面上一切正常但性能就是上不去。4.1 显存与内存的边界本地推理对显存极其敏感。显存不够时驱动会开始往系统内存里换页速度断崖式下跌。判断方法很简单跑推理的时候开着任务管理器或nvidia-smi看显存是不是接近满载。nvidia-smi -l 1如果显存占用一直在 95% 以上而且 GPU 利用率忽高忽低那就是显存瓶颈。解决办法降量化、减 num_ctx、换更小的模型。内存这边如果模型部分跑在 CPU 上那内存带宽就成了瓶颈。双通道内存比单通道快将近一倍这个差距在 CPU 推理时非常明显。如果你在用纯 CPU 跑模型先确认内存是不是双通道。4.2 电源模式与散热降频笔记本用户特别注意默认的电源模式可能让 CPU/GPU 降频运行。Windows 上把电源计划设成高性能笔记本插上电源再跑。我见过太多人用着平衡模式抱怨模型慢切到高性能直接快一截。散热也是同理。GPU 温度到 80 度以上会开始降频持续推理很容易触发。清理一下风扇灰尘、垫高笔记本、或者限制一下功耗墙都能缓解。4.3 磁盘 IO 的偶发影响模型加载阶段是磁盘密集型的。如果模型放在机械硬盘上加载时间可能是 SSD 的好几倍。把模型文件放到 NVMe SSD 上首次加载和切换模型的速度会有明显改善。这个对每次请求都重新加载模型的场景影响最大。配合前面说的 keep_alive 设置基本能规避掉这个问题。4.4 后台程序的资源抢占浏览器开几十个标签页、后台跑着 Docker、杀毒软件实时扫描模型文件……这些都会抢资源。跑推理的时候尽量关掉不必要的东西。尤其是杀毒软件把模型目录加入白名单能避免每次读取都被扫描一遍。5. 参数调优的实测数据与取舍逻辑前面讲了不少参数这里集中给一组我实测的数据方便你有个参照。测试环境是 3060 12G 32G 内存 NVMe SSD模型用 qwen2.5-coder:7b 的 Q4_K_M 量化版本prompt 长度约 6000 token。配置项配置 A配置 B配置 Cnum_ctx3276881928192GPU 层数部分 CPU全部 GPU全部 GPU工具定义全开全开精简一半首字延迟约 9s约 3.5s约 2.2s生成速度约 12 tok/s约 35 tok/s约 38 tok/s从 A 到 B主要收益来自 num_ctx 减小和全部上 GPU从 B 到 C收益来自精简工具定义。可以看到光靠服务端参数就能把速度提升两三倍插件侧的上下文精简再叠加一层。5.1 温度与采样参数的取舍temperature、top_p 这些采样参数对速度影响很小但对输出质量影响大。Roo Code 这种代码场景建议 temperature 设低一点0.1 到 0.3输出更稳定也少一些废话 token间接省时间。repeat_penalty 别设太高太高会让模型输出变得奇怪反而增加重试成本。5.2 量化等级怎么选前面提过量化等级对速度影响不大对显存影响大。选择逻辑是显存够 → 选 Q5_K_M 或 Q6_K质量更好。显存紧张 → 选 Q4_K_M性价比最高。显存非常紧张 → Q4_0 或 Q3_K_M但质量会明显下降。我的建议是优先保证全部层上 GPU其次再考虑量化等级。部分跑 CPU 的 Q5远不如全部上 GPU 的 Q4 快。5.3 模型大小的选择7B 和 14B 的速度差距在消费级显卡上大概是两到三倍。如果你的任务对质量要求不是极致7B 完全够用速度体验好太多。14B 适合显存充裕16G 以上且对质量有要求的场景。32B 及以上在消费级硬件上基本别想流畅除非你有 24G 显存的卡而且还得接受较慢的速度。6. 排查卡顿的完整链路与常见误区最后把我自己排查卡顿的完整流程整理一下遇到问题可以照着走一遍。6.1 从现象到根因的排查顺序看日志分段耗时先确定是 prefill 慢还是 decode 慢。看 GPU 占用ollama ps或nvidia-smi确认是不是全部上了 GPU。看上下文长度估算当前 prompt 的 token 数是不是超了预期。看插件设置工具定义、自动上下文、历史消息是不是太多。看系统资源电源模式、散热、后台程序、磁盘类型。看模型本身是不是模型太大硬件根本带不动。按这个顺序走基本能在十分钟内定位到问题。6.2 几个我踩过的典型误区误区一以为换个更大的模型就能解决问题。实际上模型越大越慢卡顿往往更严重。卡顿的根因通常在上下文和配置不在模型。误区二把 num_ctx 拉满。这是最普遍的错误以为上下文越大越好结果 prefill 慢到无法忍受。按需设置才是正解。误区三忽略 keep_alive。间歇性使用场景下模型反复加载卸载体验极差。设个合理的 keep_alive 能解决大半莫名卡顿。误区四只看模型速度不看插件开销。Roo Code 的上下文组装和渲染本身也要时间尤其是大项目里。精简上下文和工具定义收益不比调模型小。误区五在错误的硬件上追求高性能。纯 CPU 跑 7B 模型再怎么调也就那样。认清硬件上限选合适的模型和量化比死磕参数更实际。6.3 一个可复现的优化 checklist把上面所有内容浓缩成一份可以照着做的清单[ ] 确认模型全部层跑在 GPU 上ollama ps显示 100% GPU。[ ] num_ctx 从 8192 起步按需调整别拉满。[ ] 设置合理的 keep_alive避免频繁重载。[ ] 精简 Roo Code 里用不到的工具定义。[ ] 关闭自动包含文件改用手动引用。[ ] 长对话及时开新对话或启用摘要。[ ] 系统电源模式设为高性能笔记本插电。[ ] 模型文件放 SSD杀毒软件加白名单。[ ] 根据显存选量化等级优先保证全部上 GPU。[ ] 根据硬件选模型大小别硬上大模型。这份清单我在三台机器上都跑过基本能把卡到不能用优化到基本流畅。具体能到多快取决于你的硬件但方向是对的。6.4 关于原生速度的预期管理最后说句实在话本地模型在消费级硬件上很难真正追平云端大模型的速度尤其是首字延迟。所谓优化到原生速度更准确的理解是优化到你这套硬件能达到的合理上限。我现在的配置下7B 模型在 3060 上首字延迟两秒出头生成速度接近 40 tok/s日常写代码、改 bug 完全够用体验已经比一开始的十几秒卡死好太多。这个提升不是靠某一个神奇参数而是把上面每一环都抠了一遍积少成多。如果你调完还是慢先别急着换硬件回头看看是不是某个环节没注意到——我见过太多案例问题其实就出在一个没设的 keep_alive 或者一个拉满的 num_ctx 上。把链路拆开、逐段计时、按需配置这套方法比任何一键优化脚本都管用。