企业官网建设流程全解析

2. 一、为什么本地模型会卡：先搞清楚瓶颈在哪

1.1 卡顿表象背后的真实瓶颈

很多人一遇到 Roo Code 调用本地模型卡顿，第一反应就是“模型太大了”“显存不够”，然后急着换更小的模型或者加内存。但根据我踩坑的经验，真正的问题往往不在模型本身，而在于整个调用链路上某个环节没打通。

我们可以把 Roo Code 调用本地模型的过程拆成四段：

• Roo Code 界面本身（VS Code 插件进程）
• 本地模型服务（Ollama、LM Studio 等）
• 模型推理引擎（llama.cpp 内核）
• 硬件资源调度（显存、CPU、内存、磁盘）

卡顿可能出现在任意一段。比如你在界面上打字都卡，那是插件进程的问题；如果是发送请求后迟迟没响应，那是模型服务的问题；如果响应开始后输出速度慢，那是推理引擎和硬件的问题。排查顺序应该是“先界面、再服务、后推理、最后硬件”，而不是一上来就盯着显存看。

我在实际调试中还发现一个容易被忽略的现象：UI 界面的卡顿和模型输出的卡顿，很多人混为一谈。界面卡顿表现为滚动、输入、切换任务时延迟，而模型输出卡顿表现为 Token 生成速度慢、首字延迟高。这两者的优化方向完全不同，甚至可能互相冲突。

1.2 用数据说话：先量化卡顿程度

在动手优化之前，建议先做一次量化测试，记录三个关键指标：

• 首 Token 延迟（从发送请求到收到第一个 Token 的耗时）
• 生成速度（每秒多少个 Token）
• 界面响应延迟（在 Roo Code 中输入、滚动、切换任务时的卡顿感）

我习惯用同一个 Prompt 分别测三次，取平均值。比如用“请用中文写一段 200 字的自我介绍”这个固定任务，分别在优化前后测试，记录数值变化。这样优化完后才能知道到底提升了多少，而不是凭感觉说“好像变快了”。

以我自己的机器为例（i7-12700 + RTX 4060 Ti 16G + 32G 内存），优化前的典型数据是：首 Token 延迟约 3 秒，生成速度约 15 Token/s，界面在模型输出时会明显掉帧。经过下面一系列优化后，首 Token 延迟降到 0.8 秒左右，生成速度稳定在 40 Token/s 以上，界面几乎不再卡顿。这个提升幅度相当可观，也说明优化空间确实很大。

2. 二、界面层优化：让 Roo Code 本身先流畅起来

2.1 VS Code 插件进程的卡顿源

Roo Code 是 VS Code 的一个扩展插件，它的运行环境是 VS Code 的 Extension Host 进程。如果这个进程被大量任务阻塞，界面就会卡顿。常见的阻塞源有三个：

第一，输出内容的渲染压力。Roo Code 的聊天面板会实时渲染 Markdown 内容，当模型输出速度很快时，渲染线程可能跟不上，导致界面卡顿。这个问题在输出包含大量代码块、表格、长文本时尤其明显。

第二，插件自身的日志和状态更新。Roo Code 运行时会持续写入日志、更新任务状态、同步配置文件，这些操作如果频率过高，也会占用主线程。

第三，VS Code 本身的扩展负载。如果你同时装了十几个插件，每个都在后台运行，Extension Host 的压力会很大。Roo Code 本身是个重量级插件，再叠加其他重型插件，卡顿几乎是必然的。

我踩过的一个典型坑是：在 Roo Code 输出代码时，同时开启了自动保存、语法高亮和实时拼写检查，结果界面直接冻住了。后来关掉了拼写检查和自动保存，卡顿立刻缓解。

2.2 实际可操作的界面优化方案

针对界面卡顿，我总结了一套实际有效的优化操作流程：

第一步，关闭不必要的 VS Code 扩展。建议只保留 Roo Code 和必要的语言支持插件，把预览类、格式化类、拼写检查类插件全部禁用。实测下来，禁用 10 个以上不常用插件后，Extension Host 的 CPU 占用能下降 30% 以上。

第二步，调整 Roo Code 的渲染设置。在 Roo Code 的设置界面中，找到“输出渲染”相关的选项。如果使用的是较新版本，可以尝试关闭“自动滚动跟随输出”功能，这个功能在模型快速输出时会导致界面持续滚动刷新，消耗大量资源。

