2026/08/02

70Bモデルを4GB GPUで動かす：AirLLM実用ガイド

70Bの大規模言語モデルは4GB GPUで本当に動くか？AirLLMのレイヤーストリーミング方式、必要なハードウェア、実装方法と性能課題を解説します。

はい、70BのLLMはAirLLMで約4GBのGPUメモリを使いながら実行できます。ただし、そのモデル全体が4GBのグラフィックスカードにはフィットしません。 AirLLMはチェックポイントをディスク上に保持し、1つのトランスフォーマーレイヤーをVRAMにロードし、そのレイヤーを計算して解放し、このプロセスを繰り返します。この技術はメモリをストレージI/Oと遅延と交換します。^[1]^[2]

この区別が全てです。70Bモデルは元のデモンストレーションで使用された精度で、依然として約130GBの重み保存が必要です。4GB という数字は、狭く構成された推論実行中のVRAMのピーク値を表しており、マシン全体のメモリ、ダウンロードサイズ、またはインタラクティブなパフォーマンスではありません。

TL;DR

AirLLMは極端なオフロードを可能にします。 ディスク上にレイヤーごとのシャードを保存し、アクティブなレイヤーだけをGPUに移動します。
元のテストは16GB Nvidia T4で4GB以下で測定されました。 物理的な4GBカードから完全に動作する高速チャットボットが実行されたわけではありません。^[1]
ディスク容量と速度は依然として重要です。 最初の実行ではチェックポイントをダウンロードして再シャード化し、生成された各トークンは重みをコンピュートデバイスを通じて繰り返しストリーミングします。
短いコンテキストはトリックの一部です。 元の例は100トークンの入力長を使用しました。より大きなKVキャッシュと実行時バッファーはより多くのメモリを消費します。^[1]
研究またはバッチ速度を期待してください、反応性のあるチャットではなく。 AirLLMの著者は、ローエンドハードウェアをインタラクティブアプリケーションではなくオフラインワークのために明示的に位置づけています。^[1]
出力速度が重要な場合はAPIを使用してください。 極端なローカルオフロードは学習と時々のプライベートジョブに役立ちます。ホストされた推論は通常、より単純な本番環境パスです。

「70B LLMを4GB GPUで実行する」の本当の意味

4つの異なるリソースが1つの見出しに圧縮されています。これらを分離することで、ほとんどの悪いハードウェア決定を防ぐことができます。

リソース	AirLLMが変えること	変えないこと
GPU VRAM	1つのレイヤーと実行時状態を大まかに常駐させる	完全なチェックポイントはVRAMにない
システムメモリ	遅延ロードとメタデバイスを使用して完全モデルの実体化を回避	Python、トークナイザー、バッファーおよびOSメモリは依然として存在
ディスク	完全モデルをレイヤー指向シャードとして保存	ダウンロードは4GBにはなりません
時間	プリフェッチはロードと計算の一部をオーバーラップできる	ストレージトラフィックは依然として中心的なボトルネック

元の2023年のガイドは、80個のトランスフォーマーレイヤーを持つLlama 2ベースの70Bチェックポイントを使用しました。1つのレイヤーは約1.6GBと推定され、その100トークン例のKVキャッシュは約30MBでした。測定されたプロセスはNvidia T4で4GB GPU メモリ以下にとどまりました。^[1]

AirLLMの現在のリポジトリは、同じ考え方をLlama 3.x、Qwen、DeepSeek、Mixtral、Phi、Gemmaおよび他の家族に拡張しています。現在のリファレンステーブルは、完全精度のLlama 3.x 70Bが約4GB VRAMで実行されることを依然としてリストアップしています。^[2] これをプロジェクトクレームとメモリターゲットとして扱ってください。すべての4GBカードのスループットベンチマークではなく。

AirLLMレイヤーごとの推論がどのように機能するか

AirLLMはトランスフォーマーレイヤーをディスクから4GB GPUステージングエリアを通じてストリーミング

トランスフォーマーは順番にブロックを実行します。レイヤー12はレイヤー11の隠れた状態を消費し、レイヤー13はレイヤー12を待ちます。AirLLMはこの順序を5部構成のパイプラインで利用します。

