AI エージェント時代における CPU の重要性再評価
本文の状態
日本語全文を表示中
詳細モードで約6分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
The New Stack AI
The New Stack は Google と Arm の担当者にインタビューし、AI エージェントの台頭により CPU が制御やオーケストレーションの要として重要性を増している現状と、その技術的根拠を解説した。
Continue in AI NEW LAB
このニュースを、実務の判断につなげる
AI NEW LABで、試したことや先に確認したい条件を共有できます。まずはログインなしで読めます。
AI NEW LABで論点を見るAI深層分析を開く2026年8月12日 05:56
AI深層分析
キーポイント
CPU の役割変化:航空管制官としての機能
Google の Mo Farhat は、AI エージェント時代において CPU が大規模モデル実行の補助ではなく、ブランチ処理や制御フローを担う「航空交通管制官」としての役割を果たすと指摘した。
小規模モデルによる CPU での推論可能性
60 億〜80 億パラメータの現行モデルは性能が向上しており、特定のワークロードでは CPU で秒間約 25 トークンの処理が可能となり、エージェント用として十分機能しうる。
コード実行と分離環境(サンドボックス)の必要性
エージェントが生成したコードを実行する際、生産システムへの影響を防ぐため、Google の gVisor によるゼロトラスト環境や隔離技術が不可欠であると Arm の Bhumik Patel は強調した。
CPU が担うオーケストレーションとデータ処理
CPU は大規模言語モデルの推論だけでなく、ツール呼び出し、データ準備、セマンティック検索、ベクトルデータベースの管理など、エージェントワークロード全体のオーケストレーションを担っている。
GKE Agent Sandboxのスケーラビリティと効率化
GKE Agent Sandboxはクラスターあたり毎秒300個のサンドボックスを起動可能であり、ポッドスナップショットや待機中の環境プールを活用して迅速なスケーリングを実現する。
重要な引用
The role, more or less, is of a CPU as an air traffic controller.
Today's six- to eight-billion-parameter models are performing much better than they have in the past.
We operate in a zero-trust environment. This is exactly why you need the isolation technologies that agents run in.
"We operate in a zero-trust environment. This is exactly why you need the isolation technologies that agents run in."
編集コメントを表示
編集コメント
AI エージェントの普及に伴い、インフラ設計における CPU の役割再評価が急務となっている。特にコード実行を伴う自律的なタスクでは、セキュリティと制御性を担保する CPU と隔離技術の組み合わせが鍵となる。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。

AI インフラについて議論がなされる際、その話題はほぼ例外なく GPU や TPU に焦点が当てられます。しかし、The New Stack は Arm の Bhumik Patel 氏と Google の Mo Farhat 氏に取材し、もはや見出しを飾ることが少なくなったチップ、すなわち CPU がなぜ AI がチャットボットからエージェントへと移行するにつれて重要性を増しているのかについて話を聞きました。
Google Compute Engine で Axion や Arm ベースの仮想マシンの製品管理を担当する Farhat 氏は、「CPU の役割は、いわば航空管制官のようなもの」と語っています。
今回の対談では、会話型のチャットボットから自律型エージェントへの移行が、静かに CPU を巡る物語へと変化している様子について議論します。
「現在の 60 億〜80 億パラメータのモデルは、過去に比べてはるかに優れたパフォーマンスを発揮しています」と Farhat 氏は述べています。特定の専門的なワークロードにおいては、CPU で約 1 トークン/秒を達成できる場合があり、これはエージェント向けワークロードにとって十分な速度です。
ワークロードが「応答」から「行動」へシフトした
初期のチャットボットは単に回答を返すだけでしたが、エージェントはその回答に基づいて実際に行動を起こします。ツールを呼び出してタスクを実行し、必要に応じてコードを実行するための環境を自ら構築するのです。
「エージェント向けワークロードにおけるオーケストレーション基盤自体が、常に稼働し分岐する制御フローの論理であり、これは CPU が最も得意とする領域です」と Farhat 氏は説明します。
大規模言語モデルは通常、アクセラレータ上で動作しますが、CPU もオーケストレーション、データ準備、セマンティック検索、ベクトルデータベースの処理を担っています。ファハット氏はそう指摘しています。
クラウドと AI におけるソフトウェアエコシステムの構築を主導するパテル氏によれば、同社はこうしたワークロードを大規模に実行するために必要なソフトウェアおよびインフラ層に注力しています。彼は異なる種類のエージェントが「コードの実行や API の呼び出しなど、典型的な CPU ワークロード」を実行していると述べています。
モデルを実際に動かす役割ももちろん存在しますが、ここでは要約器、レコメンダー、評価器といった非常に小さなモデルを指しています。
「現在の 60 億〜80 億パラメータのモデルは、過去よりもはるかに高性能になっています」とファハット氏は話します。特定の専門的なワークロードにおいては、CPU で秒間約 25 トークンを生成できるため、エージェント向けのワークロードでも十分対応可能だと指摘しています。
エージェントがなぜサンドボックスを必要とするか
しかし、これらのエージェントがコードを実行するためには、本番システムに危険をもたらすことなく安全に実行できる環境が必要です。
「エージェントはコードを実行するものですから、LLM が生成したコードが信頼できることを確認する必要があります」とパテル氏は述べています。「もし信頼できない場合は、その環境をサンドボックス化します」
Google が提案する解決策は、アプリケーションとホスト OS の間に隔離層として機能するオープンソースプロジェクト「gVisor」です。Farhat 氏はこう述べています。「私たちはゼロトラスト環境で運営しています。まさにその理由から、エージェントが動作するための隔離技術が必要なのです。」
GKE Agent Sandbox は、このエージェンシー時代に必要なスケールにも対応できると Google は主張します。
「GKE Agent Sandbox を使えば、クラスターあたり 1 秒間に最大 300 のサンドボックスを起動できます」と Farhat 氏は語ります。Patel 氏によると、プラットフォームはポッドのスナップショットと、一時停止された環境のウォームプールを活用して、すべての環境を完全にプロビジョニングし続けることなく、より迅速にスケールできるように支援しています。
効率性の訴求点
Google は Axion がコスト面とエネルギー消費面の両方で優位性を持つと説明しています。
「現在の Axion は、同等の最新世代の仮想マシンと比較して最大 2 倍のパフォーマンス対価格比を提供します。さらに、エネルギー効率は 60% 以上向上します」と Farhat 氏は話しています。
Google は、一貫した高性能が必要な場合に Axion C4A マシンを、パフォーマンスとコスト最適化のバランスが求められるワークロードには N4A マシンを提供しています。完了時間が重要な計算集約型の長時間実行されるエンジニアリングジョブについては、C4A が必要な性能を提供すると Farhat 氏は指摘します。一方、密度やコストがより重要となる小規模なコード実行タスクでは、N4A を推奨しています。
「Google Cloud の選択肢には、先ほどモ氏が触れたように、高性能なワークロード向けに C4A を用意しており、その次に N4A があります」とパテル氏は語ります。「多数のエージェントをスケーリングしたい場合、さまざまなタイプのエージェントが異なる種類のコード実行や API 呼び出し、そして典型的な CPU ワークロードを処理します。そんな場合に N4A は非常に適しています」。
ファハト氏のより広い視点としては、エージェントのスケーリングが進んでも、CPU、GPU、TPU のリソースは引き続き連携して機能し続けるという点です。
「私たちは今、流動的なコンピューティングの世界にいます」と同氏は述べています。「お客様には CPU ベース、TPU、GPU ベースなど、すべての選択肢を検討いただき、将来のスケーリングを見据えたアプリケーションを構築することをお勧めします」。
原文を表示

