AMD PACE — GPU不足時代、EPYCで380トークン/秒が出るという静かな一撃

NVIDIAのH100もH200も、依然として数ヶ月待ちが普通の世界だ。GPUが手に入らない、手に入っても電力と冷却のコストが重い、というインフラ担当者の愚痴はもう聞き慣れた。そこにAMDが小さな、しかし実務的に無視しづらい一手を置いてきた。

4月8日、AMDは「PACE（Platform Aware Compute Engine）」を公開した。一言で言えば5th Gen EPYC（Zen 5）のCPUでLLM推論をフルスロットルに回すためのサービング基盤だ。そしてこれが、ベンチマーク上でvLLMを明確に上回る数字を叩き出している。

何がどれくらい速いのか

一番刺さるのは、数字だ。AMDが公開した、EPYC 9755を使ったLlama 3 8Bの比較結果を並べるとこうなる。

モード	vLLM 0.17との比較（幾何平均）
自動回帰デコード	1.60倍
スペキュラティブデコード（batch size 1）	最大4.45倍
サービングモード（エンド・トゥ・エンド）	最大2.06倍

PARD（Parallel Draft Models）と組み合わせた構成では、Llama 3.1 8Bで約380トークン/秒を単一のEPYCノードで出せる。batch size 1、つまり1ユーザーが独占する状況で、人間の読解速度をはるかに超える出力が返ってくる。CPUだけで、だ。

これは地味に衝撃的な数字で、「GPUを持たないエンタープライズにはCPU推論は現実的じゃない」という従来の共通認識を揺さぶってくる。もちろん70Bクラス以上のモデルや巨大なバッチサイズでは依然としてGPUに分があるけれど、8〜13Bクラスの実用ワークロードに関しては、EPYC+PACEで十分まかなえる射程に入ってきた。

PACEの仕組みをざっくり

技術的に何をしているのか、要点だけ整理する。

統合スケジューラ: LLM推論にはprefill（プロンプトを一括で処理する段階）とdecode（トークンを1つずつ出す段階）という、性質の違う2フェーズがある。多くの既存エンジンはこの2つを時間的に分離して走らせるが、PACEは両者をワークロードパーティショニングで同時にCPUコア上に載せる。CPUのキャッシュ階層とSIMDユニットの使い方を、モデルの挙動に合わせて動的に調整していく発想だ。

連続バッチ/バッチデコード: 従来の自動回帰モードに加え、バッチをかき集めて処理する運用モードを持つ。これがサービングモードでのスループット改善（2倍強）に直結している。

スペキュラティブデコード + PARD: 小さなドラフトモデルが先に「次のトークン候補」を提案し、本体モデルが検証する方式。AMDは並列ドラフト（Parallel Draft Models）を組み合わせることで、CPU環境でのメモリ帯域と演算量のバランスを取り直している。スペキュラティブデコードがGPUで効きづらかった理由は「本体とドラフトの同期オーバーヘッド」にあったが、PACEはCPUの特性に合わせてそこを設計し直した格好だ。

オープンソース: GitHub（amd/AMD-PACE）で公開されている。ライセンスとドキュメントを読んだ上で、自社インフラに組み込める。この点は大事で、クローズドなインフラ最適化だと「ベンダーロックイン覚悟でないと試せない」という壁があった。

誰にとって意味があるのか

PACEが効いてくるのは、次のような組織だろう。

オンプレでAIを回したいエンタープライズ: 金融、医療、法務、製造業の一部。データを社外に出せない事情を持つ業界は、GPUクラスタを自前で組むよりもEPYCサーバーにLLM推論を載せるほうが調達も運用もずっと楽だ。Mistral Small 4やLlama 3.1 8B、Gemma 4といった8〜14Bクラスのオープンモデルが実用域に入っていることもあり、「CPUで十分」な案件は着実に増えている。