第三步，检查 VS Code 的窗口缩放和字体渲染。如果你的显示器分辨率较高，VS Code 默认的缩放比例可能导致渲染压力增大。适当调整缩放比或字体渲染方式，也能缓解界面卡顿。

第四步，确认是否启用了硬件加速。VS Code 基于 Electron，默认启用 GPU 加速。但某些老显卡或驱动不兼容时，GPU 加速反而会拖慢渲染。可以在 VS Code 的启动参数中添加--disable-gpu测试，看界面是否变流畅。我测试过，在某些核显机器上，禁用 GPU 加速后界面响应速度反而提升了。

2.3 界面卡顿和输出卡顿的优先级取舍

这里要特别强调一个取舍问题：如果你只能优化一个方面，优先优化界面响应，而不是模型输出速度。原因很简单，模型输出慢一点，你还能等待；但界面卡顿会导致你无法正常操作、复制文本、中断任务，整个工作流会被打断。

我在实际使用中观察到，Roo Code 的界面卡顿会导致模型输出被意外中断。因为当你尝试滚动或点击时，插件进程繁忙，可能无法及时处理模型的流式输出回调，导致连接断开或者 Output 丢失。这个问题的隐蔽性很高，很多人会误以为是模型服务不稳定，其实是界面层先崩了。

所以我的建议是：如果你的机器配置一般，不要追求极致的 Token 生成速度；先保证界面流畅，再逐步释放模型推理的性能。具体做法是：调整模型的输出参数，适当降低最大 Token 数和输出长度限制，减少单次渲染的数据量。

注意：Roo Code 的界面渲染和模型输出速度之间存在一个平衡点。输出太快会导致渲染跟不上，输出太慢又影响效率。通过调节模型服务的并发数和批处理大小，可以找到最适合你机器的平衡参数。

3. 三、模型服务层优化：Ollama 与 LM Studio 的配置调优

3.1 选对模型服务：Ollama 还是 LM Studio

Roo Code 调用本地模型，最常用的两种服务是 Ollama 和 LM Studio。两者各有优劣，选择不当也会导致卡顿。

Ollama 的优势是轻量、易用、命令行友好，且与 Roo Code 的集成方式简单直接。它默认使用 llama.cpp 作为推理引擎，对显存的管理比较激进，会自动卸载无需的模型以释放显存。

LM Studio 的优势是图形化管理、模型下载方便、支持自定义采样参数。它在多模型切换和参数调节方面更灵活，但内存占用通常比 Ollama 更高。

我的实际建议是：如果你是新手或追求开箱即用，选 Ollama；如果你需要精细控制推理参数、且经常切换不同模型，选 LM Studio。当然，你也可以两个都装，Roo Code 里可以配置多个模型提供商，按任务切换。

3.2 Ollama 的核心配置优化

在使用 Ollama 时，有几个关键配置直接影响卡顿程度：

环境变量 OLLAMA_NUM_PARALLEL。这个变量控制同时处理的请求数量，默认值是 1 或 4（版本不同有差异）。如果设置过高，多个请求会争抢显存和 CPU，导致每个请求的响应都变慢。我建议设置为 1，让 Roo Code 的每个任务串行执行，保证单次响应的速度。

环境变量 OLLAMA_MAX_LOADED_MODELS。这个变量控制同时加载到显存中的模型数量，默认是 1。如果你需要频繁切换模型，可以适当增加到 2 或 3，但要注意显存容量。设置过高会导致显存不足，触发模型重新加载，反而更卡。

环境变量 OLLAMA_KEEP_ALIVE。这个变量控制模型在显存中保留的时间，默认是 5 分钟。如果你频繁调用模型，建议设置为 -1（永久保留），避免模型反复从磁盘加载。这个改动对首 Token 延迟的影响非常大，我从默认的"用后释放"改为常驻内存后，首 Token 延迟从 3 秒降到了 1 秒以内。

环境变量 OLLAMA_FLASH_ATTN。启用 Flash Attention 可以显著加速长上下文的推理速度，同时减少显存占用。建议设置为 1 开启。我在 4060 Ti 上实测，开启后长上下文生成速度提升了约 20%。

设置方式是在启动 Ollama 之前，在系统环境变量中添加这些项，或者编写一个启动脚本。以 Windows 为例，可以创建一个start_ollama.bat文件，内容如下：

