10年前のXeonサーバーで最新AIが快適動作、GPUなしでも実用速度を実現した手法が解説される

ChatGPTのようなAIサービスは超高性能なAIサーバーによって稼働しており、ローカルAIを自宅や手元のサーバーで動かす場合も高性能GPUや大容量メモリを搭載した最新世代PCが必要だと考えがちです。しかし、2016年ごろのIntel Xeon、128GBのDDR3メモリ、GPUなしという古いサーバーで、26B規模のローカルAIを実用的な速度で動かしたという報告が登場しました。

A 10 year old Xeon is all you need - point.free
https://point.free/blog/gemma-4-on-a-2016-xeon/

報告したのはオープンソース開発者でNixOS Steering Committeeメンバーのcafkafk氏です。使用したマシンはIntel Xeon E5-2620 v4、8コア16スレッド、AVX2対応、AVX-512非対応、L3キャッシュ20MiB、DDR3メモリ128GB、GPUなしという構成とのこと。Intel Xeon E5-2620 v4は2016年第1四半期に発売されたCPUです。

ローカルAIで速度を決める最大の要素は、CPUの計算能力だけではありません。大規模言語モデルが次の単語に相当する「トークン」を1つ生成するたび、モデルの「重み」と呼ばれる巨大な数値データをメモリからCPUへ読み込む必要があります。補足すると、重みはAIが学習によって得た知識の本体のようなデータであり、推論時には膨大な重みを何度も読み出すことになります。

そのため、古いXeonでローカルAIを動かす場合の敵は「計算の遅さ」だけではなく「メモリ帯域の細さ」です。DDR3メモリは新しいDDR5メモリやGPUに搭載される高速メモリと比べると遅く、CPUが計算を終えても次に処理するデータがメモリから届かず待たされます。AI推論では、プロセッサが全力で計算しているというより、メモリから重みが運ばれてくるのを待っている時間が大きいというわけです。

cafkafk氏が採った方針は、古いハードウェアを力技で押し切るのではなく、推論エンジンの細かな設定を徹底的に調整するというものです。一般的なローカルAI実行ツールは手軽に使える一方で、内部の最適化設定を十分に変更できない場合があります。そこでcafkafk氏は、llama.cpp系の派生版であるik_llama.cppを使用しました。実際に動作させるための「魔法の呪文」は以下の通り。

中心になる工夫の1つが「投機的デコード」の利用を指定する以下のオプションです。投機的デコードは「小さな下書きモデルが先にいくつかのトークンを予想し、大きな検証モデルが予想を確認する」という手法で処理を高速化する仕組みです。大きなモデルを毎回最初から重く動かすより、小さな下書きモデルに一部を任せることで、メモリ読み出しの負担を減らすこともできます。

古いCPUでは計算能力よりもメモリ帯域が先に限界に達しやすいため、投機的デコードの効果が大きくなります。CPUの空いている計算資源で小さな下書きモデルを動かし、大きな検証モデルの重みをメモリから何度も引っ張る回数を減らすという発想です。GPUで力任せに回すのではなく、メモリ帯域という細い道をなるべく渋滞させないための工夫というわけ。

使用されたモデルはGemma 4 26B-A4B-itで、専門家混合モデル(MoE)と呼ばれる構造です。MoEは巨大なモデル全体を毎回すべて使うのではなく、多数のエキスパートと呼ばれる部分から必要なものだけを選んで使う仕組みで、Gemma 4 26B-A4B-itの場合は総パラメーター数25.2Bのうち約3.8Bです。

ただし、MoEをCPUで動かす場合はエキスパートの選び方も重要です。エキスパートが頻繁に切り替わると、CPUのキャッシュに載せたデータがすぐ不要になり、遅いメインメモリから別のデータを読み直すことになります。古いサーバーでAIを速く動かすには、キャッシュに載せたデータをできるだけ長く使い回す必要があります。

そのためcafkafk氏は、CPU向けにMoEの動きを調整する「--cpu-moe」や、エキスパート内部の計算をまとめる「--merge-up-gate-experts」を使用しています。通常であれば複数回に分かれる計算やメモリアクセスをまとめることで、DDR3メモリとの往復を減らす狙いです。ローカルAI高速化というより、メモリ移動を減らすための地道な交通整理に近い内容。

