メモリの壁を打ち破る：10年前のXeonでGemma 4を動かす

ローカルAIにおける主流の考え方は、最先端のモデルを動かすには最新のH100や最高級のMac Studioが必要だというものです。しかし、大規模言語モデル（LLM）の推論における真のボトルネックは、必ずしも生の計算能力ではなく、「メモリの壁」にあります。トークンを生成する際、プロセッサは実際に計算を行う時間よりも、RAMからキャッシュへ重みを移動させるのを待っている時間の方が長くなります。

デプロイメント・パイプラインをブラックボックス的なインストールではなく、真剣なエンジニアリングの課題として扱うことで、これらのモデルが構想されるよりも前に存在していた古いハードウェア上でも、Gemma 4 26B Mixture-of-Experts (MoE)のような最先端のアーキテクチャを動かすことが可能です。具体的には、128GBのDDR3 RAMを搭載しGPUを持たない2016年のIntel Xeon E5-2620 v4であれば、ソフトウェアをハードウェアの物理的な現実に合わせてチューニングすることで、「読書スピード」での生成が可能になります。

ハードウェアの課題

なぜこれが困難なのかを理解するには、再利用されたエンタープライズ・サーバーのスペックを見る必要があります。

  • CPU: Intel Xeon E5-2620 v4 @ 2.10 GHz (8物理コア、16スレッド)
  • 命令セット: AVX2 (AVX-512、AVX-VNNI、およびBF16は欠如)
  • メモリ: 128 GB DDR3 (現代のDDR4/DDR5よりも大幅に遅い)
  • GPU: なし

この環境では、システムは極めてメモリ帯域に制限されています。生成されるすべてのトークンは、低速なDDR3 RAMからCPUキャッシュへ数ギガバイトの重みを運び込むことを必要とします。積極的な最適化が行われない限り、ollamaや基本的なllama-cppのような標準的なツールは、汎用的なGPUユースケース向けに設計されており、メモリのボトルネックを回避するために必要な「ノブ（調整つまみ）」を公開していないため、極めて低速になります。

最適化スタック

これを実現可能にするために、著者は専門的なフォークであるik_llama.cppを利用し、モデルのアーキテクチャをCPUのキャッシュ階層に直接マッピングするための精密なフラグのセットを使用しました。

1. Speculative Decoding と MTP

--spec-type mtp --draft-max 3 --spec-autotune というフラグを使用することで、システムは26Bの検証器（verifier）と、はるかに小さな「ドラフター（drafter）」モデルをペアにします。

Speculative decodingは、メモリの壁に対する素晴らしい回避策です。CPUの計算コストは、膨大な重みをストリーミングするコストと比較して相対的に安価であるため、システムは（L3キャッシュに完全に収まる）非常に小さなドラフターを使用して、次の数トークンを推測します。その後、より大きな検証器が、一度のパスでこれらの推測をチェックします。これにより、システムは、検証器のメモリ帯域コストを一度支払うだけで、複数のトークンを生成することが可能になります。

2. MoE ルーティングとキャッシュ・スラッシング

Gemma 4 26B-A4BのようなMixture-of-Experts (MoE)モデルは、各トークンに対してエキスパートのサブセットを使用します。しかし、128もの異なるエキスパート間を飛び回ることは、「キャッシュ・スラッシング」を引き起こす可能性があります。これは、CPUが新しい重みをRAMからフェッチするために、常にキャッシュを破棄してしまう現象です。

  • --cpu-moe: ルーティングをCPUキャッシュ階層に特化してチューニングし、重みをより長くローカルに保持します。
  • --merge-up-gate-experts: 2つのプロジェクションを単一の行列演算（matmul）に融合させます。これにより、プロセッサが結果をメモリに書き込み、すぐにそれを読み戻すという動作を防ぎ、メモリバスを横断する回数を減らします。

3. メモリ・ピニングとリパッキング

OSがパフォーマンスを阻害するのを防ぐため、設定には厳格なメモリ管理が採用されています。

  • --run-time-repack: 起動時にRAM内の重み行列を再編成し、CPUが期待する取り込み形状に合わせることで、「キャッシュミス」を減らします。
  • --mlock: モデルを物理RAMに固定（ピン留め）します。これにより、Linuxカーネルが重みをハードドライブに「スワップ」することを防ぎ、生成速度が急落してゼロになるのを防ぎます。
  • --no-kv-offload: エンジンに対し、Key-Value (KV) キャッシュのために存在しないGPUを検索しないよう明示的に指示し、不要なハードウェアチェックをショートカットします。

4. 高度な Attention メカニズム

このセットアップにおける最も重要な成果の一つは、--flash-attn on を介したCPUベースの Flash Attention の使用です。

通常、プロンプト内のすべての単語が他のすべての単語とどのように関連しているかを計算するには、巨大な $N imes N$ 行列が作成され、それがRAMに書き込まれる必要があります。Flash Attentionは、「Kernel Fusion」を使用して、これらのスコアをプロセッサのローカルキャッシュ内で小さなチャンクに分けて計算し、システムRAMに巨大な行列を実体化させる必要を回避します。

さらに、--mla-use 3 は Multi-Head Latent Attention を有効にし、KVキャッシュ（モデルの短期記憶）を圧縮することで、128GBのRAMを使い果たすことなく、巨大なコンテキスト・ウィンドウ（最大262K）を可能にします。

結果とトレードオフ

最終的なメモリ・フットプリントは約82 GBです。重みは25 GB、フルコンテキストでのKVキャッシュは56 GBとなります。

パフォーマンスは「読書スピード」と表現されていますが、実用的なトレードオフを考慮することが重要です。コミュニティの議論で指摘されているように、これらの古いXeonサーバーは、現代のARMベースのノートPCや専用のGPUセットアップと比較して、消費電力が大きく、動作音が大きい傾向にあります。しかし、このハードウェアのアクセシビリティは、実験のための強力なツールとなります。

"ストレートなAIをローカルで動かすためのボトルネックは、シリコンだけではありません。推論エンジンが実際にどのように動作するかを、深く理解することの必要性です。"

結論

26BパラメータのMoEモデルを10年前のサーバーで動かすことは、ブラックボックス的なAIツールによって作られた「使いやすさの壁」とは、それが人工的なものであることを証明しています。簡略化されたラッパーから離れ、基礎となるメモリ・アーキテクチャに深く関及与することで、ローカルAIの要件は「高価な新しいハードウェア」から「知識に基づいた設定」へとシフトします。

ホームラボや再利用されたサーバーをお持ちの方にとって、、オープンウェイトAIの最先端はすでに手元にあります。ただ、コマンドラインで泥臭い作業を行う意欲があるかどうかにかかっています。

Sources