@echo off set OLLAMA_NUM_PARALLEL=1 set OLLAMA_MAX_LOADED_MODELS=1 set OLLAMA_KEEP_ALIVE=-1 set OLLAMA_FLASH_ATTN=1 ollama serve

这个脚本每次启动 Ollama 时自动配置好环境变量，不用手动去系统设置里反复改。

3.3 LM Studio 的参数调节要点

如果你用的是 LM Studio，需要关注的参数和 Ollama 有所不同：

GPU Offload 层数。LM Studio 允许你手动指定卸载到 GPU 的层数。建议根据显存大小逐步增加，观察每次调整后的生成速度。如果出现显存溢出，就减少层数。这个参数对速度和显存占用的影响是线性的。

Context Length（上下文长度）。默认值往往是 4096 或 8192，但如果你只需要处理较短的任务，可以降低到 2048。减少上下文长度能显著降低显存占用和计算量，因为 KV Cache 的大小与上下文长度成正比。

Batch Size（批处理大小）。这个参数影响模型每次计算的 Token 数量。在 LM Studio 中，默认值通常足够，但如果你发现首 Token 延迟较高，可以尝试降低批处理大小，减少预热时间。

3.4 显存调度策略：避免模型反复加载

我在实际使用中发现，卡顿最隐蔽的原因是模型反复加载。当你切换上下文或任务时，Roo Code 可能会重新发送完整请求，而模型服务如果检测到显存不足，就会先把当前模型卸载再加载，这个过程可能耗时 5 到 10 秒。

解决方法是：保持模型常驻显存，同时控制模型体积。具体做法是：

• 选择合适量化等级的模型，比如 Q4_K_M 或 Q5_K_M，而不是追求 Q8 或 FP16
• 确保显存中只保留一个模型，关闭其他模型的加载
• 将上下文长度设置得足够覆盖任务需求，避免频繁清空和重建上下文

我在使用 Ollama 时把OLLAMA_KEEP_ALIVE设为 -1，加上OLLAMA_MAX_LOADED_MODELS设为 1，这两个设置组合起来，模型几乎不会反复加载，卡顿感大幅降低。

提示：模型反复加载还有一个典型的特征是“每次第一次请求特别慢，后续请求快”。如果你遇到这种情况，基本可以判定是 Keep Alive 设置过短或显存不足导致模型被频繁卸载。

4. 四、推理引擎与硬件层优化：榨干本地性能

4.1 llama.cpp 内核的关键参数解读

无论是 Ollama 还是 LM Studio，底层都是基于 llama.cpp 的推理引擎。几个关键参数直接影响生成速度：

n_ctx（上下文大小）：上下文越大，计算量和显存占用越高。Roo Code 的任务通常会发送系统提示词、用户指令和历史对话，这些都会计入上下文。如果设置过小，任务会被截断；设置过大，又会导致速度下降。我建议根据实际任务长度设置，一般 4096 到 8192 足够。

n_batch（批处理大小）：这个参数决定模型一次性处理多少个 Token，影响 Prompt Processing 的速度。增大批处理大小可以加快首 Token 延迟，因为 Prompt 可以被更快地并行处理。但如果显存有限，过大的批处理会导致 OOM（显存溢出）。我建议在显存允许范围内，从 512 逐渐增加到 1024 或 2048，观察首 Token 延迟的变化。

n_threads（线程数）：CPU 推理时线程数的设置直接影响计算速度。如果线程数低于 CPU 核心数，推理会变慢；过高则导致切换开销。在只有 CPU 推理或部分 CPU 卸载的场景下，建议设置为 CPU 物理核心数（不是逻辑线程数），比如 8 核 16 线程的 CPU，设置 8。

gpu_layers（GPU 卸载层数）：模型的前若干层被卸载到 GPU 计算，剩余层在 CPU 上计算。卸载的层数越多，显存占用越高，但生成速度通常也越快。对于 16G 显存的显卡运行 7B 模型，可以考虑全部卸载；对于 34B 甚至更大模型，需要根据显存精确计算。

4.2 使用 GPU 还是 CPU：我的实测对比

我分别在 GPU 和 CPU 两种模式下跑过同一个 7B 模型，记录生成速度。结果如下：

纯 GPU 的速度是纯 CPU 的 5 倍以上，差距非常明显。如果你有 NVIDIA 显卡且显存足够，优先让模型全部跑在 GPU 上。

