文档比显存允许的上下文还长怎么办？

三条路：换滑窗架构模型、把 KV 量化到 q4、或者分块检索只把相关段落塞进去。别指望把 -c 调到 128K 就解决了。

先看显存账。以 16G 卡（可用约 14.1G）跑 14B Q6_K（权重 11.48G）为例，剩 1.6G，能开约 10.7K token；同一张卡跑 GLM-4-9B Q8（权重 9.56G）剩 3.5G，因为只有 2 个 KV 头，能开超过 22K。想读更长的文档，先考虑换 KV 便宜的模型，这比换卡便宜。

第二个杠杆是 KV 量化。把 -ctk/-ctv 设 q4_0，KV 直接变 1/4，上面 14B Q6_K 的 1.6G 余量等效变成 6.4G 可用，能开的上下文翻 4 倍。代价是长程细节召回会有损失，重要场景请自己 A/B 测一下。

第三个杠杆是别把全文塞进去。分块检索（先按关键词/小模型筛出相关几段，只把这几段放进上下文）是工程做法，它把『上下文长度』问题变成了『检索质量』问题。多数读文档的需求，8K 精准上下文比 64K 全文效果好。

注意模型原生上限这一硬约束：Phi-4 只有 16K，GLM-4-9B 只有 32K，Qwen3 系列是 40K。显存够也不能超过它；想开超过原生上限需要额外的 rope 缩放设置，属于超纲使用，本站不给这类结论。