AirLLMがGitHubで3万スターを突破した。本来なら数十万円のGPUが必要な700億パラメータのLLMを、わずか4GBのGPUメモリで動かすライブラリだ。クラウド費用を抑えて自社サーバーでLLMを試したい開発現場を中心に爆発的に広がっており、GPU調達戦略そのものを揺さぶりつつある。

何が起きたか

lyogavin氏が公開するAirLLMのGitHubスターが30,907に到達した。売り文句はシンプルで、「70Bクラスの大規模言語モデルを、単一の4GB GPUで推論可能にする」。従来、Llama系70Bを素で動かすにはA100 80GB相当、量子化しても24GB級のRTX 4090が要る、というのが業界の常識だった。それを家庭用のGTX 1650クラスでも走らせるという主張だ。

AirLLMは新しいモデルを作っているわけではない。既存のTransformerモデルをレイヤー単位に分割し、必要なレイヤーだけをGPUに載せて推論を進める「レイヤーワイズ推論」を中心に、量子化(4bit/8bit)やフラッシュデコーディング、モデルの動的ロードを組み合わせている。速度を犠牲にする代わりに、VRAM要件を極限まで下げるという設計思想だ。

llmは何が変わるか：GPU前提の崩壊

エンジニア視点で見ると、このニュースの本質は「70Bが4GBで動く」という数字そのものではない。LLM推論のボトルネックがVRAM容量から、ストレージI/OとCPU-GPU間帯域に移動したという点だ。

これまでLLM運用の設計は「モデル全体がVRAMに載るか」を出発点にしていた。載らなければ諦める、載せるためにGPUを積む、あるいはクラウドに逃げる。AirLLMのアプローチは、この前提そのものを解体する。レイヤーごとにディスクからロードし、計算が終わったら破棄する。VRAMは「モデルの家」ではなく「計算のためのワークベンチ」に格下げされる。

代償は明確で、トークン生成速度は極端に遅くなる。推定で70Bの場合、秒間1トークン以下、実用ケースによっては数十秒/トークンという領域だ。リアルタイム対話には向かない。しかし、バッチ処理、社内文書の一括要約、夜間のナレッジ抽出、コード解析といった「レイテンシ非依存のLLMタスク」であれば、これで十分に成立する。ここが競合の議論でごっそり抜け落ちている論点だ。

技術的な深掘り：I/O設計とモデル選定が勝負を分ける

AirLLMをそのまま導入して「安く済んだ」と喜べるかは、実装現場のI/O設計次第だ。レイヤーワイズ推論では、1トークン生成のたびに80層前後のweightsをストレージから読み出す。70Bを4bit量子化しても実サイズは35GB前後になる。NVMe SSDのシーケンシャルリード7GB/sで割っても、単純計算で1トークンあたり5秒はディスクI/Oに食われる。ここでSATA SSDやHDDを掴んでいると、実測は10倍遅くなる。

もう一つの盲点はモデル選定だ。Llama 3.1 70Bのようなdense modelは全レイヤーを毎回舐める必要があるが、Mixtral系のMoEなら活性化するexpertだけをロードすればいい。AirLLMの真価は、MoEアーキテクチャと組み合わせたときに最大化されると筆者は推定する。動画では触れられていないが、GitHubのIssue履歴を読むとMoE対応の要望が積み上がっており、コミュニティの関心もそこに向かっている。

さらに言えば、この技術は「オンプレLLMの民主化」だけでなく、エッジ推論の設計思想にも波及する。工場のPLC近傍に置いた小型サーバーで70Bを走らせ、ネットワークを介さず設計図面を解析する、といったユースケースが、机上論から実装フェーズに入る。

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

第一に、社内のLLMユースケースを「同期処理」と「非同期処理」に仕分けろ。カスタマーサポートのリアルタイム応答はクラウドAPIのまま、夜間の議事録要約や大量文書のタグ付けはAirLLM+オンプレに寄せる。この二分割だけで、月額のAPI課金は推定30〜50%削れる。

第二に、GPU調達計画を凍結し、まずNVMe SSDとメモリの増強で試せ。A100購入の稟議を出す前に、10万円台のRTX世代マシンにNVMe Gen4を刺した検証機を1台用意する。数百万円の投資判断は、PoCの数字を見てからで遅くない。

第三に、機密データを扱う部門から巻き込め。金融の与信メモ、医療のカルテ要約、製造の設計レビュー――外部APIに出せなかったデータこそ、オンプレLLMの初期テーマとして最も投資対効果が高い。競合が手を出せない領域に、先に旗を立てるべきだ。