AIエージェントはGPUだけ速くしても詰まる。Microsoft Azure実測が示したCPUの盲点

AIエージェントの処理が遅いとき、多くのチームはまずLLMかGPUを疑う。だが、エージェントがtoolを呼び、別のagentへ仕事を渡し、結果をcontextへ戻すたびに、実行の主役はCPUとGPUの間を往復する。

Microsoft Azureの本番workloadを調べた新しい論文「Architectural Implications of Agentic AI Workflows」は、ここを実測した。結論は単純だ。AIエージェント基盤は、GPU inference serverに少しtool実行を足したものではない。短いLLM呼び出し、orchestration、tool実行が交互に現れる、別種のdatacenter workloadである。

楽天最安値を一発検索！価格ナビで今すぐチェック！

この違いを見落とすと、平均利用率は低いのに遅い、CPUもGPUも余っているのに台数だけ増える、という少し悲しい富豪アーキテクチャが完成する。

古い問題は、平均利用率だけを見てしまうこと

従来のLLM servingでは、CPUはrequestを受け、GPUへinferenceを渡す前段として扱われやすい。ところがagentic workflowでは、CPU側に少なくとも3つの役割がある。

• scheduler：model inferenceをdispatchする
• orchestrator：agent間のmessage、state、依存関係を管理する
• runner：agent logicとtoolを実行する

論文が示す代表的な本番requestは、ほぼ1分の間に複数のLLM呼び出し、agent handoff、3回のtool discovery、3回のtool実行を含んでいた。tool結果をworkflow stateへ戻さないと次の推論へ進めないため、CPUは単なる前処理ではなくcritical pathへ入る。これはFigure 2の実行例で確認できる。

新しい点は、agent workflowを3軸で分解したこと

この研究は、agentic workloadを次の3軸で整理する。

1. orchestration：次に何を動かすかをhostとmodelのどちらが決めるか
2. execution structure：sequential、parallel、hierarchicalのどれか
3. model composition：同一modelを共有するか、役割ごとに異なるmodelを使うか

この分類は単なる用語集ではない。どのresourceが、いつ、どれだけ必要になるかを予測するための地図だ。sequential workflowでも、stage境界でbuildやtestをまとめて放出すればCPU負荷は急上昇する。異なるmodelを役割別に置けば、一部のGPUだけが詰まり、別のGPUは待つ。

実測すると、CPUとGPUは同時には忙しくない

研究は2種類の証拠を組み合わせた。1つはMicrosoft Azure上のproduction agentic serviceから得た24時間trace。もう1つはSWE-Agent、Trae、CORAL、Owlという4つのopen-source workflowを使ったcontrolled studyである。

controlled studyでは、host CPU利用率の中央値は6%から31%、GPU SM activityは55%未満だった。一方、TraeのCPU利用率は通常11%付近でも、stage境界ではほぼ100%まで跳ねた。CORALはtaskを変えるだけでresource特性が逆転し、research taskではCPU 99%、GPU 44%、algorithmic taskではCPU 31%、GPU 55%になった。数値は論文のworkload characterizationにある。

つまり、平均値だけを見ると余裕がある。しかしworkflowが次のstageへ進む瞬間には、一方のresourceが突然critical pathになる。CPUとGPUを固定比率で束ねたserverでは、この時間差を吸収しにくい。

さらにhost CPUでは、backend stallが43%から47%、IPCは1.2から1.6、L1 data MPKIは14から20だった。単純なcore不足だけでなく、多数のagentとtoolを同じcore群へ載せることでcacheやbranch predictorのlocalityも悪化している。

Agoraは余ったresourceを3つの方法で回収する

論文は観察だけで終わらず、commodity server向けprototypeのAgoraで3つの対策を試した。

1. idle CPUを別workloadへ貸し出す

