Papers
返回绿色论文索引Hydro: Surrogate-based Hyperparameter Tuning Service in Datacenters打开本地 PDFPDF 转 HTML

Hydro: Surrogate-based Hyperparameter Tuning Service in Datacenters

Qinghao Hu1,2,3

Zhisheng Ye3,4

Meng Zhang1,2,3

Qiaoling Chen3,5

Peng Sun3,6

Yonggang Wen1

Tianwei Zhang1

1Nanyang Technological University

2S-Lab, NTU

3Shanghai AI Laboratory

4Peking University

5National University of Singapore

6SenseTime Research

Abstract

Hyperparameter tuning is an essential step in deep learning

model development that provides better model performance

at the cost of substantial resources. While existing systems

can improve tuning efficiency, they still fail to handle large

models with billions of parameters and efficiently leverage

cluster resources. Motivated by these deficiencies, we intro-

duce Hydro, a surrogate-based hyperparameter tuning service

that optimizes tuning workloads in both the job-level and

cluster-level granularities. Specifically, it consists of two key

components: (1) Hydro Tuner automatically generates and

optimizes surrogate models via scaling, parametrization and

fusion; (2) Hydro Coordinator improves tuning efficiency

and cluster-wide resource utilization by adaptively leveraging

ephemeral and heterogeneous resources. Our comprehensive

experiments on two tuning algorithms across six models show

that Hydro Tuner can dramatically reduce tuning makespan

by up to 78.5× compared with Ray Tune and no reduction in

tuning quality. Hydro’s source code is publicly available at

https://github.com/S-Lab-System-Group/Hydro.

1

Introduction

Over the years, we have witnessed the incredible performance

and rapid popularity of Deep Learning (DL) across many do-

mains, such as vision and speech. However, it is non-trivial

to acquire a qualified DL model because its performance is

highly sensitive to the hyperparameters, which control the

training process and require to be set before training [71].

Poor hyperparameters result in training instability and infe-

rior model quality. Conversely, well-tuned hyperparameters

can significantly improve model performance. For instance,

PyTorch [91] recently applies a new hyperparameter recipe

on ResNet-50 [41] and achieves 80.9% ImageNet classifi-

cation accuracy [18], which is 4.8% higher than the former

version (76.1%). Besides, RoBERTa [75] also demonstrates

the critical impact of hyperparameters on the performance of

large language models. Accordingly, hyperparameter tuning

becomes a common practice during DL model development.

Due to the high dimensionality of the search space, a hy-

perparameter tuning job typically contains a large group of

trials, each with a unique configuration [125]. To accelerate

the tuning process, tech companies and researchers build hy-

perparameter tuning systems as cloud services [1,8,39,92]

or standalone frameworks [32,71,72,82,125,127] (Table 1).

However, we argue that state-of-the-art tuning systems are

still expensive and inefficient in practice, as they suffer from

several fundamental problems:

Unacceptable cost of tuning large models. The extraordi-

nary performance of large foundation models (e.g., BERT

[30], GPT-3 [24]) attracts wide downstream applications

[3,4,6]. Meanwhile, the hyperparameter tuning demand for

these models increases rapidly. However, all of the existing

tuning systems require training multiple trials using several

times of resources, which is unaffordable for large models

with billions of parameters. For example, training a SOTA

language model PaLM [27] of Google takes over 6,000 TPU-

v4 [59] for around 2 months. Performing a hyperparameter

sweep on such model is intractable [23]. Consequently, hy-

perparameters of most large models are not well-tuned and

can lead to subpar performance [75].

Inefficient hardware utilization. Recent scheduling works

[46,114,115,124] report that GPUs are commonly underuti-

lized in DL clusters due to massive training jobs involving

mid- or small-scale models. Moreover, despite the growing

trend of foundation models being employed in clusters, large-

scale models often fail to fully utilize hardware resources due

to the huge communication overhead and the presence of bub-

bles in the pipeline parallelism [106]. To improve resource

utilization, some novel tuning systems incorporate features

such as elastic training [32,71,82], GPU sharing [125], and

inter-trial fusion [110]. However, these systems have certain

limitations (§8) and often require substantial resources to ex-

plore trivial trials, which results in limited resources being

contributed to the final model.

Agnostic to cluster-wide resources. Hyperparameter tun-

ing jobs are pervasive and occupy enormous resources in

GPU clusters. As reported by Microsoft [50,78], “approxi-

mately 90% of models require hyperparameter tuning, with

each tuning job containing 75 trials in median.” However,

existing tuning systems only manage trials over the requested

resources and lack interaction with cluster schedulers. Mean-

while, DL schedulers [36,40,46,87,94,114,123] also overlook

the distinct characteristic of gradually diminishing hardware

demand inherent in hyperparameter tuning jobs [71]. Conse-

quently, the cluster encounters imbalanced resource problem:

the active tuning jobs consistently occupy static resources,

leaving some of them vacant, while the queued jobs are un-

able to request these idle resources from the scheduler. This

leads to severe queuing delay, which is exacerbated when

long-term large-scale model training jobs coexist and they

occupy the majority of cluster resources.

To bridge these gaps, we design Hydro, a surrogate-based

hyperparameter tuning service that optimizes tuning jobs in

both the job-level and cluster-level granularities via automated

model scaling, fusion and interleaving. The core design of

Hydro derives from the following three insights. First, it is

feasible to search hyperparameters with a smaller model. In-

stead of tuning hyperparameters directly on the target model,

we find it is possible to tune a model with a much smaller

surrogate model by applying a novel hyperparameter transfer

theory [117, 121]. Second, cross-model fusion can be used

to improve resource utilization. Since the scaled surrogate

model is prone to incur GPU underutilization, we can utilize

the model architecture consistency of different trials to fuse

them into a single one, achieving much higher GPU utilization

and training throughput. Third, ephemeral bubble resources

in the datacenter can be leveraged for tuning. Large model

training jobs exist in the long term and occupy the majority of

resources, which incurs the starvation of other jobs. We can

leverage pipeline bubbles of large models to greatly extend

the tuning job resources in an interleaving execution way,

without hurting the training throughout of large models.

Incorporating the above insights, we build Hydro service

to minimize the makespan of tuning workloads and improve

the cluster-wide resource utilization. It consists of two key

system components: (1) Hydro Tuner is the user interface

that automatically generates surrogate models by scaling and

parametrization. It optimizes tuning efficiency via inter-trial

and intra-trial fusion, which involve combining multiple mod-

els into a single entity and subsequently performing compiler-

based optimization. Besides, it efficiently orchestrates the

tuning process with adaptive fusion and eager transfer mecha-

nisms. (2) Hydro Coordinator is the datacenter interface that

interacts with the scheduler to dynamically allocate resources

and execute trials. It extends tuning resources by interleaving

training with pipeline-enabled large model training tasks, ef-

fectively utilizing idle time intervals on each node known as

bubbles, which are caused by the gaps between the forward

and backward processing of microbatches [106]. Besides, it

improves resource utilization and cluster-wide performance

by heterogeneity-aware allocation.

To extensively assess the performance of Hydro, we con-

duct evaluations across 6 models, such as GPT-3 XL [24] and

ResNet [41]. Experiments on Hydro Tuner show that it sub-

stantially outperforms Ray by 8.778.5× on makespan reduc-

tion with single-fidelity tuning algorithm, while obtaining bet-

ter final model quality. Besides, our experiments on Hydro Co-

ordinator demonstrate that interleaving with a large pipelined

model can further extend the resource of tuning workload,

without sacrificing the throughput of the large model.

Features

Cloud Services

HPO Frameworks

Hydro

Vizier

SageMaker

NNI

Ray

Distributed Environment

Elastic Training

Auto Model Scaling

Surrogate HP Transfer

Inter-Trial Fusion

Intra-Trial Fusion

Heterogeneity Awareness

Interleaving Training

Table 1: Comparison between Hydro and existing popular

HPO systems: Google Vizier [39,105], Amazon SageMaker

[28,92], Microsoft NNI [9,127] and Anyscale Ray [72,84].

denotes system cannot support the feature for many cases.

Table 1 compares Hydro with existing tuning systems. To

summarize, we make the following contributions:

We build a holistic system that automatically applies the

novel hyperparameter transfer theory together with multiple

system techniques to jointly improve the tuning efficiency.

We identify the opportunities for cluster-wide optimization

in the datacenter, including squeezing bubble resources with

interleaving and heterogeneity-aware trial allocation.

We demonstrate the excellent performance of surrogate-

based hyperparameter tuning across general models.

2

Background and Motivation

2.1

Hyperparameter Tuning

Hyperparameter Tuning (i.e., Hyperparameter Optimization,

HPO) aims to identify the optimal hyperparameters via mas-

sive configuration exploration [71,82]. In the general work-

flow of an HPO job: (1) the user designates a search space of

hyperparameters to explore; (2) the tuning algorithm creates

a set of training trials and each trial contains one unique hy-

perparameter configuration sampled from the search space;

(3) the HPO system coordinates trials execution until the best

hyperparameter configuration is found.

Existing research works typically optimize HPO efficiency

from the tuning algorithm [33,47,63,64,67,68,70,79,104]

or system [32,60,69,71,82,110,125,127] aspects:

Algorithm taxonomy. Depending on whether to enable early

stopping, tuning algorithms can be divided into two categories

[100]: (1) single-fidelity (e.g, Random [22], Bayes [104])

algorithms require each trial to be fully trained, which is

accurate but inefficient; (2) multi-fidelity (e.g., ASHA [63],

BOHB [33]) algorithms stop unpromising trials via successive

halving [53] or curve fitting [31] strategies. They are efficient

but may miss the best hyperparameter configuration due to

the use of “low-fidelity” evaluations. Hydro well supports

both the single- and multi-fidelity algorithms.

System optimization. To further improve the tuning effi-

ciency and resource utilization, there are two advanced tech-

niques applied in state-of-the-art HPO systems: (1) elastic

training dynamically allocates more GPU resources to the top

performing trials [71] and further adjusts the entire requested

resources [32, 82, 94]. (2) GPU sharing (i.e., trial packing)

allows multiple trials to share the GPU using the NVIDIA

MPS [13] or MIG [12] technologies to achieve higher uti-

lization [125]. Different from them, Hydro combines scaling,

fusion and interleaving for ultimate efficiency.

2.2

Hyperparameter Transfer Theory

Recently, the remarkable success of foundation models has

ignited a keen interest in exploring the relationship between

model size and its optimal hyperparameter. Scaling Laws [42,

43,52] empirically study the power-law functions of batch size

and learning rate across varying model sizes. Nevertheless, the

authors [52] candidly admit that only limited configurations

are tested and the rule-of-thumb formulas break down when

dealing with models that exceed one billion parameters.

Beyond heuristic exploration, some novel hyperparameter

transfer strategies [49, 117, 121] are proposed by DL theo-

rists. For simplicity, we call them parametrization, the rule

of how to adjust hyperparameters accordingly when models

grow/shrink in both the width and depth. Different from exist-

ing HPO systems, Hydro enables automatic hyperparameter

transfer based on parametrization. To make the obscure theory

more accessible, we present a concise background overview

of the underlying theory. [116] systematically builds a coher-

ent theoretical framework for parameterization: the feature

learning effect γ of a MLP model is proportional to

γ

L

w1p , p[0,1]

(1)

where w, L indicates the width and depth of the neural network

respectively. For the purpose of simplicity, we assume that the

numbers of the hidden-layer neurons are all of similar order,

w1,w2,...wL1w. p is a metaparameter that interpolates

different parametrization strategies into a unified framework,

which is determined by inherent strategy. The objective is two-

fold: first, to maintain a fixed γ that allows hyperparameters

transfer across different model sizes, and second, to strive for

a larger γ that facilitates better feature learning. To this end,

there are two directions of parametrization:

(1) Neural Tangent (NT) parametrization (p = 0) [49]. It

naturally arose from the study of infinite-wide neural network

as Neural Tangent Kernel (NTK) [49, 89], which can keep

γ fixed by scaling the depth along with the width as Lw.

NTK is a kernel method to explain the evolution of neural

networks during training, which is derived by applying the

first-order Taylor expansion to linearized models. It belongs

to the lazy training regime where the weights move very

little [121], so that linearization approximately holds around

the initial parameters and does not learn features, which is a

fatal weakness of the NTK theory in practice. Moreover, NT

parametrization does not make sense since the wider model

does not always perform better in this context [117], which

conflicts with common observations [43,52].

(2) Maximal Update (MU) parametrization (p = 1) [121].

2−11

2−8

2−5

2−2

(a) Learning Rate

0

1

2

Loss

MLP

w/o Hydro

2−11

2−8

2−5

2−2

(b) Learning Rate

0

1

2

MLP

w/ Hydro

Consistent Best LR

2−16

2−13

2−10

2−7

(c) Learning Rate

1

3

5

7

Loss

Transformer

w/o Hydro

2−15

2−11

2−7

(d) Learning Rate

1

3

5

7

Consistent Best LR

Transformer

w/ Hydro

Scaling Ratio:

S = 16

S = 8

S = 4

S = 2

S = 1

Figure 1: Effect of Hydro parametrization. The training loss

against the learning rate on MLP (a, b) and Transformer (c,

d) with different widths. S denotes the model scaling ratio.

It generalizes the mean-field limit of the 1-hidden-layer case

[25, 80] and should be the unique parametrization that re-

tains the representation-learning capability (non-rigorously

referred to active training, in contrast to lazy training of

NT parametrization) for a large-scale neural network, which

means training does not become trivial or stuck at the initial-

ization in the large width limit. Colloquially, it is designed

to solve the issue that the input layer is updated much more

slowly than the output layer, and make all hidden activations

update with the same speed in terms of width [117].

Hydro adopts the MU parametrization, which will be fur-

ther elaborated in §4.1 and we refer readers to [98,117122]

