企业官网建设流程全解析

如果你也试过在 Roo Code 里接本地模型，大概率会碰上这样一种体验：第一句话发出去，光标转圈转得人心慌；好不容易开始出字了，又是一个字一个字往外蹦，像在看慢镜头回放。说“卡顿”都算客气了，对话稍微长一点，上下文直接被吞，AI 突然像失忆了一样。这个问题我前前后后折腾了大半个月，换过模型、调过参数、翻过日志、改过 Roo Code 配置，最后终于把本地模型的响应速度拉到了接近官方 API 的水平。整个过程踩坑不少，这篇就把我的排查思路、具体配置和实测结果完整记录下来，给同样在 Roo Code 里折腾本地模型的朋友一个可复现的优化路径。

先说结论：Roo Code 调用本地模型的卡顿，九成不是 Roo Code 本身的锅，而是模型加载链路、上下文窗口和服务端参数配置出了问题。把这三个层面理顺，速度就能有质的飞跃。文章会按照“链路分析 → 服务端优化 → Roo Code 侧配置 → 实战案例 → 问题排查”的顺序来写，每个环节都给出可直接抄作业的参数和命令。

1. 先看清整条链路：Roo Code 本地模型为什么慢

1.1 Roo Code 调用本地模型的基本原理

Roo Code 是一个 VS Code 里的开源 AI 编程助手，支持通过兼容 OpenAI 的 API 接口来对接各类模型。本地模型的接入方式，通常是用 Ollama 或者 LM Studio 这类工具，在本机起一个 HTTP 服务，然后 Roo Code 通过http://localhost:11434/v1或者http://localhost:1234/v1这样的地址去调用。

很多人以为“本地模型卡”就是模型不行，其实不对。本地模型运行的过程分三个阶段：

• 加载阶段：模型文件从磁盘读入内存和显存，这是一个大文件，动辄 4GB 到 12GB，慢是正常的。
• 预填充阶段（prefill）：模型把你这轮对话的全部历史上下文一次性处理计算，生成初步的内部状态。上下文越长，这个阶段越慢，体感就是“半天不出第一个字”。
• 生成阶段（decode）：模型逐个 token 输出文字，速度取决于显存带宽和模型大小，体感是“一个字一个字往外蹦”。

这三个阶段里，加载阶段和预填充阶段是“卡顿感”的主要来源。尤其是预填充阶段，很多人没意识到，Roo Code 每次请求会把整个会话历史全部发给模型，哪怕你已经忘了前面聊过什么，模型还得重新读一遍。上下文一长，这个阶段的计算量是线性甚至超线性增长的。

1.2 卡顿的三类典型症状与初步定位

根据我自己和身边朋友的反馈，Roo Code 接本地模型的卡顿大致可以分成三类，症状不同，对应的瓶颈也不同：

定位方法很简单：如果同样的问题在云端模型上很流畅，在本地模型上卡，那问题一定出在本地服务端或者配置上；如果本地模型在普通聊天工具里流畅，在 Roo Code 里卡，那问题就出在 Roo Code 的请求方式上，比如上下文管理不当、并发请求过多、或者挂载了太多暂不使用的 MCP 组件。

1.3 一次完整的“慢请求”拆解：时间都去哪儿了

我建议你先做一次完整的“慢请求观测”，否则后面的优化都是盲人摸象。具体操作如下：

1. 打开终端，运行ollama ps，确认模型是否已经加载到 GPU，以及显存占用情况。
2. 打开 Roo Code，发起一轮测试对话，记录从发送到第一个字出现的时间。
3. 观察ollama ps中模型加载状态是否发生变化，如果发生变化说明之前模型被卸载了。
4. 在任务管理器（Windows）或者htop（Linux/macOS）里观察 GPU 显存和 CPU 占用率。

我实测下来，一次“正常但偏慢”的请求，时间分布大概是这样的：模型加载 20 秒（如果没有常驻）、prefill 计算 15 秒、剩余的是生成时间。也就是说，大部分浪费时间根本不在于模型“想”得慢，而是在于加载和重新计算历史上下文。搞清楚这一点，优化的方向就非常明确了。

2. 服务端优化：让本地模型本身跑得更快

2.1 模型选型与量化级别的取舍

很多人一开始就选了 32B 甚至 70B 的模型，觉得大模型聪明，结果发现自己的显卡根本装不下，部分层跑到 CPU 上做计算，速度惨不忍睹。模型选型是优化的第一步，也是最关键的一步。

