概要
- 13年前の HP StoreVirtualサーバー で最新AIモデルGemma 4を動作
- AVX2非対応 のIvy Bridge Xeonで工夫して高速化
- Claude によるコード修正とデバッグ事例
- 5トークン/秒 の実用的な生成速度を達成
- 古いハードウェア活用のノウハウと教訓
13年前のサーバーでGemma 4を動かす挑戦
- ハードウェア ：HP StoreVirtual（Xeon E5-2690 v2×2、DDR3、GPUなし、AVX1のみ対応）
- モデル ：Gemma 4 26B-A4B（MoE）、Q8_0量子化
- パフォーマンス ：デコード約5.2トークン/秒、プロンプト評価約16トークン/秒
- コスト ：サーバー本体は$300未満
- 目的 ：GPUやクラウドに頼らず、古いエンタープライズ機材で最新AIを動かす実践例
きっかけと参考事例
- Hacker News で「A 10 year old Xeon is all you need」という記事が話題に
- 2016年製Broadwell XeonでGemma 4をGPUなしで動作
- ik_llama.cppと多くの最適化フラグを駆使
- 自分の環境 （Ivy Bridge Xeon）はさらに古く、AVX2非対応
- 最初はビルド失敗、Claudeに原因調査を依頼
問題の分析と解決までの流れ
- 失敗原因 ：ik_llama.cppの高速カーネルがAVX2/FMA3専用で、Ivy Bridgeでは命令セットが未対応
- Claudeの支援 ：パフォーマンスクリティカルなC++コードを解析し、AVX2未対応CPU向けにフォールバックルートを実装
- 自分の役割 ：実験・出力確認・「正しい」結果の判断
主な技術的課題
- GGML_USE_IQK_MULMATオフ時、MoE FFNの一部演算が未サポートで正常動作しない
- 症状 ：多言語のランダムな出力（ID分布が均一、意味不明な文章）
- 原因特定 ：未初期化メモリがhidden stateに混入し、softmaxがフラット化
- 修正内容 ：
- AVX2依存の部分をスカラーループに書き換え
- グラフビルダーがAVX1/スカラーパスで動作するよう分岐追加
- CI用スタブの修正・追加でビルドエラー解消
実行方法と再現手順
- ハードウェア ：Xeon E5-2690 v2（Ivy Bridge、AVX1のみ）、DDR3、GPUなし
- ビルド ：ik_llama.cppをGGML_USE_IQK_MULMATオフでコンパイル
- モデル ：Gemma 4 26B-A4B, Q8_0
- ラン ：通常のCPUフラグで起動、--run-time-repackは使わない（AVX2専用レイアウトになるため）
- 結果 ：CPUオンリーで約5トークン/秒、コストほぼゼロ
この事例が示すもの
- サブスクリプション課金 やGPU利用が「AIに強い」の本質ではない
- 本当のスキル は「パッケージ化されていない問題にモデルを適用し、答えの妥当性を自力で見極める力」
- 古い機材の再活用 によるコスト削減・耐障害性の向上
- コードリーディングと粘り強い検証 が重要
技術的詳細（バグ内容と修正ポイント）
- ik_llama.cpp （ikawrakowのllama.cppフォーク）でGemma 4のMoE推論最適化
- AVX2未対応CPU でGGML_USE_IQK_MULMATオフ時、特定のgraph op（MOE_FUSED_UP_GATE、FUSED_UP_GATE）が未対応
- 修正 ：
- スカラーパスで各演算を分割し、既存の非IQK実装で処理
- #if !GGML_USE_IQK_MULMATで分岐し、AVX2ビルドは従来通り
- CI用スタブの署名・include修正
- パフォーマンスコスト ：2回のmatmul-ID呼び出しだが、CPUは元々メモリ帯域制約なので実害小
まとめと提案
- 古いエンタープライズ機材 でも工夫次第で最新AIモデルが実用速度で動作
- サブスクリプション依存からの脱却、ローカルモデルの価値
- コードを読む力、問題特定・修正までの粘り強さ が今後ますます重要
- PRスレッド でのフィードバック歓迎
- Railsアプリや古いDB の延命も同じスピリットで対応可能
参考情報
- サーバーコスト ：$300未満でクラウド月額$1,500に対抗
- 静音化・起動プロジェクト も別途紹介あり