在 32GB 内存的笔记本上跑一个 48.4GB 的 80B 参数模型,还能以 37 tok/s 的速度往外吐字——这不是配置清单上的幻想,而是开源项目 Janas 本周晒出的实测成绩。
把"装不下"变成"读得快"
Janas-LLM 是一个用纯 C 写成的推理引擎,除 C 标准库外零依赖,GPL-3.0 开源。它的核心思路不是压缩模型,而是换问题:权重整体留在磁盘上,推理时每个 token 只把路由命中的那几个 MoE 专家从 NVMe SSD 流式读进内存,反复被调用的热专家常驻缓存,冷专家用完即走。内存只需要装下"活跃工作集",而不是整个模型。
作者 Maurizio "camauri" Cammalleri 的实测机器是一台 Intel Core Ultra 9 185H 笔记本:32GB DDR5、1TB NVMe(读速约 5.7GB/s)、集成 Arc GPU 走 Vulkan。跑 Qwen3-Next-80B-A3B 时,热专家缓存约占 19GB,其余全从盘上读。
数字:37 对 2.8,以及 13 连胜
在 2026 年 10 月 9-12 日的同机对比里,Janas-LLM 读 1024 token 提示 62 tok/s,llama.cpp 为 16;写入 24 tok/s 对 2.8 tok/s;叠加投机解码后聊天场景达到 37 tok/s。作者称在其测试机上,13 个模型(覆盖 Qwen3、Qwen3.5、Qwen3.6、Qwen3-Next 与 Gemma 4 的 dense/MoE 版本,Q4_K_M 量化)对比中 Janas-LLM 全部更快——包括 Qwen3.5-0.8B 这类小模型(写入 109 对 32 tok/s)。
80B 这一档的对照最直观:llama.cpp 常规构建在 GPU 参与时直接内存耗尽——CPU 后端要拷贝权重重排,Vulkan 后端又留下系统无法回收的缓冲;关掉重排、改用 mmap 才跑起来,写入只有 2.8 tok/s。Janas 无需任何选项就跑完了全程。
也有例外:unsloth 的 3-bit Qwen3-30B 读提示反而比 llama.cpp 慢(100 对 112 tok/s),因为该量化格式的权重还没走上 GPU 快速路径——README 里写得明明白白。投机解码同样有边界:Qwen 大模型上草稿存活率 74-89%,换到意大利语文本,Qwen3.5-2B 只活下来约三分之一,收益接近零。
一人项目,和一句"这是实验品"
README 开头就是一盆冷水:"This is an experiment, not a product"。公开 API 和命令行每周变好几次;引擎故意吃满空闲内存、用 O_DIRECT 全速读盘,机器余量不足时可能把桌面推进 swap,作者自述 GPU 曾引发一次驱动重置带走整个桌面;全部开发与测量只在这一台笔记本上完成,其他 CPU、独显、慢盘均未验证。
但它同时展示了 MoE 时代端侧推理的一条真实路线:稀疏激活意味着"模型大小"不再等于"内存需求",瓶颈从容量迁移到带宽与缓存命中率——路由若老在热门专家上打转,速度就稳;一旦游走,磁盘就是天花板。这与此前 Colibri 从 SSD 流式跑 552B 模型、伯克利把 KV 缓存压进 SSD 是同一方向的不同切面。
对普通用户,现在的建议是别急着上生产;对关注本地推理的人,这个数百 star 的仓库值得盯——一人、纯 C、零依赖做到这个完成度,本身就是对"端侧跑大模型必须堆显存"的一次反证。