如果你的显卡显存是 8GB 到 12GB，目前性价比最高的选择是 7B 到 14B 参数量的模型，量化级别用 Q4_K_M 或者 Q5_K_M。Q4_K_M 是 4bit 量化，体积约为原模型的 1/4 到 1/3，质量损失很小，但速度优势非常明显。

以编程场景为例，我强烈推荐qwen2.5-coder:7b或者qwen2.5-coder:14b这两个档位。7B 的话 6GB 显存就能跑；14B 的 Q4_K_M 量化包大约是 9GB，需要 12GB 显存才比较从容。

显存计算的方式很简单：模型文件大小 + 上下文窗口对应的 KV cache。KV cache 可以粗略估算为2 × 层数 × 隐藏层维度 × 上下文长度 × 2字节。以 14B 模型为例，当上下文窗口设置成 8192 时，KV cache 大约是 1GB 到 2GB；如果设置成 32768，就会涨到 4GB 到 6GB。所以不是上下文窗口越大越好，显存不够时，大窗口反而会因为内存交换而变得更慢。

2.2 Ollama 核心参数调优：keep_alive / num_ctx / 并发

Ollama 是目前 Roo Code 接本地模型最常用的方案，它的默认参数不少都有问题，我一个个说。

首先是keep_alive 参数。这个参数决定模型在内存里常驻的时间，默认是 5 分钟。也就是说，你上一次对话结束 5 分钟后，Ollama 会自动把模型从显存里卸载，腾出显存给其他程序。问题是，本地模型从磁盘重新加载到显存，14B 的模型要 20 秒到 30 秒。这就解释了为什么你隔一会儿再问 Roo Code，会突然卡很久。

解决办法是设置环境变量OLLAMA_KEEP_ALIVE=-1，表示模型常驻不卸载。在 Windows 上，你需要在系统环境变量里添加这个变量，然后重启 Ollama 服务。在 Linux 上可以直接export OLLAMA_KEEP_ALIVE=-1。如果你每天都会使用，设置为30m也行，但既然都本地部署了，我建议直接永久常驻。

然后是num_ctx 参数。这是 Ollama 的上下文窗口大小，默认只有 4096 token。这个默认值非常坑：当会话历史超过 4096 个 token 后，模型会丢弃最早的消息。更糟糕的是，有些场景下模型会因为“撞墙”而行为异常，表现为记忆混乱甚至直接报错。在 Roo Code 里编程，一轮任务往往就包含系统提示、文件内容、工具调用记录，很容易突破这个限制。

调整的办法有两个：一是启动模型时指定，比如ollama run qwen2.5-coder:14b --num-ctx 16384，但 Roo Code 调用时需要服务端知道这个参数，更好的办法是直接在 Roo Code 的模型配置里设置contextWindow，Roo Code 会把它转换成请求参数发给 Ollama。

最后是并发参数。Ollama 默认情况下一次只能处理一个请求，额外的请求会排队等待。Roo Code 在某些操作场景下会发出并发请求（比如同时处理多个文件改动），所以可以设置OLLAMA_NUM_PARALLEL=2或者3。但注意不要设置太高，本地模型的显存和算力有限，并行处理多个请求会互相拖慢，反而更卡。我实测下来，OLLAMA_NUM_PARALLEL=2是个合理值。

还有两个容易被忽略的环境变量：OLLAMA_MAX_LOADED_MODELS控制最多同时加载几个模型，默认是 1，如果你只用一个模型就不用改；OLLAMA_MAX_QUEUE控制队列长度，默认为 512，这个一般不用动。

2.3 LM Studio 服务端的关键配置

如果你用的是 LM Studio，优化思路类似但位置不同。LM Studio 的本地服务端点默认是http://localhost:1234/v1，模型名需要填写具体的模型标识符，通常格式是一长串路径加文件名，在 LM Studio 的 Developer 页面里能直接复制。

LM Studio 里有两个关键设置：

• GPU Offload 层数：在加载模型时，有个滑块可以控制多少层模型放到 GPU 上。如果显存足够，直接把它拉到最大（全部 offload），速度最快。如果显存不够，至少要把大部分层放 GPU，只在最后几层放 CPU。
• 上下文长度：在模型配置的Context Length里调整，默认也是 4096。你可以和 Roo Code 侧设置的 contextWindow 保持一致。

另外 LM Studio 的服务端口默认是 1234，如果你本机 1234 被占用，可以换端口，但记得 Roo Code 里的 baseURL 也要同步修改。

2.4 硬件资源检查：GPU 真的被用上了吗

