NVSwitch 1 (Volta, DGX-2 / HGX-2)

PER GPU, PER DIRECTION, and the convention here is the GOOD case - NVIDIA labels it explicitly, which is why this record can be verified while the Gen2/3 naming cannot. NVIDIA's DGX-2 technical blog (net2-nvidia-nvswitch1-dgx2-blog) carries the first-party switch figures from Hot Chips 2018: 'NVSwitch is a non-blocking NVLink crossbar with 18 ports at 51.5 GBps each, enabling any GPU pair to communicate at 300 GBps BIDIRECTIONAL bandwidth without interference' and '928 GBps aggregate BIDIRECTIONAL bandwidth'. The 300 GB/s is stated as BIDIRECTIONAL for a GPU PAIR, so the recorded per-direction value is 150 GB/s per GPU. Note there are THREE quantities here and they are not interchangeable: 300 GB/s bidirectional per GPU PAIR (this record's basis), 51.5 GB/s per switch PORT (stated without a direction qualifier by NVIDIA, so carried verbatim and not converted), and 928 GB/s switch aggregate bidirectional. RECONCILIATION, which is what makes this trustworthy: the port count and rate are consistent because each V100 has six NVLink 2 links and NVLink 2 is 25 GB/s per direction per link = 50 GB/s bidirectional per link, so 6 x 50 = 300 GB/s bidirectional per GPU - the same 300 the blog states for a GPU pair - and 18 switch ports x 51.5 GB/s = 927 GB/s, which is the blog's '928 GBps' aggregate (rounding). The switch therefore delivers exactly the per-GPU rate the direct-attached link already had and adds no bandwidth of its own: it removes the topology constraint and nothing else. That identity is the whole argument for NVSwitch, and it is why nvswitch-1 and nvswitch-2/4/5 all store a per-GPU per-direction value equal to their generation's link aggregate rather than a higher number.

Switched, non-blocking all-to-all crossbar. The NVLink crossbar reaches 1.98 TB/s of bisection bandwidth at 80% NVLink efficiency (net2-nvidia-nvswitch1-dgx2-blog), so the switch is not the bandwidth limit - the links are. Domain size is the switch's contribution: DGX-2 holds 16 V100 32 GB in one system, versus the partial-mesh 8-GPU nodes that direct attach allowed.

The switch IS the record. It also carries the property NVIDIA describes as the reason to build it: 'total memory bandwidth would actually GROW with the number of GPUs' as NUMA effects are reduced, and memory is accessed 'without intervention from other processes'. No in-network reduction exists at this generation - SHARP arrives with NVSwitch 3 on Hopper - so collectives are endpoint work here.

