AI-RANにおける社外AIワークロード統合〜AITRASオーケストレーターによる動的リソース制御の実装〜

1. 背景：AI-RANと外部AI需要の拡大

AI-RANは、RANとAIを単に組み合わせるのではなく、通信機能とAIワークロードを同一インフラ上で協調・共存させるアーキテクチャーを含む概念です。本記事では、その中でも両者が同一の計算資源を共有しながら、それぞれの特性や優先度に応じて動的にリソースを調整する「AI and RAN」の考え方に焦点を当てています。
このAI and RANの前提に立つことで、通信品質を維持しつつAI処理を同一基盤上で実行することが可能となります。一方で、両者が同じ計算資源を利用するため、需要の変動や優先度の違いをどのように制御するかが重要な設計課題となります。
さらに近年ではAI処理基盤の汎用化を背景に、通信事業者のエッジやデータセンターをより柔軟に活用する動きが広がっています。

2. 課題：内部AI制御の高度化とリソース利用効率の限界

前述のとおり、AI and RANの前提では通信機能とAIワークロードが同一の計算資源を共有します。AITRASオーケストレーターはこれまで、この枠組みの中で通信品質を維持しつつAI処理を安定的に実行できるよう、優先度制御やリソース管理を行ってきました。
しかし、同一基盤上でRANとAIが共存する構造では、両者の需要特性が時間的に重なりやすいという課題があります。特に単一国内の需要を扱う場合、ユーザートラフィックが集中する時間帯には通信機能とAI処理の双方がリソースを必要とし、ピーク時には逼迫が生じやすくなります。一方で、夜間などトラフィックが少ない時間帯にはリソースが余剰となる傾向があります。このように、AI and RANとして共存を実現できていたとしても、需要の時間的な偏りそのものを内部ワークロードのみで解消するには限界があります。そこで、余剰が発生する時間帯に外部AIワークロードを受け入れることで、計算資源の利用率を高め、インフラ全体をより効率的に運用するという方向性が重要になります。ただし、そのためにはRAN制御への影響を最小限に抑えつつ、内部・外部のAIワークロードを横断的に評価し、動的に制御できるオーケストレーション機構が不可欠です。AITRASには、AI-RAN全体を俯瞰した制御基盤として、こうした役割が求められています。

図1. AI-RANにおける時間ごとの計算資源の使用量割合の変化

3. AITRASオーケストレーターの全体像

AITRASオーケストレーターは、AI for RAN、AI on RAN、AI and RANを含むAI-RAN全体を統合的に制御する中核機構です。RAN制御とAI処理の双方に関わる計算資源の需要をリアルタイムかつ横断的に把握し、状況に応じて最適なリソース割り当てを行います。本オーケストレーターは、モニタリング情報とポリシーに基づき、各ワークロードの優先度や制約条件を踏まえたリソース配分を行います。今回、外部AIワークロードの取り込みにより、時間帯によって発生していたリソースの偏りを緩和することが可能になります。ピーク時にはRANおよび内部AIワークロードを優先し、夜間など余剰が発生する時間帯には外部AIワークロードを受け入れることで、同一インフラ上の計算資源をより効率的に活用できるようになります。これにより、RAN制御への影響を最小化しながらAI処理を実行し、時間帯による需要の変動にも柔軟に対応します。

4. 外部AI基盤との連携アーキテクチャー

本構成における外部AI基盤は、複数のAIワークロードと計算資源提供者を仲介するブローカー型のAIオーケストレーション基盤を想定しています。例えば、MWC26ではノキア ベル研究所のAI（人工知能）基盤「Nokia AI-RAN External Compute Engine」と連携したデモを紹介しました。AI-RAN Allianceで議論されている参照アーキテクチャーでは、この役割はAIドメインのワークロードを管理する「AI Orchestrator」と位置づけられ、AIワークロードの受付、実行条件の整理、実行基盤の選択および割り当てを担います。
AITRASオーケストレーターにより管理されるエッジやデータセンターのクラスターをこの外部AI基盤に対して計算資源として提供します。外部AI基盤はAITRASオーケストレーター配下のクラスターを単一の抽象化された実行可能な計算資源として認識し、必要な計算資源量や制約条件に応じてオーケストレーターから提供された計算資源を利用します。この連携において重要なのは、両者の責務を分離している点です。AITRASオーケストレーターはRAN制御への影響や内部AIとの優先度を踏まえて提供可能な計算資源を判断します。AITRASオーケストレーターと外部AI基盤の間では、要求情報や実行状況がやり取りされ、外部AI基盤側のワークロード集約やテナント管理の詳細からは分離された形で制御が行われます。
このブローカー型の連携により、個々のAIアプリケーションと直接結合することなく計算資源を提供できます。その結果、オーケストレーターはRAN制御や内部AIとの優先度調整に集中しつつ、余剰時間帯の計算資源を外部AI向けに効率よく活用する運用が実現します。

