世界を動かす技術を、日本語で。

Hypura – Apple Silicon向けのストレージ階層を考慮したLLM推論スケジューラ

2026年3月25日原文(github.com)

概要

  • Hypura はApple Silicon向けのストレージ階層対応LLM推論スケジューラ
  • モデルのテンソルを GPU・RAM・NVMe 間で最適配置し、物理メモリを超えるモデルも動作可能
  • MoEや大型Denseモデルにも対応し、 mmapクラッシュ問題を回避
  • Ollama互換APIで OpenClaw等と連携 可能
  • SSD寿命や安全性にも 十分配慮された設計

Hypura:Apple Silicon向け大規模LLM推論スケジューラ

  • Apple Silicon (MacBook Pro, Mac Studio等)の高速ユニファイドメモリとNVMeストレージを活用
  • モデルテンソルを GPU・RAM・NVMe の各階層に分散配置
    • アクセスパターン・帯域コスト・ハードウェア能力 に基づく最適化
  • 物理メモリを超えるモデルも クラッシュせず動作
    • 例:Mixtral 8x7B(31GB)を32GB Mac Miniで2.2 tok/s動作
    • Llama 70B(40GB)も0.3 tok/sで動作
    • llama.cpp ではどちらもOOMクラッシュ

技術的特徴

  • モデルアーキテクチャ理解型配置
    • Norms/Embeddings:小型・高頻度アクセス→GPU常駐
    • MoE:ルーティングで必要なエキスパートのみNVMeからオンデマンド読込(I/O 75%削減)
      • ニューロンキャッシュによる99.5%ヒット率
      • 共起追跡による次エキスパート予測プリフェッチ
    • Dense FFN:重いFFN重みのみNVMeからプールバッファ経由でストリーミング
  • プリフェッチ深度・プールバッファサイズ自動最適化
    • 利用可能メモリに応じて自動スケール

動作モード

  • full-resident :GPU+RAMに全モデル配置。NVMeアクセスなし、フルスピード
  • expert-streaming (Mixtral等MoEモデル)
    • 非エキスパートテンソルのみGPU常駐
    • エキスパートテンソルはNVMeからオンデマンド読込+キャッシュ
  • dense FFN-streaming (Llama 70B等非MoEモデル)
    • Attention/NormsはGPU常駐
    • FFNテンソルはNVMeからプールバッファ経由でストリーミング

パフォーマンス例(M1 Max, 32GB, NVMe 5.1GB/s)

| Model | Size | GPU | NVMe | Mode | Hypura | llama.cpp | 備考 | |----------------------|----------|--------|--------|------------------|-------------|-----------|----------------| | Qwen 2.5 14B Q4_K_M | 8.4 GB | 8.4 GB | — | full-resident | 21 tok/s | ~21 tok/s | GPU常駐 | | Mixtral 8x7B Q5_K_M | 30.9 GB | 1.1 GB | 29.8GB | expert-streaming | 2.2 tok/s | OOM | 99.5%キャッシュ| | Llama 3.3 70B Q4_K_M | 39.6 GB | 7.8 GB | 31.8GB | dense-FFN-stream | 0.3 tok/s | OOM | 動的プール |

  • メモリ内に収まる場合 はオーバーヘッドゼロ
  • 収まらない場合 も「動く」か「クラッシュ」かの差を生む
  • Mixtralのexpert-streamingはMoEスパース性を活用し実用的な速度を実現

インストール方法

  • Rust 1.75+ および CMake が必要
  • ソースビルド手順
    • git clone --recurse-submodules https://github.com/hypura/hypura.git
    • cd hypura
    • cargo build --release
    • 実行ファイル:target/release/hypura
  • Homebrew対応予定

クイックスタート

  • ハードウェアプロファイリング (初回のみ、キャッシュされる)
    • hypura profile
  • GGUFモデルで推論
    • hypura run ./model.gguf --prompt "Hello, world"
  • 対話モード
    • hypura run ./model.gguf --interactive
  • ベンチマーク
    • hypura bench ./model.gguf
  • 配置プラン確認
    • hypura inspect ./model.gguf
  • 未検証モデルは--max-tokens 10から開始を推奨

Ollama互換サーバー・OpenClaw連携

  • Ollama互換HTTP API を提供
    • /api/generate/api/chat/api/tags
    • 例:hypura serve ./model.gguf
  • OpenClaw との連携
    • ~/.openclaw/openclaw.jsonでOllama base URLをhttp://127.0.0.1:8080に設定
    • CLI例:openclaw config set models.providers.ollama.baseUrl "http://127.0.0.1:8080"
  • 互換性shim不要、NDJSONストリーミング等も対応