for a comprehensive review of the theory.

2.3

Opportunities for Efficient Tuning

Lightweight surrogate-based tuning. Current HPO systems

search hyperparameters directly on the target model, which is

intuitive but inefficient. In contrast, Hydro makes it possible

to tune a model with a much smaller surrogate model via

applying a novel hyperparameter transfer technique (afore-

mentioned in §2.2). For a clearer illustration of the surrogate-

based tuning effect, we employ Hydro parametrization on two

toy models and plot their converged training loss against a

range of learning rates as shown in Figure 1. Specifically, the

target MLP model contains two hidden layers (width=4096)

and we train it with SGD on CIFAR-10. Similarly, the tar-

get Transformer model contains two TransformerEncoder

layers (width=4096, i.e., dmodel) and we train it with Adam

on WikiText-2. Besides, we generate surrogate models with

different scaling (shrinking) ratios S, and the smaller model

is depicted by the lighter blue line. For instance, S=2 repre-

sents the model with width=2048. Obviously, the conventional

training paradigm (Figure 1 (a, c)) cannot share the best hy-

0

20

40

60

80

100

GPU Utilization (%)

0

20

40

60

80

100

CDF (%)

(a)

Shanghai AI Lab

Alibaba

K40

2013

M40

2015

P100

2016

V100

2017

A100

2020

H100

2022

0.0

0.4

0.8

1.2

1.6

2.0

FP32 Cores

×104

(b)

FP32 Cores

Memory (GB)

0

18

36

54

72

90

Memory (GB)

Figure 2: (a) GPU utilization distribution of one partition in

our cluster and a GPU production cluster in Alibaba [115]. (b)

Exponential growth of NVIDIA datacenter GPU capability.

x-axis: GPU model name & release year.

12 4

8

16

32

Scaling Ratio S

0

2

4

6

GFLOPs

GFLOPs » 6=S 2

(a)

Exact GFLOPs

Approximate Curve

12 4

8

16

32

Scaling Ratio S

0

20

40

60

80

Memory (GB)

Memory » 70=S + 4

(b)

Exact Memory

Approximate Curve

Figure 3: Model scaling effect of WideResNet-50. (a) Model

GFLOPs (Giga Floating Point Operations). (b) GPU memory.

perparameter across different sizes of models and there are

orders of magnitude optimal learning rate shifts. However,

Hydro parametrization (Figure 1 (b, d)) makes surrogate mod-

els stay approximately the same optimal learning rate as the

target model, which implies the feasibility of surrogate-based

tuning. Furthermore, Hydro parametrization can deliver better

performance since both tuned MLP and Transformer achieve

lower training loss than their counterparts. An intuitive expla-

nation is that the learning rate of the conventional paradigm

must tame logits’ surge, but preceding layers do not learn ap-

preciably. We perform a comprehensive evaluation of several

models in §6.3 and demonstrate the superiority of Hydro.

Fusion of numerous repetitive models. GPUs are commonly

underutilized in DL clusters [45,46,115,124,125]. Figure 2

(a) plots the Cumulative Distribution Function (CDF) of one-

week GPU utilization in one partition of our cluster, as well

as an Alibaba trace [115] for reference. We find there are only

16% and 35% of GPUs achieving higher than 50% GPU uti-

lization in Alibaba and Shanghai AI Laboratory respectively.

This issue will be exacerbated if the Hydro surrogate-based

tuning technique is applied. For instance, Figure 3 presents the

model scaling effect of training WideResNet-50 on ImageNet,

where GFLOPs follows approximately inverse-square (c1/S2)

trend drop and memory footprint follows roughly c1/S+c2

trend decrease (ci indicates constant). This implies model

scaling can significantly reduce the computation overhead,

but resources are more prone to be underutilized. To this end,

inspired by JAX vmap function [35,112], Hydro implements

an inter-trial fusion mechanism to automatically combine

multiple models into one. Operators of multiple trials can be

fused owing to the property of HPO tasks: essential is a set

of identical models (or with minor mutation). Compared with

the conventional GPU sharing mechanism (e.g., MPS), Hydro

can achieve higher training throughput, GPU utilization and

lower memory footprint (Figure 8).

Cluster resource awareness. Although HPO jobs are perva-

sive in GPU datacenters, cluster schedulers typically regard

them as general training workloads without any specific de-

sign. On the other hand, HPO systems [9,72,84] are cluster re-

source agnostic. This causes cluster-level inefficiency, such as

long job queuing delay and low GPU utilization. However, the

unique features of HPO jobs bring opportunities for more effi-

cient tuning. (1) Trial throughput insensitivity. Unlike general

DL jobs, HPO jobs are more tolerant to throughput slowdown

of partial trials. Therefore, we can run more trials by lever-

aging ephemeral bubble resources of large language model

training jobs, which are long-term existing in our datacenter

5.1). (2) Diminishing resource requirements. Multi-fidelity

HPO jobs usually explore plenty of trials at the beginning

and gradually decrease the search concurrency [32,71,82]. At

the final stage, only a few trials are exploited. Therefore, we

can not only reduce the total resource amount progressively,

but also properly leverage the heterogeneous GPU resource

5.2). With the rapid evolution of GPU computing capability

as shown in Figure 2 (b), they become more prone to be un-

derutilized for most small-scale trials [87]. Allocating trials

to appropriate GPUs can significantly improve cluster-wide

efficiency without hurting a single HPO job makespan.

3

Hydro Overview

Design principles & goals. For practical adoptions, Hydro

follows three design principles: (a) Automatic and simple.

Manually converting surrogate models is tedious and error-

prone. Hence, the whole tuning workflow should be auto-

mated and easy to use, which requires minimum user code

modification. (b) Incentive and interference-free. Although

our system focuses on optimizing HPO jobs, it does not sacri-

fice other workload performance. Instead, it is altruistic and

requires fewer resources than conventional systems, which

benefits all cluster users. (c) Modular and extensible. Each

component in Hydro can work independently to support more

scenarios (e.g., cloud). Moreover, Hydro can be applied to

general HPO tasks, and more tuning algorithms can be easily

integrated. In addition, Hydro has two primary objectives: (1)

minimizing the makespan of HPO workloads; (2) improving

the cluster-wide resource utilization.

System architecture. Figure 4 depicts the architecture of

the Hydro service. It consists of two key system components:

Hydro Tuner (blue block) as a user interface to automati-

cally generate surrogate models and optimize tuning trials,

and Hydro Coordinator (purple block) for improving tun-

ing efficiency and datacenter-level resource utilization. Each

component contains several modules for different purposes.

Specifically, there are three main modules in Hydro Tuner:

1

Hydro Tuner

Search Space

Target Model

User Config:

Hydro Coordinator

Symbolic Trace

Parametrization

Model Shrinker

Inter-Trial Fusion

Intra-Trial Fusion

Trial Binder

Surrogate Model

Trial Profiler

Adaptive Fusion

Eager Transfer

Trial Planner

Cluster

Scheduler

Dynamic Split

Distributed Training

Elastic Executor

Bubble

Squeezer

Heterogeneity-Aware

Allocator

Execution Backend:

2

3

Job Creation

Resource Allocation

Tuning Execution

Figure 4: Overview of Hydro architecture and workflow.

Model Shrinker: to obtain surrogate models by automati-

cally tracing, scaling and parametrization.

Trial Binder: to better utilize accelerators by binding multi-

ple trials and fusing internal operators.

Trial Planner: to adaptively determine the tuning strategy

based on the profiling information and intermediate results.

Additionally, Hydro Coordinator also includes three modules:

Bubble Squeezer: to extend tuning workload resources by

interleaving training with a pipeline-enabled large model.

Heterogeneity-Aware Allocator: to improve resource uti-

lization and cluster-wide performance by allocating proper

accelerators on different tuning stages.

Elastic Executor: to dynamically execute trials by splitting

fused trials and enabling distributed training.

API Design. Hydro enables high-efficient surrogate-based

hyperparameter tuning with a few lines in the developer’s

code, as shown in Figure 5. It follows the Ray Tune [72] API

to define the search space and invoke the fit() function. To

support Hydro functions, developers only require to wrap their

model, dataloader and optimizer with the prepare_xxx()

API (lines 68). Hydro traces the whole function to control

the trial execution, convert surrogate model, enable model

fusion and elastic training.

Tuning Workflow. The system workflow of Hydro is pre-

sented by black arrows in Figure 4. Specifically, when a devel-

oper wants to tune a model, she only needs to define the search

space and invoke the Hydro APIs (). After job creation, Hy-

dro Tuner automatically generates and optimizes surrogate

models by scaling and fusion. Furthermore, it adopts Trial

Planner to efficiently orchestrate the tuning process. Then

Hydro Coordinator is responsible for contacting the cluster

1

import ray, hydro

2

import hydro.train as ht

3

4

def train_func(config):

5

# Wrap model, dataloader and optimizer

6

model = ht.prepare_model(model)

7

data_loader = ht.prepare_data_loader(data_loader)

8

optimizer = ht.prepare_optimizer(SGD, lr=config["lr"])

9

for _ in range(1):

# User defined training loop

10

train_epoch(...)

11

result = validate_epoch(...)

12

ray.session.report(result)

13

14

search_space = {"lr": ray.qloguniform(1e-4, 1, 1e-4)}

15

trainer = hydro.Trainer(train_func)

16

tuner = hydro.Tuner(trainer, search_space, scaling_num=8)

17

results = tuner.fit()

Figure 5: A code example of how to use Hydro APIs to define

the search space and perform hyperparameter tuning.

scheduler to dynamically allocate resources and execute tri-

als (). It supports two novel mechanisms, which leverage

ephemeral bubbles and heterogeneous resources to further

improve datacenter efficiency. Finally, the tuning job is suc-

cessfully scheduled and starts running, where Ray [84] and

PyTorch [91] serve as the execution backend (). More de-

tails are introduced in the following sections (§4 & §5).

4

Hydro Tuner

Hydro Tuner is a core component of the Hydro service for

job-level optimization. It consists of three modules: Model

Shrinker, Trial Binder and Trial Planner.

4.1

Model Shrinker

Model Shrinker aims to obtain surrogate models by automati-

cally tracing, scaling and parametrizing the target model. The

upper part of Figure 6 depicts its workflow. It first traces

the target model and edits each layer’s configuration to build

a scaled model (). To enable hyperparameter transfer, it

then automatically parametrizes the scaled model by reini-

tializing the weight and adjusting the learning rate of each

layer accordingly (). Below we first summarize the MU

parametrization theory that Hydro parametrization relies on,

and then introduce how Hydro brings it into practice.

Maximal Update parametrization. As introduced in §2.2,

Hydro employs the MU parametrization theory [117,121] to

search hyperparameters on a small surrogate model and trans-

fer them to the large target model. The theory is built atop

Tensor Programs [117122], a unified theoretical framework

that formulates the computation of common neural networks

components as Gaussian Processes (GPs), including multi-

layer perceptrons (MLPs), recurrent neural networks (RNNs)

(e.g., Long-Short Term Memory (LSTM) [21]), skip connec-

tions [41], convolutions [62] or graph convolutions [55], pool-

ing [62], batch normalization [48], layer normalization [20],

Target Model

Trace & Scale

Parametrize

Inter-Trial

Fusion

Intra-Trial

Fusion

Surrogate Model

1

2

3

4

Figure 6: Illustration of Model Shrinker (,) and Trial

Binder (,). The length of each bar represents layer width.

and attention [108]. As a result, many practical models like

ResNet [41] and Transformer [108] can be expressed as GPs

and apply MU parametrization, since they inherently consist

of these basic components.

Theory assumption. In contrast to prior works such

as NTK [49] that necessitate unnatural conditions, MU

parametrization only requires standard Gaussian initializa-

tion for the model, which is easily achievable in practice. In

terms of data, MU parametrization requires i.i.d. samples,

which is typically present in the same dataset. However, this

requirement also limits its ability to support fine-tuning (§7).

Key insight and mechanism. The main idea of MU

parametrization is: every activation vector has roughly i.i.d.

coordinates at any time during training neural networks in

the infinite-width limit. It aims to overcome the imbalanced

per-layer learning speed issue in practice. To this end, MU

parametrization performs layer-wise fine-grained adjustment,

including per-layer initialization variance, learning rate and

other optimizer-related hyperparameters (e.g., SGD momen-

tum, Adam beta). Specifically, since the output layer is up-

dated much faster than the input layer, MU parametrization

suppresses the learning rate and initialization variance of out-

put weights by w (width) times. In addition, for SGD-like

optimizers (linear tensor update), the learning rate of input

weights and all biases is multiplied by w. For Adam-like op-

timizers (non-linear tensor update, normalizes the gradient

coordinate-wise), the learning rate of hidden weights is di-

vided by w. Hence, MU parametrization ensures consistent

magnitude updates for each layer during training regardless

of its width so that hyperparameters can be transferred across

models with different widths at any time (i.e., same converge

speed across scaled models).

To summarize, in the large width limit, MU parametrization

reveals that hyperparameters yielding lower training losses for

narrower models also result in better performance for wider

models through a specific transfer mechanism. Hydro lever-

ages this effect to obtain better test accuracy efficiently via

surrogate-based tuning, albeit without a rigorous theoretical

guarantee for every model.

Instructive example. To provide a clearer explanation of

why parametrization is necessary and how it operates, we reca-

pitulate the key insights of [121] with an instructive example

[117]. Consider a 1-hidden-layer linear model f(x) = V Ux

with scalar inputs and outputs, as well as w-width layer

weights V,URw×1. In common practice (e.g., Xavier ini-

tialization [37]), we initialize them with VN (0,1/w) and

UN (0,1), which ensures f(x) = Θ(|x|) at initialization

(Θ(·) indicates asymptotically tight bound). After one step of

SGD with learning rate 1, the new weights are V V +θU

