A transit authority maps dedicated OOB switches so GPU nodes stay manageable during fabric outages. What configuration goal does that serve?
Select an answer to reveal the explanation.
Short Explanation
When the GPU fabric has a bad day, transit ops still needs a flashlight path to every BMC. Dedicated OOB switches are that flashlight—they are not meant to carry training all-reduce traffic.
Full Explanation
Transit authorities map dedicated OOB switches so BMC management remains available when the AI compute fabric is impaired—link flaps, misconfigurations, or collective storms that take down high-speed paths must not also erase operator access. Separate OOB networking preserves an independent recovery plane for console, inventory, and power control during fabric incidents that would otherwise black-hole in-band SSH. OOB switches are not intended to forward NCCL all-reduce traffic at line rate; that is the GPU compute fabric’s job, and sizing OOB for collectives confuses planes. Collapsing OOB and compute fabrics merely to save patch cords couples failure domains and can make fabric outages unmanageable across the transit row. Dedicated OOB is not “only for printers”; HGX-class servers require managed BMC connectivity as a core AI factory pattern. Exam caveat: OOB bandwidth is typically modest by design; performance SLOs for training still ride the compute fabric, while OOB’s SLO is reachability under failure. Operational check: simulate a compute-leaf outage in a maintenance window and confirm every affected transit GPU node’s BMC remains reachable and controllable through the dedicated OOB switches.