10年前のXeonで十分だ

 (point.free)
5 ポイント 投稿者 GN⁺ 4 시간 전 | 2件のコメント | WhatsAppで共有
  • Gemma 4 26B-A4B を、2016年製の単体 Intel Xeon E5-2620 v4、DDR3 128GB、GPUなしサーバーで、ik_llama.cpp の最適化により読書速度レベルで動作させた
  • LLM のデコーダーパスは計算よりも メモリ帯域幅 がボトルネックであり、CPU は次の重みを RAM からキャッシュへ持ってくるのを待つ時間が長い
  • --spec-type mtp、--cpu-moe、--merge-up-gate-experts、--run-time-repack などは、MTP 推測デコーディング、MoE ルーティング、キャッシュ親和的なメモリ配置によって DDR3 環境のボトルネックを緩和する
  • ログ基準の総メモリ要求量は 82,355MiB で、全 262K コンテキストでは重み約 25GB より KV キャッシュ約 56GB のほうが大きい
  • ollama のようなブラックボックスツールは必要なモデル対応や細かな調整ノブが不足しており、古いハードウェアでは推論エンジンとメモリ構造を深く理解することで性能を引き出せる

実行環境と主要なボトルネック

  • テストサーバーは再利用機材で、仕様は Intel Xeon E5-2620 v4 @ 2.10GHz、8コア16スレッド、AVX2、20MiB L3 キャッシュ、2MiB L2、128GB DDR3、GPU なし
  • この CPU は AVX-512、AVX-VNNI、BF16 をサポートせず、内蔵 GPU もない
  • LLM 推論でトークンを1つずつ生成するデコーダーパスは、主に計算量ではなくメモリ帯域幅に縛られる
  • 次のトークンを計算するには、モデルの学習知識が入った重みを RAM から CPU キャッシュとコアへ継続的に移動させる必要があり、プロセッサは行列計算より次の重み転送を待つ時間のほうが長くなる
  • この「メモリの壁（memory wall）」は Xeon だけでなく H100 のような高性能機材でも重要な性能障壁として働く

ブラックボックスツールの代わりに必要な実行ノブ

  • DDR3・GPUなし環境で単純に llama-cli を実行すると非常に遅く、一般的な GPU 利用ケース向け最適化のため改善余地が大きく残る
  • ollama は必要なモデル対応がない場合があり、実行性能を十分に引き上げるほど詳細な設定を公開していない
  • 実際の実行には ik_llama.cpp が公開している多数のフラグを組み合わせる必要がある
  • 主要なフラグの組み合わせは次のとおり
--spec-type mtp --draft-max 3 --draft-p-min 0.0 --spec-autotune  
-sm graph -smgs -sas -mea 256 --split-mode-f32  
-t 8 --parallel 8  
--cpu-moe --merge-up-gate-experts  
--flash-attn on --mla-use 3  
--mlock --run-time-repack --no-kv-offload

推測デコーディングと MoE 最適化

  • --spec-type mtp --draft-max 3 --draft-p-min 0.0 --spec-autotune は、26B の検証器（verifier）を、事前に作成した小型 MTP drafter とともに使用する
  • --draft-max 3 はドラフトあたり最大3トークン、--draft-p-min 0.0 は全確率を受け入れる設定、--spec-autotune はワークロードに応じてチェーン長を調整する
  • 長い推論チェーンを生成するとき、ユーザーには最終回答だけが短く見えても、隠れた思考トークンごとに完全なデコーダーパスが必要になる
  • CPU では検証器の重みをキャッシュへストリーミングするコストが大きく、小型 drafter の活性レイヤーは L3 キャッシュによく収まるため、推測デコーディングの利点がより大きくなる
  • Gemma 4 26B-A4B は、128 個のエキスパートのうちトークンごとに 8 個が活性化する MoE 構造で、全体約 25.2B パラメータのうち活性パラメータは約 3.8B である
  • --cpu-moe は CPU キャッシュ階層に合わせてルーティングを調整し、128 個のエキスパート間を行き来してキャッシュを空にし DDR3 から再取得するキャッシュスラッシングを減らすよう動作する
  • --merge-up-gate-experts はエキスパート内部の up projection と gate projection を1つの行列積に融合し、ログでは fused_up_gate = 1 として確認できる
  • -t 8 は物理8コアに合わせた設定で、メモリボトルネックのワークロードでは 16 本の SMT スレッドをすべて使うとスループットよりスケジューリングコストが増えることがある