スレッド数の設定も重要です。使用マシンは8コア16スレッドですが、cafkafk氏は「-t 8」で物理コア数に合わせています。SMTによる16スレッドをすべて使えば速くなりそうですが、メモリ帯域が詰まっている状況ではスレッドを増やしても重みの読み出しは速くなりません。むしろスケジューリングの負担が増え、速度が伸びにくくなるとのことです。

「--mlock」も重要な設定です。Linuxではメモリが不足すると、使われていないデータをストレージへ退避するスワップが発生します。AIモデルの重みがスワップへ追い出されると、DDR3どころかストレージから巨大な重みを読み直すことになり、生成速度は一気に低下します。--mlockはモデルを物理メモリへ固定し、スワップによる失速を防ぐ設定です。ただし、Linux側のmemlock制限が小さい場合は設定が失敗するため、OS側の制限変更も必要になります。

さらに、重みをメモリ上でCPUが読みやすい形に並べ直す「--run-time-repack」も使われています。モデルの重みは単なる巨大な数字の表ではなく、CPUが読み込みやすい並びと読みにくい並びがあります。起動時に時間をかけて重みの配置を整えれば、実際に文章を生成するときのメモリ読み出しが効率化されます。

KVキャッシュの扱いもCPU専用構成では見逃せません。KVキャッシュは会話の文脈を保持する短期記憶のような領域で、長い文章や長い会話を扱うほど大きくなります。GPUがある環境ではKVキャッシュをGPU側へ逃がすことがありますが、GPUなし構成ではオフロード先のGPUが存在しません。cafkafk氏は「--no-kv-offload」でKVキャッシュをGPUへオフロードしないように指定しています。

入力されたトークン同士の関係を計算するアテンション処理にも高速化が使われています。文章が長くなるほど関係の組み合わせは増え、普通に処理すると巨大な行列をメモリに書き出す必要があります。Flash Attentionは巨大な行列を丸ごとメモリに置かず、小さな単位で計算を進めることでメモリ消費とメモリ帯域の負担を減らします。

「--flash-attn on」と「--mla-use 3」も使われています。MLAはMulti-Head Latent Attentionの略で、KVキャッシュを圧縮するような仕組みです。会話の短期記憶をそのまま大きく保存するのではなく、より小さな表現にまとめることで、巨大な文脈を扱う際のメモリ使用量を抑えます。

一方で、すべての設定が期待通りに効くわけではありません。投稿では計算グラフの分割に関する「-sm graph」などの設定も登場しますが、Gemma 4の外部MTP構成ではグラフ分割がサポートされず、レイヤー分割へ自動的に切り替わったと説明されています。cafkafk氏は「将来的に役立つ可能性がある」と述べています。

実際のメモリ使用量もかなり大きいものです。cafkafk氏によると、262Kトークンの文脈長ではモデルの重みとキャッシュを合わせた必要メモリは約82GB。内訳は重みが約25GB、KVキャッシュが約56GBで、KVキャッシュの方がモデル本体より大きくなっています。128GBのDDR3メモリがあるからこそ試せる構成というわけです。

こうして、cafkafk氏は「読むのと同じくらいの速度(reading speed)」でトークンを生成することに成功したとのこと。「最先端のAIをローカル環境で実行する際のボトルネックは、単にシリコンにあるのではない。推論エンジンが実際にどのように動作するのかを深く理解する必要があるのだ」と述べています。

また、エンジニア向けのニュース共有サイト「Hacker News」にcafkafk氏が登場し、質問に答えました。

「reading speed」とは具体的に何トークン毎秒なのかという質問に対し、cafkafk氏はサーバーが別の処理を抱えた状態で簡易ベンチマークを実行したところ、生成速度は11.94トークン毎秒だったと述べています。負荷がない状態では20トークン毎秒を超える可能性があるとも述べていますが、こちらは厳密なベンチマークではなく感触に基づく数字とのこと。250語毎分の読書速度はおおむね5～6トークン毎秒に相当するため、少なくとも負荷中の11.94トークン毎秒でも「読む速度」に届いていると説明しました。