空のモデルシェルを作成します。 Hugging Face Accelerateのメタデバイスは、すべてのパラメーターに対して実際のストレージを割り当てずにアーキテクチャを初期化します。^[3]
チェックポイントをレイヤーごとに再シャード化します。 Safetensorsファイルは再配置されるため、1つのレイヤーをロードするために関連のない複数ギガバイトシャードを読む必要がありません。
計算デバイスに1つのレイヤーをロードします。 その時点で、そのレイヤーと必要な実行時テンソルだけがGPUを占有します。
計算、解放、続行します。 隠れた状態は前に進み、レイヤーの重みはVRAMを離れます。
生成されるトークンごとに繰り返します。 プリフェッチは計算とストレージI/Oの一部をオーバーラップできますが、繰り返されるデータ移動を排除することはできません。

FlashAttentionはタイル張り、I/O対応計算を通じてattentionが使用する一時的なメモリを削減します。^[4] アクティブなレイヤーをフィットさせるのに役立ち、レイヤーストリーミングは非アクティブなウェイトが待つ場所という別の問題を解決します。

依然として必要なハードウェアとストレージ

GPUは1つのコンポーネントに過ぎません。70Bチェックポイントをダウンロードする前に、マシンの残りの部分を確認してください。

互換性のあるコンピュートパス。 ヘッドラインデモンストレーションはNvidia CUDAを対象とします。AirLLMはApple SiliconとCPUパスも文書化していますが、メモリとパフォーマンスの特性は異なります。^[2]
チェックポイントと変換のための十分なディスク容量。 プロジェクトは最初の実行レイヤー分割がディスク集約的であることを警告しています。delete_original オプションはストレージが限定されている場合、変換後に元のチェックポイントを削除できます。
高速なローカルストレージ。 NVMe はレイヤーストリーミングを無料にしませんが、遅いハードドライブはすでにI/Oバウンドループを大幅に悪化させます。
短い初期コンテキストと出力。 小さなプロンプトと20～40の新しいトークンから始めてください。より長いコンテキストはKVキャッシュを増やし、より長い出力は完全なレイヤートラバーサルを何度も繰り返します。
モデルアクセス。 ゲート付きのメタチェックポイントはHugging Face トークンとモデルライセンスの承認を必要とします。

70Bダウンロードをしてこの環境が機能するかテストするだけで始めないでください。最初に8B以下のサポートされているモデルを実行し、CUDAとストレージパスを確認してから、スケールアップしてください。

70Bモデルを使ってAirLLMを試す方法

現在のプロジェクトクイックスタートは AutoModel を使用します。これはHugging Face リポジトリIDから適切な実装を選択します。^[2] 最初にCUDAドライバーと互換性のあるPyTorch ビルドをインストールしてから、AirLLMをインストールしてください。

python -m venv .venv
source .venv/bin/activate
pip install airllm

ソースコードではなく環境変数でシークレットを保持してください：

export HF_TOKEN="your_hugging_face_token"

次に、意図的に小さな生成を実行してください：

import os

from airllm import AutoModel

MODEL_ID = "meta-llama/Llama-3.3-70B-Instruct"
MAX_LENGTH = 128

model = AutoModel.from_pretrained(
    MODEL_ID,
    hf_token=os.environ["HF_TOKEN"],
    layer_shards_saving_path="/data/airllm-shards",
)

prompt = ["Explain layer-wise inference in three short sentences."]
tokens = model.tokenizer(
    prompt,
    return_tensors="pt",
    return_attention_mask=False,
    truncation=True,
    max_length=MAX_LENGTH,
    padding=False,
)

result = model.generate(
    tokens["input_ids"].cuda(),
    max_new_tokens=32,
    use_cache=True,
    return_dict_in_generate=True,
)

print(model.tokenizer.decode(result.sequences[0]))

これはリポジトリクイックスタートの最小限の適応であり、ユニバーサル環境ロックファイルではありません。AirLLM、Transformers、PyTorch、CUDA、およびモデルのリモートコードはバージョン固有の制約を持つ可能性があるため、本番マシンにインストールする前に現在のリポジトリの問題を確認してください。

最初の実行時に何が起こるか

最初のローンチは後のローンチを表すものではありません。AirLLMはモデルをダウンロードし、そのアーキテクチャを検査し、チェックポイントをレイヤーシャードに分割し、構成されたパスにそれらのシャードを書き込む必要があります。この変換を中断するか、ディスクがいっぱいになると、不完全なsafetensorsヘッダーが残る可能性があります。プロジェクトのFAQは、不完全なキャッシュをクリアし、スペースを確保した後に再実行することをお勧めしています。 ^[2]

