Pith. sign in

REVIEW 4 major objections 5 minor 31 references

A Multi-Objective Framework for Optimizing GPU-Enabled VM Placement in Cloud Data Centers with Multi-Instance GPU Technology

T0 review · 4 major / 5 minor · reviewed 2026-08-09 · deepseek-v4-flash

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

Pith's one-line read 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.

desk verdict 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. read the letter →

arxiv 2502.01909 v1 pith:UDIUDKY3 submitted 2025-02-04 cs.DC

Ahmad Siavashi , Mahmoud Momtazpour This is my paper · ORCID
classification cs.DC
keywords CloudComputingResourceManagementGPUDefragmentationMulti-InstanceVirtualMachinePlacementConsolidationIntegerLinearProgramming
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

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

  • 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.

Reading between the lines

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

  • 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.
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.

Referee Report

4 major / 5 minor

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.

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 (4)
  1. [§5, Algorithm 1, §8] 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.
  2. [§8.2–§8.3] 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.
  3. [§8.3.2, Table 6, Abstract] 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.
  4. [§6, §8] 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.
minor comments (5)
  1. [§7, Algorithm 4] 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.
  2. [Table 6] 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.
  3. [§8.3.2] 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.
  4. [§6, Eqs. (22)–(25)] 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.
  5. [§8.2] 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.

Circularity Check

1 steps flagged · score 4.0 of 10

GRMU's headline gains are produced with heavy-basket capacity and consolidation interval tuned on the same Alibaba trace, making the headline evaluation partially in-sample; the core policy derivation is not definitionally circular.

  1. fitted input called prediction [Section 8.2 (Heavy Basket Capacity and Consolidation Interval) and Section 8.3 (GRMU Policy comparison)]
    "The parameters are tuned per workload and must be adjusted for each provider pattern. ... for the current workload, as derived in Section 5.1, the heavy basket capacity is set to 30% of the GPU pool, while the consolidation interval is disabled."

    The evaluated GRMU configuration is defined by two parameters that are selected by sweeping the same Alibaba GPU trace that later produces the claimed improvements (Figs. 6 and 9 choose 30% and Disabled; Fig. 10-12 and Table 6 report the resulting 22% acceptance gain, 17% active-hardware reduction, and 1% migration ratio). Because the same workload supplies both the parameter selection and the final comparison, the headline numbers are in-sample fitting outcomes rather than out-of-sample predictions. The reduction is not a tight equation, but the reported result is partially self-referential: a different trace would require re-tuning, and the paper explicitly says the parameters must be adjusted per workload.

full rationale

The paper's derivation of GRMU itself is not circular: the ILP objectives (Eqs. 3-5) motivate the heuristic, the CC metric is an independent observable defined in Eq. 1, and the basket/defragmentation/consolidation algorithms are constructive. The 'default placement maximizes CC' claim (Section 5) is an empirical assertion about NVIDIA driver 530.30.02, not a definitional reduction; its lack of quantitative validation is a correctness risk rather than a circularity, and I do not score it as circular. Self-citations to Cloudy [30] and the trace study [9] are load-bearing for the simulation evaluation, but there is no evidence that the cited simulator or trace analysis embeds the paper's conclusions, so they do not constitute circular reasoning. The main circularity-adjacent issue is parameter selection on the test workload: heavy basket capacity and consolidation interval are tuned with the same Alibaba trace used to compute the 22%/17%/1% claims, and Section 8.2 explicitly states the parameters are workload-specific. This makes the headline evaluation partially in-sample. Since the core GRMU mechanism has independent content and the tuned parameters are disclosed rather than hidden, the appropriate score is 4 rather than higher.

Assumptions & free parameters 3 free parameters · 4 assumptions · 0 invented entities

The central results depend on two tuned parameters and several domain assumptions about MIG behavior and trace mapping. No new physical or conceptual entities are introduced; GRMU is a scheduling policy.

free parameters (3)
  • heavyBasketCapacity = 30% of GPU pool
    Chosen by sweeping 20% to 80% on the Alibaba trace in Section 8.2.1; affects all reported results.
  • consolidationInterval = disabled
    Selected from Fig. 9 because Disabled had the best trade-off for this workload; authors state it must be tuned per workload.
  • MECC lookback window = 24 hours
    Chosen for the MECC baseline by minimizing prediction error on the same trace in Section 8.3; not central to GRMU but affects the comparison.
