​实测：PPL 一字不差，256K 真能把针捞出来（4/5）​编辑​

系列文章12G 显存跑 256K 上下文。 这一篇全是数据。三组证据质量零回退、A/B 对照证明检索有效、256K 端到端跑通。一、质量PPL 回归测试62/62delta 0我的底线是不为速度牺牲质量。所以第一个要证的就是默认配置dense的行为没有被改坏。测试语料261,167 tokens62 个采样点跑ninfer-perplexity约 13 分钟。基线改造前PPL 5.639521 最终构建 PPL 5.639521 62/62 采样点bit-identical delta 0一个 token 都没变。这比数值接近强得多——bit-identical 意味着默认路径的每一个决策页分配、mask、attention 结果都与原版逐位相同。8 道锁的门控写对了不开环境变量就是原版。附这是三元模型在 nvfp4 KV 下的基线。之前测过 nvfp4 vs rk8v4 是 0.17% PPL属于另一个维度的取舍不在这次改动的账上。二、A/B 对照证明检索不是玄学环模式最容易被质疑的点是把 KV 挪到主机再搬回来模型真的还能找到信息吗于是我设计了一个三臂对照实验。同一段 60K 提示里面藏一个 needle编号BLUEBIRD-42KV 池故意压到 32K强制溢出臂配置结果Adense全部常驻✅ 答出BLUEBIRD-42B环模式不开检索✗ 答文中没有代码——但回答是通顺的、自洽的C环模式开检索✅ 答出BLUEBIRD-42三臂合起来说明了三件事A vs Bneedle 确实被降级到主机了不搬回来就找不到——证明降级真的生效不是摆设B 的失败方式很体面模型不知道的东西它说没有而不是胡编。这说明被 mask 掉的页没有污染注意力mask 安装是正确的C 找回来了IDF 词法检索 H2D 召回这条链路端到端有效。第 3 点是最关键的背书——我用纯 CPU 词法检索替代了 KVMem 原版的 mean-K 设备端打分没写一行 CUDA kernel。这个取舍被证明够用。三、256K 端到端跑通了正式配置--max-context 262144 --kv-capacity 96000 NINFER_KV_RING1 NINFER_KV_WINDOW96000 NINFER_KV_RETRIEVE12288 NINFER_HOST_PAGEABLE1启动日志​编辑1,500 / 4,096 页——设备上只住了 37% 的页剩下 63% 在主机内存里。这就是KV 池小于逻辑上下文落地的样子。152,481-token 提示的实测指标数值逻辑上下文262,144 tokens设备 KV 池96,000 tokens1,500/4,096 页提示长度152,481 tokensprefill123.5 t/sTTFT20 分 34 秒召回 needle✅答出BLUEBIRD-42显存10.2 GB / 12 GB主机 KV8 GiB pageable不占显存decode22.8 t/s多轮也过了40K×2 和 60K×2 都正确召回第 3 篇那四层修复的成果。四、性能账天花板在哪​编辑这是整个项目最有意思的发现之一。我本来怀疑是主机↔显存搬运太频繁拖慢了 decode于是做了组对照dense decode160K全部常驻 85 t/s 环模式不开检索 49.6 t/s 环模式开检索每轮换页 ~50 t/s开了检索和不开检索速度几乎一样。这直接排除了搬运是瓶颈的假设——真凶在别处注意力 kernel 里的 mask 逐块检查。环模式需要在 kernel 内判断哪些块在显存这个检查的成本随总页数4,096增长是 decode 从 85 掉到 50 的主因与检索频率无关。而传输成本实测只有约0.1%——这就是第 3 篇里我否决传输/计算重叠优化的依据优化一个占 0.1% 的环节没有意义。所以性能优化的正确靶点很明确kernel mask 快路径第 5 篇会讲。五、诊断代码全部清理开发期挂了 23 个[diag]打印验证完全部移除只在paged_kv_cache.cpp的崩溃路径保留 2 个那两个是原本就有的、用于现场取证的打印。最终二进制来自build52/build53谱系所有原型路径都有门控。下一篇最后一篇代码推到哪了、用哪个启动器、以及那些能再快一点的开关为什么还没开。系列目录112G 显存跑 256K 上下文为什么要折腾2拆掉引擎的 8 道安全锁3Windows 的坑cudaMallocHost 居然吃显存4本文实测 PPL 一字不差、256K 能召回5收尾仓库、启动器以及还没吃完的性能红利6实测续集92.68%、全绿热力图以及一个查不出的崩溃7定向优化深 decode 9%三次被测量骗的经历