Using detach() Before Calling Metrics

[RoyiAvital]

Should I call detach() before calling metrics or is it built in?

What is the suggested way to handle this in order to be as efficient as possible memory and run time wise?

[adosar]

@RoyiAvital I am wondering the same thing but I can't find any relevant information in the documentation.

[Borda]

Good question — and you're right the docs don't spell this out.

TL;DR: TorchMetrics handles detach internally. You don't need to call .detach() before passing tensors to a metric.

Here's why: all Metric subclasses use add_state(...) to register state variables, and update() typically performs in-place additions (self.correct += ..., self.total += ...). These in-place ops on registered states don't build a computation graph back to your model's parameters. So gradients won't flow through the metric even without .detach().

Quick proof:

import torch
from torchmetrics.classification import BinaryAccuracy

preds = torch.tensor([0.8, 0.2, 0.9], requires_grad=True)
target = torch.tensor([1, 0, 1])

metric = BinaryAccuracy()
result = metric(preds, target)

print(result.requires_grad)  # False — no grad graph

When you SHOULD detach: if you're storing raw predictions/targets in a list state (e.g., for ROC curves), the tensor references could keep the computation graph alive in memory. In practice, TorchMetrics' internal state management handles this, but if you're seeing unexpected GPU memory growth, adding .detach() is a safe and cheap defensive measure:

# Safe pattern for memory-sensitive training loops
metric.update(preds.detach(), target)

It's a no-op cost-wise (detach doesn't copy data), so there's no downside.

Docs: Metric base class