MetaがGraviton5を大量採用——AIインフラの変化がエンジニアに意味すること

MetaがAWSと組んで、エージェント型AIの処理に「AWS Graviton」コアを数千万個規模で投入するという話を読んだ。
最初は「またビッグテックのインフラ話か」と流しかけたけど、ちょっと待てと思って読み返した。

GPUじゃなくCPUを積むという選択

今回の肝は、AIのワークロードにGPUではなくArmベースのCPUを本格活用するという方向性だ。
Metaが採用するGraviton5は3nmプロセスで製造されていて、前世代比で最大25%のパフォーマンス向上を謳っている。
コア数は192、コア間の通信レイテンシは最大33%削減。

なぜGPUじゃなくCPUなのかというと、エージェント型AIが求める処理の性質が違うらしい。
リアルタイムの推論、コード生成、そして複数ステップにまたがる自律タスクのオーケストレーションは、GPUより汎用CPUに向いているということのようだ。

これ、自分が最近触っているLLM周りのコードと直接つながる話だと思った。

自分のコードへの影響を考えてみた

LLMのAPIを叩くコードを書いていると、ボトルネックって意外とGPU側じゃないことが多い。
プロンプトの前処理、レスポンスのパース、ツール呼び出しの管理あたりがじわじわ重くなる。
エージェント構成にするとさらにその傾向が強くなる気がしている。

Metaが「CPU負荷の高い処理を効率化するためにGravitonを選んだ」と言っているのは、まさにその部分への投資だ。
つまりクラウド側のCPU性能が上がれば、自分が書いたエージェントの応答速度も恩恵を受ける可能性がある。
AWSのEC2やLambdaでGraviton5インスタンスが使えるようになれば、コスト最適化の選択肢が増える。

今でもGraviton4ベースのインスタンスはARM64向けにビルドしないといけないので、Dockerfileを確認しておくのは早い話だ。

# Graviton対応を意識するならプラットフォーム指定を明示する
FROM --platform=linux/arm64 python:3.12-slim

これを忘れると、デプロイ後にx86のイメージをエミュレーションで動かすことになって逆に遅くなる。
自分も一度やらかしたことがあるので、Graviton系を使うなら最初から意識しておいた方がいい。

AIインフラの多様化が進む中で何をするか

Metaの今回の動きで感じるのは、「AIインフラはGPU一択」という時代が少しずつ変わり始めているということだ。
Gravitonのような汎用CPUがエージェント処理に本格採用されるなら、使う側のエンジニアもアーキテクチャの選択を見直す機会になる。

個人開発でLLMを使ったツールを作るとき、インフラコストは本当に悩みどころだ。
GPUインスタンスは強力だけど、常時起動するには高すぎる。
CPUベースのGravitonインスタンスで十分な処理が増えるなら、月の請求がかなり変わってくる。

今すぐGraviton5が手元で使えるわけじゃないけど、自分はまずARM64でのビルドを普段のDockerfileに組み込んでおくつもりだ。
対応しておけば、新しいインスタンスタイプが来たときにすぐ乗り換えられる。