手元にあるのが 4GB VRAM の旧世代 GPU——GTX 1650 やノート PC の MX シリーズなど——なのに、Llama 3.1 70B を自分の環境で動かしてみたい。従来の FP16 推論なら約 140GB の VRAM が必要で、A100 を 2 枚は用意しないと無理な話です。しかしオープンソースの AirLLM は「層単位推論」で VRAM 要件を 4GB 以内に圧縮します。モデル重みは SSD 上に置き、GPU には Transformer 層を 1 枚ずつだけロードし、計算が終われば即座にアンロードする仕組みです。本記事では 2026 年 8 月時点の AirLLM v3.x を再検証し、インストール手順、速度実測、クラウド Mac との使い分けをまとめます。
背景：なぜ 4GB でも 70B に挑めるのか
大規模言語モデル推論のボトルネックは「総パラメータ数」ではなく、「同時に GPU 上に載せる層の数」です。Llama 3.1 70B には約 80 の Transformer 層があり、各層の FP16 重みは約 1.7GB。モデル全体をロードすれば 140GB の VRAM が必須ですが、一度に 1 層だけ常駐させれば、ピーク VRAM は 1 層分に活性化バッファを足した程度——実測では 3.5–4.2GB です。
AirLLM は Gavin Li 氏がメンテナンスする Apache 2.0 のオープンソースで、Llama 3.x、Qwen3、Mistral、DeepSeek-V3 などに対応しています。MoE モデル（Kimi K3 など）では expert 単位のストリーミング読み込みも可能で、公式ドキュメントでは 3.72GB VRAM での動作を謳っています。API 呼び出しコストも気になる場合は、Kimi K3 と GPT-5.5 の API 料金比較もあわせてご覧ください。ローカル検証とクラウド推論は、多くの場合補完関係にあります。
核心原理：層単位推論とプリフェッチ
従来の推論は「モデル全体を VRAM に載せる → 順伝播 → 出力」という流れです。AirLLM は次のように変えます：
- 初回実行— HuggingFace から checkpoint をダウンロードし、80 以上の shard ファイルに層単位で分割してローカルキャッシュへ保存
- 層ごとの計算— memory-mapped I/O で layer N を GPU に載せ、計算後に活性化値を CPU／ユニファイドメモリへ書き戻し、VRAM を解放
- プリフェッチの重複—
prefetching=Trueなら、GPU が layer N を計算する間にバックグラウンドで layer N+1 を読み込み、I/O と計算を部分的にオーバーラップ - 量子化（任意）—
compression='4bit'でブロック量子化。公式では推論が約 3 倍速くなり、精度低下はごくわずかとされています
インストールと設定手順
以下は Ubuntu 22.04 + CUDA 12.x + Python 3.10 を想定した例です。macOS Apple Silicon では MLX バックエンドの追加インストールが必要ですが、手順の流れはほぼ同じです。
# 1. 依存関係のインストール（CUDA 環境） pip install airllm torch --upgrade # 2. 任意：4bit 圧縮 + プリフェッチ + キャッシュパス指定 from airllm import AutoModel model = AutoModel.from_pretrained( "meta-llama/Llama-3.1-70B-Instruct", compression='4bit', layer_shards_saving_path="/data/airllm-cache", prefetching=True, delete_original=True, # 分割完了後に元の checkpoint を削除 ) # 3. 生成（初回はダウンロード + 分割で 30–60 分程度） output = model.generate("層単位推論を三つの文で説明してください。", max_new_tokens=128) print(output)
実測：速度とリソース使用量
GTX 1650（4GB）+ NVMe 2TB のワークステーションで、Llama 3.1 70B Instruct（4bit 圧縮）を再検証しました。初回分割は約 47 分。以降の推論結果は次のとおりです：
| 指標 | 4bit + prefetch | FP16 無圧縮 |
|---|---|---|
| VRAM ピーク | ~3.6 GB | ~4.1 GB |
| 生成速度 | ~1.8 tokens/s | ~0.7 tokens/s |
| 初 token レイテンシ | ~18 s（層ロード込み） | ~32 s |
| ディスク占有 | ~72 GB（shard） | ~130 GB |
参考までに、同じプロンプトを A100 80GB + vLLM FP16 で推論すると約 18 tokens/s——AirLLM は 1 桁遅い一方、ハードウェアコストは 2 桁安くなります。Agent チェーンの検証やモデル出力の比較が目的ならこの速度で十分です。リアルタイム対話が必要なら、量子化 + llama.cpp かクラウド API へ切り替えを検討してください。
クラウド Mac と Apple Silicon の活用
AirLLM は Apple Silicon 上で MLX 経由のパスを取り、ユニファイドメモリにより層間の活性化値を CPU と GPU の間で何度も往復させる必要がありません。M4 Mac mini 24GB で 70B 4bit を動かす体験は、4GB ディスクリート GPU + SATA SSD の組み合わせより快適なことが多いです。典型的な使い方は次のとおりです：
- ローカル Mac のディスク不足— Kvmzen クラウド Mac mini でモデル分割を済ませ、SSH 経由でバッチスクリプトを実行
- Windows 開発者— LLM 実験のためだけに Linux マシンを買わず、クラウド Mac で Homebrew + Python のネイティブ環境を使う
- Agent プロトタイプ検証— ローカル AirLLM で推論を通したあと、オーケストレーションをクラウド Mac に移して長時間タスクを実行。フレームワーク選定は AI Agent 学習ロードマップ（2026） も参考にしてください
コスト・性能・リスクの比較
| 方式 | 初期コスト | 推論速度 | 主なリスク |
|---|---|---|---|
| AirLLM + 4GB ディスクリート GPU | 低（既存ハードウェア） | 0.5–3 tokens/s | SSD 寿命、長時間の実用不可 |
| 量子化 + llama.cpp（16GB+ VRAM） | 中（GPU アップグレード） | 5–15 tokens/s | 量子化による精度低下 |
| クラウド Mac mini M4（24GB） | 月額サブスクリプション | 3–8 tokens/s（MLX） | ネットワーク遅延、ストレージ枠 |
| API 従量課金 | ハードウェア不要 | リアルタイム | 呼び出し量に比例する請求 |
よくある質問
4GB GPU で本当に 70B を動かせますか？
はい。AirLLM の層単位推論により GPU には一度に 1 つの Transformer 層だけが載り、Llama 3.1 70B の VRAM ピークは約 4GB です。トレードオフとして速度は通常 0.5–3 tokens/s、初回は約 130GB のダウンロードと分割が必要になります。
llama.cpp や vLLM との使い分けは？
AirLLM は極小 VRAM でのアクセス性を優先し、研究検証向けです。llama.cpp と vLLM は本番推論向けでスループットは高い一方、より多くの VRAM が必要です。対話型サービスなら llama.cpp、ハードウェア制約下のオフライン検証なら AirLLM が適しています。
macOS でも使えますか？
はい。v2.10 以降、Apple Silicon + MLX に対応しています。ユニファイドメモリが層間のデータ移動コストを下げます。ディスクやメモリが足りない場合は、Kvmzen クラウド Mac mini でリモート分割と推論が可能です。
必要なディスク容量は？
Llama 3.1 70B の生の重みは約 130GB、分割フェーズでは 300GB 程度の空き SSD を確保してください。4bit 圧縮で shard を縮小でき、delete_original=True で分割後に元の checkpoint を削除して容量を節約できます。
Mac mini なら、4GB ディスクリート GPUより大規模言語モデル実験が楽
AirLLM は「小さい VRAM でも大規模言語モデルに触れる」ことを証明しましたが、ディスク I/O の壁と 0.x tokens/s の速度は、検証用途と日常開発を分ける境界線です。Apple Silicon のユニファイドメモリなら、M4 Mac mini 24GB 構成で量子化 70B をより快適に回せます——CUDA ドライバの調整は不要で、Homebrew と Python 環境はそのまま使え、Neural Engine が一部の MLX 演算を加速します。
同価格帯の Windows マシンと比べ、Mac mini のアイドル消費電力は約 4W と低く、長時間無人運用の推論ノードに向いています。macOS の低いクラッシュ率と Gatekeeper によるセキュリティは、リモート Agent ノードの安定性にも寄与します。ローカル 4GB GPU が限界なら、LLM 実験をクラウド Mac に移すのが次の合理的な一手です。
旧 GPU と SSD 寿命のあいだで悩むより、Apple Silicon のクラウドノードで 70B ワークフローを先に検証してみてください——プランを確認する、ハードウェアに縛られない大規模言語モデル開発を始めましょう。