airllmとは｜4GB GPUで70B LLMを動かす仕組みと制約

「4GB の GPU で 70B の大規模言語モデルを動かせる」という一文を目にしたエンジニアは多いはずです。RTX 3060 / 4060 / 4070 クラスの手元マシンで、A100 級のハードウェアが前提だった 70B モデルを推論できるとしたら、社内 PoC やローカル検証の選択肢は大きく広がります。

その触れ込みで注目を集めているのが、GitHub リポジトリ lyogavin/airllm が公開する Python ライブラリ AirLLM です。スター数は 31,705(2026-08-20 時点)に達し、直近も v3.2.0(2026-08-18)としてリリースが継続しています。

ただし「動く」ことと「実運用に耐える」ことは別問題です。日本語圏の二次情報では、対応モデル一覧やインストール手順を紹介する記事は多い一方、レイテンシの実態や機能上の制約、類似 OSS との棲み分けまで踏み込んだ解説はまだ限られています。

本記事では、AirLLM のコアアイデアである「レイヤー単位オフローディング」の仕組みから、対応モデルとハードウェア要件、実運用上の制約、llama.cpp / DeepSpeed / KTransformers など類似 OSS との差分、Apache-2.0 ライセンスや開発体制の状況までを整理します。読み終えたときに「自分の PoC 要件に AirLLM を採用すべきか、別 OSS を選ぶべきか」を判断できる状態になることを目標にしています。

なお、記事タイトルと URL では GitHub リポジトリ表記に合わせて小文字の airllm を使っていますが、README・PyPI で公式に用いられているブランド表記は「AirLLM」です。本文中の呼称は以降「AirLLM」で統一します。

AirLLM の概要と位置づけ

AirLLM が解決する課題

大規模言語モデルの推論には、通常モデルサイズと同等以上の GPU メモリが必要です。FP16 の Llama 3.x 70B であれば概ね 140GB 前後の VRAM を要し、コンシューマ GPU 単体では搭載できません。従来この壁を越える主なアプローチは、量子化(bit 幅を下げて重みを圧縮する)・蒸留(小さなモデルに知識を移す)・枝刈り(重要でない重みを削る)の 3 つでした。ただしいずれも「重みを軽くする」代償として、程度の差はあれ品質劣化を伴います。

AirLLM はこの前提を組み替え、重みを軽くせずに「常時 VRAM に載せる範囲を絞り込む」設計を採ります。モデル全体を GPU に載せる代わりに、レイヤー単位でディスクから逐次ロードし、演算が終わったら解放して次のレイヤーをロードする、というレイヤーオフローディング方式です。結果として、量子化・蒸留・枝刈りを行わないまま 70B クラスを 4GB VRAM で動かすことができます。

つまり AirLLM の狙いは「あらゆる LLM をとりあえずロードできる状態にする」ことにあり、単発推論の応答速度を最速化することではありません。この設計思想の理解が、後述する制約セクションを正しく解釈する前提になります。

リポジトリ概要

公式リポジトリは lyogavin/airllm で、作者は Gavin Li(GitHub ハンドル @lyogavin)です。ライセンスは Apache-2.0 で、商用利用を含む二次利用が認められています。

gh api /repos/lyogavin/airllm の取得値ベースで、リポジトリの現状は次のとおりです。

Language が Jupyter Notebook として集計されているのは、README と対応モデル別のクイックスタートが Notebook で提供されているためで、ライブラリ本体は Python で実装されています。スター数から見た認知度は十分あり、最終 push も継続しているため、ドキュメント時点での活性度は健全と判断できます。

4GB GPU で 70B を動かす仕組み

レイヤー単位ロードの流れ

Transformer 系の LLM は、埋め込み層と多数の Transformer ブロック(Attention + Feed Forward)を積み上げた構造です。70B モデルであれば 80 レイヤー前後、405B クラスであれば 100 レイヤー超になります。通常の推論エンジンでは、これら全レイヤーの重みを GPU の VRAM に常駐させた状態で 1 トークンずつ生成します。

AirLLM は、各レイヤーの重みを個別のシャードファイルとしてディスク上に配置し、推論時には次のような流れで演算します。詳細な API・オプションは公式 README(README.md)を参照してください。

