Posted by Goldie Gadde and Nikita Namjoshi for the TensorFlow Team
and custom training loops. Like MultiWorkerMirroredStrategy, ParameterServerStrategy is a multi-worker data parallelism strategy; however, the gradient updates are asynchronous.
A parameter server training cluster consists of workers and parameter servers. Variables are created on parameter servers and then read and updated by workers during each step. The reading and updating of variables happens independently across the workers without any synchronization. Because the workers do not depend on one another, this strategy has the benefit of worker fault tolerance and is useful if you use preemptible VMs.
To get started with this strategy, check out the class to dispatch the execution of training steps to remote workers.
Multi Worker Mirrored Strategy
, MultiWorkerMirroredStrategy implements distributed training with synchronous data parallelism. However, as the name suggests, with MultiWorkerMirroredStrategy you can train across multiple machines, each with potentially multiple GPUs.
In synchronous training, each worker computes the forward and backward passes on different slices of the input data, and the gradients are aggregated before updating the model. For this aggregation, known as an
To get started with MultiWorkerMirroredStrategy, check out the callback.
If you are new to distributed training and want to learn how to get started, or you’re interested in distributed training on GCP, has moved out of experimental and is now a stable API. Most TensorFlow models use the float32 dtype; however, there are lower-precision types such as float16 that use less memory. Mixed precision is the use of 16-bit and 32-bit floating point types in the same model for faster training. This API can improve model performance by 3x on GPUs and 60% on TPUs.
To make use of the mixed precision API, you must use Keras layers and optimizers, but it’s not necessary to use other Keras classes such as models or losses. If you’re curious to learn how to take advantage of this API for better performance, check out the class, enabling users of model.fit or custom training loops to write training code that works with any optimizer.All built-in tf.keras.optimizer.Optimizer subclasses now accept gradient_transformers and gradient_aggregator arguments, allowing you to easily define custom gradient transformations.
With the refactor, you can now pass a loss tensor directly to Optimizer.minimize when writing custom training loops:
PYTHON
tape = tf.GradientTape() with tape: y_pred = model(x, training=True) loss = loss_fn(y_pred, y_true)
# You can pass in the `tf.GradientTape` when using a loss `Tensor` as shown below.
These changes are intended to make both Model.fit and custom training loops more agnostic to optimizer details, allowing you to write training code that works with any optimizer without modification.
Functional API model construction internal improvements
Lastly, TensorFlow 2.4 includes a major refactoring of the internals of the Keras Functional API, improving the memory consumption of functional model construction and simplifying triggering logic. This refactoring also ensures TensorFlowOpLayers behave predictably and work with CompositeTensor type signatures.
Introducing tf.experimental.numpy
TensorFlow 2.4 introduces . This module enables you to run NumPy code, accelerated by TensorFlow. Because it is built on top of TensorFlow, this API interoperates seamlessly with TensorFlow, allowing access to all of TensorFlow’s APIs and providing optimized execution using compilation and auto-vectorization. For example, TensorFlow ND arrays can interoperate with NumPy functions, and similarly TensorFlow NumPy functions can accept inputs of different types including tf.Tensor and np.ndarray.
def grad(x, wt): with tf.GradientTape() as tape: tape.watch(wt) output = tnp.dot(x, wt) output = tf.sigmoid(output) return tape.gradient(tnp.sum(output), wt)
You can learn more about how to use this API in the is a suite of tools you can use to measure the training performance and resource consumption of your TensorFlow models. The TensorFlow Profiler helps you understand the hardware resource consumption of the ops in your model, diagnose bottlenecks, and ultimately train faster.
Previously, the TensorFlow Profiler supported monitoring multi-GPU, single host training jobs. In 2.4 you can now profile MultiWorkerMirroredStrategy training jobs. For example, you can use the to choose a training step and view its step-time category breakdown across all workers.
. This guide shows common scenarios you might encounter when you profile your model training job and provides a debugging workflow to help you get better performance, whether you’re training with one GPU, multiple GPUs, or multiple machines. TFLite Profiler
The TFLite Profiler enables tracing TFLite internals in Android to identify performance bottlenecks. The
New Features for GPU Support
TensorFlow 2.4 runs with CUDA 11 and cuDNN 8, enabling support for the newly available NVIDIA Ampere GPU architecture. To learn more about CUDA 11 features, check out this .
Next steps
Check out the , follow . If you’ve built something you’d like to share, please submit it for our Community Spotlight at . Thank you!
Vollständiger Original-Bericht
Ausführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf blog.tensorflow.org.
SOCIAL SHARE CARD GENERATOR