メモリ固定、再配置、グラフ分割

  • --run-time-repack は推論直前に重み行列を CPU キャッシュのレイアウトに合わせて再構成し、ログでは Repacked 265 tensors と表示される
  • この設定は起動時に数秒のコストをかけて RAM 内の数値テーブルを CPU がより読みやすい形に再配置し、実際のテキスト生成中にメモリ帯域幅を最大限活用できるようにする
  • --mlock はモデルを RAM に固定し、OS がディスクへスワップできないようにする設定である
  • カーネルの memlock 制限が十分でないと failed to mlock 27628376064-byte buffer と Try increasing RLIMIT_MEMLOCK の警告が出るが、これは LLM 自体の問題ではなく基本的な ulimit 設定の問題である
  • --no-kv-offload は GPU のない環境で KV キャッシュを GPU に移そうとする探索をスキップし、システム RAM に保持する
  • -sm graph は計算グラフを縦方向に分割し、複数の処理装置やメモリ領域が同じレイヤーの異なる部分を同時に計算するグラフ分割を試みる
  • 今回の実行では Split mode 'graph' is not supported for Gemma4 external MTP というログとともに、レイヤー分割へ安全にフォールバックされた
  • -sas は物理 CPU ソケットまたは NUMA ノード間でのワークロード分割を指示し、--split-mode-f32 は分割後に再結合される中間地点で 32 ビット浮動小数点精度を使うようにする

Attention、メモリ使用量、結論

  • ikawrakow は CPU で Flash Attention を処理するカスタムカーネルを書いており、重いコンテキスト処理を GPU なしで動かせるようにしている
  • --flash-attn on は attention softmax と行列積を融合し、全体の N×N attention 行列を RAM に物理的に書き出さず、小さなチャンク単位でキャッシュ内で計算して消費する
  • --mla-use 3 は Multi-Head Latent Attention を有効にし、KV キャッシュの Key と Value をより小さな潜在表現に圧縮する
  • ログには flash_attn = 1、fused_moe = 1、fused_up_gate = 1 が表示され、これらの最適化が実際に適用されていることが分かる
  • メモリログ基準では全レイヤー合計は 81,607.46MiB で、モデルテンソルとキャッシュに必要なメモリは 82,355MiB である
  • 全 262K コンテキストでは重みが約 25GB、KV キャッシュが約 56GB で、KV キャッシュのほうがモデルより大きい
  • この設定では 25B パラメータの MoE を読み込み、MTP drafter による推測デコーディングを実行し、2016年製 Xeon と DDR3、GPU なしサーバーで読書速度でテキストを生成する
  • 結論として、最新のオープンウェイト AI をローカル実行するときのボトルネックはシリコンだけでなく、推論エンジンの動作とメモリ構造の理解にもあり、適切なフォーク、調整済み量子化、メモリアーキテクチャの理解があれば古いサーバーでも実行可能だということだ

関連記事

