- GPU・RAM・NVMe間のテンソル配置を最適化して大規模言語モデルを実行するストレージ階層認識型推論スケジューラ
- 32GBのMac miniで**Mixtral 8x7B(31GB)**モデルを2.2 tok/s、**Llama 70B(40GB)**モデルを0.3 tok/sで実行可能
- アクセスパターンとハードウェア帯域幅を分析し、物理メモリを超えるモデルも安定して動作、従来のllama.cppがOOMで失敗していたモデルまで処理可能
- MoE構造のエキスパートルーティング、ニューロンキャッシュ、プリフェッチによりI/Oを最大75%削減し、キャッシュヒット率99.5%を達成
- モデルサイズとハードウェアに応じてFull-resident、Expert-streaming、Dense FFN-streamingモードを自動選択し、最適な性能を維持
- Ollama互換HTTP APIを提供し、OpenClawなどと連携可能。SSDは読み取り専用で使用するため、寿命を低下させずにNVMeベース推論をサポート
概要
- HypuraはApple Silicon環境向けのストレージ階層認識型LLM推論スケジューラで、GPU・RAM・NVMe間のテンソル配置最適化を行うツール
- アクセスパターン、帯域幅コスト、ハードウェア性能に基づいてテンソルを分散配置し、物理メモリを超える大規模モデルも安定して実行可能
- 32GBのMac Miniで**Mixtral 8x7B(31GB)**モデルを2.2 tok/s、**Llama 70B(40GB)**モデルを0.3 tok/sで実行可能
- 同一環境ではllama.cppはOOM（Out of Memory）で実行不可
問題の背景
- コンシューマ向けMacは高速なユニファイドメモリとNVMeストレージを備える一方で、メモリ容量には制約がある
- たとえば32GBのM1 Maxでは40GBモデルを直接ロードできず、過剰なスワップやOOM終了が発生する
- Hypuraはモデル構造を解析し、階層ごとに最適配置を行うことでこの問題を解決
モデル構造に基づく階層配置
- NormsおよびEmbeddings: 小さいが毎トークンごとにアクセスされるためGPUに固定
- MoE Expert Routing: スパース性を活用し、1トークンあたり8個中2個のエキスパートのみを有効化
- ルーターのインターセプトにより有効なエキスパートを識別し、必要な部分だけをNVMeからロード
- I/Oを75%削減、ニューロンキャッシュ99.5%ヒット率を確保
- **共活性追跡（co-activation tracking）**により次に有効化されるエキスパートを予測し、事前プリフェッチを実行
- Dense FFN Weights: モデルサイズの約60%を占める
- NVMeから動的プールバッファを通じてストリーミング
- **プリフェッチ先読み深度（prefetch lookahead depth）**は利用可能メモリに応じて自動調整
- その結果、従来のmmap方式ではクラッシュしていたモデルも実行可能になり、メモリに収まるモデルはMetal GPU速度でオーバーヘッドなく動作
動作方式
- HypuraはGGUFファイルを読み込み、GPU・RAM・NVMe帯域幅をプロファイリング
- 各テンソルを次の3階層のいずれかに配置
- GPU(Metal): Attention、Norm、Embedding層
- RAM: GPUに積載できないオーバーフロー層
- NVMe: 残りの層、
F_NOCACHE + preadで直接I/Oを実行
- モデルサイズとハードウェアに応じて推論モードを自動選択
- Full-resident: GPU+RAMにモデル全体を常駐させ、NVMe I/Oなし
- Expert-streaming: MoEモデル向け。非エキスパートテンソルのみGPUに常駐し、エキスパートテンソルはNVMeストリーミング
- Dense FFN-streaming: 非MoEの大規模モデル向け。Attention+NormはGPUに、FFNはNVMeストリーミング
- プールバッファサイズ、プリフェッチ深度、メモリ予算はハードウェアプロファイルに基づいて自動計算
性能
- テスト環境: M1 Max、32GBユニファイドメモリ、NVMe 5.1GB/s
- 主なベンチマーク結果
- Qwen 2.5 14B Q4_K_M (8.4GB): GPU完全常駐、21 tok/s
- Mixtral 8x7B Q5_K_M (30.9GB): Expert-streamingモード、2.2 tok/s、99.5%キャッシュヒット率
- Llama 3.3 70B Q4_K_M (39.6GB): Dense FFN-streamingモード、0.3 tok/s、24スロットプール、7層プリフェッチ
- メモリに収まるモデルはオーバーヘッド0、超過モデルはHypuraにより実行可能な状態を維持
インストールと実行
- Rust 1.75+およびCMakeが必要
- インストール手順
git clone --recurse-submodules https://github.com/hypura/hypura.git
cd hypura
cargo build --release
- 実行例
hypura profile
hypura run ./model.gguf --prompt "Hello, world"
hypura run ./model.gguf --interactive
hypura bench ./model.gguf
hypura inspect ./model.gguf
- 未検証モデルは
--max-tokens 10でのテストを推奨
Ollama互換サーバー
- HypuraはOllama互換HTTP APIを提供し、OpenClawなどOllamaベースのツールと完全互換
hypura serve ./model.gguf
Endpoint: http://127.0.0.1:8080
API: /api/generate, /api/chat, /api/tags
- 主なエンドポイント
| Endpoint |
機能 |
GET / |
状態確認 |
GET /api/tags |
ロード済みモデル一覧 |
GET /api/version |
サーバーバージョン |
POST /api/show |
モデルメタデータ |
POST /api/generate |
テキスト生成 |
POST /api/chat |
対話生成 |
- OpenClaw連携は
~/.openclaw/openclaw.jsonでOllamaのbase URLをHypuraに指定
- サーバーオプション
hypura serve [OPTIONS]
--host デフォルト 127.0.0.1
--port デフォルト 8080
--context デフォルト 4096
アーキテクチャ
- Cargo workspace構成で、2つのcrateから成る
hypura: メインバイナリおよびライブラリhypura-sys: llama.cpp FFIバインディング（CMakeビルド）
- 主なモジュール
| モジュール |
役割 |
scheduler/placement.rs |
GPU/RAM/NVMe間のテンソル配置最適化 |
compute/inference.rs |
推論エンジンおよびサーバー向けロード/生成関数 |
compute/nvme_backend.rs |
NVMeストリーミング、ニューロンキャッシュ、評価コールバック |
server/routes.rs |
Ollama互換HTTPハンドラ |
profiler/ |
ハードウェアプロファイリング |
cli/bench.rs |
ベンチマークツール |
model/tensor_role.rs |
テンソル役割分類 |
FAQ
-
SSD寿命の問題はない
- HypuraはSSDからの読み取りのみを実行し、書き込みは行わない
- NVMe I/Oは
pread() + F_NOCACHEによる読み取り専用で実行
- SSDはコールドストレージの役割のみを担い、演算はRAM/GPUで行われる
- 書き込みが発生するのはベンチマーク結果JSONや統計ファイルなど、KB単位のごく小さい水準
安全ガイドライン
- モデルがRAM上限（–4GBの余裕）を超える場合、
bench --baselineをブロック
- 未検証モデルは
--max-tokens 10でテスト
- テストモデルは
./test-models/ディレクトリに保存
ライセンス
倫理的告知
- リポジトリ内のコードは作者がすべてを直接記述したものではない
- LLMを活用した指示ベースのコード生成実験として制作
- NVMeベース推論の活用可能性を探るためのプロジェクト
1件のコメント
Hacker Newsのコメント
メンテナーに提案したい。現在の比較表には Qwen 2.5 14B、Mixtral 8x7B、Llama 3.3 70B といった古いモデルが含まれている
最近は Apple ハードウェア上で Qwen 3.5 MoE モデルが驚くほど高性能だという報告が多い
Simon Willisonの記事を参考にするとよいかもしれない
可能であれば Kimi K2.5 (1T パラメータ) モデルも表に追加されるとよい
関連ツイート: seikixtc, danpacary
Heroku 関連のエラーメッセージが表示されていたが、今は再び正常に動作している
この記事を見ようとして訪れたのだが、litellm 関連の記事もすでに書いていたんですね。興味深く読んだ
ローカル作業では、毎秒 1 トークン未満の速度でもバックグラウンド作業なら十分実用になる
「即座に終了」と「一晩で完了」の違いは、依然として意味のある性能の飛躍だ
実際には、読み取りパターンがどれだけ逐次的(sequential) かが重要だ
NVMe は逐次読み取りでは 5–7GB/s だが、ランダム読み取りでは 500MB/s 程度まで落ちる
1T モデルの場合、fp16 基準では 1 回の forward pass で 2TB をストリーミングする必要があるため、理論上は 1 トークンあたり 300 秒以上かかる
対話用途には不向きだが、バッチ推論(batch inference) には可能性がある
ただし小型の MoE モデルでは毎秒複数トークンを生成できるため、実際に使える
2TB 全体を読むのではなく、一部のエキスパート層にだけアクセスする
各層は数 MiB 単位なので、NVMe アクセス効率もそれほど悪くない
「1T パラメータモデル」という話がどこから出てきたのか気になった。リポジトリには 70B 以下のモデルしか見当たらない
現実的なのは、より小さくて毎秒複数トークンを生成できる MoE 系だ
MoE のポイントは、疎活性化によって 2TB 全体を読まないことだ
ただしアクセスパターンがランダム化されるため、NVMe には最悪の条件になる
エージェント推論のようにレイテンシ(latency) が重要な作業では、この点が核心になる
Intel Optane が墓の中で身じろぎしていそうな状況だ
ただ実際には NVMe より速いわけではない。並列読み書きに対応したソフトウェアでは差はほとんどない
それでも RAID 0 で 4 台束ねれば PCIe 16x の帯域を使い切れそうだ
コンシューマー向け Mac ハードウェアは高速なユニファイドメモリと NVMeを備えているが、容量には限界がある
32GB の M1 Max で 40GB モデルをロードすると、スワップが暴走して最終的にpanic 状態になる
macOS には Linux のような OOM killer がなく、単に swap 領域が尽きるだけだ
「メモリをできるだけ多く」確保することも重要だが、より大きな要因は帯域幅(bandwidth) だ
M4 Pro は 273GB/s、M4 Max は 546GB/s、M4 Ultra は 819GB/s
モデルがメモリに収まった後は、帯域幅がトークン速度を決める
Hypura の観点では M4 Max がスイートスポットだ。64GB あれば 70B モデル(Q4)を余裕を持って動かせて、Pro の 2 倍の速度で生成できる
このプロジェクトは事実上スマートなスワップメモリのように動作する
NVMe を過度に使わないよう調整している点が興味深い
ただ、実際に NVMe に負荷が大きくかかるなら、寿命の短縮が懸念される
SSD は書き込み回数に応じてセル寿命が縮むが、読み取り負荷でコントローラが損傷することはほとんどない
もしそうなら、システムに別の問題があるということだ
このプロジェクトを 以前の実験、別の試み と比較するとよいかもしれない
今回のものはmmap ベースなのでオーバーヘッドが大きいという報告があった