浪潮、エージェント向けインフラを構築：ラックあたり4万エージェントとマルチモデル連携

はじめに

AIインフラは、一度に1つのモデルリクエストを処理する時代を超えようとしている。

プロダクションレベルのエージェントは、単にプロンプトを受け取り回答を返すだけではない。タスクを複数の段階に分解し、外部ツールを呼び出し、コンテキストを維持し、サブエージェントと連携し、中間出力を検証し、長時間アクティブな状態を保つことがある。企業がこのようなエージェントを数千単位で一度に展開する場合、インフラ要件は通常のチャットボットの推論とは大きく異なる。

北京で開催された2026オープンコンピューテクノロジーサミットにおいて、浪潮信息はこの新しいワークロードに向けて2つのインフラの方向性を提案した。

1. CPUネイティブ液冷ラックサーバー：1ラック内で4万以上の同時エージェントをサポートするよう設計。
2. MetaBrain SD200スーパーノードとEPAIマルチモデル融合APIの組み合わせ：複数の大規模モデルが連携して複雑なタスクの回答を生成、検証、統合することを可能にする。

1つ目の方向性は規模に重点を置き、多数の長時間稼働エージェントをオンラインに保つ。2つ目の方向性は品質に重点を置き、異なる強みを持つ複数のモデルが協調して動作し、1つのモデルに困難なタスクのすべての部分を強制的に処理させるのを避ける。

エージェントワークロードがもたらす異なるインフラの課題

従来の大規模モデルの推論は、通常シンプルなパターンに従う。

1. ユーザーがリクエストを送信する。
2. モデルが推論を実行する。
3. システムが応答を返す。
4. セッションが終了するか、次のリクエストを待つ。

一方、エージェントアプリケーションの実行パスははるかに長い。

単一のビジネスタスクには以下が含まれる可能性がある。

• 計画
• タスク分解
• 検索
• ツール呼び出し
• コード実行
• 権限チェック
• サンドボックスプロセス
• マルチターン推論
• サブエージェント調整
• 出力検証
• 結果集約
• 長時間実行の状態管理

したがって、インフラはモデル推論だけでなく、多数の永続的に実行されるソフトウェアプロセスもサポートする必要がある。

エンタープライズ環境では、アクティブなエージェントの数は数十から数千、さらには数万にまで上昇する可能性がある。一部のエージェントは継続的に実行されるが、他のエージェントは短いタスクのために動的に作成され、完了後に破棄される。

これにより、CPUとGPUリソースのバランスが変化する。

GPUによるトークン生成

GPUは以下の場面で依然として不可欠である。

• 大規模モデルの推論
• プリフィルとデコード
• 埋め込み生成
• マルチモーダル処理
• 高スループットのトークン生成
• モデル並列実行

CPUによるエージェント環境の実行

CPUは膨大な周辺作業を処理する。

• エージェントプロセススケジューリング
• ツール呼び出し
• コンテキストと状態管理
• ビジネスシステムとの連携
• サンドボックス実行
• ネットワークとストレージ操作
• 認証と権限
• ワークフロー調整
• 結果準備

モデルは推論やテキスト生成を担当するかもしれないが、CPUは通常、エージェントが実行されるオペレーティング環境を実行する。

したがって、エージェントインフラはGPU中心の設計から、CPU、GPU、ネットワーク、ストレージ、冷却、オーケストレーションソフトウェアが連携するシステムへと移行しつつある。

CPU密度がますます重要になる理由

一般的なエンタープライズサーバーでは、CPU密度は従来、消費電力、冷却、スペース、ケーブル、ファン、およびメンテナンス要件によって制限されてきた。

エージェントの展開は経済モデルを変える。

数千のエージェントがオーケストレーション、ツール呼び出し、および分離されたランタイム環境のためにCPUリソースを必要とする場合、CPU密度の低いラックはより多くの床面積、ネットワーク接続、および付随するインフラを占有することになる。

同時に、AIデータセンターはより高いラック電力へと進化している。

情報源によると、浪潮信息は国内のAIラック電力が300キロワット近くになると予想しており、一部のグローバルな設計はすでにメガワット級のラックシステムへと向かっている。従来の空冷は通常、1ラックあたり数十キロワットに制限されており、この密度ではますます難しくなる。

したがって、液冷はもはやGPUだけの問題ではない。

