企业官网建设流程全解析

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 里说"帮我把这个模块改造成异步实现"，发生的是这几件事：

1. Roo Code 把系统提示词、历史对话、相关文件内容和你的新指令拼成一个完整的 Prompt
2. 通过 OpenAI 兼容的 API 格式，POST 到本地推理引擎（比如 Ollama 或 LM Studio）的/v1/chat/completions接口
3. 推理引擎把 Prompt 切分成 token，先做一次 Prefill（预填充），然后开始逐 token 生成回复
4. 生成过程按流式方式把 token 逐步返回给 Roo Code（如果配置了流式的话）
5. 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 级别的编码专用模型，其次是 7B，32B 及以上要看你的显卡。

以我现在的主力模型 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。

我给一个直观的选型优先级参考：

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 0

num_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、部分层在 CPU，GPU 和 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 的 Prompt，Qwen2.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 修复后的数据对比与仍然存在的隐患

修复之后我重新测了同一任务：

整个体验直接从"没法用"变成了"能日常用"。

但我也要说一句：只要还用 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 秒等待里解脱出来。