図2. AI-RANオーケストレーターのシステムアーキテクチャー

5. 動作シーケンス：外部AIワークロード実行時

外部AIワークロードの受け入れは、AI and RAN環境における継続的なモニタリングと定期的なスケジューリング処理に基づく制御ループとして設計されています。ここでは、モニタリングによる需要可視化を起点とし、評価・判断・構成変更が実行されます。

図3. AITRASオーケストレーターと外部AI基盤との連携シーケンス

1. 需要の可視化（継続的モニタリング）

RAN制御および内部AIの需要・優先度は、モニタリング機構によって常時収集・更新されています。GPUなどの計算資源については、使用率や割り当て状況がリアルタイムに把握され、余剰リソースが継続的に可視化されます。また、外部AIの計算需要も同様に常時収集され、これらの情報は後段の判断処理の基礎データとなります。

2. 定期スケジューリングと価値評価

更新された内外の需要情報を基に、定期スケジューリングが実行されます。このタイミングで、外部へ提供可能な計算資源があるかどうかが評価されます。
現時点では、主にGPUなどの計算資源の空き状況を基準としていますが、将来的には、通信品質や運用効率といった内部価値と、外部提供による事業的価値を総合的に評価し、リソース割り当ての判断に反映することも想定しています。

3. 外部提供判断

評価結果に基づき外部へ計算資源を提供する場合、外部AI基盤（AI Orchestrator）に対して提供可能なキャパシティが提示されます。提供量は、需要状況に応じて動的に決定されます。

4. 実行（GitOpsによるクラスター設定変更）

決定された方針はGitリポジトリ上の構成変更として反映されます。役割定義（例：RAN優先、汎用、GPU専有など）や、テイント、スケジューリングポリシーなどが更新され、GitOpsの仕組みによってクラスターへ適用されます。
このため、ここでいう「実行」は、ランタイムで直接ノードやワークロードを操作することではなく、あるべき状態を宣言的な設定として更新し、その適用結果としてワークロード配置やリソース割り当てが変化する形で実現されます。設定変更はGitリポジトリを一意な望ましい状態として反映するため、安全性と再現性を担保したまま外部AI受け入れ方針をインフラへ反映することができます。

以上の1〜4は継続的な制御ループとして設計されており、モニタリングによる需要の継続的な更新と、定期的なスケジューリング・評価・GitOpsによる方針反映が循環的に実行されます。内外の需要バランスがリアルタイムに次回のスケジューリングに反映されることで、外部提供量や受け入れ方針が見直されます。このように、需要可視化から実行までを一体化した制御ループにより、AITRASはAI and RAN環境における需要変動へ継続的に対応します。
外部AI基盤と連携し、管理しているリソースを柔軟に外部へ提供できる構成とすることで、AI-RANインフラは内部・外部のAIワークロードを統合的に扱う基盤へと進化します。

6. 今後の展望：価値を最大化するインフラへの進化

本記事では、AITRASオーケストレーターを中心に、AI-RAN環境における外部AI連携の技術背景と制御構造について解説しました。リアルタイムな需要把握と柔軟なリソース制御は、計算資源を最大限活用するための重要な要素です。
今後は、外部AIワークロードを単に受け入れるか否かを判断するだけでなく、内部で利用するAIワークロードと外部に提供するAIワークロードがそれぞれ生み出す「価値」を評価し、より高い価値をもたらす選択を行う役割が求められます。通信品質や運用効率といった内部価値と、外部提供による事業的価値を総合的に評価し、より高い価値をもたらす選択を行うことが求められます。
このような価値指向のオーケストレーションにより、AITRASはAI-RANインフラを単なる実行基盤から「価値を最大化するインフラ」として進化させていきます。内部利用と外部提供を動的に最適化することで、通信インフラとしての安定性を維持しつつ、そのポテンシャルを最大限に引き出すことを目指していきます。