エージェントワークロードを支えるCPUラックも、次世代AIデータセンターの電力と冷却アーキテクチャに適合しなければならない。

1ラックで4万以上のエージェントをサポート可能

浪潮は、業界初と称するCPUネイティブ液冷ラックサーバーを発表した。

このシステムは液冷OCM 2.0アーキテクチャに基づいており、x86とArmプロセッサをサポートする。

主な仕様は以下の通り。

特性	企業報告パラメータ
1ラックあたりの最大CPU数	384
サポートする同時エージェント数	40,000以上
プロセッサアーキテクチャ	x86およびArm
冷却範囲	CPU、メモリ、SSD、ネットワークカード、光モジュール、その他の発熱コンポーネント
計算密度	0.5Uスペースに4つのCPUを統合
保守方法	液冷全ライフサイクル保守
対象シナリオ	高密度およびギガワット級AIデータセンター

このシステムは、液冷をサーバー設計完了後のアドオンコンポーネントとは見なしていない。

むしろ、計算レイアウトと冷却アーキテクチャは協調して開発されている。

CPUコールドプレートから全コンポーネント冷却へ

従来のコールドプレートサーバー

プロセッサを直接冷却できるが、メモリ、ネットワーク、ストレージ、電源コンポーネント、およびその他のデバイスは依然としてファン冷却に依存している。

密度が高まるにつれて、このアプローチの効果は薄れていく。

浪潮のネイティブ液冷アーキテクチャは、主要な発熱コンポーネントを統合冷却システムに組み込む。

• CPU
• メモリ
• ネットワークカード
• 光モジュール
• ソリッドステートドライブ
• 通信コンポーネント

これにより、内部の気流への依存が減り、コンポーネントのよりコンパクトなレイアウトが可能になる。

以下に「液冷アーキテクチャ」「液冷接続」「液冷運用保守」の3つの青色アイコンがあります。この画像は文脈と密接に関連しており、Inspurの液冷アーキテクチャサーバーの展示状況を直感的に示しており、ドキュメントで紹介されている液冷アーキテクチャ設計と対応しています。](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/44c90e20-2048-4f43-8d1d-8516006843e0-d14e80b4-e2a0-4468-a7b6-77e5229ab1ca.png)

コンパクト演算ユニット

本レポートは、複数のプロセッサと周辺コンポーネントを薄型軽量の筐体に統合したコンパクト演算ユニットについて説明しています。

設計目標は、従来以下のコンポーネントが占めていたスペースを回収することです：

• 大型ファン
• エアダクト
• 冷却配管
• 内部ケーブル
• 従来のサーバートレイ

フラットなコンポーネント配置により、1枚の大面積コールドプレートでより広いシステム領域をカバーできます。

ラックはケーブル削減またはケーブルレス設計を採用し、無停止メンテナンスをサポートします。Inspurは、これによりラック全体の導入と保守の効率が向上すると述べています。

OCMの重要性

OCMはOpen Compute Moduleの略です。

モジュラーアーキテクチャは、プロセッサモジュールをシステム全体の設計から切り離すことを目的としています。この設計により、プロセッサの世代やアーキテクチャが異なっていても、ラック全体を再設計することなく対応が容易になります。

企業やデータセンター運営者にとって、このソリューションは以下の利点をもたらします：

• より多くのハードウェア選択肢
• プラットフォームのアップグレードが容易
• 重複設計作業の削減
• x86アーキテクチャとArmアーキテクチャとの互換性向上
• ラックインフラのライフサイクル延長

実際の効果は、エコシステムの互換性、相互運用性、および関連コンポーネントの可用性に依存します。

規模は知性と等しくない

数万のエージェントを実行することで容量問題は解決できても、回答の質が自動的に向上するわけではありません。

大規模言語モデルにはそれぞれ専門性があります。

特定のモデルは以下の分野に優れている可能性があります：

• 論理的推論
• コーディング
• 長文分析
• 技術調査
• 自然な文章作成
• 構造化抽出
• 多言語タスク

超大規模モデルでも能力に限界があります。

複雑なタスクを処理する際、単一のモデルでは重要な問題を見落とす可能性があり、他のモデルがそれを発見できることがあります。また、単一のモデルは不確実性を明らかにせず、代替解釈を考慮せずに自信を持って回答する可能性があります。

