3行まとめ
このテーマをもう少し広げて見るなら、VCF 9.1でNVMe Memory Tieringを有効化する前に確認する：esxcli memtier、DRAM:NVMe比率、VM制約の実務ポイント と VCF 9.xでDell PowerFlexを使う前に確認する：SDC、NVMe/TCP、グリーンフィールド制約の実務ポイント も合わせて確認してください。AI基盤をネットワークとGPUだけで見ず、ホストメモリ容量とDRAM:NVMe比率もPoC条件に入れられます。
WebinarはAIネットワークとGPUインフラの確認論点を拾う入口として扱います。
MP-BGP EVPN、VXLAN datapath、CloudVisionとVCF Operationsの境界を確認します。
GPU性能の数字だけでなく、サーバー互換性、driver/runtime、モデル運用へ落とします。
network、GPU、storage、security、operationsを同じ検証範囲で見ます。
発表内容をそのまま採用判断にせず、自社環境で確認する項目へ分解することが重要です。
- BroadcomのVCF Webinar Libraryでは、AristaとAMDの専門家がVCF 9.1上のproduction AI networksとGPU infrastructureを扱う動画が確認できます。これは需要シグナルであり、仕様判断は公式発表、各技術ブログ、TechDocsで裏取りする必要があります。
- Arista連携では、VCF Route ControllerとArista EVPN GatewayのMP-BGP EVPN、VXLAN datapath、CloudVisionとVCF Operationsの運用境界を、設計レビューの項目として確認します。
- AMD Instinct MI350対応では、288GB HBM3EやPyTorch、vLLM、OPEA、Hugging Faceの訴求を、GPU調達ではなく、サーバー互換性、モデル運用、PoC測定、セキュリティ審査へ落とすことが大事です。
BroadcomのVMware Cloud Foundation 9.1は、AIとKubernetesを含むprivate cloud基盤として発表されました。今回の焦点は、その中でもArista NetworksとのEVPN/VXLAN連携と、AMD Instinct MI350 Series GPU対応です。どちらも「対応したから使うべき」という話ではありません。導入企業にとっての本題は、VCF側、物理ネットワーク側、GPUサーバー側、AIアプリケーション側の責任分界を、PoC前に説明できるかどうかです。
本記事は2026年6月11日JST時点で確認したBroadcom/VMware by Broadcomの公式情報をもとに、発表内容を導入前チェックへ変換します。株価やAI需要の話題は背景にとどめ、読者が触れる製品、基盤、運用判断を主役にします。
Webinarの需要シグナルを導入判断に変換する
- 1Webinar
AristaとAMDのテーマから、AI networkとGPU infrastructureの確認論点を拾います。
- 2VCF 9.1発表
production AI workloads、mixed compute、integrated securityの位置づけを確認します。
- 3Release Notes
2026年5月12日、Build 25377994、BOM、Known Issues、Product Support Notesを固定します。
- 4個別設計項目
Arista EVPN/VXLAN連携、AMD MI350対応、VKS、VCF Operationsへ分解します。
Webinarは仕様の最終根拠ではなく、確認すべき一次情報を選ぶためのシグナルです。
BroadcomのVCF Webinar Libraryには「Discover How the Newly Announced Partnerships Expand VCF 9.1 Capabilities」という動画があり、AristaとAMDの専門家がVCF 9.1上のproduction AI networksとGPU infrastructureについて話す内容として説明されています。動画の長さは10分54秒です。
ここで大事なのは、動画の表示そのものを仕様の根拠にしないことです。Webinarは「いま読者が確認すべき論点が、AIネットワークとGPUインフラに寄っている」という需要シグナルとして扱います。実際の設計判断では、BroadcomのVCF 9.1発表、VMware Cloud Foundation BlogのArista記事とAMD記事、VCF 9.1 Release Notesを見ます。
VCF 9.1発表で確認する土台
Broadcomは2026年5月5日の発表で、VCF 9.1をproduction AI workloads向けのsecure and cost-effective infrastructure platformとして位置づけています。発表文では、AI and Kubernetes native private cloud platform、integrated security、AMD/Intel/NVIDIAを含むmixed compute infrastructure supportが前面に出ています。
この表現は、AI基盤をVCF上に載せる流れを読むには重要です。ただし、発表文の強いメッセージだけで設計を決めると危うくなります。読者が最初に見るべきなのは、どの機能が自社のVCF採用バージョンで使えるのか、どのハードウェアやネットワーク構成がサポート対象なのか、どの運用チームが変更管理を持つのかです。
確認項目
- VCF 9.1のRelease Notesで、採用するバージョン、BOM、Known Issues、Resolved Issues、Product Support Notesを確認する。
- VCF 9.1の発表文にあるAI訴求を、Arista連携、AMD GPU対応、VKS、Private AI Services、VCF Operationsなどの個別確認項目へ分解する。
- Webinarは「何を追加確認するか」を決める材料にとどめ、仕様やサポート条件の最終根拠にしない。
Release Notesで固定する日付とバージョン
VCF 9.1 Release Notesでは、VMware Cloud Foundation 9.1が2026年5月12日、Build 25377994として示されています。記事を読む読者にとって、この日付は小さく見えて重要です。AristaやAMDのブログが魅力的でも、最終的に自社環境が参照するのは、採用するVCFバージョン、コンポーネント、サポートノート、既知問題だからです。
設計レビューでは、まず「VCF 9.1をどのビルド、どの更新状態で見るのか」を固定します。そのうえで、Arista EVPN/VXLAN連携とAMD MI350対応をPoC範囲に入れるかを決めます。
注意点
VCF 9.1全体の機能紹介に広げすぎると、記事の検索意図がぼやけます。VKSの3ゾーン設計は前回の記事へ、ネットワーク性能のEDP StandardはEDP確認記事へ送るのが読みやすい流れです。ここでは、AristaとAMDの連携を導入前にどう切り分けるかに集中します。
Arista EVPN/VXLAN連携は「どこで経路を交換するか」から見る
- 1VCF VPC
workload、Transit Gateway、外部endpointとの通信範囲を整理します。
- 2MP-BGP EVPN peering
VCF Route ControllerとArista EVPN GatewayのASN、neighbor、prefix、filteringを確認します。
- 3VXLAN datapath
MTU、ECMP、latency、packet loss、firewall、DNS、監視ログの所在を確認します。
- 4障害時の扱い
route withdraw、再収束時間、切り戻し手順、変更承認の所有者を決めます。
BGP sessionが成立することと、AI workloadの通信品質を満たすことは別に確認します。
Arista連携で最初に確認するのは、スイッチ名やファブリック製品名ではありません。VCF側のVPCと、Arista側のEVPN/VXLANファブリックが、どこで経路を交換し、どの通信をどの運用チームが見るのかです。
VMware Cloud Foundation BlogのArista記事では、VCFとArista Universal Cloud Networkをつなぐ考え方が示されています。例として、VCF内のVPCにいるVMがTransit Gatewayを通じてArista Leaf Switchへ接続し、別のArista Leaf配下の外部サーバーと通信する構成が説明されています。
Control planeはMP-BGP EVPN peeringで確認する
Arista記事では、VCF Route ControllerがArista EVPN GatewayとMP-BGP EVPNでpeeringし、VCF側と非VCF側がworkload routesを動的に学習する流れが示されています。ここは、導入前レビューで最も曖昧にしやすい部分です。
「BGPでつながる」とだけ書いても、設計としては足りません。どのASNを使うのか、どのprefixを広告するのか、tenantやVNIをどう対応させるのか、route filteringを誰が管理するのか、障害時にwithdrawや再収束をどう確認するのかまで決める必要があります。
確認項目
- VCF Route ControllerとArista EVPN Gatewayのpeering設計。
- ASN、BGP neighbor、route advertisement、route filtering、tenant/VNIの管理方針。
- VCF側VPC、Transit Gateway、外部endpointの通信範囲。
- 障害時のroute withdraw、再収束時間、切り戻し手順。
- 変更管理の所有者。仮想化チーム、ネットワークチーム、セキュリティチームのどこが承認するか。
Data planeはVXLAN datapathと対称性を見る
Control planeで経路を交換できても、アプリケーションが求める通信品質を満たすとは限りません。Arista記事では、VCFと非VCF環境をまたぐVXLAN datapathも説明されています。設計レビューでは、どの通信がVCF内で閉じるのか、どの通信がArista fabricをまたぐのかを分けて見ます。
AIワークロードでは、推論API、モデル取得、RAG用データベース、オブジェクトストレージ、ログ、監視、Kubernetes APIなど、通信の種類が多くなります。GPUサーバーを強くしても、モデルレジストリやストレージへの経路が詰まれば、アプリケーション全体の体験は改善しません。
注意点
VXLANで接続できることと、本番AI基盤として運用できることは別です。MTU、ECMP、latency、packet loss、firewall、DNS、監視、ログの所在を分けて確認します。特に既存環境でNSX Edge、NAT、L4/L7 load balancing、VPC Network Span、DTGWが絡む場合は、「Arista連携でEdgeをなくせる」と単純化しないほうが安全です。
VCF 9.1のVPC Network Span、TGW、DTGWを先に整理したい場合は、VCF 9.1のVPC Network Span確認記事を合わせて読むと、VCF側の境界が見えやすくなります。
NSX Edge削減の可能性は慎重に扱う
Arista記事では、仮想化チーム側にとってworkload domainのスケールや、edge node infrastructureを必要としないことによるコストや運用面の利点が示されています。これは導入検討の材料になります。ただし、読者環境で同じ効果が出るとは限りません。
既存のNSX Edgeが、NAT、firewall、load balancing、VPN、north-south traffic、テナント分離のどれを担っているかを先に棚卸しします。Arista連携は物理ファブリックとの標準ベースの相互接続を強める話ですが、NSX Edgeが持っていたすべての機能を自動で置き換える話ではありません。
評価基準
採用判断へ進めるのは、次の条件が説明できる場合です。
- Edge nodeを減らす場合でも、NAT、firewall、LB、VPN、監視の代替責任が明確である。
- VCF側のVPCとArista側のtenant/VNIの対応表がある。
- route advertisementとroute filteringの変更管理が決まっている。
- 障害時に、VCF Operations、Arista CloudVision、NSXログ、switch telemetryを突き合わせられる。
AristaファブリックとVCF運用の境界を決める
一つの画面ですべてを見る前提にせず、一次対応者とエスカレーション先を明確にします。
Arista連携の価値は、物理ネットワークとVCF側の仮想ネットワークを同じ設計会議で扱える点にあります。一方で、運用境界を曖昧にすると、障害時に「どちらの問題か」を切り分けられなくなります。
公式ブログでは、Arista CloudVisionがVCF Operationsを補完し、network deploymentsの自動化、end-to-end visibility、real-time telemetry、change controlsに関わると説明されています。ここは「一つの画面ですべて見える」と受け止めるより、どの情報がどこにあり、誰が一次対応するのかを決める材料にするのが現実的です。
CloudVisionとVCF Operationsを並べて見る
VCF OperationsはVCF側の状態、ワークロード、運用監視の中心になります。Arista CloudVisionはArista fabric側のtelemetry、構成、変更、イベントを見ます。設計レビューでは、両方のデータをどう突き合わせるかを確認します。
確認項目
| 領域 | VCF側で見るもの | Arista側で見るもの | 共通で合意するもの |
|---|---|---|---|
| 経路 | Route Controller、VPC、TGW | EVPN Gateway、leaf/spine、route table | prefix、filtering、withdraw時の扱い |
| tenant/VNI | VCFのVPC/tenant設計 | fabric側のtenant/VNI | 命名規則、変更承認 |
| 通信品質 | workload、NSX/VCF観測点 | telemetry、port、fabric path | MTU、ECMP、latency、packet loss |
| 障害対応 | VCF Operations、NSXログ | CloudVision、switch telemetry | 初動担当、エスカレーション、復旧判定 |
この表を作っておくと、PoCで「BGP sessionは張れたがアプリが遅い」という状態になった時、見るべき場所がはっきりします。
AI workloadのeast-west通信を想定に入れる
AI基盤の通信は、north-southだけではありません。GPU workerとstorage、model registry、RAG用DB、ログ基盤、Kubernetes API、監視エージェント、外部データソースの間でeast-west通信が増えます。
Arista連携を評価するPoCでは、単純な帯域測定だけに寄せないほうがいいです。実際のAI workloadに近い通信、たとえばモデルロード、推論API、ベクトル検索、ログ書き込み、監視メトリクスの流れを入れます。ネットワーク担当が見る指標と、アプリ担当が見るSLOを同じ表で管理できると、PoCの合否がぶれにくくなります。
評価基準
- BGP peeringが成立しているだけでなく、主要ワークロードの通信経路を説明できる。
- 障害時の再収束時間、アプリケーション側のretry、監視アラートが測れている。
- ネットワーク変更の承認者、作業時間、戻し方が決まっている。
- VCF側とArista側のログを、同じ時刻軸で突き合わせられる。
AMD Instinct MI350対応はGPU調達ではなく基盤設計として読む
VCF 9.1でのサポート追加を、対応サーバー、HCL、BIOS、firmware、driver/runtimeで確認します。
288GB HBM3Eの訴求を、対象モデル、量子化、batch size、sequence length、メモリ余裕で検証します。
稼働率、待ち時間、電力/冷却、予備容量、運用工数を含めて見ます。
VM/Kubernetes配置、監視、障害時の代替先、メンテナンスウィンドウを設計します。
GPUサーバー互換性、電源、冷却、ネットワーク帯域、モデルSLOが未確定なら、調達判断より棚卸しが先です。
AMD側の公式ブログでは、VCF 9.1でAMD Instinct MI350 Series GPUsをサポート対象に加える流れが示されています。MI350 Seriesは、前世代AMD GPUに対して4倍のgenerational increase in AI compute、最大10 PetaFLOPSのFP4/FP6 operations、288GB HBM3E memory、単一GPUで最大520 billion parametersのモデルを扱えるという訴求が記載されています。
これらは注目しやすい数字ですが、導入判断では数字をそのまま自社環境へ移植しないことが大切です。モデルの精度、量子化、batch size、sequence length、vLLM設定、GPU memory使用量、network/storageの待ち、電力と冷却、ラック密度で結果は変わります。
MI350の性能訴求を検証項目に変換する
MI350対応を読む時は、「高性能GPUが使える」ではなく「どのワークロードで、何を測るか」に変換します。推論、RAG、バッチ処理、学習、微調整、モデル配布では、見る指標が違います。
確認項目
| 確認対象 | 公式情報で見えること | 自社で確認すること |
|---|---|---|
| MI350 Series | VCF 9.1でのサポート追加、AI training/inferencing向け訴求 | 対応サーバー、HCL、BIOS、firmware、driver/runtime |
| GPU memory | 288GB HBM3E、単一GPUで大きなモデルを扱えるという説明 | 対象モデル、量子化、batch size、sequence length、メモリ余裕 |
| 性能/TCO | GPU数削減やTCO最適化の訴求 | 稼働率、待ち時間、電力/冷却、予備容量、運用工数 |
| VCF運用 | VCFの一貫した運用体験 | VM/Kubernetes配置、監視、障害時の代替先 |
ここで止まるべきケースもあります。GPUサーバーの互換性が未確認、電源や冷却が未確定、ネットワーク帯域が測れていない、モデルやSLOが決まっていないなら、導入判断より棚卸しが先です。
Hot-add/removeはGPUそのものと混同しない
AMDブログでは、running VMsに対してvCPU、memory、storage、network adaptersを追加または削除できる仮想ハードウェアの文脈が示されています。これはAI workloadをright-sizeする運用設計として重要です。
ただし、ここを「GPUデバイスそのものをいつでも自由に動的追加できる」と読まないように注意が必要です。本文で扱うべきは、AI workloadに必要なvCPU、memory、storage、network adapters、GPU割り当て、停止許容、メンテナンスウィンドウをどう設計するかです。
注意点
GPUが高価だからこそ、稼働率と待ち時間を一緒に見ます。GPU utilizationだけが高くても、モデルロードが遅い、network throughputが足りない、storage I/Oで詰まる、監視が取れない状態なら、本番基盤としては未完成です。VCF 9.1のCost OverviewやShowbackの確認は、FOCUS/FinOpsの記事へつなげると整理しやすくなります。
サーバー互換性と運用条件を先に見る
MI350対応を検討できるのは、GPUだけでなく、そのGPUを載せるサーバー、CPU、memory、storage、NIC、firmware、driver、冷却、電力、ラック、サポート窓口が確認できる場合です。VCF 9.1 Release Notesだけでは、読者の個別サーバー構成まで保証できません。
VCF 9.1へ上げる前のCPU/サーバー互換性に不安がある場合は、VCF 9.1移行前のCPU/サーバー互換性記事も見ておくと、GPU以前の足場を確認できます。
評価基準
- VCF 9.1の採用バージョン、BOM、サポートノートが確認済み。
- 対象GPUサーバーの互換性、firmware、driver/runtime、電力/冷却が確認済み。
- 対象モデル、推論/学習/微調整の用途、PoCの測定指標が決まっている。
- 監視、ログ、障害時の代替先、コスト可視化の責任者が決まっている。
Open frameworksは開発者体験だけでなく運用境界で見る
- 1framework選定
PyTorch、vLLM、OPEAを、推論、RAG、生成AI blueprintなどの用途に合わせて整理します。
- 2モデル管理
取得元、ライセンス、モデルカード、更新頻度、承認フローを確認します。
- 3実行環境
container registry、SBOM、脆弱性スキャン、署名、driver/runtime管理をそろえます。
- 4監査とデータ
RAGのデータ所在、prompt/log保存、削除要件、認証、監査ログを同じ表で扱います。
モデルを動かせることは出発点であり、セキュリティ審査や運用責任を省略する理由にはなりません。
AMDブログでは、PyTorchとvLLMのnative support、OPEAによるRAG/生成AI向けblueprint、Hugging Face経由で利用できるopen-source modelsが説明されています。開発者にとっては魅力的な材料です。ただし、導入企業では、モデルを動かせることと、本番運用できることは分けて確認します。
PyTorch、vLLM、OPEAをどう扱うか
PyTorchやvLLMは、モデル実行の現場で重要です。OPEAはRAGや生成AI向けのblueprintを考えるうえで役立ちます。Hugging Faceのモデル群は選択肢を広げます。
一方で、企業環境ではモデル取得元、ライセンス、モデルカード、脆弱性、コンテナイメージ、driver/runtime、データ分類、監査ログ、認証/権限が絡みます。オープンなフレームワークを使えることは出発点であり、セキュリティ審査や運用責任を省略する理由にはなりません。
確認項目
- PyTorch、vLLM、OPEAをどの用途で使うか。
- モデル取得元、ライセンス、モデル更新頻度、承認フロー。
- container registry、SBOM、脆弱性スキャン、署名、runtime管理。
- GPU memory、batch size、token throughput、model load time。
- RAGで扱うデータの所在、prompt/log保存、削除要件。
VKSやKubernetesの詳細は別記事へ逃がす
GPU workloadをKubernetesで動かす場合、VKS、node pool、network、storage、Ingress、GitOpsなどの設計が必要になります。ただし、このページでKubernetes設計をすべて扱うと、AristaとAMDの連携に必要な確認軸がぼやけます。
Kubernetes側に進む読者は、まずVKS on VCF 9.1の3ゾーン/VPC/VDS/Antrea/LB確認記事で、クラスタ配置とネットワーク境界を確認してください。GitOpsへ進む場合は、VKSでArgo CD GitOpsを始める前の記事が次の入口になります。
注意点
AI基盤の記事だからといって、Kubernetesを前提にしすぎないことも重要です。VCF上ではVMで動かすAI workloadもあります。VMで動かすか、Kubernetesで動かすか、両方を使うかによって、GPU割り当て、ネットワーク、監視、セキュリティの確認項目は変わります。
セキュリティ審査とモデル運用を同じ表に入れる
AI基盤のPoCでは、性能評価だけを先に進めがちです。しかし本番化では、モデルライセンス、データ分類、prompt/log保存、RAGのデータ所在、認証、監査ログ、ネットワーク分離が後から効いてきます。
評価基準
開発者がモデルを動かせるだけでは合格にしません。運用チームが、モデル更新、監査、障害対応、コスト可視化、セキュリティ例外、ユーザー権限を説明できる状態を合格条件にします。
ネットワークとGPUを別々にPoCしない
GPUが速くても、モデル取得、RAG検索、storage access、監視ログが詰まれば、利用者が感じる性能は出ません。
Arista連携とAMD MI350対応は、別々の話に見えます。けれどもAI基盤として見るなら、ネットワークとGPUを分けてPoCしすぎないことが大切です。GPUが速くても、モデル取得やRAGの検索、storage access、監視ログの書き込みが詰まれば、利用者が感じる性能は出ません。
PoCで先に固定するワークロード
最初に決めるのは、どのAI workloadを検証するかです。推論API、RAG、バッチ処理、学習、微調整、モデル配布では、GPU、network、storage、security、運用の評価軸が違います。
確認項目
- 対象ワークロード。推論、RAG、学習、微調整、batch、API servingのどれか。
- 合格指標。latency、throughput、token throughput、GPU utilization、HBM使用量、network throughput、packet loss、model load time、storage I/O。
- 障害試験。BGP session断、route withdraw、GPU host障害、storage遅延、モデルロード失敗、監視アラート。
- 戻し方。ネットワーク設定、VM/Kubernetes配置、driver/runtime、モデルバージョンをどう戻すか。
Arista側の測定項目
Arista側では、BGP session、route convergence、VXLAN tunnel、MTU、ECMP、leaf/spine telemetry、CloudVisionのイベント、VCF Operationsとの突き合わせを測ります。帯域測定だけでは不十分です。実際にAI workloadが使う経路を通し、モデル取得、推論API、storage access、ログ、監視の通信を含めます。
注意点
ネットワークのPoCが成功しても、セキュリティや運用の合格とは限りません。route filtering、tenant分離、監査証跡、変更承認、障害時の一次対応者を同じチェックリストへ入れます。
AMD側の測定項目
AMD側では、GPU utilization、HBM使用量、model load time、token throughput、batch size、vLLM/PyTorch設定、driver/runtime、VMまたはKubernetes上の配置、host CPU/memory、storage I/Oを見ます。
注意点
GPU性能だけでTCOを語らないことです。GPUの待ち時間、夜間や低負荷時の稼働率、電力/冷却、予備容量、障害時の代替先、運用工数、Showbackの粒度まで見て初めて、導入判断の材料になります。
設計レビュー用チェックリスト
Release Notes、Build、BOM、Known Issues、Product Support Notes、Webinarと一次情報の切り分けを確認します。
control plane、data plane、tenant/VNI、運用監視、障害対応の責任分界を確認します。
MI350対応範囲、GPU server、HCL、driver/runtime、電源、冷却、予備容量を確認します。
推論、RAG、学習、微調整、batchのどれを対象にし、合格指標をどう測るかを決めます。
モデルライセンス、データ所在、prompt/log、監査、GPU稼働率、Showbackを同じレビューに入れます。
未決項目が多い場合は、導入判断を急がず、PoC範囲と責任分界の整理を優先します。
最後に、Arista/AMD連携を導入前に確認するためのチェックリストをまとめます。これは推奨構成ではありません。読者環境の未決項目を洗い出すための道具です。
最初に確認する12項目
| 領域 | 確認すること | 未決なら止める理由 |
|---|---|---|
| VCF 9.1 | Release Notes、Build、BOM、Known Issues、Product Support Notes | 採用する土台が曖昧になる |
| 需要シグナル | Webinar Libraryのテーマと一次情報の切り分け | 動画だけで仕様判断してしまう |
| Arista control plane | Route Controller、EVPN Gateway、MP-BGP EVPN | 経路交換の責任分界が曖昧になる |
| Arista data plane | VXLAN datapath、MTU、ECMP、latency | 接続できてもアプリ要件を満たせない |
| tenant/VNI | VPC、tenant、VNI、prefixの対応 | マルチテナント運用で事故が起きやすい |
| 運用監視 | VCF Operations、CloudVision、NSXログ、telemetry | 障害時の切り分けが遅れる |
| AMD MI350 | 対応範囲、GPU server、HCL、driver/runtime | 調達後に載せられない可能性がある |
| AI workload | 推論、RAG、学習、微調整、batchのどれか | PoCの合否が曖昧になる |
| framework | PyTorch、vLLM、OPEA、Hugging Face | 開発者体験と運用審査が分断される |
| VM/Kubernetes | VMで動かすか、VKSで動かすか、両方か | GPU割り当てやネットワーク設計が変わる |
| security | モデルライセンス、データ所在、prompt/log、監査 | 本番化直前に止まりやすい |
| cost/TCO | GPU稼働率、待ち時間、電力/冷却、Showback | 性能だけで投資判断に見える |
先に止まるケース
次の状態なら、導入判断より棚卸しを優先したほうが安全です。
- VCF 9.1の採用バージョン、BOM、既知問題が未確認。
- Arista fabric側の担当者、BGP/tenant/VNI方針、変更承認が未定。
- GPUサーバーの互換性、電力、冷却、driver/runtimeが確認できていない。
- 対象モデル、ワークロード、PoCの合格指標が決まっていない。
- VCF Operations、CloudVision、NSXログ、アプリログの突き合わせ方法がない。
- セキュリティ審査、モデルライセンス、RAGデータ所在、prompt/log保存の責任者がいない。
進めてよいケース
前向きにPoCへ進めるのは、ネットワーク担当、仮想化担当、AI/アプリ担当、セキュリティ担当、運用担当が、同じPoC範囲と同じ失敗時の戻し方を説明できる時です。VCF 9.1のArista/AMD連携は、AI基盤を広げる材料になります。ただし、使いこなすには、発表内容を自社の経路、GPU、モデル、監視、セキュリティへ翻訳する作業が必要です。
Broadcom Watch Japanでは、VCF 9.1、AI networking、Private AI、VMware by Broadcomの公式発表を一次情報ベースで追っています。更新通知はニュースレターで受け取れます。
次に読むなら
参照した主な情報源
- Broadcom VCF Webinar Library, "Discover How the Newly Announced Partnerships Expand VCF 9.1 Capabilities", 2026年6月11日確認
https://videos.software.broadcom.com/vcf-webinars/detail/videos/vcf-webinar/video/6395272233112/discover-how-the-newly-announced-partnerships-expand-vcf-9.1-capabilities?autoStart=true
- Broadcom News, "Broadcom Announces VMware Cloud Foundation 9.1, Enabling Secure and Cost-Effective Infrastructure for Production AI", 2026年5月5日公開、2026年6月11日確認
https://news.broadcom.com/releases/broadcom-announces-vmware-cloud-foundation-9-1
- VMware Cloud Foundation Blog, "Broadcom and Arista Networks Collaboration Offers a Unified Network Fabric for Private Cloud", 2026年5月5日公開、2026年6月11日確認
https://blogs.vmware.com/cloud-foundation/2026/05/05/announcing-evpn-interoperability-with-arista-networks-vcf-9-1/
- VMware Cloud Foundation Blog, "AI with VCF 9.1 on AMD GPUs: Build with open frameworks and simplify management, at a lower TCO", 2026年5月5日公開、2026年6月11日確認
https://blogs.vmware.com/cloud-foundation/2026/05/05/ai-with-vcf-9-1-on-amd-gpus-build-with-open-frameworks-and-simplify-management-at-a-lower-tco/
- Broadcom TechDocs, "VMware Cloud Foundation 9.1 Release Notes", 2026年6月11日確認
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/release-notes/vmware-cloud-foundation-9-1-0-0-release-notes.html