{"id":"84918db2-99b9-4a5e-b2e6-a703aa8bda29","arxiv_id":"2502.01909","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"GRMU, a placement policy for NVIDIA MIG GPUs, is reported to accept 22% more requests and use 17% less active hardware on an Alibaba trace, with only 1% of accepted VMs migrated.","lead":"This paper models placement of GPU-sharing VMs on NVIDIA MIG hardware as an optimization problem and introduces GRMU, a heuristic scheduler that uses quotas and live migrations to reduce fragmentation. On a trace from Alibaba's GPU cluster it reports 22% higher request acceptance, 17% less active hardware, and migrations for only 1% of accepted VMs.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The 22%/17%/1% gains are computed under an unvalidated model of NVIDIA's default MIG block placement; if Cloudy's Assign differs from the real driver, the GRMU advantage could be a simulator artifact.","rationale":"The reader's weakest assumption identifies exactly the same load-bearing point, so I agree with the CONDITIONAL verdict. The paper is honest about tuning and discusses the configuration space in detail, but its headline results are entirely simulation-based, and the simulator's one place where the real hardware matters is the default MIG placement rule. The paper states this rule was observed with driver 530.30.02, yet provides no measurements to back the CC-maximization model. The internal analysis in Section 5.1 makes the concern concrete: the default policy is described as generating 248 sequential configurations, 69% of which are not CC-optimal, and Table 3 shows that equal-CC arrangements can differ in which profiles they can host. Because GRMU's defragmentation and its comparison against MCC/MECC/BF/FF all operate on top of this lower-level rule, a mismatch between Cloudy's Assign and real firmware would invalidate every reported improvement. The proposed test is practical and decisive: compare Assign's block choices against nvidia-smi on real hardware for a sample of the enumerated configurations. This is a verification requirement, not a speculative objection, and it can be satisfied by the authors with a modest hardware experiment. I also note the abstract's 17% active-hardware reduction does not match Table 6: GRMU's AUC of 87,546.53 is 14.3% lower than FF's 102,169.44, not 17% (it is 18.4% lower than MCC's 107,363.19). That arithmetic discrepancy should be corrected, but it is secondary to the placement-fidelity question because even the corrected number is still produced under the unvalidated lower-level model. No machine-checked proof, code release, or independent reproduction is provided, so the conditional acceptance should require both the placement validation and the correction.","tokens_in":15452,"tokens_out":4413,"duration_ms":43520,"concrete_test":"On an NVIDIA A100 with driver 530.30.02, enumerate a representative sample of the 723 reachable configurations from Section 5.1. For each configuration, use nvidia-smi to create every MIG profile that the configuration can host, record the starting block chosen by the driver, then destroy the instance. Compare the observed choices with Algorithm 1's Assign (arg-max CC). If the driver's chosen starting block disagrees in even one configuration where the CC rule is not unique, or if it systematically differs on non-tie cases, the simulator's lower-level placement is not validated and the GRMU evaluation numbers cannot be trusted.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is a set of simulation results, so the fidelity of Cloudy's lower-level MIG placement is load-bearing. Section 5 asserts that NVIDIA driver 530.30.02 places a MIG profile by maximizing Configuration Capability (CC), encoded as Algorithm 1's Assign. No quantitative comparison to real driver behavior is reported. Section 5.1 itself shows that CC-maximizing placement is not forced: many configurations are suboptimal, and Table 3 gives two arrangements with identical CC but different per-profile capacities. If the real driver's tie-breaking or block selection differs from arg-max CC (or if the valid start-block table is incomplete), then the fragmentation analysis, the defragmentation decisions in Algorithm 4, and the final comparison in Table 6 and Figures 10-12 all inherit that error. Because all headline improvements are differences between policies simulated under this assumed rule and no real MIG placement result is reported, the 22% acceptance, 17% active-hardware, and 1% migration claims are not yet established.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper addresses GPU-enabled VM placement in cloud data centers where NVIDIA MIG imposes rigid block-alignment rules. It formulates a multi-objective ILP maximizing acceptance, minimizing active hardware, and minimizing migration overhead, then proposes GRMU, a multi-stage heuristic that combines dual-basket GPU partitioning, CC-based intra-GPU defragmentation, and inter-GPU consolidation. The method is evaluated on the 2023 Alibaba GPU cluster trace using the Cloudy simulator, with reported improvements of 22% higher acceptance over MCC, 17% lower active hardware over FF, and migrations on only 1% of accepted MIG-enabled VMs.","tokens_in":15673,"tokens_out":7058,"duration_ms":67161,"significance":"If the reported results hold, GRMU would be a practically valuable policy for MIG-aware scheduling, with a strong trade-off among acceptance, hardware usage, and migration cost. The paper contributes a formal model of MIG placement constraints, a concrete heuristic decomposition, and a trace-driven evaluation against several baselines. Its strengths include the explicit modeling of MIG start-block constraints, the use of a real production trace, and the stepwise ablation of basket sizing, defragmentation, and consolidation. However, the empirical claims are not yet established: the simulator's lower-level MIG placement rule is asserted without quantitative validation, and key parameters are tuned on the same trace used for the final comparison, making the headline numbers partly in-sample.","major_comments":[{"comment":"The assumption that NVIDIA driver 530.30.02 places MIG profiles by arg-max CC, encoded in Algorithm 1's Assign procedure, is load-bearing for the entire evaluation. The fragmentation analysis in §5.1, the defragmentation decisions in Algorithm 4, and all comparisons in §8 inherit this assumption. No quantitative comparison against real driver behavior is reported, and Table 3 itself shows two configurations with equal CC but different per-profile capacities, so tie-breaking and start-block selection can change outcomes. Without a validation experiment on real A100 hardware, or at least a sensitivity analysis over plausible alternative placement rules, the 22%/17%/1% claims could be simulator artifacts.","section":"§5, Algorithm 1, §8"},{"comment":"The heavy-basket capacity of 30% and the disabled consolidation interval are selected in §8.2 by sweeping on the same Alibaba trace that is later used for the final comparison in §8.3. In addition, the MECC look-back window n=24 is chosen in §8.3 by minimizing prediction error on the same trace. The reported improvements are therefore in-sample fits, not out-of-sample predictions. There are no error bars, no repeated runs with different random or seed conditions, and no holdout period. Please provide an evaluation on a separate time interval or with cross-validation, and show how the headline numbers vary with the tuned parameters.","section":"§8.2–§8.3"},{"comment":"The active-hardware reduction claim is not supported by Table 6 as stated. The text says GRMU outperforms the second-best policy FF by 17%, but the normalized AUC values in Table 6 are 0.8153 for GRMU and 0.9516 for FF, which is a relative reduction of 14.3%. The abstract's unqualified 'reduces active hardware by 17%' cannot be reproduced from the table, since the baseline is not specified. Please correct the number and explicitly state the baseline policy and the exact relative reduction used in every occurrence.","section":"§8.3.2, Table 6, Abstract"},{"comment":"The ILP formulation in §6 is not solved or compared against. Section 8 states that even a solver cannot handle the problem within a viable timeframe even at limited scale, but no small-scale optimality gaps, lower bounds, or reduced-instance comparisons are reported. As a result, the heuristic's quality relative to the stated multi-objective goals is unquantified. Please either solve the ILP on small instances and report GRMU's gap, or explicitly reposition the ILP as a conceptual model rather than a benchmark that the evaluation is tied to.","section":"§6, §8"}],"minor_comments":[{"comment":"In the Fragmentation function, gpu′ is mutated cumulatively as profiles are placed, so the resulting fragVal depends on the iteration order over profiles and start blocks. This makes the fragmentation score order-dependent; please define the metric statelessly or restore gpu′ for each candidate placement.","section":"§7, Algorithm 4"},{"comment":"The 'Normalized Value' column should state its normalization baseline explicitly; the current table appears to normalize to MCC=1.0000, but this is not stated in the text.","section":"Table 6"},{"comment":"The sentence 'It is expected that FF and BF policies have a smaller cumulative area compared to MCC and MECC' is confusing because Table 6 shows GRMU with the smallest area; clarify that the expectation holds only for FF/BF versus MCC/MECC and not for GRMU.","section":"§8.3.2"},{"comment":"The text says that inter-machine migrations (mi j=1) trigger intra-machine GPU reassignments (ωi jk), but this implication is not enforced by the constraints; either add a linking constraint or rephrase the claim as a modeling preference.","section":"§6, Eqs. (22)–(25)"},{"comment":"Figures 6–9 would benefit from error bars or per-run variance markers, since the 'good balance' conclusions for basket capacity and consolidation interval are based on single-point comparisons.","section":"§8.2"}],"recommendation":"major_revision","confidential_remarks":"The paper is within the journal's scope and presents a plausible practical heuristic, but the empirical case is not yet solid: the lower-level MIG placement model is unvalidated, the headline parameters are tuned in-sample, and the active-hardware number is internally inconsistent. I would not reject the paper, but the revision needs a real-hardware validation or sensitivity analysis, a holdout-based evaluation, and corrected quantitative claims before acceptance can be recommended."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"GRMU is a plausible scheduler for MIG-based clouds, and the configuration-space analysis in Section 5.1 is the most valuable part of the paper. The 22% acceptance improvement over MCC looks credible as a simulation result; the 17% hardware reduction does not match Table 6 (relative to FF it's 14.3%), and the 1% migration claim is just arithmetic on 37/3168. The authors are honest that basket capacity and consolidation interval are tuned per workload on the same trace, so the headline numbers are fitting, not prediction. That doesn't kill the work, because the mechanism is sensible: dual-basket quotas protect small profiles from 7g.40gb monopolization, and intra-GPU defragmentation attacks a real MIG problem. But the evaluation needs a holdout or at least error bars before the numbers are advertised.\n\nThe bigger soft spot is the load-bearing assumption in Section 5: the claim that NVIDIA driver 530.30.02 places profiles by arg-max CC is asserted, not validated. The whole GRMU advantage depends on that model. If Cloudy's Assign differs from real firmware tie-breaking, the fragmentation analysis and the gains are simulator artifacts. The authors should show a few real MIG placements on an A100 matching the model. The ILP is never solved, so it's a formalization exercise; fine, but don't oversell it. No code or data released, which makes the tuning circularity worse.\n\nWho's it for: people building MIG-aware schedulers. It deserves a serious referee, but with major revision: fix the arithmetic, add holdout or cross-validation, validate the MIG placement model, and release artifacts. I'd be inclined to accept after that.","headline":"Useful MIG-aware scheduler with an interesting configuration-space analysis, but the headline numbers are tuned on the same trace and one of them doesn't match the paper's own table.","tokens_in":16158,"tokens_out":1685,"would_cite":true,"duration_ms":16629,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A placement policy that respects MIG block-alignment rules raises VM acceptance by 22% and cuts active GPU hardware by 17% on a real cluster trace.","keywords":["Cloud Computing","Resource Management","GPU Defragmentation","Multi-Instance GPU","Virtual Machine Placement","Consolidation","Integer Linear Programming"],"falsifier":"On an A100 GPU using the same driver generation as the paper's experiments, create the two-1g.5gb instance scenario from Section 5.1 and record where the second instance lands; if the hardware does not put it on the block that leaves the most room for future profiles, the paper's model of the default MIG placement policy is wrong.","tokens_in":15272,"feed_emoji":"🖥️","tokens_out":9133,"duration_ms":84819,"temperature":0.7,"pith_summary":"This paper argues that the rigid block-alignment rules of Multi-Instance GPU (MIG) technology are a first-class scheduling constraint, and that a placement policy built around them can substantially beat generic bin-packing heuristics. It formalizes MIG-enabled VM placement as a multi-objective integer linear program that simultaneously maximizes request acceptance, minimizes active physical machines and GPUs, and minimizes live migrations. Because solving that ILP online is impractical, the paper proposes GRMU, a staged heuristic that splits GPUs into a heavy basket for the largest profile and a light basket for all others, defragments the most fragmented light GPU by intra-GPU migration, and optionally consolidates half-empty GPUs. On a published GPU cluster trace, the paper reports that GRMU accepts 22% more requests than the best comparison policy, uses 17% less active hardware, and migrates only about 1% of accepted MIG-enabled VMs. If these numbers hold, GRMU is a concrete recipe for getting more utilization out of MIG-capable data center GPUs without drowning operators in migrations.","feed_headline":"MIG-aware placement lifts acceptance 22%, cuts active GPUs 17%","feed_subtitle":"A quota-based defragmentation policy for MIG keeps migrations below 1% of accepted VMs.","key_machinery":"The load-bearing mechanism is the Configuration Capability (CC) metric, defined as $\\mathrm{CC}(G)=\\sum_{p\\in P}|S(G,p)|$, the number of ways a GPU configuration $G$ can still accommodate each MIG profile. The paper treats the hardware's native block allocator as a CC-maximizing procedure (its Assign algorithm), and then builds every higher-level decision on this metric: the fragmentation score ranks GPUs by how much reclaimable space they carry, the defragmentation step replays a GPU's VMs onto an empty GPU to detect which VMs would be relocated by the native policy, and dual-basket quota partitioning reserves capacity for the largest profile. Intra-GPU migration repairs the most fragmented GPU; inter-GPU consolidation pairs half-empty single-profile GPUs; both use the native CC-maximizing placement as the fixed lower level.","core_discovery":"The central empirical discovery is that MIG fragmentation is not just a single-GPU nuisance but a data-center-scale loss that a placement policy can recover. The paper defines Configuration Capability (CC), the count of profiles a GPU configuration can still host, and observes that the hardware's default MIG placement chooses the start block that maximizes CC; nevertheless, sequential allocations drift into suboptimal arrangements. GRMU exploits this by operating at the VM-to-GPU level: it reserves a quota of GPUs for the 7g.40gb profile, places smaller profiles first-fit in the remaining pool, and when a request is rejected it finds the light-basket GPU with the highest fragmentation score, replays its VMs onto an empty model of the GPU to see which ones would land elsewhere under the default policy, and migrates only those VMs. The paper's quantitative claim is that on 1,213 hosts and 8,063 MIG-enabled VMs from the released GPU cluster trace, this policy raises overall acceptance by 22% over the best baseline (MCC), cuts cumulative active hardware by 17% versus the second-best policy (FF), and migrates 37 of 3,168 accepted VMs.","pith_inferences":["Our inference: if the CC-maximizing model of the default placement is wrong in a common case, GRMU's fragmentation rankings and replay-based defragmentation would be built on the wrong lower level; a hardware check of the Assign algorithm on an A100 is the cheapest decisive experiment.","Our inference: the dual-basket quota idea transfers to other MIG-capable GPUs and to any resource with alignment constraints, but the paper only demonstrates it on A100 profiles.","Our inference: making basket capacities and consolidation intervals adaptive to request forecasts could remove the offline tuning step, since the chosen 30% and 'disabled' settings were selected by grid search on one trace.","Our inference: because CC counts every profile equally, replacing it with demand-weighted expected capability would shift the policy toward per-profile fairness rather than raw acceptance."],"forward_implications":["A MIG-aware upper-level scheduler can recover most of the fragmentation loss without modifying the hardware's closed lower-level placement policy.","The 30% heavy-basket capacity and the disabled consolidation interval are workload-dependent; providers must re-tune them, and the paper's stepwise procedure shows how.","The policy deliberately sacrifices acceptance of the largest profile (0.6x versus the best baseline) to protect smaller profiles; providers who prioritize large jobs would enlarge the heavy basket.","The ILP formulation gives a formal three-objective target against which future online placement policies can be measured."],"supporting_citations":[{"why":"Defines the MIG profile set, placement rules, and start-block constraints that the entire model is built on.","marker":"[19]"},{"why":"Supplies the released GPU cluster trace used to construct the 8,063-VM workload.","marker":"[8]"},{"why":"Provides the discrete-event simulator in which all placement policies are evaluated.","marker":"[30]"},{"why":"Documents GPU fragmentation in large ML clusters and motivates the fragmentation-aware scheduling direction.","marker":"[7]"},{"why":"Shows prior MIG partitioning work and frames the multitenant GPU sharing problem that this paper extends to VM placement.","marker":"[5]"},{"why":"Provides analysis of the released cluster trace that informs workload construction.","marker":"[9]"},{"why":"Supplies the IQR outlier-removal method used to clean arrival times in the trace.","marker":"[31]"}],"fun_headline_variants":["Quota-based MIG placement boosts acceptance 22%, cuts GPU waste 17%","GPU defragmentation policy lifts VM acceptance 22%, cuts active hardware 17%","MIG placement fix: 22% more VMs accepted, 17% fewer GPUs active","Defragmenting MIG pools raises acceptance 22%, trims active GPUs 17%","Quota-based MIG placement: +22% acceptance, -17% active GPUs"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that the simulator's placement of memory blocks on a GPU matches what the real hardware's default software actually does; if the real placement chooses different positions, the fragmentation analysis and all reported gains would be an artifact.","fun_headline_variants_meta":{"raw":{"variants":["Quota-based MIG placement boosts acceptance 22%, cuts GPU waste 17%","GPU defragmentation policy lifts VM acceptance 22%, cuts active hardware 17%","MIG placement fix: 22% more VMs accepted, 17% fewer GPUs active","Defragmenting MIG pools raises acceptance 22%, trims active GPUs 17%","Quota-based MIG placement: +22% acceptance, -17% active GPUs"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001111,"raw_usage":{"total_tokens":4675,"prompt_tokens":1037,"completion_tokens":3638,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":653,"completion_tokens_details":{"reasoning_tokens":3521}},"tokens_in":653,"tokens_out":3638,"duration_ms":24711,"temperature":1.0,"reasoning_tokens":3521,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-09T14:01:48.578383+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"On an A100 GPU using the same driver generation as the paper's experiments, create the two-1g.5gb instance scenario from Section 5.1 and record where the second instance lands; if the hardware does not put it on the block that leaves the most room for future profiles, the paper's model of the default MIG placement policy is wrong.","supporting_citations":[{"cited_title":"URL https://docs.nvidia.com/datacenter/tesla/ mig-user-guide","cited_arxiv_id":null,"evidence_quote":"Defines the MIG profile set, placement rules, and start-block constraints that the entire model is built on."},{"cited_title":"URL https://github.com/alibaba/clusterdata/tree/ master/cluster-trace-gpu-v2023","cited_arxiv_id":null,"evidence_quote":"Supplies the released GPU cluster trace used to construct the 8,063-VM workload."},{"cited_title":"Siavashi, M","cited_arxiv_id":null,"evidence_quote":"Provides the discrete-event simulator in which all placement policies are evaluated."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Documents GPU fragmentation in large ML clusters and motivates the fragmentation-aware scheduling direction."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Shows prior MIG partitioning work and frames the multitenant GPU sharing problem that this paper extends to VM placement."},{"cited_title":"Siavashi, M","cited_arxiv_id":null,"evidence_quote":"Provides analysis of the released cluster trace that informs workload construction."},{"cited_title":"Smiti, A critical overview of outlier detection methods, Computer Science Review 38 (2020) 100306","cited_arxiv_id":null,"evidence_quote":"Supplies the IQR outlier-removal method used to clean arrival times in the trace."}],"review_version":1}