Frenzy: A Memory-Aware Serverless LLM Training System for Heterogeneous GPU Clusters

Dong Li; Sheng Xiao; Shuibing He; Siling Yang; Zhe Pan; Zihan Chang

REVIEW 4 major objections 6 minor 25 references

Frenzy: A Memory-Aware Serverless LLM Training System for Heterogeneous GPU Clusters

T0 review · 4 major / 6 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Frenzy predicts GPU memory from model hyperparameters and schedules jobs on heterogeneous clusters, so users can submit LLM training without specifying GPU types or counts.

desk verdict Frenzy's idea is sensible, but the undefined resource-plan priority ordering makes the headline JCT gains unfalsifiable until it is specified. read the letter →

arxiv 2412.14479 v1 pith:AAK2G5I6 submitted 2024-12-19 cs.DC

Zihan Chang , Sheng Xiao , Shuibing He , Siling Yang , Zhe Pan , Dong Li This is my paper · ORCID

classification cs.DC

keywords serverlesscomputingheterogeneousGPUclustersLLMtrainingmemorypredictionresourceschedulingdataparallelismtensorjobcompletiontime

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Frenzy claims that LLM training on a heterogeneous GPU cluster can be made serverless: the user submits a model and training configuration, and the system decides how many GPUs of which type to allocate. The feasibility rests on a closed-form estimate of peak GPU memory, which lets the system enumerate feasible combinations of data and tensor parallelism. The paper reports that this memory predictor is 92-98% accurate, that the scheduler overhead is about ten times lower than an existing scheduling method, and that average job completion time drops by 12-18% on real cluster workload traces.

What carries the argument

The memory-aware resource predictor (MARP) is the load-bearing component. It uses the weight formula $W = Vh + l(12h^2+13h)$, static memory $20W/t$, and activation memory $sBhl(10/d + 24/(dt) + 5as/(dht))$ to estimate peak GPU memory as a function of model shape, batch size, data parallelism $d$, and tensor parallelism $t$. The constraint $20W/t + sBhl(10/d + 24/(dt) + 5as/(dht)) < C$, with $C$ the GPU memory capacity, turns memory feasibility into a search over $(d,t)$ pairs. The heterogeneity-aware scheduler (HAS) then chooses among the ranked plans using best-fit node packing, preferring the fewest nodes with the tightest-fit GPUs.

What would settle it

Train a large decoder-only transformer with pipeline parallelism enabled on a heterogeneous cluster, measure the actual peak GPU memory, and compare it to the formula's prediction. If the measured peak exceeds the prediction by more than the claimed error margin, or if training aborts with out-of-memory, the central memory-prediction claim is falsified.

Watch

Extended reading notes

Core claim

Frenzy's central claim is that peak GPU memory during LLM training can be decomposed into a static part (model weights plus Adam optimizer states in mixed precision, $20W/t$ under tensor parallelism $t$) and a dynamic part (activations, $sBhl(10/d + 24/(dt) + 5as/(dht))$ with data parallelism $d$), where the weight count is $W = Vh + l(12h^2 + 13h)$. Requiring the sum to be below a GPU's memory capacity yields feasible combinations of data and tensor parallelism, hence the number and type of GPUs needed. The paper then claims that scheduling these plans with a best-fit node-packing strategy that prefers single-node placements reduces average job completion time compared with existing heterogeneity-aware schedulers, because the resource plans match actual memory use and the scheduler keeps communication within nodes.

Load-bearing premise

The memory formula assumes only data and tensor parallelism and omits pipeline parallelism, communication buffers, memory fragmentation, and framework overhead; if these are substantial for a given model, the predicted GPU counts and types will be wrong and the job-completion-time gains will not hold.

Editorial extensions

If this is right