这是很多人忽略的一点：你以为模型在 GPU 上跑，其实它可能在 CPU 上硬扛。我就碰到过类似情况，用 4060 显卡跑模型，速度却慢得离谱，一查发现 Ollama 用的是 CPU 模式。

检查方法非常直白，运行ollama ps，看PROCESSOR这一列：

如果显示 CPU 或者混合模式，首先要确认显卡驱动是否安装正确。Windows 上，Ollama 依赖 CUDA 和 NVIDIA 驱动，去官网装最新驱动即可。装完驱动后重启 Ollama，用ollama ps验证。

另外一种常见情况是显存不足导致部分层落回 CPU。比如你拿 8GB 显存的卡跑 14B 模型，模型文件 9GB，自然放不下，于是部分层就跑到内存里用 CPU 算。这时候的优化方向就两个：换更小参数量的模型，或者用更低量化的版本（比如从 Q5_K_M 降到 Q4_K_M 甚至 Q3_K_S）。模型文件大小直接决定显存占用，这一步是最立竿见影的优化。

3. Roo Code 侧配置优化：让请求更轻、更高效

3.1 API 端点与模型信息的正确配置方式

Roo Code 的 API 配置入口在左下角的“账户/设置”区域，选择 Provider 时有几个选项：如果选 Ollama，Roo Code 会自动枚举你本机已下载的模型列表；如果选 OpenAI Compatible，需要手动填写baseURL和model。

我的建议是：优先用 Ollama Provider，它会在配置时自动请求/api/tags接口拿模型列表，避免手填模型名时出现的“404 model not found”问题。如果你确实要用 OpenAI Compatible 模式，需要注意两点：

• baseURL要填完整：Ollama 的兼容端点不是http://localhost:11434而是http://localhost:11434/v1，漏掉/v1会一直报连接错误。LM Studio 的端点则是http://localhost:1234/v1。
• model名要带 tag：比如不能只写qwen2.5-coder，要写qwen2.5-coder:14b；LM Studio 则必须填模型文件的完整标识。

填完之后，Roo Code 会要求你配置模型信息（Model Info）。这里重点设置三个字段：

• Context Window：本地服务端的上下文长度，要和 Ollama 的 num_ctx 一致。比如统一设置为16384。
• Max Output Tokens：单次生成的最大 token 数，建议4096甚至8192。如果设置太小，Roo Code 执行复杂的代码生成任务时会被频繁截断，表现为“生成到一半就停”。
• Temperature：编程任务建议0到0.3。温度太高模型容易胡言乱语，也会让输出更不可预测。

3.2 上下文管理：控制 token 消耗的实战技巧

这是整个优化里我认为最核心的一环。Roo Code 的底层机制决定了，每次对话都会把完整历史发给模型。这意味着，如果一段会话持续了两个小时，积累了大量的文件内容和工具调用记录，后续每次请求的 prefill 阶段都会非常耗时，而且很可能超过上下文窗口上限。

我实测过一个案例：一段会话积累到 12000 个 token 之后，每次请求的 prefill 时间从 3 秒涨到了 18 秒。这不是模型变笨了，而是它的“开场白”越来越长了。

控制上下文有几个实用的招：

• 及时清理会话：当一个任务完成，就该新建会话，不要让一个会话里堆积多个无关任务。Roo Code 有清理功能的入口，但手感和云端产品有差距，所以我自己习惯是每完成一个独立任务，就手动开新会话。
• 主动精简任务描述：向 Roo Code 描述需求时，精准说出文件路径和目标，不要让它去扫描无关目录。
• 利用/clear命令：在某些版本里，通过命令面板输入/clear可以重置当前会话的上下文，但要保留任务上下文的话，记得先把重要信息记录到项目记忆里。
• 避免在同一个会话里频繁切换关注点：比如一会儿让模型改前端、一会儿让它改后端、一会儿问它数据库设计，这种反复横跳会加速上下文膨胀。我自己的习惯是：说清楚当前这个阶段“只做 A 类任务”，其他问题先记在 TODO 里，下一轮会话再处理。

3.3 流式输出、超时与并发设置的细节

Roo Code 默认采用流式输出，也就是模型生成一个 token 就推一个过来，这个不需要手动改，也不要主动去改成非流式。非流式要等全部生成完才一次性返回，长代码段等待时间会非常长，体验几乎是不可用的。

真正容易踩坑的是超时设置。有些版本默认的 HTTP 超时时间比较短，本地模型响应稍慢一点就会触发超时，Roo Code 直接报错中断。如果你发现对话进行到一半突然提示请求失败，去设置里把超时时间调长，比如300秒。这一步千万别省，尤其是你刚优化完服务端参数，还没来得及验证效果时，又冒出个超时错误，很容易让人误以为优化没起作用。

