ollama run llama3 太慢

在 Ollama 里跑 llama3，最常遇到的不是跑不起来，而是能跑但慢得让人放弃：一句话等半天，长回答还会卡住。多数时候不是模型不行，而是显存装不下、量化档位选错、或者参数把资源耗在来回搬运上。这篇给一套从看现象到动手改的排查顺序，让你知道先动哪个开关，什么情况下该换模型而不是继续调参。

在 Ollama 里跑 llama3，最常遇到的不是跑不起来，而是能跑但慢得让人想放弃：问一句话等半天，回答一长还卡住。多数时候不是模型不行，而是显存装不下、量化档位选错，或者参数把资源耗在来回搬运上，白白拖慢了速度。

下面这套顺序是给普通本地环境用的：先看清是哪种慢，再对显存挑量化档位，然后按固定优先级调参数，最后才判断要不要换模型或换机器。每一步都给出验证方式，改完能对比出有没有用，而不是凭感觉乱试。

先分清是哪种慢，别一上来就调参数

慢有好几种：有的是一开始就没动静，有的是吐字像挤牙膏，还有的是开头挺快、聊到后面越来越卡。前两种基本是加载和显存问题，第三种多半是上下文越堆越长，或者显存被别的进程悄悄抢走了。

• 先记基线：Ollama 自己会报 token 生成速率，动手前先把当前数字记下来，改完才有得对比，接口层面的延迟基线可以到 /tools/speed-test 对齐
• 看有没有 CPU 回退：显存装不下时，模型会被拆到内存和 CPU 上跑，速度往往掉一个数量级，用系统工具盯住显存和内存占用就能看出来
• 分清首字慢和吐字慢：首字慢通常是模型加载或换入换出，吐字慢才更多跟量化档位和算力有关，两者处理方式不一样

量化档位对上显存，是最省事的一步

同一个模型有好几个量化档位，档位越低越省显存，但质量损失也越明显。先按你手上的显存反推能装下哪一档，比反复试参数快得多。判断口径很简单：模型权重加上上下文缓存再加一点余量，能不能整个塞进显存；塞不下就会卸载到内存，这才是很多人觉得慢的根因。

还有一点：同参数量的低比特量化版本，往往比高参数量高比特版本跑得更快，效果也不一定差，别死盯着最大的那个模型名不放。具体每档的显存要求和质量对照不写死在文章里，到 /models/deploy 按当前模型和卡型自己算一遍，术语不清楚再去 /ai-dict/category/tech 对一下。

参数调整的先后顺序与常见坑

参数不是改得越多越好，顺序错了会白忙。建议从影响最大、最容易回退的地方下手，一步步验证，别一次动好几个开关，否则出问题都不知道是谁干的。

1. 先压上下文长度把对话历史砍短，只保留最近几轮，长文档先切片再喂，不要整份文件直接丢进去。验证方式：看吐字速度有没有回升，回升明显说明就是上下文吃显存。
2. 再限制并发同一时间只放一个请求进来，多个请求抢显存会互相拖慢。验证方式：单请求速度应该更稳，波动变小。
3. 最后动底层开关常驻内存能省掉重复加载时间，但会一直占着显存；机器还要干别的活时就别开，按使用频率决定。卸载层数、上下文档位这类偏底层的参数放最后调。

调到头还是慢，该换思路而不是继续抠参数

先把量化档位和参数这两个低成本动作做完，如果还是达不到要求，就说明这台机器的上限摆在那里，继续抠参数边际收益很低。这时候该判断的是：瓶颈在生成速度，还是任务本身太重。让模型做长链推理、生成大段代码，天然就慢，换更小的模型或把任务拆开往往更有效。

• 确认瓶颈位置：是单纯的生成慢，还是任务设计得太重，两种情况解法完全不同
• 横向试结构：同尺寸下不同模型结构速度差别不小，试几个再定，可到 /inference 对照开源模型的规格与比价
• 评估换方案：对延迟有硬要求时，考虑换卡或走按量接口，选型账参考 /compute/sizing 和 /compute/tco，数字以页面当时为准
• 判断原则：低成本动作做完仍不达标，再考虑硬件或方案切换，别一上来就加钱

判断标准可以更直接一点：如果你的任务本身就需要长上下文加复杂推理，那本地这台机器注定吃力，与其调参不如换任务切分方式；如果只是日常问答还是慢，那问题基本还在显存和量化这一层。