assumptions (4)
  • domain assumption NVIDIA's default MIG placement policy maximizes the Configuration Capability metric.
    Observed for driver 530.30.02 and used in Algorithm 1 and all simulations; no quantitative validation is provided.
  • domain assumption Alibaba trace pods can be mapped to single MIG profiles using the nearest normalized combined value, and pods requiring more than one full GPU can be excluded.
    Section 8.1; the workload is synthetic after this mapping, and the excluded pods are less than 1%.
  • domain assumption The Cloudy simulator faithfully models PM and GPU capacities and the default MIG block placement.
    Section 8 relies on Cloudy [30]; no artifact link or validation study is included.
  • standard math A large enough constant B makes the big-M constraints in the ILP valid.
    Section 6, Eq. (12) to Eq. (18); standard ILP modeling practice.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Multi-Objective Framework for Optimizing GPU-Enabled VM Placement in Cloud Data Centers with Multi-Instance GPU Technology." pith.science (2026). https://pith.science/paper/UDIUDKY3

@misc{pith2026250201909,
  author       = {Pith},
  title        = {Pith review of: A Multi-Objective Framework for Optimizing GPU-Enabled VM Placement in Cloud Data Centers with Multi-Instance GPU Technology},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/UDIUDKY3}},
  note         = {Machine review of arXiv:2502.01909}
}
read the original abstract

The extensive use of GPUs in cloud computing and the growing need for multitenancy have driven the development of innovative solutions for efficient GPU resource management. Multi-Instance GPU (MIG) technology from NVIDIA enables shared GPU usage in cloud data centers by providing isolated instances. However, MIG placement rules often lead to fragmentation and suboptimal resource utilization. In this work, we formally model the MIG-enabled VM placement as a multi-objective Integer Linear Programming (ILP) problem aimed at maximizing request acceptance, minimizing active hardware usage, and reducing migration overhead. Building upon this formulation, we propose GRMU, a multi-stage placement framework designed to address MIG placement challenges. GRMU performs intra-GPU migrations for defragmentation of a single GPU and inter-GPU migrations for consolidation and resource efficiency. It also employs a quota-based partitioning approach to allocate GPUs into two distinct baskets: one for large-profile workloads and another for smaller-profile workloads. Each basket has predefined capacity limits, ensuring fair resource distribution and preventing large-profile workloads from monopolizing resources. Evaluations on a real-world Alibaba GPU cluster trace reveal that GRMU improves acceptance rates by 22%, reduces active hardware by 17%, and incurs migration for only 1% of MIG-enabled VMs, demonstrating its effectiveness in minimizing fragmentation and improving resource utilization.

Figures

Figures reproduced from arXiv: 2502.01909 by the authors.