另外要谨慎开启“并发请求”相关的选项。Roo Code 在某些场景下会同时跑多个生成请求，比如并行修复多个编译错误，这是很方便的功能。但本地模型的服务端（Ollama 或 LM Studio）在并行处理时，每个请求都会变慢，整体吞吐反而不如串行。我个人的经验是：并发请求只在显存余量充足且模型较小（7B 级别）时才打开；8GB 显存跑 14B 模型，老老实实关掉并发，一次干一件事。

3.4 善用记忆功能：减少重复劳动和上下文累积

Roo Code 支持在项目里维护一个ROO/目录，里面可以放置系统提示、规则文件和逐步任务的记录。合理利用这些文件，能大幅减少模型在对话里“重复确认”的次数，从而间接降低上下文膨胀。

具体做法是：在项目根目录创建.roo/配置文件，把项目的搭建约定、代码风格、依赖管理方式等常量信息写进去。这样 Roo Code 每次读取项目时就能自动掌握这些背景，你不用在每轮对话里重复描述。实际上模型需要转的圈子少了，浪费在冗余上下文上的 prefill 时间也跟着减下来了。

4. 实战案例：从“三分钟等一次”到“接近原生速度”

4.1 案例环境与初始痛点

我用一套有代表性的环境来做这次实测：Windows 11 Notebook，NVIDIA RTX 4060 8GB 显存，32GB 内存，Ollama 0.5 版本 +qwen2.5-coder:14b（Q4_K_M 量化，文件约 9GB），Roo Code 为当时的最新稳定版。

初始状态非常不理想：第一次对话大约要 40 秒才开始出字，输出速度约为每秒 8 到 10 个 token。对话超过 10 轮之后，每次请求前都会出现一段 20 到 30 秒的明显停顿。如果隔 6 分钟没有操作，再次对话还会额外多等 20 秒左右，那是模型重新加载的时间。总体而言，根本没法用于真实开发。

我先用ollama ps检查，PROCESSOR显示为100% GPU，说明不是 CPU 推理问题，显存空间的紧张才是首要嫌疑。

4.2 逐步优化的实测记录

第一步：解决模型反复加载问题。

设置系统环境变量OLLAMA_KEEP_ALIVE=-1，重启 Ollama 服务。这一步做完，最明显的变化是“隔几分钟再问”不再需要等待模型加载了。表面上省的是 20 秒的加载时间，实际上更重要的是，模型常驻显存后，上下文状态得以延续，后续请求的 prefill 也稳定了。

第二步：调整上下文窗口与模型兼容。

Roo Code 默认可能给 Ollama 发送较大的上下文窗口请求，但 Ollama 侧的模型默认num_ctx=4096，两者不匹配会导致两方面的问题：一是对话稍长就被截断，二是模型需要动态重建上下文而额外消耗计算资源。

我把 Roo Code 的 Context Window 设为8192，同时把 Ollama 的num_ctx也调整为8192。为什么不是 16384？因为 8GB 显存跑 14B Q4_K_M 已经占了约 9GB 文件所需的显存空间（实际会用到部分内存），再给 8192 token 的 KV cache（约 1.5GB 到 2GB），刚好接近显存上限。如果强行开到 16384，KV cache 变大，模型就不得不把一些层挪到 CPU，反而更慢。

调整之后，首字延迟从 40 秒降到了 10 秒以内，输出速度略有提升，能稳定在每秒 12 到 15 个 token。卡顿感还在，但至少能用了。

第三步：换用模型大小与显存更匹配的方案。

8GB 显存跑 14B 模型，显存始终处于临界状态，系统经常要处理内存与显存之间的交换。我换成了qwen2.5-coder:7b（Q4_K_M 约 4.7GB），显存瞬间宽裕。KV cache 开到了 16384 也毫无压力。同时，我把 Roo Code 的 Max Output Tokens 从默认值调到了4096。

这一步的体感变化最明显：首字延迟降到 3 秒以内，流式输出稳定在每秒 25 到 35 个 token。这个时候，Roo Code 的响应速度已经非常接近付费 API 的体验了。

第四步：清理 MCP 和关闭并发。

我检查了 Roo Code 里挂载的 MCP（Model Context Protocol）服务器，发现之前配置的文件系统 MCP 和 fetch MCP 虽然平时不用，但仍在每次请求时被加载为工具列表并占用上下文。我把这两个 MCP 从配置里移除，然后关闭了并发请求选项。

