q8_0 缓存值得开吗？

处理长文档和代码时，通常值得：缓存所占的那部分显存能多装大约一倍的上下文，而且 Ollama 自己的文档说它的精度损失很小。`q4_0` 能开得更长，但损失更大，上下文越长越明显，所以要先在你自己的任务上试过再依赖它。

为什么显存还有剩余，模型却停在"满窗口"？

因为那是模型训练或配置支持的最长上下文；本页从不按超过模型自身窗口的长度来计算。运行时也许允许你设得更长，但模型并不是为此设计的，超出窗口后回答质量会下降。

llama.cpp 默认会开这么长的上下文吗？

新版 llama.cpp 在不加 `-c` 时会从模型训练时的上下文长度开始，再裁剪到显卡装得下；Ollama 有它自己的默认值。最好自己设定上下文（llama.cpp 用 `-c 32768`，Ollama 用 `num_ctx`），这样得到的是你计划的长度，而不是运行时自己定下的值。

你的显卡能开多长上下文？

最常见的几张卡上，每个推荐模型在它该下载的那一档下，能从容开到的最长上下文 —— 分别列出默认 fp16 KV 缓存，以及把缓存量化到 q8_0、q4_0 之后的结果。

每张卡列出的是本站为它推荐的模型：在聊天、代码、图像三类任务里，能从容装下的最大模型，以及只占约三分之二显存、留出余量的最大模型。每个数字都直接取自显存计算器（4K 上下文、batch 1），每一行都能以相同设置在计算器里打开。

每个数字都是保持绿色（不超过显存 88%）的最长上下文，由计算器本身逐档算出。"满窗口"表示模型自身支持的最大长度都能装下，再长模型本身也不支持。"偏紧可到"表示如果接受黄色（偏紧），还能开到多长。

RTX 5060 Ti 16G · RTX 4060 Ti 16G · Radeon RX 9070 XT

16 GB

模型	量化档位	fp16 缓存	q8_0 缓存	q4_0 缓存
Mistral Small 24B Instruct最长 32K	AWQ INT4	8K偏紧可到 24K	16K偏紧可到 32K	31K偏紧可到 32K	计算器
Devstral Small 1.1 24B最长 128K	AWQ INT4	10K偏紧可到 26K	19K偏紧可到 49K	36K偏紧可到 92K	计算器
Magistral Small 1.2 24B最长 128K	AWQ INT4	10K偏紧可到 26K	19K偏紧可到 49K	36K偏紧可到 92K	计算器
Falcon 3 10B Instruct最长 32K	Q4_K_M	32K · 满窗口	32K · 满窗口	32K · 满窗口	计算器
Gemma 4 E4B IT最长 128K	Q8_0	128K · 满窗口	128K · 满窗口	128K · 满窗口	计算器

RTX 4060 Ti 8G

8 GB

模型	量化档位	fp16 缓存	q8_0 缓存	q4_0 缓存
Falcon 3 10B Instruct最长 32K	GPTQ INT4	9K偏紧可到 17K	17K偏紧可到 32K	32K · 满窗口	计算器
Qwen3.5 9B最长 256K	Q4_K_M	17K偏紧可到 57K	32K偏紧可到 107K	62K偏紧可到 202K	计算器
Qwen3 4B Instruct最长 32K	Q6_K	23K偏紧可到 32K	32K · 满窗口	32K · 满窗口	计算器
Qwen3.5 2B最长 256K	Q8_0	256K · 满窗口	256K · 满窗口	256K · 满窗口	计算器

RTX 5070

12 GB

模型	量化档位	fp16 缓存	q8_0 缓存	q4_0 缓存
DeepSeek-V2-Lite Chat最长 160K	Q4_K_M	18K偏紧可到 81K	35K偏紧可到 153K	67K偏紧可到 160K	计算器
Gemma 3 12B IT最长 128K	Q5_K_M	14K偏紧可到 44K	33K偏紧可到 89K	70K偏紧可到 128K	计算器
Granite 3.1 8B Instruct最长 128K	Q4_K_M	31K偏紧可到 43K	58K偏紧可到 81K	111K偏紧可到 128K	计算器
Gemma 4 E2B IT最长 128K	Q8_0	128K · 满窗口	128K · 满窗口	128K · 满窗口	计算器

RTX 3090 · RTX 4090

24 GB