そのため、Inspurの2つ目のインフラストラクチャの方向性は、マルチモデル連携に焦点を当てています。

同一タスクに対するマルチモデル協調処理

EPAIマルチモデル統合APIは、複雑なタスクを並行して複数の候補モデルに分配します。

各モデルは独立して回答を生成します。さらに、審査・統合モデルが候補回答を比較し、以下を特定します：

• 共通の結論
• 矛盾する判断
• 見落とされた情報
• 独自の洞察

サポートされていない宣言：

• 調整が必要な領域

その後、プラットフォームは統合された回答を生成します。

これは単純な多数決でも、すべての回答をそのまま連結することでもありません。予想されるワークフローは以下の通りです：

1. 候補生成
2. モデル横断的レビュー
3. 差異と欠落の分析
4. 最終出力への統合

Inspurの報告によると、このシステムは DRACO評価で53.9% を達成し、テストに使用された候補プール内の各単一モデルよりも優れていました。

この結果は、プラットフォームの報告ベンチマークとして捉えるべきであり、モデル統合が常に最良の単一モデルを上回ることを示すものではありません。パフォーマンスは、候補モデル、評価モデル、ルーティングロジック、タスクタイプ、プロンプト、および評価方法に依存します。

単純なタスクには単一モデルを使用

すべてのリクエストで複数のモデルを実行すると、コストとレイテンシが不必要に増加します。

そのため、EPAIは短く予測可能なタスクと複雑なタスクを区別します。

単一モデルに適したタスク

軽量モデルで十分な場合：

• 簡単なQ&A
• フォーマット変換
• 基本的な抽出
• 分類タスク
• 短いツール呼び出し
• 一般的なコンテンツ変換

マルチモデル統合に適したタスク

複数モデルが有効な場合：

• 深層調査
• 技術比較
• アーキテクチャ分析
• 複雑な計画
• 長文推論
• ハイステークスレビュー
• 証拠が曖昧なタスク
• 独立した検証が必要な出力

このルーティング原則は、本番システムにとって重要です。

品質の向上が追加のトークンコスト、GPU時間、応答レイテンシを相殺できる場合に、マルチモデル連携が最も価値を発揮します。

EPAIマルチモデル統合ワークフロー

EPAI APIは、マルチモデルオーケストレーションを統合インターフェースの背後に隠すことを目的としています。

開発者はプラットフォームにリクエストを送信します。EPAIが以下を管理します：

• 候補モデル選択
• 並行タスク分散
• 応答収集
• 評価モデル実行
• 差異分析
• 最終回答生成

同じインターフェースをエージェントアプリケーションや開発フレームワークに統合でき、各チームがカスタムモデルルーティングや評価システムを構築する必要はありません。

このアーキテクチャは、以下のモデルを混在して使用する企業に適しています：

• オープンソースモデル
• プロプライエタリモデル
• 汎用モデル
• ドメイン特化モデル
• ローカルデプロイモデル
• クラウドAPIモデル

主な運用上の課題は、複数の大規模モデルを同時に利用可能に保つ必要があることです。これにより、アクセラレータメモリ、相互接続帯域幅、スケジューリング、および低レイテンシ通信に対する要求が高まります。

MetaBrain SD200がトークンエンジンを提供

MetaBrain SD200スーパーノードは、マルチモデル統合ワークフローを支えるハードウェアプラットフォームです。

このシステムは、マルチホスト、低レイテンシのメモリセマンティック通信アーキテクチャを採用しています。Inspurによると、単一システム内で64個の国産GPUアクセラレータを統一相互接続できます。

その設計には以下が含まれます：

• OCMおよびOAMオープンコンピュートアーキテクチャ
• 3Dメッシュ相互接続
• 統一アクセラレータアドレッシング
• 高速ピアツーピア通信
• 大容量共有メモリ

能力

• 複数の兆パラメータモデルをサポート
• ソフトウェアとハードウェアの連携最適化

このスーパーノードは、最大4兆パラメータの単一モデル、またはエージェントアプリケーションが同時に使用する複数の兆パラメータモデルをサポートできるとされています。

テストにおけるトークン生成時間4.77ミリ秒

Inspurは、SD200により兆パラメータモデルKimi K2.6の単一トークン生成時間を4.77ミリ秒に短縮したと報告しています。

また、以前の実装と比較してファーストトークン生成時間が35%削減されたとも報告されています。

