PipeLink lets separately built GPU kernel parts work together
PipeLink: Contract-Guided Linking of GPU Kernel Components · arXiv:2610.37200
In plain words
Fused GPU kernels can be built from parts written by different teams or libraries, but those parts may claim the same on-chip resources. PipeLink lets each part declare what it needs and promises, then checks and connects the parts when they are linked.
In 51 timed configurations on three NVIDIA GPU models, linked kernels ran within 0.2% of controls compiled from the same parts as one unit. That result covers those tests, not every kernel or GPU.
The research
When separately written GPU kernel parts share on-chip resources, their hard-coded assignments can collide. Teams may have to reconcile those assignments by hand or keep the parts in separate kernels. Can a linker combine independently compiled parts while coordinating what they share?
PipeLink links separately compiled GPU kernel parts by checking their contracts, jointly assigning resources, and generating the connections between them.
PipeLink links separately compiled GPU kernel parts by checking what each part requires and promises, jointly assigning on-chip resources, and generating connections. Researchers compared linked kernels with single-unit controls built from the same sources and connecting code.
Across 51 timed configurations on three NVIDIA GPU models, linked throughput stayed within 0.2% of control throughput. This supports the view that, in these tests, linking did not add a meaningful performance cost to the compositions.
PipeLink checks whether components’ declared contracts agree, not whether their code follows those contracts. Its generated transfers move data only within one thread block; arithmetic, precision conversion, and communication between blocks or GPUs remain in component code.
What the evidence shows
- The composition problem
PipeLink is a contract-guided linker that combines separately compiled components into one fused GPU kernel. The components can be written in different libraries, but they may share on-chip memory, barriers, warps, registers, and tile schedules.
Because components often hard-code their positions in those resources, combining them can require manual coordination or separate kernels.
- Contracts coordinate components
The contracts record what each component requires and promises, including shared resource needs and geometry facts. PipeLink checks these declarations, assigns resource positions jointly, and generates connections such as tensor transfers.
The components’ instructions stay opaque to the linker, and the vendor backend folds link-time decisions into constants.
- Changed facts expose a gap
A test of changed geometry facts shows what symbol linking misses. Researchers changed one constant in one owner of a four-owner MoE kernel, repacked only that owner, and linked it with the others’ unchanged objects.
Symbol linking accepted all five cases, but three kernels hung and two left some output unwritten. PipeLink relinked all five correctly by propagating each changed fact to its consumers.
- Linking stayed near controls
Researchers compared linked kernels with single-unit controls made from the same component sources and generated code, with the same placement, floating-point mode, and inputs. Across 51 timed configurations on H200, B300, and RTX 5090 GPUs, linked throughput was within 0.2% of control throughput.
The authors interpret this as evidence that the case studies measure what composition enables rather than a cost from linking.
- Results depend on workload
The examples show that composition can enable cross-library and multi-owner kernels, while performance depends on the workload. Replacing an attention component sped up Llama-1B decoding at a 4096-token context but slowed it at 16 tokens.
A four-owner MoE training kernel stayed near its monolithic step’s throughput, and a fused Qwen3-32B operation outpaced a cuBLAS-plus-compiled-activation comparison in one B300 setting.
Deep
- Original paper authors
- Jize Guo, Xupeng Miao
- Submitted to arXiv
- License
- CC BY 4.0