梦行志12G 本地推理生产线 ④ 32K 墙是怎么死的：死旋案 + KV 流式 + 128K 窗口决策
回答塌缩 160/93/73/48/29 的死旋案复盘，KV 流式 99.96% 命中实测，窗口扩张的完整账本依据
12G 本地推理生产线 ④ 32K 墙是怎么死的：死旋案 + KV 流式 + 128K 窗口决策
两种"上下文满了"，一种真死，一种是设计
真死（窗口截断）：32K 版（--max-context 32768）下，agent 会话 prompt 涨到 32.4–32.7K 时，剩余可生成空间只剩几百 token，回答逐条塌缩：160 → 93 → 73 → 48 → 29 tokens，且引擎日志 the reply reached max tokens while still thinking, so it has no answer 反复出现。表现像"模型变笨了/卡住了"，实际是物理空间耗尽——这就是"32K 墙"。
设计行为（会话累满）：--max-context 131072 的长会话，prompt 逐步逼近 128K 时，剩余"想 + 答"空间自然塌缩，引擎 thinking capped。这是设计内的软着陆，开新会话即可，不是故障。排障时两者务必分清——死旋塌缩看 prompt 绝对值，累满看会话累计量。
为什么升到 131072（128K）
- agent 长会话实测在 31K 撞墙（剩余 max_tokens 357→183→95），需求直接顶到 130K
- 同卡先例：官方 IQ2_XS 自安装起就跑 131072 两周多无事故；SC117-IQ2_XS 版还有单段 33,788 token 长生成（prompt 33.6K，6.8 分钟）@ 83.1 t/s 的纪录——128K + 无 mmap 这条路在本卡被验证过
- RAM 账最坏口径：32G pinned 专家预算 + 1.8G 全量 131K KV（安装日志实测
KV cache lives in RAM (1.8 GB)）+ 系统 8–10G ≈ 50–53G / 62G，过线
KV 的真实行为：驻留 + 流式，不是"全在显存"
131K 版的 KV 配置是 --kv int8 + --kv-resident 8192。两个反直觉实测：
引擎 clamp：给 8192，引擎实际按 20480 cells 驻留 VRAM（K/V streaming: 20480 cells in VRAM），超出驻留的部分流式走 pinned RAM，逐请求：
KV streaming: 99.96% of 4536 block reads hit VRAM, 190–224 MiB read from RAM也就是说：热 KV 在显存、冷 KV 在内存，读放大被流式层吸收，99.96% 命中率下对速度的侵蚀很小（D 版 42 t/s 就是含流式的数字）。
int8 vs q4_0：KV 量化位数再降一档（q4_0）能省一半 KV 的显存/内存占用，代价是长窗口远端的检索质量下降。写作/长会话场景不选 q4_0——它的正确用法是 VRAM 真的挤到拒启时的急救杠杆，不是日常配置（触发条件见第 1 篇基线表的注解）。
128K 版的验收数字（干净环境）
| 项 | 值 |
|---|---|
| 启动 | ready: context 131072 tokens, images on |
| expert cache | 1045 experts / 2.02G（reserve 1500 版）→ 955 / 1.84G（reserve 1728 版，第 3 篇） |
| 长生成 | 14,095 tokens @ 42.1 tok/s（命中 63.2%）；2,029 tokens @ 29.9（prompt 16.5K，对话增长的自然降速） |
| 3 条大生成 | 7,396 / 9,018 / 8,127 @ 39.1 / 42.1 / 43.1 t/s，命中 47–54%，无 #2065 警告 |
| host RAM | 46–48G 稳定，无 swap 风暴、无 exit -9 |
结论：128K 在这台机器上不是"撑一撑"，是常规工况——只要三维账本（第 2 篇）列平、启动环境干净（第 3 篇），余量 10 万+ token，32K 墙从此不存在。
下一篇：量化位怎么选——速度梯队就是量化梯队。