2件のコメント

 
GN⁺ 4 시간 전
Hacker Newsのコメント

  • 新しい Gemma 4 Drafter モデルを動かす方法が不足しており、主要なツールが性能調整ポイントを隠していることへのもどかしさからこの記事を書いたとのこと
    結局、GPUなしで、単一の Xeon E5-2620 v4 と 128GB DDR3 RAM しかない古い再利用サーバーで、最新の 26B MoE モデルを読書速度で動かすことに成功した
    記事の最後に量子化モデルへのリンクも貼ったが、言及した ik_llama-cpp フォークを使わないと動かず、詳細は別の記事を見る必要がある
    機械学習エンジニアではなく、サーバーも Nix キャッシュの役割で忙しいが、質問があれば答えられる範囲で答えられるとのこと

    • メモリ帯域幅に縛られる作業なら、SMT はむしろ典型的に有用なケースではないかと気になる
      1つのスレッドが DDR3 を待っている間に、別のスレッドが実行できるため
      また、--cpu-moe の説明もよく分からない。1つのエキスパートが約 4.0GiB のパラメータを持っているのに、L3 キャッシュが 20MiB しかないなら、エキスパートの順序を最適化してもパラメータを有意にキャッシュできないように思える
      他の人も言っているように、Intel Xeon E5-2xxx v4 の一部だけが DDR3 をサポートしており、Intel の資料では E5-2620 v4 はその1つではない
    • 本当に実用的で素晴らしい成果だ。似たような Dell T7610 ワークステーションでも同等かそれ以上の性能が出るのか気になる
      デュアル Xeon と 128GB DDR3 の構成で、CPU は合計 24コア/48スレッドの 2 × Xeon E5-2697 v2 なので、コア数は上だが実際の差は大きくないかもしれない
      ほこりをかぶっているだけの機材だが、読書速度 Gemma ならかなり期待できそう
    • 2年前に Amazon でリファービッシュの 2× E5-2690v4 サーバー、128GB RAM、Dell T7810 を 500ドル未満で買った
      Amazon で「chia farming」を検索するとよいが、chia seeds は無視すればいい
      今では同じ機材が 2.5倍ほど高くなっているが、現行世代の DDR5 マシンよりはずっと安い
      https://www.amazon.com/dp/B095TRGCSX
    • 本当に DDR3 なのか疑わしい。家に E5 v4 の機材が2台あるが、どちらも DDR4 なので、2011-3 ソケットが DDR3 と DDR4 の両方をサポートしているのか混乱する
    • この構成は自分の状況にぴったりに見える
      Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz、オンライン CPU 0-31、128GB RAM の構成だ
      DIMM スロットが8個あると、実際にメモリ帯域幅も良くなるのか気になる。今このかわいそうな機材は YouTube 視聴用にしか使われていない

  • まだそこまでではないが、今のバブルが終わる明白な終着点は、ローカルハードウェアやデバイス上で動く公開モデル が大半の用途で「十分に良い」ものになることだ
    そうなれば、現在の技術業界で起きていることは完全に崩れるかもしれない

    • 自分にもすでにそういうことが起きた。CoPilot の価格変更をきっかけにサブスクリプションを解約し、VRAM 内だけで動く ローカルのコーディングモデル を入れた
      本当に行き詰まった時は Claude API を呼ぶだろうが、必要の 80% はもっと賢くないローカルモデルでこなせそうだ
      プログラミング言語や手法は大きく変わらないので、少なくとも5年は使えることを期待しているし、同じ VRAM にもっと賢いモデルを載せられるよう最適化が進んだら、その時にアップグレードすればいい
      この方向性は気に入っている
    • Amazon としては、公開モデルを動かし、実行コストに近い価格で時間単位の利用を売るほうが有利ではないかと思う
      そうしない理由を推測するなら、現在 AI 研究所がモデルを大きな赤字で売っているため、Amazon にとって低マージンの計算資源は他の高マージン商品ほど魅力がないからかもしれない
      現状が崩れるのに、必ずしもローカル実行まで進む必要はないのかもしれない。AI 研究所の潤沢な資金の滑走路が尽き、実際の実行コストを上回る価格で売らなければならなくなれば、計算資源を持つ誰にでも 公開モデルサービス を汎用的な価格でより安く提供する誘因が生まれる
    • OpenAI や Anthropic は、究極的には AI 企業というより 計算インフラ事業 に近い
      誰もがモデルを持ち、実行する能力を持つようになるだろうし、そのため GPU 不足が彼らに有利に働いている
    • 新たに誕生した兆ドル級の企業にとっては最悪のシナリオだ
      彼らの希望は、企業や中小企業がすべての業務プロセスをクラウドに移し、従業員ができるだけ多くのトークンを使うよう競争することにかかっている
    • 完全に崩れるとまでは言わないが、その方向に進んでいるのは確かだ
      「十分に良い」モデルにプライバシーと長期的なコスト削減が加われば魅力的だ
      逆説的に、コーディングエージェント向けの汎用実行環境が良くなるほど、Claude のようなサービスの堀は浅くなる。数か月前の最前線モデルに、一部の公開モデルがどれほど早く追いついたか信じがたいほどだ

  • 記事も良く、技術的にも印象的だ。ビルドパイプラインを理解し、ローカルで実行できるべきだという点には同意する
    ただし、電気料金次第では経済的ではないかもしれない。古いサーバーはエネルギー効率が低く、昔の Xeon サーバーは負荷時に 200W くらい食うと思っていたが、同じモデルは OpenRouter では 100万トークンあたり 0.1/0.3ドル、76トークン/秒、262k コンテキストで提供されている
    しかも、こうしたサーバーはうるさい。ただし 200W という見積もりは高すぎた気もするし、昔使っていた古い Xeon サーバーが電気を多く食ったのは覚えているが、正確な型番は思い出せない

    • 2620v4 は電力を食いまくる怪物ではない。サーバーボード次第ではあるが、サーバーが必ずそうだというわけでもない
      サーバーはたいていうるさいが、それも構成による。こうしたチップをベースにした格安ホスティングは多く、思ったより電力効率は良い
    • 負荷時は 85W に近いはずだ。安価なクーラーでも非常に静かで、温度も 50°C をめったに超えない
    • 1U や 2U に収めるには、必要な静圧を作るために高速ファンが必要なので、こうしたサーバーはうるさい
      似た構成を 4U ケースと低速の 120mm ファンで動かせば問題ない

  • ほかの人たちもこれに気づいているのを見るとうれしい。2012年製のXeonと16〜24GB RAMのコンテナで Gemma 26B-A4B Q4 を動かしていて、おおよそ8〜12トークン/秒が出ている
    大きなコンテキストやGPU実行と比べることはできず、llama.cppの画像デコーダもGPUよりかなり遅いが、小さな自動化タスクや一般常識の質問には十分使える。読みながら追える程度なので待ち時間もそれほど苦にならない
    構成はOpenBLASとOpenMPを有効にした llama.cpp ビルド、OPENBLAS_NUM_THREADS=4、OMP_NUM_THREADS=4、unsloth/gemma-4-26B-A4B-it-GGUF:UD-Q4_K_XL、q8_0 キャッシュ、8192コンテキストといった設定
    CPUごとにAVX2のような最適化を探す必要があり、MTPは少し試したが性能向上はなかった。キャッシュやコンテキストのバッチサイズを調整したり、Q2まで落とすこともできるし、スレッドの過剰割り当ては避けたほうがよい。まずはデフォルト設定や llama-bench から試すのを勧める

    • いま フランケンシュタイン・システム を組んでいる。中国製DDR3 X99ボード、12コアXeon v3、32GB 1866MT/s RAM、1080 Ti構成
      テスト中には、11GB VRAMに完全に収まる gemma4:e4b-it-q4_K_M を動かし、50トークン/秒を超えた。そのくらい小さいモデルはコーディングには役立たないが、ほかの用途はありそう
      Wake-on-Useを作って、個人用ChatGPTのように使いたい。PiをプロキシにしてWake-on-LANスクリプトを呼ぶ形も可能かもしれず、いつか面白い週末プロジェクトになりそう
      常時起動しているLLMは、12GB 2060に半分も載らないdenseな Gemma4:31b で、非常に遅いが品質は良く、自動キュー処理用途なので出力を見て待ち続けるわけではない。2060がもう1枚あるが、2枚とも挿すとPCがPOSTできない
    • llamaとローカルコンピューティングの話として、数日前に Georgi Gerganov がMac M2 UltraやRTX 5090でローカルにQwen3.6 27Bを動かし、llama.cpp開発を支援しているとツイートしていた

  • しばらくMac Studio Proを検討していたが、結局こちらの道に来た。HP Z620 のヘッドレスマシンに192GB ECC RAM、デュアルXeon E5-2680 v2、Optane AIC、10GB VRAMのP102-100を2枚、Debian 12.6を載せた最小ブートSSD、Pascalカードをサポートする固定の旧CUDAを構成した
    地下室からAMT/meshcommanderでリモート利用し、llama.cpp とフロントエンドを立ち上げてローカルネットワーク経由で接続している。Talkie、Qwen 3.6 27b、medgemmaを触っていて、適切な量子化を選べばGGUFの性能は全体的にかなり良かった
    総費用は500ドル未満だったが、昨年eBayで買ったサーバーなので今は事情が違うかもしれない
    今後 三進法LLM が花開けば、この古いハードウェアでも実は知識の詰まった高密度モデルをホストできるようになってほしい。GPU RAMより大きく、Optaneにはみ出しても構わず、速度より一般的な事実知識のほうが重要だ
    最終計画は、設定後に地下室のFaradayゴミ箱に保管し、世界が崩壊したときの「文明再建」用オラクルとして残しておくこと。もちろんその状況では電力が問題になるだろうが、このハードウェアがこれほど安く、最新AIが実用的な場面が多いなら試す価値はある

  • AIの進歩で最も面白いのはAGIや特定のAIユニコーンの最新モデルではなく、ローカルで何を動かせるか だ
    6年前には高性能ゲーミングPCで面白いがほとんど役に立たないモデルを動かしていたが、今ではM5ノートPCでそれより100倍優れたものを動かせる
    市場がメモリ不足に反応し、Apple siliconの進歩が同じペースで続くなら、6年後にローカルで動かせるものは非常に興味深いか、あるいは恐ろしいものになるだろう
    これがAI企業のバリュエーションに何を意味するのかも分からない。以前イベントでその会社の社員に似たような質問をしたら、答えずにカクテルを取りに行ってしまった

    • 口にできないこともある。AIモデル事業には、持続的で守りやすい技術的優位という 堀 はなく、短期的な優位しかない
      AI事業は古い工場のように資本集約的だ。データセンターは高価で、モデルは大量の電力を消費し、内部ハードウェアは3〜4年ごとに入れ替える必要がある
      より小さく特化したモデルが下から利益率を削っていく。文字起こし、音声、画像検出に巨大モデルは不要だ
      従来のソフトウェア事業のような高い利益率を期待する理由はなく、AIの利益の大半は消費者に渡る。ただし、Microsoft、Google、Amazon、Metaのような一部の巨大企業は規模の経済でコスト優位を狙えるかもしれない
    • コンシューマー向けハードウェアでローカル実行できる水準はかなり順調に伸びている
      5080のような最上位ではないが、そこそこ良いゲーミングGPUがあれば、2025年初頭の最先端より優れたローカルモデルを動かせる
      やりたい作業に応じてモデルを切り替える必要はあるかもしれず、1つで全部こなす超巨大モデルはまだデータセンターの領域だ
    • 結局は 利便性 の問題だ。Wikipediaからソーシャルメディア、メール、動画サーバーまで、多くのものをローカルで動かせる
      しかし、フルタイム勤務で子どもが2人いる大半の人には、パッチ適用や保守に割く時間もエネルギーもない。システムはどんどん複雑になり、バグも増える。自由と利便性の間にある昔からのトレードオフだ
    • AI企業のバリュエーションにはおそらくほとんど影響しない
      大半のユーザーはLLMが何かも、どう実行されるかも知らない。多くのLLM利用者は職場で提供されるものをそのまま使い、少し詳しいユーザーでもOpenAIやAnthropicのサブスクリプション料金を払うことに抵抗がないように見える
      ローカルLLMを好む、小さいが熱心なオープンウェイトモデル利用者層は生まれるだろうが、それ以外は大手プロバイダーから消費し続ける可能性が高い。今日のOS選択のように、少数のLinuxユーザーと大多数のWindows、macOS、Chromeユーザーという構図に近いかもしれない
    • ソフトウェア、とくにゲームでは昔からそうだった
      5〜6年前のゲームはずっと安く買えて、平凡なハードウェアでも動かせる。だが業界が5年間止まっているわけではないので、より良いハードウェアを必要とする新しいソフトウェアが出続ける

  • 元の投稿者がコメントで明かした結果は約12トークン/秒
    このハードウェアで可能だと思っていたよりはるかに印象的な努力だが、満足できる対話型セッションに必要な水準にはまだかなり足りない

    • 特にこの手の小さなモデルは、OpenRouterのようなプラットフォームでは本当に安くて速い
      最先端モデルより100〜500倍安いことが多く、トークン/秒も2〜5倍速い場合がある
    • その結果を見つけるまでに時間がかかりすぎた。SSDでもモデルを動かせることを考えると、遅いRAMで実行可能なのは驚くことではない
    • 対話型としてもそこまで悪くはない: https://mikeveerman.github.io/tokenspeed/?rate=12&mode=text
      バックグラウンド用途なら十分に問題ないだろう
    • 紙と鉛筆、関数電卓でもRSA暗号化はできる
      動きはするが、本格的な作業に使えるスループットではない

  • E5-2620 v4は素晴らしい。10年間使っていて、アップグレードしようとしたが今の価格を見てやめた
    64GB DDR4にRX 9060 XT 16GBを載せているが、ゲームもまだ十分高速に動く。DOOM The Dark AgesではCPUが少しボトルネックかもしれないが、60fps出るので問題ない
    軽量LLMをGPUで回すのは当然の選択で、CPUでもチューニングすればそこそこ動かせるのがすごい
    1か月前に2667 v4を30ドルで買い、かなり性能向上しそうだが、まだ必要になっていない。記事のようにLLM用途へさらに寄せるなら、2667は少し速いRAMを扱えるのでアップグレードするかもしれない

    • デュアルE5 2667-v4、256GB DDR4、Z640、1080 Ti構成だが、2025年上半期にSSDを除く部品を全部合わせて500ドル未満で揃えられた
      中古市場で見つかるものには今でもかなり驚かされる
      RAMとGPUの価格がここまで高騰するとは思っておらず、たまたまタイミングが良かった。eBayで300ドル前後の3080を確保して1080 Tiを売ることも考えているが、それ以外は素晴らしいアップグレードだった
      電気はCoca Colaみたいにがぶ飲みするが、ワークステーションとしては見事に動いてくれるので、壊れるまで使い倒すつもりだ
    • CPUを10年使うのは本当に長く感じる
      以前は熱による損傷で5〜7年もするとCPUは死ぬと思っていたが、それが間違った前提なのか気になる。今どきのCPUは昔よりずっと強くて頑丈なのかもしれない

  • 古いXeonの最適化に関連して、最近似たような記事があった
    “High-Performance AI on a Budget: Optimizing llama.cpp for Qwen3.5 Inference on a Dual-GPU HP Z440”
    https://news.ycombinator.com/item?id=47320244

  • 意外なことにItaniumもLLMにかなり向いているようだ: https://medium.com/@tglozar/running-llama-inference-on-intel...
    考えてみれば納得できる
 
cronex 1 시간 전

内容が面白いですね。旧型のXeonシステムがあるので、一度試してみようと思います。