AirLLM：4GBのGPU上で70Bモデルを実行できるのか？テストと limites

#AirLLM が掲げる約束：4 GB の VRAM で 70B モデルを実行

Q4 量子化した 70B モデルを完全にメモリに読み込むには、約 40 GB の VRAM が必要です。つまり、RTX 4090（24 GB）にもう1枚のカードを追加するか、大容量のユニファイドメモリを搭載した Mac Studio が必要になります。AirLLM は、同じモデルを 4 GB のカードでも動かせると主張しており、控えめな性能の GTX 1650 や Google Colab の無料 T4 も含まれます。モデルのサイズをごまかすマーケティング上のトリックではありません。回答を生成するのは、FP16 または 4/8ビットの完全な 70B モデルです。

秘密は3つの言葉に集約されます：モデルは決してVRAM全体に読み込まれません。AirLLMはネットワークをレイヤーに分割し、ディスクに保存し、計算中にGPUに一度に1つのレイヤーのみを読み込みます。したがって、VRAMには常に1つのレイヤーの重みと現在のアクティベーションのみが含まれます。これが、わずか数ギガバイトで済む理由です。

#レイヤー ストリーミングはどのように機能するか

Transformer型のLLMは、同じ構造（アテンション＋フィードフォワード）の層を積み重ね、順番に処理を通す仕組みです。Llama 70Bには80層あります。従来の推論では、80層すべてを一度にVRAMに読み込み、生成中はすべての層をメモリに保持します。AirLLMはこの原則を逆転させます。

ディスク上での重みの分割

初回読み込み時、AirLLMはモデルの重みをレイヤーごとに個別のファイルに分割し、SSDに保存します。この変換ステップはモデルごとに一度だけ実行されます。

オンデマンドロード

トークンを生成するには、エンジンがGPUに1層をロードし、計算を行ってVRAMを解放した後、2層をロードし、計算を繰り返し、80層まで進みます。

VRAMは一定です

任意の時点で、VRAMに存在するのは1つのレイヤーのみです。メモリピークは、最大のレイヤーとコンテキストの長さに依存し、モデルの総サイズには依存しません。

プリフェッチとディスク上の重みの量子化

AirLLMは現在のレイヤーの計算中に次のレイヤーを事前に読み込み、ディスク上の重みをブロックごとに量子化してデータの読み込み量を削減できます。

ボトルネックは一目瞭然です。生成される各トークンごとに、モデルの重み全体をディスクから読み込む必要があります。70Bの場合、1つのトークンに対してSSDからGPUへ数十GBのデータが転送されます。AirLLMの性能と限界のすべてが、まさにこの部分で決まります。

#前提条件とインストール

AirLLMは、PyTorchとHugging Faceのエコシステムを基盤とするPythonライブラリです。Ollamaとは使い方が異なり、デーモンもrunコマンドもありません。Pythonスクリプトにインポートして使います。始める前に必要なものは以下のとおりです。

GPU

VRAMを4GB以上搭載したNVIDIAのカードなら、どれでも利用できます（CUDA）。Apple Silicon（MPS）とCPUにも対応していますが、動作はさらに遅くなります。

ディスク

高速なNVMe SSDが必須です。さらに、展開後のモデルを保存する容量も必要です（70Bモデルで約40GB、FP16ではさらに多くなります）。

システムRAM

16GBは十分です。AirLLMはモデルをRAMにロードしません。CPUオフロードの従来方式とは異なります。

Python

Python 3.10以降の環境にPyTorchおよびCUDAが正しくインストールされていること

pip install airllm

#70Bモデルを4GBで実行するテスト

Llama 70Bをロードし、質問するための最小限のコードは十五行程度です。AirLLMは最初の呼び出し時に層ごとに分割を担当します（複数分のコンバージョン時間とHugging Faceからのモデルダウンロードを考慮してください）。

from airllm import AutoModel

# Le modèle est découpé en couches au premier chargement
model = AutoModel.from_pretrained("meta-llama/Meta-Llama-3.1-70B-Instruct")

input_text = ["Explique le layer streaming en une phrase."]
input_tokens = model.tokenizer(input_text,
                               return_tensors="pt",
                               truncation=True,
                               max_length=128,
                               padding=False)

generation_output = model.generate(
    input_tokens['input_ids'].cuda(),
    max_new_tokens=64,
    use_cache=True,
    return_dict_in_generate=True)

output = model.tokenizer.decode(generation_output.sequences[0])
print(output)

1. 01
   1. 初回読み込み

   AirLLMはモデルをダウンロードした後、レイヤーごとのファイルに変換してSSDに保存します。この処理には時間がかかりますが、必要なのは一度だけです。次回以降の実行ではディスクキャッシュを再利用します。
2. 02
   2. コンプレッションの設定

   compression='4bit'（または'8bit'）というパラメータは、ディスクから読み込むデータ量を減らすため、推論が速くなります。ただし、品質はわずかに低下します。これは通常の量子化と同じトレードオフです。
3. 03
   3. 生成

   各トークンはSSDから80層すべてを完全に読み込みます。進行バーは層ごとに進みます。これは視覚的に遅く、正常です。
4. 04
   4. 測定

   総所要時間に生成されたトークン数を割って、実際のトークン生成速度（tokens/s）を算出してください。これは、そのツールが貴社の状況で利用可能かどうかを判断するための唯一の指標です。

#実測ベンチマーク：1秒あたりのトークン数はどれくらいですか？

ここで、うたわれている可能性が物理的な現実に直面します。NVMe SSD からストリーミングする 70B モデルでは、速度はトークン/秒ではなく、トークンあたりの秒数で語ることが多くなります。報告されている構成と私たちのテストに基づく、おおよその目安は以下のとおりです。