and U U + θV, where θ is some scalar of size Θ(1) de-

pending on the inputs, labels, and loss function. Then

f(x) = V ′⊤Ux

=

V U +θUU +θV V +θ2UV

x

(2)

which will blow up with width w in the infinite limit because

UU = Θ(w) by Law of Large Numbers. In other word, it

only allows O(1/w) learning rate so as to avoid float overflow,

and yield kernel limits (§2.2). Consequently, it fails to perform

feature learning (learning rate0) to update weights after

random initialization.

However, by applying maximal update parametrization, we

have VN

0,1/w2

, UN (0,1), learning rates ηV =

1/w and ηU = w. After one step of SGD, now we have

f(x) =

V U +θw1UU +θwV V +θ2UV

x

(3)

and one can verify this is Θ(1) and remains bounded. In

contrast to common practice, MU parametrization has Θ(1)

learning rate and admits feature learning maximally, which

allows every parameter to be updated maximally (in terms of

scaling with width) without leading to float overflow.

Heuristic adaptation. While Tensor Programs support

more versatile model components (e.g., convolution), obtain-

ing a closed-form solution for arbitrary models is infeasible.

The efficacy of the MU parametrization has been rigorously

demonstrated on a 2-hidden-layer MLP trained with SGD

for multiple steps, and the proof can be readily extended to

deeper MLPs [121]. For more general models in practice,

some heuristic tricks are adopted to enhance their hyperpa-

rameter transferability. For example, Transformer [108] mod-

els require two additional operations in the self-attention: (1)

scaling the attention logit by 1/dk rather than 1/dk, where

dk is the attention head size; (2) zero initialization on query

layer q. We also empirically find that using a larger sequence

length provides a better transfer effect for Transformer mod-

els. For models with some special components or architecture

(e.g., MoE [101]), hyperparameters may not well transfer with

MU parametrization alone. Hence, additional analysis and

tailored adjustments may be required.

Hydro parametrization. It is arduous and error-prone to

implement MU parametrization manually to generate a surro-

gate model. Developers are required to not only thoroughly

understand the MU parametrization theory, but also manually

Output Layer:

1. Zero-Variance Initialization

2. Layer Input Multiply S

3. If SGD Optimizer, Layer LR Divide S

Hidden Layer:

1. Init Variance Multiply S

2. SGD & Adam Optimizer LR Multiply S

Input Layer:

1. Init Variance Multiply S

2. If SGD Optimizer, Layer LR Divide S

Figure 7: Hydro parametrization implementation. Illustration

on a simple 4-layer model with SGD or Adam-like optimizer.

adjust the model width, initialization function and learning

rate layer by layer. Any incorrect adjustment may directly

incur hyperparameter transfer failures. To this end, we im-

plement Hydro parametrization, an automated and simplified

parametrization strategy based on MU parametrization. We

demonstrate the excellent effect of Hydro parametrization

with visualized results in Figures 1 and 10.

For a clearer illustration, we present the Hydro parametriza-

tion process in Figure 7, which applies different strategies to

the input, hidden and output layers. Developers only need to

specify their desired scaling ratio S (S = 8 by default) and then

Hydro will parametrize the model accordingly. Concretely, at

the model initialization stage, we apply zero-variance initial-

ization to the output layer instead of 1/w2, which will not be

detrimental to performance and can remove this mismatch is-

sue between the surrogate model and target model in the initial

Gaussian process [117]. Moreover, we apply zero initializa-

tion to all biases, and weights as well as learning rate scaling

strategies are annotated in the figure, which is invoked by

the prepare_optimizer API to build a hydro_optimizer.

Besides, we insert a Multiply layer in front of the output

layer to scale its input by S.

Applicable Scope: Hydro parametrization works well for

most ubiquitous hyperparameters that control model ini-

tialization and training, including learning rate, batchsize,

lr_scheduler, momentum, etc. However, it has limited support

on regularization-related hyperparameters, such as weight de-

cay and dropout, because they naturally depend on both the

model size and data size. Although parametrization cannot

be applied to all hyperparameters, it is sufficient to achieve

qualified performance in most cases. After most hyperpa-

rameters are tuned with the surrogate model, developers can

further tune the regularization hyperparameters within a much

smaller search space on the target model if needed. Moreover,

we provide a comprehensive summary of additional limita-

tions associated with Hydro parametrization in Section 7.

Trace and scale. Before performing the above parametriza-

tion, we need to first trace the target model and build a scaled

model. Since there are various model definition styles in the

PyTorch ecosystem, it is necessary to obtain a uniform and

equivalent modality from disparate community model codes.

We implement HydroTracer based on torch.fx [97], which

allows developers to trace and edit the model. Specifically,

we replace call_function nodes (e.g., torch.nn.functional)

with the corresponding call_module nodes (e.g., torch.nn)

for subsequent layer scaling and fusion (§4.2). We apply dif-

ferent scaling rules to the input, output and hidden layers.

For instance, we parse nn.Linear kwargs and modify both

the in_features and out_features values by dividing S for hid-

den layers. In addition, we only scale the out_features of

input and in_features value of output layers. To handle the

data-dependent control-flow, we use proxy nodes along with

developer-provided concrete values to determine the execu-

tion flow [61]. According to our evaluation of notable models,

including TorchVision [18] (e.g., ResNet [41], MobileNet

[44], VGG [103]) and HuggingFace Transformers [113] (e.g.,

BERT [30], GPT [95], Swin [76]), developers can trace and

scale these models with Hydro without modifying the code.

Correctness check. While Hydro has achieved automatic

parameterization, there are still potential failures due to cer-

tain special model components that require heuristic adapta-

tion as previously mentioned, as well as other corner cases

that have not been considered. To this end, we further im-

plement a safeguard mechanism to check the correctness of

the parametrization and notify users whether they should use

Hydro to prevent misleading hyperparameters and resource

wastage. Firstly, Hydro performs a simple per-layer width

check when scaling to avoid too narrow layers (e.g., only 1

neuron width for a Linear layer). Additionally, taking inspira-

tion from gradient checking as a simple method for verifying

the correctness of an autograd implementation, Hydro has a

quick parameterization profiling stage that checks whether the

average size (L1 value) of each activation vector is bounded

to avoid possible parameterization failure based on [117]. It

only lasts for very few steps at the beginning of the HPO job.

4.2

Trial Binder

Although Model Shrinker dramatically reduces the computa-

tion of each trial (Figure 3), it inevitably incurs the resource

underutilization issue, which deteriorates small- or mid-size

target models (e.g., deployed on edge devices). To address

this problem, Trial Binder further optimizes surrogate mod-

els by binding multiple trials and fuses internal operators

to better utilize accelerators. We illustrate its mechanism in

the bottom part of Figure 6. It merges a set of fusible trials

into a HydroTrial with grouped operators and optimizer ().

To further accelerate training, we automatically just-in-time

(JIT) compile the fused (inter-) surrogate model to obtain

fast and flexible fusion (intra-) kernels (). Note that the

last model with closer layer distance represents the reduced

memory-bounded operations through intra-trial fusion.

Inter-trial fusion. There are plenty of trials with the same

or similar model structure in a HPO job. Inspired by JAX

vmap [35,112], which returns a batched version of the target

function by vectorizing each input along the axis specified, we

can batch multiple trials into a single one by fusing their opera-

Framework

Input Data

Model States

MPS

Fusion Only

Hydro

1

5

1

5

1

5

(c)

Figure 8: Inter-trial fusion effect on ResNet-18. (a) Accu-

mulated throughout of fused surrogate model w.r.t the target

model. (b) GPU memory footprint of different fusion counts.

Red horizontal line denotes the A100 memory bound. (c)

Schematic diagram of memory occupation detail of 5 models

GPU sharing with MPS, Hydro and Fusion (w/o Scaling).

tors. Hydro implements an inter-trial fusion mechanism to au-

tomatically bind surrogate models. Specifically, Trial Binder

traverses the traced surrogate model and replaces the torch.nn

operators with grouped hydro.nn operators according to

the predefined fusion rule and fusion count F determined

by Trial Planner. hydro.nn provides mathematically equiva-

lent implementations of batched original PyTorch operators

based on HFTA [110]. For instance, hydro.nn.Linear is

implemented atop torch.baddbmm (i.e., batch matrix-matrix

product and add), which adds an additional dimension batch

(i.e., F) compared with torch.nn.Linear (addmm). Besides,

for each hydro.nn operator, we reimplement the initializa-

tion function to support independent model-wise Hydro

parametrization and realize the defusion mechanism to ex-

tract a specific sub-model. Additionally, hydro_optimizer

and hydro_lr_scheduler are designed to support both the

model fusion and parametrization simultaneously. These are

performed automatically, and developers typically do not need

to understand the rationale and modify codes.

Figure 8 plots the extraordinary effect of integrating model

scaling with inter-trial fusion on ResNet-18 (S = 8), tested

on CIFAR-10 with batchsize=256. It is evident that Hydro

is capable of concurrently training impressive 676 models

on a single A100 GPU. Compared with the conventional

GPU sharing mechanism MPS [13] (MIG [12] has similar

performance), Hydro achieves over 10× training throughput

improvement and over 20× GPU memory conservation. If

we directly apply inter-trial fusion to the target model (with-

out scaling), the throughput improvement is relatively much

limited. Furthermore, we provide an intuitive interpretation

of how memory footprint reduction occurs in Figure 8 (c).

The model states (blue blocks) encompass all aspects asso-

ciated with model training such as model weights, gradients,

activations, and optimizer states [96]. MPS has repetitive

memory overheads incurred by CUDA context of DL frame-

work (purple blocks) and independent data loading (pink

blocks). In contrast, Hydro avoid such redundancy and further

reduce model-related memory footprint. Note that here we

only compare with vanilla training paradigm without consid-

ering more advanced memory optimization techniques like

Salus [124]. Moreover, beyond the better GPU utilization and

higher throughput, inter-trial fusion also alleviates the I/O

pressure owing to the accompanied data-loading fusion.

Lazy intra-trial fusion. Hydro supports automatic model

fusion to further accelerate training based on the nvFuser

[10] compiler backend. Although plenty of previous works

[51,107,129] demonstrate that operator fusion can improve

training throughput via better memory locality, it does not al-

ways bring benefits to HPO workloads due to its high compil-

ing overhead. For instance, nvFuser [10] takes approximately

2-epoch time to compile a ResNet-18 model to deliver around

10% speedup per epoch, which means a trial needs to run at

least 20 epochs to avoid slowdown. However, most trials will

end up in a few epochs for multi-fidelity tuning algorithms.

To this end, Hydro apathetically adopts the intra-trial fusion.

For simplicity, Hydro currently only applies to trials with

deterministic training steps, such as all HydroTrials when

applying single-fidelity tuning algorithms and the trial that

trains the target model with transferred hyperparameters.

4.3

Trial Planner

Trial Planner is the key module that interacts with the tuning

algorithm and trial executor. We introduce two mechanisms

that improve the surrogate-based tuning efficiency.

Adaptive fusion. The trial count and resource amount vary

significantly across different HPO jobs. Hence, the fusion

count F of each HydroTrial should be adaptively determined

to achieve the desired performance. Hydro contains the fol-

lowing steps to fuse trials and assign GPUs: (1) Trial Planner

invokes the tuning algorithm to generate a set of hyperparam-

eter configurations (trials). (2) Since inter-trial fusion requires

trials with the same operator shapes, we split them into differ-

ent trial groups according to their batchsizes. (3) Based on the

linear growth of GPU memory shown in Figure 8 (b), we can

profile the trials with F = 1 and F = 2 for each trial group

and estimate the upper bound of the fusion count Fmax. (4)

Hydro assigns all available GPUs to each trial group accord-

ing to group’s weight, which equals to B×N (denoted as the

product of batchsize and trial count of the group). (5) Each

trial group evenly distributes trials based on the group GPU

amount and Fmax, and Hydro fuses them as a HydroTrial on

each GPU. In this way, Hydro can leverage as many GPUs as

possible and achieve the optimal global throughput.

Eager transfer. As the HPO job progresses, more and more

1 2 3 4

1

2

3

4

5 6 7 8

1 2 3

1

4

2

3

4

5 6 7

1 2

1

3

2

4

3

4

5 6

1

1

2

2

3

3

4

4

5

5

W1

W2

W3

W4

1

2

3 4 5

(a) 1F1B (Most Popular Pipeline Schedule)

1 2 3 4

Trial 1

1

2

3

4

5 6 7 8

T1

1 2 3

Trial 2

1

4

2

3

4

T2

5 6 7

T2

1 2

T3

1

3

2

4

3

4

Trial 3

5 6

T3

1

1

2

2

3

3

4

4

Trial 4

5

5

W1

W2

W3

W4

Memory

1

2

3 4 5

(b) Hydro Trials Interleave with 1F1B Workload

Memory

Forward

Pass

Backward

Pass

Bubble

Model & Framework

Memory

Activation

Memory

Hydro

Trial

Hydro

Memory

Resume

Resume

Pause

Flush

Pause

Flush

Figure 9: Illustration of (a) 1F1B Pipeline and (b) Hydro

Bubble Squeezer, with four pipeline stages and four micro-

batches. Note the right-side memory diagrams can only reflect

the relative relation of the same color blocks across workers.

trials terminate and the degree of the parallelism gradually

decreases, resulting in underutilized or idle resources. On

the other hand, the best hyperparameter configuration some-

times appears in the early stage. Therefore, instead of training

the target model after all the surrogate-based tuning trials

are done, we can eagerly transfer the intermediate best hy-

perparameters and leverage vacated resources to validate the

configuration on the target model. Hydro records all evaluated

hyperparameters and schedules a TargetTrial for the target

model training when 50% (customizable) of the surrogate-

based tuning trials are done and there exist idle resources.

If a better hyperparameter is searched, Hydro terminates the