4つのシグナルを個別に監視してください：

nvidia-smi -l 1          # GPUメモリと使用率
free -h                  # システムメモリ
df -h /data              # 空きディスク容量
iostat -xz 1             # ストレージ飽和度（systatがインストールされている場合）

低いVRAM数値だけでは成功ではありません。最初のトークンまでの時間、出力トークンあたりの秒数、ディスク読み取り容量、および繰り返される実行が完了したシャードを再利用するかどうかを記録してください。

適合しても、AirLLMが遅い理由

通常のGPU推論は重みを一度ロードし、多くのトークンとリクエストで再利用します。極端なレイヤーオフロードはこの利点を逆転させます。新しいトークンはモデルの完全なスタックを通過する必要があり、重みはストレージから小さなピースでGPUに移動します。

AirLLMはプリフェッチを追加して、ロードと計算をオーバーラップさせ、4ビットまたは8ビットのブロック単位重み圧縮を提供してストレージトラフィックを削減します。リポジトリは圧縮からの最大3倍の改善を報告していますが、実際のパフォーマンスはモデル、ストレージ、GPU、コンテキスト、およびソフトウェアバージョンに依存します。^[2]

これにより、次の方法がより信頼できるようになります：

そうでなければロードできないモデルの1回限りの評価；
オフラインドキュメント分類または抽出；
レイテンシーが二次的な低ボリュームのプライベートバッチ処理；
メモリスケジューリングとモデルアーキテクチャの研究。

ライブチャット、エージェントループ、高い同時実行性、またはレイテンシーターゲットを持つAPIの場合には悪いデフォルトです。

AirLLMと量子化とAPI

アプローチ	ローカルウェイト	一般的な目的	主なトレードオフ
AirLLMレイヤーストリーミング	はい	過度に大きなモデルを実行可能にする	非常に低いスループットと大量のディスクI/O
4ビット量子化	はい	モデルをより小さく高速にする	密な70Bモデルは依然として重みに4GB以上必要
CPU/GPUオフロード	はい	適度に過度なモデルをRAMとVRAMに分割	相当なシステムメモリが必要
ホストされたAPI	いいえ	インタラクティブまたは本番推論を取得	リモート実行、使用コスト、プロバイダー信頼

実験がポイントの場合はAirLLMを選択してください。ローカルインタラクティビティがポイントの場合は、より小さい量子化モデルを選択してください。70Bクラスモデルと使用可能な応答時間の両方が要件の場合は、APIを選択してください。

同じ区別がはるかに大きな主張にも適用されます。私たちのKimi K3を4GB GPUで実行する分析は、疎専門家がストリーミング単位を変更するが、チェックポイントを削除しない理由を説明しています。現在のロングコンテキストAPIの例については、MiniMax M3 APIガイドを参照するか、ライブモデルカタログを参照してください。

実践的な決定チェックリスト

70B LLMを4GB GPUで試す前に、これらの質問に答えてください：

目的は実行を証明することですか、それとも応答性のある製品を構築することですか？
ディスクは元のモデルと変換中のそのレイヤーシャード化されたコピーを保持できますか？
チェックポイントアーキテクチャは現在のAirLLMリリースで明確にサポートされていますか？
ワークロードは長い最初のトークンまでの時間と低スループットを許容できますか？
モデルライセンスは意図された使用を許可していますか？
小さなチェックポイントで最初に同じソフトウェアスタックをテストしましたか？

2～4の質問への答えが「いいえ」の場合、4GB見出しは有用なデプロイメント計画ではありません。

Gavin Li. Unbelievable! Run 70B LLM Inference on a Single 4GB GPU with This New Technique. November 30, 2023. huggingface.co/blog/lyogavin/airllm
AirLLM. AirLLM repository, current quickstart, supported models, configuration, and FAQ. Retrieved August 2, 2026. github.com/lyogavin/airllm
Hugging Face Accelerate. Big Model Inference and the meta device. huggingface.co/docs/accelerate/usage_guides/big_modeling
Dao et al. FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness. NeurIPS 2022. arxiv.org/abs/2205.14135