32GB笔记本跑80B大模型：纯C引擎把专家流式塞进SSD

在消费级硬件上运行大模型，通常意味着你要么接受小参数模型的平庸表现，要么为显存和内存付出高昂代价。但最近B站上流传的一个实验项目，给出了第三条路：一台32GB内存、没有独立显卡的笔记本，跑起了总参数80B的模型，生成速度还能到24 tokens/s。

32GB内存跑80B：反常识的数字

这个项目叫 Genus，一个用纯C写的推理引擎，作者是 Janas。它实现了一个听起来不太可能的结果：在32GB内存的笔记本上推理 Qwen3-Next-80B 模型。

Qwen3-Next-80B 的模型文件大小约 48.4GB，远超过这台机器的物理内存。按常规思路，模型权重必须先加载进内存或显存才能计算，但 Genus 的做法是：权重根本不加载进内存，全部留在硬盘上。

这意味着内存里只保留极少量必要数据，真正的大头——模型参数——安安静静待在 SSD 里。

专家流式加载：每个Token只读用到的部分

Genus 能做到这件事，靠的是对 MoE（混合专家）架构的针对性设计。

80B 是模型的总参数量，但每次前向推理只激活约 3B 参数。剩下的专家权重，在那一刻是"沉睡"的。Genus 利用了这个特性：每个 Token 只从 SSD 读取它真正需要的那几个专家，其余部分继续躺在硬盘上不碰。

同时，常用的专家会被缓存到内存中，形成"热数据在内存、冷数据在 SSD"的分层结构。这是一种把 MoE 稀疏激活特性用到极致的做法——既然计算只用 3B，那 I/O 也只需要读 3B 对应的那部分。

当然，SSD 的随机读取速度远低于内存带宽，能跑到 24 tokens/s 说明作者在预取、缓存和读取调度上做了不少工作。

MoE（Mixture of Experts，混合专家）是一种把单个稠密模型拆成多个"专家"子网络的架构。每次前向推理时，门控网络根据输入内容只挑选少数几个专家参与计算，其余专家不参与。好处是总参数量可以做得很大以提升容量，但单次实际计算的参数量被控制在很小范围内，从而兼顾能力与效率。像 Qwen3-Next-80B 这样的模型，80B 是全部专家的参数总量，而单个 Token 真正激活的只有约 3B。正因如此，激活比例非常低，推理时所需的计算与部分数据访问量也远小于总规模。这一稀疏特性是流式加载方案成立的前提：既然计算只用到少数专家，理论上就可以只把这几块权重搬进内存，其余继续留在更廉价的存储介质上。

实测速度：24 tokens/s vs CPU 拉满的 2.8

性能数据是这个项目最有说服力的部分。

在写作场景下，Genus 在这台 32GB 笔记本上达到约 24 tokens/s。作为对比，同一台机器如果"拉满 CPU"跑传统方式，速度只有约 2.8 tokens/s——差距接近一个数量级。

这个对比很关键：它说明流式加载并没有成为瓶颈，反而因为绕开了内存容量的硬限制，让更大的模型变得可用。24 tokens/s 大约接近人类快速阅读的速度，用于聊天、代码补全这类交互场景已经具备可用性。

tokens/s 是大模型推理速度的常用衡量单位，表示每秒生成的词元数量。词元是模型处理文本的基本单位，一个英文单词可能被拆成一到多个 token，中文大致一个字对应一个或多个 token。对于交互式场景，速度体验通常有相对经验区间：低于 5 tokens/s 时输出明显慢于阅读速度，等待感强烈；10 到 20 tokens/s 接近流畅阅读的节奏，适合聊天、补全；20 tokens/s 以上则基本感觉不到卡顿。因此 24 tokens/s 这个数字的意义不仅在于与 2.8 tokens/s 的倍数差距，更在于它跨过了"可用"这条体验线。值得注意的是，流式加载方案的瓶颈往往在存储随机读取而非算力，所以速度对 SSD 性能、缓存命中率和预取策略非常敏感，不同硬件上表现可能有较大波动。

不只是命令行：MCP 服务器和 OpenAI 风格接口

Genus 不只是一个跑分玩具，它配套了实际可用的接口。

项目内置了一个 MCP（Model Context Protocol）服务器，方便接入支持 MCP 的工具链。此外还提供了一个 OpenAI 风格的 HTTP 接口，可以直接对接 VS Code 做代码补全。

这一点让它的定位从"实验"向"能用"靠近了一步。对于想在本地跑大模型又买不起大显存的开发者来说，OpenAI 兼容接口意味着现有工具几乎不用改就能连上。

MCP（Model Context Protocol，模型上下文协议）是一套用于把大模型与外部工具、数据源连接起来的开放协议。它定义了一套标准接口，让模型能够以统一方式调用文件系统、数据库、API 等外部能力，客户端（如编辑器、Agent 框架）只需实现一次协议即可接入不同后端。在 Genus 中内置 MCP 服务器，意味着它不仅能生成文本，还能被支持 MCP 的工具链当作可调用的模型后端使用。而 OpenAI 风格 HTTP 接口则指遵循 OpenAI Chat Completions 等端点约定的 REST 接口，社区已有大量客户端、SDK 和编辑器插件按这套约定开发，因此只要后端能兼容该格式，就无需修改前端代码即可直接替换接入，这也是本地推理项目常见的"即插即用"策略。

作者的态度：这只是实验，还不是产品

需要泼一盆冷水的是，作者自己明确说：这只是一个实验，还不是产品。

这意味着它大概率缺少完善的文档、错误处理、多平台支持和长期维护承诺。SSD 的寿命、不同硬件下的稳定性、并发请求下的表现，都是未知数。纯 C 实现虽然性能好、依赖少，但对普通用户来说编译和配置的门槛不低。

从技术角度看，Genus 的价值在于验证了一条路径：在显存和内存受限的设备上，通过精细的 I/O 调度和 MoE 稀疏性利用，大模型并非完全不可及。它更像是一份有启发性的技术证明，而不是一个开箱即用的产品。如果你手头有闲置的 32GB 笔记本和一块够快的 SSD，倒是值得关注一下这个方向后续会不会有更成熟的实现。