60MB小模型，CPU狂飙400 tok/s
一名开发者披露了自研250M参数量化模型：部署体积仅60MB，普通笔记本CPU生成速度约400 tok/s，还能借助磁盘缓存检索最多100M token历史。
250M 参数模型被压到 60MB，速度快得反常
一名独立开发者近日披露了一款从零训练的 250M 参数语言模型，宣称其部署体积只有 60MB、运行内存约 80MB，并能在不使用 GPU 的情况下，于普通笔记本 CPU 上达到约 400 token/s 的生成速度。
这款尚未公布正式名称的模型使用 30B token 的 FineWeb 数据训练，权重被量化至平均不足 2 bit。开发者还设计了一套分层上下文机制：最近 2048 token 保留为 FP16 KV Cache，更早的历史则压缩至 1 bit 并写入磁盘，模型最多可以从 100M token 的历史中检索信息。
这不是一款可以直接对标 GPT、Claude 或 Qwen 主力模型的通用助手，而是一次颇有价值的极限压缩实验。它证明了当模型规模、词表表示、量化训练和上下文存储被共同设计时，本地 LLM 的部署门槛还能继续下探；但它目前更接近研究原型，而不是已经完成充分验证的成熟产品。
截至 2026 年 8 月 22 日，主要技术信息仍来自开发者在 Reddit r/MachineLearning 发布的说明。公开内容尚未给出完整论文、训练代码、权重下载、许可证、处理器型号及标准基准测试，因此下文涉及速度与内存的数据均应视为作者自报结果，而非第三方复现结论。
60MB 并不违反算术，真正难点是低于 2 bit 后还能工作
量化是把模型权重从 FP16、FP32 等高精度数值压缩为更低位宽表示的技术，目标是减少存储、内存占用和推理时的访存压力。
250M 参数如果使用 FP16，每个参数占 2 字节，仅原始权重就需要约 500MB；如果使用标准 4 bit 量化，理论权重体积约为 125MB；如果恰好使用 2 bit，理论体积则是 62.5MB。开发者宣称平均位宽低于 2 bit，因此把整个部署压到约 60MB，在容量计算上是成立的。
| 部署形态 | 参数量 | 权重精度 | 理论权重体积 | 披露运行内存 | 披露生成速度 | |---|---:|---:|---:|---:|---:| | 本次实验模型 | 250M | 平均低于 2 bit | 低于 62.5MB | 约 80MB | 约 400 tok/s，CPU | | 常规 250M FP16 模型 | 250M | 16 bit | 约 500MB | 通常高于 500MB | 取决于实现与 CPU | | 常规 250M 4-bit 模型 | 250M | 4 bit | 约 125MB | 通常高于 125MB | 取决于实现与 CPU | | 常见 7B 4-bit 本地模型 | 7B | 4 bit | 约 3.5GB，实际文件常为 4GB 左右 | 常见为 4—6GB 以上 | 消费级设备通常为个位数至数十 tok/s |
低于 2 bit 的难点从来不是把文件做小，而是控制量化误差。4 bit 量化已经成为本地 LLM 的常见平衡点，因为它通常能在模型质量、内存和推理效率之间取得相对稳定的折中；进入 2 bit 甚至更低后，可供每个权重表达的信息急剧减少，离群值、量化分组、缩放因子和算子设计都会明显影响输出质量。
这款模型更值得关注的地方是从训练阶段就适配极低位宽，而不是对一个普通 FP16 模型进行事后压缩。训练时量化或量化感知训练能让模型提前适应有限的数值表示范围，通常比训练结束后直接把权重压到 2 bit 更可靠。开发者没有完整披露量化格式、分组大小、缩放参数和混合精度层，因此目前还无法判断 60MB 是否包含全部运行组件，也无法与 GGUF、GPTQ、AWQ 等常见格式进行严格的同位宽比较。
400 tok/s 的核心不是算力，而是每次只读取约 60MB 权重
单路 LLM 解码通常受内存带宽限制，因为生成每一个新 token 时，密集模型往往需要重新读取大部分权重。
一个实用的粗略估算是：生成速度约等于可用内存带宽除以每 token 需要读取的活跃权重字节数。如果该模型每生成一个 token 需要读取约 60MB 权重，那么 400 tok/s 对应约 24GB/s 的持续数据吞吐，即 60MB × 400 = 24,000MB/s。对现代双通道 DDR5 笔记本来说，这一带宽需求并非离谱。
400 tok/s 因而是一个在物理上可信、但仍需复现的数字。模型只有 250M 参数，远小于当前本地部署常见的 7B、14B 或 30B 模型；权重文件又只有约 60MB，可以较好地驻留在 CPU 高速缓存和系统内存层级中。与一个 4 bit 7B 模型相比，它每步需要搬运的数据可能少几十倍，吞吐达到数百 token/s 并不令人意外。
这个速度也不能直接解释为它比大型模型强几十倍。tok/s 是吞吐指标，只表示模型输出 token 的速度，不代表回答正确率、代码能力或推理深度。250M 参数模型即使输出速度达到 400 tok/s，其知识容量和复杂任务能力通常仍无法与 7B 以上模型等量齐观。
作者目前也没有说明 400 tok/s 的测试边界。处理器型号、线程数量、批大小、量化内核、上下文长度、操作系统、是否使用 AVX2 或 AVX-512，以及统计的是纯解码速度还是包含预填充阶段，都会改变结果。尤其是预填充和解码是两项不同指标：前者负责读取整段提示词，后者负责逐 token 生成，单独公布解码速度无法说明百万 token 历史的首次响应时间。
80MB 内存的说法同样需要限定条件。这个数字可能指短上下文状态下的核心工作集，而不是操作系统统计的完整进程常驻内存；如果模型通过内存映射读取 60MB 文件，文件页缓存如何计入也会影响结果。最近 2048 token 的 FP16 KV Cache 究竟占多少空间，还取决于层数、注意力头数量、头维度及是否采用多查询注意力，现有披露不足以完成核算。
百万 token 不放内存，而是按 320 字节一个 token 写入磁盘
KV Cache 是 Transformer 在生成过程中保存历史注意力键和值的缓存，用于避免每生成一个 token 都重新计算全部上下文。
传统长上下文方案的主要问题是 KV Cache 会随序列长度持续增长。开发者给出的办法是保留最近 2048 token 的 FP16 缓存，把更早的历史压缩成 1 bit 表示并写入磁盘，平均每个历史 token 占约 320 字节。模型从训练阶段就学习如何从这份磁盘缓存中检索，而不是把全部历史持续放在内存里参与普通注意力计算。
| 历史长度 | 按 320 字节/token 计算的磁盘占用 | 适合场景 | |---:|---:|---| | 100K token | 约 32MB | 长文档、单个代码仓库摘要 | | 1M token | 约 320MB | 多本书、长期会话记录 | | 10M token | 约 3.2GB | 大型知识库或长期 Agent 日志 | | 100M token | 约 32GB | 超长期个人档案、海量文本检索 |
这套机制更像模型原生的可检索外部记忆，而不是通常意义上的 100M token 全注意力上下文。全注意力意味着任意位置的信息都能在模型层内参与组合和推理；磁盘记忆则需要先定位相关片段，再把结果带回当前窗口。两者都能让模型接触很久以前的信息，但计算能力并不相同。
开发者对此给出的边界相当明确：受预算限制，模型只被训练为从历史缓存中检索并回答，没有被训练为在 100M token 上进行复杂推理。这意味着它可能适合回答“几个月前那次会议定了什么日期”，却不一定能完成“综合过去半年数千次操作记录，找出导致故障的因果链”这类跨片段、多跳推理任务。
磁盘缓存也没有消灭上下文成本，而是把成本从内存容量转移到了存储容量、检索延迟和缓存构建上。100M token 需要约 32GB 磁盘，这对笔记本 SSD 并非不可接受；但如果检索过程需要大量随机读取，实际延迟将取决于索引结构、压缩布局和 SSD 性能。作者尚未公布百万或亿级历史下的召回率、首 token 延迟和磁盘读取量，因此“支持 100M token”目前只能理解为设计上限，而非已经证明可以流畅推理的等价上下文窗口。
固定 512-bit token 编码，可能是压缩词表的关键一环
固定 token 编码是为每个 token 分配预设二进制代码，而不是直接使用常规的可训练词嵌入表保存一整行高精度向量。
开发者表示，这款模型的词表不是普通 embedding table，每个 token 对应一个固定的 512-bit code。常规模型通常为每个词元保存一组可训练浮点向量，词表越大、隐藏维度越高，输入嵌入和输出头占用的参数就越多；对只有 250M 参数的小模型来说，词表相关参数可能占据相当可观的比例。
固定 512-bit 编码有机会降低词表存储，并让 token 表示具备更强的结构化压缩能力。512 bit 等于 64 字节，即使词表包含 50,000 个 token，原始固定编码也只需要约 3.2MB；但模型如何把这些二进制码映射到隐藏状态、输出层是否共享表示、编码是否包含纠错或语义结构，当前都没有完整说明。
这项设计也让传统困惑度比较变得更谨慎。token 级困惑度会受到分词器和词表设计影响，同一句文本如果被切成不同数量的 token，perplexity 就不能直接横向比较。固定 512-bit 编码并不必然改变分词粒度，但在缺少 tokenizer 细节的情况下，仅凭 perplexity 很难判断它相当于哪一档现有模型。
困惑度 23.3 说明它学会了英语分布，但不能证明会推理
困惑度是衡量语言模型预测下一个 token 难度的指标，数值越低通常表示模型对测试文本的概率预测越准确。
作者在未参与训练的英文教育网页上测试了基础模型，窗口长度为 2048 token，得到每 token 交叉熵 3.15 nats、困惑度 23.3，以及每字节 0.99 bit。这里的数学关系能够对应：e 的 3.15 次方约为 23.3，因此交叉熵与困惑度至少在数值上自洽。
每字节 0.99 bit 是更值得关注的指标，因为 bits per byte 相比 token 级困惑度更少受到分词器差异影响。它表示模型平均使用约 0.99 bit 的信息量编码测试文本中的一个字节，可用于观察语言建模压缩能力。不过，测试集规模、去重方式、FineWeb 污染检查和评测脚本都未公开，现阶段仍不能把这个数字当作独立基准成绩。
基础语言建模质量也不等于聊天和推理能力。开发者披露的是英文网页续写指标，没有给出 MMLU、ARC、HellaSwag、GSM8K、HumanEval 或指令遵循测试。一个模型可以很好地预测常见英语文本，却在数学、多步规划、代码生成和事实问答上表现有限。
30B token 的训练量意味着每个参数平均对应约 120 个训练 token。对于 250M 参数模型而言，这是明显的高数据训练路线，有利于把有限参数尽可能训练充分；但模型容量仍然构成硬上限，更多数据不能无限补偿参数规模不足。它更可能成为高速分类、短文本补全、关键词抽取或本地检索入口，而不是替代数十亿参数的通用模型。
真正有用的场景，是把模型塞进过去放不下 LLM 的地方
60MB 体积的实际意义是让语言模型进入低内存、弱算力和离线优先的设备，而不是在排行榜上挑战大型模型。
这款模型如果能够按披露数据稳定运行，最合适的场景包括：
- 在普通笔记本上进行超低延迟文本补全，不占用独立 GPU；
- 在离线桌面软件中完成分类、标签生成、格式整理和简单问答；
- 为本地 RAG 系统提供轻量检索路由，先找出相关历史，再交给更强模型处理；
- 在长期运行的个人 Agent 中保存大量操作记录，并按需找回旧信息；
- 在树莓派级别或低功耗 x86 设备上探索端侧语言交互；
- 作为投机解码的小模型候选，为更大的目标模型批量猜测后续 token。
投机解码可能是它最现实的高价值方向。投机解码是先由小模型快速生成若干候选 token，再由大模型并行验证的推理技术；小模型越快，且输出分布越接近目标模型，整体加速潜力越高。400 tok/s 的 CPU 模型如果能与大型模型形成较高接受率，价值可能不在独立回答问题，而在减少大模型逐 token 解码次数。
长期记忆则是它最有辨识度、也最容易被误读的能力。把 100M token 历史压进约 32GB 磁盘确实比把 KV Cache 全放进内存实用得多，但最终体验取决于召回率，而不是容量数字。一个能保存所有内容却经常找错片段的系统，并不比传统向量数据库更可靠。
现阶段的结论：工程方向很亮眼，模型能力仍缺证据
这次披露最有价值的结论是，250M 参数、低于 2 bit、60MB 权重和磁盘长期记忆可以被联合设计，而不是分别作为推理后的补丁。
它也再次说明，本地 LLM 的速度首先取决于每生成一个 token 要搬运多少数据。把 7B 模型换到更贵的硬件上是一条路线，把模型压到 60MB、让普通内存带宽足以喂满 CPU，则是另一条路线。后者牺牲了模型容量，却换来了极低成本和极高吞吐。
这款模型目前还不能被称为已经验证的 100M 长上下文 LLM。公开信息只证明作者提出了相应架构并报告了结果，尚缺少权重、代码、复现步骤、标准基准、长历史压力测试和消融实验。尤其需要确认的是：低于 2 bit 量化损失有多大、80MB 是否为完整内存占用、400 tok/s 使用哪款 CPU，以及 100M token 历史中的检索准确率如何变化。
我们的判断是，这是一项值得跟进的端侧模型实验，但暂时不应把它包装成“大模型装进 60MB”。250M 参数本质上仍是小模型，400 tok/s 的高速度主要来自极小权重，而不是新的通用智能突破。真正可能产生行业价值的部分，是模型原生适配超低位宽和分层磁盘记忆的思路；如果后续开放权重并被第三方复现，它可能成为本地补全、长期记忆 Agent 和投机解码领域的一块实用组件。