A developer can submit a model without specifying GPU types or counts; Frenzy derives the hardware plan from the model's shape, batch size, and the cluster's available memory.
The prioritized list of resource plans lets the scheduler pick the most training-efficient plan that the current cluster can satisfy, avoiding out-of-memory failures and over-provisioning.
Because HAS uses best-fit node packing instead of solving an integer linear program, scheduling overhead stays low even as the number of concurrent tasks grows.
On the evaluated workloads, average job completion time falls by 12-18% compared to existing heterogeneity-aware scheduling, and per-job throughput rises by roughly 27-29%.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The same memory-estimation inequality could be extended to include pipeline parallelism, which the paper deliberately excludes; adding a term for layer-partitioned parameters would let the predictor handle the very largest models.
The closed-form weight formula assumes a standard decoder-only transformer; testing on mixture-of-experts or encoder-decoder architectures would show whether the 92-98% accuracy claim generalizes beyond the tested transformer family.
Resource plans that map model configuration directly to GPU type and count could also drive cost-aware or energy-aware placement, since each plan implies a specific hardware mix and runtime.
The tenfold scheduling-overhead reduction is demonstrated against one specific prior method; comparing against simpler heuristics like first-fit would isolate how much of the gain comes from the prioritized plan list versus the bin-packing itself.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Frenzy does something real: it lets a user submit an LLM training job without specifying GPU types or counts, predicts peak memory with standard closed-form estimates, and schedules with a fast best-fit heuristic. The serverless framing is not new, but the packaging for heterogeneous clusters is a legitimate contribution. Credit where due: MARP uses published formulas (20W/t and the activation expression) rather than fitting to the experiments, and the 92–98% accuracy on two real models is evidence those formulas work for those configurations. The scheduling overhead reduction is believable because bin packing is cheap compared to Sia's ILP.

The soft spots are real and one is load-bearing. The priority ranking across MARP's resource plans is never defined. Section IV-A says MARP 'adopts a priority ranking' and Fig. 1 says plans come out 'with priorities,' but no objective, formula, or algorithm is given. HAS then returns the first satisfiable plan. The text says the plans at the forefront indicate higher training efficiency, but the mapping is absent. That ordering determines the resource choice, and the resource choice determines the JCT. So the claimed 12–18% improvement over Sia could be an artifact of a hidden ranking rather than a property of HAS. That unfalsifiability is not minor. The evaluation also has no error bars, no released code or traces, and no control for total GPU resources consumed, so over-provisioning could explain the gains. Memory prediction is validated on only two GPT-2 variants, and the paper honestly limits the model to data and tensor parallelism, leaving out pipeline parallelism, fragmentation, and framework overhead. These are addressable, but they need real work.

Who is this for: systems researchers working on GPU cluster scheduling and serverless ML platforms. It deserves a serious referee, not a desk reject: the design is plausible, the Sia comparison is the right target, and the gaps are fixable. My recommendation: send to review, and require the authors to specify the ranking, release code and traces, and rerun with error bars and a resource-equivalent baseline.

Referee Report

4 major / 6 minor

Summary. The paper proposes Frenzy, a serverless-style scheduling system for LLM training on heterogeneous GPU clusters. Frenzy consists of MARP, which predicts peak GPU memory usage from closed-form formulas for model states and activations under data and tensor parallelism and generates candidate resource-allocation plans, and HAS, which selects the first satisfiable plan and allocates GPUs using a best-fit/greedy node-placement strategy. The evaluation uses a small real cluster and the PAI simulator with Philly and Helio traces, comparing against Sia and opportunistic scheduling. The paper claims 92-98% memory prediction accuracy, a 10x reduction in scheduling overhead, and 12-18% average job completion time (JCT) reduction.

Significance. If the claims hold, the paper addresses a real usability problem: automating the choice of GPU types and counts for LLM training on heterogeneous clusters. The memory formulas are taken from prior published work and are validated against measured peak memory rather than fitted, which is a strength. The use of real workload traces (Philly, Helio) and comparison to Sia are also appropriate. However, the central JCT and scheduling claims currently rest on an undefined plan-ranking rule, an uncontrolled comparison that does not account for total GPU resources consumed, and simulation results without released code or error bars. These issues must be resolved before the contribution can be assessed reliably.

major comments (4)