on-going TargetTrial or starts a new TargetTrial depending on

the resource utilization. This mechanism efficiently shortens

the job makespan and improves the resource utilization.

5

Hydro Coordinator

Hydro Coordinator focuses on cluster-level optimization. It

consists of three modules: Bubble Squeezer, Heterogeneity-

Aware Allocator and Elastic Executor. It is important to high-

light that the first two modules are tailored for specific cluster

scenarios. Specifically, Bubble Squeezer can only be acti-

vated when a pipeline-enabled foundation model pretraining

job is running within the cluster. The Heterogeneity-Aware

Allocator is meticulously designed to better leverage multiple

generations of GPUs coexisting in the cluster.

5.1

Bubble Squeezer

In addition to HPO jobs, there are many kinds of workloads

that coexist in the GPU datacenter, such as inference, debug-

ging and large-scale distributed training jobs [45, 50, 111].

With the rapid popularity of foundation models (e.g., GPT-

3 [24]) in recent years, some large model pretraining work-

loads exist in our datacenter in the long term. As complained

by many users, the majority of machines are occupied by

large model training jobs that usually last for days to weeks,

which incurs the starvation of other jobs. Additionally, the

pipeline parallelism [85,88] is usually adopted to support a

larger model by splitting it into several stages and placing

them across multiple workers. However, bubbles inherently

exist in the synchronous pipeline parallelism [106], such as

the commonly used 1F1B [34,86] strategy. Besides, the imbal-

ance peak memory issue (Figure 9) between different pipeline

stages further exacerbates the resource inefficiency [65].

Hydro designs Bubble Squeezer, which leverages bubbles

to greatly extend the tuning job resources in an interleaving

execution way, almost without hurting the training throughout

of large models. HydroTrials are perfectly suitable for the

bubble interleaving execution due to the following unique fea-

tures: (1) Throughput insensitivity. Unlike general DL training

jobs, tuning jobs are more tolerant of the slowdown of partial

trials. This inspires us to squeeze the spare resources of the

bubbles and execute trials in a pause-and-resume way. (2) De-

terministic resource pattern. General small-scale workloads

(e.g., debugging) have unknown and unpredictable resource

requirements. However, Hydro profiles and records the re-

source consumption of HydroTrials, mitigating the potential

out-of-memory (OOM) issues if they are colocated with large

models. (3) Elastic trial size. Based on Model Shrinker, the

scaled model has a much smaller memory footprint (Figure

3) than the original model, which means we typically do not

need to swap out its GPU memory during colocation. Besides,

we can dynamically adjust the trial fusion count according to

the remaining GPU memory with Trial Binder.

To clearly illustrate how Bubble Squeezer works, we first

introduce the 1F1B pipeline parallelism in Figure 9 (a). It

transfers intermediate activations of the partial model at the

forward and backward passes between different workers using

point-to-point communication [130], thus each worker cannot

continuously utilize the GPU. For Worker 1, after the forward

pass of the last micro-batch (blue block 4), it has to wait for

the backward pass of the first micro-batch (green block 1),

leaving GPU idle for a long time. Other workers also present

similar bubble patterns but occupy less GPU memory since

fewer activations of micro-batch needed to store.

In Figure 9 (b), Hydro interleaves four HydroTrials of

different sizes with the large model training workload. Each

trial executes in a pause-and-resume paradigm to squeeze the

bubbles. Since Hydro Tuner has traced and canonicated each

layer with hydro.nn, we further register hooks on each mod-

ule of the trial to support on-demand pause and resumption in

the forward and backward passes of each layer. When a large

model training job exists, Hydro coordinates with datacenter

scheduler to acquire more GPUs from this model and tags

them as ephemeral resources. For the large model, we also im-

plement a corresponding hook inside its training framework

(i.e., DeepSpeed [96]) to report its training progress and re-

source consumption. Each worker executes its corresponding

pipeline under DeepSpeed’s pipeline parallelism. Therefore,

we implement a fine-grained synchronization mechanism to

guarantee that HydroTrials only could be executed within

the bubbles, by intercepting the status of the CUDA streams

of the NCCL kernels. Hydro can further adjust the fusion

count to adaptively fit in the remaining memory and improve

GPU utilization. At the beginning and end of the bubble of

large model training, we control the resumption and pause

of trial model training by Linux signals. The fine-grained

suspend-resume control eliminates the performance interfer-

ence caused by CUDA kernels running simultaneously.

In general, the effectiveness of Bubble Squeezer varies de-

pending on multiple factors, and we present the scenarios

where it works best. Regarding the HPO job aspect, Hydro

is more effective when using (1) multi-fidelity tuning algo-

rithms because they allow most trials to be terminated in a few

epochs using the ephemeral resources and execute immediate

top trials on exclusive resources to avoid possible blocking

caused by interleaving slowdown. In addition, (2) models with

fewer layers are preferred as they are prone to complete the en-

tire iteration within the bubble time and require relatively less

memory to support a higher fusion number. As for pipelined

large model aspect, Hydro can achieve better performance

when the pretraining job has (3) more pipeline stages across

more servers, which implies a higher bubble ratio and more

ephemeral resources. A large model pretraining job typically

can support multiple different HPO jobs interleaving simulta-

neously and accelerate dozens, even hundreds of HPO jobs

(depending on its resources and duration scale) during its

pretraining process. In addition, there may be cases where

some scaled models are still too large to be allocated on any

GPU of the pretraining model. Due to the high memory swap

overhead in our scenario, Hydro does not support offloading

techniques like Bamboo [106]. As a result, Bubble Squeezer

is unable to support such models.

5.2

Heterogeneity-Aware Allocator

HPO workloads generally have diminishing resource require-

ments [71]. They usually explore plenty of trials at the begin-

ning and gradually decrease the search concurrency. At the

final stage, only a few trials are exploited. Hence, tuning with

fixed GPU resources can lead to underutilization. Existing

HPO systems [32,82] support autoscaling to dynamically ad-

just the tuning resources. However, they do not consider the

GPU heterogeneity in the datacenter.

Inspired by Gavel [87], a novel heterogeneity-aware cluster

scheduler for general DL jobs, we design a resource allocator

to allocate appropriate GPUs to trials, which can improve the

cluster-wide efficiency without sacrificing the job makespan.

Hydro supports both resource autoscaling and heterogeneity-

aware allocation. Specifically, if there is any node or GPU idle

for over 1 minute (customizable), Hydro will interact with

the cluster scheduler to release the resource. Other affiliated

resources like CPU will also be released as a bundle. Ad-

ditionally, Hydro creates TargetTrial with the eager transfer

mechanism and makes the target model training process well

hidden inside the tuning time. Since the TargetTrial typically

trains alone without fusion, it may not be able to fully utilize

the GPU resources. So Hydro will place it on an GPU of

old version (e.g., V100) if its SM Activity rate (measured

by NVIDIA DCGM [11]) is lower than 50% (customizable).

Similar action will be applied to surrogate models if their al-

located resources are underutilized and there exist other HPO

jobs pending in our service queue.

5.3

Elastic Executor

Elastic Executor is designed to improve the job efficiency by

leveraging all assigned GPU resources. It supports two elastic

mechanisms: (1) dynamic split and (2) automated distributed

training. Specifically, when an idle GPU emerges, the fused

HydroTrial will not directly increase its GPU count by con-

ventional distributed training. Instead, Hydro will evenly split

this HydroTrial into multiple HydroTrials and exclusively

place them on the idle GPUs to reduce the communication

overhead. Furthermore, since the memory footprint of some

large models is high even though scaled, Hydro supports two

types of elastic strategies for unfused surrogate models: (a)

Evenly distribute: allocating idle GPU resources to all unfused

surrogate models evenly. (b) Performance-aware (default):

allocating idle GPU resources to the top performing trial. For

the target model, Hydro automatically increases the number

of workers to enable distributed training.

6

Evaluation

Hydro is implemented on top of Ray [72,84] with about 12K

LoC. For Hydro Tuner, Model Shrinker relies on torch.fx [97]

and mup [117], while Trial Binder is built with HFTA [110]

and nvFuser [10]. As for Hydro Coordinator, we modify Deep-

Speed [96] to further support Bubble Squeezer and validate

the interleaving execution as a prototype. And the Elastic

Executor based on Ray Train as well as PyTorch FSDP [17].

We evaluate Hydro Tuner and Hydro Coordinator indepen-

dently for a fair comparison. Our experiment search space

does not include weight decay because Hydro is unable to

transfer regularization hyperparameters, but it is sufficient to

achieve qualified performance without tuning it.

6.1

Experiment Setup

Testbed. We conduct our experiments on a GPU datacenter

of Shanghai AI Laboratory. Each node has 8 NVIDIA A100

80GB GPUs, 2 AMD EPYC 7742 CPUs (128 cores) [2]

and 1TB memory. GPUs are interconnected to each other by

NVLink and NVSwitch [14], and inter-node communication

is achieved via NVIDIA Mellanox 200Gbps HDR InfiniBand

[7]. All the experiments are conducted on A100 GPUs, unless

explicitly stated in §6.5.

Workloads and search spaces. We evaluate Hydro tuning

performance over six popular CV/NLP models, as listed in

Table 2. Specifically, GPT-3 XL is a large language model

architecture belonging to GPT-3 family. It contains 1.3B pa-

rameters and we use an open source implementation by GPT-

Task

Search Space

Model

Dataset

Optimizer

# of GPU

# of Trial

Avg. Time

Reduction

Avg. Quality

Difference

Size

GPT-3 XL [24]

OpenWebText [38]

AdamW

128

100

78.5 ×

0.48 ppl

XL

Language

Modeling

lr: UQlog(105, 101, 105)

gamma: UQ(0.01, 0.9, 0.01)

Transformer [108]

WikiText-103 [81]

Adam

8

200

8.7 ×

0.15 ppl

M

WideResNet-50 [126]

ImageNet [29]

SGD

32

200

20.3 ×

+1.18% acc

XL

MobileNetV3 Large [44]

Flowers102 [90]

Adam

16

500

12.3 ×

+0.05% acc

L

VGG-11 [103]

CIFAR-100 [57]

SGD

8

500

10.8 ×

+0.09% acc

M

Image

Classification

lr: UQlog(104, 1.0, 104)

momentum: UQ(0.5, 0.999, 103)

batchsize: [128, 256, 512]

gamma: UQ(0.01, 0.9, 0.01)

ResNet-18 [41]

CIFAR-10 [57]

SGD

8

1000

16.2 ×

+0.02% acc

M

Table 2: Summary of (1) workloads used in the evaluation and (2) single-fidelity tuning improvements over Ray. Model Quality:

ppl indicates perplexity (the lower the better) and acc denotes accuracy (the higher the better). For XL tasks, we estimate the

time cost of Ray based on simulation and use the official hyperparameter setting as the model quality baseline.

60

70

80

90

Val. Accuracy (%, S = 1)

J

I

H

G

F

E

D

C

B

A

69.64

78.16

79.25

79.80

83.52

84.38

84.42

87.18

92.20

92.32

(a)

60

70

80

90

Val. Accuracy (%, S = 2)

J

I

H

G

F

E

D

C

B

A

69.49

76.52

78.43

78.87

83.22

83.68

83.76

85.81

90.31

90.84

(b)

60

70

80

90

Val. Accuracy (%, S = 4)

J

I

G

H

F

E

D

C

B

A

68.23

74.64

76.68

76.83

80.91

81.26

81.61

83.22

86.78

86.92

(c)

60

70

80

90

Val. Accuracy (%, S = 8)

J

I

G

H

F

E

D

C

B

A

64.04

66.78

71.79

72.27

75.14

76.15

76.16

77.72

82.13

82.54

(d)

0

2000 4000 6000 8000 10000

Training Iterations

0.0

0.5

1.0

1.5

2.0

2.5

Training Loss

(e)

C (lr=0.01)

C with Fusion

E (lr=0.005)

E with Fusion

H (lr=0.002)

H with Fusion

A: [256, 0.05, 0.95]

B: [128, 0.3, 0.6]

C: [512, 0.01, 0.9]

D: [128, 0.005, 0.6]

E: [512, 0.005, 0.9]

F: [256, 0.01, 0.5]

G: [256, 0.001, 0.9]

H: [512, 0.002, 0.9]

I: [128, 0.2, 0.99]

J: [512, 0.0004, 0.95]

Figure 10: Hydro Tuner mechanisms validation. (a)(d) Scaling validation: randomly select 10 hyperparameter sets ([batchsize,

lr, momentum]) to visualize the transfer effect of multi-dimensional hyperparameters across different scaling ratios S = 1,2,4,8

on model ResNet-18. (e) Fusion validation: loss curves of the standard model (solid line) and inter-trial fused model (dash line).

Neo [5,23]. We further enable mixed precision training for

WideResNet-50 and two language modeling tasks. For the

dataset, we crop Flowers102 into 224×224 images, whose

input size is the same as ImageNet. And we swap its train and

test dataset split to get a larger training dataset to make it sim-

ilar to more general jobs. Moreover, we denote single-node

tasks as M-size, and distributed tuning tasks as L/XL-size.

We adopt three kinds of optimizers for above models, in-

cluding SGD [99], Adam [54], and AdamW [77]. We use

StepLR to decay the learning rate (lr) of each parameter

group by gamma at every fixed step for all tasks. Additionally,

we design two groups of search spaces for CV and NLP tasks

respectively (Table 2), where UQ(lower,upper,q) represents

uniformly sampling a quantized (increment of q) float value

between lower and upper. Similarly, UQlog uniformly sam-

ples in different orders of magnitude. Note that the search

space of MobileNetV3 Large excludes momentum due to the

incompatibility of Adam.

Tuning algorithms. Hydro supports multiple popular single-

fidelity and multi-fidelity tuning algorithms, such as Random

