--- title: "When the Network Adds the Values: What SHARP Reduction Offloads" description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20." canonical: "https://www.leviathansystems.co/articles/in-network-sharp-reduction-versus-switch-forwarding" last-updated: "2026-10-20" --- # When the Network Adds the Values: What SHARP Reduction Offloads Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20. SHARP can move supported collective aggregation and reduction work from CPUs or GPUs into the network. Ordinary packet forwarding carries the contributions; an aggregation node can combine their values before passing a partial result onward. The additional function is arithmetic in the communication path. A capable switch label alone does not establish that a particular application uses it or completes faster. An aggregate active-job count does not identify which collective used the offload path. ## Locate the arithmetic in the communication path A proposal that names an in-network reduction capability promises more than transporting packets between participants. It promises that supported network elements can perform part of the collective's aggregation work. That distinction matters when two offers quote similar link rates but describe different execution paths. NVIDIA calls the technology Scalable Hierarchical Aggregation and Reduction Protocol (SHARP). Its introduction describes moving collective work from CPUs and GPUs into the network, combining contributions as aggregation nodes are reached. For a sum reduction, the important action is adding corresponding values. In the ordinary forwarding role, the network transports payloads while the reduction arithmetic remains with the endpoints. With reduction offload, some of that arithmetic occurs along the network path. This capability has a defined scope. It does not establish that a switch executes arbitrary model layers, selects experts or runs the application. Nor does a reference to collective offload establish that every operation in a program is eligible. The buyer needs the particular operation and implementation behind the claim. References: [SH1](https://networking-docs.nvidia.com/sharpum/3130/introduction) ## Follow four contributions through a conceptual tree Consider four hypothetical participants contributing the exact scalar integers 2, 3, 5 and 7 to a sum. Stipulate two intermediate aggregation nodes and one parent. The first intermediate node receives 2 and 3 and produces 5. The second receives 5 and 7 and produces 12. The parent receives those partial sums and produces 5 + 12 = 17. The two occurrences of 5 have different roles: one is an original contribution, and the other is the partial sum of 2 and 3. The partial values represent their respective contributions; the parent does not need those contributions separately to complete this stipulated sum. This is the mechanism that makes aggregation different from forwarding four unchanged payloads onward for endpoint arithmetic. The requested mathematical sum remains 2 + 3 + 5 + 7 = 17. A correctly completed endpoint reduction would also produce 17. The distinction is where the additions happen. If the intended collective requires the result at every participant, delivery to those participants is still part of completing that collective; the parent producing 17 describes only the illustrated aggregation. This is an original conceptual tree, not an actual SHARP resource tree or an installation design. It supplies no physical routes, payload encoding or timing, so it supports no link-traffic calculation, resource-fit claim or speedup. Its exact integer arithmetic also establishes no real implementation's reduction order or floating-point equivalence. ## Separate reduction from forwarding, output ownership and DPU services A forwarding-capacity claim concerns carrying traffic through a specified boundary. Reduction offload adds the ability to combine eligible contributions. A larger port-rate sum does not show that additions took place, and an aggregation capability does not define the capacity of the populated uplinks. Use the switch-bandwidth and oversubscription article for that separate capacity comparison. A collective's mathematical contract is another question. The linked all-reduce, all-gather and reduce-scatter article explains the values returned and their ownership. An offload implementation still has to deliver the requested result. Changing the execution location does not turn gathering separate contributions into summing them, or a partial result into a complete all-reduce output. Likewise, a DPU infrastructure-service proposal needs its selected software function and integration result identified. The BlueField architecture article addresses that purchase. The word offload shared by such proposals is insufficient to make their functions equivalent: identify the work being moved, its destination and the output being promised. For routed MoE traffic, ask which token representations must reach which experts. Combining values answers a different question from preserving destination-specific inputs. A reduction capability therefore cannot substitute for evidence of the application's dispatch and return exchange. ## Read the release and software path together The references here are NVIDIA's SHARP 3.13.0 documentation, checked October 20, 2026. Its Release Notes table dates revision 3.13.0 to October 30, 2025; that page's footer separately says October 13, 2025. The Introduction page itself says August 1, 2022; the NCCL integration page says October 30, 2024. Those page dates remain relevant even within the named documentation set. General Information, updated November 18, 2025, lists distribution packages including DOCA-Host 3.2.0 and HPC-X 2.25, alongside device firmware prerequisites. Its operating-system and platform coverage refers readers to the applicable HPC-X and DOCA-Host documentation. These are version-scoped references, not a universal platform-support matrix for a purchase made today. The NCCL integration page identifies the NCCL-SHARP plugin as the integration path and describes binary distribution through HPC-X and source distribution. Its requirements name ConnectX-6 HDR and above, Quantum HDR switches and above, DOCA-Host and GPUDirect RDMA. These historical requirements explain why the switch is only part of the implementation; they do not qualify an offered combination of hardware and software. Ask the appointed OEM or software integrator to identify the supported combination in the actual offer, including the relevant library, plugin, host stack and device software. A product-family name cannot connect the application's collective request to a particular execution path. References: [SH2](https://networking-docs.nvidia.com/sharpum/3130/general-information), [SH3](https://networking-docs.nvidia.com/sharpum/3130/using-nvidia-sharp-with-nvidia-nccl), [SH4](https://networking-docs.nvidia.com/sharpum/3130/release-notes) ## Match the requested work to supported operations and resources The SHARP Collective Library page, updated November 4, 2024, describes an API for integration with communication runtimes and names collective operations and datatypes. A library's advertised operation list does not by itself show which work a particular NCCL path offloads. Have the implementation owner identify the actual reduction operation, datatype and supported path for the intended use. Aggregation resources also have limits. The 3.13.0 General Information capability table distinguishes low-latency and streaming aggregation and gives different tree and concurrency limits for Quantum and Quantum-2. That distinction makes resource availability part of the applicability question, even when equipment is described as SHARP capable. For a proposal covering several jobs, ask which workload population the supplier's resource explanation covers and how the selected implementation accommodates it. A capability entry for a device cannot establish that a particular job obtained and used the required resources. The supported design and evidence for that claim must come from the responsible platform team. References: [SH2](https://networking-docs.nvidia.com/sharpum/3130/general-information), [SH5](https://networking-docs.nvidia.com/sharpum/3130/nvidia-sharp-collective-library) ## Attribute the offload claim to a group and a collective The Control Flags section of the SHARP 3.13.0 NCCL integration page describes streaming aggregation support for a single NCCL communicator/process group (PG), with selective enablement for particular groups. This statement applies to that named integration path; it is not a rule for all SHARP versions, LLT or UCC paths, or every group across a fabric. The same documentation set's sharp_am Telemetry page defines active_sat_jobs as the number of active SHARP jobs requesting SAT rather than just LLT. It describes a request population. The field supplies neither a process-group identity nor a record that an individual collective executed or completed on the offload path. Consider an original fictional application with two process groups, G1 and G2. G1 has a represented sum collective C1; G2 has a represented sum collective C2. A supplier initially says SHARP enabled and supplies only a contemporaneous active_sat_jobs = 1. Even with that timing match, neither statement attributes C1 or C2 to the offload path. The count identifies no group or call, and the enabled label does not resolve selective coverage. One SAT-requesting SHARP job must not be equated with one process group or one collective. Now explicitly stipulate that the appointed implementation owner supplies a valid, matched, implementation-specific execution association for these represented calls: G1/C1 used the named NCCL-SHARP streaming offload path, while G2/C2 used a different endpoint path. This association is a hypothetical premise, independent of the aggregate count. It is not an actual trace, an invented standard log field or a universal instrumentation recipe. The offload conclusion now covers C1 in G1 for that represented execution only. C2 is attributed to the endpoint path. The resolved association changes which call the buyer can include in the offload claim; it does not extend that claim to both groups, later calls or the application's remaining work. Correctness, performance and application completion require their own evidence. References: [SH3](https://networking-docs.nvidia.com/sharpum/3130/using-nvidia-sharp-with-nvidia-nccl), [SH6](https://networking-docs.nvidia.com/sharpum/3130/sharp_am-telemetry) ## Connect capability, observed use and application completion Keep the evidence questions separate when reading the offer. Capability concerns whether the equipment and software support the requested operation and datatype. Allocation concerns the resources made available; a request concerns what was asked for. Actual use concerns the path taken by the represented collective. Result evidence concerns the values returned and their required recipients. Performance concerns comparable completed work. Application completion concerns the workload's final required outcome. The fictional execution association answers the actual-use question for C1 and C2, without supplying the other answers. A generic successful NCCL output establishes neither the location of the arithmetic nor the use of SHARP. Its operation, participation, correctness and timing evidence still matter within their recorded scope. The NCCL bandwidth article explains algbw and busbw, while the all-reduce evidence article addresses run provenance and generated-result checks. Neither metric name supplies the missing attribution to an offload path. If the offer also promises improved performance, ask which comparable completed work supports that improvement. Keep the operation, datatype, message size, participating resources and software conditions attached to the comparison. A change in elapsed time without an explained comparison cannot isolate the contribution of in-network reduction. Finally, locate the application's completion boundary. A collective completing is an intermediate event when further computation or communication is required. Even evidence that C1 used SHARP and completed faster would leave full application completion to be assessed separately. ## Bring the selected connections to a physical cabling inquiry Once the platform and network owners have selected the supported equipment and connection plan, Leviathan's Structured Cabling & Fiber Installation service can discuss the agreed routing, installation, dressing, labels and physical connection records. Provide a nonconfidential outline of the endpoints, specified assemblies, routes, materials supplier, work window and required handoff records through the related project-inquiry link. That physical scope interfaces with the appointed platform team's work. SHARP software integration, fabric configuration, offload verification and application-performance assessment remain separately assigned to the responsible technical owners. References: [L1](https://www.leviathansystems.co/services/structured-cabling) ## Primary sources - [SH1 — NVIDIA SHARP 3.13.0 documentation: Introduction](https://networking-docs.nvidia.com/sharpum/3130/introduction). Checked 2026-10-20. Collective offload and aggregation-node mechanism; page updated August 1, 2022. Useful for explaining execution location, without a measured performance conclusion. - [SH2 — NVIDIA SHARP 3.13.0: General Information](https://networking-docs.nvidia.com/sharpum/3130/general-information). Checked 2026-10-20. Updated November 18, 2025. Package versions, device prerequisites and hardware aggregation limits establish version-specific applicability; platform coverage refers to the relevant software documentation. - [SH3 — NVIDIA SHARP 3.13.0 documentation: Using NVIDIA SHARP with NVIDIA NCCL](https://networking-docs.nvidia.com/sharpum/3130/using-nvidia-sharp-with-nvidia-nccl). Checked 2026-10-20. Page updated October 30, 2024. Plugin, distribution and prerequisites; the Control Flags section describes selective process-group enablement for this NCCL streaming path, without establishing fabric-wide coverage. - [SH4 — NVIDIA SHARP 3.13.0: Release Notes](https://networking-docs.nvidia.com/sharpum/3130/release-notes). Checked 2026-10-20. The revision table dates document version 3.13.0 to October 30, 2025; the page footer separately says October 13, 2025. - [SH5 — NVIDIA SHARP 3.13.0 documentation: NVIDIA SHARP Collective Library](https://networking-docs.nvidia.com/sharpum/3130/nvidia-sharp-collective-library). Checked 2026-10-20. Page updated November 4, 2024. API integration and advertised collective/datatype scope help frame implementation questions; a library capability list does not establish an individual runtime's offload coverage. - [SH6 — NVIDIA SHARP 3.13.0: sharp_am Telemetry](https://networking-docs.nvidia.com/sharpum/3130/sharp_am-telemetry). Checked 2026-10-20. Page updated January 30, 2025. The active_sat_jobs definition supports interpreting an aggregate SAT-requesting job count; the field does not identify an individual process group or collective execution. - [L1 — Leviathan Systems: Structured Cabling & Fiber Installation](https://www.leviathansystems.co/services/structured-cabling). Checked 2026-10-20. Physical installation to approved routes, endpoints and labels, with identified material responsibilities and agreed handoff records. ## Related Leviathan resources - [Compare all-reduce, all-gather and reduce-scatter results](/articles/gpu-collectives-allreduce-allgather-reduce-scatter) - [Distinguish switch bandwidth from populated uplink capacity](/articles/switch-bandwidth-versus-fabric-oversubscription) - [Separate BlueField architecture from a delivered DPU service](/articles/bluefield-nic-mode-versus-dpu-services) - [Read NCCL algbw and busbw in the scope of the operation](/articles/nccl-bandwidth-validation) - [Review the provenance of an all-reduce submission](/articles/nccl-all-reduce-validation-acceptance) - [Discuss structured cabling for the selected connection plan](/services/structured-cabling) - [Send a physical cabling project inquiry](/contact?service=structured-cabling&from=%2Farticles%2Fin-network-sharp-reduction-versus-switch-forwarding) ## Scope the physical connections for the selected fabric Share a nonconfidential endpoint plan, specified assemblies, routes, supply responsibilities and required physical records to discuss scope, requirements and availability. [Discuss the scope](/contact?service=structured-cabling&from=/articles/in-network-sharp-reduction-versus-switch-forwarding)