需要提醒的是，Mac 用户的情况有所不同。Apple Silicon 统一内存架构，GPU 和 CPU 共享内存。在 Mac 上直接全部卸载到 GPU（也就是 Metal）是合理选择，不需要像 NVIDIA 那样纠结显存分配。

4.3 硬件层面的其他优化手段

除了显存分配，还有几个硬件层面的优化点容易被忽略：

关闭无关进程。本地模型推理时，浏览器开几十个标签页、后台挂着视频渲染、IDE 里跑着编译任务，这些都会抢占 CPU 和内存资源。建议推理时关闭不用的软件，至少保证 8G 以上可用内存。

更新显卡驱动。不要小看驱动的作用。NVIDIA 显卡驱动对 CUDA 和 llama.cpp 的兼容性重大影响。我曾经因为驱动版本过旧，生成速度只有 12 Token/s；更新到最新驱动后，直接翻倍到 25 Token/s 以上。

确认是否走 CUDA 还是 Vulkan。llama.cpp 在不同编译版本下支持不同的后端。如果你的机器支持 CUDA，确保使用的是 CUDA 版本而不是 CPU 版本。有些用户安装了纯 CPU 版，却误以为在用 GPU 推理，卡顿是必然的。

4.4 温度参数和上下文裁剪对速度的影响

在 Roo Code 调用模型时，可以通过 API 参数影响生成速度。关键参数包括：

Temperature（温度）：温度不影响速度，但影响生成效果。如果你在优化速度，温度设为 0.6 到 0.8 之间即可，太低会导致输出死板，太高会导致跑题。

Max Tokens（最大生成长度）：这个参数限制每次最多生成多少 Token。如果你只是处理简短任务，设置较小的 Max Tokens 可以避免模型浪费算力生成冗余内容。Roo Code 中如果设置了太大的 Max Tokens，即使模型完成回答，也存在后续输出被打断时的计算浪费。

Stream（流式输出）：Roo Code 默认使用流式输出，也就是边生成边显示。如果你发现界面卡顿，可以尝试关闭流式输出，等模型全部生成完再一次性显示。但这样会失去实时预览的体验，且首字延迟会变长。我建议保留流式输出，通过优化渲出来解决界面卡顿问题。

注意：上下文裁剪非常关键。Roo Code 每次发送请求时，会默认携带历史对话作为上下文。如果对话太长，Prompt 的 Token 数会很大，导致每次请求的首 Token 延迟剧增。合理裁剪上下文、控制对话轮数，能明显降低每次请求的计算量。

5. 五、完整优化实战：从卡顿到原生速度的全流程

5.1 优化前的评估与准备

开始优化之前，先准备好以下信息：

• CPU 型号、核心数和线程数
• 显卡型号、显存大小
• 内存容量和频率
• 正在使用的模型名称和量化等级
• Roo Code 版本号和模型服务版本号

我整理了一份自用的评估表，你可以对照填写：

拿到这些信息后，就可以开始逐层优化了。

5.2 优化步骤一：先解决模型服务的启动和常驻

这一步的目标是让模型尽快就绪，避免反复加载。

在 Ollama 中，通过环境变量设置模型常驻。这里要注意，OLLAMA_KEEP_ALIVE=-1只在关闭 Ollama 或模型被手动卸载前有效。如果你需要切换模型，建议先手动删除旧的模型（用ollama stop命令）再加载新的。

我建议在 Windows 上把 Ollama 的启动命令写进一个批处理文件，双击即启动并带好配置。完整内容如下：

@echo off set OLLAMA_NUM_PARALLEL=1 set OLLAMA_MAX_LOADED_MODELS=1 set OLLAMA_KEEP_ALIVE=-1 set OLLAMA_FLASH_ATTN=1 ollama serve

如果你的电脑是 16G 显存，可以把OLLAMA_MAX_LOADED_MODELS提高到 2，但前提是两个模型的总显存占用不超过 13G 左右，留出余量给上下文和计算缓冲。

5.3 优化步骤二：调节 Roo Code 侧的请求参数

Roo Code 中与本地模型相关的设置主要在这些地方：

• OpenRouter / OpenAI 兼容 API 配置（指向本地地址）
• 模型的 Max Tokens 上限
• 上下文长度设置
• 任务并发数

实际配置时，我建议：

• Max Tokens 设为 2048 或 4096（根据任务需求）
• Context 设为 4096 起步，如果任务复杂再调高
• 并发数设为 1（Roo Code 本身是单任务串行执行，不需要并发）