[22], HyperBand [64], ASHA [63]. Since our work focuses

on system aspect optimization instead of tuning algorithms,

we select two representative tuning algorithms in our evalu-

ation: (1) Random (single-fidelity): fully evaluates each ran-

domly generated trial; (2) ASHA (multi-fidelity): eliminates

unpromising trials via asynchronous successive halving strat-

egy. They are common hyperparameter tuning paradigms in

practice. Besides, their asynchronous and prior-independent

nature makes them more suitable for large-scale distributed

tuning with numerous trials [71].

Baselines. We consider the following two systems as baseline:

(1) Ray [72, 84]: performs HPO with the vanilla Ray Tune

library; (2) Ray+ES: applies two advanced techniques in Ray

Tune (Elastic training and GPU Sharing). Our implementa-

tion of Ray+ES refers to HyperSched [71] and Fluid [125].

Specifically, we place multiple trials on the same GPU us-

ing NVIDIA MPS [13] and allocate more GPU resources to

the top performing trials if idle GPUs are available. We do

not employ A100 MIG [12] sharing due to its similar perfor-

mance with MPS but less flexibility [110]. Additionally, since

existing popular HPO systems (Table 1) mainly differ in the

application scenario and API design, and their system perfor-

mance on the same tuning algorithm is similar, the Ray-based

systems are sufficient for representing SOTA.

6.2

Surrogate-based Tuning Validation

Before performing end-to-end evaluations, we first give an

intuitive experiment to validate the effect of surrogate-based

tuning, which is the foundation of Hydro. As shown in Figure

10 (a)(d), we randomly choose 10 hyperparameter configu-

rations (denoted as AJ) on the ResNet-18 model and build

Model

# of GPU

# of Trial

Avg. Time

Improvement

Avg. Quality

Difference

GPT-3 XL

64

100

33.4 ×

0.43 ppl

Transformer

4

200

5.8 ×

0.09 ppl

WideResNet-50

16

200

9.7 ×

+0.87% acc

MobileNetV3 Large

8

500

8.0 ×

+0.08% acc

VGG-11

4

500

9.4 ×

+0.19% acc

ResNet-18

4

1000

14.5 ×

+0.05% acc

Table 3: Summary of multi-fidelity tuning improvements.

Deadline (s)

# of GPU

Model

Avg. Accuracy

Ray

Ray+ES

Hydro

900

4

VGG-11

65.42%

66.39%

68.68%

ResNet-18

89.66%

90.71%

91.32%

Table 4: Summary of tuning performance with a deadline.

surrogate models with Hydro using different scaling ratios

S = 2,4,8, where S = 1 represents the target model. We train

each model for 100 epochs on the CIFAR-10 dataset with

a fixed seed=1. Since the HPO job is essentially a ranking

problem of hyperparameter configurations, we mainly care

about whether the order is maintained especially for the top

configurations, namely hyperparameter transfer effect. From

the result, it is obvious that the performance ranking of hy-

perparameters transfers well across different scaling ratios.

Admittedly, configurations G and H are swapped when S4,

but it has no influence on the final tuning result since they per-

form poorly and top configurations keep a consistent ranking.

Besides, the wider model always outperforms the narrower

one under the same hyperparameters, which is inline with MU

parametrization theory and demonstrates that surrogate model

can effectively transfer multi-dimensional hyperparameters.

Additionally, we also validate the inter-trial fusion effect,

which is another key mechanism of Hydro. Figure 10 (e)

shows the training loss curves of trials C, E, H and their fused

versions. We select these three trials because their batchsize

and momentum are consistent and only differ in lr. As we can

see, the convergence curves of the fused model well overlap

with the original standalone training curves, which demon-

strates that inter-trial fusion is a mathematically equivalent

transformation and does not affect the model convergence.

6.3

End-to-End Performance of Hydro Tuner

To cover most hyperparameter tuning scenarios in practice, we

conduct end-to-end experiments across 6 workloads with dif-

ferent settings and 3 common tuning paradigms (case IIII).

Note that Hydro Tuner adopts a fixed resource size (without

enabling Hydro Coordinator) for fair comparisons.

Case I: single-fidelity tuning. When a user seeks for ex-

tremely excellent model performance with ample resources,

single-fidelity tuning is applied to avoid missing the best hy-

perparameter configuration. Table 2 summarizes the Hydro

VGG11

ResNet18

VGG11

ResNet18

0

5

10

15

20

Makespan (hours)

Single-fidelity

Multi-fidelity

Ray

Ray+ES

Hydro

40

60

80

100

Accuracy

69.33

92.69

68.49

91.91

69.42

92.71

68.68

91.96

Ray

Hydro

Figure 11: Summary of the end-to-end results. Bars indicate

tuning makespan and points represent final model accuracy.

improvement on single-fidelity tuning over different sizes of

workloads, where we apply S = 16 for XL models and S = 8

(default value) for other models. Since HPO jobs require com-

pletely training massive trials, we perform each experiment

twice and report their average results on time reduction and

tuned model quality over Ray. Besides, we obtain Ray tuning

time of XL experiments based on simulation due to their un-

acceptable tuning cost, and adopt the official hyperparameter

configurations [16,24] to train the model as quality baselines.

The target model training time is included in Hydro.

From the table, we can see that Hydro substantially outper-

forms Ray by 8.778.5× in time reduction, while obtaining

better final model quality. The time reduction mainly derives

from two aspects: (1) Less resource demand of trials. For

instance, the scaled GPT-3 XL trials do not require distributed

training. For smaller models, Hydro further applies inter-trial

fusion to improve trial concurrency and resource utilization.

(2) Smaller model trains faster. Each trial has fewer FLOPs

(Figure 3) to compute, which is more obvious on larger mod-

els. Additionally, we also observe that the effect of Hydro

is more evident for larger models, with more intensive trials

and fewer resources. This reflects Hydro is more suitable for

large-scale HPO jobs with limited resources, which is hard to

handle by existing systems.

Case II: multi-fidelity tuning. When a user desires to obtain

a good model with a relatively lower cost, multi-fidelity tun-

ing is applied to search hyperparameters efficiently. Table 3

reports the Hydro performance on multi-fidelity tuning. We

keep the same experiment settings as Case I, except using

half GPU resources. Besides, we configure ASHA [63] with

bracket = 1,grace = 3,reduction = 3. We observe that Hy-

dro can achieve 5.833.4× reduction over Ray. Hydro can

further benefits ASHA due to its much higher concurrency,

which prevents the inaccurate promotion issue of ASHA [66].

Furthermore, we find that Hydro can also slightly improve

the final model quality, which is mainly due to the different

model initialization and more balanced layer-wise training

rate configuration by Hydro parametrization. The results are

also in line with Figure 1 that Hydro delivers a lower loss.

Case III: tuning with a deadline. When a user wants to

get a model as good as possible by a fixed deadline, budget-

bounded ASHA is applied. We simply evaluate two models

with a deadline of 15 minutes as shown in Table 4. Hydro

VGG-11

ResNet-18

0

5

10

15

20

Makespan (hours)

(a) Fusion Effect

Ray

Hydro

w/o Inter-fusion

Hydro

w/o Intra-fusion

Hydro

VGG-11

ResNet-18

0

2

4

6

8

10

(b) Scaling Effect

S = 1 (w/o Scaling)

S = 2

S = 4

S = 8 (Default)

S = 16

Figure 12: Ablation study. (a) Effect of inter- or intra-trial

fusion. (b) Makespan of different scaling ratios.

0

250

500

750

1000

Inter-Trial Fusion Number

0

10

20

30

Normalized Throughput

(a)

0

250

500

750

1000

Inter-Trial Fusion Number

0

20

40

60

80

Memory (GB)

(b)

S = 8

S = 8 (AMP)

S = 4

S = 4 (AMP)

S = 2

S = 2 (AMP)

Figure 13: Sensitivity analysis of S and AMP on ResNet-18.

(a) Accumulated throughout. (b) GPU memory footprint.

outperforms other baselines in final model accuracy within a

limited time since it can well hide the target model training

time inside the surrogate model tuning with Eager Transfer.

End-to-end result visualization. Figure 11 summarizes the

makespan and accuracy of VGG-11 and ResNet-18 across

different tuning algorithms and baselines. We note that Ray

and Ray-ES share the same accuracy point since elastic and

GPU sharing have no effect on the final model quality. The

surrogate-based tuning (Hydro) can significantly reduce the

search makespan without sacrificing the model accuracy. Due

to the page limit, we only select these two models for presen-

tation because of their relatively obvious efficacy of Ray-ES.

Ray-ES has less improvement over Ray for larger models like

WideResNet-50, since it cannot benefit from GPU sharing

and the elastic improvement is limited (only for later stage).

6.4

More Evaluation on Hydro Tuner

Ablation study of fusion. Figure 12 (a) reveals an interest-

ing observation that Hydro can only achieve very limited

improvement over Ray if inter-trial fusion is disabled, even

though we have scaled the model by 8×. This is because

GPUs are underutilized for such small models and there is no

evident training speedup although we scale the model. Hence,

it is important to combine Model Shrinker and Trial Binder

to achieve the desired performance. Additionally, we also

evaluate the effect of intra-trial fusion. However, we find its

improvement is limited on small models.

Sensitivity analysis of scaling. Figure 13 clearly presents the

effect of the scaling ratio S on GPU memory and accumulated

fused trial throughput, where the normalization base is the

throughput of the target model. We find that the peak through-

put increases linearly alone with S. GPU memory also shows

0

50

100

150

200

250

300

350

400

Time (s)

0

20

40

60

80

100

SM Activity (%)

Ray

Ray+ES

Hydro

Figure 14: GPU utilization of HPO systems on ResNet-18.

500

1000

1500

2000

2500

Time (ms)

0

25

50

75

100

SM Activity (%)

HydroTrial

LLM

LLM + Bubble Squeezer

Figure 15: Visualizing Bubble Squeezer effect via DCGM.

Two iterations of the first pipe stage are presented. The execu-

tion periods of the HydroTrial are highlighted by red arrows.

a similar pattern. In Figure 12 (b), we further evaluate the

effect of the scaling ratio S on the overall tuning time. Hydro

can continuously obtain benefits from higher scaling ratios.

Besides, the final model accuracy maintains stable.

Sensitivity analysis of AMP. Figure 13 analyzes the effect

of mixed precision training (i.e., AMP [15]), where solid and

dashed lines represent the settings without and with AMP, re-

spectively. We can find that the peak throughput can be further

improved via enabling AMP. Besides, its effect on memory is

also obvious, improving nearly 2× maximum fusion count.

Impact on GPU utilization. Figure 14 plots the GPU uti-

lization traces on one GPU for 300 seconds using different

HPO systems. We employ NVIDIA DCGM [11] to record

SM Activity as GPU utilization. It is obvious that Hydro

can achieve much higher GPU utilization than other baselines

owing to the superior capability of inter-trail fusion [110].

Overhead analysis. We perform the overhead analysis on

the ResNet-18 multi-fidelity tuning workload. Its overhead

mainly derives from two aspects: (1) profiling accounts for

0.8%; (2) defusion (including trial restart) accounts for 3.3%.

The associated overhead is minor when weighed against the

substantial enhancements in the tuning efficiency of Hydro.

6.5

Hydro Coordinator Evaluation

Bubble Squeezer. To evaluate the impact of Bubble Squeezer,

we interleave HydroTrials with a large GPT model over 32

A100 GPUs containing 4 pipeline stages on 4 nodes, which

is implemented based on DeepSpeed [96] along with Mega-

tronLM [56,88,102]. We measured the SM activity with and

without Bubble Squeezer in Figure 15. Two traces are col-

lected separately and we align them at the beginning of the

figure. For the original GPT training, since the only active

kernel in the bubble is NCCL kernel for communication, the

SM activity is extremely poor (about 2%) during the bubble.

Hydro utilizes the unused SMs and achieves a relatively high

SM utilization at about 50%, with no evident slowdown to

the GPT model training. Here the HydroTrial is ResNet-18

model with fusion count F = 16, obtaining around 15% of ex-

clusive throughput. We also measure the throughput influence

of direct colocation and find it causes unacceptable interfer-

ence (about 12% slowdown for the large model). Additionally,

we further simulate the end-to-end performance of Bubble

Squeezer. Here we set that the Hydro tuning job can only

apply 1 exclusive GPU since most resources are occupied by

the large model. We find the makespan of the tuning job can

be greatly reduced by 2.7× with the free lunch.

Heterogeneity-Aware Allocator. We create a tiny cluster

partition with 2 A100 and 2 V100 nodes (32 GPUs in to-

tal) to evaluate the impact of Heterogeneity-Aware Alloca-

tor. Besides, we uniformly sample 20 middle-size HPO jobs

from Table 3 and randomly generate their job arrival time

within one hour. Compared to resource-agnostic allocation,

we find Heterogeneity-Aware Allocator achieves approxi-

mately a 1.3x reduction in the average job completion time.

7

Discussion

Limitations. Despite the extraordinary performance, Hydro’s

surrogate-based tuning paradigm does have three limitations:

(1) Hydro parametrization does not support regularization

hyperparameters, such as weight decay and dropout, as eluci-

dated in §4.1. (2) Hydro does not allow for any customized

initialization techniques because Hydro implements its own

automatic layer-wise re-initialization mechanism, which plays

a crucial role in parameterization. (3) Hydro does not sup-

port fine-tuning since its theory is built atop i.i.d. samples

(requiring the same dataset). Nevertheless, Hydro can deliver

qualified models for most cases.

Future work. In the future, we plan to improve our work in

following directions. (1) Supporting more DL frameworks

like TensorFlow [19] and JAX [35]. (2) Considering more re-

source dimensions like CPU and network bandwidth besides

GPU [83,128], such as implementing the dataloader fusion

of trials to further alleviate I/O contention. (3) Expanding the