这一步之后，即便是复杂的多文件修改任务，也能保持流畅输出，不再出现“突然卡住几秒再继续”的顿挫感。最终的实测数据是：中等复杂度任务从提出需求到完成，平均耗时从原来约 5 分钟降到 1 分钟以内，和云端模型的使用体验差距已经非常小了。

4.3 最后的配置清单（可直接抄作业）

5. 常见问题与排查技巧实录

5.1 高频问题速查表

问题遇到了不要慌，大部分情况都能根据现象快速对号入座：

5.2 几个容易忽略的“隐形杀手”

排查过程中我有几个深刻的教训，这里单独拿出来说。

第一个是 Windows 上的 Ollama 老进程残留。改了环境变量之后没重启 Ollama，或者服务管理器里有多个 Ollama 进程并行，导致新参数根本没生效。最稳妥的做法是：修改环境变量后，在任务管理器里把所有 Ollama 相关进程全部结束，再重新启动服务或者直接重启电脑。别怕麻烦，参数生效与否直接决定后续所有优化是否有效。

第二个是磁盘速度对模型加载的影响。模型文件从 NVMe 固态硬盘加载和从机械硬盘加载，时间差是好几倍。如果模型需要反复加载，而你又刚好存在机械盘上，那配置再优化也白搭。把模型目录放到 NVMe 固态盘上，这个细节能让你在每次启动时少等十几秒甚至几十秒。

第三个是显存不是只看总容量。某些显卡的显存中有一部分会被系统和其他常驻程序占用，实际可用显存比标称值少不少。在任务管理器的“性能”面板里，去看“专用 GPU 内存”的“共享”项，确认真实的可支配余量。我自己的机器就是所谓 8GB 显存，实际跑模型可用只有 6.8GB 左右，这也是我最后选择 7B 模型的原因之一。

第四个是 Roo Code 版本更新后配置变化。Roo Code 迭代速度非常快，某些版本升级后，之前填的自定义 Provider 配置可能被重置，或者模型信息需要重新确认。升级后最好第一时间去设置页看一眼模型参数，免得用着用着突然变慢。

5.3 进阶方向：Embedding、向量记忆与更快的引擎

如果你的本地模型在 Roo Code 里已经跑得很流畅，还想更上一层，可以尝试两个方向。

一个是本地 Embedding 模型的接入。Roo Code 的代码库记忆和 @ 方式引用文件时，可能会调用 Embedding 服务来做相关性检索。默认情况下，Roo Code 可能使用云端或内置的 Embedding 服务，但这会拖慢本地整体使用体验，还可能在无网络时不可用。你可以通过 Ollama 部署一个nomic-embed-text之类的本地 Embedding 模型，并把 Roo Code 的相关配置指向它。这样文件引用和记忆检索都完全本地化，速度和隐私都更好。

另一个方向是尝试更快的推理引擎。Ollama 和 LM Studio 背后都是 GGUF 格式加各类推理后端，但不同版本的优化程度有差异。比如 Ollama 的Qwen3系列模型在某些新版本里支持了更多优化算子，速度比早期版本提升明显；LM Studio 也有性能模式的设置。我的建议是保持 Ollama 和 LM Studio 的自动更新，实测新版本通常会带来推理速度的改进，不会越更新越慢。

写在最后：一些掏心窝的体会

折腾完这一圈，我最大的感受是：本地模型和云端 API 的差距，不在于“能不能跑”，而在于愿不愿意花时间去研究它。云端 API 开箱即用，是因为人家帮你把加载、并发、上下文管理这些事情都做了；本地模型把这些选择权全部交到你手里，没人帮你兜底，能不能让它跑顺，拼的全是细节。

我踩过的最大的坑，是当初一门心思地盯着“显存够不够”“模型大不大”，完全没意识到会话历史膨胀才是卡顿的最大凶手。后来我把“及时开新会话”和“精简任务描述”这两个习惯养成之后，哪怕是相同的硬件、相同的模型，体验都比之前好了不只一档。所以如果你现在正被卡顿折磨，我的建议是：先别急着换模型，把你当前的会话上下文检查一下，把 keep_alive 和上下文窗口参数对一对，效果往往会出乎意料。

最后再分享一个小技巧：每次调优完，都顺手在 Roo Code 里发起一轮复杂的多文件修改任务来压测，别只问一句“你好”就以为完事了。真实开发场景下，模型要读文件、改代码、反复确认步骤，对上下文的压力远大过日常聊天。用真实任务来检验优化效果，才是唯一靠谱的标准。