When the conversation turns to AI infrastructure, it almost always lands on GPUs and TPUs. The New Stack sat down with Bhumik Patel of Arm and Mo Farhat of Google to talk about the chip that rarely makes the headlines anymore: the CPU, and why it’s getting more important, not less, as AI shifts from chatbots to agents.
Farhat, who leads product management for Axion and Arm-based virtual machines at Google Compute Engine, tells The New Stack, “The role, more or less, is of a CPU as an air traffic controller.”
In this episode, we discuss how the shift from conversational chatbots to autonomous agents is quietly turning into a CPU story.
“Today’s six- to eight-billion-parameter models are performing much better than they have in the past,” Farhat says. For some specialized workloads, he says, CPUs can deliver roughly 25 tokens per second, which can be enough for agentic workloads.
The workload shifted from answering to acting
Early chatbots returned a response, but agents can act on them. They perform tasks by calling tools and, when needed, create environments to execute the code they write.
“The orchestration harnesses themselves for agentic workloads are these always-on branching kind of control-flow logic that CPUs are great at,” Farhat says.
While large language models typically run on accelerators, CPUs also handle orchestration, data preparation, semantic search, and vector databases, Farhat says.
Patel, who drives Arm’s software ecosystem efforts for cloud and AI, says the company is focused on the software and infrastructure layers needed to run these workloads at scale. Different types of agents, he notes, are doing “different type[s] of code execution and API calling and the typical CPU work.”
There’s a role for actually running models here, too, but we’re talking about very small ones, including summarizers, recommenders, and evaluators.
“Today’s six- to eight-billion-parameter models are performing much better than they have in the past,” Farhat says. For some specialized workloads, he says, CPUs can deliver roughly 25 tokens per second, which can be enough for agentic workloads.
Why agents need sandboxes, and lots of them
For those agents to run code, though, they need an environment that lets them do so securely without endangering production systems.
“The agents are doing code execution, so you want to make sure that the LLM-generated code is trusted,” Patel says. “Or if it’s not trusted, then you kind of sandbox the environment.”
Google’s pitch for this is gVisor, an open-source project that acts as an isolation layer between the application and the host operating system. As Farhat puts it, “We operate in a zero-trust environment. This is exactly why you need the isolation technologies that agents run in.”
As Farhat puts it: “We operate in a zero-trust environment. This is exactly why you need the isolation technologies that agents run in.”
GKE Agent Sandbox, Google argues, can also handle the scale necessary in this agentic era.
“GKE Agent Sandbox will allow customers to spin up 300 sandboxes per second per cluster,” Farhat says. Patel says the platform uses pod snapshots and warm pools of suspended environments to help customers scale more quickly without keeping all of those environments fully provisioned.
The efficiency pitch
Google says Axion can offer advantages in both cost and energy use.
“Axion today will give you up to 2x the price performance of comparable current-generation virtual machines,” Farhat says, “and we’ll do that at over 60% better energy efficiency as well.”
Google offers Axion C4A machines for consistently high performance and N4A machines for a balance of performance and cost-optimized workloads. For a compute-bound, long-running engineering job where completion time is critical, Farhat says C4A offers the needed performance. For smaller code-execution tasks where density and cost matter more, he points to N4A.
“The good thing about the options in Google Cloud is, like Mo offered earlier, you have the C4A for high-performance workloads, and then the N4A,” Patel says. “You want to scale a large number of agents, and different types of agents are doing different types of code executions and API calling and the typical CPU work. The N4A is a great fit.”
Farhat’s broader point is also that CPU, GPU, and TPU resources will continue to work together as agents scale.
“We’re in a fluid compute world,” he says. “We do recommend that customers look at all the options, CPU-based, TPU, GPU-based, and ensure that their application is built to scale going forward.”
The post Why CPUs still matter in the age of AI agents appeared first on The New Stack.
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み