AirLLMがGitHubで3万2千スターを突破した。700億パラメータのLLMを、たった4GBのゲーミングGPU1枚で推論できるという触れ込みだ。層ごとに分割ロードする独自技術が、社内サーバーで大規模モデルを動かしたい企業と研究者の関心を一気に引き寄せている。コスト、機密性、そして速度のトレードオフを、エンジニア視点で解剖する。

何が起きたか

lyogavin/airllm リポジトリのスター数が32,530に到達した。AirLLMは、70Bクラスの巨大LLMを4GB VRAMのGPU1枚で推論可能にするPythonライブラリだ。通常、70Bモデルの推論には量子化しても40GB前後のVRAMが必要で、H100やA100といった数十万円〜数百万円級のGPUが前提となる。AirLLMは、Transformerのレイヤーごとにモデルをディスクから逐次ロードし、推論後に破棄することで、VRAM常駐量を1レイヤー分に抑える設計を採る。結果、コンシューマー向けのGeForce RTX系や、場合によっては数世代前のミドルレンジGPUでも70B推論が原理上動く。ただし後述の通り、この方式は推論スループットを大きく犠牲にする構造でもある。

なぜこのニュースが重要か

このニュースの本質は「70Bを動かせる」という派手さではなく、LLM推論の制約条件が『VRAM総量』から『I/O帯域と時間』にシフトしたことにある。従来、大規模LLMのオンプレ運用は「VRAMの壁」で頓挫していた。金融・医療・製造業の情シスが社内でLlama系70Bを回そうとすれば、まずGPU調達で数百万円の稟議が必要になり、そこで話が止まる。AirLLMは、この稟議プロセスを飛ばして「まず動かして検証する」フェーズに持ち込める。3万2千スターという数字は、この「PoC以前の障壁」に苦しんでいたエンジニアがいかに多かったかの裏返しだ。

ただし冷静に見るべきは、これがllama.cppやvLLMの代替ではなく、用途特化のニッチツールである点だ。速度が実用に耐えないため、対話型のChatbotには使えない。夜間バッチの文書要約、社内ドキュメントの一括埋め込み生成、コンプライアンスチェックなど、「レイテンシ非依存・機密性最重視」の領域にピンポイントで刺さる。ここを見誤ると、導入したものの誰も使わないシャドウAIになる。

技術的な深掘り

AirLLMのコア技術は、Hugging Face Transformersのモデル構造を利用したレイヤーワイズ・オフローディングだ。70Bモデルは通常80層前後のTransformerブロックを持つ。各層は数百MB〜1GB程度なので、1層ずつSSDから読み込んでVRAMに載せ、forward計算し、次の層に置き換える。これを1トークン生成ごとに全層繰り返す。

つまり、1トークンの生成に モデル全体をディスクから1回読み直す ことになる。NVMe SSDの実効帯域を3GB/s、モデルサイズを量子化後40GBとすれば、1トークン約13秒。100トークンで20分超だ。これは推論というより「バッチジョブ」であり、対話用途は事実上不可能である。

一方で、この設計は本質的に KVキャッシュ管理さえ工夫すれば、モデルサイズは無限に拡張可能 という含意を持つ。405Bだろうが動く。GPUを「巨大な計算バッファ」ではなく「小さな計算ユニット」として再定義した点で、思想的にはvLLMのPagedAttentionとは真逆のアプローチだ。ハードウェア側でCXLやGPUDirect Storageが普及すれば、この方式の速度制約は数倍改善する可能性があり、中長期的にはオンプレLLMの標準アーキテクチャの一つになると推定する。

経営者として次に取るべき動き

第一に、GPU調達計画を一度止める。H100を購入する稟議が回っているなら、まずAirLLMで既存の遊休GPU（社内のワークステーションや開発機のRTX 4060/4070でも可）を使い、70Bモデルの出力品質を1週間で検証すべきだ。ハードウェア投資は品質確認の後で構わない。

第二に、バッチ用途のLLMタスクを棚卸しする。契約書レビュー、議事録要約、コード監査、社内FAQの再生成など、夜間に走らせて朝までに結果があれば十分な業務を洗い出す。これらは外部APIに機密データを渡さずに済むため、コンプライアンス部門との調整コストも激減する。

第三に、リアルタイム用途は別建てで設計する。カスタマーサポートのチャットボット等は、AirLLMではなく7B〜13Bの小型モデルをvLLMで回すか、外部APIを継続利用する二層構成にする。ツール選定を一本化しようとすると、必ず失敗する。