32GB内存的Mac，也能跑Llama 70B
想象一下：你花了两万多块买的MacBook M1 Max，32GB统一内存，看起来很猛对吧？
但当你试图在本地跑一个70B参数的Llama模型时，系统会给你展示一个残酷的现实——"内存不足"。
70B模型有多大？按Q4量化算，将近40GB。你的Mac只有32GB，GPU工作集更小，大概8GB。
以前这事没得商量。跑不动就是跑不动。要么加钱买更大内存的机器，要么乖乖去用云端API。
但现在，一个叫Hypura的开源项目说：别急着认命。
它干的事情其实可以用一句话概括——把Mac的NVMe SSD也当成内存来用。
这不是什么新鲜概念，Windows和Linux早就支持虚拟内存。但Hypura"聪明"的地方在于，它不是一股脑把数据扔到SSD上，而是精确计算每一层模型该放在哪里。
注意力层放GPU，Norm层放GPU，部分FFN层放RAM，剩下的放NVMe。什么时候该预读、该预读多少，系统全自动算好。
实测数据很有意思：
Qwen 2.5 14B，8.4GB，全驻留GPU，速度21 tok/s，和llama.cpp持平——因为模型本身就放得下，Hypura不添乱。
Mixtral 8x7B，30.9GB，常规方法直接OOM。Hypura用"专家流式"策略，只保留非专家张量在GPU上，专家张量按需从NVMe加载，速度2.2 tok/s。99.5%的缓存命中率，意味着大部分I/O只发生在预热阶段。
Llama 3.3 70B，39.6GB，常规方法依然OOM。Hypura把Attention和Norm留在GPU（约8GB），FFN张量（约32GB）从NVMe流式读取，速度0.3 tok/s。
0.3 tok/s是什么概念？生成一个词需要三秒多。慢吗？确实慢。但能跑起来vs直接崩溃，这是两码事。
它是怎么做到的？
Hypura的核心逻辑是分层存储。
GPU的Metal层速度最快，但容量最小，受限于recommendedMaxWorkingSetSize。放不下的部分，交给统一内存（RAM），通过mmap映射访问。再放不下的，交给NVMe，用直接I/O（F_NOCACHE + pread）绕过系统缓存，配合预读取机制。
它不像传统虚拟内存那样"傻等缺页"，而是根据模型结构提前规划。
针对MoE模型（如Mixtral），Hypura利用了稀疏激活的特性——每生成一个token，其实只有2/8的专家会被调用。这意味着NVMe不需要一次性读取所有权重，按需加载即可。
针对dense模型（如Llama 70B），它采用"Dense FFN-streaming"策略，把计算密集但不需要频繁访问的FFN层剥离到NVMe，保持Attention层在GPU上高速运行。
Pool buffer大小、预读取深度、内存预算——这些在传统方案里需要开发者手动调优的参数，Hypura全部自动化。它读取GGUF文件，profile你的硬件（GPU工作集、RAM容量、NVMe带宽），然后自己算出最优解。
等等，这真的没问题吗？
评论区里有人提出了一个很实际的担忧：NVMe的寿命。
把推理过程的一部分负载转移到SSD上，意味着大量的写入操作。虽然SSD的TBW（总写入量）对于普通用户来说很难耗尽，但长期高强度使用会加速老化。
另外还有性能问题。
NVMe的顺序读取和随机读取差距巨大。好的NVMe顺序读取能到5-7GB/s，但随机读取可能掉到500MB/s甚至更低。模型推理的访问模式是随机的还是顺序的？这直接决定了实际性能。
MoE模型的稀疏激活意味着不需要读取全部权重，但访问模式从顺序变成了随机——这恰恰是NVMe最不擅长的情况。
有评论者提到："sequential reads on a decent nvme get you 5-7 GB/s, random reads drop to maybe 500 MB/s depending on queue depth."
对于1T参数的模型，按FP16算，一次前向传播需要读取约2TB权重。即使按顺序读取的峰值速度，也需要300多秒一个token。这显然不适合交互式使用，但作为后台批量处理任务，还是有价值的。
一个有趣的历史对照
有评论者说："Intel Optane rolling in its grave."
Optane是Intel曾经推出的傲腾内存技术，本质上也是用高速SSD来扩展内存。Intel当年花了巨大资源推广这个技术，最后因为成本和市场接受度问题彻底放弃。
现在，一个GitHub上默默无闻的开源项目，用类似的技术思路，让Apple Silicon跑通了原本跑不动的大模型。
讽刺的是，Optane当年没能解决的很多问题，Hypura在消费级硬件上做到了。不是因为技术更先进，而是因为场景更聚焦——Hypura不需要兼容所有硬件、所有模型，它只需要搞定Mac上的GGUF文件推理。
所以，这东西值得用吗？
看你的需求。
如果你的模型能完整放进内存，Hypura不会带来任何加速——它自己测过，21 tok/s vs 21 tok/s，零 overhead。但也零收益。
如果你的模型超出内存但不是特别大（比如30GB级别的MoE），Hypura能让你从"崩溃"变成"能跑"。2.2 tok/s的Mixtral，做交互式对话有点勉强，但做批量推理、思维链输出，够用了。
如果你的目标是70B级别的模型，0.3 tok/s意味着它更适合的场景是：丢在后台跑一夜，第二天看结果。对话？洗洗睡吧。
有个评论说得很中肯："For a lot of local workloads, sub-1 tok/s is useless in foreground and perfectly acceptable in background. If the choice is 'this crashes' vs 'this finishes overnight,' that's still a meaningful capability jump."
深以为然。
能跑≠好用，但能跑是第一步。
【MiniMax-M2.1锐评】：Hypura这种项目最打动人的地方，不是技术有多炫，而是它解决了一个具体而真实的困境——你的设备其实比你想象的更有潜力，只是没人愿意帮它"解锁"。
参考链接：
https://github.com/t8/hypura