How Bridge by Armada Integrates NVIDIA Infra Controller (NICo)

Turning Bare Metal into Tenant-Ready AI Infrastructure

Introduction

Modern AI infrastructure demands more than raw GPU horsepower. Getting hundreds — or thousands — of GPUs from freshly racked-and-stacked to a fully operational, multi-tenant AI cluster requires a sophisticated orchestration layer that spans hardware discovery, network fabric programming, firmware validation, and tenant isolation. With newer generations of rack-scale AI supercomputer products such as NVL72, the provisioning, configuration, and management challenges have become extremely complex.

That is exactly what Bridge by Armada, by incorporating the open-source NVIDIA NICo project (NVIDIA Infra Controller, formerly Carbide), delivers.

NICo is NVIDIA's Bare Metal Manager (BMM) open source project — a purpose-built controller that speaks native hardware languages: Redfish for BMC management, InfiniBand Partition Keys for GPU-fabric isolation, DPU-native networking primitives for multi-tenant overlays, and NVLink configuration and partitioning.

Bridge is Armada's GPUaaS management platform — the control plane that exposes GPU compute as a service to tenants through a unified API, handling VPCs, IaaS (bare metal, VM, storage, VPC, security groups), PaaS (managed Kubernetes), and AI model, application, and platform orchestration (Slurm, Token Factory, Jupyter Notebooks, MLOps, and a number of third-party commercial ISV products) along with billing.

Together, the layers form a clean separation of concerns: NICo owns the physical layer; the rest of Bridge owns the service layer. This post explains how the two systems integrate, why the boundary is drawn where it is, and how the combined architecture makes zero-touch cluster bring-up and tenant provisioning possible at scale. Bridge also takes care of supporting this across heterogeneous server platforms (well beyond just NVL72) and GPU families, and continues to enhance the support matrix.

Architecture Overview: Who Owns What

The integration follows a strict separation-of-concerns model. Neither system reaches across the boundary uninvited — all cross-system operations flow through well-defined handoff contracts.

Bridge Network Controller	NVIDIA NICo
Before provisioning: Spectrum-X spine/leaf BGP underlay; leaf → DPU port configuration	Hardware discovery: Scout + Redfish — GPU, NIC, IB GUID, TPM enumeration; host + DPU pairing via BMC serial matching
After provisioning (SDN): OVS switches for VM traffic flows	DPU multi-tenant networking: BGP extension, VXLAN/EVPN overlay, NSG/ACL; IP allocation (/31 linknets, /32 IPs), DHCP on DPU
Management hosts: IP management + VLAN for non-DPU resources	InfiniBand & NVLink fabric: IbFabricMonitor, IbPartition lifecycle, NVSwitch management

What NICo Brings to the Table

NICo is purpose-built for GPU cluster management. It was designed from the ground up to handle the unique challenges of large-scale GPU deployments — challenges that generic bare-metal managers simply were not designed for.

Hardware Discovery via Redfish

At the heart of NICo's discovery capability is its Scout agent, which combines NVIDIA's discovery tooling with standard DMTF Redfish APIs to perform a deep inventory of every node in the cluster. This is not a simple ping-and-enumerate operation — NICo discovers:

• GPU device identity and health state
• Network Interface Card (NIC) configuration and InfiniBand GUIDs
• TPM modules for hardware root-of-trust attestation
• DPU presence and pairing with host BMC via serial number matching
• DPU configuration via the DPU BMC port

The Redfish integration is key here. Because iDRAC (Dell), iLO (HPE), and servers from Cisco, Supermicro, Lenovo, and others all expose standard Redfish endpoints, NICo can manage heterogeneous hardware fleets without vendor-specific plugins. Every server gets a stable hardware identity that persists across reboots and reprovisioning events.

DPU-Native Multi-Tenant Networking

One of NICo's most powerful capabilities is its use of BlueField DPUs to implement multi-tenant network isolation entirely in the data plane, without touching the host operating system. It is worth noting that this can be accomplished by directly working with Spectrum-X switches, but the DPU-based implementation helps when Spectrum-X based network isolation is not possible due to root permission concerns on the switch.

For each tenant, NICo programs:

• BGP extension — BGP peering between DPU and leaf switch using eBGP, establishing a per-tenant routing domain
• VXLAN/EVPN overlay — VPC-level isolation using VLAN-VNI and L3VNI, giving each tenant a private network address space
• NSG / ACL enforcement — security group rules applied per representor port on the DPU; traffic is filtered before it ever reaches the host
• DHCP + metadata — per-host DHCP and metadata services served from the DPU itself, eliminating a centralized DHCP dependency

This architecture means that tenant network configuration is enforced in hardware, not software, and that a misconfigured or compromised host OS cannot bypass network security policies.

InfiniBand Fabric Lifecycle Management

For GPU-to-GPU communication — the performance-critical east-west traffic of distributed training workloads — NICo manages the InfiniBand fabric through deep UFM integration:

• IbFabricMonitor runs continuously, enforcing PKey (partition key) bindings and detecting fabric anomalies in real time
• IbPartition lifecycle manages the full lifecycle of IB partitions: PKey pool allocation, GUID-to-PKey mapping, and security posture enforcement

NVLink Fabric Lifecycle Management

For that same performance-critical east-west traffic, NICo manages the NVLink fabric through Fabric Manager integration:

• NVSwitch management handles intra-node NVLink switching for NVL72 GPU groups, enabling full-bandwidth GPU mesh connectivity within a server

What the Rest of Bridge Adds on Top

While NICo handles the physical and network layer, the other layers of Bridge provide the service abstraction that transforms raw hardware into a cloud-grade platform. Bridge exposes GPU compute through five delivery models:

Model	Description
BMaaS	Bare Metal as a Service — tenant gets exclusive access to full GPU nodes, provisioned via iPXE into their chosen OS
VMaaS	Virtual Machines — GPU-passthrough VMs with tenant-managed lifecycle, using OVS-based networking
CaaS	Containers as a Service — Kubernetes clusters with GPU device plugins, CSI storage, and multi-tenant namespace isolation
AIaaS / Token Factory	Model as a service, fine-tuning, and the ability to deploy Jupyter Notebook instances to tenants, along with token-based billing
Managed Slurm	HPC job scheduling — Slurm clusters managed by Bridge, supporting distributed training and batch inference workloads

The Integration: How Discovery Works

Before a single tenant can be served, Bridge uses NICo to discover and inventory the entire cluster. This four-stage process is fully automated — no manual inventory entry is required.

1. Prepare the network fabric (Owner: Bridge Network Controller) Bridge scans and identifies all spine and leaf switches, brings up BGP routing across the full switch fabric, configures switch ports facing server DPUs, and sets up the ADMIN management overlay. Once complete, DPUs can communicate, and the next step is unblocked.

2. Connect management nodes (Owner: Bridge Network Controller) Bridge joins the NICo API node to the ADMIN overlay, assigns IPs to all management infrastructure, and verifies reachability before proceeding. Only when NICo's API is confirmed reachable does the process advance.

3. Discover all hardware (Owner: NICo) NICo provisions DPUs over the OOB management network, boots servers into a lightweight discovery image, and enumerates CPUs, GPUs, NICs, InfiniBand topology, and NVLink connectivity. Each server receives a stable hardware identity that persists through its lifecycle.

4. Sync to Bridge inventory (Owner: NICo → Bridge) NICo pushes the complete hardware inventory to Bridge's database. Server records, IP allocations, and IB partition assignments are all synchronized. Servers are tagged with flavor metadata (NVLink-capable vs. standard) and appear as available in the Bridge UI.

Three principles govern this process:

• Fully automated — hardware registers itself; no manual inventory entry
• Gated and safe — each step only proceeds when the previous is confirmed complete
• Single source of truth — NICo is the authoritative inventory; Bridge reads from NICo

Tenant Provisioning: From Zero to GPU-Ready in Five Steps

Once discovery is complete, the cluster is ready to accept tenants. The end-to-end provisioning flow — from creating a tenant account to having a fully isolated, GPU-ready environment — proceeds through five well-defined stages, each with a clear owner.

Step 1 — Create tenant (Bridge → NICo)

• Bridge auth creates an organization in Keycloak (identity provider)
• Bridge Orchestrator registers the tenant in NICo
• SSH keysets are established for the tenant
• A shared Tenant ID becomes the reference for all subsequent operations