これらの数値は、特定の最適化およびテスト環境での結果であり、すべてのモデル、デプロイメント、プロンプト長、同時実行レベル、または本番ワークロードにおけるレイテンシを保証するものではありません。

これらの改善は、複数の技術に起因します。

マルチトークン予測

自己回帰モデルは通常、最初に1つのトークンを生成し、新しい状態を検証してから次のトークンを生成します。

マルチトークン予測は、1ステップで複数の候補トークンを生成し、それらをまとめて検証することを試みます。

予測精度が高い場合、逐次デコードのラウンド数を削減できます。

W4A8量子化

最適化では、混合エキスパートモデル負荷の一部にINT4重みとINT8アクティベーション計算を使用しています。

BF16計算と比較して、以下を削減できます：

• メモリ帯域幅の負荷
• アクセラレータメモリ使用量
• 計算要件
• トークンあたりの推論コスト

量子化はモデル品質に影響を与える可能性があるため、本番チームは速度結果のみに依存せず、自社の負荷に基づいて精度を評価する必要があります。

実行時カーネルコンパイル

JITコンパイルは、実行時にテンソル形状、レイアウト、データ型に基づいて専用のアクセラレータカーネルを生成します。

汎用の静的実装と比較して、専用カーネルは不要な分岐を減らし、メモリアクセスを改善します。

プリフィル-デコード分離

プロンプトプリフィルとトークンデコードは、異なるパフォーマンス特性を持っています。

2つのフェーズを分離することで、リソースを差別化して割り当て、KVキャッシュを非同期に転送し、計算と通信の競合を減らせます。

モデル互換性

Inspurは、SD200が以下の主要なオープンソースモデルのパフォーマンス最適化を完了したと述べています：

• Kimi K2.6
• DeepSeek V4
• GLM 5.2
• MiniMax M3

互換性は、必ずしも各モデルが同じレイテンシやスループットを達成することを意味するわけではありません。

モデルアーキテクチャ、パラメータ数、MoE設計、コンテキスト長、量子化、バッチ処理、サービングソフトウェアは、すべてパフォーマンスに影響を与えます。

エンタープライズ版で導入障壁を低減

64アクセラレータのスーパーノードは大規模AIインフラプロジェクトに適していますが、多くの企業にとっては規模が大きすぎ、コストも高すぎます。

浪潮情報は元脳SD200エンタープライズ版も発表しました。

エンタープライズ版は、スケールアップするコンピューティングドメインを64アクセラレータから16に縮小し、オンプレミスでの兆パラメータモデルの展開を目的としています。

その謳われている特長は以下の通りです：

• 16アクセラレータの統一再相互接続ドメイン
• ネイティブメモリセマンティクス通信
• 統一アドレッシング
• テラバイト級の統一再アクセラレータメモリ
• 兆パラメータ推論におけるファーストトークン生成時間が40%以上向上
• 主要なオープンソース兆パラメータモデルをネイティブサポート
• 完全なSD200システムと比較して移行・適応コストが低い

このエンタープライズ版は、主に以下のワークロードを対象としています：

• 長文書の理解
• 複雑な論理推論
• プライベートモデルの展開
• マルチエージェント連携
• 社内研究
• 機密性の高いビジネスアプリケーション

これは、オンプレミスでのモデル制御が必要だが、64アクセラレータのスーパーノードを正当化できない組織向けに、より小規模なエントリポイントを提供します。

インフラストラクチャスタックの統合化が進む

OCTS 2026で発表された製品は、3層アーキテクチャを示しています。

層	主な役割
ソフトウェアプラットフォーム	モデルアクセス、タスクルーティング、オーケストレーション、権限、評価、結果の統合
CPUインフラストラクチャ	エージェントプロセス、ツール呼び出し、サンドボックス実行、コンテキスト管理、ビジネスシステムとの連携
GPUスーパーノード	大規模モデル推論、高スループットトークン生成、マルチモデル実行

3層すべてが連携して機能する場合にのみ、システムは正常に動作します。

高速なGPUクラスターがあっても、貧弱なエージェントスケジューリングを補うことはできません。高密度のCPUラックがあっても、強力なモデルにアクセスできなければ推論品質を向上させることはできません。基礎となるモデルが効率的にロードまたは接続できなければ、洗練された統合APIも有用なレイテンシを提供できません。