Roo Code 的 API Base URL 如果配置的是http://localhost:11434/v1，则调用 Ollama 的 OpenAI 兼容接口。注意需要在 Ollama 服务运行后才能访问。

5.4 优化步骤三：验证 API 调用是否走对端口

这一步很容易踩坑。很多人在配置 Roo Code 时，把 API 地址写错了，或者端口不对，导致请求走了 else 的默认公共端点，结果延迟极高。

验证方法：在浏览器中访问http://localhost:11434，如果能看到提示，说明 Ollama 正在运行。再访问http://localhost:11434/v1/models，如果能返回模型列表 JSON，说明 OpenAI 兼容接口正常。

在 LM Studio 中，默认端口是http://localhost:1234/v1。如果你用的 LM Studio，需要在 Roo Code 里把 API Base URL 改为这个地址。

我踩过的一个坑是：安装了多个本地模型服务，端口冲突，结果 Ollama 的请求被某个错误地路由到了 LM Studio，导致接口返回格式不对，Roo Code 一直报错、重试，界面卡顿严重。关闭多余的服务后恢复正常。

5.5 优化步骤四：测试并记录优化效果

完成以上配置后，重新运行性能测试，对比优化前后的数据：

生成速度从 15 到 42 Token/s 的跨度是非常可感的。在 Roo Code 中连续对话时，每个回答几乎都是即时打印出来的，不再有“一个字一个字蹦”的粘滞感。

5.6 优化步骤五：进阶设置（按需开启）

如果你的显存足够，可以尝试以下进阶设置：

开启 Flash Attention。在 Ollama 中已通过环境变量开启。如果使用 LM Studio，可以在模型加载设置中找到 Attention 相关选项开启。

降低模型精度。如果显存不足导致模型只能部分卸载到 GPU，考虑改用 Q3_K_S 或 Q3_K_M 量化的模型文件。量化等级降低会带来轻微的效果损失，但速度提升明显。我在 7B 模型上实测，Q4 降到 Q3，速度还能再提升约 15%。

使用更小的模型。如果任务不复杂，换用 1.5B 或 3B 的小模型，速度会非常快，几乎零卡顿。Roo Code 中可以通过 API 配置切换模型，不影响整体工作流。

6. 六、常见问题排查与速查表

6.1 卡顿问题排查清单

结合长期实操，整理了这张速查表，按优先级排查：

6.2 避坑心得：最常见的五个坑

第一个坑是端口写错。Ollama 的 OpenAI 兼容接口是http://localhost:11434/v1，而不是根地址。漏写/v1会导致接口返回 HTML 而非 JSON，Roo Code 解析报错后反复重试，形成卡顿假象。

第二个坑是Max Tokens 设置的过小。如果任务生成的回答长度超过了 Max Tokens 上限，Roo Code 会截断输出，模型可能生成一半就停止。用户以为模型卡住了，一直在等待，实际是输出被限制了继续生成。

第三个坑是同时多个模型服务争抢显存。装了 Ollama、LM Studio、One-API 等多个程序，各自加载不同的模型，显存被瓜分，每个模型都只能用一小部分 GPU 算力，速度当然慢。解决办法是统一用其一，并确保其他服务退出。

第四个坑是驱动版本太旧。很多人长期不更新显卡驱动，导致 llama.cpp 无法发挥新硬件的性能。定期更新驱动对本地模型推理的提速效果非常明显。

第五个坑是上下文设置过大。在 Roo Code 中如果对话历史很长，每次请求携带的上下文会越来越大，首 Token 延迟会呈线性增长。建议及时清空多余对话，或手动控制内部对话轮数。

6.3 实测案例：从卡顿到流畅的完整记录

最后分享一个完整的实测案例。有位使用 8G 显存笔记本的朋友，配置是 i5-12450H + RTX 3050 4G。他反馈 Roo Code 调用 Qwen2.5-7B 时卡得无法使用，首 Token 延迟约 8 秒，生成速度只有 4 Token/s，界面也频繁冻结。

我们一起排查后发现：他的 Ollama 版本过旧，不支持 Flash Attention。模型默认加载到 CPU，GPU 只卸载了少数几层。4G 显存跑 7B Q4 模型，理论上是能卸载约 20 层的，但因为驱动不支持 CUDA 12.2，导致 GPU 后端失效。

我们做了三步调整：