✓ Tenant exists in both databases with consistent identity

Step 2 — Define networks (Bridge → NICo)

• Bridge Orchestrator creates a VPC in NICo
• NICo creates VLAN + VNI intent for the tenant's network segment
• IB partition intent is created for GPU compute fabrics
• NV partition intent is created for NVL72 GPU groups

✓ Isolated network and GPU fabric are ready before any server is allocated

Step 3 — Allocate server (Bridge Orchestrator)

• Orchestrator calls the NICo AllocateInstance API
• NICo switches the DPU from admin network to tenant network
• DPU agent applies VXLAN, VRFs, ACLs, IB, and NVLink configuration (reconciling all intents)
• Host reboots into tenant OS via iPXE

✓ Server is provisioned and tenant-ready with full network and GPU fabric isolation

Step 4 — Steady state (both systems)

• NICo DPU health and config reconciliation loop runs continuously
• NICo IB fabric monitor enforces partition state and detects anomalies
• Bridge NC monitors switch fabric health and gateway operations
• Both systems generate alerts on degradation or misconfiguration

✓ Platform stays healthy automatically — no manual intervention required

Step 5 — Release server (Bridge → NICo)

• Orchestrator calls the NICo ReleaseInstance API
• DPU switches back to admin network, wiping tenant configuration
• IB GUIDs are unbound and IB/IP segments are released
• Bridge NC cleans up gateway and load balancer rules

✓ Server is returned to the available pool, cryptographically clean and ready for the next tenant

Why This Integration Matters for AI Infrastructure

Redfish as the universal management plane

One of the most important design decisions in the Bridge/NICo integration is the choice to use standard Redfish APIs for hardware management. Because Redfish is a DMTF-standardized protocol supported across server vendors, Bridge and NICo can manage heterogeneous fleets without vendor lock-in.

DPU offload changes the security model

Traditional multi-tenancy enforces isolation at the hypervisor or OS level — which means a kernel exploit on one tenant's workload could potentially compromise another's. By moving network enforcement to the DPU, the Bridge/NICo architecture pushes the security boundary below the host OS entirely. Even if a tenant's OS is compromised, the DPU-enforced VRFs, ACLs, and VXLAN segmentation remain intact and cannot be bypassed from the host side.

InfiniBand and NVLink partition management at scale

Distributed AI training workloads are extremely sensitive to IB or NVLink fabric configuration errors — a single misconfigured PKey can cause NCCL all-reduce performance to collapse, or cause cross-tenant data leakage. NICo's continuous IbFabricMonitor addresses this by treating partition state as a continuously reconciled intent rather than a one-time configuration. If a switch reboot or fabric event causes PKey bindings to drift, NICo detects and corrects the deviation automatically — without any operator intervention.

Zero-touch scale-out

The gated discovery flow means that adding new nodes to an existing cluster is fully automated. New servers are powered on, they boot into the discovery image, NICo enumerates their hardware and assigns them a stable identity, and they appear in Bridge's available pool — all without any manual inventory entry. For operators managing clusters of hundreds or thousands of nodes, this is not a convenience feature; it is an operational necessity.

Conclusion

The Bridge/NICo integration represents a thoughtfully designed division of responsibility between two systems that each excel in their own domain. NICo (formerly Carbide) handles everything that requires speaking the language of hardware: Redfish for BMC management, InfiniBand PKeys and NVLink partitioning for GPU fabric isolation, and DPU-native networking for tenant segmentation. Other components of Bridge handle everything above that line: tenant identity, VPC management, workload orchestration, and AI/ML platform services.

The result is an AI infrastructure platform that is simultaneously easier to operate (zero-touch bring-up, continuous reconciliation, automated scale-out) and more secure (DPU-enforced isolation, hardware root of trust, PKey-gated GPU fabric access) than traditional approaches.

For organizations building or evaluating large-scale GPU clusters — whether for internal AI workloads or as a commercial cloud offering — the Bridge/NICo architecture provides a production-grade blueprint that directly addresses the hardest problems: multi-tenancy at the hardware level, GPU fabric lifecycle management, and fully automated cluster operations.

Learn More

For technical documentation, API references, and deployment guides, visit the Armada developer portal or reach out to the Armada infrastructure engineering team.