Hypura是一个GitHub项目，帮助用户在Mac内存不足时运行大型模型，通过优化内存使用解决性能瓶颈问题。

GitHub项目：Hypura - 在Mac上运行超内存限制的大模型

项目简介

Hypura是一个专为Apple Silicon设计的存储层级感知LLM推理调度器。它能够根据访问模式、带宽成本和硬件能力，将模型张量分布在GPU、RAM和NVMe等不同存储层级上，从而实现在物理内存不足的情况下运行超大型模型。

核心功能

1. 跨层级张量分配：

   • GPU（Metal）：存储注意力层、归一化层和嵌入层，提供最快访问速度
   • RAM：存储超出GPU工作集的层
   • NVMe：通过直接I/O按需加载剩余层

2. 自动模式选择：

   • 全驻留模式：模型完全适配GPU+RAM时使用
   • 专家流模式：针对MoE模型（如Mixtral），仅保留非专家张量在GPU
   • 密集FFN流模式：适用于超大型密集模型（如Llama 70B）

性能表现

在M1 Max（32GB统一内存，NVMe顺序读取约5.1GB/s）上的基准测试： - Qwen 2.5 14B：21 tok/s（全驻留模式） - Mixtral 8x7B：2.2 tok/s（专家流模式） - Llama 3.3 70B：0.3 tok/s（密集FFN流模式）

技术亮点

• 利用MoE模型的稀疏性（每个token仅激活2/8专家）
• 神经元缓存实现99.5%的命中率
• 动态调整预取深度和池大小
• 自动硬件性能分析

安装与使用

1. 从源代码构建： shell git clone --recurse-submodules https://github.com/hypura/hypura.git cd hypura cargo build --release

2. 基本命令：

   • 硬件分析：hypura profile
   • 模型推理：hypura run ./model.gguf
   • 基准测试：hypura bench ./model.gguf

兼容性

提供与Ollama兼容的HTTP API，可作为Ollama的替代方案，支持包括OpenClaw在内的工具。

安全说明

• 仅从SSD读取数据，不会因写入操作损坏SSD
• 建议首次测试时使用--max-tokens 10参数
• 大型模型测试应放在./test-models/目录

许可证

MIT许可证

项目状态

• 版本：v0.1.0（发布于2026年3月17日）
• 开发者：Tate Berenbaum（@t8）
• 技术栈：Rust（91.8%）、Shell（5.4%）、C（2.8%）

该项目展示了利用NVMe支持推理的创新方法，通过智能调度实现在有限内存设备上运行超大型模型的能力。

以下是评论内容的总结：

1. 关于1T参数模型的疑问

   • 有评论质疑1T参数模型的来源，指出代码库中只提到70B或更小的模型。
   • "Where does '1T parameter model' come from? I can only see models with 70B params or less mentioned in the repo."
   • "Are there any 1T parameter open source models?"

2. 技术比较与性能讨论

   • 有评论提到与类似设计的对比，认为使用mmap可能带来显著开销。
   • "Very similar design except that this is apparently using mmap, which according to the earlier experiment incurs significant overhead."
   • 另一评论认为OS分页性能更差，因为内核的页面错误处理是反应式的，无法预取。
   • "OS paging would be significantly worse here. The kernel's page fault handler is reactive — it doesn't know you're about to read layer 47's FFN weights, so it can't prefetch."

3. 实际应用与性能担忧

   • 有评论对NVMe的寿命表示担忧，认为频繁读写可能影响其耐久性。
   • "I do wonder in practice how the 'smarts' pan out, because putting a ton of stress on your NVMe during generation is probably not the best choice for it's longevity."
   • 另一评论指出1T模型的推理速度可能极慢，不适合交互式使用。
   • "for a 1T model youd need to stream something like 2TB of weights per forward pass at fp16. even at peak sequential thats 300+ seconds per token which is... not great for interactive use."

4. 与其他工具的对比

   • 有评论提到Ollama的局限性，希望有类似工具能提供更好的性能。
   • "There needs to be something like this from Ollama. At the moment Ollama has a lot of flaws that prevent it from getting great performance."

5. 标题与宣传的争议

   • 有评论认为“运行”一词具有误导性，实际速度极慢。
   • "This is <1 tok/s for the 40GB model. Come on, 'Run' is not the right word. 'Crawl' is."

6. 潜在用途与价值

   • 有评论认为尽管速度慢，但对于后台任务仍有意义。
   • "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."

7. 技术细节的质疑

   • 有评论指出缺乏与llama.cpp的mmap对比，以及对MoE预测机制的疑问。
   • "You do not provide any comparison to llama.cpp with mmap. You do not explain how any kind of predictor can work for MoE experts."

8. 其他相关资源

   • 有评论分享了Simon Willison关于类似技术的文章。
   • "Simon Willison wrote a good post about Dan Woods’ work on 'Autoresearching Apple's 'LLM in a Flash' to run Qwen 397B locally'."

总结：评论围绕1T参数模型的真实性、技术实现细节、性能表现、与其他工具的对比以及实际应用场景展开了讨论，既有对技术创新的认可，也有对性能和宣传的质疑。