[Section IV-A and Algorithm 1] The priority ranking that orders MARP's resource plans is never specified. Section IV-A states that MARP 'adopts a priority ranking' and Figure 1 refers to plans 'with priorities', but no objective function, formula, or algorithm for this ranking is given anywhere in the paper. HAS (Algorithm 1) simply returns the first plan in this undefined order, so the 'optimal' plan that drives the JCT results depends entirely on a hidden decision rule. The authors must define the ranking (e.g., minimize estimated training time, maximize predicted throughput, or minimize GPU-hours) and evaluate its sensitivity, because otherwise the 12-18% JCT improvement cannot be attributed to the described design.
[Section V-B, Figures 4 and 5] The JCT comparison to Sia and opportunistic scheduling does not control for the total amount of GPU resources consumed. Since MARP determines both the type and the number of GPUs, Frenzy may achieve lower JCT simply by allocating more or larger GPUs than the Sia baseline, which is given user-specified GPU counts. The paper reports no GPU-hours, utilization, or resource-normalized throughput. Without such a control, the claimed 12-18% JCT reduction is not evidence of scheduling efficiency. The authors should report total resource consumption, per-job GPU-hours, or an equivalent-resource comparison, and should add error bars or confidence intervals, since no variance or significance information is reported.
[Section IV-A and Section V-C] The memory predictor is validated only on GPT2-350M and GPT2-7B with a limited set of parallelism configurations, yet MARP's output drives all downstream claims. The formula in Section IV-A deliberately considers only data and tensor parallelism and omits pipeline parallelism, activation recomputation, communication buffers, memory fragmentation, and framework-specific overhead. The paper should either demonstrate that the formula generalizes to larger models and other parallelism configurations (e.g., GPT-3-scale or models with pipeline parallelism), or state explicitly the configurations for which the resource plans are guaranteed to be safe. As written, an OOM or under-allocation outside the tested range would invalidate the serverless guarantee.
[Algorithm 1, lines 14-34] The HAS pseudocode appears buggy. Line 14 computes fitSz as the minimum GPU size satisfying reqSz, but line 15 filters nodes with 'gpu.size > fitSz', excluding nodes whose size is exactly fitSz, which contradicts the best-fit text. If no node has size strictly greater than fitSz but some have size equal to fitSz, N_Lst can be empty and the while loop cannot make progress. The pseudocode also lacks a termination condition for the case where no feasible node exists. The authors should correct the inequality, add an explicit tie-breaking rule, and prove or argue that the allocation loop always terminates on a satisfiable plan.

minor comments (6)

[Section IV-B] In the example, J ob(2, 32) is described as requiring 'at least 36GB of memory'; the numbers 32 and 36 are inconsistent and should be aligned.
[Figure 5(a)] The scheduling-overhead figure lacks labeled axes and numerical units, and the 10x claim is not supported by any reported numeric overhead values in the text.
[Section V-C] The 'memory prediction accuracy' metric is never defined. Please specify whether it is (predicted - measured)/measured, a ratio, or a percentage error, and report per-configuration values.
[Section V-B] The workload name is written inconsistently as both 'Helio' and 'Helios'; the same name should be used throughout.
[Reference [23]] The baseline called 'Opportunistic Scheduling' is cited to Lyra, but the description in Section V-A sounds like a generic FCFS policy; please clarify the relationship or cite the original opportunistic scheduling work.
[Algorithm 1] There are typographical errors in the pseudocode identifiers (e.g., 'J obRespourceP lans', 'singleN odeM eetRequirement'), which should be corrected for readability.

Circularity Check

0 steps flagged · score 0.0 of 10

No material circularity: the memory formulas are adopted from external published work and validated against measured peak memory, and the scheduling claims rest on standard benchmark comparisons rather than on a self-referential derivation.

full rationale

Frenzy's central derivation chain is the MARP memory predictor followed by the HAS scheduler. The memory predictor is not circular: the static memory formula (20W/t) is attributed to prior Megatron/DeepSpeed work [24], and the activation formula is attributed to Korthikanti et al. [19]; both are external sources, not the authors' own prior results. The parameter-count approximation W = Vh + l(12h^2 + 13h) is stated as a profiling-based approximation rather than fitted to the experiments reported in Section V. The paper then validates the combined formula against measured peak memory on GPT2-7B and GPT2-350M and reports 92%-98% accuracy; this is a genuine out-of-sample comparison of a stated analytical model to observed values, not a fitted parameter renamed as a prediction. The resource plan generation follows a feasibility inequality, 20W/t + sBhl(10/d + 24/(dt) + 5as/(dht)) < GPU capacity, with N = d*t, which is an application of the external memory model and does not define its output in terms of the claimed result. The HAS scheduling design is a best-fit/greedy allocation algorithm and is compared against Sia and opportunistic scheduling on the Philly and Helio traces; this is a standard performance evaluation. One notable gap is that the priority ordering of MARP's resource plans is never specified, which makes the claim that HAS selects the 'optimal' plan under-specified, but that is a completeness or attribution concern rather than a circularity: no equation or defined value is reused as its own conclusion. There is no load-bearing self-citation chain, no imported uniqueness theorem, and no ansatz smuggled in from the authors' own prior work. Thus, while the paper has reproducibility weaknesses, none of its central predictions reduce by construction to their inputs, so the circularity score is 0.

