Say I have an the output of y=model(x) where y.size() is [batch_dimensions, 1]. I would then like to calculate the individual gradients of each example in the output with respect to the model.parameters(). Naively, I could do:

grads = [torch.autograd.grad(y[batch], model.parameters(), retain_graph=True) batch in range(batch_dimensions)]

which is an awful lot faster. However, this seems to sum the gradients across the batches, which is not quite what I want. How could I possibly achieve what I require efficiently?

@roylight, could I ask about your use case for individual per-example gradients?

To answer your question, cybertronai/autograd-hacks donâ€™t support PyTorchâ€™s nn.LSTM out of the box, but if you write a custom LSTM (using nn.Linear, some activation functions, and a for-loop), cybertronai/autograd-hacks should be able to help (there is an implementation for per-sample-gradients of nn.Linear in there).

Indeed, it doesnâ€™t support anything other than Conv/Linear, so would need some work. In ideal world, an autovectorization operation would be able to do this automatically, but right now it seems manual algebra is required.

@richard one common demand for per-example gradient norms is from privacy people â€“ a datapoint with a large gradient could influence the final solution strongly, so you could â€śleakâ€ť information about that datapoint through the final model.

@Yaroslav_Bulatov weâ€™re working on prototyping an auto-vectorization operation like JAXâ€™s vmap (https://github.com/pytorch/pytorch/issues/42368) in the hopes that it may be able to compute per-sample-gradients (among other use cases). Thereâ€™s a slight problem where it doesnâ€™t quite work for the per-sample-gradient use case, because of how PyTorch internals are organized, but weâ€™re figuring that out.

Iâ€™m curious if youâ€™ve come across other demands for per-example gradients. Iâ€™ve spoken with some folks in the differential privacy space but havenâ€™t been able to find other use cases.

The other place is optimization research. There are thousands of papers whose implementation would benefit from efficient access to per-example gradients. Few examples â€“

Optimize faster: cluster gradients, then undersample large clusters, paper.

Find potentially mislabeled examples by checking if gradients change rapidly, paper.

Predict generalization by measuring sharpness of feasible solution. This needs variance of per-example Hessians, which are gradients of the gradient function. paper.

Popular optimizers like AdaGrad and natural gradient were formulated in terms of per-example gradients. Because frameworks didnâ€™t provide efficient way to do this, all practical implementations substituted batch gradients as an approximation.
Their derivatives (Adam, KFAC, Shampoo, full AdaGrad) ended up inheriting this approximation. What if this approximation is bad? Without per-example gradient support, itâ€™s too much work to check.

Basically this feature would make PyTorch a more friendly research platform.

PS: efficient per-example gradients (as well as per-example Hessians, Hessian vector products, per-example gradient norms, etc) are all just special cases of einsum optimization. Computation for these quantities comes down to a series of multiplications and additions, and einsum optimizer is what tells you how to properly rearrange them.

An example of using this perspective to improve on PyTorchâ€™s Hessian vector product and to compute batch of Hessian norms efficiently

Thank you for the detailed reply! Iâ€™ll take a look through the papers. This is really helpful - weâ€™re also exploring other mechanisms to compute per-example-gradients (that arenâ€™t through an auto-vectorization operator) and investigating use cases will help out with the decision making.