1. トークン生成の各ステップで、レイヤー 0 の重みをディスクから読み込み、GPU 上で演算する。
2. レイヤー 0 の出力(アクティベーション)を保持したまま、レイヤー 0 の重みを VRAM から解放する。
3. レイヤー 1 の重みを読み込み、演算する。以下同様に最終レイヤーまで繰り返す。
4. 最終出力から次トークンを選択し、次のトークン生成ステップに戻る。

VRAM に常駐するのは「1 レイヤー分の重み + アクティベーション + KV キャッシュ」となるため、モデル全体のパラメータ数ではなく「最も重い 1 レイヤーの大きさ」が VRAM 要件を決めます。これが 70B を 4GB VRAM で扱える技術的な根拠です。

初回のみ、Hugging Face などから取得したモデルを AirLLM 向けにレイヤー単位で再パッキング(sharding)する処理が走ります。このステップはディスク I/O が支配的で、大規模モデルでは数分単位の待ち時間が発生します。

4bit / 8bit 量子化オプション

AirLLM のデフォルトは重みをそのまま保持する構成ですが、AutoModel.from_pretrained(...) の引数として compression='4bit' または compression='8bit' を指定することで、block-wise の量子化を有効化できます。量子化対象は「重みのみ」で、activations(中間演算結果)は非量子化のまま扱われる点が README で明示されています。

• 4bit / 8bit 量子化を有効にするとロード対象データが小さくなり、README では compression 併用で最大 3 倍程度の推論高速化が示されています。
• 併せて、次レイヤーの重みを先読みする prefetching で約 10% の追加高速化が可能とされています。

量子化はあくまで「オフローディングを高速化するオプション」として位置づけられており、AirLLM の中核は量子化ではなくレイヤー単位オフローディングである点は変わりません。

対応モデルとハードウェア要件

対応モデルファミリー

README で対応が明示されているモデルファミリーは次のとおりです。同一ファミリー内でも派生モデルによって挙動が異なる場合があるため、実採用時は該当モデルのクイックスタート Notebook を参照する必要があります。

• Llama(2 / 3 / 3.1 / 3.3 / 4)
• Qwen(1 / 2 / 2.5 / 3 / 3.5 / 3.8)
• DeepSeek(V2 / V3 / R1)
• Mistral / Mixtral
• Phi
• Gemma
• ChatGLM
• Baichuan
• InternLM
• Yi
• Kimi K3

密モデル・MoE モデルの区別なくレイヤー単位で扱う汎用性が特徴で、密モデル特化ではないという点で後述の KTransformers とは設計方針が異なります。

VRAM 目安テーブル

README には主要モデルの VRAM 目安が示されています。あくまで推論時の常駐 VRAM の目安であり、ディスク上のモデル本体はサイズなりの容量を占有します。数値の出典は公式 README の該当セクションです。

「4GB VRAM で 70B」はキャッチコピーとしてよく引用されますが、実用上は 8B クラスを常駐 1〜2GB で扱えることの方が、手持ちの RTX 3060 クラスでの検証には有効なケースが多くなります。逆に DeepSeek-V3 のような 671B モデルは 12GB VRAM に加えて、ディスク側に数百 GB のシャード領域が必要になります。

対応プラットフォームと CUDA バージョン

• Linux / Unix 全般。
• macOS は Apple Silicon 環境のみ対応。
• モデルによって CUDA 12 系または CUDA 13 系のいずれかを要求する。

Windows 単独環境は README で公式サポートとして明示されていないため、WSL2 経由の Linux 環境を選ぶのが安全な運用となります。

インストールと最小コード例

pip でのインストール

AirLLM は PyPI 上で配布されており、最新バージョンは pypi.org/project/airllm から確認できます。インストールは pip の 1 行で完結します。

pip install airllm

出典: https://github.com/lyogavin/airllm(README Quick Start セクション)

初回のみ、対象モデルをレイヤー単位で再パッキングするための追加ダウンロードとディスク書き出しが走ります。ディスクの空き容量は、扱う最大モデルのシャード容量(例えば 70B FP16 なら 140GB 前後)を上回るサイズを見込んでおく必要があります。

