CUDA Fabric Memory: Allocation Handles, Local Maps and Device Access

Keep the fabric, operating system, process and device distinct

NVIDIA's DGX GB Rack Scale Systems Hardware chapter, updated September 17, 2026, describes an NVL72 domain containing 72 GPUs and eighteen compute trays. Each tray contains two Grace CPUs and four Blackwell GPUs and runs an OS image. NVLink connects the trays for communication.

Those equipment relationships do not establish one host process, one process address space or one CUDA device. Nor do they establish how many devices a particular container or process can enumerate. The B200/GB200 identity guide explains the hardware units; the question here concerns access by a particular application participant.

CUDA's multi-GPU chapter describes several execution arrangements, including processes running across independent operating system instances. A supplier therefore needs to identify the actual process and GPU participants behind a memory-access claim. Rack membership supplies context, while the proposed software arrangement determines which access relationship needs explanation.

References: [N-HW][N-MULTI]

A portable handle crosses the process boundary

Within one host process, CUDA unified virtual addressing and supported peer access can allow a kernel on one GPU to use a pointer to another GPU's memory. That same-process relationship must not be carried unchanged across a process boundary.

The CUDA Programming Guide's Interprocess Communication chapter, updated September 10, 2026, distinguishes transferable handles from device pointers obtained locally by each participating process. Giving Q the number used as P's pointer does not give Q a valid pointer. Fabric handles extend the sharing relationship across independent OS instances on supported NVLink systems.

The selected example uses VMM fabric sharing. It does not use legacy CUDA memory IPC, whose documented restrictions include Linux-only support and exclusion of cudaMallocManaged allocations. The separate SVA/PASID article explains a different process-address mechanism; it cannot establish this CUDA import relationship.

References: [N-MULTI][N-IPC]

Follow allocation identity through a local map to device permission

The guide documents CU_MEM_HANDLE_TYPE_FABRIC from CUDA 12.4 onward. Applicable device VMM and fabric-handle support, the driver/platform combination, a running NVIDIA IMEX daemon and exporter/importer access to the same applicable IMEX channel qualify its use. A CUDA version or NVLink label alone does not establish those conditions.

A physical allocation supplies backing. An exported shareable handle represents it for transfer; import yields the receiving process's allocation handle. A reserved address range has no backing until mapped. Mapping associates backing with addresses; access rights cover a device and range.

The CUDA Driver API 13.4 reference treats cuMemMap and cuMemSetAccess separately: mapping does not grant accessibility. A successful import alone therefore leaves the accessing GPU's permission unresolved.

For a returned offer, connect these objects to the same allocation rather than accepting an unrelated successful import, a reserved address total or permission for another device.

References: [N-VMM][N-DRIVER]

FAB-8 fixes one allocation and one read requirement

FAB-8 is a fictional supplier-return comparison. Process P and process Q run in different OS instances. P uses GPU A and Q uses GPU B, two named participants in a supported NVLink fabric. Stipulate the applicable CUDA/driver/platform and fabric support, a running IMEX daemon and access to the same applicable IMEX channel. The 8 MiB extent and its address alignment satisfy the actual allocation and mapping granularity requirements.

There is one live physical payload allocation X on GPU A, containing exactly 8 MiB. P already has a valid local mapping of all X at 0x100000000. There is no additional payload copy or multicast replication. Correct synchronization and the required lifetimes are stipulated throughout one identified use interval.

The requirement is precise: Q's GPU code executing on GPU B must have a valid address-centric read of every byte of X during that interval. It is not a CPU dereference requirement, a latency target, an all-local-memory requirement or a whole-model-fit claim. The following returns change the supplied access relationship while retaining those fixed premises.

Returns A and B leave different parts of the requirement unsatisfied

Return A supplies the rack/domain membership and P's numeric pointer, 0x100000000. It supplies no Q import or local mapping. That return does not establish the required read. The pointer number has been communicated, but Q's relationship to allocation X has not. The useful clarification is the supported sharing and local-address relationship for Q, rather than another confirmation that the GPUs belong to the fabric.

Return B supplies a valid export/import of X and a complete Q mapping at 0x200000000. It explicitly states that GPU B has no access rights to that range. B has answered the allocation and mapping questions, but its own permission description excludes the required GPU read. Permission for GPU A or another range would not resolve the stated omission.

Neither conclusion reports a kernel launch or an observed fault. They assess the returned conditions. A is incomplete at the process-sharing boundary; B expressly lacks the accessing device's permission. It would be equally wrong to accept B because mapping succeeded or to use A's inadequacy as proof that cross-node sharing is impossible.

Return C closes the stipulated read relationship

Return C corrects B's access description: GPU B now has supported read permission over Q's entire 8 MiB mapping of X. Every other FAB-8 premise remains unchanged, including allocation identity, support, synchronization and the use interval.

Under those complete stipulated relationships, Q's GPU code can address X through Q's own range. At byte offset 128, which is hexadecimal 0x80, P's address is 0x100000080 and Q's is 0x200000080. Both refer to the same backing byte of X. Q does not need to use P's numeric base address.

C therefore meets the fictional access requirement that A leaves unestablished and B fails. This is a conditional conclusion from the supplied relationships, not an actual implementation or test result. A real supplier's response must establish the corresponding conditions for its offered environment.

The correction grants the described read; it does not assign a write entitlement. It also does not move X's backing to GPU B, combine the OS instances, merge the processes or create a single CUDA device.

Two address extents still refer to one 8 MiB payload allocation

Using 1 MiB = 1,048,576 bytes, X contains 8 × 1,048,576 = 8,388,608 bytes. P's inclusive mapped range is 0x100000000 through 0x1007fffff. Q's is 0x200000000 through 0x2007fffff. Each contains exactly 8,388,608 addressable bytes, and offset 128 lies within both.

Adding the two virtual extents gives 16,777,216 bytes of address-range extent across two processes. That sum describes neither one contiguous 16 MiB allocation nor two payload copies. The stipulated physical payload backing remains one 8,388,608-byte allocation on GPU A. This account excludes mapping structures and other system overhead.

The practical consequence is visible in C: Q gains a way to address the existing payload without this example adding another payload allocation. That says nothing about the latency of the remote accesses or the capacity needed by the rest of an application. The related Unified Memory guide owns the separate allocation-versus-residence decision.

Keep the complete range and use interval attached to the offer

One resolved address establishes only that address. FAB-8 closes the full requirement because C expressly covers every byte, GPU B and the identified interval. Evidence for the first page, another GPU or an earlier interval would leave a different part of the requirement open.

The Driver API reference ties allocation deallocation to outstanding mappings and handle references. Releasing one handle is not by itself proof that the backing has disappeared. Conversely, an earlier mapping record does not establish that the same range remains mapped and permitted later.

Request a response connecting X's identity and extent, the exporting and importing participants, Q's range, GPU B's read permission and the period of intended use. Ask the platform owner to explain the supported lifetime relationship covering that period. This is an evidence question, not an instruction to alter permissions or configure IMEX.

If a revised return changes the backing allocation, GPU, mapped extent or interval, reassess the relationship on that changed basis. Retaining the same pointer number would not by itself retain the original conclusion.

References: [N-DRIVER]

Select communication for the required result

Addressability alone supplies no synchronization guarantee. FAB-8 assumes correct synchronization so it can isolate the access decision. Use the CUDA atomic-scope and memory-order guide when the actual question is when another participant may safely consume a payload.

Likewise, reading X does not compute a reduction or distribute model state. The collective-operations guide explains returned values and rank ownership; the DDP/FSDP guide explains replica and shard placement. A fabric mapping settles neither question. NCCL, NVSHMEM, MPI, framework-managed and custom approaches remain possible for their intended purposes; this example declares none universally mandatory or unnecessary.

The current CUDA guide also documents Compute Fabric Transport as a resource-centric alternative. It addresses a logical endpoint using a process-local endpoint identifier and an offset, with explicit asynchronous fabric operations rather than a required peer virtual-address mapping. Its support depends on architecture, driver and configuration, with NVLink reachability and applicable IMEX daemon/channel prerequisites.

A supplier proposing that alternative needs to explain its own endpoint relationship. It should not be rejected merely for lacking FAB-8's selected VMM mapping. The comparison here answers whether an offered address-centric read is established; it does not make that path a universal communication rule.

References: [N-MULTI][N-CFT]

Carry a separate equipment requirement into physical preparation

The technical decision can stand on its own. If the selected equipment also needs receiving, preparation or rack assembly, Leviathan's Rack Assembly & Preparation service and contextual project inquiry below address that physical package.

Share a nonconfidential equipment summary, approved configuration, supplied integration state, proposed site, permitted physical tasks and required handoff records. Identify the team receiving the prepared or assembled equipment so the engagement can define its inputs, work and outputs.

Memory implementation, CUDA and IMEX administration, software/security operations and workload acceptance remain with the appointed platform and application owners. A physical handoff does not establish FAB-8's software access relationship.

References: [L1]