Patent Publication Number: US-2020293838-A1

Title: Scheduling computation graphs using neural networks

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     This application claims priority to U.S. Provisional Application No. 62/817,971, filed on Mar. 13, 2019. The disclosure of the prior application is considered part of and is incorporated by reference in the disclosure of this application. 
    
    
     BACKGROUND 
     This specification relates to scheduling computation graphs using neural networks. Neural networks are machine learning models that employ one or more layers of nonlinear units to predict an output for a received input. Some neural networks include one or more hidden layers in addition to an output layer. The output of each hidden layer is used as input to the next layer in the network, i.e., the next hidden layer or the output layer. Each layer of the network generates an output from a received input in accordance with current values of a respective set of parameters. 
     One or more portions of a neural network may be implemented by corresponding individual computing device(s) (e.g., one device may implement one layer), so that the multiple devices collectively implement the neural network. Due to the large number and size of operations generally required to generate the outputs in the neural network, one device can consume significant computer resources and take a significant amount of time to perform its task. The time and computational resources collectively required by the multiple devices depend on the task each device is required to perform and the scheduling of those tasks. 
     Workloads to be executed by one or more devices may be represented as computation graphs and the one or more devices may execute the computation graph in order to execute the workload. 
     SUMMARY 
     This specification describes a system implemented as computer programs on one or more computers in one or more locations that determines a schedule for a computation graph by combining a neural network policy with an optimization algorithm, e.g., a genetic algorithm. In other words, the system uses the neural network policy to generate one or more instance-specific proposal distributions that are used by an optimization algorithm that schedules the input computation graph for execution across a plurality of (computing) devices. Each device may be a hardware resource that performs operations independent of other devices in the multiple devices. 
     The generated schedule can define any of a variety of aspects of the execution of input computation graph for the plurality of devices. As a particular example, the schedule can specify which device each operation represented by a node in the graph should be assigned to and, for each device, the order in which the device should execute the operations assigned to the device. 
     Particular embodiments of the subject matter described in this specification can be implemented so as to realize one or more of the following advantages. 
     By combining a neural network policy with an optimization algorithm, e.g., a genetic algorithm, as described in this specification, a schedule can be generated for a computation graph that effectively distributes the execution of the workload represented by the graph across a set of devices. In particular, the performance of the optimization algorithm can be significantly improved by incorporating the neural network as described without a significant increase in the time required or computational resources consumed in generating the schedule. This makes it possible to derive a schedule for the computational task such that, when the schedule is implemented, the computational task is performed collectively by the multiple devices with reduced computing resources and/or more rapidly. 
     The neural network used by the system described in this specification is “generalizable”, that is, it can be used to generate high-quality proposal distributions for computation graphs that were not seen during training. Therefore, the system described in this specification may reduce consumption of computational resources (e.g., memory and computing power) by obviating the need to re-train the network each time a new computation graph needs to be scheduled. In particular, many existing techniques that attempt to use neural networks or other machine learning algorithms to determine a placement for a computation graph across devices require that the model that generates the placements be trained for each new graph that needs to be placed. This additional training consumes a large amount of computational resources, particularly because many of these techniques require that the candidate placements generated during training be evaluated by actually executing the graph using the candidate placement. The described technique, on the other hand, can achieve high quality performance on previously unseen graphs without any additional training. 
     The details of one or more embodiments of the subject matter described in this specification are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the subject matter will become apparent from the description, the drawings, and the claims. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  shows an example computation graph scheduling system. 
         FIG. 2  is a flow diagram of an example process for scheduling a computation graph. 
         FIG. 3  is a flow diagram of an example process for training the graph neural network. 
     
    
    
     Like reference numbers and designations in the various drawings indicate like elements. 
     DETAILED DESCRIPTION 
       FIG. 1  shows an example graph scheduling system  100 . The graph scheduling system  100  is an example of a system implemented as computer programs on one or more computers in one or more locations, in which the systems, components, and techniques described below can be implemented. 
     The system  100  receives data representing an input computation graph  110  and generates a schedule  150  that includes graph execution decisions for executing the computation graph  110  across multiple devices. Optionally, the input computation graph  110  may be a portion of a larger computation graph. The system may include a unit operative to receive the larger computation graph and to select the input computation graph from it. 
     The computation graph  110  represents a workload to be distributed across the devices and includes nodes that represent operations and edges that represent dependencies between operations. For example, an edge from one node to another can represent that an output of an operation represented by the first node, e.g., a tensor or other data generated by the operation, is provided as an input to an operation represented by the other node. 
     As a particular example, the workload can be all of or a portion of a neural network inference workload or a neural network training workload. However, more generally, the computation graph can represent any workload that is executed by performing multiple operations that have some kind of dependencies, e.g., data dependencies, between them. The workload may for example be a workload for a computational task which is processing real-world data collected by one or more sensors (e.g., camera(s) and/or microphone(s)), and/or a workload for a computational task which generates control signals to control an electromechanical agent operating on the real world, e.g., moving (e.g., translating and/or changing its configuration) in the real-world. 
     The devices can include any appropriate types of computer hardware devices, i.e., any devices that are able to perform at least some of the operations represented in the computation graph. In some implementations, the devices are heterogeneous. For example, the devices can include a combination of any of, central processing units (CPUs), graphics processing units (GPUs), application-specific integrated circuits (ASICs) or other special-purpose hardware, field-programmable gate arrays (FPGAs), and so on. In some other implementations, the devices are homogenous, i.e., only include devices of the same device type, i.e., only devices of one of the types above or only devices that are made up of the same combination of devices of the types above. 
     The schedule  150  generated by the system  100  can specify any of various aspects of the execution of the computation graph  110  on the plurality of devices, i.e., can include any of a variety of graph execution decisions. 
     In some cases, the schedule  150  assigns each operation represented in the graph  110  to a respective device. In some of these cases, for each device, the schedule  150  also specifies the order in which the device should execute the operations that are assigned to the device. 
     In some cases, the schedule  150  specifies which tensors that are generated while executing the graph should be prioritized for transfer between devices when multiple tensors need to be transferred from one device to another in order to execute the graph according to the schedule. 
     In some cases, the schedule  150  specifies multiple operations that should be fused into a single operation during the execution of the computation graph  110 . That is, a single device should perform the specified operations, e.g., as if they were a single operation. 
     In some cases, the schedule  150  specifies which tensors, i.e., which data that is generated by operations represented by nodes, should be stored for later use by other nodes and which tensors should be re-computed. For example, the tensor may not be transferred from a first device which generates it to at least one other device which employs it; instead, the other device (or a third device) may generate the tensor afresh for use by the other device. This may have the advantage that memory space is not consumed by storing the tensor until it is used by the other device. 
     In particular, the system  100  processes data representing the computation graph using a graph neural network  120  to generate one or more instance-specific proposal distributions  130  (“node-level distribution choices”) for an optimization algorithm  140  that schedules the input computation graph for execution across the devices. The proposal distributions are referred to as “instance-specific” because different input computation graphs will result in different proposal distributions being generated by the neural network  120 . 
     More specifically, the graph neural network  120  has been trained to generate proposal distributions  130  that are predicted to result in the optimization algorithm  140  generating a schedule  150  that optimizes a performance metric that measures the execution of the computation graph  110 . 
     For example, the performance metric can measure the peak memory usage during the execution of the graph, the time required to execute the computation graph, or other properties of the execution that reflect the quality of the schedule. In some cases, the execution graph is subject to some constraint, e.g., on the peak memory use at any given time on any of the devices. In these cases, whenever the constraint is violated, e.g., a generated schedule causes some device to use more than a threshold amount of memory at some point during execution of the graph, the system can set performance metric to a predetermined value that indicates that the constraint was violate (and the generated schedule is not valid). 
     Once the graph neural network  120  has been used to generate the instance-specific proposal distributions  130 , the system  100  generates a schedule  150  for the execution of the computation graph by performing the optimization algorithm  140  in accordance with the generated instance-specific proposal distributions  130 . 
     What kind of proposal distributions  130  the system  100  generates is dependent on the inputs that are required by the optimization algorithm  140 . In other words, the system can generate proposal distributions that are appropriate for any of a variety of optimization algorithms  140  that can generate an optimized schedule for executing a computation graph on multiple devices. 
     In some examples, the optimization algorithm is a genetic algorithm. A genetic algorithm begins with an initial population of candidates and, at each of multiple iterations, modifies the population by sampling mutations, crossovers, or both. In this example, each candidate in the initial population is a different possible schedule for the graph. In the example of  FIG. 1 , the optimization algorithm  140  is a genetic algorithm that is referred to as Biased Random Key Genetic Algorithm (BRKGA). 
     Conventionally, these algorithms use fixed distributions, i.e., distributions that are always the same for all input graphs, when determining how to modify the population at a given iteration. Instead of these fixed distributions, the system  100  uses the instance-specific distributions generated using the graph neural network. In the BRKGA algorithm, for example, the system generates the parameters for one or more distributions for each node in the computation graph  110  (“node-level distributions”) and, optionally, a set of elite biases for each node in the computation graph  110 . 
     In some other examples, the optimization algorithm  140  is a stochastic local search algorithm. A stochastic local search algorithm samples an initial candidate and, at each of multiple iterations, adjusts the current candidate to generate a final candidate. Conventionally, these algorithms use fixed distributions for sampling the initial candidate, for adjusting the current candidate, or both. Instead, the system  100  uses the instance-specific proposal distributions generated using the graph neural network  120  to select the initial candidate, to make the local adjustments at each iteration, or both. 
     While the described techniques can be used to generate instance-specific proposal distributions for any optimization algorithm that optimizes any aspect of a schedule, an example follows that uses BRKGA to optimize a schedule that specifies (i) operation to device assignments (ii) operation scheduling and (iii) tensor transfer priorities. 
     In particular, BRKGA maintains a population of chromosomes each representing a candidate schedule. 
     If the computation graph  110  is to be scheduled across d devices and includes nodes representing o operations and produces t tensors that may potentially need to be transferred between the devices, each chromosome is an n dimensional vector that has three distinct parts: (1) o×d entries specifying op-to-device affinities for each of the o operations; (2) o entries specifying scheduling priorities for each of the o operations and (3) t×d entries specifying tensor-to-device priorities for transfers that may be needed. 
     Once a final candidate has been generated by BRKGA, i.e., a chromosome has been selected, the system  100  then obtains a schedule  150  from the final chromosome by performing a topological sort over the operations given their tensor dependencies, breaking ties by using the corresponding scheduling priorities for the operations. 
     To generate a final candidate, BRKGA performs multiple evolution steps, i.e., a fixed number of steps or runs for a fixed amount of time or runs for a fixed number of evaluation calls, and is specified by the following: 1) scalar integer parameters π, πe, and π c  representing the population size, number of elites, and number of children, respectively, 2) respective elite biases for each of the n entries ρ i ∈[0.5, 1.0), and 3) a mutant generation distribution D over [0, 1] n . The procedure aims to find a chromosome that maximizes f, a function that maps a chromosome to a performance metric. 
     The initial population is created by sampling from D, using known good solutions, or a mixture of both. One evolution step is completed as follows. 
     1. Sort the chromosomes in order of decreasing fitness using f. Denote the first π e  chromosomes in the order as elites and the remaining chromosomes as nonelites. 
     2. Construct the next generation of the population from three different sources of chromosomes: (a) Copy the elite chromosomes unmodified from the last generation. (b) For each of the π c  new children, select two parent chromosomes uniformly at random, one from the nonelites and one from the elites, and apply a crossover procedure to generate a new chromosome given the two parents. (c) Generate the remaining π-π e -π c  mutated chromosomes in the next generation of the population by sampling from D. 
     Given elite and nonelite chromosome a and b both in [0, 1] n , the crossover procedure produces a child chromosome c by independently combining entries from the parents. Specifically, for each index i∈1, . . . , n independently, let c i =a i  with probability ρ i  and c i =b i  with probability 1−ρ i . 
     Any new chromosome in the population is then evaluated to determine the fitness f of the chromosome, i.e., to determine the performance metric of the schedule defined by the chromosome. Evaluating a schedule is described in more detail below with reference to  FIG. 3 . 
     Thus, BRKGA requires the probability distribution D and the elite biases in order to operate. Conventionally, each of these would be agnostic to the input graph, i.e., would be pre-configured and held constant for all input graphs. Instead, the graph neural network  120  is used to predict node-specific probability distributions, node-specific elite biases, or both, that are used in place of the probability distribution D and the elite biases. 
     For example, the system can, instead of using a single distribution D, use n independent beta distributions in place of the single distribution D, one for each entry in a given chromosome. The graph neural network  120  may be used to predict the parameters of the beta distributions for the entries of the chromosome that correspond to different operations represented by nodes in the graph, i.e., for a given node in the graph, the graph neural network  120  can be used to predict the parameters of d+1 independent beta distributions, corresponding to device affinities for the operation represented by the node and the scheduling priority for the operation represented by the node. The beta distributions corresponding to the remaining d×t entries specifying tensor-to-device priorities can be set to graph-agnostic pre-determined distributions. 
     BRKGA can then use these beta distributions in place of D when constructing the initial population and generating new chromosomes for each new generation of the population, i.e., when generating the π-π e -π c  mutated chromosomes for each new generation. 
     Optionally, instead of or in addition to predicting the parameters of the beta distributions for a given node, the graph neural network  120  can be used to predict the elite bias for the node or parameters of a probability distribution over elite bias values for the node. Thus, in these cases, the output of the graph neural network  120  is also used to perform the crossover procedure when generating a new generation of the population. 
     The operation of BRKGA is described in more detail in Jose Fernando Gonçalves and Mauricio G. Resende. Biased random-key genetic algorithms for combinatorial optimization. Journal of Heuristics, 17(5):487-525, October 2011. ISSN 1381-1231. doi: 10.1007/s10732-010-9143-1. 
     To generate the proposal distributions using the graph neural network  120 , the system  100  processes the data representing the computational graph  110 , i.e., attribute vectors for the nodes and edges in the graph, using the graph neural network  120  to generate a respective representation vector for each node in the graph. The attribute vectors for the nodes and edges represent features of the node or edge, e.g., sizes of the tensors received as input or output of an operation or transmitted over an edge, or types of operations performed by nodes. 
     Any of a variety of graph neural network architectures that are configured to process graph data to generate representation vectors for nodes in the graph can be used. One example graph neural network architecture is described in Peter W. Battaglia et al. 2018. Relational inductive biases, deep learning, and graph networks. CoRR (2018). arXiv:1806.01261 http://arxiv.org/abs/1806.01261. Another example graph neural network architecture is described in Justin Gilmer, Samuel S Schoenholz, Patrick F Riley, Oriol Vinyals, and George E Dahl. 2017. Neural message passing for quantum chemistry. arXiv preprint arXiv:1704.01212 (2017). Yet another example graph neural network architecture is described in Franco Scarselli, Marco Gori, Ah Chung Tsoi, Markus Hagenbuchner, and Gabriele Monfardini. 2009. The graph neural network model. IEEE Transactions on Neural Networks 20, 1 (2009), 61-80. 
     The system  100  then generates the proposal distributions  130  from the representation vectors for the nodes of the graph that are generated by the graph neural network  120 . 
     In some implementations, the system  100  generates the parameters of the proposal distribution(s) for a given node in the graph only from the representation vector for the given node, e.g., by processing the representation vector for the given node through a multi-layer perceptron or other neural network. 
     In some other implementations, the system  100  generates the parameters of the proposal distribution(s) for the nodes in the graph auto-regressively. That is, the system  100  orders the nodes and then generates the parameters of the proposal distribution(s) for a given node conditioned on the representation vector for the given node and the generated parameters for any nodes that are before the given node in the order, e.g., by processing the feature representations of the nodes in the order using a recurrent neural network. 
     In some implementations, the system directly generates the parameters of the distributions, e.g., by directly regressing the values of the parameters. 
     In other implementations, the system  100  can define a discrete action space in which each discrete action in the space maps to a unique set of parameters for the proposal distribution(s) needed by the optimization algorithm for a given node. That is, each action in the discrete action space is a different set of parameters for the proposal distributions needed by the optimization algorithm for a given node. For each node, the system  100  then generates a probability distribution over the discrete action space from the vector representation of the node (using one of the techniques above) and then samples from the probability distribution or selects the action with the highest probability to generate the proposal distributions for the node. 
     In some implementations, the system  100  then executes the computation graph on the devices in accordance with the generated schedule. 
     In some other implementations, the system  100  provides data specifying the generated schedule to another system and the other system uses the provided data to execute the computation graph on the devices. 
       FIG. 2  is a flow diagram of an example process  200  for scheduling a computation graph. For convenience, the process  200  will be described as being performed by a system of one or more computers located in one or more locations. For example, a graph scheduling system, e.g., the graph scheduling system  100  of  FIG. 1 , appropriately programmed in accordance with this specification, can perform the process  200 . 
     The system obtains data representing an input computation graph (step  202 ). 
     The input computation graph includes a plurality of nodes that are connected by edges, with the nodes representing operations and the edges representing dependencies between the operations. For example, the input computation graph can represent all or some of the operations required to perform an inference using a neural network or to train a neural network. 
     Because of the way that the graph neural network has been trained (as will be described below with reference to  FIG. 3 ), the input computation graph need not be a graph that was included in the training data used to train the graph neural network. The system processes the data representing the input computation graph using the graph neural network (step  204 ). As described above, the graph neural network is a neural network having a plurality of network parameters and configured to process the data representing the input computation graph in accordance with the network parameters to generate one or more instance-specific proposal distributions for the optimization algorithm. In other words, the graph neural network generates instance-specific proposal distributions that are used by the optimization algorithm instead of the default or conventional proposal distributions that would conventionally be used by the optimization algorithm. 
     The system generates a schedule for the input computation graph by performing the optimization algorithm in accordance with the one or more instance-specific proposal distributions generated by the graph neural network for the input computation graph (step  206 ). In other words, the system runs the optimization algorithm using the instance-specific proposal distributions in place of the conventional proposal distributions that would be used by the optimization algorithm. For example, the system can run the optimization for a fixed number of iterations or for a fixed amount of time and then use the solution found by the algorithm after the fixed number of iterations or after the fixed amount of time as the generated schedule. 
     Thus, the only computational overhead introduced to the scheduling process by generating the instance-specific probability distributions is the overhead that is required to perform a forward pass through the graph neural network for the computation graph, which will typically be minimal relative to the amount of computational resources consumed by the optimization algorithm. 
     In some implementations, the system then executes the input computation graph on the plurality of devices by causing the plurality of devices to perform the operations represented by the nodes in the input computation graph in accordance with the generated schedule. 
     In some other implementations, the system provides data specifying the executed schedule to another system, which then uses the data to cause the devices to perform the operations represented by the nodes in the input computation graph in accordance with the generated schedule. 
       FIG. 3  is a flow diagram of an example process  300  for training the graph neural network. For convenience, the process  300  will be described as being performed by a system of one or more computers located in one or more locations. For example, a graph scheduling system, e.g., the graph scheduling system  100  of  FIG. 1 , appropriately programmed in accordance with this specification, can perform the process  300 . 
     The system can repeatedly perform the process  300  for different training examples on a set of training data in order to repeatedly adjust the values of the network parameters to determine trained values of the network parameters. Each training example in the training data is data representing a different training computation graph. Thus, by performing the process  300  the system trains the neural network on different computation graphs and such that the trained neural network will generalize the computation graphs that are not represented in the set of training data. 
     The system processes a training example, i.e., data that represents a computation graph, in accordance with current values of the network parameters to generate one or more training instance-specific proposal distributions for the optimization algorithm (step  302 ), i.e., to generate all of the proposal distributions that are required for the optimization algorithm to run. 
     The system generates a training schedule for the training computation graph represented by the training example by performing the optimization algorithm in accordance with the one or more training instance-specific proposal distributions (step  304 ). 
     The system determines a performance metric for the execution of the training computation graph (step  306 ). 
     Generally, the performance metric measures one or more properties of the execution of the training computation graph that are attempting to be optimized by the generated schedule. For example, the performance metric can measure the peak memory usage during the execution of the graph, the time required to execute the computation graph, or other properties of the execution that reflect the quality of the schedule. The performance metric can also be derived from a combination of multiple properties of the execution, e.g., as a weighted sum of the peak memory usage and the time required to execute the graph. 
     In some implementations, the system determines the performance metric by executing the training computation graph on the plurality of devices by causing the plurality of devices to perform the operations represented by the nodes in the input computation graph in accordance with the training schedule and measuring the properties of the execution that are used to generate the performance metric. 
     In some other implementations, the system maintains a cost model that models the values of the one or more properties for a given input schedule and uses the maintained cost model to determine the values of the one or more properties, i.e., without needing to execute the graph on the devices. Maintaining and using such a computationally cheap cost model enables fast optimization and may be better suited for distributed training of the graph neural network since a cost model is cheap to replicate in parallel actors, while hardware environments are not. Example techniques for constructing such a cost model for a given set of devices are described in Ravichandra Addanki, Shaileshh Venkatakrishnan, Shreyan Gupta, Hongzi Mao, and Mohammad Alizadeh. Placeto: Efficient progressive device placement optimization. In Workshop on ML for Systems at NeurIPS 2018, 2018 and Zhihao Jia, Matei Zaharia, and Alex Aiken. Beyond data and model parallelism for deep neural networks. CoRR, 2018. URL http://arxiv.org/abs/1807.05358. 
     The system generates a reward from the performance metric (step  308 ). Generally, the system maps the performance metric to a reward value that can be maximized to improve the performance metrics. In some cases, to improve the generalization of the neural network to different graphs, the system can generate the reward based on the performance metric and a baseline performance metric generated from the execution of the training computation graph in accordance with a baseline schedule. The baseline schedule can be, e.g., a schedule that is generated by the optimization algorithm in accordance with default, graph-agnostic proposal distributions. As a particular example, the reward can be the negative of the ratio between the performance metric and the baseline performance metric. 
     The system determines an update to the current values of the network parameters based on the reward (step  310 ). This may be done using a reinforcement learning technique. For example, the system can maximize the expected reward through a policy gradient reinforcement technique, e.g., REINFORCE with or without a variance reducing baseline. 
     This specification uses the term “configured” in connection with systems and computer program components. For a system of one or more computers to be configured to perform particular operations or actions means that the system has installed on it software, firmware, hardware, or a combination of them that in operation cause the system to perform the operations or actions. For one or more computer programs to be configured to perform particular operations or actions means that the one or more programs include instructions that, when executed by data processing apparatus, cause the apparatus to perform the operations or actions. 
     Embodiments of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, in tangibly-embodied computer software or firmware, in computer hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible non transitory storage medium for execution by, or to control the operation of, data processing apparatus. The computer storage medium can be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them. Alternatively or in addition, the program instructions can be encoded on an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus. 
     The term “data processing apparatus” refers to data processing hardware and encompasses all kinds of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can also be, or further include, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit). The apparatus can optionally include, in addition to hardware, code that creates an execution environment for computer programs, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them. 
     A computer program, which may also be referred to or described as a program, software, a software application, an app, a module, a software module, a script, or code, can be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages; and it can be deployed in any form, including as a stand alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A program may, but need not, correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data, e.g., one or more scripts stored in a markup language document, in a single file dedicated to the program in question, or in multiple coordinated files, e.g., files that store one or more modules, sub programs, or portions of code. A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a data communication network. 
     In this specification, the term “database” is used broadly to refer to any collection of data: the data does not need to be structured in any particular way, or structured at all, and it can be stored on storage devices in one or more locations. Thus, for example, the index database can include multiple collections of data, each of which may be organized and accessed differently. 
     Similarly, in this specification the term “engine” is used broadly to refer to a software-based system, subsystem, or process that is programmed to perform one or more specific functions. Generally, an engine will be implemented as one or more software modules or components, installed on one or more computers in one or more locations. In some cases, one or more computers will be dedicated to a particular engine; in other cases, multiple engines can be installed and running on the same computer or computers. 
     The processes and logic flows described in this specification can be performed by one or more programmable computers executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by special purpose logic circuitry, e.g., an FPGA or an ASIC, or by a combination of special purpose logic circuitry and one or more programmed computers. 
     Computers suitable for the execution of a computer program can be based on general or special purpose microprocessors or both, or any other kind of central processing unit. Generally, a central processing unit will receive instructions and data from a read only memory or a random access memory or both. The essential elements of a computer are a central processing unit for performing or executing instructions and one or more memory devices for storing instructions and data. The central processing unit and the memory can be supplemented by, or incorporated in, special purpose logic circuitry. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks. However, a computer need not have such devices. Moreover, a computer can be embedded in another device, e.g., a mobile telephone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device, e.g., a universal serial bus (USB) flash drive, to name just a few. 
     Computer readable media suitable for storing computer program instructions and data include all forms of non volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD-ROM disks. 
     To provide for interaction with a user, embodiments of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. In addition, a computer can interact with a user by sending documents to and receiving documents from a device that is used by the user; for example, by sending web pages to a web browser on a user&#39;s device in response to requests received from the web browser. Also, a computer can interact with a user by sending text messages or other forms of message to a personal device, e.g., a smartphone that is running a messaging application, and receiving responsive messages from the user in return. 
     Data processing apparatus for implementing machine learning models can also include, for example, special-purpose hardware accelerator units for processing common and compute-intensive parts of machine learning training or production, i.e., inference, workloads. 
     Machine learning models can be implemented and deployed using a machine learning framework, e.g., a TensorFlow framework, a Microsoft Cognitive Toolkit framework, an Apache Singa framework, or an Apache MXNet framework. 
     Embodiments of the subject matter described in this specification can be implemented in a computing system that includes a back end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front end component, e.g., a client computer having a graphical user interface, a web browser, or an app through which a user can interact with an implementation of the subject matter described in this specification, or any combination of one or more such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet. 
     The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In some embodiments, a server transmits data, e.g., an HTML page, to a user device, e.g., for purposes of displaying data to and receiving user input from a user interacting with the device, which acts as a client. Data generated at the user device, e.g., a result of the user interaction, can be received at the server from the device. 
     While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any invention or on the scope of what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of particular inventions. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially be claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination. 
     Similarly, while operations are depicted in the drawings and recited in the claims in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system modules and components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products. 
     Particular embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results. As one example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous.