ollama部署大模型最低要求多少显卡

很多人装完 Ollama，兴冲冲 pull 一个大模型，结果要么加载到一半就失去响应，要么跑起来了但每秒钟只吐一两个词。问题通常不在 Ollama 本身，而在你手上的显卡能不能装下这个模型。这篇不讲概念，只给你一套从「我要跑多大模型」倒推到「最低要什么卡」的算法，以及装不下的时候按什么顺序降级。

很多人装完 Ollama，兴冲冲 pull 一个大模型，结果要么加载到一半就失去响应，要么跑起来了但每秒钟只吐一两个词。问题通常不在 Ollama 本身，而在你手上的显卡能不能装下这个模型。这篇不讲概念，只给你一套从「我要跑多大模型」倒推到「最低要什么卡」的算法，以及装不下的时候按什么顺序降级。

先把预期摆正：本地跑模型不是「装上了就能用」，而是要同时过显存、带宽、算力三道关。显存不够直接加载失败，带宽和算力不够则是能跑但慢到没法干活。下面按模型规模、量化档位、上下文长度三个变量拆开算，你对着自己的卡往上套就行。

先分清「跑得动」和「跑得舒服」是两件事

显存决定能不能加载，带宽和算力决定生成速度，这两个门槛要分开看。能加载不等于能用，慢到每秒一个词的任务体验上等于不可用。所以别人说「我这卡能跑」，你要追问一句：是加载成功，还是每秒出词速度能接受。这两件事对硬件的要求差得很远。

跑得动

模型权重和 KV 缓存能被完整放进显存，进程不报错、不中途挂掉

跑得舒服

加载完成后生成速度稳定在你能接受的区间，不会让你等到怀疑人生

卡在哪

加载失败几乎都是显存不够；速度慢则多半是显存刚好卡满、被迫部分卸载到内存

• 判断标准是三个变量：模型参数量、量化档位、上下文长度；三者任何一个放大，显存需求都会往上跳一档。
• 参数量是基础盘，但真正压垮显存的常常是上下文和并发，别只盯着模型名字里的数字。
• 量化档位是调节阀，档位越低越省显存，代价是输出质量下降，代码和长链推理最容易先露馅。
• 什么情况下不适用：如果你只是想偶尔试个效果、不在乎等待时间，那么 CPU 加内存也能勉强跑小模型，不必套用显卡门槛。

一个够用的口算公式：权重 + 上下文 + 余量

把总占用拆成三块相加，比直接背「多少 G 够用」靠谱得多。第一步算权重：参数量乘以每参数字节数，量化档位越低字节越少，这一项是显存开销的大头。第二步算上下文：KV 缓存随上下文长度和并发数线性增长，长上下文场景下这一项可能追上权重。第三步留余量：驱动、运行时和碎片化会吃掉一部分，实际可用显存永远比标称少。

结论要落到「总占用 = 权重 + KV 缓存 + 固定开销」这个加法上，不要只看参数量下结论。同样一个模型，短上下文单请求能跑，拉到长上下文再开几个并发就爆，这不是玄学，是加法没算全。具体每项怎么估算，去站内硬件术语页把口径对齐以后再套数字。

按量化档位分档：每档对应的可用显存起点

量化档位本质上是在用输出质量换显存。同一模型，高精度档位画质损失最小但占用最高，适合显卡有余量、追求输出稳定的场景；中等量化档位是日常本地对话和知识库问答最常选的一档；低位量化档位门槛最低，但长链推理和代码类任务更容易出现明显退化，属于能跑但别指望好用。

实际选档的时候别一上来就拉满精度，先用中等档位跑通流程，确认任务能接受再考虑升档。反过来，如果只是为了验证某类任务本地能不能做，低位档位就够了，没必要为一次实验上大卡。