これがエージェントインフラストラクチャにおける競争の主要な変化です。

初期の市場は、単一のサーバーがどれだけ大規模なモデルをサポートできるかに主眼が置かれていました。エージェント時代は、システムレベルのパフォーマンスに注意が向けられるようになりました：

• どれだけのエージェントプロセスをオンラインに維持できるか？
• それらはどれだけ速くモデルやツールを呼び出せるか？
• 複数のモデルを同時に実行できるか？
• メモリはどのように共有または分離されているか？
• 権限はどのように実行されるか？
• プラットフォームは単純なタスクと複雑なタスクで異なるルーティングを実行できるか？
• システムは高負荷の並行処理下でも安定を維持できるか？
• それは有用なトークンをどれだけ効率的に生成するか？

企業が導入前に評価すべきこと

ベンダーが提供する華やかな数値は有用ですが、エージェントインフラストラクチャプラットフォームを選択するには十分ではありません。

本番環境での評価では、完全なワークロードを測定する必要があります。

1. エージェント並行性

アクティブユーザーだけでなく、以下もカウントします：

• タスクごとのサブエージェント
• ツールプロセス
• サンドボックス
• バックグラウンドジョブ
• 永続的セッション
• ピーク時のバースト
• 障害復旧プロセス

2. エージェントあたりのCPUとメモリ

軽量な

検索エージェントと、独立した開発環境を備えたコーディングエージェントでは、リソース要件の特性が大きく異なります。

「ラックあたりのエージェント数」という指標は、対象アプリケーションの実際のメモリ、CPU、ストレージ、ネットワーク要件にマッピングされなければなりません。

3. モデルレイテンシ

以下を測定する必要があります：

• ファーストトークン生成時間
• トークン間レイテンシ
• エンドツーエンドのタスク完了時間
• キューレイテンシ
• ツール呼び出しレイテンシ
• 並行処理シナリオでのレイテンシ

ベンチマークでの低いトークン生成時間は、エンドツーエンドのワークフローにおける低レイテンシを保証するものではありません。

4. マルチモデル経済性

マルチモデル統合は品質を向上させる可能性がありますが、推論コストが倍増する可能性があります。

チームは以下を比較する必要があります：

• 単一モデルの精度
• 統合モデルの精度
• 消費されたトークン数
• GPU 使用率
• 応答時間
• レビューモデルコスト
• 失敗率
• 手動レビューの削減量

5. 冷却と施設の互換性

ネイティブ液冷ラックには、対応する施設インフラストラクチャが必要です。

以下を確認する必要があります：

• 冷却液分配ユニット
• 供給・戻り水温
• 圧力と流量の要件
• 漏洩検知
• メンテナンス手順
• 廃熱回収計画
• ラック給電能力
• データセンターの床耐荷重

6. モデルとアクセラレータの移植性

オープンモジュール標準は柔軟性を高める可能性がありますが、実際の移植性はソフトウェアの互換性に依存します。

以下を検証する必要があります：

• モデルフレームワーク
• 推論エンジン
• 量子化サポート
• カーネル利用可能性
• ドライバの成熟度
• 監視ツール
• アクセラレータ交換
• アップグレード手順

7. 信頼性とガバナンス

長期実行エージェントには、以下に対する強力な管理が必要です：

• 本人確認
• 権限設定
• 鍵管理
• ネットワークアクセス
• サンドボックス環境
• 監査ログ
• レート制限
• 承認フロー
• モデルルーティング
• データ保存

インフラストラクチャの密度は、運用上の分離を犠牲にするものであってはなりません。

よくある質問と回答

浪潮のCPUネイティブ液冷エージェントラックとは何ですか？

これは、従来の空冷設計に液冷を追加するのではなく、冷却システムを中心に設計されたラック全体のCPUサーバーです。浪潮は、最大384のCPUを搭載し、40,000以上の並行エージェントをサポートできると述べています。

1つのラックで本当に40,000のAIエージェントを実行できますか？

その数値は、浪潮のリファレンスアーキテクチャベンダーレポートの最大値です。実際の容量は、エージェントごとに必要なCPU、メモリ、ストレージ、ネットワーク、サンドボックス分離リソースに依存します。

AIエージェントにはなぜこれほど多くのCPUが必要なのですか？

