IMPLEMENTING PARAMETER SERVER IN NETWORKING INFRASTRUCTURE FOR HIGH-PERFORMANCE COMPUTING
1. A method, comprising:
- executing a distributed deep learning (DL) model training process to train model parameters of a DL model using a plurality of worker nodes executing on one or more server nodes of a computing system; and
executing a parameter server within a networking infrastructure of the computing system to aggregate local model parameters computed by the plurality of worker nodes and to distribute aggregated model parameters to the plurality of worker nodes using the networking infrastructure of the computing system.
Techniques are provided for implementing a parameter server within a networking infrastructure of a computing system to reduce the communication bandwidth and latency for performing communication synchronization operations of the parameter server. For example, a method includes executing a distributed deep learning (DL) model training process to train model parameters of a DL model using a plurality of worker nodes executing on one or more server nodes of a computing system, and executing a parameter server within a networking infrastructure of the computing system to aggregate local model parameters computed by the plurality of worker nodes and to distribute aggregated model parameters to the plurality of worker nodes using the networking infrastructure of the computing system.
- 1. A method, comprising:
executing a distributed deep learning (DL) model training process to train model parameters of a DL model using a plurality of worker nodes executing on one or more server nodes of a computing system; and executing a parameter server within a networking infrastructure of the computing system to aggregate local model parameters computed by the plurality of worker nodes and to distribute aggregated model parameters to the plurality of worker nodes using the networking infrastructure of the computing system.
- View Dependent Claims (2, 3, 4, 5, 6, 7, 8, 9, 10)
- 11. An article of manufacture comprising a processor-readable storage medium having stored program code of one or more software programs, wherein the program code is executable by one or more processors to implement method steps comprising:
- View Dependent Claims (12, 13, 14, 15)
- 16. A computing system, comprising:
a server cluster comprising a plurality of server nodes, wherein the server nodes comprise accelerator devices configured to execute a plurality of worker nodes to perform a distributed deep learning (DL) model training process to train model parameters of a DL model; and networking infrastructure to network connect the plurality of server nodes within the sever cluster, wherein the networking infrastructure is configured to execute a parameter server which aggregates local model parameters computed by the plurality of worker nodes and distributes aggregated model parameters to the plurality of worker nodes using the networking infrastructure of the computing system.
- View Dependent Claims (17, 18, 19, 20)
This disclosure relates generally to techniques for accelerated data processing in a high-performance computing environment.
Various types of special-purpose processors, such as graphics processing units (GPUs) for general purpose computing and other types of hardware accelerators, have been developed for accelerated processing of specific types of workloads. The processing capabilities of GPU devices and other types of hardware accelerators are currently being utilized in various applications to accelerate the processing of highly-parallelized computational workloads in various technical fields. In particular, general-purpose computing on GPU (GPGPU) is utilized for high-throughput, accelerated processing of compute kernels for workloads (e.g., vector-based computations, matrix-based computations, etc.) that exhibit data-parallelism. For example, GPIUs are used to accelerate data processing in high-performance computing (HPC) and embedded computing systems, for various applications such as financial modeling, scientific research, machine learning (ML), deep learning (DL), data mining, video data transcoding, image analysis, image recognition, virus pattern matching, augmented reality, encryption/decryption, weather forecasting, big data analytics and comparisons, and other applications with computational workloads that have an inherently parallel nature.
A distributed computing environment which comprises a large scale of shared computing resources over a cluster of computing nodes is typically utilized to support emerging applications such as big data analytics and DL model training applications. A distributed DL model training task requires the collection, storage, and processing of a significantly large amount of data, wherein the data includes training data to build and optimize DL models, as well as model parameters of the deep learning models which are utilized for inference processing. Implementing an efficient distributed computing environment for DL training (and other HPC applications) is not trivial as the intensive computational workloads, and the massive volume of data that must be stored, streamed, prefetched, and coordinated between the shared computing resources of the distributed computing platform presents a significant challenge and practical limit on system performance and scalability.
For distributed DL training applications, an HPC system can implement a parameter server (PS) system to enable distributed and parallelized training of a deep neural network model using a cluster of worker nodes (e.g., accelerator devices such as GPU devices). A parameter server system provides a communication synchronization protocol in which multiple worker nodes involved in a parallel distributed DL training process have shared access to a recent set of model parameters of a given DL model being trained. The parameter server system provides a synchronization mechanism which involves performing an “all-reduce” operation by aggregating and averaging the processing results (subsets of computed parameters) from all parallel worker nodes, and then distributing the aggregated/averaged processing results to all worker nodes for subsequent computations. Depending on various factors such as, e.g., the amount of data that needs to be synchronized between the worker nodes, the number of worker nodes involved in the training process, the inter-node/intra-node network and hardware topology of the distributed systems, etc., the communication synchronization operations of the parameter server system can consume a significant amount of bus/network communication bandwidth, which can adversely impact the performance of the distributed DL training process.
Illustrative embodiments of the invention include methods for implementing a parameter server within a networking infrastructure of a computing system to reduce the communication bandwidth and latency for performing communication synchronization operations of the parameter server. For example, one embodiment includes a method which comprises executing a distributed DL model training process to train model parameters of a DL) model using a plurality of worker nodes executing on one or more server nodes of a computing system, and executing a parameter server within a networking infrastructure of the computing system to aggregate local model parameters computed by the plurality of worker nodes and to distribute aggregated model parameters to the plurality of worker nodes using the networking infrastructure of the computing system.
Other embodiments of the invention include, without limitation, systems and articles of manufacture comprising processor-readable storage media, which are configured to implement a parameter server within a networking infrastructure of a computing system to reduce the communication bandwidth and latency for performing communication synchronization operations of the parameter server.
Illustrative embodiments of the invention will now be explained in further detail with regard to systems and methods for implementing a parameter server system within networking infrastructure elements such as network interface cards (NICs), virtual NICs, computational switch devices, and/or virtual switches, to support high-performance computing applications such as deep learning computing. While the exemplary embodiments discussed herein can be implemented for various HPC applications in which parameter server systems are utilized to synchronize application state, for illustrative purposes, embodiments of the invention will be discussed in the context of performing DL model training for Deep Neural Network (DNN) applications in a distributed computing environment. A distributed DL model training process requires a significant use of computing resources (e.g., processor, memory, storage, and networking resources), and the communication of large amounts of data over internal system busses and/or inter-node network communication links. As explained in further detail below, the incorporation of parameter server logic within networking infrastructure elements enhances communication performance (e.g. reduces communication latency) for performing parameter synchronization operations for a cluster of accelerator devices (e.g., GPU devices) performing a distributed, data parallel DL model training task.
A DL model is typically utilized in machine learning applications for pattern recognition, image processing, and other artificial intelligence applications. A DL application can utilize a DNN, wherein a DNN comprises a feedforward artificial neural network with multiple hidden layers. A convolutional neural network (CNN) is one class of DNN which is commonly applied for analyzing images. A CNN comprises a sequence of functional layers including an input layer, an output layer, and a plurality of hidden layers between the input and output layers. The functional layers include, but are not limited to, convolutional layers, pooling layers, fully connected layers, normalization layers, etc. A convolutional layer applies a “convolution operation” to an input dataset, and passes the processing results to the next layer in the network. As is known in the art, a convolutional layer applies filters (alternatively referred to as neurons or kernels) across all regions of an input dataset, wherein each filter is spatially smaller than the full volume of the input data set. The filters of a convolutional layer each comprise a set of learnable parameters (or weights), which are learned using a DL model training process. A convolutional layer utilizes a set of filters to perform a forward pass through an input dataset, wherein each filter slides (or convolves) across the width and height of the input volume and computes dot products between the entries of the filter and the input data at any position (i.e., receptive field). In essence, the convolution layer computes an output of neurons which are connected to corresponding local regions in the input data.
A DL model can be trained using a stochastic gradient descent (SGD) training process. With SGD training, error gradient with respect to model parameters of a given DL model are calculated using multiple iterations of a backpropagation process. A backpropagation comprises a sequence of three cycles including (i) a forward process, (ii) a backward process, and (iii) a weight update process, wherein the backpropagation process is repeated for many iterations until a convergence criterion is met. A distributed SGD DL training process can be implemented in an HPC system using a data-parallel programming model in which the SGD training process is executed in parallel by a plurality of worker nodes (e.g., accelerator devices such as GPU devices) that are distributed over one or more compute nodes of the HPC system.
In data parallel training, for each iteration of a backpropagation process, a mini-batch of data samples is partitioned and evenly distributed to a plurality of worker nodes (e.g., GPU devices), which can reside on the same or different server machines. With data parallelism, each worker node has access to a complete copy of a current state of the DL model, but for each iteration, each worker node is only assigned a subset of the data samples of a current mini-batch for processing. For each iteration, each worker node executes kernel functions (via GPU devices) to perform a forward propagation of the DL network model using its respective subset of data samples, followed by an error backpropagation process to compute the gradient of the loss with respect to the DL model parameters. The worker nodes perform the forward and backward propagation operations on their respective subsets of a given mini-batch dataset in parallel. The gradient parameters computed by all worker nodes for the given iteration are then aggregated/synchronized (e.g. averaged) and the averaged gradient parameters are pushed to each worker node so that each worker node can perform a parameter update process using the averaged gradient parameters to update the model parameters of the DL network model.
Various distributed system configurations can be implemented to aggregate/synchronize the model parameters, and push the averaged gradient parameters to each worker node to perform the distributed DL model training process. In one embodiment, a DL model training process can be implemented using a parameter server system to perform distributed and parallelized SGD training of a DL model using a cluster of accelerator devices (e.g., GPU device). For example,
The distributed computing system 100 comprises a parameter server system 110 comprising a plurality (S) of parameter server nodes 110-1, 110-2, . . . , 110-S (collectively, parameter servers 110), a bus/communication network 120, and a worker node cluster 130 comprising a plurality (N) of worker nodes 130-1, 130-2, . . . , 130-N (collectively, worker nodes 130). The parameter server nodes 110-1, 110-2, . . . , 110-S manage a respective set of globally shared model parameters 112-1, 112-2, . . . , 112-S. The worker nodes 130-1, 130-2, . . . , 130-N comprise respective accelerator devices 132-1, 132-2, . . . , 132-N (collectively, accelerator devices 132.). The accelerator devices 132 can be any type of processor (e.g., central processing unit (CPU), GPU, etc.) which is capable of performing high performance computing functions for the target application.
The term “processor” as used herein is intended to be broadly construed so as to include any type of processor that performs processing functions based on software, hardware, firmware, etc. For example, a “processor” is broadly construed so as to encompass all types of hardware processors including, for example, (i) general purpose processors which comprise “performance cores” (e.g., low latency cores), and (ii) workload-optimized processors, which comprise any possible combination of multiple “throughput cores” and/or multiple hardware-based accelerators. Examples of workload-optimized processors include, for example, multicore CPUs, GPUs, digital signal processors (DSPs), system-on-chip (SoC), application-specific integrated circuits (ASICs), and field programmable gate array (FPGAs), tensor processing units (TPUs), and other types of specialized processors or coprocessors that are configured to execute one or more fixed functions. The term “hardware accelerator” broadly refers to any hardware that performs “hardware acceleration” to perform certain functions faster and more efficient than is possible for executing such functions in software running on a more general-purpose processor.
Each worker node 130-1, 130-2, . . . , 130-N within the cluster 130 manages a worker process which is executed by a respective accelerator device 132-1, 132-2, . . . , 132-N. A worker process can be implemented as a bare metal process, or a virtual process (e.g., a virtual machine, container application, etc.). While the parameter server system 110 can be implemented on a single compute node to store and manage all parameters of a DL model in the single node,
In some embodiments, the parameter server nodes 110 and the worker nodes 130 of the distributed system 100 are separate logical nodes which execute on the same physical node (e.g., server node). In other embodiments, the parameter server nodes 110 and the worker nodes 130 of the distributed system 100 are separate logical nodes which are distributed and executed across two or more different physical nodes (e.g., different server nodes). In this regard, the bus/communication network 120 comprises backbone networking infrastructure and communication protocols to implement one or more of various types of intra-node and/or inter-node connection topologies and communication protocols that are utilized to physically connect, and enable communication between, the hardware processor resources which execute the functions of the parameter server nodes 110 and the worker nodes 130.
For example, the intra-node connection topologies within a given physical server node can be implemented using various communication protocols such as a Remote Direct Memory Access (RDMA) protocols, an InfiniBand (IB) protocol, a Peripheral Component Interconnect Express (PCIe) protocol, a NVIDIA® NVLink™ protocol, NVIDIA GPUDirect, and other point-to-point serial interconnect protocols that enable, e.g., CPU-GPU and GPU-GPU communication.
Furthermore, a given server node may implement the QuickPath Interconnect (QPI) protocol, which is a point-to-point processor interconnect framework that enables a Non-Uniform Memory Access (NUMA) architecture for a cluster of processors, etc. The inter-node connection topologies between different physical server nodes and the types of inter-node communication protocols that are used by the server nodes for network communication can include, but are not limited to, communication protocols such as TCP/IP, Gigabit Ethernet (GbE) (e.g., 10/25/40/100 GbE), RDMA, IB, Message Passing Interface (MPI), etc.
The deep learning computing platform 50 comprises a softvare platform to support deep learning tasks such as DL model training and inference processing (or classification), which are executed on the distributed computing system 100. The deep learning computing platform 50 can be implemented using known commercially available machine learning platforms such as Tensorflow, Microsoft Cognitive Toolkit (CNTK), Apache MXNet, Caffe, and other open-source deep learning frameworks that are configured to train, and deploy deep neural networks for HPC applications. The deep learning model layer 52 can implement one or more different types of models such as CNN models, recurrent neural network (RNN) models, region-based CNN (R-CNN) models, faster R-CNN models, mask R-CNN models, and other state-of-the-art DL models that are commonly utilized for high-performance DL computing applications.
The deep learning compute module 54 comprises software libraries and application programming interfaces (APIs) of one or more deep learning frameworks (e.g., Tensorflow NTIK, MXNet, etc.), which include pre-written code, classes, procedures, scripts, configuration data, etc., which (i) can be called or otherwise utilized by the accelerator devices 132-1, 132-2, . . . , 132-N (e.g., GPU devices) of the respective worker nodes 130-1, 130-2, . . . , 130-N executing machine learning tasks and related functions, or which (ii) are utilized by control functions executing on host processor devices to access or communicate with the accelerator devices 132-1, 132-2, . . . , 132-N through the accelerator device drivers 56. The types of software libraries and APIs of the deep learning compute module 54 will vary depending on the particular framework of the deep learning computing platform 50.
For example, the deep learning compute module 54 can implement commercially available library and/or API platforms such CUDA®, which is a parallel computing platform and application programming interface created by NVIDIA. The CUDA API enables the use of CUDA-enabled GPUs for general purpose processing. The CUDA platform is a software layer that allows direct access to the instruction set and parallel computational elements of a GPU, for executing compute kernels. In particular, the NVIDIA CUDA API comprises the CUDA® Deep Neural Network library (cuDNN) library and the NVIDIA cuBLAS library. As is known in the art, cuDNN is a GPU-accelerated library of primitives for deep neural networks, which provides implementations for standard routines such as forward and backward propagation operations in DL models comprising convolution layers, pooling layers, normalization layers, activation layers, etc. The cuDNN library is utilized by various deep learning frameworks, such as Tensorflow, CNTK, MXNet, Keras, and Caffe, to support high-performance GPU acceleration. The NVIDIA cuBLAS library is a fast GPU-accelerated implementation of the standard basic linear algebra subroutines (BLAS). The cuBLAS APIs allow an application to be accelerated by deploying compute-intensive operations to a single GPU or distributing work across multi-GPU configurations. Keras is a high-level neural network API, written in Python and capable of running on top of TensorFlow and CNTK. In one embodiment, the accelerator device driver layer 56 comprises GPU drivers that are implemented using cuDNN.
In some embodiments, the deep learning computing platform 50 implements methods to perform a distributed SGD training process to train DL models using a data-parallel training process executed on the distributed computing system 100. As noted above, with a SGD training process, error gradients are computed for the model parameters of a DL model being trained using multiple iterations of a backpropagation process which comprises a sequence of three cycles including (i) a forward process, (ii) a backward process, and (iii) a weight update process, wherein the backpropagation process is repeated for many iterations until a convergence criterion is met. Each iteration of the backpropagation process is performed on a mini-batch of data, wherein a mini-batch of data comprises a subset (or portion) of a total dataset of model training data.
With a data parallel SGD model training process, the host system (not shown in
During the DL training process, the worker nodes 130-1, 130-2, . . . , 130-N execute kernel functions on the respective accelerator devices 132-1, 132-2, . . . , 132-N to perform the forward, backward, and a weight update cycles of the backpropagation process. For each iteration backpropagation process, each worker node 130-1, 130-2, . . . , 130-N utilizes its local subset of mini-batch data to execute a forward propagation process on the DL model, followed by error backpropagation to compute gradients of the loss with respect to the DL network model parameters. In particular, the feed forward operation (forward process) is performed to process the subset of mini-batch data, layer by layer, using the given DL model. Once the information reaches the final output layer of the DL model, an error signal is calculated and back propagated through the layers of the DL model using a backward process, which involves minimizing an objective function by calculating error gradients with respect to model parameters (e.g., weights) and the input data. In this manner, for the given iteration, each worker node 130 computes a set of gradients of the DL model based on its local subset of the mini-batch of training data.
Following the forward and backward operation for the given iteration, each worker node 130 will communicate with one of the parameter server nodes 110 to send the locally computed parameters (gradients) to parameter server node 110. In some embodiments, there is one parameter server node 110 for each worker node 130. In other embodiments, each parameter server node 110 is assigned to two or more worker nodes 130. Each parameter server node 130 will receive a set of locally computed parameters from one or more associated worker nodes 130. The parameter server nodes 110-1, 110-2, . . . , 110-S will then communicate with each other (via an inter-PS communication protocol) to aggregate the local parameters (e.g., compute global average gradients) and update the DL model parameters, and then push the updated DL model parameters to the worker nodes 130.
For example, in some embodiments, the parameter server nodes 110-1, 110-2, . . . , 110-S send the local computed parameters (gradients) to one of the parameter server nodes 110 (all gather operation) which is designed to perform an all-reduce operation. The designated parameter server node 110 performs an all-reduce operation on the aggregated parameters by computing an average of all the local gradients provided by the worker nodes 130 for the given DL training iteration. The globally shared parameters 112-1, 112-2, . . . , 112-S on each of the parameter server nodes 110 are then globally updated with the computed gradient average, and each parameter server node 110 pushes the global updated parameters to the worker nodes 130. The worker nodes 130 then proceed to use the global updated parameters to perform a weight update process for the given iteration of the DL model training process. In this manner, the model parameters are managed and synchronized by the plurality of cooperating parameter server nodes 110 that collectively update the globally shared model parameters 112-1, 112-2, . . . , 112-S, which are shared across the worker nodes 130. With this framework, all state that is shared among the worker nodes 130 (i.e. the DL model parameters being learned) is maintained and synchronized by the parameter server nodes 110. At the end of each iteration, each worker node 130 has a complete copy of the most recent (intermediate) DL model.
In accordance with embodiments of the invention, techniques are provided to implement a distributed parameter server system (e.g., for distributed DL model training) in a way that provides high-communication performance for communication synchronization in terms of both bus/network bandwidth and minimal latency, thereby preventing the synchronization operations of the parameter server system from becoming a bottleneck for a data parallel, distributed DL model training process, as described above. Indeed, high communication bandwidth is needed to be able to sustain the transfer of local parameters from worker nodes to parameter server nodes, and the transfer of global updated parameters from the parameter server nodes to the workers during each iteration of the DL model training process to synchronize the application state. Further, the issue of communication latency is critically important for synchronized distributed DL training, as the training process is temporarily suspended/blocked during periods in which parameter synchronization operations are being performed.
On the other hand, the implementation of a parameter server system for distributed DL model training application has a relatively low impact on computing and storage resources. Indeed, with regard to computing resources, a parameter server system performs relatively simple computations, e.g., computing averages of floating point numbers. In addition, with regard to storage resources, a given DL model comprises a set of model parameters that require about 20 megabytes (MB) to about 500 MB, or greater. In addition, in distributed frameworks where the parameters of the DL model are sharded across N nodes, each parameter server will store 1/N of the total size of the DL model.
While some parameter server systems are configured to execute the parameter server logic in host system CPU devices or in accelerator devices (e.g., GPU devices) that perform the DL training operations, these configurations are not as optimal as incorporating parameter server logic into networking infrastructure elements using techniques as discussed herein. Indeed, while CPU devices have large storage capacity, the use of CPU devices to execute parameter server logic can result in relatively low communication and low computations. Further, while GPU devices have high power computing capabilities due to the massive number of cores and parallel computation model, state of the art GPU devices have less storage capabilities as compared to CPU system memory, and similar communication capabilities as CPUs.
In this regard, executing parameter server logic within networking infrastructure elements provides enhanced communication performance as compared to CPU and GPU devices. In this configuration, the parameter server logic is close to the raw networking hardware interface with much shorter code path, allowing the parameter synchronization to occur on “wire”. In addition, dedicated networking optimized software, such as extended Berkeley Packet Filter (eBPF), eXpress Data Path (XDP), Storage Performance Development Kit (SPDK), etc., can be utilized to further reduce the latency in data traffic for sending and receiving model parameters by parameter server nodes executing in networking element to perform parameter synchronization operations. The ability to incorporate a parameter server system within a networking infrastructure of a distributed computing system is not trivial. There are various technical challenges for placing a parameter server system within the networking infrastructures, which are addressed using various methods discussed herein.
For example, with regard to configuration and management, techniques are provided to configure a parameter server within networking infrastructure elements (e.g., NICs, I/O adaptors, converged Ethernet adaptors, switches, virtual NICs, virtual switches, etc.) and expose the parameter server to various upper layers of a DL computing platform. In addition, the inter-node and intra-node communications/interactions between worker nodes and parameter server nodes in the networking infrastructure should be seamless and efficient. In addition, the selection of communication protocols to optimize data transfer and minimize latency is an important factor to consider for achieving high communication performance. Indeed, the faster the DL training operation executes, the higher demand there is on communication bandwidth. In this regard, embodiments of the invention leverage various communication protocols such as DMA, RDMA, XDP, etc., to minimize latency in parameter synchronization operations. In addition, techniques for implementing a parameter server system within a networking infrastructure are designed to provide a flexible and scalable worker node deployment configuration which can accommodate a bare metal or a virtualization (e.g., container, virtual machine, etc.) environment for worker nodes.
In this regard, embodiments of the invention provide techniques to implement a “PS-in-networking” system in which a parameter server system is incorporated within a networking infrastructure of computing system. A parameter server can be implemented in a smart NIC, a virtual NIC, a computational switch, a virtual switch, etc. In addition to enhancing synchronization communication and reducing latency, a PS-in-networking system provides various advantages. For example, a PS-in-networking system provides good scalability wherein each worker node can have a smart NIC that executes a parameter server node, allowing parameter synchronization to scale as more worker nodes are added. In addition, by offloading the parameter server logic from a host CPU or accelerator device (e.g., GPU), the CPU can focus on executing functions such as data pre-processing and pipeline management, and the GPU devices can focus on executing DL training operations.
Furthermore, current state-of-the-art smart NIC devices by design are network optimized and perform various functions such as TCP offloading (via a TCP offload engine (TOE)), real-time data compression/encryption, and other hardware accelerator functions. As such, smart NIC devices can readily perform the computation functions (e.g., averaging gradient parameters) of a parameter server without impacting the other tasks that may be concurrently performed by the NIC device. Further, a PS-in-networking system can be configured to leverage virtualization functionalities, such as single root input/output virtualization (SR-IOV), etc., in a virtualized environment. As is known in the art, SR-IOV is a specification that allows a single physical PCIe resource to be shared in a virtual environment. In this manner, worker nodes can run in a virtualization environment (e.g., container, or virtual machine), which allows a smart NIC to utilize the SR-IOV protocol to enhance communications between parameter server nodes and worker nodes.
In addition, each compute node 210-1 and 210-2 comprises a plurality of GPU devices 220 (e.g., GPU0 and GPU1) and respective network interface cards (NICs) 230-1 and 230-2. The GPU devices 220 comprise GPU cores 222 and GPU memory 224. The NICs 230-1 and 230-2 execute respective parameter server (PS) nodes 240-1 and 240-2. Each compute node 210-1 and 210-2 comprises an intra-node connection topology 250 to connect the CPU devices 212-1 and 212-2 to the respective GPU devices 220, and to connect the CPU devices 212-1 and 212-2 and GPU devices 220 to the respective NIC devices 230-1 and 230-2. The intra-node connection topology 250 within the compute nodes 210-1 and 210-2 can be implemented using various communication protocols such as a DMA, IB, PCIe, NVLink, GPUDirect, and other point-to-point serial interconnect protocols that enable, e.g., CPU-GPU communication, GPU-GPU communication, GPU-NIC communication, and CPU-NIC communication.
The distributed HPC system 200 is configured to perform a distributed SGD training process to train DL models using a data-parallel training process executed on the distributed computing system 200, which is the same or similar to the DL training process discussed above for
During a DL training process, the CPU devices 212-1 and 212-2 will access mini-batches of a training dataset from the respective persistent storage systems 214-1 and 214-2, and store the mini-batches of data in the respective system memories 216-1 and 216-2. For a given iteration of a DL training process, a mini-batch of data (M data samples) is accessed from each system memory 216-1 and 216-2 and evenly distributed among the two (2) GPU worker nodes 220 on each compute node 210-1 and 210-2 such that M/2 data samples of the given mini-batch of data are stored in the GPU memory 224 of the GPU devices 220 of each compute node 210-1 and 210-2.
Each worker node process being executed by the GPU devices 220 will execute DL model training kernel functions using the GPU cores 222 to process a local subset of a given mini-batch of training data for the given iteration to compute local model parameters (e.g., gradients). The GPU devices 220 on the compute node 210-1 will communicate with the local parameter server node 240-1 executing on the NIC device 230-1 to transfer the local processing results (e.g., computed gradients) to the local parameter server node 240-1. Similarly, the GPU devices 220 on the compute node 210-2 will communicate with the local parameter server node 240-2 executing on the NIC device 230-2 to transfer the local processing results (e.g., computed gradients) to the local parameter server node 240-2.
The local parameter server nodes 240-1 and 240-2 communicate over the inter-node network 260 to aggregate the local processing results and synchronize the global aggregated processing results with all worker nodes. In some embodiments, one of the parameter server nodes 240-1 and 240-2 is designated as a master parameter server node which is configured to receive the local processing results from all parameter server nodes, perform an all-reduce operation to aggregate the local process results to generate a global set of parameters (global reduced parameters) and then distribute the global set of parameters to each local parameter server node to copy the global parameters to the memory of the GPU device executing the worker nodes.
In the example embodiment of
The multi-core SoC 302 implements network interface circuitry to support multiple network input/output (I/O) ports 312 for inter-node network communication. The I/O network ports 312 can implement network communication protocols such as TCP/IP, GbE, 10/25/40/100 GbE), RDMA, IB, etc. In addition, multi-core SoC 302 implements network interface circuitry to support one or more I/O ports 314 for intra-node network communication (e.g., PCIe, etc.).
The multi-core SoC 302 is connected to the configurable memory interface circuitry 304 via an internal communication bus 316 (e.g., PCIe x4 communication bus). In one embodiment, the configurable memory interface circuitry 304 comprises a FPGA device which can be configured to provide a memory interface to various types of memory devices 306 and 308 located on the NIC 300. The configurable memory interface circuitry 304 is connected to the memory devices 306 and 308 using memory buses 318. The configurable memory interface circuitry 304 can be configured to provide a memory interface to various types of remote memory devices (not residing on the NIC 300), which are connected via an alternative interface communication buses 320.
The on-board memory devices 306 and 308 include volatile memory 306 and non-volatile memory 308, which are utilized to store program instructions that are read and processed by the multi-core SoC 302 to execute a native operating system and one or more logic node functions (e.g., parameter server 302-1) and to temporarily store data that is utilized and/or generated by the native OS and application programs running on multi-core SoC 302. For example, the volatile memory 306 may be a dynamic random-access memory (e.g., DRAM) or other forms of volatile random-access memory. The non-volatile memory 308 may comprise a flash storage device, a SSD (solid-state drive) device, or other types and combinations of non-volatile memory. The memory devices 306 and 308 other memory or storage media as described herein, which have program code and data tangibly embodied thereon, are examples of what is more generally referred to herein as “processor-readable storage media” that store executable program code of one or more software programs. Articles of manufacture comprising such processor-readable storage media are considered embodiments of the invention. An article of manufacture may comprise, for example, a storage device such as a storage disk, a storage array or an integrated circuit containing memory. The term “article of manufacture” as used herein should be understood to exclude transitory, propagating signals.
In one embodiment, the multi-core SoC 302 comprises a multi-core processor with a reduced instruction set computing (RISC) architecture. For example, the multi-core SoC 302 may be a 64-bit ARM (Advanced RISC machine) multi-core processor (e.g., ARMv8), a 64-bit MIPS (Microprocessor Without Interlocked Pipeline Stages) multi-core processor, a RISC-V multi-core processor, etc. The multi-core SoC 302 can run any suitable operating system such as a 64 bit Linux kernel. When the IP address for the NIC 300 is configured, the NIC 300 can be accessed and managed using a suitable security protocol such as SSH (Secure Shell), or other methods to securely access remote Linux systems. The core logic of the parameter server 302-1 can execute in user space, or in kernel space by leveraging a high-performance in-kernel traffic processing framework such as XDP or eBPF. The XDP protocol provides a high performance, programmable network data path in a Linux kernel by supporting bare metal packet processing at a lowest level in the software stack.
Various configuration and management protocols can be utilized to enable PS-in-networking systems according to embodiments of the invention. For example, a deep learning computing platform (e.g., DL computing platform 50,
As is known in the art, a “socket” is a one endpoint of a two-way communication link between two programs running on a network. A socket is bound to a port number so that the TCP layer can identify the application to which data should be sent. An endpoint (or socket) is defined by a combination of an IP address and a port number. The following configuration file illustrates an exemplary method for configuring different ports (port A and port B) to distinguish functions between worker nodes and a parameter server node executing in a network element, using an XML or JSON-like configuration file:
The initialization stage is configured to define a number (P) of parameter server nodes to implement for the distributed parameter server system. As noted above, for balanced communication, the global parameters maintained by a parameter server can be partitioned among multiple parameter server nodes in a distributed manner, which serves to reduce memory usage of each parameter server node, and to reduce the communication traffic to/from the parameter server nodes. For example, assume that the total size of a parameter set of a given DL model is N bytes, and that there are P parameter servers, ideally, each parameter server node will manage N/P bytes of the total size of the parameter set.
In addition, as part of the initialization stage, at least one parameter server node can be designed as “master” parameter server node that is responsible for performing various functions such as (i) collecting (all gather operation) all sets of local parameters (e.g., gradients) computed by all worker nodes for a given mini-batch of training data in a given iteration of a SGD training process, (ii) aggregate the sets of local parameters by, e.g., computing average values among the local gradients computed by the worker nodes and (iii) send the aggregated parameter set (averaged values) to all workers nodes through a broadcast communication. Furthermore, among all worker/parameter server nodes, at least one worker node can be designated as a master worker node which is responsible for model initialization, mini-batch synchronization (notifying all parameter servers), and saving the final result of an intermediate DL model.
After the initialization stage is complete, and the parameter server nodes of the distributed parameter server are configured within the networking infrastructure of the computing system, each network element (e.g., smart NIC) that executes a parameter server node during real-time operation (running stage) will start a daemon thread on a specified port for the PS service, allocate memory for the global parameters assigned for handing by the PS service, and initialize the values (may be zero or randomized). The daemon thread generates control messages to perform and/or trigger functions such as, e.g., result dumping, forcing shutdown, providing notification events for mini-batch processing completion, etc. Once a training process is deemed to be complete (based on some pre-defined criterion such as meeting a maximum number of epochs/iterations of the DI, model training resulting in a DL model having a classification accuracy that meets a specified classification accuracy threshold), the parameters of the DL model can be saved by the master worker/parameter server nodes.
Furthermore, the local parameter server node 440 (acting as the master PS) receives the local processing results of all other worker nodes operating on remote host nodes, wherein such local processing results are transmitted from remote parameter server nodes operating in network elements on the remote host nodes (step 3). In one embodiment, a RDMA process is utilized to directly transfer (device-to-device memory copy operation) the local processing results of remote worker nodes from the memories of remote network elements (e.g., NIC devices) executing the remote parameter server nodes, to the target region in memory of the network element 430 which is assigned to store the parameters managed by the local parameter server node 440.
Next, the local parameter server node 440 operating as the master PS performs a parameter aggregation process using an average( ) method to compute average of all the local processing results received from the local worker nodes 420 and remote worker nodes executing on remote host nodes (step 4). If a remote host node comprises multiple worker nodes that compute local processing results, the local parameter server node executing in the network element of the remote host node will not separately send the local processing results to the master PS 440. Instead, the local parameter server node of the remote host node will perform a local aggregation process by computing an average of the local processing results of the multiple worker nodes operating on the remote host node, and then transmit the local-aggregated result to the master PS 440. The local aggregation of local processing results of multiple worker nodes in a host node serves to reduce the network traffic and communication bandwidth needed to transmit the local processing results of all worker nodes to the master PS 440 for the all-reduce operation.
Once the global aggregated processing results are computed by the master PS 440, the global aggregated processing results are broadcast (via, e.g., RDMA) to all other remote parameter server nodes of the distributed parameter server system integrated within the networking infrastructure of the distributed computing system (step 5), wherein the global aggregated processing results can then be transferred to the worker nodes executing on remote host nodes. In addition, the master PS 440 will transmit the global aggregated processing results (via, e.g., DMA) from the memory of the network element 430 to the memory of the processor devices which execute the local worker node(s) 430 (step 6).
In another embodiment, data compression methods can be utilized to compress the local processing results (e.g. after local aggregation) which are transmitted to the master PS using, for example, embedded data compression/decompression engines (e.g., compression engine 320-3,
In the example embodiment of
In one embodiment, the virtual worker nodes 510-1, 510-2, . . . , 510-V comprise virtual machines that are implemented using a hypervisor platform which executes on the host node 500, wherein the virtual machines are instantiated to implement the functions of the multiple virtual worker nodes. As is known in the art, virtual machines are logical processing elements that may be instantiated on one or more physical processing elements (e.g., servers, computers, or other processing devices). That is, a “virtual machine” generally refers to a software implementation of a machine (i.e., a computer) that executes programs in a manner similar to that of a physical machine. Thus, different virtual machines can run different operating systems and multiple applications on the same physical computer. A hypervisor is an example of what is more generally referred to as “virtualization infrastructure.” The hypervisor runs on physical infrastructure, e.g., CPUs and/or storage devices, of the host node 500, and emulates the CPUs, memory, hard disk, network and other hardware resources of a host system, enabling multiple virtual machines to share the resources. The hypervisor can emulate multiple virtual hardware platforms that are isolated from each other, allowing virtual machines to run, e.g., Linux and Windows Server operating systems on the same underlying physical host. An example of a commercially available hypervisor platform that may be used to implement one or more of the virtual machines in one or more embodiments of the invention is the VMware® vSphere™ which may have an associated virtual infrastructure management system such as the VMware® vCenter™. The underlying physical infrastructure may comprise one or more commercially available distributed processing platforms which are suitable for the target application.
In another embodiment, the virtual worker nodes 510-1, 510-2, . . . , 510-V comprise containers such as Docker containers or other types of Linux containers (LXCs). As is known in the art, in a container-based application framework, each application container comprises a separate application and associated dependencies and other components to provide a complete filesystem, but shares the kernel functions of a host operating system with the other application containers. Each application container executes as an isolated process in user space of a host operating system. In particular, a container system utilizes an underlying operating system that provides the basic services to all containerized applications using virtual-memory support for isolation. One or more containers can be instantiated to execute data parallel training functions on the host node 500. In yet another embodiment, containers may be used in combination with other virtualization infrastructure such as virtual machines implemented using a hypervisor, wherein Docker containers or other types of LXCs are configured to run on virtual machines in a multi-tenant environment.
The compute nodes 610-1 and 610-2 comprise compute clusters 620, wherein each compute cluster 620 comprises a plurality of worker nodes 620-1 and 620-2 which execute on processor devices (e.g., CPUs, GPUs, etc.). The cluster of worker nodes 620-1 and 620-2 in each compute node 610-1 and 610-2 is connected to a respective NIC device 640-1 and 640-2 using an intra-node communication bus 630.
In the example embodiment, a network switch 650 connected to, and part of the inter-node communication network 660 executes a parameter server 650-1. In one embodiment, the network switch 650 comprises a computational (smart) switch that is coupled to the respective NIC devices 640-1 and 640-2 to network connect the compute nodes 610-1 and 610-2. The computational switch 650 implements standard switching functions, as well as data computation processing and networking functions using high performance processor devices (e.g., SoC, CPU, CPU and GPU, etc.) with either multiple 100G or one 200G (or 400G, in the future) connectivity, connected directly to switch ASICs. The close proximity of the compute nodes 610-1 and 610-2 to the computational switch 650, coupled with the high processing power and high I/O port bandwidth of the NIC devices 640-1 and 640-2 and the switch 650, readily enables a PS-in-networking configuration in which the computational switch 650 can host a parameter server node (e.g., master PS node), while significantly reducing network bandwidth communication and latency associated with the synchronization functions performed by the parameter server 650-1.
In summary, PS-in-networking techniques as disclosed herein can be readily leveraged in state-of-the-art networking hardware used in data center configurations, to provide increased communication efficiency (e.g., latency and bandwidth) as compared to conventional systems in which parameter servers are executed in CPU or GPU devices. In addition, PS-in-networking systems according to embodiments of the invention provide good scalability, allow offloading of parameter server functions from CPU and GPU devices, and provide flexible configurations to support bare metal and virtualization environments.
It is to be understood that the above-described embodiments of the invention are presented for purposes of illustration only. Many variations may be made in the particular arrangements shown. For example, although described in the context of particular system and device configurations, the techniques are applicable to a wide variety of other types of information processing systems, computing systems, data storage systems, processing devices and distributed virtual infrastructure arrangements. In addition, any simplifying assumptions made above in the course of describing the illustrative embodiments should also be viewed as exemplary rather than as requirements or limitations of the invention. Numerous other alternative embodiments within the scope of the appended claims will be readily apparent to those skilled in the art.