Helion, the PyTorch team’s domain-specific language for writing machine learning kernels that run well across hardware, now computes its kernel configuration at compile time instead of searching for it. The PyTorch blog says the heuristics are merged and enabled by default on H100 and B200 GPUs with the Triton backend. For teams that have been paying GPU-hours to tune every kernel, the cost structure just changed.
The problem was tuning time. A single Helion definition can become thousands of distinct Triton programs, and the autotuner compiles and benchmarks many candidates to choose among them, again for each kernel and each shape. The PyTorch post cites an earlier team that tuned one paged-attention kernel for 72 shapes: 10 hours in quick mode, 25 at full effort.
The new approach reads the compiler’s device IR and records structural facts about the kernel, such as the tiled axes, the tunable block sizes, and the tiles alive at each point. Then it sorts the kernel into one of three families. Anything containing a matmul gets the matmul heuristic, a reduction without a matmul gets the reduction heuristic, and everything else gets the pointwise one. When some loop extents are unknown until runtime, the heuristics stay out of it and Helion reverts to its old default.
Each heuristic sets the knobs an autotuner would normally search: block sizes, warp count, pipeline stages, L2 grouping, and eviction policies. They lean on a resource estimate built from a liveness analysis, which predicts the registers and shared memory each thread block needs, plus tensor memory (on Blackwell). The authors concede this is a guess about Triton’s decisions, and that plenty of the guesses are wrong.
The numbers favor the shortcut. The first test used nine linear-attention variants and six production shapes on H100. In the forward pass, the computed config is 1.18x faster than the handwritten Triton in Flash Linear Attention. Helion’s earlier no-tuning default ran at 0.52x, and full autotuning reached 1.26x. On six vLLM reduction kernels, the heuristic output hits 1.27x of vLLM’s handwritten CUDA, against 0.58x before and 1.31x with full autotuning. Tuning bought roughly 3 percent more.
Against torch.compile in its max-autotune mode, the picture is mixed. Ten reduction kernels come in at 1.09x, and thirteen matmul families over 70 shapes land at 1.88x. The post flags that the second figure is not a clean comparison, because the PyTorch versions of some kernels materialize intermediates that Helion fuses. Jagged HSTU attention regressed outright, dropping from 3.72x under the old default to 3.27x.
Helion’s authors also tested whether the computed configs could seed the autotuner. Over 38 matmul-heavy kernels, seeded searches needed a median of 1 config to land within 50 percent of the best result, against 35.5 unseeded. Reaching within 5 percent took 175 configs seeded and 255.5 unseeded. A complete search still took 420.5 against 521.5. The winning configs from both arms differed by well under one percent, so seeding shortens the wait without improving the destination.
The authors say the goal was never to beat the autotuner, which can benchmark thousands of candidates. They wanted a new point between wait time and speed. Everything was measured on NVIDIA hardware only, and the constants were tuned against H100 and B200. The post names measuring real register and shared-memory usage after compilation as the likely next fix.
For anyone shipping Helion kernels on those two chips, the default build is now a credible first deploy, and a full autotuning run belongs only on the fixed shapes where that last few percent justifies a day of GPU time.
Originally reported by the PyTorch blog (pytorch.org) on November 12, 2026.
