In this article
A directed peer-access result, a topology relationship and an engine transfer are separate observations.
A physical connection is not a capability result
Two GPUs may share a server and still differ in how software can transfer data between them. A visible interconnect, a favorable topology entry and a successful peer-access query are separate pieces of evidence. None of them alone proves that a particular inference engine uses direct transfers for its chosen model partition.
The CUDA best-practices guide discusses device communication and data movement as workload-dependent operations. Build the investigation around a concrete transfer path. Do not use the mere presence of multiple devices as evidence that their VRAM becomes one transparent allocation pool.
Build a directed pair matrix
Give each row a source GPU and each column a destination GPU, using stable identities alongside local indices. Record the supported capability result for every tested direction. Preserve query failure, unavailable support and an actual negative capability result as distinct states. A blank cell means untested unless the record says otherwise.
The DCGM topology and links guide provides context for interpreting relationships and observed links. Put that inventory beside the capability matrix rather than replacing the matrix with it. Keep the operating system, driver, runtime and partition configuration because support and visibility can change with the environment.
Separate capability from successful execution
A positive capability result is a precondition to investigate the relevant direct path, not a measured transfer speed. Run an appropriately bounded test with known buffer sizes and directions, and verify its actual route. If software falls back through host memory, label that result explicitly instead of mixing it with direct-transfer observations.
For an illustrative example, consider devices A and B. Record A-to-B and B-to-A observations separately, even if both eventually support the same behavior. A failed transfer after a positive capability check requires its own error record. Do not rewrite the capability cell to passed merely because a different host-mediated copy completed.
Test the application path
Next determine how the engine distributes weights, state and communication. An independent copy test cannot establish collective performance or model-serving throughput. Preserve the engine’s parallelism settings and confirm which device identities participate. A pair matrix is especially useful when a configuration accidentally includes a device different from the one tested.
Compare isolated and simultaneous transfers only when that distinction matters to the workload. Include shared-path contention and memory placement in the record. Use repeated observations rather than interpreting one fast transfer as a bandwidth reservation that remains available to every concurrent request.
Keep the conclusion at the right layer
The final artifact has three sections: topology inventory, directed capability results and measured workload behavior. Explain the connection between them without collapsing their meanings. This identifies whether the problem is unsupported access, an unexpected software route or a bottleneck in the real parallel workload. It also prevents a misleading promise that any two visible GPUs can host a model requiring their summed VRAM.
After a driver or device change, repeat the affected checks and retain a new matrix version. An earlier positive observation is useful history, but it cannot automatically be transferred to a different execution environment.