AIインフラは、単一のモデルリクエストに一度に応えるだけの時代を超えつつある。プロダクションレベルのエージェントは、単にプロンプトを受け取り回答を返すだけでなく、タスクを複数の段階に分解し、外部ツールを呼び出し、コンテキストを維持し、サブエージェントと連携し、中間出力を検証し、長...
AIインフラは、一度に1つのモデルリクエストを処理する時代を超えようとしている。
プロダクションレベルのエージェントは、単にプロンプトを受け取り回答を返すだけではない。タスクを複数の段階に分解し、外部ツールを呼び出し、コンテキストを維持し、サブエージェントと連携し、中間出力を検証し、長時間アクティブな状態を保つことがある。企業がこのようなエージェントを数千単位で一度に展開する場合、インフラ要件は通常のチャットボットの推論とは大きく異なる。
北京で開催された2026オープンコンピューテクノロジーサミットにおいて、浪潮信息はこの新しいワークロードに向けて2つのインフラの方向性を提案した。
1つ目の方向性は規模に重点を置き、多数の長時間稼働エージェントをオンラインに保つ。2つ目の方向性は品質に重点を置き、異なる強みを持つ複数のモデルが協調して動作し、1つのモデルに困難なタスクのすべての部分を強制的に処理させるのを避ける。
従来の大規模モデルの推論は、通常シンプルなパターンに従う。
一方、エージェントアプリケーションの実行パスははるかに長い。
単一のビジネスタスクには以下が含まれる可能性がある。
したがって、インフラはモデル推論だけでなく、多数の永続的に実行されるソフトウェアプロセスもサポートする必要がある。
エンタープライズ環境では、アクティブなエージェントの数は数十から数千、さらには数万にまで上昇する可能性がある。一部のエージェントは継続的に実行されるが、他のエージェントは短いタスクのために動的に作成され、完了後に破棄される。
これにより、CPUとGPUリソースのバランスが変化する。
GPUは以下の場面で依然として不可欠である。
CPUは膨大な周辺作業を処理する。
モデルは推論やテキスト生成を担当するかもしれないが、CPUは通常、エージェントが実行されるオペレーティング環境を実行する。
したがって、エージェントインフラはGPU中心の設計から、CPU、GPU、ネットワーク、ストレージ、冷却、オーケストレーションソフトウェアが連携するシステムへと移行しつつある。
一般的なエンタープライズサーバーでは、CPU密度は従来、消費電力、冷却、スペース、ケーブル、ファン、およびメンテナンス要件によって制限されてきた。
エージェントの展開は経済モデルを変える。
数千のエージェントがオーケストレーション、ツール呼び出し、および分離されたランタイム環境のためにCPUリソースを必要とする場合、CPU密度の低いラックはより多くの床面積、ネットワーク接続、および付随するインフラを占有することになる。
同時に、AIデータセンターはより高いラック電力へと進化している。
情報源によると、浪潮信息は国内のAIラック電力が300キロワット近くになると予想しており、一部のグローバルな設計はすでにメガワット級のラックシステムへと向かっている。従来の空冷は通常、1ラックあたり数十キロワットに制限されており、この密度ではますます難しくなる。
したがって、液冷はもはやGPUだけの問題ではない。
エージェントワークロードを支えるCPUラックも、次世代AIデータセンターの電力と冷却アーキテクチャに適合しなければならない。
浪潮は、業界初と称するCPUネイティブ液冷ラックサーバーを発表した。
このシステムは液冷OCM 2.0アーキテクチャに基づいており、x86とArmプロセッサをサポートする。
主な仕様は以下の通り。
| 特性 | 企業報告パラメータ |
|---|---|
| 1ラックあたりの最大CPU数 | 384 |
| サポートする同時エージェント数 | 40,000以上 |
| プロセッサアーキテクチャ | x86およびArm |
| 冷却範囲 | CPU、メモリ、SSD、ネットワークカード、光モジュール、その他の発熱コンポーネント |
| 計算密度 | 0.5Uスペースに4つのCPUを統合 |
| 保守方法 | 液冷全ライフサイクル保守 |
| 対象シナリオ | 高密度およびギガワット級AIデータセンター |
このシステムは、液冷をサーバー設計完了後のアドオンコンポーネントとは見なしていない。
むしろ、計算レイアウトと冷却アーキテクチャは協調して開発されている。
従来のコールドプレートサーバー
プロセッサを直接冷却できるが、メモリ、ネットワーク、ストレージ、電源コンポーネント、およびその他のデバイスは依然としてファン冷却に依存している。
密度が高まるにつれて、このアプローチの効果は薄れていく。
浪潮のネイティブ液冷アーキテクチャは、主要な発熱コンポーネントを統合冷却システムに組み込む。
これにより、内部の気流への依存が減り、コンポーネントのよりコンパクトなレイアウトが可能になる。
以下に「液冷アーキテクチャ」「液冷接続」「液冷運用保守」の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はOpen Compute Moduleの略です。
モジュラーアーキテクチャは、プロセッサモジュールをシステム全体の設計から切り離すことを目的としています。この設計により、プロセッサの世代やアーキテクチャが異なっていても、ラック全体を再設計することなく対応が容易になります。
企業やデータセンター運営者にとって、このソリューションは以下の利点をもたらします：
実際の効果は、エコシステムの互換性、相互運用性、および関連コンポーネントの可用性に依存します。
数万のエージェントを実行することで容量問題は解決できても、回答の質が自動的に向上するわけではありません。
大規模言語モデルにはそれぞれ専門性があります。
特定のモデルは以下の分野に優れている可能性があります：
超大規模モデルでも能力に限界があります。
複雑なタスクを処理する際、単一のモデルでは重要な問題を見落とす可能性があり、他のモデルがそれを発見できることがあります。また、単一のモデルは不確実性を明らかにせず、代替解釈を考慮せずに自信を持って回答する可能性があります。
そのため、Inspurの2つ目のインフラストラクチャの方向性は、マルチモデル連携に焦点を当てています。
EPAIマルチモデル統合APIは、複雑なタスクを並行して複数の候補モデルに分配します。
各モデルは独立して回答を生成します。さらに、審査・統合モデルが候補回答を比較し、以下を特定します：
サポートされていない宣言：
その後、プラットフォームは統合された回答を生成します。
これは単純な多数決でも、すべての回答をそのまま連結することでもありません。予想されるワークフローは以下の通りです：
Inspurの報告によると、このシステムは DRACO評価で53.9% を達成し、テストに使用された候補プール内の各単一モデルよりも優れていました。
この結果は、プラットフォームの報告ベンチマークとして捉えるべきであり、モデル統合が常に最良の単一モデルを上回ることを示すものではありません。パフォーマンスは、候補モデル、評価モデル、ルーティングロジック、タスクタイプ、プロンプト、および評価方法に依存します。
すべてのリクエストで複数のモデルを実行すると、コストとレイテンシが不必要に増加します。
そのため、EPAIは短く予測可能なタスクと複雑なタスクを区別します。
軽量モデルで十分な場合：
複数モデルが有効な場合：
このルーティング原則は、本番システムにとって重要です。
品質の向上が追加のトークンコスト、GPU時間、応答レイテンシを相殺できる場合に、マルチモデル連携が最も価値を発揮します。
EPAI APIは、マルチモデルオーケストレーションを統合インターフェースの背後に隠すことを目的としています。
開発者はプラットフォームにリクエストを送信します。EPAIが以下を管理します：
同じインターフェースをエージェントアプリケーションや開発フレームワークに統合でき、各チームがカスタムモデルルーティングや評価システムを構築する必要はありません。
このアーキテクチャは、以下のモデルを混在して使用する企業に適しています：
主な運用上の課題は、複数の大規模モデルを同時に利用可能に保つ必要があることです。これにより、アクセラレータメモリ、相互接続帯域幅、スケジューリング、および低レイテンシ通信に対する要求が高まります。
アイデアを一文で入力するだけで、We0 AI が紹介サイト、ページ、CMS を生成し、公開後の顧客獲得と流入拡大を支援します。
無料登録で完全なプロジェクトを 1 つ生成
1 つの完全な生成フローを試し、最初のプロジェクトのドラフトをすぐに確認するのに最適です。
MetaBrain SD200スーパーノードは、マルチモデル統合ワークフローを支えるハードウェアプラットフォームです。
このシステムは、マルチホスト、低レイテンシのメモリセマンティック通信アーキテクチャを採用しています。Inspurによると、単一システム内で64個の国産GPUアクセラレータを統一相互接続できます。
その設計には以下が含まれます：
能力
このスーパーノードは、最大4兆パラメータの単一モデル、またはエージェントアプリケーションが同時に使用する複数の兆パラメータモデルをサポートできるとされています。
Inspurは、SD200により兆パラメータモデルKimi K2.6の単一トークン生成時間を4.77ミリ秒に短縮したと報告しています。
また、以前の実装と比較してファーストトークン生成時間が35%削減されたとも報告されています。
これらの数値は、特定の最適化およびテスト環境での結果であり、すべてのモデル、デプロイメント、プロンプト長、同時実行レベル、または本番ワークロードにおけるレイテンシを保証するものではありません。
これらの改善は、複数の技術に起因します。
自己回帰モデルは通常、最初に1つのトークンを生成し、新しい状態を検証してから次のトークンを生成します。
マルチトークン予測は、1ステップで複数の候補トークンを生成し、それらをまとめて検証することを試みます。
予測精度が高い場合、逐次デコードのラウンド数を削減できます。
最適化では、混合エキスパートモデル負荷の一部にINT4重みとINT8アクティベーション計算を使用しています。
BF16計算と比較して、以下を削減できます：
量子化はモデル品質に影響を与える可能性があるため、本番チームは速度結果のみに依存せず、自社の負荷に基づいて精度を評価する必要があります。
JITコンパイルは、実行時にテンソル形状、レイアウト、データ型に基づいて専用のアクセラレータカーネルを生成します。
汎用の静的実装と比較して、専用カーネルは不要な分岐を減らし、メモリアクセスを改善します。
プロンプトプリフィルとトークンデコードは、異なるパフォーマンス特性を持っています。
2つのフェーズを分離することで、リソースを差別化して割り当て、KVキャッシュを非同期に転送し、計算と通信の競合を減らせます。
Inspurは、SD200が以下の主要なオープンソースモデルのパフォーマンス最適化を完了したと述べています：
互換性は、必ずしも各モデルが同じレイテンシやスループットを達成することを意味するわけではありません。
モデルアーキテクチャ、パラメータ数、MoE設計、コンテキスト長、量子化、バッチ処理、サービングソフトウェアは、すべてパフォーマンスに影響を与えます。
64アクセラレータのスーパーノードは大規模AIインフラプロジェクトに適していますが、多くの企業にとっては規模が大きすぎ、コストも高すぎます。
浪潮情報は元脳SD200エンタープライズ版も発表しました。
エンタープライズ版は、スケールアップするコンピューティングドメインを64アクセラレータから16に縮小し、オンプレミスでの兆パラメータモデルの展開を目的としています。
その謳われている特長は以下の通りです：
このエンタープライズ版は、主に以下のワークロードを対象としています：
これは、オンプレミスでのモデル制御が必要だが、64アクセラレータのスーパーノードを正当化できない組織向けに、より小規模なエントリポイントを提供します。
OCTS 2026で発表された製品は、3層アーキテクチャを示しています。
| 層 | 主な役割 |
|---|---|
| ソフトウェアプラットフォーム | モデルアクセス、タスクルーティング、オーケストレーション、権限、評価、結果の統合 |
| CPUインフラストラクチャ | エージェントプロセス、ツール呼び出し、サンドボックス実行、コンテキスト管理、ビジネスシステムとの連携 |
| GPUスーパーノード | 大規模モデル推論、高スループットトークン生成、マルチモデル実行 |
3層すべてが連携して機能する場合にのみ、システムは正常に動作します。
高速なGPUクラスターがあっても、貧弱なエージェントスケジューリングを補うことはできません。高密度のCPUラックがあっても、強力なモデルにアクセスできなければ推論品質を向上させることはできません。基礎となるモデルが効率的にロードまたは接続できなければ、洗練された統合APIも有用なレイテンシを提供できません。
これがエージェントインフラストラクチャにおける競争の主要な変化です。
初期の市場は、単一のサーバーがどれだけ大規模なモデルをサポートできるかに主眼が置かれていました。エージェント時代は、システムレベルのパフォーマンスに注意が向けられるようになりました：
ベンダーが提供する華やかな数値は有用ですが、エージェントインフラストラクチャプラットフォームを選択するには十分ではありません。
本番環境での評価では、完全なワークロードを測定する必要があります。
アクティブユーザーだけでなく、以下もカウントします：
軽量な
検索エージェントと、独立した開発環境を備えたコーディングエージェントでは、リソース要件の特性が大きく異なります。
「ラックあたりのエージェント数」という指標は、対象アプリケーションの実際のメモリ、CPU、ストレージ、ネットワーク要件にマッピングされなければなりません。
以下を測定する必要があります：
ベンチマークでの低いトークン生成時間は、エンドツーエンドのワークフローにおける低レイテンシを保証するものではありません。
マルチモデル統合は品質を向上させる可能性がありますが、推論コストが倍増する可能性があります。
チームは以下を比較する必要があります：
ネイティブ液冷ラックには、対応する施設インフラストラクチャが必要です。
以下を確認する必要があります：
オープンモジュール標準は柔軟性を高める可能性がありますが、実際の移植性はソフトウェアの互換性に依存します。
以下を検証する必要があります：
長期実行エージェントには、以下に対する強力な管理が必要です：
インフラストラクチャの密度は、運用上の分離を犠牲にするものであってはなりません。
これは、従来の空冷設計に液冷を追加するのではなく、冷却システムを中心に設計されたラック全体のCPUサーバーです。浪潮は、最大384のCPUを搭載し、40,000以上の並行エージェントをサポートできると述べています。
その数値は、浪潮のリファレンスアーキテクチャベンダーレポートの最大値です。実際の容量は、エージェントごとに必要なCPU、メモリ、ストレージ、ネットワーク、サンドボックス分離リソースに依存します。
言語モデルはGPU上で実行されるかもしれませんが、エージェントはスケジューリング、ツール実行、状態管理、ビジネスシステムアクセス、セキュリティチェック、隔離されたランタイム環境のためにCPUも必要とします。長時間実行とマルチエージェントワークフローは、このCPU需要をさらに増加させます。
OCMは、コンピューティングモジュールをより広範なラック設計から分離するためのオープンコンピュートモジュールアーキテクチャです。浪潮の液冷OCM 2.0システムは、複数のCPUアーキテクチャと全コンポーネント液冷をサポートします。
MetaBrain SD200は、大規模モデル推論とマルチモデルワークロード向けに設計された浪潮のAIスーパーノードです。64アクセラレータのスケールアウトアーキテクチャを採用し、統一アドレッシングと高速相互接続をサポートします。
これは、1つのタスクを複数の候補モデルに送信し、それらの独立した回答を収集し、
レビューと統合モデルを使用して、最終応答を生成する前に合意、相違点、見落とし、独自の見解を特定するAPIです。
いいえ。マルチモデルは複雑なタスクのパフォーマンスを向上させる可能性がありますが、トークン消費、計算コスト、レイテンシが増加します。単純なタスクは、単一の軽量モデルにルーティングする方が適しています。
フル版のSD200は超大規模ワークロードを処理するために64アクセラレータのスケールアウトドメインを採用していますが、SD200エンタープライズ版はドメインを16アクセラレータに縮小し、より低いインフラ障壁でオンプレミスの兆パラメータモデルを展開する必要がある企業を対象としています。
DeepSeek：AIモデルプロバイダー。そのオープンソースモデルはSD200互換リストに含まれています。
浪潮がOCTS 2026で発表した内容は、エンタープライズ・エージェントが引き起こす2つの主要課題に対処するものです。
CPUネイティブ液冷ラックは拡張性に重点を置き、エージェントのスケジューリング、ツール、サンドボックス、コンテキスト管理、長時間実行プロセスに高密度な環境を提供します。SD200とEPAマルチモデル融合ワークフローはインテリジェンスに焦点を当て、複数の大規模モデルが連携して複雑なタスクを処理し、レビューモデルが出力結果を統合します。
より広範な示唆として、エージェントインフラは単一の高速アクセラレータに還元できません。本番システムでは、CPU、GPU、メモリ、インターコネクト、冷却、オーケストレーション、権限管理、評価を調整する必要があります。
エージェントインフラの主要な評価基準は、単一モデルの実行効率から、システム全体が数千のエージェントを効率的にスケジューリングし、信頼性の高い結果を継続的に生成できるかどうかに移行しています。