The FIRST NVSwitch silicon, added 2026-10-03 to complete the 1/2/3/4/5 ladder - the family was missing its founding generation, and its absence made the generational naming scheme unreadable (see nvswitch-2's naming trap below). AUDIT 2026-10-05, DIRECTION BUG FOUND AND CORRECTED - this record stored bandwidth_gbps 300 while its own bandwidth_basis said 'the recorded per-direction value is 150 GB/s per GPU', so the typed field and the prose contradicted each other by exactly 2x and the prose was right: NVIDIA's sentence is 'any GPU pair to communicate at 300 GBps BIDIRECTIONAL bandwidth', so 300 is the aggregate and the per-direction value is 150. The stored value is now 150. The value was wrong in the exact way this repo warns about - a bidirectional aggregate left unhalved in a per-direction field - and it had been carried since the record was created, undetected because 300 GB/s is a real number from the same source, appears verbatim in NVIDIA's own text, and is also the V100's genuine per-GPU aggregate, so nothing about the stored figure looks wrong in isolation. It was also the only record in the family whose stored value was inconsistent with its own stated convention: nvswitch-2, nvswitch-3, nvswitch-4 and nvswitch-5 all halve correctly (300 from 600, 450 from 900, 450 from 900, 900 from 1,800), which is why the mistake survived - it was the lone unhalved row in an otherwise consistent column, and the comparative reading 'nvswitch-1 = nvswitch-2 = 300' was itself the tell. The check that caught it is the one worth reusing: read every stored bandwidth_gbps in a family against its own bandwidth_basis sentence and compare direction conventions across siblings, because a sibling column that is internally consistent makes the one bad row invisible to a per-record review. Confidence raised 0.85 -> 0.9 now that field and convention agree and both are first-party. Recorded as gotcha w7n-nvswitch-1-stored-the-bidirectional-aggregate-as-per-direction. FIRST-PARTY FIGURES (NVIDIA developer blog, sourced from the Hot Chips 2018 NVSwitch and DGX-2 presentation): 18 NVLink ports at 51.5 GBps per port; any GPU pair at 300 GBps bidirectional without interference; 928 GBps aggregate bidirectional; 1.98 TB/s bisection at 80% NVLink efficiency; DGX-2 = 16 V100 32 GB, 2 petaFLOPS, 512 GB aggregate GPU memory. THE GENERATION NAMING IS A TRAP AND THIS RECORD SETS IT STRAIGHT, because three different numbering schemes are in play and mixing them is the most common error in this domain: (1) NVSwitch silicon is numbered 1/2/3/4/5 across Volta/Ampere/Hopper/Blackwell/Vera Rubin; (2) the NVLink LINK generation advances independently, so A100 is NVLink 3 with NVSwitch 2 (see nvlink-3 and nvswitch-2), while H100 is NVLink 4 with NVSwitch 4 and B200 is NVLink 5 with NVSwitch 5; (3) NVIDIA's own product pages increasingly drop the number entirely and write 'NVSwitch' or 'NVLink Switch'. Concretely: NVSwitch 1 = V100/DGX-2, NVSwitch 2 = A100, NVSwitch 3 = H100, NVSwitch 4 = H100 (the vendor table labels it 'NVLink 4 Switch' for the same part), NVSwitch 5 = Blackwell. Do NOT match a switch record to a link record by generation number. INFERENCE RELEVANCE: this is the generation where 'multi-GPU serving' stopped being a partial mesh, and NVIDIA's claim that aggregate memory bandwidth grows with GPU count is a direct serving argument - it is the reason a 16-GPU V100 node could hold a model that no single device could, without paying a bandwidth penalty per layer. But at 150 GB/s per direction per GPU against the V100's 900 GB/s memory interface the fabric is still ~1/6 of local bandwidth, so it remains a capacity play rather than a bandwidth play - the same conclusion as nvlink-1, one generation apart. === 150 GB/s RE-VERIFIED 2026-10-08 (w8-reverify) — CONFIRMED, AND THE HALVING IS CORROBORATED BY A SECOND RECORD. === The 300 -> 150 correction was re-checked two independent ways. (1) NVIDIA's own sentence, re-read live on the DGX-2 blog: 'NVSwitch is a non-blocking NVLink crossbar with 18 ports at 51.5 GBps each, enabling any GPU pair to communicate at 300 GBps BIDIRECTIONAL bandwidth without interference'. BIDIRECTIONAL is NVIDIA's word, so 300 is the aggregate over both directions and 150 is the per-direction half. (2) THE INDEPENDENT ARITHMETIC, which is what makes this more than a restatement of the source: the same blog says the V100 has six NVLinks, and this repo's own nvlink-2 record holds 25 GB/s PER LINK PER DIRECTION. Six links x 25 GB/s per direction = 150 GB/s per direction per GPU, and x2 = 300 GB/s bidirectional - the number NVIDIA prints. So the per-direction figure is forced by a second, unrelated record rather than only by dividing the headline, which is the difference between a halved number and a verified one. (3) The cross-generation convention check also holds: nvswitch-2/3/4/5 all state 'PER GPU, PER DIRECTION' and hold 300/450/450/900, the halves of published 600/900/900/1800 bidirectional aggregates, so this record now agrees with the column it sits in. THE CONVENTION IS STATED, which was the second half of the re-verification question: the record's typed value is 150 and its bandwidth_basis opens 'PER GPU, PER DIRECTION' and names the three quantities that must not be conflated - 300 bidirectional per GPU pair, 51.5 per switch port (unqualified by NVIDIA and carried verbatim), and 928 switch aggregate bidirectional. All three are present and distinguishable, so a reader cannot silently mix them.