開発環境・CI用途: コードレビュー、静的解析、内部ドキュメント検索のような継続的に走るタスクは、ピーク性能よりもコスト効率と可用性が重要になる。GPU一枚を遊ばせておくよりも、既存のEPYCサーバーの空きコアにPACEを載せて回す方が、総所有コストは下がる。

マルチリージョンのエッジ推論: 巨大GPUクラスタを各リージョンに置くのは不経済。AWS・GCP・Azureのリージョンを問わず、EPYCインスタンスはほぼどこでも借りられる。地理的な分散を優先する場面では、PACE + EPYCの組み合わせが現実解になる可能性がある。

個人開発者にとっては正直、直接の恩恵は薄い。自宅のサーバーにEPYC 9755を載せている人はそう多くない。ただ、PACEがOSSで公開されたことで、将来的にコンシューマ向けZen 5 CPU（Ryzen 9000シリーズ）向けの派生や、より軽量な実装が出てくる可能性は残されている。

vLLMとの距離感

ここは誤解されやすいので整理しておく。PACEはvLLMの代替ではなく、vLLMがあまり得意でなかったCPU推論領域を埋めるポジションだ。GPUクラスタで巨大なバッチを回すなら、依然としてvLLM（あるいはTGI、SGLang）が第一選択になる。PACEの数字を見て「vLLMは時代遅れ」と解釈するのは早計だ。

比較条件を冷静に見ると、AMDのベンチマークはCPU vs CPUでの勝負ではなく、EPYC 9755上でのvLLMの挙動を基準点にして、PACEがどれだけ引き上げたかを示している。同じハードでvLLMを使うよりPACEのほうが速い、という主張だ。

また、ベンチマークで使われたLlama 3 8Bはモデルサイズとしては扱いやすい部類で、70B以上でどうなるかは別の検証が要る。大きなモデルはメモリ帯域の壁に当たりやすく、CPU推論は不利になる傾向がある。ここは過剰な期待を持ち込まないほうがいい。

懸念と限界

フェアに書いておく。

ハードウェア縛り: PACEの真価は5th Gen EPYC（Zen 5）の微細な命令セットに最適化されている部分にある。古いEPYCやIntel Xeonでも動くかもしれないが、同じ速度は出ない可能性が高い。つまり、既存資産のEPYC 4thや3rd Genを活用するという用途には直接効かない。

ドキュメントの厚み: 公開されたばかりなので、プロダクション投入に必要なデプロイガイド、障害対応、観測性のベストプラクティスが十分に揃っていない。先行導入するチームは、GitHubのIssueを追いかけながら試行錯誤することになる。

NVIDIAとの比較情報の不足: AMDは「vLLMに対するスピードアップ」を見せているが、同価格帯のNVIDIA GPU（A10、L4、RTX 6000 Ada等）を使ったセットアップとの直接比較は提示していない。TCO（総所有コスト）の議論には、電力消費、冷却、ラック密度、ライセンスなど複数軸が絡む。数字の裏取りには時間がかかる。

何が変わりうるか

PACEそのものがAIインフラの景色を一夜で変えることはない。だが、「GPUでなくてもLLMは実用速度で回る」という事実が数字で示されたことは、インフラ選定の会議室に持ち込める新しい根拠になる。

これまで「NVIDIA一択」と言われ続けてきた領域で、AMDはここ数年地道にソフトウェアスタック（ROCm、OptimumAMD）を整えてきた。PACEはその延長線上にある、CPU側からの補強策だ。GPUを握りすぎたNVIDIAに対して、「実は必要な案件ぜんぶGPUじゃない」と静かに示してみせる動き。派手さはないが、エンタープライズAIの経済性を着実に揺さぶる種類の発表だと思う。

H100の入荷を待っているプロジェクトがあれば、待つ間にEPYCサーバー1台でPoCを走らせる選択肢が、現実味を帯びてきた。少なくとも、そういう会話ができる状態にAMDは引き上げてきた。

AMD PACE 公式技術記事 / GitHub (amd/AMD-PACE)