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

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

概要

  • 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より速くないよ、特に最近のやつはね。

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

pmem

インテルが良いことを途中でやめないわけがないよね。それでも、4つのドライブでRAID 0カードを作って16xレーンを満たすことはできないのかな?それがPCIeで押し通せる最大値だしね。

メモリスタもこのAIブームでは影が薄いね。10年前にはもうすぐそこにあったのに。

実際の問題は、読み取りパターンがNVMeの帯域幅を満たすほど連続的なのか、それともアテンションレイヤーのアクセスパターンがランダムすぎてスループットを落とすのかってことだね。 decentなNVMeでの連続読み取りは5〜7 GB/s出るけど、ランダム読み取りはキューの深さによって500 MB/sくらいに落ちる。1Tモデルだと、前方パスごとに約2TBの重みをストリーミングする必要がある。ピークの連続読み取りでも、トークンごとに300秒以上かかるから、インタラクティブな使用にはあまり向いてないけど、レイテンシを気にしないバッチ推論には問題ないかもね。それでも、面白いコンセプトの証明だと思う。『動く』と『役に立つ』の間のギャップが面白いところだね。

1Tモデルだと、前方パスごとに約2TBの重みをストリーミングする必要がある これってMoEモデルのポイントを完全に見失ってない?MoE推論はスパースだから、各レイヤーで重みのほんの一部しか読まないんだよね。それでも、各エキスパートレイヤーはかなり小さい(大体数MiB)けど、その読み取りはNVMeには十分な大きさだよ。

うん、確かに同意するよ。これは機能的なユースケースというよりはPOCだね。ただ、多くの小さいMoEモデルにはこの方法が実際に役立つし、複数のトークン/秒を達成できる可能性があるよ。

M1 Maxでのキュー深度1の4Kランダムリードは、約65MB/sだよ。

多くのローカルワークロードでは、1トークン/秒未満は前景では役に立たないけど、バックグラウンドでは全然問題ないよ。「これがクラッシュする」か「これが一晩で終わる」なら、まだ意味のある能力の向上だね。

MoEのポイントがここで重要だよ。つまり、スパースアクティベーションは、フォワードパスごとに2TB全部を読み込むわけじゃないけど、アクセスパターンが順次からランダムに変わるのが、NVMeにとっては最悪のケースなんだ。エージェント推論のワークロードについて、ピークスループットよりも一貫したレイテンシが欲しいなってずっと考えてる。

メンテナンス担当者への提案だけど、比較表にはかなり古いモデルが載ってるね。Qwen 2.5 14BやMixtral 8x7B、Llama 3.3 70Bとか。今、AppleハードウェアでQwen 3.5 MoEモデルがすごい結果を出してるって報告がたくさんあるよ(ストリーミングエキスパート - https://simonwillison.net/2026/Mar/24/streaming-experts/を見てみて)。そのモデルを表に入れるといいな。もしうまくいけば、1TパラメータのKimi K2.5も入れてみて。https://twitter.com/seikixtc/status/2036246162936910322 と https://twitter.com/danpacary/status/2036480556045836603もチェックしてみて。

サイモン、ちょっと脱線だけど、あなたのウェブサイトが動いてないみたい。 > アプリケーションでエラーが発生し、ページを表示できませんでした。アプリケーションの所有者なら、詳細を確認するためにログをチェックしてください。Heroku CLIからこのコマンドでできるよ。simowillison.netに行くとこのエラーが出るんだ。でも、例えば他のランダムなブログ/リンクはちゃんと動くよ: https://simonwillison.net/2026/Mar/19/openai-acquiring-astra... (trivy/litellmについて何か書いてるか見たくてあなたのウェブサイトをチェックしたんだ。litellmのスペースで何が起こったかを確認するのを強くお勧めするよ。あなたの考えを読みたいからね。)良い一日を、サイモン! 編集: 今はウェブサイトが動いてるけど、前に何が悪かったのかはわからないな(Herokuの問題かな?)今は動いてるよ。 編集-2: ウェブサイトが動いた後、すでにそのことについての投稿があるのを見たよ。

Kimiの例にトークンレートの指標がないのは残念だね。

これをシェアしてくれてありがとう!もしHypuraでベンチマークを自分で試してみたいなら、喜んで統計に追加するよ。それ以外だったら、やることリストに追加しとくね :)

コンシューマーハードウェア(MacBook Pro、Mac Studio)は、高速なユニファイドメモリとNVMeストレージを搭載してるけど、容量が限られてる。32GBのM1 Maxでは、40GBのモデルをそのまま読み込むことはできない — OSはスワップスラッシュを繰り返して、OOMキラーが介入するまで続く。macOSにはその意味での「OOMキラー」はないんだ。(スワップスペースが不足した時のキラーはあるけど、かなり弱い。)だから、どうなるかというと、メモリの配線が失敗するか、すごく遅くなってパニックになるかのどちらかだね。

「できるだけ多くのメモリ」というのはモデルの容量には合ってるけど、帯域幅を見落としてる。Apple Siliconには異なるレベルがあって、M4 Proは273 GB/s、M4 Maxは546 GB/s、M4 Ultraは819 GB/sの帯域幅を持ってる。帯域幅は、モデルがメモリに収まった後のtok/sを決定する。M4 Maxは、同じモデルでM4 Proの2倍のデコード速度を提供する。Hypuraがやることに関しては、Maxがベストな選択だね。64GBで70BをQ4で読み込めて、余裕もあるし、Proの2倍の帯域幅があれば、生成が実際に使えるレベルになるんだ。