Activations
Activation capture is runtime tracing applied to a forward pass: recording what a module actually produced for a given input, rather than only inspecting its static weights.
Capturing an activation
The bundled local runner attaches via forward hooks, so setting a capture point on a module's output works the same way as setting a breakpoint anywhere else - pick the module in the Architecture view or Outliner, and mark its output for capture. Once a forward pass runs (or an existing .tmrun trace is replayed), the captured activation is addressable and inspectable exactly like a static weight tensor: it has tensor statistics, it's viewable in the Matrix and Heatmap view, and a single value from it is inspectable in the Scalar Inspector.
Why capture activations at all
Weights alone don't tell you how a model actually behaves on real input - two structurally similar models can produce very different activations for the same input, and a weight that looks unremarkable statically can still produce runaway activation values at runtime. Activation capture is what turns "is this tensor's static distribution reasonable" into "is this tensor's actual runtime behavior reasonable," which is a materially different - and often more diagnostic - question.
A common pattern: NaN provenance
A NaN discovered in a checkpoint's weights (see NaN and Inf Detection) tells you it exists. A NaN breakpoint on activations during a captured forward pass is usually what tells you where it was first introduced - which is a very different, and often much more useful, question during debugging.
Related resources
- Runtime Traces - the capture mechanism this page applies to activations specifically.
- Gradients - the backward-pass counterpart to activation capture.
- NaN and Inf Detection - using an activation breakpoint to trace a NaN to its source.