13年前のXeonでGemma 4 26B、GPUなし5 tok/s
Original: Running Gemma 4 26B at 5 tokens/sec on a 13-year-old Xeon with no GPU View original →
13年前のXeonサーバーでGemma 4 26Bを約5 tokens/secで動かしたという話は、単なる古い機械への郷愁ではない。local inferenceがどこまで下りてくるのかを示す境界テストである。対象はHP StoreVirtualを再利用したdual Xeon E5-2690 v2、DDR3、GPUなし、AVX1のみ対応でAVX2もFMA3もないIvy Bridge世代の機械だ。
面白いのは、遅さそのものではなく壊れ方だった。使われたのはGemma 4のMoE inferenceに必要な最適化を含むikawrakow版ik_llama.cppで、一部の高速経路はAVX2を前提にしていた。pre-AVX2環境ではgraph builderがfused opを作る一方、dispatcher側には対応するcompute pathがない。クラッシュやNaNではなく、計算されないtensorが混ざって決定的な多言語ノイズを出すため、原因を見つけにくい。
修正は、AVX2専用のfused up-gate経路を古いCPUでも動く2つのmatmulとSILU乗算へ分解するものだった。scalar compile fixやCI stubの整理も加わり、non-AVX2環境でもbuildと実行が通るようになった。結果としてGemma 4 26B-A4BのQ8_0がCPU-onlyでdecode約5.2 tok/s、prompt eval約16 tok/sに到達した。
HNの議論はすぐに経済性へ移った。電気代と冷却まで入れれば、provider inferenceのほうが安いという計算がある。一方で、すでに手元にある古いサーバーなら、private workload、低速batch処理、offline用途、API障害時のfallbackとして価値があるという見方もある。local AIを語るには、token単価、電力、速度、データ制御を同じ表に置く必要がある。
もう一つの論点はagentの使い方だ。これは「AIが一発で直した」話ではない。人間が実験を回し、ログを読み、正しい出力の基準を持ち、失敗条件を狭めたからこそ、agentが未知のC++ inference codeへ深く入れた。local inferenceの未来は最新GPUだけではない。古いinstruction setと正確なdebuggingが、捨てられたサーバーをもう一度使える道具にする。
Related Articles
大きな反応を集めた理由は古いCPUの意外性だけでなく、LLM inferenceの現実的なボトルネックが見えたことにある。
注目点は、巨大なMoEモデルを普通のPCで実用的に動かせるのかという現実的な問いだ。ColibriはGLM-5.2の疎な活性化を使い、モデル全体をRAMやGPUへ一度に載せない設計を取る。
patched llama.cpp で Qwen 3.5-9B を MacBook Air M4 16 GB と 20,000-token context で動かしたという LocalLLaMA 投稿は、今回の 2026年4月4日クロールで 1,159 upvotes と 193 comments を集め、TurboQuant を単なる研究見出しではなく実際の local inference 議論に押し上げた。