Profiling TorchNeuron (Part 1): System-level profiling on AWS Trainium.
- ID
- 37955
- Status
- summarized
- Published
- 22 Oct 2026, 12:04 AM
- Fetched
- 22 Oct 2026, 1:56 AM
- Provider
- Hugging Face Blog
- Category
- developer-ai
- Original URL
- https://huggingface.co/blog/amazon/profiling-torchneuron-part-1
- Source URL
- https://huggingface.co/blog/feed.xml
Summary
- Score
- 4.5
- Created
- 22 Oct 2026, 1:56 AM
- Tags
- Audience
- developersai_ml_learners
What happened
Part 1 of a Hugging Face/Amazon series walks through system-level profiling of TorchNeuron on AWS Trainium. It shows how to set NeuronConfig with DEVICE and RUNTIME modes, capture_enabled_for_nc='0', and correlate_device_time=True, then use NeuronProfiler.export_trace to write trace.json and read key_averages() to compare Self CPU time with Neuron device time. The walkthrough follows one operation through Neuron Explorer from PyTorch dispatch to runtime scheduling to NeuronCore execution, and compares three implementations of the same operation.
Why it matters
If you run PyTorch on Trainium, this gives a concrete profiling recipe: set modes=[DEVICE, RUNTIME] and correlate_device_time=True so key_averages() lines up CPU and Neuron device time, then use that table to decide whether an op is CPU-dispatch-bound or NeuronCore-bound before rewriting it. If you are not on Trainium, there is no action here.
Discussion angle
For anyone who has profiled on Trainium: which key_averages() signal actually changes your optimization decision — device time share or Self CPU time — and when is Neuron Explorer overkill?