一张24GB的RTX 3090，模型本体已经占去约17GB显存，测试者仍把雨果的《悲惨世界》全文塞进接近100万token的上下文，在不同位置埋下7条信息并全部找了出来。代价是整次运行耗时1805秒，约半小时。
这里运行的具体模型是ornith-1.0-35b-1M-MTP-APEX-Compact.gguf，基于Qwen 3.5 35B A3B。测试使用BeeLlama.cpp v0.4.3 preview，把ctx-size设为1048576，K和V缓存都采用kvarn4，同时开启flash-attn与kv-unified，parallel设为1，batch和ubatch分别为4096、1024。
反常之处不只是“3090能加载35B模型”。模型本体占去约17GB后，留给上下文缓存和其他运行开销的空间已经很窄；上下文越长，保存历史token状态的KV缓存还会继续膨胀。百万token真正卡住的，往往不是模型文件能不能放进去，而是这部分随文本长度增长的缓存。
KVarN压缩的正是这里。它用低比特形式保存K、V缓存，并通过Hadamard旋转和针对K、V两个方向的方差归一化，缓解量化误差在长程生成中的累积。KVarN论文报告过2-bit量化在数学、代码等生成评测中的结果，不过这次RTX 3090案例用的是4-bit K/V缓存，近百万token的7针检索结果来自实际运行记录。
这次真正跨过的门槛，是“装得下”之后，模型还能从近百万token中把指定信息找回来。 如果只是服务没有崩溃，只能证明容量够了；7根针全部命中，则多了一层长距离检索能力的证明。它仍不等于模型已经完整理解整部长篇小说，更不能直接代表代码库分析、合同审阅或多轮Agent任务也会同样可靠。
这和8月10日那次16GB显卡运行Qwen 27B的上下文扩容也不是一回事。此前的ROCm补丁主要修正MTP计算缓冲区被高估的问题，单卡可用上下文从19,456提高到76,032；这次则是在模型已占约17GB显存的前提下，进一步压缩随上下文增长的KV缓存。两条路线都在挤显存，但动的是不同部分。
判断这次结果，可以分成三个门槛。加载模型和上下文，是容量证明；7针全中，是一次检索成功；换一批文本、改变针的位置并重复运行，仍能稳定交付，才算进入可用工作流。目前公开记录跨过了前两个门槛，没有提供重复次数、7根针的位置清单，也没有普通q4的同条件对照，因此不能据此断言普通q4一定失败或KVarN在所有模型上都更可靠。
1805秒 同样决定了它的用途。接近半小时的总耗时不适合追求即时回应的对话，却让单卡低频处理超长资料出现了新的可能。先把大部头资料一次送入，再做少量定位和提取，对等待时间的容忍度通常高于连续交互；真正使用时，关键结果仍应回到原文核对。
这个案例带来的吸引力，不是3090突然成了“百万上下文万能卡”，而是24GB显存在特定推理引擎、模型和KV缓存方案下，已经完成了一次此前很难想象的近百万token有效检索。
如果本地模型能稳定处理近百万token，你最想先丢给它哪份超长资料？
