本地跑 Ollama，很多人卡在同一类场景：单条对话挺顺，一开多请求就排队；换了个量化档位显存就爆；模型参数量和显存对不对得上全靠猜。这篇不讲原理长文，只给判断标准和可执行动作：先把限制分成并发、量化、显存三块，每一块都告诉你先看什么、改哪个参数、什么情况下这套做法不适用。
本地跑 Ollama，卡住的地方往往很集中：单条对话挺顺，一开多请求就开始排队；换了个量化档位显存直接爆；模型参数量和显存到底对不对得上，全靠猜。这篇不讲原理长文，只把限制拆成并发、量化、显存三块，每块告诉你先看什么、改哪个参数、什么情况下这套做法不适用，帮你自己判断卡在哪一步。
动手之前先记住一个前提：所有结论都要在一台固定的机器、固定的模型、固定的提示词长度上量出来才有意义。换机器、换模型、换上下文长度，之前的体感都要重新测。下面每节都给判断口径，具体数值到站内对应页面核对当时的数字，别背别人的结论。
并发这块先认清 Ollama 的定位
Ollama 面向单机本地使用，默认不是一个高并发推理服务。同时来多个请求时更像排队，而不是把算力并行分摊，第二条请求的等待时间会明显拉长。判断你要不要往上压，靠曲线不靠感觉：先量单条基线，再按 2、4、8 个并发逐级加，看首字延迟和总耗时是线性变差还是突然跳崖，跳崖点就是这台机器的事实上限。
- 量单条基线固定提示词和输出长度，用接口连续请求几条，记下首字延迟和总耗时，这就是后面所有对比的参照。
- 逐级加压并发从 2 开始翻倍往上加，每次只看两个指标：首字延迟涨了多少、总耗时涨了多少。
- 找跳崖点延迟随并发线性上升属于正常，某一档突然翻几倍就是上限到了，别再把并发数往上加。
- 调常驻与预热确认模型留不留内存、请求间隔多长，这两项比调一个并发数更能改善排队体感。
量化档位不是越低越好，先看质量掉在哪
同一模型不同量化档位，显存占用差别很大，但损失不是均匀分布的：日常对话、摘要这类任务可能察觉不到，代码、数学、长链推理掉得最明显。所以判断标准不是「哪个档位能跑」，而是「你的任务在哪个档位开始出错」。拿你自己几条真实任务，在每个档位各跑一遍，对比错漏数而不是感觉。档位含义和适用范围到 /glossary 和 /models 看当时的说明。
- 按任务类型定档：格式稳定、数值精度要求高的任务别一路降档，宁可换更小的模型
- 别混着比：中转站接口给的模型和本地拉到的权重、量化方式可能不是一回事，体感差异先排除这层再怪量化
- 长上下文任务单独测：上下文一拉长，量化带来的偏差更容易暴露
- 降档之后重跑一遍基线：质量变化和速度变化要一起看，不能只看显存省了多少
| 现象 | 大概率原因 | 先做什么 |
|---|---|---|
| 回答能听懂但代码常错 | 量化档位压得太低 | 换高一档，用同一批任务对比错漏数 |
| 聊得挺好，长文档总结丢内容 | 上下文吃紧或截断 | 缩短输入或换更小模型，不要只降量化 |
| 以为自己换了模型其实没换 | 接口和本地权重不一致 | 先确认来源和量化方式，再比较档位 |
显存不够的排查顺序，别一上来就加卡
显存问题要分三种：模型装不下、装下了但上下文吃满、碎片和缓存占着不释放。三种表现不一样——装不下直接报错，上下文吃满表现为越聊越慢或中途失败，缓存占位则只是使用率高但速度正常。排查顺序是先算权重按当前量化大概要多少，再叠加 KV 缓存随上下文增长的部分，最后留出系统和图形界面的余量。规格数字到 /models/deploy 和 /compute/gpus 对照当时的资料，别套用别人的配置。
- 先确认速度正常不正常显存使用率高但输出速度正常，多半是缓存占位，先按 /tools/speed-test 测一遍再决定要不要动手。
- 分清报错类型直接报内存错误是装不下，跑到中间失败或越来越慢更像上下文吃满，处理方向完全不同。
- 调层卸载把一部分层放 CPU 能跑起来但会变慢，这是用速度换能跑，适合偶尔用一次的场景。
- 缩上下文上下文长度直接决定缓存大小，缩它能救显存但会截断长文档，和层卸载分开权衡。
两件事不要混：层卸载影响的是每步推理速度，缩上下文影响的是能处理多长的输入。前者伤体验，后者伤功能，先想清楚你更不能接受哪一个，再决定动哪个参数。做批处理或长文档场景时，这套取舍往往意味着要换模型而不是硬调参数。
一份能照着走的自查清单
上面三块单独看都不复杂，真正容易乱的是同时改好几个变量，最后不知道是谁的锅。下面这条顺序的核心原则是一次只动一个参数，并且每次都回到同一条基线对比。
- 固定一个提示词和上下文长度，量出单请求速度基线，之后任何改动都拿它对比
- 按并发、量化、显存三块分别只改一个变量，一次改两样就分不清原因
- 先判断卡在哪一层：排队说明并发到顶，掉质量说明量化降太多，报内存错误才是显存问题
- 把结论和适用边界记下来，换机器或换模型后基线必须重新量
| 卡住的表现 | 对应哪一块 | 优先动作 |
|---|---|---|
| 第二条请求等很久 | 并发 | 测跳崖点，别再加并发数 |
| 代码和长推理变差 | 量化 | 换高一档，用同一批任务对比 |
| 跑着跑着失败或变慢 | 显存 | 先测速度，再决定缩上下文还是卸载层 |
| 使用率高但速度正常 | 缓存占位 | 不用处理，先记录基线 |
常见问题
Ollama 能扛多少并发？
没有通用答案，取决于模型、量化档位和显卡。可靠做法是自己压测：先量单请求基线，再逐个加并发看延迟曲线什么时候跳崖，那个点就是你这套配置的上限。要真做多用户服务，换支持批处理的推理框架更合适。
量化到很低的档位，为什么感觉变笨了？
量化损失不是均匀分布的，闲聊和总结往往看不出，代码、数学和多步推理最容易掉。用你自己的真实任务在不同档位各跑一遍，比错漏数而不是比感觉；精度要求高的任务别硬降档。
显存报错了，是不是只能换显卡？
先按顺序排：是权重装不下、上下文吃满、还是缓存碎片。可以试缩上下文、把部分层卸载到 CPU、降量化档位，代价分别是截断长文本和变慢。只有这些都试过还不行，才谈换卡或租卡。
