Introduction

torch.no_grad() and requires_grad=False both affect gradient tracking, but they solve different problems. torch.no_grad() is a temporary context that tells PyTorch not to build autograd history for operations executed inside the block. requires_grad=False is a tensor or parameter property that says a particular tensor should not receive gradients.

Use torch.no_grad() for inference-time graph suppression

A common inference pattern is:

1import torch
2
3model.eval()
4
5x = torch.randn(4, 10)
6with torch.no_grad():
7    y = model(x)

Inside the no_grad block, PyTorch does not build the computation graph for those operations. That reduces memory usage and usually speeds up evaluation.

This is why torch.no_grad() is the standard answer for validation and inference code.

Use requires_grad=False to freeze specific parameters

If you want a tensor or model parameter not to receive gradients during training, set its flag:

for param in model.backbone.parameters():
    param.requires_grad = False

This is common in transfer learning when you want to freeze a pretrained backbone and train only a classification head.

The key difference is scope:

• 'torch.no_grad() affects operations inside a code block'
• 'requires_grad=False affects specific tensors or parameters'

These tools can be used together

You can freeze parameters and still run normal training on the remaining trainable layers. You can also use torch.no_grad() during evaluation even if some parameters normally require gradients during training.

Example transfer-learning setup:

1for param in model.backbone.parameters():
2    param.requires_grad = False
3
4optimizer = torch.optim.Adam(model.classifier.parameters(), lr=1e-3)

And later, evaluation:

model.eval()
with torch.no_grad():
    logits = model(inputs)

These are complementary, not competing, mechanisms.

Freezing parameters is not the same as disabling autograd globally

Suppose a layer's parameters have requires_grad=False, but you run forward propagation outside torch.no_grad(). PyTorch may still track graph information for other trainable tensors in the computation.

So freezing parameters does not automatically mean "no graph will be built anywhere." It only means those specific tensors are not asking for gradients.

That distinction matters when debugging memory usage. If you want no autograd tracking for a full evaluation pass, torch.no_grad() is still the right tool.

Optimizers and frozen parameters

If a parameter has requires_grad=False, it will not accumulate a gradient. In practice, optimizers usually ignore it because there is no gradient to apply.

Still, it is often cleaner to pass only trainable parameters to the optimizer. That makes intent explicit and avoids unnecessary bookkeeping.

model.eval() is separate again

A lot of confusion comes from mixing gradient control with evaluation mode. model.eval() changes the behavior of layers such as dropout and batch normalization. It does not disable autograd by itself. That is why inference code often needs both model.eval() and torch.no_grad() together.

Common Pitfalls

The most common mistake is using requires_grad=False on model parameters and assuming that automatically replaces torch.no_grad() for inference. It does not.

Another common issue is wrapping training code in torch.no_grad() accidentally, which prevents gradients from being built and breaks backpropagation.

People also forget that model.eval() is separate from gradient tracking. Evaluation mode changes layer behavior such as dropout and batch normalization, while no_grad changes autograd behavior.

Finally, freezing parameters without changing the optimizer parameter list can still work, but it is often less explicit than optimizing only the trainable subset.

Summary

• 'torch.no_grad() temporarily disables autograd tracking inside a code block.'
• 'requires_grad=False freezes specific tensors or parameters.'
• Use torch.no_grad() for inference and evaluation.
• Use requires_grad=False when you want to freeze part of a model during training.
• These tools solve different problems and are often used together.