Assumptions & free parameters 0 free parameters · 5 assumptions · 0 invented entities

The paper introduces no fitted free parameters; all constants come from cited literature. The key assumptions are the memory formulas and the presumption that only data and tensor parallelism matter. No new physical or conceptual entities are proposed.

assumptions (5)

domain assumption LLM architecture follows a standard transformer with weight count W = Vh + l(12h^2 + 13h).
Assumes decoder-only transformer with standard self-attention and MLP shapes; invoked in Section IV-A to derive static memory.
domain assumption Static memory for mixed-precision training with Adam is exactly 20W.
Taken from Megatron-Deepspeed literature [24]; assumes no offloading and no optimizer-state compression.
domain assumption Activation memory is given by the formula s b h l (10 + 24/t + 5 a s / (h t)).
Copied from Korthikanti et al. [19]; assumes specific activation recomputation settings and tensor-parallel distribution that may not hold for all frameworks.
domain assumption Data parallelism equally splits the global batch into micro batches b = B/d.
Assumed in Section IV-A to compute per-GPU dynamic memory; ignores non-uniform data sharding.
domain assumption Peak GPU memory equals the sum of static and dynamic memory, with no extra allowance for communication buffers, fragmentation, or pipeline-parallel states.
This is the core simplification behind MARP's inequality; if false, the resource plans may be infeasible.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Frenzy: A Memory-Aware Serverless LLM Training System for Heterogeneous GPU Clusters." pith.science (2026). https://pith.science/paper/AAK2G5I6

@misc{pith2026241214479,
  author       = {Pith},
  title        = {Pith review of: Frenzy: A Memory-Aware Serverless LLM Training System for Heterogeneous GPU Clusters},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/AAK2G5I6}},
  note         = {Machine review of arXiv:2412.14479}
}

read the original abstract

Existing work only effective on a given number of GPUs, often neglecting the complexities involved in manually determining the specific types and quantities of GPUs needed, which can be a significant burden for developers. To address this issue, we propose Frenzy, a memory-aware serverless computing method for heterogeneous GPU clusters. Frenzy allows users to submit models without worrying about underlying hardware resources. First, Frenzy predicts the required number and type of GPUs by estimating the GPU memory usage of the LLM. Then, it employs a low-overhead heterogeneity-aware scheduling method to optimize training efficiency. We validated Frenzy's performance by conducting multi-task LLM training tests on a heterogeneous GPU cluster with three different GPU types. The results show that Frenzy's memory usage prediction accuracy exceeds 92\%, the scheduling overhead is reduced by 10 times, and it reduces the average job completion time by 12\% to 18\% compared to state-of-the-art methods.

Figures

Figures reproduced from arXiv: 2412.14479 by the authors.

**Figure 2.** MARP. For a training job, MARP calculates the GPU memory that will be occupied by Model States and Activations during training, based on the model and training config, under different numbers of data parallelism and tensor parallelism. MARP adopts a priority ranking for the requirements training resources plans obtained from different parallel schemes. LLM, especially decoder-only models, have reached a high level o… view at source ↗

**Figure 5.** Frenzy scheduling result compared with Sia [PITH_FULL_IMAGE:figures/full_fig_p006_5.png] view at source ↗

Figures from the paper (1 more)

**Figure 6.** Figure 6: Frenzy memory prediction compared with reality [PITH_FULL_IMAGE:figures/full_fig_p006_6.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

25 extracted references · 19 canonical work pages

[1]

Alpa: Automating inter-and Intra-Operator par- allelism for distributed deep learning

Zheng, Lianmin, et al.“Alpa: Automating inter-and Intra-Operator par- allelism for distributed deep learning.” 16th USENIX Symposium on Operating Systems Design and Implementation (OSDI 22). 2022

work page 2022
[2]

Pollux: Co-adaptive cluster scheduling for goodput- optimized deep learning

Qiao, Aurick, et al. “Pollux: Co-adaptive cluster scheduling for goodput- optimized deep learning.” 15th USENIX Symposium on Operating Systems Design and Implementation (OSDI 21). 2021

work page 2021
[3]

Gandiva: Introspective cluster scheduling for deep learning

Xiao, Wencong, et al. “Gandiva: Introspective cluster scheduling for deep learning.” 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI 18). 2018

