Printing the loss during TensorFlow training
ML System Design practice on Codemia
Design recommenders, ranking systems and training pipelines the way ML interviews actually ask for them, with worked solutions.
Introduction
Printing loss during training is one of the fastest ways to verify that a TensorFlow model is actually learning. The right method depends on whether you are using the high-level Keras training loop or a custom GradientTape loop, but in both cases the goal is the same: observe the loss at a cadence that is useful without flooding the console.
Keras Already Prints Loss
If you use model.fit, TensorFlow can print loss automatically through the verbose setting.
With verbose=1, Keras prints per-epoch progress, including the loss. That is often enough for ordinary training.
Custom Callback for Cleaner Output
If you want exactly one formatted line per epoch, use a callback.
This is useful when you want stable, minimal logging or when you also want to print validation loss or custom metrics.
Printing Per Batch
For more granular debugging, print the loss at the end of each batch:
Per-batch logging is helpful when:
- debugging exploding gradients
- checking that loss changes within an epoch
- diagnosing a data pipeline issue
But it becomes noisy quickly on real datasets.
Custom Training Loop
If you are not using model.fit, print the loss directly from the custom training loop.
This gives you complete control over what is printed and when.
tf.print Inside Graph Code
If your training step is wrapped in @tf.function, plain Python print may not behave the way you expect. In those cases, use tf.print.
tf.print is designed to work correctly inside TensorFlow graph execution.
Logging Validation Loss Too
For many real experiments, training loss alone is not enough. Add validation data to fit so Keras also reports val_loss:
That gives you a better signal about whether the model is merely fitting the training set or actually generalizing.
Common Pitfalls
The most common mistake is printing too often. Per-batch loss on a large dataset can overwhelm logs and slow training enough to distort the debugging session.
Another issue is assuming the printed loss should always decrease every single step. Stochastic training is noisy, so the overall trend matters more than every individual line.
A third pitfall is using Python print inside graph-traced code and then assuming nothing happened because no output appeared. In graph contexts, prefer tf.print.
Finally, do not monitor only training loss forever. Once the loop is basically working, add validation loss too, because a falling training loss can still hide overfitting.
Summary
- '
model.fit(..., verbose=1)already prints loss for standard Keras training.' - Use callbacks when you want custom epoch or batch logging.
- In custom loops, print the loss directly after each update step.
- Use
tf.printinside graph-traced TensorFlow functions. - Monitor the loss at a useful cadence rather than dumping every possible value.
Related reading
- Problem with running object_detection_tutorial TypeError load missing 2 required positional arguments
- Problems implementing an XOR gate with Neural Nets in Tensorflow
- Processing time gets longer and longer after each iteration TensorFlow
- Produce balanced mini batch with Dataset API
- Probability and Neural Networks
- Probability prediction method of KNeighborsClassifier returns only 0 and 1
- Printing thread id in log file using log4j
- Problem with dynamic persistent volume in Helm

System Design Fundamentals
Build a strong foundation in designing scalable, reliable distributed systems.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
ML System Design practice on Codemia
Design recommenders, ranking systems and training pipelines the way ML interviews actually ask for them, with worked solutions.