OpenClaw 对接 Ollama 时，模型版本选错，最直接的表现往往不是立刻报错，而是模型加载到一半被系统杀掉、推理速度骤降，或者上下文窗口稍微调大就显存溢出。这个问题本质上不是模型参数量一个数字决定的，而是显存容量、量化精度和上下文长度三者共同作用的结果。只有先估算实际显存占用，再结合显卡档位做选择，才能让本地模型在 OpenClaw 中稳定运行。
一、先搞清楚显存到底被什么占用
Ollama 运行模型时的显存占用由三个部分组成：权重本身、推理时的激活值、以及 KV 缓存。权重占用是最主要的部分，它直接由参数量和每个权重占用的字节数决定。一个参数如果使用 FP16 精度存储，需要 2 字节；使用 8-bit 量化需要 1 字节；使用 4-bit 量化只需要 0.5 字节。7B 模型在 4-bit 下，仅权重约 3.3GB，在 FP16 下约 13GB，差距非常明显。
def estimate_model_gb(params_billions, bits_per_weight):
bytes_per_weight = bits_per_weight / 8
weight_gb = params_billions * 1_000_000_000 * bytes_per_weight / (1024 ** 3)
return round(weight_gb, 2)
print(estimate_model_gb(7, 4)) # 7B 4-bit 约 3.26GB
print(estimate_model_gb(14, 4)) # 14B 4-bit 约 6.52GB
print(estimate_model_gb(70, 4)) # 70B 4-bit 约 32.61GB
真实运行中，不能只看权重数字。Ollama 还要为 CUDA 上下文、临时缓冲和 KV 缓存留出空间。以 7B 模型 4-bit 量化、4096 上下文为例，实际峰值显存通常比纯权重大 1GB 到 2GB。如果上下文长度增加到 32768，KV 缓存会线性增长，可能额外吃掉数 GB，甚至超过权重本身。因此选择模型版本时，先按纯权重乘以 1.2 到 1.4 的系数估算总占用，是比较安全的做法。
Ollama 的量化标签也直接反映体积差异。q4_0 体积最小、速度最快，但生成质量略低；q4_K_M 体积稍大，综合效果更均衡，是多数场景的首选；q5_K_M 和 q6_K 质量更高，但需要更多显存；q8_0 则接近原始精度，体积明显增大。看到模型名时不能只看 7B、14B、70B 这些数字，还要把量化标签一起纳入估算。
二、不同显存档位对应的模型选择
实际选择时可以按可用显存而不是显卡标称显存来判断，因为系统桌面、浏览器和其他进程也会占用一部分显存。一般建议在标称显存基础上预留 1GB 到 2GB 余量，再把剩下的空间用于模型。下面是常见显存档位下的参考选择。
| 可用显存 | 推荐模型版本 | 说明 |
|---|---|---|
| 6GB - 8GB | 3B/4B 的 q8_0，或 7B/8B 的 q4_K_M | 7B q4_K_M 需要控制上下文长度，日常短文本够用 |
| 10GB - 12GB | 7B/8B 的 q6_K，或 13B/14B 的 q4_K_M | 14B q4_K_M 在 12GB 显存下基本可稳定运行 |
| 14GB - 16GB | 13B/14B 的 q6_K，或 32B 的 q4_K_M | 16GB 是本地模型比较舒服的区间 |
| 20GB - 24GB | 32B/34B 的 q4_K_M、q5_K_M | 优先保证余量，70B q3_K_M 虽能加载但不建议长期使用 |
| 40GB 以上 | 70B 的 q4_K_M 或更高 | 可以同时放开较大的上下文窗口 |
对于 8GB 显卡，首选 7B 或 8B 的 q4_K_M 版本。如果 OpenClaw 中经常需要长文档处理，可以降到 3B 或 4B 的 q8_0，换取更大的上下文窗口。12GB 显存可以尝试 14B 的 q4_K_M，但上下文最好控制在 4096 到 8192。16GB 显存则可以比较从容地使用 13B/14B 的 q6_K，或尝试 32B 的 q4_K_M。
24GB 显卡建议优先考虑 32B 或 34B 的 q4_K_M、q5_K_M，这类模型在 OpenClaw 做代码补全、指令跟随时表现更稳。70B 的 q3_K_M 虽然可能加载成功，但余量太少，一旦上下文拉长或并发请求增加，很容易触发显存不足。48GB 及以上再考虑 70B 的 q4_K_M，或者为更强模型留出更大上下文空间。
三、OpenClaw 中的实际配置方式
在 OpenClaw 中对接 Ollama，通常有两种方式：一是通过 OpenAI 兼容接口连接本地 Ollama 服务，二是在模型列表中直接选择 Ollama 已拉取的模型。无论哪种方式，最终都要指定模型名称和上下文长度。模型名称中的冒号后面就是版本标签，例如 qwen2.5:7b-instruct-q4_K_M，标签里的 7b 表示参数量，q4_K_M 表示量化方式，这两部分必须同时关注。
ollama pull qwen2.5:7b-instruct-q4_K_M ollama run qwen2.5:7b-instruct-q4_K_M --num-ctx 4096
如果显存紧张，可以在启动模型时通过参数限制上下文和并行请求，避免瞬时显存峰值。比如把 num_ctx 设为 4096，并将 num_gpu 设为 -1 表示尽量把层放进 GPU。如果模型大于显存，Ollama 会自动把一部分层放回内存，但这会明显降低推理速度。OpenClaw 的配置文件中也可以写清 base_url、model 和 num_ctx，含义与 Ollama 原生参数一致。
{
"provider": "ollama",
"base_url": "http://127.0.0.1:11434/v1",
"model": "qwen2.5:7b-instruct-q4_K_M",
"num_ctx": 4096
}
配置完成后，可以先发送一条短消息测试响应速度。如果首 token 等待时间明显过长，或系统内存占用异常升高，说明模型层没有完全加载到显存。此时优先降低上下文长度，再考虑更换更小量化版本，而不是直接切换成一个过大的模型。OpenClaw 对本地推理的稳定性要求较高，留出显存余量通常比追求更高参数量更划算。
四、常见误区和排查方法
第一个常见误区是把参数量当成唯一标准。14B 的 q4_K_M 与 13B 的 q8_0 相比，显存占用可能差不多，甚至后者更高，因为 q8_0 的每权重字节数是前者的两倍。所以只比较数字大小没有意义，必须把量化标签一起看。第二个误区是忽略上下文长度。很多人只在拉取模型时看了体积，却没有限制 num_ctx，导致默认长上下文时 KV 缓存把显存占满。OpenClaw 中如果出现加载成功但一提问就崩溃，多半与此有关。
nvidia-smi ollama ps
如果 nvidia-smi 显示显存已接近上限，而 ollama ps 显示模型已部分使用 CPU，说明当前模型超出显存能力。可以降低量化级别、减少上下文，或者直接选择更小的模型版本。如果显存占用不高但响应慢，可能是模型本身推理速度受限，或 GPU 不支持某些高效算子，这时更换为同参数量下更通用的 q4_K_M 版本通常更稳妥。
还有一种情况是 OpenClaw 同时运行多个本地任务，比如代码补全、文档摘要和对话代理并发执行。单个模型跑得动，不代表并发场景下仍然稳定。并发请求会同时占用 KV 缓存和临时缓冲，峰值显存可能比单次请求高出很多。遇到这种问题，优先降低 OpenClaw 中的并发数量，或者为本地服务单独配置一个更小的模型实例。
OpenClawOllama本地模型显存选择修改时间：2026-08-29 23:14:17