A city GPU fabric must isolate public-health and permitting AI tenants on shared InfiniBand. What should operators configure?
Select an answer to reveal the explanation.
Short Explanation
Shared IB metal does not mean shared gossip. Put public-health and permitting on separate InfiniBand PKeys so tenants stay isolated.
Full Explanation
On a shared city GPU InfiniBand fabric, secure multi-tenancy between public-health and permitting AI tenants is enforced with InfiniBand partition keys (PKeys). PKeys define which HCAs may communicate over IB partitions so agencies sharing switches and cables still cannot freely RDMA across tenant boundaries. That is the InfiniBand-native isolation control plane for municipal multi-tenant GPU fabrics. IPoIB subnet addressing to segment tenant traffic on the fabric fails because IPoIB is an IP-layer overlay that does not enforce InfiniBand partition membership; RDMA between tenants is still controlled by PKeys, not subnet addresses. InfiniBand service levels with QoS policies for tenant traffic classes fail because service levels and QoS only manage traffic priority and bandwidth; they do not create partition membership or block cross-tenant RDMA. Subnet Manager LID assignments to separate public-health workloads fail because LIDs are local routing identifiers within a subnet, not access controls; they cannot stop HCAs from communicating across tenant boundaries when PKeys permit it. Exam caveat: NCP-AIN expects PKeys for IB multi-tenancy; do not substitute IPoIB subnet addressing, QoS service levels, or Subnet Manager LID assignments for partition-based isolation. Operational check: assign distinct PKeys for public-health and permitting HCAs, confirm same-PKey RDMA works within each agency, and confirm cross-agency RDMA fails while management PKeys remain tightly scoped.