{"id":"ec463a4a-d0e1-4865-8079-1583e13de65b","arxiv_id":"2608.07971","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":7,"one_line_summary":"A Kubernetes-native scheduler jointly reshapes job configurations, prices cluster resources, and predicts GPU-sharing interference, reporting up to 2.94x lower average JCT and 2.02x higher throughput in testbed and simulation evaluations.","lead":"ElastiCo lets training and offline inference jobs share GPUs by reshaping each job's resource footprint, pricing scarce resources, and predicting interference between co-located workloads. On a 64-GPU testbed and simulations up to 512 GPUs it reports up to 2.94x lower average job completion time and roughly double cluster throughput versus static scheduling.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"JCT gains may be an artifact of an undefined training completion criterion: RST alters batch size without modeling convergence or learning-rate scaling, so 'completion' may correspond to less useful training work than the baselines.","rationale":"The reader's weakest assumption was the IAC predictor's generalization to out-of-distribution workloads. That is a legitimate external-validity concern and is acknowledged in Limitation 4, but it does not threaten the internal validity of the 64-GPU testbed result. My concern is prior: the paper never defines what it means for a training job to 'complete,' and the RST mechanisms directly alter batch size and other convergence-relevant knobs without any statistical-efficiency modeling. The paper's own introduction says training jobs run 'until convergence' (§1), yet the formal objective (Eq. 1) and the evaluation's attainment metric (Table 4) track throughput, not convergence or accuracy. If the testbed terminated jobs at a fixed iteration or epoch count, then switching to a smaller batch reduces the amount of training work done per job, so ElastiCo's JCT improvement could be inflated by completing jobs that have seen fewer samples or less diverse data than the baseline's jobs. The paper gives no evidence that all configurations in Table 2 reach equivalent model quality, nor that micro-batch changes are accompanied by learning-rate adjustment. This is a measurable, concrete gap: it can be settled by running one workload to a target accuracy under the configurations used and comparing time-to-accuracy. Because the central headline number (2.94x JCT) is not defined against a clear, quality-equivalent endpoint, the current evidence is insufficient to verify the claim. The system design ideas (RST, ESP, IAC) are interesting and the ablation is informative, but the evaluation's main metric must be re-anchored before the core contribution can be assessed.","tokens_in":39933,"tokens_out":8409,"duration_ms":94368,"concrete_test":"Inspect the evaluation harness (testbed trace and simulator) or, in its absence, run a controlled experiment: take ResNet-50 or BERT from Table 2, train to a fixed target accuracy (e.g., a specific top-1/top-5 validation accuracy) under the configurations ElastiCo selects, including small-batch/AMP/checkpointing reshapes, and record wall-clock JCT to that accuracy. Compare with Volcano on the same trace. If the time-to-accuracy ratio is substantially below 2.94x, or if the original testbed used a fixed iteration count, the headline gain is an artifact of the completion criterion. Also verify whether learning-rate scaling is applied when micro-batch size changes; without it, the reshaped configurations are not statistically equivalent training runs.","verdict_should_be":"UNVERDICTED","load_bearing_attack":"The central JCT claim is computed over training jobs whose completion is never defined and whose configurations are changed without any account of statistical efficiency. Section 3.1.2 profiles T_j(c) as 'training throughput (samples or iterations per second)'; the ESP objective (Eq. 1) maximizes this throughput subject only to a throughput floor L_j (Eq. 4). The evaluation's attainment metric (Table 4) is the fraction of jobs meeting the throughput target; no accuracy or convergence target is reported. When ESP selects a smaller micro-batch (Table 2 lists batch sizes as low as 32) or switches configurations mid-run, the number of samples per gradient step changes. Without learning-rate scaling (never mentioned in the paper), the number of steps to convergence and the final model quality change. If jobs ran to a fixed iteration count, a reshaped job processing a smaller batch 'completes' after fewer samples, doing less useful training work; if jobs ran to a fixed epoch count, T_j(c) in samples/sec is not a valid proxy for time-to-convergence because smaller batches typically require more iterations to reach the same accuracy. In either case, the reported 2.94x JCT reduction and 2.02x throughput improvement are not established as improvements in real training completion time. The paper must state the termination criterion and show that all selected configurations reach the same target accuracy (or adopt Pollux-style goodput modeling).","agreement_with_reader":"disagree"},"referee_report":{"model":"deepseek-v4-flash","summary":"ElastiCo is presented as a Kubernetes-native middleware for GPU clusters that jointly schedules deep-learning training and offline LLM inference workloads. It combines three mechanisms: Resource Shape Transformation (RST), which exposes each job as a family of resource/performance configurations; Elastic Shadow Pricing (ESP), a Lagrangian-relaxation-based pricing scheme that decomposes the allocation problem into per-job configuration selection; and Interference-Aware Co-location (IAC), a DNN-based predictor of pairwise slowdown under GPU sharing. A fourth module, Phase-Aware Disaggregated Scheduling (PDS), closes the loop with queue-aware capacity reservation, reconfiguration, and migration. The paper evaluates ElastiCo on a 64-GPU A100 testbed and in trace-driven simulations up to 512 GPUs, reporting average JCT reductions of up to 2.94x, cluster throughput improvements of 2.02x, and GPU SM utilization rising from about 25% to 46% relative to static scheduling.","tokens_in":40211,"tokens_out":5726,"duration_ms":58401,"significance":"If the results hold, ElastiCo makes a strong contribution to elastic GPU cluster scheduling by treating intra-job configuration flexibility as a first-class dimension and coupling it with interference-aware pricing. The ablation study usefully attributes the largest gain to RST (53% JCT increase when disabled), and the IAC predictor is reported with a 7.6% MAPE and R^2=0.89. The system is implemented without user-code modification and the paper includes a careful accounting of scheduling latency and reconfiguration overhead. These strengths make the paper of clear interest to the systems community. However, the headline JCT and throughput numbers rest on an undefined training completion criterion and on an evaluation that is in-distribution with respect to the interference predictor, so the quantitative claims need substantial strengthening before acceptance.","major_comments":[{"comment":"The headline JCT result is not established because the manuscript never defines what 'completion' means for training jobs. Section 3.1.2 defines T_j(c) as 'training throughput (samples or iterations per second)', the ESP objective (Eq. 1) maximizes this throughput subject only to a throughput floor L_j (Eq. 4), and Table 4's attainment metric is the fraction of jobs meeting the throughput target, not an accuracy or convergence target. When RST selects a smaller micro-batch (Table 2 lists batch sizes down to 32) or switches configurations mid-run, the samples-per-gradient-step changes, and no learning-rate scaling is mentioned anywhere in the paper. If jobs run to a fixed iteration count, a reshaped job with a smaller batch completes after fewer samples and does less useful training work; if jobs run to a fixed epoch count, T_j(c) in samples/sec is not a valid proxy for time-to-convergence because smaller batches typically require more iterations to reach the same accuracy. The 2.94x JCT reduction and 2.02x throughput improvement are therefore not shown to be improvements in real training completion time. The authors must state the termination criterion and demonstrate that all selected configurations reach the same target accuracy, or adopt a goodput-style model (as in Pollux) that accounts for statistical efficiency.","section":"§3.1.2, §3.2.1, §5.2, Table 4"},{"comment":"The implemented scoring function does not match the claimed Lagrangian decomposition. The per-job subproblem in Eq. (6) maximizes w_j T_j(c) - sum_r lambda_r R_j(c)[r], where w_j is a per-job fairness weight (e.g., inverse remaining iterations). Eq. (7) instead minimizes Score_j(c) = 1 - T_j(c)/T_j(c_max) + sum_r lambda_r R_j(c)[r] + Gamma_j(c), which is equivalent to maximizing T_j(c)/T_j(c_max) - sum_r lambda_r R_j(c)[r] and drops w_j entirely. Thus the 'weighted throughput' objective of Eq. (1) is not what the scheduler optimizes, and the fairness rationale for w_j is not realized. Please either incorporate w_j into the implemented score or explicitly state that the practical scheduler uses an unweighted, normalized objective.","section":"§3.2.2 (Eq. 6) vs §3.2.3 (Eq. 7)"},{"comment":"The interference predictor is trained and evaluated in-distribution with respect to the workloads used in the end-to-end tests. Section 3.3.2 states that training data is generated by sampling pairs of the workloads listed in Table 2; Section 5.5 cross-validates on the same 12 workload families; and the 512-GPU simulation uses the same predictor and, per §5.1, is calibrated on the identical testbed trace. The 7.6% MAPE therefore does not demonstrate that IAC generalizes to workloads outside the evaluation mix, and the §7 limitation 4 concession ('accuracy may degrade on model architectures with substantially different hardware utilization profiles') applies directly to the reported JCT and throughput gains. Please add a held-out-workload evaluation (e.g., MoE or diffusion models) and show that the scheduler's admission decisions remain correct outside the training distribution.","section":"§5.5, §7 (Limitation 4)"},{"comment":"The central quantitative claims are reported without error bars, confidence intervals, or any indication of run-to-run variance. Table 4 reports a single 24-hour replay for each system, and the scalability numbers in Table 8 likewise appear to be single simulation runs. Because scheduling outcomes under dynamic workload arrivals can be highly variable, a 2.94x JCT improvement from a single trace does not support the strength of the abstract's claims. Please report the mean and spread (or at least multiple seeds) for the testbed and simulation experiments, and state the number of independent runs.","section":"Table 4, §5.2, §5.6"}],"minor_comments":[{"comment":"The figure text in the manuscript contains long placeholder strings such as '/uni00000013/uni00000011/...' that appear to be PDF-extraction artifacts; these should be replaced with the intended axis labels and legends.","section":"Figures 6, 8, 9"},{"comment":"For reproducibility, the DNN hyperparameters should be reported: layer widths, learning rate, number of epochs, batch size, and early-stopping criteria are all absent.","section":"§3.3.2"},{"comment":"The 'Open source' column lists a dash for ElastiCo; please clarify whether the code is planned to be released, since several baselines are excluded for lack of public implementations.","section":"Table 3"},{"comment":"The parameter beta is introduced as controlling sensitivity but no default value is given, and beta_max is never assigned a concrete value in the experiments; please specify the values used and any sensitivity analysis.","section":"§3.3.3, Eq. (11)"},{"comment":"The reconfiguration overhead is reported as consuming less than 0.3% of total GPU-hours, but it is unclear whether the time spent in checkpoint-resume transitions is included in the reported JCT values; please clarify whether the 2.3 transitions/hour/GPU are part of the completion time.","section":"§5.7"}],"recommendation":"major_revision","confidential_remarks":"The two load-bearing concerns are the undefined training completion criterion and the in-distribution evaluation of the IAC predictor; both directly affect the validity of the headline JCT and throughput numbers and should be resolved before acceptance. The Lagrangian scoring mismatch is a smaller but easily fixable correctness issue that should also be addressed."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: this is a serious systems paper. The new thing is real — treating intra-job configuration flexibility as a first-class scheduling dimension, coupled with Lagrangian shadow pricing and an interference predictor that feeds back into the allocation loop. The engineering is also real: Kubernetes-native, no user-code changes, a 64-GPU testbed, a 512-GPU simulation, and a clean ablation. The IAC predictor's 7.6% MAPE and R2 of 0.89 are credible, and the ablation showing RST as the largest single contributor is informative. Credit where it is due: the authors built and measured an actual system, not just a model.\n\nThe load-bearing soft spot is the training-completion criterion. The paper never defines what 'completion' means for training jobs. The objective is throughput, and the attainment metric is the fraction of jobs meeting a throughput floor. If jobs run to a fixed iteration count, then shrinking the micro-batch means the job processes fewer total samples and 'completes' after less useful training work. If jobs run to a fixed epoch count, then throughput in samples per second is not a valid proxy for time-to-convergence without learning-rate scaling, which is never mentioned. Either way, the 2.94x JCT reduction and 2.02x throughput improvement are not established as improvements in real training completion time. Pollux addressed exactly this with goodput; ElastiCo does not. This is not a nitpick — it is the central metric of the paper.\n\nOther soft spots, in proportion: the closest co-location-aware baselines (SIRIUS, Mudi, GPUColo) are not benchmarked. The authors justify this by unavailability of implementations, which is fair, but it leaves the comparative claim weaker than the abstract implies. The interference predictor is trained and cross-validated on the same 12 workload families used in the end-to-end evaluation and simulation, so generalization is untested; the authors concede this in Section 7, limitation 4. There are no error bars on end-to-end metrics, and the number of tunable parameters is large. These are real limitations, but they are acknowledged and they do not make the work circular — the scheduler outcomes are measured, and the ablation is meaningful.\n\nWho should read this: systems researchers working on GPU scheduling, co-location, or cluster resource management. It deserves a serious referee. The right next step is peer review with a demand for major revision: define completion and accuracy targets, re-run the training-heavy experiments with fixed accuracy or convergence criteria, add error bars, and ideally benchmark at least one co-location-aware system. With those changes, the result would be worth citing.","headline":"A genuinely new combination of configuration reshaping, shadow pricing, and interference-aware co-location, but the headline JCT claims rest on an undefined training-completion criterion and same-distribution evaluation; it deserves serious review, not immediate acceptance.","tokens_in":40782,"tokens_out":2055,"would_cite":false,"duration_ms":27155,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"ElastiCo argues that treating a job's configuration as elastic rather than fixed is the missing lever for GPU cluster efficiency, and shows that jointly reshaping jobs, pricing resources, and predicting interference cuts average job…","keywords":["GPU cluster scheduling","job co-location","interference-aware scheduling","elastic configuration","shadow pricing","deep learning training","LLM inference","Kubernetes"],"falsifier":"Run ElastiCo on a cluster whose workload mix includes a model architecture with a markedly different hardware utilization profile (for example, mixture-of-experts or an image-diffusion model) that was never in the training set, and compare the IAC predictor's slowdown estimates against measured co-location throughput; if the predictor's MAPE well exceeds the reported 7.6% or if the scheduler admits pairs whose true performance decay falls below 0.6, the end-to-end JCT and utilization gains would not transfer to that mix.","tokens_in":39710,"feed_emoji":"🖥️","tokens_out":5035,"duration_ms":50474,"temperature":0.7,"pith_summary":"ElastiCo claims that GPU clusters serving both deep-learning training and offline LLM inference waste most of their capacity because each job is locked into one fixed resource configuration. The paper proposes to treat configuration flexibility as a first-class scheduling dimension: each job is profiled into a family of feasible resource-performance shapes, the scheduler prices every resource with dynamic shadow prices so each job picks its best shape independently, and a learned model predicts how much any two jobs will slow each other down if co-located. On a 64-GPU A100 testbed and in trace-driven simulations up to 512 GPUs, this combined mechanism reduces average job completion time by up to 2.94x, raises cluster throughput by 2.02x, and lifts GPU SM utilization from about 25% to 46% compared with a static scheduler. The ablation shows the largest single contribution comes from reshaping jobs' resource demands rather than from job ordering or packing.","feed_headline":"Reshaping job configs cuts GPU cluster waits 2.94x","feed_subtitle":"ElastiCo prices GPU resources and predicts co-location interference, doubling throughput on the same hardware.","key_machinery":"The load-bearing object is the Lagrangian decomposition of the joint configuration-and-allocation integer program together with the interference penalty that couples the two halves. Concretely, RST builds a profile family for each job (batch size, activation checkpointing, mixed precision, KV-cache settings), ESP assigns a shadow price $\\lambda_r$ to each resource and lets every job pick the profile minimizing performance cost plus resource rent plus interference penalty, and IAC trains a three-layer DNN to predict slowdown $\\hat{S}_{i|j}$ from hardware counters, task attributes, and pairwise features, with the constraint that predictions stay $\\ge 1$. The Phase-Aware Disaggregated Scheduling module closes the loop by reserving capacity for the queue, re-running price updates and interference checks for a few rounds, and then applying configuration switches or migrations. The whole epoch costs roughly $O(M \\cdot I \\cdot N \\cdot \\bar{K} + N^2 F)$ and stays under 15 ms at 200 jobs.","core_discovery":"The paper's central claim is that configuration selection, multi-resource allocation, and interference awareness are three interdependent parts of one problem, and that solving them jointly is what unlocks the idle capacity in GPU clusters. Its mechanism is a closed loop: Resource Shape Transformation (RST) exposes each job as a set of discrete profiles trading throughput against memory and compute; Elastic Shadow Pricing (ESP) relaxes the capacity constraints with Lagrange multipliers so each job independently minimizes a score that includes a resource rent and an interference penalty; and Interference-Aware Co-location (IAC) supplies those penalties from a neural network that predicts pairwise slowdown from 36 hardware-counter and task-level features. The loop repeats until the placement is capacity-feasible and interference-safe. The paper argues that this joint design, not any single component, delivers the reported 2.94x JCT reduction, 2.02x throughput gain, and 44% reduction in extra GPU instances, and the ablation study attributes the largest individual gain to RST, with a 53% JCT increase when it is disabled.","pith_inferences":["The pricing formulation suggests a natural extension to multi-GPU parallelism: if data, tensor, and pipeline parallel strategies are added as profile dimensions, the same shadow-price loop could co-select parallelism degree and per-GPU knobs, which the paper itself lists as future work.","Because the IAC predictor's accuracy is the main transfer risk, an online-learning variant that updates on newly measured co-location pairs would plausibly let ElastiCo absorb novel architectures (for example, mixture-of-experts or diffusion models) without offline re-training.","The 44% reduction in extra GPU instances implies a direct hardware-cost consequence: a cluster operator buying capacity for a fixed workload mix could buy roughly half as many additional GPUs, which is a sharper economic statement than the JCT or utilization numbers alone.","The weak negative correlation between training and inference demand observed in the traces suggests the approach would benefit any cluster whose workload classes have infrequently coinciding peaks; testing on traces with strong positive correlation would bound the generality of the utilization gain."],"forward_implications":["Schedulers that treat a job's resource request as fixed leave a large, exploitable fraction of GPU capacity idle; exposing configuration families is a direct way to recover it.","A market-style pricing loop with per-resource shadow prices can make configuration selection tractable even when each job has dozens of feasible profiles and the cluster runs hundreds of jobs.","Interference prediction must be configuration-aware: the same two jobs can be a safe pair under one set of knobs and a harmful pair under another, so co-location admission should be based on predicted slowdown, not just memory budgets.","Co-location decisions can be steered by charging jobs for the interference they impose, converting a combinatorial safety check into a penalty term in an otherwise decomposable optimization."],"supporting_citations":[{"why":"Supplies the shadow-price and proportional-fairness foundation that ESP's Lagrange multiplier update is built on.","marker":"[38]"},{"why":"NVIDIA MPS is the hardware mechanism that allows multiple jobs to share one GPU, which IAC predictions and co-location assume.","marker":"[44]"},{"why":"vLLM provides the continuous-batching and memory-utilization knobs that RST uses to build inference job profiles.","marker":"[15]"},{"why":"Lucid is the elastic training scheduler baseline that ElastiCo must beat in the evaluation.","marker":"[10]"},{"why":"Pollux is the prior co-adaptive scheduling work whose goodput view ElastiCo extends to co-location and interference.","marker":"[9]"},{"why":"The Alibaba PAI production trace supplies the SM-utilization and configuration-flexibility measurements that motivate the design.","marker":"[2]"},{"why":"The GenAI serving trace supplies the bursty inference demand pattern used to justify co-location opportunity.","marker":"[11]"},{"why":"Mudi is a close co-location system that ElastiCo positions against in the qualitative comparison.","marker":"[1]"}],"fun_headline_variants":["ElastiCo co-schedules training and inference, cutting waits 2.94x","Interference-aware scheduling doubles cluster throughput","Joint pricing and placement unlock idle GPU capacity","ElastiCo's elastic shapes slash job delays 2.94x","GPU co-location via shadow pricing cuts waits 2.94x"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The interference predictor, trained on pairwise measurements of the twelve evaluation workloads, must keep its accuracy when the cluster runs models and sharing patterns outside that training set, because the scheduler's co-location safety decisions rest on those predictions.","fun_headline_variants_meta":{"raw":{"variants":["ElastiCo co-schedules training and inference, cutting waits 2.94x","Interference-aware scheduling doubles cluster throughput","Joint pricing and placement unlock idle GPU capacity","ElastiCo's elastic shapes slash job delays 2.94x","GPU co-location via shadow pricing cuts waits 2.94x"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000833,"raw_usage":{"total_tokens":3654,"prompt_tokens":984,"completion_tokens":2670,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":600,"completion_tokens_details":{"reasoning_tokens":2598}},"tokens_in":600,"tokens_out":2670,"duration_ms":24048,"temperature":1.0,"reasoning_tokens":2598,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T00:36:03.422656+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run ElastiCo on a cluster whose workload mix includes a model architecture with a markedly different hardware utilization profile (for example, mixture-of-experts or an image-diffusion model) that was never in the training set, and compare the IAC predictor's slowdown estimates against measured co-location throughput; if the predictor's MAPE well exceeds the reported 7.6% or if the scheduler admits pairs whose true performance decay falls below 0.6, the end-to-end JCT and utilization gains would not transfer to that mix.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"NVIDIA MPS is the hardware mechanism that allows multiple jobs to share one GPU, which IAC predictions and co-location assume."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Pollux is the prior co-adaptive scheduling work whose goodput view ElastiCo extends to co-location and interference."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The Alibaba PAI production trace supplies the SM-utilization and configuration-flexibility measurements that motivate the design."}],"review_version":1}