AutoModel を用いた最小推論コード

README 冒頭の Quick Start に掲載されている最小コード例です。改変せず引用しています。実行例や出力結果は本記事では扱わず、あくまでコード構造の把握のために掲載します。

from airllm import AutoModel

model = AutoModel.from_pretrained("Qwen/Qwen3-32B")

input_text = ['What is the capital of United States?']
input_tokens = model.tokenizer(input_text,
    return_tensors="pt",
    return_attention_mask=False,
    truncation=True,
    max_length=128,
    padding=False)

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

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

出典: https://github.com/lyogavin/airllm(README 冒頭 Quick Start)

AutoModel.from_pretrained("Qwen/Qwen3-32B") の時点で、初回はモデル取得と sharding が動きます。API 面は Hugging Face Transformers の AutoModel に寄せられており、.generate(...) の呼び出し方も一般的な Transformers ユーザーにとって馴染みやすい形になっています。

実運用上の制約と現実的な使いどころ

このセクションは AirLLM 採用判断の核になります。README では「不可能を可能にする」文脈で紹介されている一方、第三者レビューや技術ブログでは共通の制約が指摘されています。以降の記述は複数の二次情報にもとづくため、各記述の直後に出典 URL を明記します。

速度の実態

AirLLM は 1 トークン生成のたびに、モデルの全レイヤーをディスクから順次読み込みます。したがって推論スループットはディスクの読み込み速度が支配的で、常駐型のエンジンと比べて桁違いに遅くなります。