work page 2018
[4]

MLaaS in the wild: Workload analysis and scheduling in Large-Scale heterogeneous GPU clusters

Weng, Qizhen, et al. “MLaaS in the wild: Workload analysis and scheduling in Large-Scale heterogeneous GPU clusters.” 19th USENIX Symposium on Networked Systems Design and Implementation (NSDI 22). 2022

work page 2022
[5]

Analysis of Large-ScaleMulti-TenantGPU clus- ters for DNN training workloads

Jeon, Myeongjae, et al. “Analysis of Large-ScaleMulti-TenantGPU clus- ters for DNN training workloads.” 2019 USENIX Annual Technical Conference (USENIX ATC 19). 2019

work page 2019
[6]

Heterogeneity-Aware cluster scheduling policies for deep learning workloads

Narayanan, Deepak, et al. “Heterogeneity-Aware cluster scheduling policies for deep learning workloads.” 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20). 2020

work page 2020
[7]

Metis: Fast Automatic Distributed Training on Heterogeneous GPUs

Um, Taegeon, et al. “Metis: Fast Automatic Distributed Training on Heterogeneous GPUs.” 2024 USENIX Annual Technical Conference (USENIX ATC 24). 2024

work page 2024
[8]

Sia: Heterogeneity-aware, goodput- optimized ML-cluster scheduling

Jayaram Subramanya, Suhas, et al. “Sia: Heterogeneity-aware, goodput- optimized ML-cluster scheduling.” Proceedings of the 29th Symposium on Operating Systems Principles. 2023

work page 2023

Show all 25 references

[9]

ElasticFlow: An elastic serverless training platform for distributed deep learning

Gu, Diandian, et al. “ElasticFlow: An elastic serverless training platform for distributed deep learning.” Proceedings of the 28th ACM Interna- tional Conference on Architectural Support for Programming Languages and Operating Systems, V olume 2. 2023

2023
[10]

Gpt-4 technical report

Achiam, Josh, et al. “Gpt-4 technical report.” arXiv preprint arXiv:2303.08774 (2023)

2023 arXiv
[11]

SeamlessM4T-Massively Multilingual & Multi- modal Machine Translation

Barrault, Lo ¨ıc, et al. “SeamlessM4T-Massively Multilingual & Multi- modal Machine Translation.” arXiv preprint arXiv:2308.11596 (2023)

2023 arXiv
[12]

NVIDIA A100 Tensor Core GPU

NVIDIA. NVIDIA A100 Tensor Core GPU. https://www.nvidia.com/en- us/data-center/a100
[13]

NVIDIA GeForce RTX 3090

NVIDIA. NVIDIA GeForce RTX 3090 . https://www.nvidia.com/en- us/geforce/graphics-cards/30-series/rtx-3090-3090ti
[14]

Zero: Memory optimizations toward training trillion parameter models

Rajbhandari, Samyam, et al. “Zero: Memory optimizations toward training trillion parameter models.” SC20: International Conference for High Performance Computing, Networking, Storage and Analysis. IEEE, 2020

2020
[15]

Megatron-lm: Training multi-billion pa- rameter language models using model parallelism

Shoeybi, Mohammad, et al. “Megatron-lm: Training multi-billion pa- rameter language models using model parallelism.” arXiv preprint arXiv:1909.08053 (2019)

2019 arXiv
[16]

Mixed precision training

Micikevicius, Paulius, et al. “Mixed precision training.” arXiv preprint arXiv:1710.03740 (2017)

2017 arXiv
[17]

Adam: A method for stochastic optimization

Kingma, Diederik P. “Adam: A method for stochastic optimization.” arXiv preprint arXiv:1412.6980 (2014)

2014 arXiv
[18]

Large-scale machine learning with stochastic gradient de- scent

Bottou, L ´eon. “Large-scale machine learning with stochastic gradient de- scent.” Proceedings of COMPSTAT’2010: 19th International Conference on Computational StatisticsParis France, August 22-27, 2010 Keynote, Invited and Contributed Papers. Physica-Verlag HD, 2010

