你想在家里的游戏电脑上运行一个超大模型，却发现模型文件有119 GiB，显卡显存只有16 GB，连32 GB系统内存也装不下。通常到这里就该换机器了。现在，一位开发者换了个思路：不把模型全部装进去，而是把暂时用不到的部分留在SSD，需要时再读取。其在 Reddit 帖文中称，一台配备RTX 5060 Ti 16 GB、32 GB DDR5内存和Gen5 NVMe SSD的电脑，运行176.9B参数的Qwen3.8-Flash-Next时，解码速度达到9—10 tok/s。
这里的tok/s是“每秒生成多少个词元”。词元可以粗略理解成模型处理文字时使用的小片段。本文的配置、速度和比较数字均来自开发者单方面发布的Reddit帖子，目前没有第三方复测。
不是装进显卡，而是分层摆放
标题里的“挤进16GB显卡”容易让人误会。119 GiB模型并没有完整进入显存。更准确地说，这套推理引擎把显存、系统内存和SSD排成三级仓库：常用部分放在离计算最近的位置，冷门部分继续留在磁盘。
这个模型采用MoE，也就是“混合专家”结构。模型内部有许多被称为“专家”的计算模块，每生成一个词元，只调用其中一部分。它有点像大型资料库：不必把所有档案同时摊在桌上，只要提前放好最常查的几册，再临时去库房取其余资料。
按开发者披露的数据，稠密权重——注意力、共享专家和输出层等每次都要用到的部分——占4.4 GiB显存；最热门的路由专家占8.8 GiB显存。另有0.6 GiB词元嵌入表和6.0 GiB次热门专家放在系统内存。合计约20 GiB驻留在显存或内存中。
剩下约99 GiB仍在SSD：48.5 GiB是按需读取的路由专家，50.7 GiB是hashed n-gram table，即按连续词元片段的哈希值组织的数据表。帖子没有进一步解释这张表在模型中的具体作用。
关键不是读盘，而是少读、早读
每生成一个词元，模型会在48层中各调用10个专家，总计480次。开发者称，其中约377个专家已经在显存或系统内存里，约103个需要从SSD读取。专家查找的内存命中率约为75%，每个词元实际读盘约270 MiB。
引擎用GCLOCK缓存策略保留热门专家；把下一档专家放入pinned RAM——锁定的一块系统内存，可经PCIe传输；再用8个读取线程从NVMe SSD取其余数据。lookahead prefetch会预判下一层可能调用哪些专家，提前发起读取，尽量让读盘和计算重叠。
模型文件采用GGUF——本地大模型工具常用的封装格式；权重使用NVFP4——面向NVIDIA硬件的4位浮点格式。引擎让FP4矩阵乘法直接在Tensor Core上执行，不先展开成更高精度格式。
从“勉强能跑”到接近可用
开发者报告的benchmark轮次解码速度为9.06 tok/s，择优轮次为10.4 tok/s；处理一段约5500词元输入时，prefill速度为49.2 tok/s。Prefill指模型先读完输入、建立计算状态的阶段，与随后逐词生成的解码不是同一项速度。
帖子还称，同一台机器运行llama.cpp时，平均解码速度为4.9 tok/s。不过两边是否采用完全一致的上下文长度、采样参数和其他设置，材料没有说明，因此不能把它当成严格的同条件性能翻倍。
本刊9月28日报道过相近路线：当时12 GB显卡运行约85 GB模型，速度约3 tok/s。这次配置把模型文件推到119 GiB、显存提高到16 GB，并自报9—10 tok/s。真正值得注意的不是“16 GB显卡拥有了119 GiB显存”，而是存储调度开始把原本只能证明可行的方案，推向更接近日常交互的速度。
局限与未知
- 所有性能数字均为作者自报，未附可复现实验日志、完整benchmark配置、输出质量对比或第三方测试；10.4 tok/s还是“最佳轮次”。
- 每词元约270 MiB的持续读取会带来多少能耗、SSD写读负担及长期成本，帖子没有给出实测。
- 开发者预计优化SSD streaming后，v2可达到约14—15 tok/s；这只是尚未实现的预期，不能视为当前成绩。