application scenarios such as cloud environments. It presents

an opportunity for dynamic selection of heterogeneous spot

instances, which can yield substantial cost savings [82,106].

(4) Enabling partial model fusion across trails with minor

architectural differences (e.g., add/remove/modify a few lay-

ers/blocks). Furthermore, Hydro can integrate model match-

ing technique from ModelKeeper [60] to identify the models

with similar architectures across jobs from different users

and achieve cross-job level fusion, which can significantly

improve cluster efficiency.

8

Related Work

AutoML systems. Automated Machine Learning (AutoML)

refers to the process of automating the tasks associated with

optimizing ML model performance. In general, AutoML com-

prises two essential components: HPO and Neural Architec-

ture Search (NAS). NAS systems (e.g., Retiarii [127], Modu-

larNAS [74]) aim to discover the optimal model architecture

for a specific task. On the other hand, HPO focuses on opti-

mizing the hyperparameters of a fixed architecture, usually

separate from NAS. Our work primarily concentrates on HPO.

Prior HPO systems like HyperSched [71], Rubberband [82]

and Seer [32] support elastic training to allocate more GPU re-

sources to promising trials, which is also supported in Hydro.

Elastic training can make use of idle GPUs but fails to improve

single GPU utilization. On the other hand, Fluid [125] further

leverages NVIDIA MPS [13] technique to allocate multiple

trials on a single GPU. HFTA [110] achieves inter-trail fusion

on a shared accelerator. They can improve hardware utiliza-

tion but only work well on tiny models (e.g., AlexNet [58],

PointNet [93]). Based on the unique surrogate-base tuning na-

ture, Hydro significantly extends the fusion application scope

via model scaling and achieves automatic model fusion with

minimum manual effort.

Pipeline parallelism and interleaving execution. Recent

studies exploit bubbles induced by pipeline parallelism from

multiple angles. Bamboo [106] fills redundant computations

into bubbles to provide resilience and fast recovery for pre-

emptible cloud instances. EnvPipe [26] selectively lowers

the SM frequency of bubble periods to save energy. Unlike

them, Hydro leverages bubbles to train HPO trials via inter-

leaving execution, which is inspired by some prior works.

For instance, Wavelet [109] and Zico [73] reduce the GPU

peak memory based on interleaving. Muri [128] supports

multi-resource interleaving to reduce contention.

9

Conclusion

This paper presents Hydro, a surrogate-based hyperparameter

tuning service that provide job and cluster level optimization

via automated model scaling, fusion and interleaving. Our

experiments show that Hydro can dramatically reduce the

tuning makespan and improve the cluster resource utilization.

Acknowledgments

We sincerely thank our shepherd, Mathias Lécuyer, and the

anonymous OSDI reviewers for their valuable comments on

this paper. We also want to thank Greg Yang from Microsoft

for the theory part support, Richard Liaw and Antoni Baum

from Anyscale for the system development assistance, Shang

Wang and Xin Li from UofT for their insightful discussion

on inter-trial fusion, Shenggan Cheng and Shenggui Li from

NUS for their constructive feedback on bubble squeezer. Ad-

ditionally, we thank Li Ma and Shixin Yu for their technical

support, as well as generous hardware resources from Shang-

hai AI Laboratory. This study is supported under the RIE2020

Industry Alignment Fund - Industry Collaboration Projects

(IAF-ICP) Funding Initiative, as well as cash and in-kind con-

tributions from the industry partner(s). Zhisheng Ye, Meng

Zhang and Qiaoling Chen contribute equally to this work.

References

[1] Alibaba machine learning platform for ai.

https:

//www.alibabacloud.com/product/machine-lea

rning, 2023.

[2] Amd epyc 7742 cpu. https://www.amd.com/en/p

roducts/cpu/amd-epyc-7742, 2023.

[3] Chatgpt.

https://openai.com/blog/chatgpt,

2023.

[4] Duolingo. https://www.duolingo.com/, 2023.

[5] Eleutherai gpt-neo 1.3b. https://huggingface.co

/EleutherAI/gpt-neo-1.3B, 2023.

[6] Github copilot. https://github.com/features/co

pilot/, 2023.

[7] Infiniband networking. https://www.nvidia.com/e

n-us/networking/products/infiniband/, 2023.

[8] Microsoft azure automated machine learning. https:

//azure.microsoft.com/en-us/products/machi

ne-learning/automatedml, 2023.

[9] Microsoft neural network intelligence. https://gith

ub.com/microsoft/nni, 2023.

[10] Nvfuser. https://github.com/pytorch/pytorch

/projects/30, 2023.

[11] Nvidia data center gpu manager. https://develope

r.nvidia.com/dcgm, 2023.

[12] Nvidia multi-instance gpu. https://www.nvidia.c

om/en-us/technologies/multi-instance-gpu/,

2023.

[13] Nvidia multi-process service. https://docs.nvidi

a.com/deploy/mps/index.html, 2023.

[14] Nvlink and nvswitch. https://www.nvidia.com/e

n-us/data-center/nvlink/, 2023.

[15] Pytorch automatic mixed precision training. https:

//pytorch.org/docs/stable/amp, 2023.

[16] Pytorch examples. https://github.com/pytorch

/examples, 2023.

[17] Pytorch fullyshardeddataparallel. https://pytorch.

org/docs/stable/fsdp, 2023.

[18] Torchvision new training recipe. https://pytorc

h.org/blog/how-to-train-state-of-the-art-m

odels-using-torchvision-latest-primitives/,

2023.

[19] Martín Abadi, Paul Barham, Jianmin Chen, Zhifeng

Chen, Andy Davis, Jeffrey Dean, Matthieu Devin, San-

jay Ghemawat, Geoffrey Irving, Michael Isard, Man-

junath Kudlur, Josh Levenberg, Rajat Monga, Sherry

Moore, Derek G. Murray, Benoit Steiner, Paul Tucker,

Vijay Vasudevan, Pete Warden, Martin Wicke, Yuan

Yu, and Xiaoqiang Zheng. Tensorflow: A system for

large-scale machine learning. In 12th USENIX Sympo-

sium on Operating Systems Design and Implementa-

tion, OSDI ’16, 2016.

[20] Jimmy Lei Ba, Jamie Ryan Kiros, and Geoffrey E. Hin-

ton. Layer normalization. CoRR, 2016.

[21] Dzmitry Bahdanau, Kyunghyun Cho, and Yoshua Ben-

gio. Neural machine translation by jointly learning to

align and translate. In 3rd International Conference on

Learning Representations, ICLR ’15, 2015.

[22] James Bergstra and Yoshua Bengio. Random search

for hyper-parameter optimization. Journal of Machine

Learning Research, 2012.

[23] Sid Black, Stella Biderman, Eric Hallahan, Quentin

Anthony, Leo Gao, Laurence Golding, Horace He,

Connor Leahy, Kyle McDonell, Jason Phang, Michael

Pieler, USVSN Sai Prashanth, Shivanshu Purohit, Laria

Reynolds, Jonathan Tow, Ben Wang, and Samuel Wein-

bach. Gpt-neox-20b: An open-source autoregressive

language model. In Proceedings of the 60th Annual

Meeting of the Association for Computational Linguis-

tics — Workshop on Challenges & Perspectives in Cre-

ating Large Language Models, ACL-BigScience ’22,

2022.

[24] Tom Brown, Benjamin Mann, Nick Ryder, Melanie

Subbiah, Jared D Kaplan, Prafulla Dhariwal, Arvind

Neelakantan, Pranav Shyam, Girish Sastry, Amanda

Askell, Sandhini

Agarwal, Ariel

Herbert-Voss,

Gretchen Krueger, Tom Henighan, Rewon Child,

Aditya Ramesh, Daniel Ziegler, Jeffrey Wu, Clemens

Winter, Chris Hesse, Mark Chen, Eric Sigler, Mateusz

Litwin, Scott Gray, Benjamin Chess, Jack Clark,

Christopher Berner, Sam McCandlish, Alec Radford,

Ilya Sutskever, and Dario Amodei.

Language

models are few-shot learners. In Advances in Neural

Information Processing Systems, NeurIPS ’20, 2020.

[25] Lénaïc Chizat and Francis Bach. On the global con-

vergence of gradient descent for over-parameterized

models using optimal transport. In Advances in Neural

Information Processing Systems, NeurIPS ’18, 2018.

[26] Sangjin Choi, Inhoe Koo, Jeongseob Ahn, Myeongjae

Jeon, and Youngjin Kwon.

Envpipe: Performance-

preserving dnn training framework for saving en-

ergy. In 2023 USENIX Annual Technical Conference,

USENIX ATC ’23, 2023.

[27] Aakanksha Chowdhery, Sharan Narang, Jacob De-

vlin, Maarten Bosma, Gaurav Mishra, Adam Roberts,

Paul Barham, Hyung Won Chung, Charles Sutton, Se-

bastian Gehrmann, Parker Schuh, Kensen Shi, Sasha

Tsvyashchenko, Joshua Maynez, Abhishek Rao, Parker

Barnes, Yi Tay, Noam Shazeer, Vinodkumar Prab-

hakaran, Emily Reif, Nan Du, Ben Hutchinson, Reiner

Pope, James Bradbury, Jacob Austin, Michael Isard,

Guy Gur-Ari, Pengcheng Yin, Toju Duke, Anselm

Levskaya, Sanjay Ghemawat, Sunipa Dev, Henryk

Michalewski, Xavier Garcia, Vedant Misra, Kevin

Robinson, Liam Fedus, Denny Zhou, Daphne Ippolito,

David Luan, Hyeontaek Lim, Barret Zoph, Alexan-

der Spiridonov, Ryan Sepassi, David Dohan, Shivani

Agrawal, Mark Omernick, Andrew M. Dai, Thanu-

malayan Sankaranarayana Pillai, Marie Pellat, Aitor

Lewkowycz, Erica Moreira, Rewon Child, Oleksandr

Polozov, Katherine Lee, Zongwei Zhou, Xuezhi Wang,

Brennan Saeta, Mark Diaz, Orhan Firat, Michele

Catasta, Jason Wei, Kathy Meier-Hellstern, Douglas

Eck, Jeff Dean, Slav Petrov, and Noah Fiedel. Palm:

Scaling language modeling with pathways.

CoRR,

2022.

[28] Piali Das, Nikita Ivkin, Tanya Bansal, Laurence Roues-

nel, Philip Gautier, Zohar Karnin, Leo Dirac, Lakshmi

Ramakrishnan, Andre Perunicic, Iaroslav Shcherbatyi,

Wilton Wu, Aida Zolic, Huibin Shen, Amr Ahmed, Fela

Winkelmolen, Miroslav Miladinovic, Cedric Archem-

beau, Alex Tang, Bhaskar Dutt, Patricia Grao, and Ku-

mar Venkateswar. Amazon sagemaker autopilot: a

white box automl solution at scale. In Proceedings of

the Fourth International Workshop on Data Manage-

ment for End-to-End Machine Learning, DEEM ’20,

2020.

[29] Jia Deng, Wei Dong, Richard Socher, Li-Jia Li, Kai

Li, and Li Fei-Fei. Imagenet: A large-scale hierar-

chical image database. In 2009 IEEE Conference on

Computer Vision and Pattern Recognition, 2009.

[30] Jacob Devlin, Ming-Wei Chang, Kenton Lee, and

Kristina Toutanova. BERT: Pre-training of deep bidi-

rectional transformers for language understanding. In

Proceedings of the 2019 Conference of the North Amer-

ican Chapter of the Association for Computational

Linguistics, NAACL ’19, 2019.

[31] Tobias Domhan, Jost Tobias Springenberg, and Frank

Hutter. Speeding up automatic hyperparameter opti-

mization of deep neural networks by extrapolation of

learning curves. In Proceedings of the International

Joint Conference on Artificial Intelligence, IJCAI ’15,

2015.

[32] Lisa Dunlap, Kirthevasan Kandasamy, Ujval Misra,

Richard Liaw, Michael Jordan, Ion

Stoica, and

Joseph E. Gonzalez. Elastic hyperparameter tuning

on the cloud. In Proceedings of the ACM Symposium

on Cloud Computing, SoCC ’21, 2021.

[33] Stefan Falkner, Aaron Klein, and Frank Hutter. BOHB:

Robust and efficient hyperparameter optimization at

scale. In Proceedings of the 35th International Confer-

ence on Machine Learning, ICML ’18, 2018.

[34] Shiqing Fan, Yi Rong, Chen Meng, Zongyan Cao, Siyu

Wang, Zhen Zheng, Chuan Wu, Guoping Long, Jun

Yang, Lixue Xia, Lansong Diao, Xiaoyong Liu, and

Wei Lin. Dapple: a pipelined data parallel approach for

training large models. In Proceedings of the 26th ACM

SIGPLAN Symposium on Principles and Practice of

Parallel Programming, PPoPP ’21, 2021.

[35] Roy Frostig, Matthew James Johnson, and Chris Leary.

Compiling machine learning programs via high-level

tracing.

In Proceedings of Machine Learning and

Systems, MLSys ’18, 2018.

[36] Wei Gao, Qinghao Hu, Zhisheng Ye, Peng Sun, Xiaolin

Wang, Yingwei Luo, Tianwei Zhang, and Yonggang

Wen. Deep learning workload scheduling in gpu dat-

acenters: Taxonomy, challenges and vision. CoRR,

2022.

[37] Xavier Glorot and Yoshua Bengio. Understanding the

difficulty of training deep feedforward neural networks.

In Proceedings of the Thirteenth International Confer-

ence on Artificial Intelligence and Statistics, ICML ’10,

2010.

[38] Aaron Gokaslan and Vanya Cohen. Openwebtext cor-

pus. https://skylion007.github.io/OpenWebTe

xtCorpus/, 2023.

[39] Daniel Golovin, Benjamin Solnik, Subhodeep Moitra,

