先看已经做出的东西
我围绕端侧 KV Cache 压缩，推进算法参考、llama.cpp / GGML 运行时、持久存储与 Hexagon 内核。重点是让压缩表示被运行时正确、高效地消费。
后端持有因子池；图重建与存储生命周期解耦。
跟踪新增块与上传进度，按变化范围同步。
连接 INT8 存储契约、HTP 适配与 v79 数值验证。
一条跨越算法与硬件的工程链
历史 KV 分块压缩，近期窗口保持稠密表示。运行时管理因子、位置与有效块，后端负责重建或直接消费；两种路径具有不同的验证进度。
- Python 参考
BlockSVD · 量化 · 质量检查 - C++ / GGML
因子池 · 位置 · 增量同步 - HTP / AOT
存储 ABI · dispatch · memref - Hexagon HVX
重建 / 因子计算 · 独立参考验证
我的工作重点是这些层之间的接口与实现：让生产端输出、运行时存储、后端输入和数值参考遵守同一份契约。
三个决定，解释工程价值
01 / 压缩率不是最终目标
早期 Qwen3-1.7B 的 Python 原型在 2048-token 文本上，PPL 从 17.9799 变为 18.0442（+0.36%），但自回归评估耗时从 104.6 秒增至 300.5 秒。GPU→CPU 拷贝与 NumPy SVD 暴露了压缩路径的成本。因此，质量验证与运行时优化必须分别推进。
02 / 图可以重建，因子不必重新上传
将因子池交给 BlockSVD context 持有，并为后端建立独立副本。按层组、流与序列区分存储，容量按需增长；图拓扑改变时保留已有因子。追加块只同步尚未上传的区间，非追加修改则回退到完整重打包。
03 / 先把消费路径测清楚，再扩展集成
重建路径提供可验证的基线；直接计算压缩 Attention 则需要同时处理因子计算、近期窗口、因果掩码与 Softmax。局部 HVX 因子计算已经有仿真结果，但不能据此宣称完整 Attention 更快。将这些阶段分别验证，避免把局部优势误当成最终收益。
成果分别由什么支撑
模型质量 / H20
Qwen3-1.7B · rank 8 · block 64 · INT8 · 2048 tokens；PPL +0.36%。
单篇文本、早期 Python 路径；该轮评估耗时约为基线 2.87 倍。
存储与上传 / CPU
Qwen3-1.7B 小规模 smoke：14 个层组、56 次容量内更新，每次上传一个 8240-byte 块，无整池重传。
macOS CPU 路径，n_ctx=32；证明存储行为，不代表手机速度或模型质量。
HTP 适配 / v79 仿真
固定 INT8 重建 fixture：K / V 转为 FP16 后与独立参考最大绝对误差均为 0。
固定形状、仿真执行；与 Android FastRPC 真机验证分开。
局部内核 / v79 仿真
B64 / Rk32 / Rv32 / D128，1 个 Hkv、2 个 GQA query heads；HVX 因子计算 11,640 Pcycles，对标量参考约 10.56×。
仅因子计算；不含完整 Softmax、近期窗口和在线合并。
本页于 2026.09.16 整理现有源码与实验记录，未重新运行实验。各行属于不同实验，不拼成统一加速比；80% 内存减少仍是原始目标，不作为成果数字。
接下来要完成的闭环
将局部因子计算接入包含 Softmax、因果掩码与近期窗口的完整消费路径，在匹配基线下测量；再分别核验真机运行、峰值内存、生成质量与端到端时延。
阅读路线：如果关注推理系统，重点看因子池与数据同步；如果关注编译器或算子，重点看存储 ABI、AOT 适配与独立数值参考。