Figure 2
Figure 2. MIG fragmentation scenarios the utilization of the device. These illustrations show traditional and MIG-specific fragmentation scenarios. Tackling defragmentation challenges in data centers with numerous GPUs is essential, as these problems intensify in such environments. The difficulty in allocating GIs on single GPUs, due to non-contiguous memory and unavailable starting blocks, limits utilization. Reorganizing GP… view at source ↗
Figure 1
Figure 1. Profile placements on A100 4. Motivation The rules for placing MIG profiles present challenges in the allocation of GIs. GIs are created and destroyed in response to accepted and completed requests, which can lead to fragmentation [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 3
Figure 3. Alternative configurations with different per profile capacity Profile Original Configuration Alternative Configuration 1g.5gb 5 5 1g.10gb 2 3 2g.10gb 2 2 3g.20gb 1 1 4g.20gb 1 0 7g.40gb 0 0 CC 11 11 [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (8 more)
Figure 4
Figure 4. Figure 4: Components of the multi-stage GRMU placement [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 5
Figure 5. Figure 5: Distribution of profiles in the workload [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]
Figure 7
Figure 7. Figure 7: Acceptance of requested profiles across varying heavy basket [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]
Figure 8
Figure 8. Figure 8: Comparison of average and overall acceptance rates across varying [PITH_FULL_IMAGE:figures/full_fig_p009_8.png]
Figure 9
Figure 9. Figure 9: Objective function values for different consolidation intervals 8.3. Comparison We compare the GRMU policy with four VM placement policies: First-Fit (FF), Max Configuration Capacity (MCC), Max Extended Configuration Capacity (MECC), and Best-Fit (BF). Each of these po…
Figure 10
Figure 10. Figure 10: presents the hourly acceptance rates throughout the simulation, including the overall rate at its conclusion [PITH_FULL_IMAGE:figures/full_fig_p010_10.png]
Figure 11
Figure 11. Figure 11: Acceptance rates per policy across GPU profiles [PITH_FULL_IMAGE:figures/full_fig_p011_11.png]
Figure 12
Figure 12. Figure 12: illustrates the trends in active hardware usage over simulation time for each policy. As shown, GRMU typically activates fewer resources during execution. For a more detailed comparison, [PITH_FULL_IMAGE:figures/full_fig_p011_12.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

31 extracted references · 30 canonical work pages

  1. [1]

    Siavashi, M

    A. Siavashi, M. Momtazpour, gVMP: A multi-objective joint VM and vGPU placement heuristic for API remoting-based GPU virtualization and disaggregation in cloud data centers, Journal of Parallel and Distributed Computing 172 (2023) 97–113

    work page 2023

  2. [2]

    Chung, J.-S

    W.-C. Chung, J.-S. Tong, Z.-H. Chen, A fine-grained GPU sharing and job scheduling for deep learning jobs on the cloud, The Journal of Supercomputing 81 (2) (2025) 361

    work page 2025

  3. [3]

    Amaral, J

    M. Amaral, J. Polo, D. Carrera, S. Seelam, M. Steinder, Topology-aware GPU scheduling for learning workloads in cloud environments, in: SC17: International Conference for High Performance Computing, Networking, Storage and Analysis, 2017, pp. 1–12

    work page 2017

  4. [4]

    X. Zhu, L. Gong, Z. Zhu, X. Zhou, Vapor: A GPU sharing scheduler with communication and computation pipeline for distributed deep learning, in: IEEE Intl Conf on Parallel & Distributed Processing with Applications, Big Data & Cloud Computing, Sustainable Computing & Communications, Social Computing & Networking (ISPA/BDCloud/SocialCom/SustainCom), 2021, p...

    work page 2021

  5. [5]

    B. Li, T. Patel, S. Samsi, V . Gadepally, D. Tiwari, MISO: Exploiting multi-instance GPU capability on multi-tenant GPU clusters, in: Proceedings of the 13th Symposium on Cloud Computing, 2022, pp. 173–189

    work page 2022

  6. [6]

    M. Lee, S. Seong, M. Kang, J. Lee, G.-J. Na, I.-G. Chun, D. Nikolopoulos, C.-H. Hong, ParvaGPU: E fficient spatial GPU sharing for large-scale DNN inference in cloud environments, in: SC24: 11 International Conference for High Performance Computing, Networking, Storage and Analysis, 2024, pp. 1–14

    work page 2024

  7. [7]

    Q. Weng, L. Yang, Y . Yu, W. Wang, X. Tang, G. Yang, L. Zhang, Beware of fragmentation: Scheduling GPU-sharing workloads with fragmentation gradient descent, in: USENIX Annual Technical Conference (USENIX ATC 23), 2023, pp. 995–1008

    work page 2023

  8. [8]

    URL https://github.com/alibaba/clusterdata/tree/ master/cluster-trace-gpu-v2023

    Alibaba cluster trace program, Accessed: 20 January 2025. URL https://github.com/alibaba/clusterdata/tree/ master/cluster-trace-gpu-v2023

    work page 2025

Show all 31 references
  1. [9]

    Siavashi, M

    A. Siavashi, M. Momtazpour, GPU cluster dynamics: insights from Alibaba’s 2023 trace release, Computing 107 (1) (2024) 4

    2024

  2. [10]

    A. H. T. Dias, L. H. A. Correia, N. Malheiros, A systematic literature review on virtual machine consolidation, ACM Computing Surveys (CSUR) 54 (8) (Oct. 2021)

    2021

  3. [11]

    Imran, M

    M. Imran, M. Ibrahim, M. S. U. Din, M. A. U. Rehman, B. S. Kim, Live virtual machine migration: A survey, research challenges, and future directions, Computers and Electrical Engineering 103 (2022) 108297

    2022

  4. [12]

    Saidi, D

    K. Saidi, D. Bardou, Task scheduling and VM placement to resource allocation in cloud computing: challenges and opportunities, Cluster Computing 26 (5) (2023) 3069–3087

    2023

  5. [13]

    J. Lin, W. Lin, W. Wu, W. Lin, K. Li, Energy-aware virtual machine placement based on a holistic thermal model for cloud data centers, Future Generation Computer Systems 161 (2024) 302–314

    2024

  6. [14]

    Alahmad, A

    Y . Alahmad, A. Agarwal, Multiple objectives dynamic VM placement for application service availability in cloud networks, Journal of Cloud Computing 13 (1) (2024) 46

    2024

  7. [15]

    H. Xu, C. Jian, A meta reinforcement learning-based virtual machine placement algorithm in mobile edge computing, Cluster Computing 27 (2) (2024) 1883–1896

    2024

  8. [16]

    Regaieg, M

    R. Regaieg, M. Koub `aa, Z. Ales, T. Aguili, Multi-objective optimization for VM placement in homogeneous and heterogeneous cloud service provider data centers, Computing 103 (2021) 1255–1279

    2021

  9. [17]

    C.-H. Hong, I. Spence, D. S. Nikolopoulos, GPU virtualization and scheduling methods: A comprehensive survey, ACM Computing Surveys (CSUR) 50 (3) (2017) 1–37

    2017

  10. [18]

    URL https://docs.nvidia.com/vgpu

    NVIDIA Virtual GPU (vGPU) Software, Accessed: 20 January 2025. URL https://docs.nvidia.com/vgpu

    2025

  11. [19]

    URL https://docs.nvidia.com/datacenter/tesla/ mig-user-guide

    NVIDIA Multi-Instance GPU User Guide, Accessed: 20 January 2025. URL https://docs.nvidia.com/datacenter/tesla/ mig-user-guide

    2025

  12. [20]

    Siavashi, M

    A. Siavashi, M. Momtazpour, GPUCloudSim: an extension of CloudSim for modeling and simulation of GPUs in cloud data centers, The Journal of Supercomputing 75 (5) (2019) 2535–2561

    2019

  13. [21]

    A. K. Kulkarni, B. Annappa, GPU-aware resource management in heterogeneous cloud data centers, The Journal of Supercomputing 77 (11) (2021) 12458–12485

    2021

  14. [22]

    A. Garg, U. Kurkure, H. Sivaraman, L. Vu, Virtual machine placement solution for VGPU enabled clouds, in: International Conference on High Performance Computing & Simulation (HPCS), IEEE, 2019, pp. 897–903

    2019

  15. [23]

    Sivaraman, U

    H. Sivaraman, U. Kurkure, L. Vu, TECN: task selection and placement in GPU enabled clouds using neural networks, in: International Conference on High Performance Computing & Simulation (HPCS), IEEE, 2019, pp. 890–896

    2019

  16. [24]

    Sivaraman, U

    H. Sivaraman, U. Kurkure, L. Vu, Task assignment in a virtualized GPU enabled cloud, in: International Conference on High Performance Computing & Simulation (HPCS), IEEE, 2018, pp. 895–900

    2018

  17. [25]

    URL https://docs.nvidia.com/deploy/mps

    Multi-Process Service, Accessed: 20 January 2025. URL https://docs.nvidia.com/deploy/mps

    2025

  18. [26]

    C. Tan, Z. Li, J. Zhang, Y . Cao, S. Qi, Z. Liu, Y . Zhu, C. Guo, Serving DNN models with multi-instance GPUs: A case of the reconfigurable machine scheduling problem, arXiv preprint arXiv:2109.11067 (2021)

    2021 arXiv

  19. [27]

    M. Lee, S. Seong, M. Kang, J. Lee, G.-J. Na, I.-G. Chun, D. Nikolopoulos, C.-H. Hong, ParvaGPU: E fficient spatial GPU sharing for large-scale DNN inference in cloud environments, in: International Conference for High Performance Computing, Networking, Storage and Analysis, IE...

    2024

  20. [28]

    Arima, M

    E. Arima, M. Kang, I. Saba, J. Weidendorfer, C. Trinitis, M. Schulz, Optimizing hardware resource partitioning and job allocations on modern GPUs under power caps, in: Workshop Proceedings of the 51st International Conference on Parallel Processing, 2022, pp. 1–10

    2022

  21. [29]

    Saroliya, E

    U. Saroliya, E. Arima, D. Liu, M. Schulz, Hierarchical resource partitioning on modern GPUs: A reinforcement learning approach, in: IEEE International Conference on Cluster Computing (CLUSTER), IEEE, 2023, pp. 185–196

    2023

  22. [30]

    Siavashi, M

    A. Siavashi, M. Momtazpour, Cloudy: A Pythonic cloud simulator, in: 32nd International Conference on Electrical Engineering (ICEE), IEEE, 2024, pp. 1–5

    2024

  23. [31]

    Smiti, A critical overview of outlier detection methods, Computer Science Review 38 (2020) 100306

    A. Smiti, A critical overview of outlier detection methods, Computer Science Review 38 (2020) 100306. 12

    2020

Pith tools

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