模型	量化档位	fp16 缓存	q8_0 缓存	q4_0 缓存
Recursive Flint 40B-A2.5B最长 256K	Q3_K_M	21K偏紧可到 157K	43K偏紧可到 256K	84K偏紧可到 256K	计算器
MiniCPM-V 4.7 35B-A3B最长 256K	Q4_K_S	15K偏紧可到 205K	28K偏紧可到 256K	54K偏紧可到 256K	计算器
ERNIE 4.5 21B-A3B最长 128K	Q4_K_M	119K偏紧可到 128K	128K · 满窗口	128K · 满窗口	计算器
GPT-OSS 20B最长 128K	MXFP4	128K · 满窗口	128K · 满窗口	128K · 满窗口	计算器
Gemma 3 12B IT最长 128K	Q5_K_M	128K · 满窗口	128K · 满窗口	128K · 满窗口	计算器

RTX 5090 · 32 GB RAM (CPU)

32 GB

模型	量化档位	fp16 缓存	q8_0 缓存	q4_0 缓存
Nemotron 3.5 Bolt 74B-A9B最长 256K	IQ2_XXS	256K · 满窗口	256K · 满窗口	256K · 满窗口	计算器
GLM-4.7-Flash最长 128K	Q4_K_M	128K · 满窗口	128K · 满窗口	128K · 满窗口	计算器
Gemma 3 27B IT最长 128K	Q4_K_M	117K偏紧可到 128K	128K · 满窗口	128K · 满窗口	计算器

模型	量化档位	fp16 缓存	q8_0 缓存	q4_0 缓存
Qwen3-VL 30B-A3B Instruct最长 40K	Q3_K_M	4K偏紧可到 33K	7K偏紧可到 40K	14K偏紧可到 40K	计算器
North Mini Code 1.0 30B-A3B最长 256K	Q3_K_M	23K偏紧可到 132K	54K偏紧可到 256K	114K偏紧可到 256K	计算器
DeepSeek-V2-Lite Chat最长 160K	Q4_K_M	160K · 满窗口	160K · 满窗口	160K · 满窗口	计算器
Gemma 3 12B IT最长 128K	Q5_K_M	91K偏紧可到 128K	128K · 满窗口	128K · 满窗口	计算器

为什么上下文会占显存

上下文里的每个 token，都会在每个保留缓存的层里留下一组 K 和 V 向量：每个 token 占 2 × 层数 × kv_heads × head_dim × 字节数。同样大小的两个模型，这里可以相差好几倍。分组查询注意力让多个注意力头共用一个 KV 头；滑动窗口层只保留固定长度的窗口；Qwen3.5/3.6 这样的混合架构只在四分之一的层里保留随上下文增长的缓存。所以同一张卡上，有的模型能开满整个窗口，同样大小的另一个模型却只能开几千 token。这里每个数字都是让计算器本身逐档计算得出的，而不是把公式倒推出来。

把 KV 缓存量化

KV 缓存不一定要用 fp16。ggml 的 q8_0 用 34 字节存 32 个值，约为 fp16 的 53%；q4_0 用 18 字节，约 28%。Ollama 的文档说，q8_0 精度损失很小，通常对模型质量没有明显影响；q4_0 有小到中等的损失，上下文越长可能越明显，具体因模型而异。两个运行时都需要开启 Flash Attention。llama.cpp 里加 -ctk q8_0 -ctv q8_0（默认的 -fa auto 会自动开启 Flash Attention）；Ollama 在服务端设置 OLLAMA_KV_CACHE_TYPE=q8_0，它会作用于加载的所有模型。

常见问题

q8_0 缓存值得开吗？: 处理长文档和代码时，通常值得：缓存所占的那部分显存能多装大约一倍的上下文，而且 Ollama 自己的文档说它的精度损失很小。q4_0 能开得更长，但损失更大，上下文越长越明显，所以要先在你自己的任务上试过再依赖它。
为什么显存还有剩余，模型却停在"满窗口"？: 因为那是模型训练或配置支持的最长上下文；本页从不按超过模型自身窗口的长度来计算。运行时也许允许你设得更长，但模型并不是为此设计的，超出窗口后回答质量会下降。
llama.cpp 默认会开这么长的上下文吗？: 新版 llama.cpp 在不加 -c 时会从模型训练时的上下文长度开始，再裁剪到显卡装得下；Ollama 有它自己的默认值。最好自己设定上下文（llama.cpp 用 -c 32768，Ollama 用 num_ctx），这样得到的是你计划的长度，而不是运行时自己定下的值。