サーバーオプション

  • hypura serve <MODEL> [OPTIONS]
    • --host <HOST>(デフォルト127.0.0.1)
    • --port <PORT>(デフォルト8080)
    • --context <N>(デフォルト4096)

アーキテクチャ

  • Cargoワークスペース
    • hypura:本体バイナリ・ライブラリ
      • CLI:src/main.rs
      • ロジック:src/lib.rs各モジュール
    • hypura-sys:llama.cpp用FFIバインディング(CMakeビルド)
  • 主要モジュール
    • scheduler/placement.rs:テンソルの階層配置
    • compute/inference.rs:推論エンジン
    • compute/nvme_backend.rs:NVMeストリーミング・キャッシュ
    • server/routes.rs:Ollama APIハンドラ
    • profiler/:ハードウェア検出
    • cli/bench.rs:ベンチマーク
    • model/tensor_role.rs:テンソル分類

FAQ・安全性・倫理

  • SSD寿命への影響
    • Hypuraは SSDへ書き込みを行わない
    • 読み出しのみ(pread+F_NOCACHE)、計算はRAM/GPU上
    • 書き込みはごくわずか(ベンチ結果JSON・統計ファイルなど)
  • 安全性
    • bench --baselineはRAM-4GBを超えると自動ブロック
    • 未検証モデルは--max-tokens 10から開始
  • ライセンス
    • MIT
  • 倫理
    • 本リポジトリのコードは作者が直接書いたものではなく、LLMを活用した実験的生成物
    • NVMe推論の有用性への好奇心と探求心から生まれたプロジェクト

Hypura はApple Siliconユーザーにとって、物理メモリの壁を超えて大規模LLMを快適に動かすための強力なツール。 Ollama/OpenClaw連携や安全設計 も魅力。大型LLM推論の新しい選択肢として注目。

Hackerたちの意見

「1Tパラメータモデル」ってどこから来たの?リポジトリには70Bパラメータ以下のモデルしか見当たらないんだけど。

うん、タイトルはリンクのどこにもないね。可能なのは間違いないけど、重要なのは速度だけだし、ここではそれについて何も学べないね…

可能性として言及してるけど、ベンチマークは共有しなかったんだ。正直言って、パフォーマンスが遅すぎて、特定のタスクにしか役立たないから。もっと実用的な使い方は派手じゃないけど、複数のトークン/秒を達成できる(つまり、すべての専門家を同時にメモリにロードする必要がない小さなMoEモデルとかね)。

これを https://news.ycombinator.com/item?id=47476422 と https://news.ycombinator.com/item?id=47490070 と比較するのは面白そうだね。デザインはすごく似てるけど、こっちはmmapを使ってるみたいで、前の実験によるとかなりのオーバーヘッドがかかるらしい。

これはLLMが書いたものだから…うん。

ただ、これはモデルの重みを大幅に量子化したバージョンを使ってないから、品質が落ちるんだよね。

これはかなりクールなプロジェクトだね!基本的には、スワップメモリを使ってRAMを拡張するようなもので、でも「スマート」にやるからNVMeを無駄にオーバーロードしないんだ。実際にその「スマートさ」がどう機能するのか気になるけど、生成中にNVMeに大きな負荷をかけるのは、たぶん長持ちさせるためには良くない選択だと思う。

これはNVMeにストレスや摩耗を与えてないよ、純粋な読み込みの作業だから。

でも「スマート」にやるからNVMeを無駄にオーバーロードしないって「NVMeをオーバーロードする」って何?初めて聞いたよ。 > 生成中にNVMeに大きな負荷をかけるのは本当に「NVMeにストレスをかけるべきじゃない」よ、もしそうなってるなら何かが深刻におかしい。俺はSSDをずっと使ってるけど、書き込み操作はフラッシュセル自体の寿命には影響するけど、コントローラーインターフェースには全く影響しないはずだよ、何か見落としてるのかな。

インテルのオプテインが墓の中で転がってる。

まだストレージユニットに4つの新品があるんだ。こういう時のためにね。冗談はさておき(実際に持ってるけど!)、Optaneはあんまり役に立たないと思うな(うちのは256GiBだし)。レガシーソフトウェアで、複数の読み書きが並行して行われないものを使ってるなら、便利なレガシーの補助ツールだけど、そうじゃなければNVMeより速くないよ、特に最近のやつはね。

インテルがそれを復活させるのはもう遅いかな?

Hacker Newsで議論の続きを見る