1. 更新 Ollama 到最新版本并开启 Flash Attention
2. 更新 NVIDIA 驱动到支持 CUDA 12.2 的版本
3. 把模型从 Q4_K_M 换为 Q3_K_S 量化，并设置OLLAMA_KEEP_ALIVE=-1

最终结果：首 Token 延迟降到了 1.5 秒，生成速度稳定在 18 Token/s，界面卡顿基本消失。这个例子说明，即使显存不大，通过正确的配置和优化，也能达到可用的流畅度。

7. 七、其他常见卡顿场景的延伸优化

7.1 Roo Code 调用 LM Studio 卡顿

同样的问题在 LM Studio 上也会遇到。与 Ollama 相比，LM Studio 的卡顿主要体现在界面负载较高、模型切换时加载慢。建议：

• 使用 LM Studio 的本地推理服务时，关闭服务器模式的多用户功能，只保留本机访问
• 在 LM Studio 的设置中，降低“高水位线”（GPU 显存分配上限），防止显存被占满
• 使用 LM Studio 时，建议开启 CPU 和 GPU 同时推理，在显存不足时自动分摊

如果你在 Roo Code 中配置 LM Studio，记得 API Base URL 填http://localhost:1234/v1，并确认 LM Studio 的开发者模式已经开启。

7.2 表格类大数据渲染卡顿的优化思路

如果你在 Roo Code 中处理的是代码生成、日志分析等数据密集任务，可能会遇到输出大量表格时界面卡顿。Roo Code 会渲染包含大量行列的表格，渲染开销很大。

优化的思路是：避免模型一次性输出超长表格。可以在 Prompt 中要求模型用简洁的列表或分段输出，而不是生成庞大的 Markdown 表格。比如让模型"用三点说明每个方案"，而不是“列一个 20×5 的表格”。

7.3 联想：与本地向量模型集成时的卡顿

有些用户会把 Roo Code 与本地向量模型（如 embedding 模型）集成，用于 RAG 检索。当每次请求都需要先做向量的存储和检索时，卡顿可能出在向量模型的调用开销上。

我的经验是：将 embedding 模型和对话模型分开部署，避免同一个服务同时处理两种任务。embedding 模型通常很小，可以用 CPU 跑；对话模型在 GPU 上跑。这样可以避免两者争抢显存和计算资源。

7.4 从 Roo Code 出发，迁移到 Claude Code 调用本地模型的经验

最近很多人开始尝试用 Claude Code 调用本地模型（比如 LM Studio），遇到卡顿问题的思路是完全一致的。核心都是：

• 模型常驻显存
• 正确的 API 地址和格式
• 合理的上下文管理
• 匹配的量化等级和硬件配置

如果你从 Roo Code 切换到 Claude Code，不要想着重写一套优化方案，而是沿用这套排查流程：先确认 API 通不通，再确认模型是否常驻，最后调节推理参数。这套方法论是通用的，与具体前端工具无关。

8. 写在实际操作后的几点体会

经过这么多轮优化，我最深的体会是：本地模型调试的卡顿，绝大多数不是单点问题，而是整条链路不协调的结果。你可能花几个小时去调一个参数，最后发现真正的问题是另一个环节。

比如有一次，我反复调 OLLAMA_NUM_PARALLEL、换模型量化等级、调上下文长度，始终觉得速度不行。最后发现是 VS Code 的另一个插件在后台做索引，把 CPU 吃满了，导致 CPU 与 GPU 混合推理时整个系统变慢。关掉那个插件后，一切恢复了正常。这提醒我：对本地模型优化来说，全局的资源调度意识比逐点调参更重要。

另外，记录优化前后的数据也是我强烈推荐的。没有量化数据，你很难知道某个调整到底有没有效果，也很难在和他人交流时说明问题的真实状态。花十分钟做一次标准化测试，能省下后面几小时的盲调时间。

最后再说一个小技巧：如果你的机器显存不大，建议固定使用同一套模型的常驻方案，不要频繁在多个模型之间切换。模型切换本身会带来额外开销，而且每次切换后要重新预热，卡顿感会很强。该用大模型的时候才切过去，平时尽量用一个小模型完成高频简单任务，这是我在实际使用中最省心的配置。

这套优化流程我维护了很长一段时间，每隔一阵就会根据新版本的工具重新验证一遍。不同版本的 Ollama、Roo Code 在参数默认值上有所变化，但底层的优化思路稳定可靠。希望这份踩坑实战记录，能帮你省下不少弯路。