企业官网建设流程全解析

用 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 线程数。如果你开了部分 offload，CPU 也会参与推理，线程数设太低会导致 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_PARALLEL=1、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 设备，如果你用 Ollama 在 macOS 上跑模型，记得确认是否启用了闪存注意力（flash attention），这个在 Ollama 里可以通过环境变量打开，但不同版本的默认值不一样，需要自己在日志里确认。

6. 高频卡顿问题排查速查表

很多问题都是反复出现的，我把踩过的坑整理成一张表，方便你遇到问题直接对号入座。如果对不上，再用性能监控工具去查。

排查时我的建议是：先看 ollama ps 确认模型是否加载，再跑一次 prompt 直连服务端接口计时，看延迟到底是发生在服务端还是客户端。这一步能帮你砍掉一半的怀疑对象。之后再结合图表，基本能在几次操作内定位到问题。

最后再分享一个很实用的习惯：每次调整完参数，别急着开跑真正的任务，先在 Roo Code 里发一条简单的指令测响应时间，比如"回复OK"，连续测三次取平均值。这样才能稳定对比指标，而不至于被任务本身的复杂度误导。另外建议在同一台机器上只保留一个本地推理服务进程，别让 Ollama 和 LM Studio 同时运行，两个服务抢显存抢内存带宽，看起来没冲突，实际对速度的拖累非常明显。

我自己的体会是，本地模型调优没有一劳永逸的万能配置，每次换硬件、换模型、换任务类型，至少都要重新看一遍上面的几个关键参数。但只要养成按照"服务端驻留、量化与上下文、客户端参数、系统资源"这个顺序排查的习惯，绝大多数卡顿都能在十分钟内解决。希望这篇踩坑实录能帮你省下我当初浪费的那些周末。