Greg Kochanski, John Karro, and D. Sculley. Google

vizier: A service for black-box optimization. In Pro-

ceedings of the 23rd ACM SIGKDD International Con-

ference on Knowledge Discovery and Data Mining,

KDD ’17, 2017.

[40] Juncheng Gu, Mosharaf Chowdhury, Kang G. Shin,

Yibo Zhu, Myeongjae Jeon, Junjie Qian, Hongqiang

Liu, and Chuanxiong Guo. Tiresias: A GPU cluster

manager for distributed deep learning. In 16th USENIX

Symposium on Networked Systems Design and Imple-

mentation, NSDI ’19, 2019.

[41] Kaiming He, Xiangyu Zhang, Shaoqing Ren, and Jian

Sun. Deep residual learning for image recognition.

In Proceedings of the IEEE Conference on Computer

Vision and Pattern Recognition, CVPR ’16, 2016.

[42] Tom Henighan, Jared Kaplan, Mor Katz, Mark Chen,

Christopher Hesse, Jacob Jackson, Heewoo Jun, Tom B.

Brown, Prafulla Dhariwal, Scott Gray, Chris Hallacy,

Benjamin Mann, Alec Radford, Aditya Ramesh, Nick

Ryder, Daniel M. Ziegler, John Schulman, Dario

Amodei, and Sam McCandlish. Scaling laws for au-

toregressive generative modeling. CoRR, 2020.

[43] Jordan Hoffmann, Sebastian Borgeaud, Arthur Men-

sch, Elena Buchatskaya, Trevor Cai, Eliza Rutherford,

Diego de las Casas, Lisa Anne Hendricks, Johannes

Welbl, Aidan Clark, Tom Hennigan, Eric Noland,

Katherine Millican, George van den Driessche, Bog-

dan Damoc, Aurelia Guy, Simon Osindero, Karen Si-

monyan, Erich Elsen, Oriol Vinyals, Jack William Rae,

and Laurent Sifre. An empirical analysis of compute-

optimal large language model training. In Advances in

Neural Information Processing Systems, NeurIPS ’22,

2022.

[44] Andrew Howard, Mark Sandler, Grace Chu, Liang-

Chieh Chen, Bo Chen, Mingxing Tan, Weijun Wang,

Yukun Zhu, Ruoming Pang, Vijay Vasudevan, Quoc V.

Le, and Hartwig Adam. Searching for mobilenetv3.

In Proceedings of the IEEE/CVF International Confer-

ence on Computer Vision, ICCV ’19, 2019.

[45] Qinghao Hu, Peng Sun, Shengen Yan, Yonggang Wen,

and Tianwei Zhang. Characterization and prediction of

deep learning workloads in large-scale gpu datacenters.

In Proceedings of the International Conference for

High Performance Computing, Networking, Storage

and Analysis, SC ’21, 2021.

[46] Qinghao Hu, Meng Zhang, Peng Sun, Yonggang Wen,

and Tianwei Zhang. Lucid: A non-intrusive, scalable

and interpretable scheduler for deep learning training

jobs. In Proceedings of the 28th International Confer-

ence on Architectural Support for Programming Lan-

guages and Operating Systems, ASPLOS ’23, 2023.

[47] Yimin Huang, Yujun Li, Hanrong Ye, Zhenguo Li, and

Zhihua Zhang. Improving model training with multi-

fidelity hyperparameter evaluation. In Proceedings of

Machine Learning and Systems, MLSys ’22, 2022.

[48] Sergey Ioffe and Christian Szegedy. Batch normaliza-

tion: accelerating deep network training by reducing

internal covariate shift. In Proceedings of the 32nd

International Conference on Machine Learning, ICML

’15, 2015.

[49] Arthur Jacot, Franck Gabriel, and Clement Hongler.

Neural tangent kernel: Convergence and generalization

in neural networks. In Advances in Neural Information

Processing Systems, NeurIPS ’18, 2018.

[50] Myeongjae Jeon, Shivaram Venkataraman, Amar Phan-

ishayee, Junjie Qian, Wencong Xiao, and Fan Yang.

Analysis of large-scale multi-tenant GPU clusters for

DNN training workloads. In 2019 USENIX Annual

Technical Conference, USENIX ATC ’19, 2019.

[51] Zhihao Jia, Oded Padon, James Thomas, Todd Warsza-

wski, Matei Zaharia, and Alex Aiken. Taso: optimizing

deep learning computation with automatic generation

of graph substitutions. In Proceedings of the 27th ACM

Symposium on Operating Systems Principles, SOSP

’19, 2019.

[52] Jared Kaplan, Sam McCandlish, Tom Henighan,

Tom B. Brown, Benjamin Chess, Rewon Child, Scott

Gray, Alec Radford, Jeffrey Wu, and Dario Amodei.

Scaling laws for neural language models. CoRR, 2020.

[53] Zohar Karnin, Tomer Koren, and Oren Somekh. Al-

most optimal exploration in multi-armed bandits. In

Proceedings of the 30th International Conference on

International Conference on Machine Learning, ICML

’13, 2013.

[54] Diederik P Kingma and Jimmy Ba. Adam: A method

for stochastic optimization. In International Confer-

ence on Learning Representations, ICLR ’15, 2015.

[55] Thomas N. Kipf and Max Welling. Semi-supervised

classification with graph convolutional networks. In

International Conference on Learning Representations,

ICLR ’17, 2017.

[56] Vijay Korthikanti, Jared Casper, Sangkug

Lym,

Lawrence McAfee, Michael Andersch, Mohammad

Shoeybi, and Bryan Catanzaro. Reducing activation

recomputation in large transformer models. CoRR,

2022.

[57] Alex Krizhevsky and Geoffrey Hinton. Learning mul-

tiple layers of features from tiny images. 2009.

[58] Alex Krizhevsky, Ilya Sutskever, and Geoffrey E. Hin-

ton. Imagenet classification with deep convolutional

neural networks. In Advances in Neural Information

Processing Systems, NeurIPS ’12, 2012.

[59] Sameer Kumar, Yu Wang, Cliff Young, James Brad-

bury, Naveen Kumar, Dehao Chen, and Andy Swing.

Exploring the limits of concurrency in ml training on

google tpus. In Proceedings of Machine Learning and

Systems, MLSys ’21, 2021.

[60] Fan Lai, Yinwei Dai, Harsha V. Madhyastha, and

Mosharaf Chowdhury. ModelKeeper: Accelerating

DNN training via automated training warmup. In 20th

USENIX Symposium on Networked Systems Design

and Implementation, NSDI ’23, 2023.

[61] Zhiquan Lai, Shengwei Li, Xudong Tang, Keshi Ge,

Weijie Liu, Yabo Duan, Linbo Qiao, and Dongsheng Li.

Merak: An efficient distributed dnn training framework

with automated 3d parallelism for giant foundation

models. CoRR, 2022.

[62] Yann LeCun, Léon Bottou, Yoshua Bengio, and Patrick

Haffner. Gradient-based learning applied to document

recognition. Proceedings of the IEEE, 1998.

[63] Liam Li, Kevin Jamieson, Afshin Rostamizadeh, Eka-

terina Gonina, Jonathan Ben-tzur, Moritz Hardt, Ben-

jamin Recht, and Ameet Talwalkar. A system for mas-

sively parallel hyperparameter tuning. In Proceedings

of Machine Learning and Systems, MLSys ’20, 2020.

[64] Lisha Li, Kevin Jamieson, Giulia DeSalvo, Afshin Ros-

tamizadeh, and Ameet Talwalkar. Hyperband: A novel

bandit-based approach to hyperparameter optimization.

Journal of Machine Learning Research, 2018.

[65] Shigang Li and Torsten Hoefler. Chimera: efficiently

training large-scale neural networks with bidirectional

pipelines. In Proceedings of the International Confer-

ence for High Performance Computing, Networking,

Storage and Analysis, SC ’21, 2021.

[66] Yang Li, Yu Shen, Huaijun Jiang, Wentao Zhang, Jix-

iang Li, Ji Liu, Ce Zhang, and Bin Cui. Hyper-tune:

towards efficient hyper-parameter tuning at scale. Pro-

ceedings of the VLDB Endowment, 2022.

[67] Yang Li, Yu Shen, Huaijun Jiang, Wentao Zhang, Zhi

Yang, Ce Zhang, and Bin Cui. Transbo: Hyperparam-

eter optimization via two-phase transfer learning. In

Proceedings of the 28th ACM SIGKDD Conference

on Knowledge Discovery and Data Mining, KDD ’22,

2022.

[68] Yang Li, Yu Shen, Jiawei

Jiang, Jinyang Gao,

Ce Zhang, and Bin Cui. Mfes-hb: Efficient hyperband

with multi-fidelity quality measurements. In Proceed-

ings of the AAAI Conference on Artificial Intelligence,

AAAI ’21, 2021.

[69] Yang Li, Yu Shen, Wentao Zhang, Yuanwei Chen, Huai-

jun Jiang, Mingchao Liu, Jiawei Jiang, Jinyang Gao,

Wentao Wu, Zhi Yang, Ce Zhang, and Bin Cui. Open-

box: A generalized black-box optimization service. In

Proceedings of the 27th ACM SIGKDD Conference

on Knowledge Discovery & Data Mining, KDD ’21,

2021.

[70] Yang Li, Yu Shen, Wentao Zhang, Jiawei Jiang, Bolin

Ding, Yaliang Li, Jingren Zhou, Zhi Yang, Wentao Wu,

Ce Zhang, and Bin Cui. Volcanoml: speeding up end-

to-end automl via scalable search space decomposition.

Proceedings of the VLDB Endowment, 2021.

[71] Richard Liaw, Romil Bhardwaj, Lisa Dunlap, Yitian

Zou, Joseph E. Gonzalez, Ion Stoica, and Alexey Tu-

manov. Hypersched: Dynamic resource reallocation

for model development on a deadline. In Proceedings

of the ACM Symposium on Cloud Computing, SoCC

’19, 2019.

[72] Richard Liaw, Eric Liang, Robert Nishihara, Philipp

Moritz, Joseph E. Gonzalez, and Ion Stoica. Tune: A

research platform for distributed model selection and

training. CoRR, 2018.

[73] Gangmuk Lim, Jeongseob Ahn, Wencong Xiao,

Youngjin Kwon, and Myeongjae Jeon. Zico: Efficient

GPU memory sharing for concurrent DNN training. In

2021 USENIX Annual Technical Conference, USENIX

ATC ’21, 2021.

[74] Yunfeng Lin, Guilin Li, Xing Zhang, Weinan Zhang,

Bo Chen, Ruiming Tang, Zhenguo Li, Jiashi Feng,

and Yong Yu. Modularnas: Towards modularized and

reusable neural architecture search. In Proceedings of

Machine Learning and Systems, MLSys ’21, 2021.

[75] Yinhan Liu, Myle Ott, Naman Goyal, Jingfei Du, Man-

dar Joshi, Danqi Chen, Omer Levy, Mike Lewis, Luke

Zettlemoyer, and Veselin Stoyanov. Roberta: A ro-

bustly optimized bert pretraining approach. CoRR,

2019.

[76] Ze Liu, Yutong Lin, Yue Cao, Han Hu, Yixuan Wei,

Zheng Zhang, Stephen Lin, and Baining Guo. Swin

transformer: Hierarchical vision transformer using

shifted windows. In Proceedings of the IEEE Inter-

national Conference on Computer Vision, ICCV ’21,

2021.

[77] Ilya Loshchilov and Frank Hutter. Decoupled weight

decay regularization. In International Conference on

Learning Representations, ICLR ’19, 2019.

[78] Kshiteej Mahajan, Arjun Balasubramanian, Arjun

Singhvi, Shivaram Venkataraman, Aditya Akella,

Amar Phanishayee, and Shuchi Chawla. Themis: Fair

and efficient GPU cluster scheduling. In 17th USENIX

Symposium on Networked Systems Design and Imple-

mentation, NSDI ’20, 2020.

[79] Ruben Martinez-Cantin. Bayesopt: A bayesian opti-

mization library for nonlinear optimization, experimen-

tal design and bandits. Journal of Machine Learning

Research, 2014.

[80] Song Mei, Andrea Montanari, and Phan-Minh Nguyen.

A mean field view of the landscape of two-layer neural

networks. Proceedings of the National Academy of

Sciences, 2018.

[81] Stephen Merity, Caiming Xiong, James Bradbury, and

Richard Socher. Pointer sentinel mixture models. In

International Conference on Learning Representations,

ICLR ’17, 2017.

[82] Ujval Misra, Richard Liaw, Lisa Dunlap, Romil Bhard-

waj, Kirthevasan Kandasamy, Joseph E. Gonzalez, Ion

Stoica, and Alexey Tumanov.

Rubberband: Cloud-

based hyperparameter tuning. In Proceedings of the

Sixteenth European Conference on Computer Systems,

EuroSys ’21, 2021.

[83] Jayashree

Mohan, Amar Phanishayee, Janardhan

Kulkarni, and Vijay Chidambaram. Looking beyond

GPUs for DNN scheduling on Multi-Tenant clusters.

In 16th USENIX Symposium on Operating Systems

Design and Implementation, OSDI ’22, 2022.

[84] Philipp Moritz, Robert Nishihara, Stephanie Wang,

Alexey Tumanov, Richard Liaw, Eric Liang, Melih Eli-

bol, Zongheng Yang, William Paul, Michael I. Jordan,

and Ion Stoica.

Ray: A distributed framework for

emerging AI applications. In 13th USENIX Sympo-

sium on Operating Systems Design and Implementa-

tion, OSDI ’18, 2018.

[85] Deepak Narayanan, Aaron Harlap, Amar Phanishayee,

Vivek Seshadri, Nikhil R. Devanur, Gregory R. Ganger,

