TorchNeuron: trace an operation all the way to hardware
Amazon's RMSNorm walkthrough connects profiler totals to device execution, giving optimization work a concrete starting point.
torch.neuron.synchronize() is consequential in Amazon's profiling example. It waits for device work before the collection advances. Josh Longenecker explains that omitting it can let export happen before execution finishes, leaving the Neuron timing column empty.
Published October 21, 2026, the walkthrough compares RMSNorm on Trainium using separate PyTorch operations, the built-in torch.rms_norm, and compilation of the original function. Both the built-in operation and the compiled version consolidate the calculation into a fused kernel in this example.
The useful connection is between measurement and execution. key_averages() identifies expensive device operations. Neuron Explorer then follows their dispatch, runtime scheduling and hardware activity, exposing the gaps that fusion removes.
I would use that sequence before attempting a custom kernel: select an expensive operation from the table, inspect its trace, then decide whether an existing fused operator or compilation addresses the observed work. The boundary is equally concrete. An RMSNorm improvement in this setup does not establish the same improvement for a complete model.
Source: Josh Longenecker at Amazon, Profiling TorchNeuron (Part 1): System-level profiling on AWS Trainium..