言語モデルはGPU上で実行されるかもしれませんが、エージェントはスケジューリング、ツール実行、状態管理、ビジネスシステムアクセス、セキュリティチェック、隔離されたランタイム環境のためにCPUも必要とします。長時間実行とマルチエージェントワークフローは、このCPU需要をさらに増加させます。

OCM 2.0とは何ですか？

OCMは、コンピューティングモジュールをより広範なラック設計から分離するためのオープンコンピュートモジュールアーキテクチャです。浪潮の液冷OCM 2.0システムは、複数のCPUアーキテクチャと全コンポーネント液冷をサポートします。

MetaBrain SD200とは何ですか？

MetaBrain SD200は、大規模モデル推論とマルチモデルワークロード向けに設計された浪潮のAIスーパーノードです。64アクセラレータのスケールアウトアーキテクチャを採用し、統一アドレッシングと高速相互接続をサポートします。

EPAIマルチモデル統合APIとは何ですか？

これは、1つのタスクを複数の候補モデルに送信し、それらの独立した回答を収集し、

レビューと統合モデルを使用して、最終応答を生成する前に合意、相違点、見落とし、独自の見解を特定するAPIです。

マルチモデル統合は常に単一モデルよりも優れていますか？

いいえ。マルチモデルは複雑なタスクのパフォーマンスを向上させる可能性がありますが、トークン消費、計算コスト、レイテンシが増加します。単純なタスクは、単一の軽量モデルにルーティングする方が適しています。

SD200とSD200エンタープライズ版の違いは何ですか？

フル版のSD200は超大規模ワークロードを処理するために64アクセラレータのスケールアウトドメインを採用していますが、SD200エンタープライズ版はドメインを16アクセラレータに縮小し、より低いインフラ障壁でオンプレミスの兆パラメータモデルを展開する必要がある企業を対象としています。

関連ツール

• 浪潮EPAエンタープライズAIプラットフォーム：モデル管理、アプリケーション開発、検索、展開、マルチモデルワークフローをサポートします。
• 浪潮液冷ソリューション：液冷CPU/GPUサーバーを展開するためのインフラストラクチャソリューション。
• オープンコンピュートプロジェクト：サーバー、ラック、電源、冷却、データセンター向けのオープンハードウェア設計を開発する業界コミュニティ。
• Kimi：月之暗面のアシスタント兼モデルプラットフォームであり、その最適化結果は浪潮SD200に引用されています。

DeepSeek：AIモデルプロバイダー。そのオープンソースモデルはSD200互換リストに含まれています。

関連リンク

• 浪潮智能体基盤発表：液冷CPUラック、SD200、エンタープライズ向けスーパーノードの公式発表を掲載。
• MetaBrain SD200 4.77ms性能発表：SD200の最適化とトークン生成結果に関する浪潮の技術概要。
• EPAマルチモデル融合API：候補生成、レビュー、融合メカニズム、DRACOスコアに関する公式説明。
• 浪潮EPA製品ページ：エンタープライズ向け大規模モデル開発プラットフォームの製品情報。
• 浪潮液冷データセンターソリューション：液冷データセンター導入ソリューションの公式情報。
• 2026 オープンコンピューティング・テクノロジー・サミット：OCTS 2026イベントページおよび関連オープンソースコンピューティング発表。
• オープンコンピュートプロジェクト財団：オープンインフラストラクチャ標準とコミュニティプロジェクトの公式情報。

まとめ

浪潮がOCTS 2026で発表した内容は、エンタープライズ・エージェントが引き起こす2つの主要課題に対処するものです。

CPUネイティブ液冷ラックは拡張性に重点を置き、エージェントのスケジューリング、ツール、サンドボックス、コンテキスト管理、長時間実行プロセスに高密度な環境を提供します。SD200とEPAマルチモデル融合ワークフローはインテリジェンスに焦点を当て、複数の大規模モデルが連携して複雑なタスクを処理し、レビューモデルが出力結果を統合します。

より広範な示唆として、エージェントインフラは単一の高速アクセラレータに還元できません。本番システムでは、CPU、GPU、メモリ、インターコネクト、冷却、オーケストレーション、権限管理、評価を調整する必要があります。

エージェントインフラの主要な評価基準は、単一モデルの実行効率から、システム全体が数千のエージェントを効率的にスケジューリングし、信頼性の高い結果を継続的に生成できるかどうかに移行しています。