![\"Live](\"https://docs.armada.ai/assets/images/ai-grid-live-view-4a8140b82242764660967cc2757b55e2.png\")
\nLive view of AI GridReal-time AI is reshaping infrastructure requirements.
\nInference workloads such as conversational AI, real-time video generation, AR/XR streaming, visual search, and large-scale personalization demand ultra-low latency, predictable performance, and geographic proximity to users and data sources. Centralized AI factories remain essential for training, but for many AI-native services, inference at scale requires AI Grids: geographically distributed GPU infrastructure operating as a unified, policy-controlled system.
\nArmada is collaborating with NVIDIA to enable NVIDIA AI Grid on Armada Edge Platform (AEP), providing telecommunications operators, service providers, and enterprises with a validated architecture for deploying and operating distributed AI infrastructure at global scale.
\nThis post explores the architecture and operational model behind that system.
\nArmada Edge Platform is aligned with the NVIDIA AI Grid reference design and integrates with key NVIDIA technologies, including: NVIDIA RTX PRO Servers, NVIDIA HGX B200 systems, NVIDIA Spectrum-X Ethernet networking, NVIDIA BlueField DPUs, and NVIDIA AI Enterprise software.
\nTogether, these components form a distributed AI infrastructure stack designed for production-scale inference across centralized and edge environments.
\nWhere NVIDIA provides the accelerated compute, networking, and software stack, Armada provides the distributed control plane and operational layer required to manage this infrastructure coherently across thousands of locations.
\n\nLive view of AI Grid
Deploying GPUs at multiple sites is not equivalent to operating a distributed AI platform.
\nAI Grid deployments must support:
\nArmada Edge Platform provides a unified control plane spanning centralized AI factories, regional hubs, and edge locations.
\n![\"Monitoring](\"https://docs.armada.ai/assets/images/ai-grid-monitoring-3e1b1b01179ed605fd1fc0fd23d5a931.png\")
\nMonitoring and Observability for AI Grid
Rather than treating each GPU site as an isolated cluster, AEP stitches distributed GPU infrastructure into a single operational domain. This enables:
\nThe result is a globally distributed GPU fabric that behaves like a coherent platform.
\nAI inference workloads differ significantly from traditional cloud workloads. They are often latency-sensitive, data-locality constrained, burst-driven, GPU-intensive, and multi-tenant in nature.
\nAEP's orchestration layer evaluates placement decisions across multiple dimensions:
\nThis enables deterministic and optimized inference placement across distributed sites.
\nFor example, conversational AI workloads can be pinned close to users for minimal response time, while batch inference or less sensitive workloads can be placed in regional hubs or centralized AI factories, all under a single operational framework.
\n![\"Grid](\"https://docs.armada.ai/assets/images/ai-grid-capacity-ef32603dc4e1c3e48f65e7615d98b394.png\")
\nGrid Capacity and Composition
Each AI Grid location operates as a secure, multi-tenant environment.
\nArmada platform layer supports Bare metal provisioning, virtual machines, storage and networking services, managed Kubernetes, Model-as-a-Service, managed SLURM, Jupyter notebooks, and end-to-end ML workflows.
\nIsolation is enforced across CPU, GPU, network, and storage resources to ensure strong tenant separation, predictable performance, compliance alignment, and maximized GPU efficiency. This allows operators to safely expose distributed GPU capacity as monetizable services, including GPUaaS and inference platforms.
\nAI Grid performance depends not just on GPUs but on network architecture.
\nArmada Edge Platform integrates directly with the service provider's network layer to establish dedicated, policy-controlled connectivity from data sources to GPU workloads.
\nThis ensures predictable latency, secure data paths, traffic isolation, QoS enforcement, and end-to-end performance guarantees. By combining distributed GPU placement with network-aware orchestration, AI inference becomes a deterministic system rather than a best-effort deployment.
\n![\"AI](\"https://docs.armada.ai/assets/images/ai-grid-workload-allocation-c9110a9a0652a92694b401488d4e029f.png\")
\nAI Grid Workload Allocation
Distributed AI requires standardized infrastructure at the physical layer. AEP supports AI Grid across brick-and-mortar data centers as well as Armada's Galleon modular data centers when data centers are unavailable or can't be built rapidly enough.
\nGalleon, Armada's modular data center platform, provides a ruggedized, rapidly deployable, high-density AI infrastructure foundation for AI Grid deployments.
\nGalleon integrates Power systems, Cooling, Networking, Compute and Storage into a standardized, edge-ready form factor. This enables accelerated deployment timelines, consistent hardware profiles across sites, repeatable rollout models along with edge and remote environment operations.
\nWhen combined with AEP's control plane, Galleon allows operators to treat distributed AI infrastructure as a scalable system rather than a collection of bespoke deployments.
\n![\"AI](\"https://docs.armada.ai/assets/images/ai-grid-workload-allocation-2-883eb7307175e7458ea4aceb70ecee50.png\")
\nAI Grid workload allocation
The transition to AI Grids is not solely a technical evolution but it is an economic one.
\nTelecommunications operators and service providers can leverage distributed GPU infrastructure to:
\nArmada provides the operational layer that transforms geographically distributed GPU deployments into unified, revenue-generating AI platforms, including sovereign GPU cloud.
\n![\"AI](\"https://docs.armada.ai/assets/images/ai-grid-revenue-metrics-3b98664599331eaee9cc494c1ee8d7aa.png\")
\nAI Grid Revenue Metrics and Cost Optimization
By abstracting complexity across hardware, networking, orchestration, and lifecycle management, AEP enables operators to scale AI infrastructure from dozens to thousands of sites without multiplying operational overhead.
\nThe next phase of AI infrastructure is defined by distribution, orchestration intelligence, and operational consistency.
\nNVIDIA AI Grid provides the accelerated computing foundation. Armada provides the distributed control plane and a physical deployment model through its Galleon and AEP.
\nTogether, this architecture enables AI infrastructure that is geographically distributed, operationally unified, network-aware, secure and multi-tenant, and policy-driven that is scalable to thousands of locations.
\nFinally, distributed inference is no longer an edge experiment and has become core infrastructure. The AI Grid era is here, and it requires systems built to operate everywhere, as one.
\nTo learn more, schedule a demo.
", "url": "https://docs.armada.ai/bridge/blog/armada-nvidia-ai-grid", "title": "Operationalizing Distributed AI: Armada and NVIDIA AI Grid", "summary": "Real-time AI is reshaping infrastructure requirements.", "date_modified": "2026-03-17T00:00:00.000Z", "author": { "name": "Anish Swaminathan" }, "tags": [ "nvidia", "ai-grid", "distributed-ai", "inference", "edge", "orchestration" ] }, { "id": "https://docs.armada.ai/bridge/blog/nvidia-dsx-air", "content_html": "Armada has been an NVIDIA DSX Air user since late 2024, and we have derived significant benefits from its ability to simulate Spectrum-X Ethernet environments for both internal development and customer proof-of-concept initiatives. NVIDIA DSX Air has enabled us to validate networking configurations and topologies, test multi-tenant configurations, and accelerate Bridge software deployments (Bridge is an on-prem Armada software product that provides multi-tenancy and cloud services on GPU hardware) without relying exclusively on physical hardware.
\nWe are excited about the launch of NVIDIA DSX Air and the expanded AI Factory digital simulation capabilities it introduces. This next evolution unlocks multiple use cases for Armada and our customers — driving measurable improvements across development velocity, PoC efficiency, operational stability, OPEX reductions and go-to-market. The key benefits are described below.
\nIf you're building GPU cloud management software like Bridge, you are constantly running into hardware constraints. Testing against large-scale topologies, DPUs and advanced NVLink fabrics, as well as next-gen GPUs isn't trivial.
\nWith NVIDIA DSX Air, we can simulate full AI Factory environments — including GPUs, NVLink, Spectrum-X Ethernet switches, ConnectX SuperNICs, and BlueField DPUs — while continuing to validate against physical production-grade clusters.
\nThat means:
\nFor Bridge, this translates to faster releases, better validation, and stronger resiliency. Simulation accelerates validation, while hardware testing ensures production-grade performance and interoperability.
\nWith the advent of AI Grid, NVIDIA DSX Air will become even more valuable. We will be able to simulate multiple edge sites and rapidly develop our policy-based application placement capabilities.
\nToday, most AI factory or multi-tenancy PoCs depend on real infrastructure. That slows everything down:
\nNVIDIA DSX Air breaks that dependency. Armada can provision simulated AI factory environments where customers can evaluate Bridge and its numerous capabilities:
\nThis allows early-stage validation without waiting on hardware availability, compressing PoC timelines from months to weeks — before transitioning to hardware-based validation with greater confidence. That shortens sales cycles for us. More importantly, it lowers psychological friction. When customers can \"try before they rack,\" adoption accelerates. Once this phase completes, the customer can ultimately move to a hardware based PoC.
\nThis is where the long-term value resides. Bridge customers operating AI factories at scale deal with:
\nMaking changes in production is risky. With NVIDIA DSX Air, customers can build a high-fidelity digital twin of their environment and:
\nNVIDIA DSX Air features extensibility, which will allow us to model our modular datacenters branded Galleon. With Galleon modeling, we will be able to use our datacenter infrastructure management software to simulate actions such as changing chillers on the digital twin before applying the same action to the physical environment.
\nInstead of configure and hope, customers can simulate and verify. For brownfield environments especially — where some multi-tenancy rules were implemented manually — this reduces the fear of Bridge \"messing up\" existing configurations. Customers can easily reduce costly configuration errors that can result in six-figure downtime events.
\nOperational risk is one of the biggest hidden OPEX drivers in AI infrastructure. Digital twins reduce that risk.
\nThe NVIDIA DSX Air blueprint marketplace introduces another dimension. Bridge based pre-built blueprints will be instantiated within the NVIDIA DSX Air environment; customers can experience our value immediately at a fraction of the cost compared to the hardware — integrated with simulated GPU, networking, storage, and security stacks. Now we go beyond simulation to becoming discoverable.
\nIt positions Bridge inside the AI factory design phase — not after hardware has already been deployed.
\nFor Bridge, NVIDIA DSX Air unlocks:
\nAI factories are the future of infrastructure, and high-fidelity digital twins will become standard practice. And Bridge will be native to that future — not bolted on after the racks are live.
", "url": "https://docs.armada.ai/bridge/blog/nvidia-dsx-air", "title": "How NVIDIA DSX Air Reduces Dev/Test Costs, Accelerates PoCs, and Lowers Production Risk for Armada and Its Customers", "summary": "Armada has been an NVIDIA DSX Air user since late 2024, and we have derived significant benefits from its ability to simulate Spectrum-X Ethernet environments for both internal development and customer proof-of-concept initiatives. NVIDIA DSX Air has enabled us to validate networking configurations and topologies, test multi-tenant configurations, and accelerate Bridge software deployments (Bridge is an on-prem Armada software product that provides multi-tenancy and cloud services on GPU hardware) without relying exclusively on physical hardware.", "date_modified": "2026-03-16T00:00:00.000Z", "author": { "name": "Pavan Samudrala" }, "tags": [ "nvidia", "dsx-air", "simulation", "digital-twin", "ai-factory", "spectrum-x" ] }, { "id": "https://docs.armada.ai/bridge/blog/distributed-ai-edge", "content_html": "All AI is not created equal. While centralized inference serves some use-cases well where long thinking times are acceptable, new use cases such as physical AI, real-time agentic AI chatbots, digital avatars doing real time dialog, and computer vision require faster response times. It is not just about network latency, but compute latency becomes important, mandating computation closer to data sources, and lower bandwidth usage across the network in order to scale cost effectively.
\nThese applications can't tolerate the latency of round trips to centralized data centers nor can they afford the cost of constantly transferring large volumes of data. Instead, they require inference that is geographically distributed, dynamically orchestrated, and tightly optimized for latency and bandwidth.
\nThis is fueling a surge in demand for distributed inference infrastructure—capable of running AI models across clusters of GPUs residing at regional data centers and edge sites, while maintaining cloud-like flexibility and scale. The distributed inference market is poised for exceptional growth between 2025 and 2030, with projections indicating an expansion from USD 106.15 billion to USD 254.98 billion at a CAGR of 19.2%.
\nNVIDIA MGX servers, based on a modular reference design, can be used for a wide variety of use cases, from compute-intensive datacenter to edge workloads. MGX provides a new standard for modular server design by improving ROI and reducing time to market and is especially suited to distributed inference. Some of the reasons for this are:
\nWhen combined with NVIDIA Spectrum-X Ethernet networking platform for AI, customers can extract the full performance of the underlying GPUs.
\nWhile MGX servers along with Spectrum-X and NVIDIA AI Enterprise offer an integrated solution stack, distributed inference presents a number of infrastructure challenges for a GPU-as-a-Service (GPUaaS) provider:
\nThe above challenges require a secure and dynamic tenancy software layer for distributed inference. The ideal software solution must offer:
\nBridge GPU CMS provides the following functionality:
\nBridge GPU CMS when coupled with NVIDIA MGX, Spectrum-X, and NVIDIA AI Enterprise solves the above-listed problems for GPUaaS providers. The components for this architecture are:
\nThe infrastructure is installed at the distributed edge-core locations, along with other software components including Bridge GPU CMS, and all the hardware related tests are performed, before onboarding the resources.
\nOnce this is completed, the site administrator discovers the infrastructure using Bridge GPU CMS, and creates the underlay network using the Spectrum switches and the network adapters or DPUs on the MGX servers. The Admin then goes on to create tenants, which are the logical entities that run different types of workloads on the same physical infrastructure.
\nThe important consideration while allocating these resources is that they need to be fully isolated, so that each tenant's workload can run without any performance or security implication from other tenants. Bridge GPU CMS ensures this by providing hard multi-tenancy at all levels - CPU, GPU, memory, network adapters, network switches, internal and external storage, all the way to the external gateway.
\nThe next wave of AI adoption depends on pushing inference closer to where data is generated—at the edge. Achieving this requires more than raw compute; it calls for an architecture that delivers secure multi-tenancy, dynamic scaling, high utilization, and seamless integration with cloud-native AI services.
\nNVIDIA MGX servers, combined with Spectrum-X networking and NVIDIA AI Enterprise, provide the performance and flexibility needed for distributed Edge deployments. Layered with Bridge GPU Cloud Management Software, organizations gain the management and orchestration capabilities essential for turning this distributed infrastructure into a scalable, revenue-generating service.
\nThe opportunity is clear: distributed inference is becoming central to how next-generation AI will be delivered. Now is the time to explore, pilot, and engage to unlock these capabilities and be part of the ecosystem shaping the future of AI at the edge.
", "url": "https://docs.armada.ai/bridge/blog/distributed-ai-edge", "title": "Delivering Distributed AI at the Edge with Bridge", "summary": "All AI is not created equal. While centralized inference serves some use-cases well where long thinking times are acceptable, new use cases such as physical AI, real-time agentic AI chatbots, digital avatars doing real time dialog, and computer vision require faster response times. It is not just about network latency, but compute latency becomes important, mandating computation closer to data sources, and lower bandwidth usage across the network in order to scale cost effectively.", "date_modified": "2025-09-02T00:00:00.000Z", "author": { "name": "Amar Kapadia" }, "tags": [ "edge", "distributed-ai", "inference", "nvidia-mgx" ] }, { "id": "https://docs.armada.ai/bridge/blog/nvis-topology-onboarding", "content_html": "We recently collaborated with the NVIDIA Infrastructure Specialist (NVIS) team to onboard and validate a complex metadata topology deployed by NVIS into our Bridge GPU Cloud Management Software (CMS). This activity demonstrates how Bridge GPU CMS can take over an NVIS deployed GPU topology and then perform day 1, 2 activities such as discovery, dynamic multi-tenancy, observability, fault management, and more.
\nThe initial deployment and configuration of GPU hardware for NVIDIA Cloud Partners (NCPs) and subsequent management is often done by different entities. Case in point, Day 0 tasks for NCP GPU environments are often performed by NVIS. After NVIS hands over the cluster to the NCP effectively with one single tenant, the task of multi-tenancy and other Day 1, 2 tasks can be performed by Bridge GPU CMS.
\nIn other words, there is a hand-off from an NVIS deployed topology to our GPU CMS. NCPs and GPU-as-a-service providers needed a robust and automated method to:
\nWe validated the successful hand-off of a 16 SU topology deployed by NVIS to Bridge GPU CMS. This validation was performed on NVIDIA Air.
\nBy automating and validating the metadata topology through Bridge GPU CMS, the NCPs can achieve:
\nThis use case illustrates how Bridge GPU CMS can successfully onboard a GPU topology deployed by NVIS. This validation is very important for NCPs as they require a clean hand-off between Day 0 to Day 1,2 activities without any disruptions.
", "url": "https://docs.armada.ai/bridge/blog/nvis-topology-onboarding", "title": "Onboarding NVIDIA NVIS Deployed GPU Topology with Bridge GPU CMS", "summary": "We recently collaborated with the NVIDIA Infrastructure Specialist (NVIS) team to onboard and validate a complex metadata topology deployed by NVIS into our Bridge GPU Cloud Management Software (CMS). This activity demonstrates how Bridge GPU CMS can take over an NVIS deployed GPU topology and then perform day 1, 2 activities such as discovery, dynamic multi-tenancy, observability, fault management, and more.", "date_modified": "2025-07-02T00:00:00.000Z", "author": { "name": "Namachi Sankaranarayanan" }, "tags": [ "nvidia", "nvis", "topology", "onboarding" ] }, { "id": "https://docs.armada.ai/bridge/blog/ddn-exascaler-integration", "content_html": "Managing external storage for GPU-accelerated AI workloads can be complex—especially when ensuring that storage volumes are provisioned correctly, isolated per tenant, and automatically mounted to the right compute nodes. With Bridge GPU Cloud Management Software (GPU CMS), this entire process is streamlined through seamless integration with DDN EXAScaler.
\nWith Bridge GPU CMS, end users don't need to manually log into multiple systems, configure storage mounts, or worry about compatibility between compute and storage. The DDN EXAScaler integration is fully automated—allowing users to simply specify:
\nEverything else—from tenant-aware provisioning, storage policy enforcement, network isolation, to automatic mount point creation—is handled seamlessly by Bridge GPU CMS.
\nThe process starts with the NCP admin (cloud provider admin) importing the entire GPU infrastructure (compute, storage, E-W network, N-S network) into the software and setting up a new tenant. Once the tenant is created, the tenant user can allocate a GPU bare-metal or VM instance and request external storage from DDN.
\nThe tenant simply provides:
\nOnce these inputs are provided, Bridge GPU CMS handles all interactions with DDN, including:
\nThis zero-touch integration eliminates any need for the tenant to interact with the DDN portal directly.
\nTo ensure transparency and operational assurance, the NCP admin or tenant admin can view all configured storage volumes directly within Bridge GPU CMS. For additional verification, they can also cross-check the automatically created tenants, networks, policies, and mount points directly in the DDN admin portal.
\nAll configurations are performed via APIs with no manual intervention.
\nOnce the storage is provisioned, the tenant user can log directly into their allocated GPU compute node and immediately access the mounted DDN EXAScaler storage volume. Whether for large-scale AI training data or model checkpoints or inference, this automated mount ensures data is available where and when the user needs it.
\nManaging network isolation in AI cloud environments is critical for ensuring tenant data security, performance consistency, and compliance. This becomes even more important in high-performance AI clusters that rely on InfiniBand fabric for ultra-low latency communication between GPU nodes.
\nWith Bridge GPU Cloud Management Software (GPU CMS), cloud providers can achieve complete InfiniBand network isolation for every tenant—all through an automated, policy-driven process. This ensures each tenant's data and traffic are fully segregated, with no manual intervention required.
\nBridge GPU CMS achieves end-to-end isolation on InfiniBand fabrics by integrating seamlessly with NVIDIA UFM (Unified Fabric Manager). This allows for:
\nThis policy-based automation eliminates manual errors, guarantees secure isolation across the entire InfiniBand fabric, and ensures each tenant receives a fully segregated high-performance network.
\nAll discovery, tenant creation, and isolation enforcement actions are fully visible within Bridge GPU CMS Admin Portal. Both NCP admins (cloud provider admins) and tenant admins can track:
\nThis centralized visibility ensures operational transparency and gives cloud providers the tools they need to enforce multi-tenant isolation at scale.
\nWhile this blog focuses on InfiniBand isolation, Bridge GPU CMS also supports Ethernet network isolation, including full integration with NVIDIA Spectrum-X switches. Whether using Ethernet, InfiniBand, or a combination of both, Bridge GPU CMS ensures complete network separation between tenants—across both the control plane and data plane.
", "url": "https://docs.armada.ai/bridge/blog/infiniband-network-isolation", "title": "Automated InfiniBand Network Isolation with Bridge GPU CMS", "summary": "Managing network isolation in AI cloud environments is critical for ensuring tenant data security, performance consistency, and compliance. This becomes even more important in high-performance AI clusters that rely on InfiniBand fabric for ultra-low latency communication between GPU nodes.", "date_modified": "2025-03-07T00:00:00.000Z", "author": { "name": "Raghuram Gopalshetty" }, "tags": [ "networking", "infiniband", "isolation", "multi-tenancy" ] }, { "id": "https://docs.armada.ai/bridge/blog/vast-storage-integration", "content_html": "Managing external storage for GPU-accelerated AI workloads can be complex—especially when ensuring that storage volumes are provisioned correctly, isolated per tenant, and automatically mounted to the right compute nodes. With Bridge GPU Cloud Management Software (GPU CMS), this entire process is streamlined through seamless integration with VAST external storage systems.
\nWith Bridge GPU CMS, end users don't need to manually log into multiple systems, configure storage mounts, or worry about compatibility between compute and storage. The VAST integration is fully automated—allowing users to simply specify:
\nEverything else—from tenant-aware provisioning to storage policy enforcement and automatic mount point creation—is handled seamlessly by Bridge GPU CMS in the background.
\nThe process starts with the NCP admin (cloud provider admin) importing the compute node into the system and setting up a new tenant. Once the tenant is onboarded, the tenant user can allocate a GPU bare-metal instance and request external storage from VAST.
\nThe tenant simply provides:
\nOnce these inputs are provided, Bridge GPU CMS handles all interactions with VAST, including:
\nThis zero-touch integration eliminates any need for the tenant to interact with the VAST portal directly.
\nTo ensure transparency and operational assurance, the NCP admin or tenant admin can view all configured storage volumes directly within Bridge GPU CMS. For additional verification, they can also cross-check the automatically created tenants, networks, policies, and mount points directly in the VAST admin portal.
\nThis two-way visibility ensures that:
\nOnce the storage is provisioned, the tenant user can log directly into their allocated GPU compute node and immediately access the mounted VAST storage volume. Whether for large-scale AI training data or model checkpoints, this automated mount ensures data is available where and when the user needs it.
\nTo further validate, the tenant can create and save files to the external storage—confirming that the VAST integration is complete and the storage is fully accessible from their compute instance.
\nThe latest Bridge GPU CMS announces network automation, observability, fault management, and multi-tenancy for the v1.3 NVIDIA Spectrum-X Reference Architecture (RA). The Reference Architecture defines an East-West compute network fabric optimized for AI cloud deployments with HGX systems and a North-South converged network for external access, storage, and control plane traffic.
\nAs part of this announcement, Bridge supports NVIDIA Spectrum-4 SN5000 Series Ethernet switches, NVIDIA Cumulus Linux, NVIDIA BlueField-3 SuperNICs and DPUs, NVIDIA NetQ AI observability and telemetry platform, and NVIDIA Air data center digital twin platform along with NVIDIA HGX H100/H200 nodes.
\nNVIDIA Cloud Partner (NCP) and enterprise AI clouds must provide hard isolation between tenants. Bridge GPU CMS addresses this comprehensively across seven pillars:
\nBy enforcing isolation and performance in each pillar, we ensure tenants can run demanding AI workloads securely and without compromising the performance on shared hardware.
\nA modern GPU data center switch fabric typically comprises multiple segmented networks—most notably the East-West (Compute) network and the North-South (Converged) network. The North-South network itself includes Inband management, Storage, and External/Tenant access.
\nA single Scalable Unit (SU)—as defined by NVIDIA Spectrum-X Reference Architectures—contains:
\nThis topology serves just 256 GPUs, highlighting the operational complexity and scale. Without automation, managing such fabrics—especially across multiple SUs—becomes impractical and error-prone.
\nBridge CMS addresses this challenge by offering:
\nBridge GPU CMS automates all the tasks needed to turn a BlueField-3 equipped server into a Spectrum-X host. When a new host is provisioned, the GPU CMS:
\nThis makes the host fully Spectrum-X aware — ready to participate in high-performance GPU-to-GPU networking, where the multi-tenancy relies on BGP EVPN from Cumulus and Spectrum-X switches.
\nBridge GPU CMS creates tenant isolated overlay networks on the ethernet switch fabric using VxLAN and VRF with BGP as the control plane. From the end-user perspective, the GPU CMS provides the ability to define Virtual Private Clouds (VPCs) with multiple subnets, much like a traditional public cloud.
\nBehind the scenes, each VPC is backed by an isolated VRF (Virtual Routing and Forwarding) and each subnet corresponds to a unique VxLAN segment.
\nThis abstraction gives users the flexibility to:
\nTo support multiple tenants securely and efficiently on the same physical fabric, Bridge GPU CMS uses VxLAN (Virtual Extensible LAN) in combination with VRF (Virtual Routing and Forwarding) constructs. This ensures complete L2/L3 network isolation across tenants.
\nEach tenant's workloads operate within a dedicated overlay network, backed by a separate VRF instance, enabling traffic segmentation, independent routing policies, and security boundaries, without sacrificing performance.
\nBridge GPU CMS supports both NetQ and OTLP based telemetry for NVIDIA Spectrum-X switches.
\nSwitch Telemetry via Cumulus NVUE:
\nSuperNIC Telemetry via DOCA DTS:
\nInfrastructure administrators can subscribe to NetQ events directly from the GPU CMS. When subscribed events are triggered, Bridge GPU CMS invokes its own remediation logic to auto-correct faults without manual intervention, helping customers with dramatic OPEX reduction.
\nThe CMS subscribes to the following fault scenarios from NetQ:
\nBridge GPU CMS integration with Spectrum-X is extensively validated on NVIDIA Air (data center digital twin), enabling realistic simulation and demonstration of features in a virtual environment.
\nOur platform is already being used by NCPs in multiple regions along with Spectrum-X. For example, a leading Southeast Asian telecom operator is deploying an AI compute grid for distributed inference. Similarly, a top U.S. NCP is building an AI-and-RAN edge platform with multi-tenancy support for multiple use cases or customers.
", "url": "https://docs.armada.ai/bridge/blog/spectrum-x-validation", "title": "Bridge GPU CMS Announces Network Automation and Multi-Tenancy for NVIDIA Spectrum-X", "summary": "The latest Bridge GPU CMS announces network automation, observability, fault management, and multi-tenancy for the v1.3 NVIDIA Spectrum-X Reference Architecture (RA). The Reference Architecture defines an East-West compute network fabric optimized for AI cloud deployments with HGX systems and a North-South converged network for external access, storage, and control plane traffic.", "date_modified": "2025-01-15T00:00:00.000Z", "author": { "name": "Sriram Rupanagunta" }, "tags": [ "networking", "spectrum-x", "nvidia", "multi-tenancy", "automation" ] }, { "id": "https://docs.armada.ai/bridge/blog/nvidia-bluefield-rtx-pro-integration", "content_html": "As organizations continue to build AI factories capable of handling massive-scale inference and data processing, one challenge looms large: how to deliver secure, multi-tenant infrastructure that keeps GPUs fully utilized without adding operational complexity.
\nAt Armada, we're solving that challenge head-on. Bridge product now integrates with NVIDIA BlueField-3 data processing units (DPUs) and NVIDIA RTX PRO Servers featuring NVIDIA RTX PRO 6000 Blackwell Server Edition GPUs — creating an end-to-end foundation for high-performance, automated AI infrastructure.
\nGPU infrastructure deployed manually could result in inefficiency, underutilization, and data exposure. With Bridge, enterprises can automate the entire lifecycle of GPU infrastructure while enabling secure multi-tenancy across compute, storage, and networking layers.
\nBy leveraging NVIDIA BlueField DPUs, network, storage and security workloads for AI infrastructure are offloaded from host CPUs, freeing up valuable compute cycles for business applications. Further, BlueField-accelerated data movement and zero trust security result in faster inference, stronger isolation, and more predictable performance for every AI workload.
\nBridge integrates with NVIDIA RTX PRO Servers and NVIDIA BlueField DPUs to power fully automated AI Factories.
\nKey capabilities include:
\nTogether, these features enable enterprises to deploy secure, high-performance AI environments faster — maximizing GPU efficiency while reducing operational overhead.
\nArmada continues to expand Bridge to leverage additional capabilities of the BlueField. Upcoming features include:
\nThe journey doesn't stop here. With NVIDIA BlueField-4 on the horizon — offering 6X the compute power of NVIDIA BlueField-3 and 800 Gb/s throughput — Bridge will extend its capabilities even further.
\nThese innovations will enable AI factories to handle gigascale workloads while maintaining tight isolation, blazing-fast data access, and best-in-class security.
\nAs enterprises evolve from AI pilots to full-scale production, they need infrastructure that's not only powerful — but programmable, secure, and efficient. The integration of Bridge with NVIDIA RTX PRO Servers and NVIDIA BlueField DPUs represents a major step toward that future.
\nWe're excited to help our customers build the world's most efficient and secure AI factories — one GPU at a time.
", "url": "https://docs.armada.ai/bridge/blog/nvidia-bluefield-rtx-pro-integration", "title": "Armada Powering the Next Generation of Secure, Multi-Tenant AI Factories", "summary": "As organizations continue to build AI factories capable of handling massive-scale inference and data processing, one challenge looms large: how to deliver secure, multi-tenant infrastructure that keeps GPUs fully utilized without adding operational complexity.", "date_modified": "2024-12-15T00:00:00.000Z", "author": { "name": "Amar Kapadia" }, "tags": [ "nvidia", "bluefield", "dpu", "rtx-pro", "multi-tenancy", "ai-factory", "automation" ] }, { "id": "https://docs.armada.ai/bridge/blog/soft-isolation-risks", "content_html": "Relying solely on Kubernetes Namespaces or vClusters for multi-tenant isolation in GPU clouds is risky — especially when hosting untrusted or external workloads.
\nIn September 2024, Wiz discovered a critical NVIDIA Container Toolkit vulnerability (CVE-2024-0132) that allowed GPU containers to escape soft isolation and gain root access to the host. This flaw impacted over one-third of GPU-enabled environments and exposed the limits of Kubernetes-based isolation.
\nSoft isolation is not secure isolation. For environments like Neoclouds, NVIDIA Cloud Partners (NCPs), or regulated industries, only hard or hybrid isolation strategies — such as dedicated Kubernetes clusters, MIG-based GPU partitioning, VPCs, VxLAN, VRFs, KVM virtualization, IB P-KEY, and NVLink partitioning — can protect against container escapes.
\nWhen building a multi-tenant GPU cloud, it's common to rely on Kubernetes-native tools like Namespaces or vClusters for tenant isolation. This \"soft isolation\" approach offers ease of deployment and simplicity — but it carries serious security risks in GPU-accelerated environments.
\nSoft isolation assumes that tenants can safely share the same Kubernetes control plane, node kernel, and container runtime. But when it comes to multi-tenant GPU workloads, this assumption breaks down fast — and can open the door to container escapes, privilege escalation, and cross-tenant compromise.
\nThis isn't just theoretical.
\nIn September 2024, security researchers at Wiz discovered a critical vulnerability — CVE-2024-0132 — in the NVIDIA Container Toolkit (v1.16.1 and earlier), a core component used to enable GPU access for Docker, containerd, and CRI-O containers.
\nHere's what went wrong:
\nThe vulnerability was widespread. Wiz estimated that over one-third of cloud GPU environments — across AWS, Azure, GCP, and on-prem systems — were running the vulnerable software. Kubernetes clusters using the NVIDIA GPU Operator v24.6.1 and earlier were especially affected.
\nCritically, this vulnerability bypassed all protections offered by Kubernetes Namespaces or vClusters. Even if workloads were logically isolated at the K8s level, any tenant with the ability to run a malicious GPU container could break out and attack the host.
\nThis incident underscores a hard truth: soft isolation is not sufficient in environments where untrusted or external tenants run GPU workloads. Kubernetes Namespaces and vClusters only provide logical segmentation — they don't protect against kernel-level or runtime-level exploits.
\nFor Neoclouds, NVIDIA Cloud Partners (NCPs), or regulated enterprises, soft isolation leaves the door wide open. A single misconfigured container or a compromised customer workload could escalate into a full infrastructure breach.
\nTo protect against these risks, multi-tenant GPU clouds must adopt hard or hybrid isolation, including:
\nAdditionally, any GPU cloud environment should now be running the latest version of NVIDIA Container Toolkit and GPU Operator.
\nWhile deploying a dedicated, multi-node Kubernetes cluster is the gold standard for large production tenants, this model is not always cost-effective for smaller teams, university labs, or development workloads. To address this, lightweight, dedicated Kubernetes clusters using efficient, fully compliant distributions like K3s or MicroK8s could also be considered. These clusters are deployed within a single virtual machine, providing a complete, self-contained environment with its own dedicated kernel and control plane, while physical GPUs are attached via passthrough.
\nSoft isolation is fine — until it isn't. In GPU-accelerated environments, especially those involving multi-tenancy, the risks are too high to depend solely on Kubernetes constructs like Namespaces or vClusters.
\nReal-world vulnerabilities like CVE-2024-0132 show that container escapes are not just possible — they're happening. If you're serving customers, partners, or even internal departments with access to GPU workloads, you need real, infrastructure-level isolation.
\nThe good news? With tools like Bridge GPU CMS, you can build secure, tenant-isolated GPU clouds that automatically configure isolation across compute, storage, networking, VPC, NVLink, InfiniBand, and GPUs — without taking on all the complexity yourself.
", "url": "https://docs.armada.ai/bridge/blog/soft-isolation-risks", "title": "The Hidden Risks of Soft Isolation in Multi-Tenant GPU Clouds", "summary": "Relying solely on Kubernetes Namespaces or vClusters for multi-tenant isolation in GPU clouds is risky — especially when hosting untrusted or external workloads.", "date_modified": "2024-10-15T00:00:00.000Z", "author": { "name": "Amar Kapadia" }, "tags": [ "security", "isolation", "multi-tenancy", "kubernetes" ] } ] }