runner coreが暇な時間はco-located workloadへ使わせ、tool burstが近づくとharvesterを退避させる。低負荷条件の平均では、co-located workload単独時のthroughputを95%回収し、host CPU利用率を30%高めながら、agent slowdownを3%未満に抑えた。ただし高負荷条件では平均回収率53.7%、slowdown 3.9%まで悪化している。よい数字だけをつまむと、agentも記事もburstする。

2. GPU memoryをoversubscribeする

同じmodelを使うagentを集約し、重複weightを減らしてKV cacheへ回す。OwlではGPUを3分の1減らしながらgeneration throughputを82%高め、1時間あたりの完了taskを22%増やし、tail latencyを2.5分の1にした。energy efficiencyも51%改善した。これはTable IIIの特定workflowと構成に対する結果で、すべてのagent systemへそのまま当てはまる数字ではない。

3. CPU coreを役割とtaskで分ける

scheduler、orchestrator、runnerを同じpoolへ押し込まず、役割別に分離する。さらにtool種別ではなくtask単位でcore affinityを持たせ、同じrepositoryやfileを扱う一連の作業のlocalityを守る。評価ではtoolのCPU需要を最大46%、worst-case latencyを13%下げ、serving throughputの99%を維持した。

AICompanyの解釈。最初に直すべきはGPU台数ではなく計測境界

ここからは論文の主張ではなく、AICompanyの実務的な解釈である。

agent基盤で最初に導入すべきなのは、Agoraの完全再実装ではない。LLM call、orchestrator、tool、handoffの境界ごとに時間とresourceを記録するinstrumentationだ。境界が見えなければ、GPU待ち、tool待ち、CPU contention、external API待ちがすべて「agentが遅い」に畳み込まれる。

小さく試すなら、同じtask setで次の4項目を比べればよい。

1. 各stageのstartとendを記録する
2. host CPU、GPU SM、GPU memoryを1秒粒度で取得する
3. medianだけでなくp95とburst peakを出す
4. shared CPU poolとrole-separated poolでthroughputとtail latencyを比較する

ここで重要なのは、平均CPU利用率が低いからcoreを減らす、という短絡をしないことだ。平均が低くても、agentが待っている瞬間だけ100%へ張り付くなら、そのburstがuser latencyを決める。

限界。Azure全体の答えではない

この研究には強いproduction evidenceがある一方、公開情報だけでは埋められない穴もある。

• production studyは24時間traceだが、request総数やservice別の母数は公開されていない
• Azure fleetのraw traceとAgoraの実装は、論文から公開artifactを確認できない
• controlled studyは4 frameworkで、model、tool、task、loadが変われば最適なpoolingも変わる
• CPU harvestingは高負荷時に効果が縮み、一部frameworkではslowdownが大きくなる
• GPU集約の82% improvementと2.5倍のtail latency改善はOwlの測定条件に依存する
• security isolation、noisy neighbor、tool sandboxの境界は性能最適化とは別に検証が必要である

したがって、この論文は「agent serverは必ずGPUを3分の1削減できる」と証明したものではない。「agent workflowではresource需要が時間的にも役割的にも分離する。だから固定比率のserver設計と平均値中心の監視は危ない」と示した研究である。

Verdict

この論文の価値は、AIエージェントの遅さをmodelの問題だけにしなかったことにある。LLM、tool、orchestratorを一つのrequest graphとして見れば、CPUとGPUが交互に待つ理由が説明できる。

実務で持ち帰るべき原則は3つだ。stage境界を計測する。resourceを役割別に見る。平均ではなくburstとtailを見る。

GPUを増やす前に、agentがどこで立ち止まっているかを測る。その一手だけで、次の投資先がGPUなのか、CPUなのか、toolなのか、ようやく話し合えるようになる。

一次資料

• Architectural Implications of Agentic AI Workflows（arXiv abstract）
• 論文HTML全文
• workload characterization
• Agoraのserver design case studies

【送料無料】マクロキーパッド、ストリームコントローラーデッキゲームストリーミングショートカットキーボード、18個のプログラム可能