一句话看懂：alphaXiv 上的一篇新论文提出 PageGram，把多头 n-gram 哈希表的各行放进同一页，使设备端大参数记忆表的读取次数接近普通平表，同时保留多头抗碰撞优势。
事件核心：发生了什么
根据 alphaXiv 2026 年 10 月 12 日公开的论文摘要，PageGram 针对的是设备端大容量 n-gram 记忆表的一个实际瓶颈。传统平表一次 token 读两页，但不同 n-gram 哈希到同一行后无法区分；Engram 风格的多头寻址给每个 n-gram 阶数配 8 个独立头，虽然降低碰撞，却让每次 token 产生 16 次分散读取。
PageGram 的做法是：先按 n-gram 哈希到一个页，再让每个头在该页内独立选择自己的槽位，从而把同一阶数的所有头行放在一起。论文报告，在 20B 参数、4-bit 存储、1 GiB 页缓存的回放测试中，PageGram 平均每 token 触发 0.99 次 flash 读，而 Engram 风格为 9.18 次；NVMe 驱动上的查找吞吐可达到后者的 5 到 8 倍。需要说明的是，这是缓存未命中块读计数，不是端到端延迟或手机实测加速。
为什么重要
大模型把越来越多知识放到可学习的哈希记忆表中，这类表参数规模大、计算开销低，适合放在 flash 上。但如果布局不合理，推理时会被随机读放大拖慢。PageGram 把“多头独立性”和“页局部性”放到同一设计里，说明在不牺牲表大小的前提下，读取成本可以接近平表。这为端侧大模型、边缘推理和低成本 AI 应用提供了一条可参考的工程路径。
对用户/开发者/创作者的影响
对开发者而言，这类记忆表如果落地，意味着在同等模型规模下，设备端推理可能减少对高带宽内存和高端算力的依赖。对 AI 应用和图像生成等场景，低延迟查询有助于把大参数记忆表放进手机、PC 或边缘设备。对创作者和企业采购来说，目前公开信息仍停留在论文阶段，不应视为已上线产品；是否真正降低端到端延迟，还要看推理引擎、页缓存大小和硬件驱动实现。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
一是论文是否补充完整实验、基线细节和不同硬件上的实测延迟；二是 PageGram 的页缓存策略能否在主流推理框架中落地，尤其是 4-bit 存储下的精度损失是否可控；三是 Engram 等方案是否跟进类似布局，以及端侧大模型厂商会不会把这类 n-gram 记忆表纳入产品路线。
来源：alphaXiv