2010
[19]

Reducing activation recomputation in large transformer models

Korthikanti, Vijay Anand, et al. “Reducing activation recomputation in large transformer models.” Proceedings of Machine Learning and Systems 5 (2023): 341-353

2023
[20]

Characterization and prediction of deep learning workloads in large-scale gpu datacenters

Hu, Qinghao, et al. “Characterization and prediction of deep learning workloads in large-scale gpu datacenters.” Proceedings of the Inter- national Conference for High Performance Computing, Networking, Storage and Analysis. 2021

2021
[21]

Language models are unsupervised multitask learners

Radford, Alec, et al. “Language models are unsupervised multitask learners.” OpenAI blog 1.8 (2019): 9

2019
[22]

Bert: Pre-training of deep bidirectional transformers for language understanding

Kenton, Jacob Devlin Ming-Wei Chang, and Lee Kristina Toutanova. “Bert: Pre-training of deep bidirectional transformers for language understanding.” Proceedings of naacL-HLT. V ol. 1. 2019

2019
[23]

Lyra: Elastic scheduling for deep learning clusters[C]//Proceedings of the Eighteenth European Conference on Computer Systems

Li J, Xu H, Zhu Y , et al. Lyra: Elastic scheduling for deep learning clusters[C]//Proceedings of the Eighteenth European Conference on Computer Systems. 2023: 835-850

2023
[24]

Using deepspeed and megatron to train megatron-turing nlg 530b, a large-scale generative language model[J]

Smith S, Patwary M, Norick B, et al. Using deepspeed and megatron to train megatron-turing nlg 530b, a large-scale generative language model[J]. arXiv preprint arXiv:2201.11990, 2022

2022 arXiv
[25]

Alibaba clusterdata

Alibaba. Alibaba clusterdata. https://github.com/alibaba/clusterdata

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.

[1] [1]

Alpa: Automating inter-and Intra-Operator par- allelism for distributed deep learning

Zheng, Lianmin, et al.“Alpa: Automating inter-and Intra-Operator par- allelism for distributed deep learning.” 16th USENIX Symposium on Operating Systems Design and Implementation (OSDI 22). 2022

work page 2022

[2] [2]

Pollux: Co-adaptive cluster scheduling for goodput- optimized deep learning

Qiao, Aurick, et al. “Pollux: Co-adaptive cluster scheduling for goodput- optimized deep learning.” 15th USENIX Symposium on Operating Systems Design and Implementation (OSDI 21). 2021

work page 2021

[3] [3]

Gandiva: Introspective cluster scheduling for deep learning

Xiao, Wencong, et al. “Gandiva: Introspective cluster scheduling for deep learning.” 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI 18). 2018

work page 2018

[4] [4]

MLaaS in the wild: Workload analysis and scheduling in Large-Scale heterogeneous GPU clusters

Weng, Qizhen, et al. “MLaaS in the wild: Workload analysis and scheduling in Large-Scale heterogeneous GPU clusters.” 19th USENIX Symposium on Networked Systems Design and Implementation (NSDI 22). 2022

work page 2022

[5] [5]

Analysis of Large-ScaleMulti-TenantGPU clus- ters for DNN training workloads

Jeon, Myeongjae, et al. “Analysis of Large-ScaleMulti-TenantGPU clus- ters for DNN training workloads.” 2019 USENIX Annual Technical Conference (USENIX ATC 19). 2019

work page 2019

[6] [6]

Heterogeneity-Aware cluster scheduling policies for deep learning workloads

Narayanan, Deepak, et al. “Heterogeneity-Aware cluster scheduling policies for deep learning workloads.” 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20). 2020

work page 2020

[7] [7]

Metis: Fast Automatic Distributed Training on Heterogeneous GPUs

Um, Taegeon, et al. “Metis: Fast Automatic Distributed Training on Heterogeneous GPUs.” 2024 USENIX Annual Technical Conference (USENIX ATC 24). 2024

work page 2024

[8] [8]

Sia: Heterogeneity-aware, goodput- optimized ML-cluster scheduling

Jayaram Subramanya, Suhas, et al. “Sia: Heterogeneity-aware, goodput- optimized ML-cluster scheduling.” Proceedings of the 29th Symposium on Operating Systems Principles. 2023

work page 2023