AIエージェントがコードを実行し、Webを検索し、データベースから情報を取得している間、大規模言語モデル（LLM）の推論を担うGPUが待機することがある。
こうしたツール処理の多くは、現在のAIシステムではCPU上で実行されるか、CPUによって制御されている。「GPUは条件分岐が苦手だからだ」と説明されることもあるが、それだけが理由ではない。
NVIDIAのCUDA Programming Guideによれば、GPUも条件分岐そのものは実行できる。ただし、同じwarpに属するスレッドが異なる経路へ分かれると、該当しないスレッドを一時的に無効化しながらそれぞれの経路を処理するため、並列実行の効率が低下することがある。
一方、AIエージェントが利用するツールには、BashやPythonによるコード実行、Webアクセス、外部API、ファイル操作、大規模な検索インデックスなどがある。こうした処理がCPU側に置かれる理由には、OSや既存ソフトウェアとの連携、I/O、メモリ容量なども関係する。
Georgia Institute of TechnologyとIntelの研究者らが2025年11月に初版を公開し、2026年4月に更新した論文「Towards Understanding, Analyzing, and Optimizing Agentic AI Execution: A CPU-Centric Perspective」は、5種類のエージェント型AIワークロードを使い、CPU側のツール処理が実際にどの程度のボトルネックになるのかを測定している。
結果を見ると、ツール処理が全体の待ち時間を大きく左右するケースもあれば、依然としてLLM推論が支配的なケースもある。
つまり、「AIエージェントではCPUがボトルネックになる」という一文だけでは足りない。どのツールを使い、どのCPUとGPUを組み合わせ、何を測った数字なのかを見る必要がある。
AIエージェントのツール呼び出しでは何が動いているのか
AIエージェントは、LLMが一度推論して答えを返して終わるとは限らない。
途中で「このツールを使う」と判断し、その結果を受け取ってから、再びLLMが次の行動を決める。例えばコーディングエージェントなら、ファイルを開き、コードを書き換え、Pythonやテストを実行し、その結果を読んで次の修正を決める、といった処理を繰り返す。
論文では、こうした実行方式を大きく二つに分けている。
一つは、次にどのツールを使うかをLLM自身が判断する方式。もう一つは、ホスト側のPythonコードなどが、次に呼び出すツールやLLMを決める方式だ。
研究チームは、異なる種類のツールを使う5つのワークロードを選んで測定した。
- HaystackによるRAG
- Toolformer
- Web検索を組み込んだLangChain
- SWE-Agent
- ChemCrow
例えばSWE-Agentでは、Bashを使ったファイル操作やPythonコードの実行が含まれる。これは現在のコーディングエージェントにも近い処理だ。
論文は、AIモデルの推論自体は主にGPUで行われる一方、BashやPythonの実行、Web検索、LexRankによる要約、大規模データベースの検索など、多くのツール処理はCPU上で実行されるか、CPUから制御されるとしている。
ただし、「ツールだからCPUでなければならない」という意味ではない。
例えばRAGの検索について、研究チームは115GBのC4文書コーパスを使った。測定に使用した2種類のGPUはいずれもメモリ容量が96GBだったため、検索インデックスをGPUメモリへ収めることができず、CPU版FAISSを使って厳密最近傍検索（ENNS）を実行している。
この場合、CPUを選んだ理由には、GPUの分岐性能ではなく、扱うデータの大きさが直接関係している。
また論文には、同じツールをCPUとGPUの両方へ実装して比較した実験はない。
したがって、この研究結果だけから「ツール処理はGPUへ移しても速くならない」と結論付けることはできない。
GPUは「条件分岐できない」のではない
GPUについてよく使われる説明の一つに、「GPUは同じ計算を大量に並べるのは得意だが、条件分岐は苦手」というものがある。
方向としては理解しやすいが、より正確には、GPUも条件分岐を実行できる。ただし、同時に実行するスレッドが異なる経路へ分かれた場合に効率が落ちやすい。
NVIDIA GPUのSM（Streaming Multiprocessor）は、スレッドを32本ずつ「warp」と呼ばれる単位にまとめて実行する。
warpは一度に共通する命令を実行するため、32本のスレッドが同じ実行経路をたどる場合に最も効率がよい。この実行モデルはSIMT（Single Instruction, Multiple Threads）と呼ばれる。
単純化して考えるなら、32人の作業員が同じ指示に従って一斉に作業するようなものだ。
全員が同じ作業をするなら効率がよい。しかし途中で「条件を満たす人はA、満たさない人はB」と分かれれば、一つのwarpとして同じ命令だけを32本すべてへ有効にできなくなる。
CUDA Programming Guideでは、warp内のスレッドがデータ依存の条件分岐で異なる経路へ進んだ場合、各経路を処理する際に、その経路に属さないスレッドを無効化すると説明している。
この「warp divergence」によって、GPUの演算器の一部が使われない時間が生じ、実行効率が下がる。
ただし、これは同じwarp内での話である。
別々のwarpは独立してスケジュールされるため、一つのwarpで分岐が起きたからといって、GPU上のすべてのスレッドが同じように止まるわけではない。
さらに、Volta世代に相当するcompute capability 7.0以降では「Independent Thread Scheduling」が導入された。
GPUはスレッドごとにプログラムカウンタやコールスタックなどの実行状態を保持し、同じwarp内でもより細かい単位でスレッドをまとめ直して実行できる。
そのため、古いGPUの「warp全体が常に完全なロックステップで進む」というイメージを、そのまま現在のGPUへ当てはめるのも正確ではない。
それでも、同じwarp内で多くのスレッドが異なる処理を行えば、SIMTの並列性を十分に生かせないという基本的な問題は残る。
CUDA Programming Guideはさらに、CPUコアとは異なり、SMが命令をin-orderで発行し、CPUで一般的な分岐予測や投機実行を行わないことも説明している。
ただし、これらはGPUの実行モデルについての説明であって、「AIエージェントのツールはCPUで実行すべきだ」と示したものではない。
5つのワークロードでは、CPUが支配する場合としない場合があった
研究チームは二つのハードウェア構成を使って実験した。
Sys 1は、64コアのIntel Xeon Granite RapidsとNVIDIA RTX Pro 6000 Blackwellを組み合わせる。
Sys 2は、72コアのNVIDIA Grace CPUとH200 GPUを搭載したGH200 Grace Hopperシステムである。
どちらのGPUもメモリ容量は96GB。ソフトウェアにはPyTorch 2.8.0とvLLM 0.14.0を使い、それぞれのワークロードを5回実行した。
測定結果を見ると、「AIエージェントではCPUが常に支配的」という単純な結果にはなっていない。
| ワークロード | 主なツール | 総レイテンシで大きかった処理 |
|---|---|---|
| Haystack RAG | 厳密最近傍検索（ENNS） | 検索がSys 1で81〜83%、Sys 2では最大89% |
| Toolformer | WolframAlpha API | LLM推論がSys 1で約88%、Sys 2で77% |
| Web拡張LangChain | Web検索、LexRank要約 | LexRank要約がSys 1で48〜55%、Sys 2で40〜45% |
| SWE-Agent | Bash、Python実行 | Sys 1で25〜38%、Sys 2では最大65% |
| ChemCrow | RDKitによる3D配座生成 | 重い分子では85%（Sys 1）、88%（Sys 2） |
Haystack RAGの検索や、ChemCrowで計算量の多い分子を扱った場合には、ツール処理だけで総レイテンシの8割以上を占めた。
一方、WolframAlpha APIを利用するToolformerでは、LLM推論の方が大きな割合を占めている。
同じ「ツールを使うAIエージェント」でも、実際のボトルネックはツールによって大きく異なる。
Web検索を利用するLangChainでは、さらに別の要因がある。
URLから情報を取得する処理はネットワーク通信を伴うため、レイテンシのばらつきが大きかった。
待ち時間が長いからといって、それがCPUの演算性能だけで生じているとは限らない。
GPUを高速化するとCPU側の割合が大きくなることがある
二つのシステムを比べると、GPU側の推論が速くなることで、相対的にCPU側の処理が目立つ例も確認された。
Toolformerでは、LLM推論が総レイテンシに占める割合はSys 1の約88%から、H200を使うSys 2では77%へ下がった。
SWE-Agentでは逆に、BashやPythonによるツール実行の割合が、Sys 1では25〜38%だったのに対し、Sys 2では最大65%まで上がった。
研究チームは、高性能なGPUによってLLM推論が短縮されると、それまで目立たなかったCPU側のツール処理が新たなボトルネックとして現れる場合があると説明している。
ただし、Sys 1とSys 2ではGPUだけでなくCPUも異なる。
そのため、二つのシステムの差をすべて「H200にした結果」と考えることはできない。論文も、異なるCPUとGPUを組み合わせたシステム全体として評価している。
バッチを64から128へ増やすと、CPU側では待ち時間が急増した
研究チームは、一度に並行して処理するリクエスト数を増やした場合の性能も測った。
GPUによるLLM推論では、ある程度までバッチサイズを増やすことで並列処理能力を生かし、スループットを伸ばせる。
ただし、バッチが大きくなるにつれてKVキャッシュがGPUメモリを多く消費するため、容量やメモリ帯域の制約によって伸びは徐々に鈍る。
CPU側のツール処理では、別の問題が現れた。
SWE-Agentでバッチサイズを64から128へ倍増させた場合、平均レイテンシの増加幅は次のようになった。
| 処理 | 平均レイテンシの増加 |
|---|---|
| H200上のLLM推論 | 1.06倍 |
| RTX Pro 6000上のLLM推論 | 1.18倍 |
| Intel Granite Rapids上のBash多重プロセス処理 | 1.53倍 |
| NVIDIA Grace上のBash多重プロセス処理 | 1.94倍 |
同じ傾向は、LangChainのLexRank要約にも現れた。
バッチサイズを64から128へ増やすと、CPUで行う要約処理の平均レイテンシはSys 1で2.0倍、Sys 2で1.9倍になった。一方、GPU上のLLM推論時間はほぼ変わらなかった。
研究チームは、CPU負荷の高いLangChain、SWE-Agent、ChemCrowでは、バッチサイズ128付近でCPUコアの過剰な割り当てが発生し、スループットが飽和したとしている。
RAGの検索はさらに早く、バッチサイズ16または32を超えると、最終レベルキャッシュ（LLC）への負荷やディスクI/Oの競合によって伸びが鈍った。
論文のFigure 4aでは、CPUとGPUが高負荷になる時間帯も大きくずれている。
CPU負荷の高いツールを実行している間はGPUが待機し、GPUでLLMを推論している間は、CPUの負荷はオーケストレーションや実行時のデータ管理などに限られる。
つまり、CPUとGPUのどちらか一方だけを高速化しても、もう一方が待っている時間が残る。
CPUとGPUの処理を重ねる「COMB」
研究チームは、この問題への対策として「CPU-Aware Overlapped Micro-Batching（COMB）」を提案している。
大量のリクエストを一度にCPUへ渡すのではなく、小さなマイクロバッチへ分ける。
論文では、CPU側の並列効率を基に、上限をCPU数のおよそ1〜2倍に設定する方法を示している。
重要なのは、単にバッチを小さくすることだけではない。
あるマイクロバッチのCPU処理が終わり、その結果をGPUが処理している間に、次のマイクロバッチのCPU処理を始める。
こうしてCPU処理とGPU処理の時間帯を重ねることで、どちらか一方が待機している時間を減らす。
v3では、オープンループの負荷試験でCOMBによりサービスレイテンシがP50で最大2.9分の1、P90で最大3.9分の1、総レイテンシが最大1.8分の1になったとしている。
ただし、これは研究チームが構築した特定のワークロードとハードウェアで得た結果であり、あらゆるAIエージェントで同じ改善が得られるわけではない。
この研究だけで「CPUはGPUより並列処理が苦手」と一般化しない
論文では、今回の実験条件について、GPUでのLLM推論の並列化がCPUによる多重プロセス実行より効率的だったと述べている。
SWE-Agentでバッチサイズを64から128へ増やした際の1.06倍、1.18倍、1.53倍、1.94倍という差は、その一例である。
ただし、これは「CPUとGPUにまったく同じ処理を与え、ハードウェア本来の並列性能を比較した実験」ではない。
GPU側ではvLLMを使ったLLM推論を実行し、CPU側では複数のBashプロセスを動かしている。処理内容もソフトウェアスタックも異なる。
また、著者にはCPUを開発するIntelの研究者が含まれており、論文は2026年10月2日時点でも査読前のarXivプレプリントである。
したがって、この結果は「今回測定したエージェント型ワークロードでは、CPU側のツール処理がGPU推論より早く並列化の限界へ達した」と読むのが適切だ。
CPUとGPUというプロセッサー一般の性能差を証明した結果ではない。
NVIDIAは1ラックに2万2500超のCPU実行環境を配置
こうしたCPU需要の増加を意識した製品も登場している。
NVIDIAは2026年3月16日、エージェント型AIや強化学習向けをうたう「Vera CPU」を発表した。
同時に発表した液冷のVera CPU Rackは、1ラックに最大256基のVera CPUを搭載し、2万2500を超えるCPU実行環境を同時に動かせるとしている。
NVIDIAによると、それぞれの環境は独立して動作し、コンパイラ、スクリプト、ランタイム、エージェントが呼び出すツールなどを実行できる。
コーディングエージェントを開発するCursorもVeraの採用企業として挙げられている。
NVIDIA CEOのJensen Huang氏は発表時に、CPUはモデルを補助するだけの存在ではなくなり、AIシステムそのものを動かす役割が大きくなっているとの考えを示した。
ただし、「2万2500超のCPU環境」はNVIDIA自身による製品仕様・性能説明であり、独立した第三者による検証結果ではない。
CPUとGPUの比率も変わるとの予測
CPU需要の増加は、市場予測にも現れている。
TrendForceは2026年9月29日、現在のAIデータセンターでは、CPU 1基に対してGPUが4〜8基程度という構成が一般的だと説明した。
同社はArmの推計を引用し、従来型のAIデータセンターでは1GW当たり約3000万CPUコアが必要だったのに対し、エージェント型AIでは約1億2000万コアへ4倍に増える可能性があるとしている。
CPU:GPU比についても、将来はおよそ1:1〜1:2へ近づくとの見方を示している。
ただし、これは現在のAIデータセンターがすでに1:1へ移行したという意味ではない。
1億2000万コアという数字はArmの推計であり、1:1〜1:2という比率も将来予測である。実際の構成は、学習、推論、エージェント実行など、データセンターが担当する処理によって変わる。
NVIDIAのVera CPU Rackの登場と、こうした市場予測は、AIインフラでGPUだけでなくCPU側の処理能力も改めて注目されていることを示している。
「最大90.6%」は、どの版の数字なのか
この分野の記事を読む際に注意したいのが、「ツール処理が総レイテンシの最大90.6%を占める」という数字だ。
この数字は、2025年11月1日に公開された論文のv1に記載されている。
v1の要旨と本文では、CPU上で動くツール処理が総レイテンシの最大90.6%を占めたとしている。
一方、2026年4月16日に公開された現在のv3では、序論に「ツール処理が支配的なワークロードでは最大88%」と記載されている。
v3の個別結果を見ると、RAG検索はSys 1で81〜83%、Sys 2では最大89%を占めている。
つまり、同じarXiv番号の論文でも、版の更新によってタイトル、著者、提案する最適化手法、性能値の記述が変わっている。
v1では最適化手法を「CGAM」と「MAWS」と呼んでいたが、v3では「COMB」と「MAS」へ変更されている。
TrendForceが2026年9月29日の記事で引用した「最大90.6%」はv1に由来する数字だ。一方、現在のarXiv最新版であるv3を読む場合には、88%や89%という数字が登場する。
v3は、この数字がv1から変わった理由を明示していない。
そのため、「90.6%から88%へ性能が改善した」「再測定で90.6%が誤りだった」と推測することもできない。
同じ測定条件で単純に数値だけが修正されたとは限らないからだ。
「AIエージェントではCPU処理が最大90.6%を占める」という見出しだけを読むのではなく、
- どのワークロードを測った数字なのか
- どのCPUとGPUを使ったのか
- 論文のどの版を参照しているのか
を確認する必要がある。
自分のAIエージェントでCPUがボトルネックになっているかを知る方法も同じだ。
まず、LLM推論にかかる時間と、検索、コード実行、ファイル操作などのツール処理にかかる時間を別々に測る。
論文が示したのは、ツール処理の時間が無視できないワークロードでは、GPU推論だけを高速化していくとCPU側の処理が相対的に大きなボトルネックになり得る、ということだ。
「AIエージェントだからCPUが詰まる」のではなく、どこで時間を使っているかを測ったうえで、CPU、GPU、I/O、ネットワークのどこを改善すべきか判断する必要がある。