70B / 高速なPCIe 4.0 NVMe

0.1〜0.5 token/s程度であり、1語を生成するのに2〜10秒かかります。200トークンの応答には数分かかります。

70B / SSD SATA

さらに2〜5倍遅くなります。ディスクの帯域幅は約500 MB/sが上限で、生成速度は0.1 token/s未満に落ちます。

比較：70BモデルをVRAMに読み込んだ場合（RTX 4090 × 2）

15から30トークン/秒。ディスクによってはAirLLMと比べて30から300倍の差があります。

RTX 3060 12 GBを1枚使ったQ4の8Bモデル

40〜80 トークン/秒で、ストリーミングは一切なし。失われる快適さがどれほど大きいかを示すための比較です。

式は単純です。各トークンごとに、ディスクからモデル全体を読み直す必要があります。4ビットの 70B は約 40 GB のサイズです。NVMe の読み取り速度が 5 GB/s の場合、計算を開始する前に、トークンあたりすでに 8 秒の純粋な入出力時間がかかります。重みがディスク上に存在する限り、いかなるソフトウェア最適化でもこの壁を回避することはできません。最良の場合（小規模モデル、非常に高速なディスク、積極的な圧縮）でも 5 倍から 30 倍の遅延となり、大規模モデルではさらに大きくなります。

#現実的な活用例

0.2トークン/秒という速度ではAirLLMは会話に使用できません。しかし、遅いことが問題にならない実際のシナリオは存在します。画面の前で誰も待たない場合です。

オフラインでのバッチ処理

夜間に 70B モデルで500件のドキュメントを処理するスクリプトでは、1件に3分かかっても問題ありません。朝には結果が揃っているからです。これが最も妥当な用途です。

単発の実験

クラウドGPUを借りたり機材を購入したりせずに、特定の70Bモデルがいくつかのプロンプトにどう答えるかを確認し、投資に見合うか判断する。

急ぎではない構造化抽出

データセットを生成する、コーパスにアノテーションを付ける、埋め込みや要約をバックグラウンドで生成するなど、処理量をあまり重視しない作業。

予算をかけずに巨大モデルを利用する

小型GPUを1枚しか持っていない学生、研究者、あるいは好奇心のある方で、ほかの方法では動かせないモデルを試してみたい方。

#宣伝文句である場合

「70Bを4 GBで動かす」という表現は技術的には正しいものの、通常どおり使えると示唆するなら、読者に誤解を与える表現です。以下では、AirLLMが暗に期待させることを実現できない状況を紹介します。

インタラクティブチャット

返答を何分も待っていては、会話が成り立ちません。対話には、ファックス並みの速度で返答する70Bモデルよりも、即座に応答するローカルの8Bまたは14Bモデルの方がはるかに役立ちます。

リアルタイムコードアシスタント

自動補完やペアプログラミングには、数秒での応答が必要です。AirLLMは、その要件を満たすにはほど遠い状態です。

マルチユーザー対応サーバー

複数ユーザーへのサービス提供は不可能です：各トークンが単一のリクエストに対してすでにディスク帯域幅全体を占有しているためです。

本番運用

AirLLMを基盤にオンラインサービスを運用することはできません。レイテンシとSSDの摩耗（常時行われる大量の読み取り）が、その用途に採用できない理由です。

#代替案：まずは従来の量子化から

レイヤーストリーミングを使う前に、モデルをメモリ内に保持できる方法をすべて検討してください。ほぼ常に、そのほうが望ましい選択です。問うべきなのは「70Bモデルを4GBにどう収めるか」ではなく、「どのモデルが自分のニーズを実際に満たすか」です。

量子化のビット数を下げる

70BモデルはQ4_K_Mなら約40 GBに収まり、Q2/Q3なら必要なメモリは大幅に少なくなります。ただし、70Bを過度に量子化すると品質が落ちます。多くの場合、無理なく読み込めるQ4の32Bモデルを選ぶ方がよいでしょう。

より小さく、最近登場したモデルを選ぶ

2026年の32B（約19 GB VRAM）または14B（約9 GB）は、ほとんどのタスクで2024年の70Bと互角に渡り合える一方、単一のカードで即座に動作します。

CPU/GPUのオフロード：Ollama または llama.cpp

これらのエンジンは、VRAMが不足すると一部の層をシステムRAMにオフロードします。GPUフルロードよりも遅くなりますが、RAMはSSDの100倍速いため、AirLLMよりはるかに速いです。

一時的な用途のためにクラウドGPUを借りる

本物の70Bを一度だけ素早くテストする場合、GPUを1時間レンタルするコストは低く、通常のスループットが得られます。ローカルで数時間待つよりも、多くの場合、コストパフォーマンスが優れています。

#さらに詳しく

AirLLMは制約を回避するためのツールです。利用する前に、VRAMの扱いやモデル選択に関する基本的な調整方法を把握しておくほうがよいでしょう。当サイトの3つのガイドが、この説明を補完します。

量子化の選択（Q4、Q5、Q8、FP16）

Q4 や Q3 でモデルの品質がどの程度低下するか、そしてディスクストリーミングを使わずに大きなモデルを限られた VRAM に収める方法を理解する。

ローカルAI向けGPUの選び方

RTX 3060 12GBからMac Studio Ultraまで、VRAM・予算・パフォーマンスのバランスを考慮し、実際に使用可能なモデルのサイズを判断します。

llama.cpp vs vLLM vs Exllama

推論エンジンと、そのCPU/GPUオフロードの管理。VRAMが少し足りない場合に、AirLLMに代わる有力な選択肢です。