Phillip B. Gibbons, and Matei Zaharia. Pipedream:

generalized pipeline parallelism for dnn training. In

Proceedings of the 27th ACM Symposium on Operating

Systems Principles, SOSP ’19, 2019.

[86] Deepak Narayanan, Amar Phanishayee, Kaiyu Shi, Xie

Chen, and Matei Zaharia. Memory-efficient pipeline-

parallel dnn training. In Proceedings of the 38th Inter-

national Conference on Machine Learning, ICML ’21,

2021.

[87] Deepak

Narayanan, Keshav

Santhanam, Fiodar

Kazhamiaka, Amar Phanishayee, and Matei Zaharia.

Heterogeneity-Aware Cluster Scheduling Policies

for Deep Learning Workloads.

In 14th USENIX

Symposium on Operating Systems Design and

Implementation, OSDI ’20, 2020.

[88] Deepak Narayanan, Mohammad Shoeybi, Jared Casper,

Patrick LeGresley, Mostofa Patwary, Vijay Korthikanti,

Dmitri Vainbrand, Prethvi Kashinkunti, Julie Bernauer,

Bryan Catanzaro, Amar Phanishayee, and Matei Za-

haria. Efficient large-scale language model training

on gpu clusters using megatron-lm. In Proceedings

of the International Conference for High Performance

Computing, Networking, Storage and Analysis, SC ’21,

2021.

[89] Radford M. Neal.

Priors for Infinite Networks.

Springer New York, 1996.

[90] Maria-Elena Nilsback and Andrew Zisserman. Au-

tomated flower classification over a large number of

classes. In Sixth Indian Conference on Computer Vi-

sion, Graphics & Image Processing, 2008.

[91] Adam Paszke, Sam Gross, Francisco Massa, Adam

Lerer, James Bradbury, Gregory Chanan, Trevor

Killeen, Zeming Lin, Natalia Gimelshein, Luca Antiga,

Alban Desmaison, Andreas Kopf, Edward Yang,

Zachary DeVito, Martin Raison, Alykhan Tejani,

Sasank Chilamkurthy, Benoit Steiner, Lu Fang, Jun-

jie Bai, and Soumith Chintala. Pytorch: An impera-

tive style, high-performance deep learning library. In

Advances in Neural Information Processing Systems,

NeurIPS ’19, 2019.

[92] Valerio Perrone, Huibin Shen, Aida Zolic, Iaroslav

Shcherbatyi, Amr Ahmed, Tanya Bansal, Michele

Donini, Fela

Winkelmolen, Rodolphe

Jenatton,

Jean Baptiste Faddoul, Barbara Pogorzelska, Miroslav

Miladinovic, Krishnaram

Kenthapadi, Matthias

Seeger, and Cédric Archambeau. Amazon sagemaker

automatic model tuning:

Scalable

gradient-free

optimization.

In Proceedings of the 27th ACM

SIGKDD Conference on Knowledge Discovery &

Data Mining, KDD ’21, 2021.

[93] Charles R. Qi, Hao Su, Kaichun Mo, and Leonidas J.

Guibas. Pointnet: Deep learning on point sets for 3d

classification and segmentation. In Proceedings of

the IEEE Conference on Computer Vision and Pattern

Recognition, CVPR ’17, 2017.

[94] Aurick Qiao, Sang Keun Choe, Suhas Jayaram Sub-

ramanya, Willie Neiswanger, Qirong Ho, Hao Zhang,

Gregory R. Ganger, and Eric P. Xing. Pollux: Co-

adaptive cluster scheduling for goodput-optimized

deep learning. In 15th USENIX Symposium on Op-

erating Systems Design and Implementation, OSDI

’21, 2021.

[95] Alec Radford, Jeff Wu, Rewon Child, David Luan,

Dario Amodei, and Ilya Sutskever. Language mod-

els are unsupervised multitask learners. 2019.

[96] Samyam Rajbhandari, Jeff Rasley, Olatunji Ruwase,

and Yuxiong He. Zero: Memory optimizations toward

training trillion parameter models. In Proceedings of

the International Conference for High Performance

Computing, Networking, Storage and Analysis, SC ’20,

2020.

[97] James Reed, Zachary DeVito, Horace He, Ansley

Ussery, and Jason Ansel. torch.fx: Practical program

capture and transformation for deep learning in python.

In Proceedings of Machine Learning and Systems, ML-

Sys ’22, 2022.

[98] Daniel A. Roberts, Sho Yaida, and Boris Hanin. The

Principles of Deep Learning Theory. Cambridge Uni-

versity Press, 2022.

[99] Sebastian Ruder. An overview of gradient descent

optimization algorithms. CoRR, 2017.

[100] David Salinas, Matthias Seeger, Aaron Klein, Vale-

rio Perrone, Martin Wistuba, and Cedric Archambeau.

Syne tune: A library for large scale hyperparameter

tuning and reproducible research. In First Conference

on Automated Machine Learning, AutoML ’22, 2022.

[101] Noam

Shazeer, *Azalia

Mirhoseini, *Krzysztof

Maziarz, Andy Davis, Quoc Le, Geoffrey Hinton, and

Jeff Dean. Outrageously large neural networks: The

sparsely-gated mixture-of-experts layer. In Interna-

tional Conference on Learning Representations, ICLR

’17, 2017.

[102] Mohammad Shoeybi, Mostofa Patwary, Raul Puri,

Patrick LeGresley, Jared Casper, and Bryan Catanzaro.

Megatron-lm: Training multi-billion parameter lan-

guage models using model parallelism. CoRR, 2020.

[103] Karen Simonyan and Andrew Zisserman. Very deep

convolutional networks for large-scale image recogni-

tion. In International Conference on Learning Repre-

sentations, ICLR ’15, 2015.

[104] Jasper Snoek, Hugo Larochelle, and Ryan P. Adams.

Practical bayesian optimization of machine learning

algorithms. In Proceedings of the 25th International

Conference on Neural Information Processing Systems,

NeurIPS ’12, 2012.

[105] Xingyou Song, Sagi Perel, Chansoo Lee, Greg Kochan-

ski, and Daniel Golovin.

Open source vizier: Dis-

tributed infrastructure and api for reliable and flexible

blackbox optimization. In First Conference on Auto-

mated Machine Learning, AutoML ’22, 2022.

[106] John Thorpe, Pengzhan Zhao, Jonathan Eyolfson, Yi-

fan Qiao, Zhihao Jia, Minjia Zhang, Ravi Netravali,

and Guoqing Harry Xu. Bamboo: Making preemptible

instances resilient for affordable training of large dnns.

In 20th USENIX Symposium on Networked Systems

Design and Implementation, NSDI ’23, 2023.

[107] Colin Unger, Zhihao Jia, Wei Wu, Sina Lin, Mandeep

Baines, Carlos Efrain Quintero Narvaez, Vinay Ra-

makrishnaiah, Nirmal Prajapati, Pat McCormick, Ja-

maludin Mohd-Yusof, Xi Luo, Dheevatsa Mudigere,

Jongsoo Park, Misha Smelyanskiy, and Alex Aiken.

Unity: Accelerating DNN training through joint opti-

mization of algebraic transformations and paralleliza-

tion. In 16th USENIX Symposium on Operating Sys-

tems Design and Implementation, OSDI ’22, 2022.

[108] Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob

Uszkoreit, Llion Jones, Aidan N Gomez, Ł ukasz

Kaiser, and Illia Polosukhin. Attention is all you need.

In Advances in Neural Information Processing Systems,

NeurIPS ’17, 2017.

[109] Guanhua Wang, Kehan Wang, Kenan Jiang, XI-

ANGJUN LI, and Ion Stoica. Wavelet: Efficient dnn

training with tick-tock scheduling. In Proceedings of

Machine Learning and Systems, MLSys ’21, 2021.

[110] Shang Wang, Peiming Yang, Yuxuan Zheng, Xin Li,

and Gennady Pekhimenko. Horizontally fused training

array: An effective hardware utilization squeezer for

training novel deep learning models. In Proceedings

of Machine Learning and Systems, MLSys ’21, 2021.

[111] Qizhen Weng, Wencong Xiao, Yinghao Yu, Wei Wang,

Cheng Wang, Jian He, Yong Li, Liping Zhang, Wei Lin,

and Yu Ding. MLaaS in the wild: Workload analysis

and scheduling in Large-Scale heterogeneous GPU

clusters. In 19th USENIX Symposium on Networked

Systems Design and Implementation, NSDI ’22, 2022.

[112] William F. Whitney. Parallelizing neural networks on

one gpu with jax, 2023.

[113] Thomas Wolf, Lysandre Debut, Victor Sanh, Julien

Chaumond, Clement Delangue, Anthony Moi, Pierric

Cistac, Tim Rault, Rémi Louf, Morgan Funtowicz, Joe

Davison, Sam Shleifer, Patrick von Platen, Clara Ma,

Yacine Jernite, Julien Plu, Canwen Xu, Teven Le Scao,

Sylvain Gugger, Mariama Drame, Quentin Lhoest, and

Alexander M. Rush. Transformers: State-of-the-art nat-

ural language processing. In Proceedings of the 2020

Conference on Empirical Methods in Natural Lan-

guage Processing: System Demonstrations, EMNLP

’20, 2020.

[114] Wencong Xiao, Romil Bhardwaj, Ramachandran Ram-

jee, Muthian Sivathanu, Nipun Kwatra, Zhenhua Han,

Pratyush Patel, Xuan Peng, Hanyu Zhao, Quanlu

Zhang, Fan Yang, and Lidong Zhou. Gandiva: Intro-

spective cluster scheduling for deep learning. In 13th

USENIX Symposium on Operating Systems Design and

Implementation, OSDI ’18, 2018.

[115] Wencong Xiao, Shiru Ren, Yong Li, Yang Zhang,

Pengyang Hou, Zhi Li, Yihui Feng, Wei Lin, and

Yangqing Jia. Antman: Dynamic scaling on GPU clus-

ters for deep learning. In 14th USENIX Symposium on

Operating Systems Design and Implementation, OSDI

’20, 2020.

[116] Sho Yaida. Meta-principled family of hyperparameter

scaling strategies. CoRR, 2022.

[117] Ge Yang, Edward Hu, Igor Babuschkin, Szymon Sidor,

Xiaodong Liu, David Farhi, Nick Ryder, Jakub Pa-

chocki, Weizhu Chen, and Jianfeng Gao. Tuning large

neural networks via zero-shot hyperparameter trans-

fer. In Advances in Neural Information Processing

Systems, NeurIPS ’21, 2021.

[118] Greg Yang. Wide feedforward or recurrent neural net-

works of any architecture are gaussian processes. In

Advances in Neural Information Processing Systems,

NeurIPS ’19, 2019.

[119] Greg Yang. Tensor programs ii: Neural tangent kernel

for any architecture. CoRR, 2020.

[120] Greg Yang. Tensor programs iii: Neural matrix laws.

CoRR, 2021.

[121] Greg Yang and Edward J. Hu. Tensor programs iv:

Feature learning in infinite-width neural networks. In

Proceedings of the 38th International Conference on

Machine Learning, ICML ’21, 2021.

[122] Greg Yang and Etai Littwin. Tensor programs iib: Ar-

chitectural universality of neural tangent kernel train-

ing dynamics. In Proceedings of the 38th International

Conference on Machine Learning, ICML ’21, 2021.

[123] Zhisheng Ye, Peng Sun, Wei Gao, Tianwei Zhang, Xi-

aolin Wang, Shengen Yan, and Yingwei Luo. Astraea:

A fair deep learning scheduler for multi-tenant gpu clus-

ters. IEEE Transactions on Parallel and Distributed

Systems, 2021.

[124] Peifeng Yu and Mosharaf Chowdhury. Fine-grained

gpu sharing primitives for deep learning applications.

In Proceedings of Machine Learning and Systems, ML-

Sys ’20, 2020.

[125] Peifeng Yu, Jiachen Liu, and Mosharaf Chowdhury.

Fluid: Resource-aware hyperparameter tuning engine.

In Proceedings of Machine Learning and Systems, ML-

Sys ’21, 2021.

[126] Sergey Zagoruyko and Nikos Komodakis. Wide resid-

ual networks. In British Machine Vision Conference,

BMVC ’16, 2016.

[127] Quanlu Zhang, Zhenhua Han, Fan Yang, Yuge Zhang,

Zhe Liu, Mao Yang, and Lidong Zhou. Retiarii: A deep

learning Exploratory-Training framework.

In 14th

USENIX Symposium on Operating Systems Design

and Implementation, OSDI ’20, 2020.

[128] Yihao Zhao, Yuanqiang Liu, Yanghua Peng, Yibo Zhu,

Xuanzhe Liu, and Xin Jin. Multi-resource interleaving

for deep learning training. In Proceedings of the An-

nual Conference of the ACM Special Interest Group on

Data Communication, SIGCOMM ’22, 2022.

[129] Lianmin Zheng, Chengfan Jia, Minmin Sun, Zhao Wu,

Cody Hao Yu, Ameer Haj-Ali, Yida Wang, Jun Yang,

Danyang Zhuo, Koushik Sen, Joseph E. Gonzalez, and

Ion Stoica. Ansor: Generating high-performance ten-

sor programs for deep learning. In 14th USENIX Sym-

posium on Operating Systems Design and Implementa-

tion, OSDI ’20, 2020.

[130] Lianmin Zheng, Zhuohan Li, Hao Zhang, Yonghao

Zhuang, Zhifeng Chen, Yanping Huang, Yida Wang,

Yuanzhong Xu, Danyang Zhuo, Eric P. Xing, Joseph E.

Gonzalez, and Ion Stoica. Alpa: Automating inter- and

Intra-Operator parallelism for distributed deep learning.

In 16th USENIX Symposium on Operating Systems

Design and Implementation, OSDI ’22, 2022.