• 高精度档位：适合显卡显存明显富余、且输出质量不能打折的场景。
• 中等量化档位：日常对话和知识库问答的默认落点，质量与占用的平衡点。
• 低位量化档位：显存门槛最低，适合先跑通流程再决定要不要升级硬件。
• 对照表不要抄固定数字，去 /models/deploy 按当前模型和量化档位算一遍。
• 如果同一任务换个档位结果差别很大，说明这个任务对质量敏感，别硬压档位。

显卡档位怎么对：从集显到多卡

把显卡粗略分几档，你就能判断自己该往哪个方向走。核显和集显基本只够跑很小的模型做验证，别指望当生产力。入门独显够跑中小尺寸模型的中低位量化，适合个人试用和轻量知识库。中高端消费卡能覆盖主流尺寸模型的常用量化档位，是本地部署的常见落点。双卡或多卡能把显存叠加，但要注意 Ollama 的多卡切分策略和卡间通信开销，不是简单加总。

具体型号的边界，别信传言，去看站内按显卡整理的实测记录，同一张卡在不同量化档位下的表现差别不小。判断标准很简单：你算出来的总占用小于卡的可用显存，且留出余量，才算稳妥。

上下文和并发：最容易被忽略的第二笔账

上下文开得越大，KV 缓存占用越高。把上下文从短档位拉到长档位，显存可能直接翻倍，这是「昨天还能跑今天就爆显存」的常见原因。并发数会按倍数放大 KV 缓存，个人用保持单请求即可，多用户共用要按并发预留。排查顺序是：先看上下文设置，再看并发，最后才怀疑量化档位选错。

如果你在做长文档问答或者多人共用的内部工具，这两项必须提前算，不能等上线了再调。估算方法可以参考站内关于显存与并发估算的页面，把上下文长度和并发数输进去看总占用的跳变。

1. 确认业务上下文长度把实际输入的最长文本量出来，别用默认值拍脑袋；这一步决定 KV 缓存的基础量级。
2. 确认同时使用人数个人用保持单请求；多用户按峰值并发预留，否则高峰期会排队甚至失败。
3. 按估算页算总占用去 /gpu-vram-concurrency-estimate 输入上下文和并发，看总占用是否踩过显存红线。
4. 留出余量再上线算出来的占用要明显小于可用显存，余量不足就先缩上下文或降并发，而不是硬扛。

装不下时的降级顺序（照这个顺序试）

显存不够的时候，按顺序试比乱调参数高效得多。第一档换更低的量化档位，代价是输出质量下降，适合先跑通再说的场景；第二档换更小的参数量模型，这一步收益最直接，很多任务小模型也够用；第三档缩上下文、关并发，把省下来的显存还给权重；第四档 CPU 卸载，把部分层放到内存，速度会明显变慢。

完整清单见 /vram-optimization-guide。如果四档都试完还是不行，说明该换硬件或者改成调 API，而不是继续折腾参数。判断什么时候该放弃：当降级已经影响到任务正确性，或者速度慢到无法完成工作时，本地部署这条路对当前需求就不合适了。

落地动作：装之前和装之后各做一次检查

装之前先把需求写清楚，再对着站内页面核对，别先买卡再找模型。装之后跑一次基线测试，记录加载耗时和生成速度，作为以后调参的参照。长期观察显存水位，判断还剩多少余量，别等到某天突然爆了才发现没留缓冲。

1. 装之前确认需求先确认业务的上下文长度和是否要并发，再去 /models/deploy 和 /compute/sizing 里对一遍模型与硬件的匹配。
2. 装之后跑基线用 /tools/speed-test 之类的工具跑一次，记录加载耗时和生成速度，作为后续判断「变快了还是变慢了」的基准。
3. 长期看显存水位定期记录运行时的显存占用，判断还剩多少余量，判断口径参考 /vram-usage-normal-check。
4. 不合适就换路线如果检查下来始终贴着红线跑，说明硬件和任务不匹配，改小模型或改用 API 比继续调参划算。

不适用的情况也说清楚：如果你只是做一次性实验、用完就删，可以跳过基线测试这一步，跑通就行。但只要这个本地服务要长期用，基线这一步就别省，后面每次调整都需要它当参照。