• 標準的な GPU 常駐型推論と比較して、5〜30 倍のレイテンシが観測されるとする第三者レビューがあります(出典: https://rohit-shirke.medium.com/airllm-and-70b-on-a-4gb-gpu…)。
• 別の実測レポートでも「動作はするが、対話用途に耐える速度は出ない」との評価が示されています(出典: https://dev.to/arshtechpro/airllm-runs-a-70b-model-on-a-4gb…)。

これらの数値は SSD 種別(SATA / NVMe / PCIe Gen4 以降)や CPU〜GPU バス帯域に強く依存します。同じ AirLLM 構成でも、NVMe 上に sharding するのと HDD 上に置くのとでは体感速度が大きく変わるため、ストレージ計画は事前検討事項になります。

機能上の制約

現状の AirLLM は、実運用の LLM アプリケーションでよく使われる周辺機能に対して制限があります。以下の指摘は複数の技術ブログで共通しています。

• ストリーミング応答に非対応。応答は全トークン生成完了後に一括で返却されます(出典: https://nachoconesa.com/blog/airllm-llms-hardware-modesto?l…)。
• function calling / tool 呼び出しなど、対話エージェント用途で前提となる周辺機能もサポート範囲外です(出典: https://github.com/NPC-Worldwide/npcpy/blob/main/docs/guide…)。
• 初回モデル分割(sharding)はディスク I/O が重く、大規模モデルでは数分〜数十分単位の待ち時間が発生します。

これらは「ロードして生成する」という単発推論の 1 パスに機能を絞り込んだ結果であり、AirLLM の設計思想上の割り切りに近い制約と言えます。

向く用途 / 向かない用途

上記の速度と機能制約を踏まえると、AirLLM の適用範囲はおおむね以下のように整理できます。

「実運用として使えるか」ではなく「実験・検証のスタートラインに立てるか」を判断する OSS として捉えるのが実態に近い評価になります。

類似 OSS との比較

限られた VRAM 環境で大規模 LLM を推論する用途では、AirLLM の他にもいくつかの選択肢があります。ここでは代表的な 3 種類との差分を整理します。

llama.cpp との違い

ggml-org/llama.cpp は、GGUF フォーマットで量子化された重みを扱う C/C++ の推論エンジンです。--n-gpu-layers などのオプションで、GPU と CPU RAM に任意割合でレイヤーをオフロードできます。Ollama や LM Studio といったツールの背後でも採用されており、量子化 LLM 推論の事実上の標準となっています。

AirLLM との違いは主に次の 2 点です。1 点目はエコシステムの前提で、llama.cpp は量子化前提(Q2〜Q8_0 が主戦場)なのに対し、AirLLM は無量子化での 70B ロードを可能にする点が独自ポジションです。2 点目はオフロード先で、llama.cpp が CPU RAM 中心なのに対し AirLLM は SSD/ディスク前提です。汎用性・エコシステム規模・単発応答速度では llama.cpp が大きく優位で、AirLLM は「量子化による品質劣化を許容できない」用途で選ばれる位置づけになります。

DeepSpeed / ZeRO-Inference との違い

microsoft/DeepSpeed は分散学習向けフレームワークで、ZeRO-Inference は推論時に重み・KV キャッシュを CPU / NVMe に段階的にオフロードする機構を提供します。

AirLLM との違いは、想定するデプロイ規模と最適化軸にあります。DeepSpeed / ZeRO-Inference はマルチ GPU・データセンター前提で、バッチスループットの最適化を主眼に置いています。設定 JSON の記述や環境構築のコストも AirLLM より重く、単一 4GB GPU の個人環境で「まず動く/動かないを突破する」用途とは目的地が異なります。バッチ推論の総スループットを稼ぐ場面では ZeRO-Inference、単発ローカル実験では AirLLM、という棲み分けが妥当です。

KTransformers との違い

kvcache-ai/ktransformers は、MoE(Mixture of Experts)モデルに特化した推論最適化を行う OSS です。専門家(expert)単位で重みをオフロードし、DeepSeek-V3 のような巨大 MoE を消費者向けハードウェアで実用速度で動かすことを目標としています。

AirLLM との違いは、対象モデルの絞り込み方にあります。KTransformers は MoE 特化で、アクティブな expert のみが計算参加するため単発応答速度が優位になるケースが多いのに対し、AirLLM は密モデル・MoE のどちらであっても「まずロードできる」汎用性を優先しています。DeepSeek-V3 系を高速に動かしたい場合は KTransformers、モデルファミリーを絞らず幅広く試したい場合は AirLLM、という判断軸になります。

比較サマリ

4 つの観点で 4 種類の OSS を並べると、AirLLM の独自ポジションが明確になります。

メンテナンス状況とライセンス

ライセンス(Apache-2.0)

AirLLM のライセンスは Apache-2.0 で、商用利用・改変・再配布・特許使用許諾が明示的に認められています。社内 PoC やプロダクトへの組み込みを検討する際に、ライセンス面で追加の交渉が必要になることは基本的にありません。派生物を配布する場合、著作権表示と NOTICE ファイルの取り扱いなど、Apache-2.0 標準の条件は満たす必要があります。

リリース履歴と開発ペース

PyPI 上のリリース履歴を見ると、直近 3 ヶ月でも継続的にバージョンが更新されています。

• v3.0.0 / v3.0.1(2026-06-30): FP8 モデル対応、DeepSeek-V3 / Qwen3 対応追加
• v3.1.0(2026-07-29): 追加モデル対応・不具合修正
• v3.2.0(2026-08-18): 最新リリース

README の News セクションでも、2026 年 8 月には Qwen3.8-27B を 3.33GB VRAM で動かせるようになったことや、2026 年 7 月に Kimi K3(2.8T)が 3.72GB VRAM で動作したことが報告されています。GitHub リポジトリの pushed_at は 2026-08-19 で、リポジトリ本体側の更新も止まっていません。

体制と持続性の観点

コミット履歴と PR 一覧を見ると、AirLLM は現状ほぼ単一開発者(@lyogavin)主導で開発されています。Fork 数は 3,362 と多いものの、コアの機能追加は作者の手によるものが中心です。この体制は、迅速な意思決定と機能追加が可能な一方、作者の稼働状況に持続性が強く依存する構造的リスクを持ちます。

社内で AirLLM を採用する場合は、公式リポジトリの Issue・PR の反応速度と直近リリース頻度を継続監視する運用を組み込むこと、必要に応じて自社 fork を維持できる体制を確保しておくこと、の 2 点を判断材料に含めるのが安全です。

採用判断のポイント

これまでの内容を踏まえ、「AirLLM を採用すべきケース」と「別の選択肢を選ぶべきケース」を整理します。

AirLLM が適するケース

• 量子化を許容できない品質検証: 蒸留・枝刈り・量子化を挟まない状態で 70B / 405B クラスの応答品質を確認したいケース。品質評価のベースラインとして FP16 の 70B が必要な場合、他の OSS では単一 GPU では扱いにくく AirLLM が現実的な選択肢になります。
• ローカル環境での試作・研究: 手持ちの RTX 3060 / 4060 / 4070 クラスで、まず 70B 以上のモデルを触ってみたい研究・学習用途。応答速度よりも「動くこと」が価値になる段階では有効です。
• オフラインでのバッチ推論: リアルタイム性が不要で、夜間バッチや検証データのオフライン推論を回す用途。1 件あたりのレイテンシは大きくても、まとめて回す前提であれば実用に持ち込めます。
• モデルファミリーを絞り込みたくない検証: Llama / Qwen / DeepSeek / Mistral など、幅広いファミリーを同じ枠組みで比較したい PoC。

AirLLM を選ばない方がよいケース

• ユーザー向けリアルタイム対話: 応答遅延がユーザー体験に直接影響する用途では、常駐型の推論エンジン(llama.cpp + 量子化、vLLM、TGI 等)を選ぶ方が現実的です。
• ストリーミング応答が前提のプロダクト: チャット UI の「タイピング風表示」を必要とする場合、AirLLM の一括返却型 API は要件を満たしません。
• tool 呼び出しを含むエージェント基盤: function calling / tool 呼び出しを軸にした設計では、対応済みのランタイム(vLLM 等)を採用する方が実装コストが低くなります。
• 本番のスループット要件がある推論基盤: 高スループット・マルチテナントを想定するなら、ZeRO-Inference や vLLM など、バッチ最適化を主眼とした基盤の方が向いています。
• MoE モデルを高速に扱いたい: DeepSeek-V3 系の MoE モデルを実用速度で動かしたい場合は、KTransformers など MoE 特化 OSS の方が優位です。

PoC / 研究 / 実運用の 3 レイヤーで見た場合、AirLLM は「PoC・研究用途で品質評価のベースラインを取る」役割に位置づけ、実運用フェーズには他の OSS への切り替え計画をセットで持っておくのが、後悔の少ない導入方針になります。

まとめ

本記事で整理した AirLLM の要点は次のとおりです。

• コアアイデアはレイヤー単位オフローディングで、量子化・蒸留・枝刈りを伴わずに 70B クラスを 4GB VRAM で扱えます。
• 対応モデルは Llama / Qwen / DeepSeek / Mistral / Mixtral / Phi / Gemma / ChatGLM / Baichuan / InternLM / Yi / Kimi K3 と幅広く、密モデル・MoE を汎用にカバーします。
• 反面、1 トークンごとに全レイヤーをディスクから読み込むため、常駐型と比べて 5〜30 倍のレイテンシが観測される事例があり、ストリーミング応答や tool 呼び出しには非対応です。
• 類似 OSS では、スループット重視なら llama.cpp / vLLM / ZeRO-Inference、MoE モデル特化なら KTransformers が優位で、AirLLM は「無量子化でとにかくロードできる」位置づけです。
• ライセンスは Apache-2.0 で商用利用に問題はありませんが、開発体制はほぼ単一開発者主導であり、採用時は継続監視と自社 fork 体制の検討が必要です。

次のアクションとしては、公式リポジトリ lyogavin/airllm と PyPI ページ pypi.org/project/airllm で最新の対応モデル・バージョンを確認しつつ、比較対象となる llama.cpp / DeepSpeed / KTransformers のアプローチも並行して評価する流れが、意思決定の質を高めます。

関連情報

AirLLM を含むローカル LLM 推論基盤の技術選定や、社内 PoC の要件整理でご検討中の方は、お問い合わせフォーム からご相談いただけます。ハードウェア構成の妥当性評価や、他 OSS との比較検討など、初期の要件整理段階からご一緒します。

エンジニアの方へ

フリーランスとして機械学習・LLM 領域の案件をお探しの方は、Workee フリーランス向けサービス をご覧いただけます。案件情報の閲覧や登録手続きをご確認いただけます。