1. 先承认一个事实本地模型卡顿九成不在模型算力我最初把 Roo Code 接到本地模型时踩过一个大坑换了个 24G 显存的机器跑 Qwen3-30B-A3B自认为配置拉满了结果打开 Roo Code 试了两个任务——第一个任务还行第二个任务开始疯狂转圈输出断断续续甚至点一下界面要等两三秒才有反应。当时我的第一反应是模型太弱、显卡带不动。直到我把整个调用链路拆开看了一遍才发现模型本身每秒吐 token 的能力并不差真正拖垮体验的是上下文塞太满、服务端并发抢显存、编辑器 UI 渲染跟着添乱这三件事叠在一起。这篇文章就围绕 Roo Code 调用本地模型LM Studio、Ollama 都适用的卡顿问题把我实际排查和优化过的方案完整写出来。内容适合已经在用 Roo Code 接本地模型、但觉得能用但不流畅的人也适合准备从 Cursor 或 Claude Code 切到本地模型、担心体验落差的人。最终目标很明确让本地模型在 Roo Code 里的响应体感尽量接近你原来用云端 API 时的原生速度。1.1 卡顿现象拆解你感受到的慢是哪一种慢先说一个很容易被忽略的点卡顿不是一种现象而是至少四种现象的混合体。不把它们区分开后面的优化就是在盲人摸象。首 token 延迟高你发出指令后界面半天没动静好几秒后第一个字符才冒出来。这类问题十有八九是上下文 prefill太慢或者模型服务端正在处理别的请求。生成速度低第一个 token 出来之后输出以每秒三五个字的速度爬行甚至比人打字还慢。这通常是显存爆了、部分层掉到 CPU 上推理或者量化档位选得太激进。输出中断与自动重试生成到一半停住然后 Roo Code 重新发起请求表现为对话反复转圈。这类问题通常在超时配置和服务端并发上。UI 整体黏滞不光输出慢连展开侧边栏、滚动 diff 都卡。这就是编辑器渲染线程的问题了和模型推理不在同一个环节。我建议你下次遇到卡顿时别急着调参数先按下 F12 打开 Roo Code 的输出面板看看它到底卡在哪一步是 API request 阶段花了 8 秒还是 streaming 阶段每秒只有 3 个 token。能定位到这一步优化方向基本就定了。1.2 一条请求从 Roo Code 到本地模型要路过五道门为了方便理解和排查我把一次请求的完整路径拆成五段。这五段里任何一段出问题你感受到的都是Roo Code 好卡但它们的修法完全不同。环节作用常见卡顿原因排查手段①上下文拼装Roo Code 把系统提示词、文件内容、对话历史拼成 prompt上下文太长、系统提示词臃肿、MCP 工具结果过大看请求日志中 prompt 字符数②HTTP 传输与排队请求发到本地服务端服务端可能正在忙服务端并发处理中、超时设置过短观察服务端日志的排队时长③Prefill 阶段模型对 prompt 做预填充建立 KV cache上下文过长、Flash Attention 未开启统计 TTFT首 token 时间④Decode 阶段模型逐 token 生成显存溢出、量化过激进、生成速度低观察 tokens/s 指标⑤UI 渲染流式输出、diff 高亮、日志面板刷新Electron 渲染线程过载、扩展日志刷屏切到小任务观察界面流畅度你可能会发现本地模型的 decode 速度再快只要上下文拼装阶段塞了几万个 token 的旧文件prefill 时间就会暴涨。这就是为什么很多人换了更大的显存、更快的显卡卡顿依旧——问题不在生成速度而在每次请求前那段漫长的上下文预处理。1.3 判断基线什么是原生速度值不值得追我说的原生速度不是要本地模型跑得比云端 API 还快——本地模型在单 token 生成速度上确实可能被云端大模型吊打但交互体验上完全能做到无感知延迟。拿我自己的量化标准来说首 token 延迟300ms 到 1.5s 以内属于流畅超过 3s你就会有卡住的错觉。生成速度20 token/s 以上是及格线30-50 token/s 基本能媲美云端接口的吐字速度。UI 交互输出过程中你还能正常滚动代码、切换文件而不是整个界面一起僵住。在动手之前先把这几个数字刻在脑子里。后文所有优化最终都是为了逼近这个标准。这套标准和云端 API 最大的区别在于云端 API 的瓶颈往往在网络延迟和限流而本地模型所有环节都在你手里每个瓶颈都有对应的旋钮可以拧。2. 动手前必看的四个健康指标先定位再优化很多人一上来就换模型、换量化档结果越换越懵。我的习惯是先在服务端和系统层把四个指标拉出来看一眼花五分钟定位再决定动哪里。磨刀不误砍柴工。2.1 指标一首 token 延迟——决定有没有卡住的错觉首 token 延迟TTFT是你的指令发出后到第一个 token 出现在屏幕上的时间。它包含了网络请求、服务端排队、以及最重要的 prefill 计算。在 LM Studio 的服务端日志里每个请求都会打印类似 prompt tokens: 8245, eval time: 1.2s 的信息Ollama 可以用ollama ps查看模型加载状态日志里也有 eval 耗时。实测下来相同模型下8K token 上下文的 prefill 大约需要 1-1.5 秒但如果上下文膨胀到 16K、32Kprefill 会线性恶化到 3-6 秒。所以第一准则就是上下文温度Context Window不是越大越好而是够用就好。如果 Roo Code 每次调用都塞进去几万 token 的仓库文件你换什么显卡都救不回来。后面第 4 节我会给出控制上下文的具体策略。2.2 指标二生成速度——持续输出时的真实吞吐生成速度Decode Speed反映的是模型进入逐字输出阶段后每秒能吐多少 token。这个数字直接决定你看到代码一行行蹦出来的速率。用 LM Studio 的话界面上会实时显示 tokens/sOllama 的每个请求日志末尾也会打印 eval rate。我有一个 4070 12G 的机器跑 Qwen3-8B Q4_K_M大概 45 token/s跑 Qwen3-30B-A3B 时如果显存刚好能塞下大概 25 token/s但如果显存溢出掉到 CPU 上跑立刻掉到 3 token/s——这就是最典型的输出一半卡死场景。看生成速度时要注意它和 TTFT 是两回事。有时生成速度明明很高但界面表现为等半天才开始动那是 prefill 的问题有时首 token 很快但后半段越来越慢那就要查温度过高导致的显存降频以及 KV cache 是不是已经堆满了。2.3 指标三显存与内存换页——卡顿的最大元凶显存占用是本地模型卡顿的头号嫌疑犯而且它有个很迷惑人的特性任务管理器里显示GPU 内存用了 90%但你以为还没爆结果模型服务端已经开始把层卸载到 CPU 了。llama.cpp 系的服务端LM Studio 和 Ollama 底层都是它在显存不足时会静默地把部分计算层放回 CPU你的生成速度会断崖式下跌而且界面不会有任何红色警告。Windows 下打开任务管理器切到性能页看专用 GPU 内存那一栏Linux 下用nvidia-smi看显存占用。我建议设置一个底线显存占用不要超过 85%超过就换更小的量化档、减小上下文、或者减掉同时加载的模型数量。宁可牺牲一点模型智商也不能让它溢出到内存。内存换页比显存推理慢十倍不止那种输出到一半畜力卡住的体验多半都是它引起的。2.4 指标四UI 线程与渲染——你的编辑器在掺和什么最后这个指标最隐蔽。模型推理是在显卡上做的但 Roo Code 是跑在 VS Code 的 Electron 渲染进程里的。如果你的扩展面板在输出时疯狂刷新日志、diff 视图在高亮渲染一个几千行的代码补丁UI 线程就会被抢占导致界面点哪里都没反应。我之前就遇到过一个假卡顿模型生成速度正常但每次输出时侧边栏看起来像 PPT 一样一卡一卡的。后来发现是 Roo Code 的日志输出面板开了 verbose 模式服务端每吐一个 token 它都在刷屏渲染。把日志等级调回 info、关掉派发面板的持续输出之后UI 立刻恢复丝滑。Windows 用户还要多留意一个点很多笔记本默认把 VS Code 的 Electron 进程分配到核显上渲染。打开系统设置里的显示卡找到 Code.exe 和所有 electron 相关的进程手动指定为高性能独显运行。这个操作看着和模型无关实际对 UI 流畅度的影响非常明显。3. Roo Code 这边的配置别让工具链拖后腿服务端再快Roo Code 这边配置不对体验照样稀碎。这一节讲的是客户端侧的优化每一项都不难但很容易被忽略。3.1 在 Roo Code 里配置本地 API 的正确姿势Roo Code 支持 OpenAI 兼容接口所以接本地模型不需要什么特殊魔改。在扩展设置的 API Provider 里选择 OpenAI CompatibleBase URL 填 LM Studio 的http://127.0.0.1:1234/v1或者 Ollama 的http://127.0.0.1:11434/v1模型名填你本地服务端实际加载的模型名。这里有一个容易踩的坑模型名必须和服务端完全一致。LM Studio 这边是下拉菜单选择Ollama 那边要用ollama list看到的完整名称比如qwen3:14b填qwen3有时候会报 404。另外本地模型没必要填 API Key随便填个local占位就行但别留空某些版本留空会导致请求校验不过。还有一点要注意Roo Code 的请求超时设置。云端 API 通常秒回默认超时设置短没问题本地模型在做长上下文 prefill 时冷启动可能花五六秒如果超时设置太短Roo Code 会自行中断并重试看起来就是输出到一半重新转圈。把超时时间调大到 300 秒以上能减少很多误判。3.2 关闭日志与自动重试让请求队列变干净Roo Code 在运行时会输出大量调试日志。默认的日志等级如果开着 verbose每个请求的细节都会刷到输出面板而输出面板在 VS Code 里走的是 UI 渲染线程——你模型跑得再快界面也可能被日志刷新拖死。我的做法是在 Roo Code 设置里把日志等级从 verbose 降到 info。如果需要调试再临时开回来平时保持安静。另外如果扩展里有请求失败自动重试类选项建议调低重试次数或直接关闭。本地模型服务端本身并发的承载能力有限自动重试会在排队队列里反复插入相同请求反而把服务端拖得更慢造成恶性循环。还有一个被很多人忽略的点Roo Code 每次请求都会携带系统提示词、当前文件内容、对话历史和 MCP 工具结果。如果你挂了好几个 MCP server每个工具的返回结果都会追加进上下文。工具结果动辄几千 token几次调用下来上下文就膨胀了prefill 时间随之暴涨。所以只保留当前任务必需的 MCP 工具别一股脑全开。3.3 精简系统提示词与上下文注入本地模型和云端大模型的差距在短上下文时并不明显但一旦上下文变长本地小模型的理解能力会快速退化。所以 Roo Code 里一个非常管用的优化是主动控制注入内容的量。具体来说我一般会在 Roo Code 的自定义指令里加上一条回复尽量精炼优先给出可直接执行的代码减少冗余解释。这不光是省 token更重要的是让生成阶段集中精力输出有效代码而不是先啰嗦两句。另外Roo Code 支持把常用文件作为上下文引用文件 或 #文件建议只在必要时引用。如果你把整个项目的 README、架构文档、所有 TODO 一次性全引用进去每轮对话都要 prefill 一遍这些内容——这是本地模型卡顿的隐藏大头。宁可让模型在某些细节上不知道也不要让它每次请求都背着整个项目文件夹跑。3.4 Memory Bank 与本地向量模型把记忆检索做成快路径Roo Code 的 Memory Bank记忆库功能我一开始觉得鸡肋后来发现它和本地向量模型结合起来是优化 prefill 的利器。思路很简单与其每次请求都把所有记忆文件、历史决策、技术选型记录一股脑塞进上下文不如先用本地向量模型把记忆库切成 chunk 并建立索引。任务开始时只检索 top-k 最相关的记忆条目注入上下文。这样上下文从一万多 token 降到三四千 tokenprefill 时间能缩短一半以上而且模型还能精准拿到它需要的历史信息。实现上不需要太复杂LM Studio 和 Ollama 都支持 embedding 模型比如 bge-m3、nomic-embed-text速度极快几乎不吃显存。你可以用一段简单的 Python 脚本做 chunk 向量化把向量存进 SQLite 或 ChromaDB然后通过一个轻量 MCP 工具给 Roo Code 提供检索能力。这个玩法顺带解决了一个很多人头疼的问题本地模型记性差。不是模型记性差是你每次都把记忆全部塞给它反而把最相关的部分淹没了。4. LM Studio / Ollama 服务端的提速策略把推理吞吐拉满客户端再怎么精简服务端的推理速度和显存调度才是根本。这一节我把两个主流服务端的核心参数讲透先讲原理再给配置。4.1 显存调度GPU Offload 与 KV Cache 量化的取舍LM Studio 的模型加载界面里有一个GPU Offload滑块决定多少层放到显卡上。很多人把它拉到 100%觉得这样最快。实际上如果模型总大小 KV cache 上下文缓冲超过了显存容量服务端会自动压缩或者换出速度掉得比调到 95% 还狠。更稳的做法是让模型权重刚好能大部分驻留显存预留一部分显存给 KV cache。以 16G 显存为例跑一个 Q4 量化的 14B 模型权重约 9G再给上下文留 4-6G 的 KV cache 空间剩下给系统和其他进程这是比较健康的配比。这样模型推理和上下文缓存都在显存里完成不碰内存。KV cache 也支持量化。LM Studio 里可以把 KV cache 量化到 Q8_0 甚至 Q4_0精度损失很小但显存占用能省一半。开启这个选项后很多原本只能跑 8K 上下文的显存可以跑到 16K 甚至更多。注意上下文需求大的任务KV cache 量化的收益比换更小模型还明显。4.2 模型选型为什么同是 32BMoE 比 Dense 更适合写代码模型选型对体验的影响比大多数人想象的大。同样是 30B 级别的模型Dense稠密架构每次生成都要激活全部参数MoE混合专家架构只激活一小部分专家。在消费级显卡上这意味着天壤之别。我实测过Qwen3-30B-A3BMoE激活 3B 参数在 12G 显存的卡上用 Q4 量化可以跑到 20-25 token/s而同样规模的传统稠密模型的文生速度通常只有个位数。这就是为什么我会对想跑大模型但显存不够的朋友优先推荐 MoE 模型。它的短板是 prefill 阶段——因为专家路由机制首 token 延迟会比小模型略高但只要你把上下文控制好整体体验远胜于硬跑一个稠密大模型。当然MoE 也不是万能。如果显存只有 8G老老实实跑 Qwen3-8B 或 Llama 3.1 8B 更好至少能保证全量驻留显存。盲目上 30B 的 MoE 如果塞不下被挤到 CPU 上体验照样拉胯。4.3 采样参数与上下文长度调错了速度翻倍也没用很多人优化只盯着速度忽略了采样参数对有效速度的影响。本地模型的 temperature 如果设得偏高模型会频繁生成废话、重复内容甚至跑偏到无关话题看起来 token 在吐实际上有效代码没多少。我通常把 Roo Code 里本地模型的 temperature 设在 0.1-0.3 之间top_p 设在 0.9 左右。这个区间的代码生成质量明显更稳也减少了因为答非所问而被迫再来一次的次数。这里还有一层关系本地小模型的长处是遵循指令和代码补全低采样温度可以最大限度发挥这个优势。上下文长度num_ctx / context window更是关键。Ollama 的默认上下文只有 2048新版是 4096如果 Roo Code 发送的 prompt 超过这个值会被直接截断。模型读不全你的文件内容和对话历史就会开始胡言乱语你以为模型差其实是上下文被截断了。建议在 Ollama 的 Modelfile 里显式设置num_ctx 3276832K或者在 LM Studio 加载模型时把上下文拉到 16K-32K。但注意上下文开得越大KV cache 占用越高如果你的显存紧张宁可上下文开 16K 也不要让它溢出。4.4 Flash Attention 与 Prompt Cache小开关大收益在模型服务端配置里有两个小开关经常被忽略但对速度影响极大。第一个是 Flash Attention。它在计算注意力时减少显存读写prefill 阶段能快近一倍。LM Studio 和 Ollama 都支持这个选项界面上一勾就行。如果你的旧版本没有这个选项建议升级到较新版本。我用同样的模型在同样的硬件上对比过开启 Flash Attention 后首 token 延迟从 2.1 秒降到 1.2 秒效果非常直观。第二个是 Prompt Cache提示词缓存。llama.cpp 系的新版本会对重复的 prompt 前缀做缓存比如你的系统提示词、项目说明这些每次请求都相同的部分第二次请求时直接复用它们的 KV cache不用重新计算。在 LM Studio 里这是一个单独的缓存开关在 Ollama 里对应OLLAMA_KV_CACHE相关环境变量。我实测在反复调同一个任务时启用缓存后请求耗时能降低 30%-40%。需要提醒的是缓存在上下文长度较大、显存剩余不足时会自动失效所以它和 KV cache 量化一样需要保证显存有余量才能真正发挥作用。5. 实测参数表从 8G 到 24G 显存都能照抄的配置前面讲的都是原理和方法最后我直接给出三档经过实测的配置按显存档次抄作业即可。这几个配置我在自己的机器上都跑过一遍不敢说绝对最优但至少是稳定不卡、能干活的基线。5.1 8G 显存档跑 Qwen3 8B / Llama 3.1 8B 的流畅配置8G 显存是目前很多入门玩家的门槛。这个档位不要贪大模型老老实实跑 7B-8B 级别的模型并在上下文和量化上做文章。模型Qwen3-8B 或 Llama 3.1 8BGGUF 量化 Q4_K_M 或 Q5_K_M上下文8K-16K不要开满 32KKV cache 量化Q8_0 或 Q4_0必须开Flash Attention必须开服务端并发限制为 1避免多请求争抢显存Roo Code 侧日志调 info超时调 300 秒只启用必要 MCP 工具这个配置下生成速度大概在 35-50 token/s首 token 延迟在 1-2 秒左右日常 Roo Code 写代码、改 bug 完全够用。如果你发现某个任务特别吃上下文可以临时把上下文调到 16K但注意显存占用不要超过 85%。5.2 16G 显存档跑 Qwen3-14B / 32B MoE 的平衡配置16G 是当前甜品级显卡的主流容量也是性价比最高的档位。这个容量可以比较从容地跑 14B 的全量或者 30B 的 MoE也可以把 8B 模型的上下文开到很大。模型Qwen3-14BQ4_K_M或 Qwen3-30B-A3BQ4_K_MMoE上下文16K-24KKV cache 量化Q8_0如果跑 MoE 模型建议开 Q4_0Flash Attention必须开GPU offload14B 可以拉 100%30B MoE 建议 95% 并打开 KV 量化服务端并发1-2最多 2Roo Code 侧优先使用 Memory Bank 本地向量模型压缩上下文把这档配置的优势发挥出来实测 Qwen3-14B 在这个配置下能达到 25-30 token/sQwen3-30B-A3B 在显存刚好塞下时也有 20-25 token/s。要特别留意 30B MoE 在冷启动时的 prefill 时间会比 14B 慢不少所以上下文控制在这档尤其重要。5.3 24G 及以上跑满血模型的配置与验证方法24G 已经能跑很多 32B 的稠密模型了也能给大上下文留足空间。这个档位的玩家很容易犯一个错误觉得显存够大就把上下文拉满、模型全加载结果某些场景照样卡。模型Qwen3-32BDenseQ4_K_M 或 Q5_K_M、Qwen3-30B-A3BQ6几乎无损、甚至尝试 70B 级别的 MoE上下文32K-64K根据任务类型取舍KV cache 量化Q8_0 起步显存紧张时开 Q4_0Flash Attention必须开GPU offloadDense 32B 拉满没问题70B MoE 建议先看显存余量再决定 offload 比例服务端并发2-4Roo Code 侧可以放心引用更多文件但仍建议用向量模型做记忆检索把 prefill 时间压下来验证方法很简单跑一个中型重构任务看 Roo Code 输出面板里请求耗时和 token 速率。如果首 token 延迟稳定在 1.5 秒内、生成速度在 30 token/s 以上说明配置到位。如果还卡回到第 2 节的四个指标重新排查大概率是上下文或显存换页在作怪而不是模型本身。5.4 验证优化成功的两条硬标准配置调完怎么判断优化有没有到位我给自己定了两条硬标准不达标就继续调一是连续跑三个不同类型的任务改 bug、加功能、重构都能在首 token 1.5 秒内开始输出且中途不出现长时间停顿。如果你发现某个特定任务经常卡去查它的上下文是不是特别长或者是不是 MCP 工具返回了超大结果。二是 UI 全程不黏滞。输出过程中你能正常滚动旁边文件、操作其他面板。如果模型跑得飞快但界面僵住回头检查日志等级和 Electron 渲染相关的设置包括 Windows 图形性能选项。模型调用这条链路优化完后这部分往往是最后一个坑。我在实际操作中的体会是本地模型在 Roo Code 里的体验决定因素从来不是单点性能而是整条链路的匹配度。模型大小、量化档位、上下文长度、服务端并发、客户端日志任何一个环节失衡都会让你花不少钱买的显卡发挥不出应有的水平。上面这套流程走一遍之后我的开发主力机已经稳定在输入指令到开始输出大约一秒的状态这个体感不输给之前用云 API 的时候。最后再分享一个小技巧优化到流畅之后把当前这套配置截图或者记下来等升级硬件或换模型时对照着调整能省掉不少重新踩坑的时间。