Pith. sign in

REVIEW 5 major objections 7 minor 1 cited by

KIS-S: A GPU-Aware Kubernetes Inference Simulator with RL-Based Auto-Scaling

T0 review · 5 major / 7 minor · reviewed 2026-08-06 · deepseek-v4-flash

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

Pith's one-line read A PPO autoscaler trained entirely in simulation cuts P95 inference latency by up to 6.7x on a real Kubernetes GPU cluster.

desk verdict The testbed is real and the code is shipped, but the headline latency numbers look like synthetic artifacts rather than measured results. read the letter →

arxiv 2507.07932 v1 pith:MAMAD3IR submitted 2025-07-10 cs.DC

Guilin Zhang , Wulan Guo , Ziqi Tan , Qiang Guan , Hailong Jiang This is my paper
classification cs.DC
keywords KubernetesGPUschedulingreinforcementlearningresourceorchestrationsystemperformanceevaluationautoscalinginferenceservingPPO
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

KIS-S argues that a reinforcement-learning autoscaler for GPU inference can be trained entirely inside a GPU-aware simulator and then deployed to a live Kubernetes cluster without retraining, outperforming threshold-based scaling. It pairs KISim, a simulator that runs on real GPU hardware with Prometheus metrics, with KIScaler, a PPO agent that reads metrics and adjusts pod replicas through the Kubernetes API. Across four synthetic traffic patterns, the paper reports P95 latency up to 6.7x lower than a fixed CPU deployment, a 75.2% improvement in training reward, and faster reaction to bursts. The broader point is that RL-based autoscaling could become safe and practical without costly trial-and-error on production clusters.

What carries the argument

The load-bearing mechanism is the closed training-and-deployment loop formed by KISim and KIScaler. KISim is a GPU-aware Kubernetes simulator running on a real node (Intel i7, RTX 3080, 32 GB RAM) with MicroK8s, Triton Inference Server serving MobileNetV4, and Prometheus/DCGM metric collection. KIScaler, a PPO agent with a 137k-parameter actor-critic, observes a 10-dimensional normalized state vector --- replica count, GPU utilization, P95 latency, throughput, CPU/memory usage, first-order trends, episode progress, and a load-pattern identifier --- and emits a multi-discrete action adjusting GPU replicas, CPU replicas, and placement preference by writing desired replica counts to the Kubernetes API. The reward $$r_t = -\$\alpha$\,\text{Latency}_t + \$\beta$\,\text{GPUUtil}_t - \gamma\,\text{ReplicaOverhead}_t$$ balances latency minimization, GPU efficiency, and over-provisioning penalty.

What would settle it

Remove the load-pattern identifier from the state vector, retrain, and deploy to the real cluster under the four traffic patterns; if the P95-latency advantages over HPA shrink substantially or vanish, then the reported generalization depends on leaked pattern information. Separately, compare the simulator's reported P95 latency and GPU utilization against measurements from the real cluster under identical traffic; large discrepancies would mean the training signal is synthetic in a way that invalidates sim-to-real transfer.

Watch

Extended reading notes

Core claim

The paper claims that a Proximal Policy Optimization (PPO) agent can learn a latency-aware, resource-efficient replica-scaling policy entirely inside a simulator and then be deployed directly to a real single-GPU Kubernetes cluster with no fine-tuning. Training runs for 100 episodes on four synthetic traffic patterns (ramp, periodic, random, spike) with synthetic feedback due to a one-active-GPU hardware constraint; the moving-average reward rises from 1.05 to 1.84, a 75.2% increase. In deployment, KIScaler reports P95 latency reduced by up to 6.7x relative to a fixed CPU baseline under ramp traffic, 5.1x under random traffic, and 2.3x under periodic traffic, together with 23.4% higher average GPU utilization and 4x faster response to bursts. The authors present this as evidence that simulation-trained RL policies generalize to real cluster dynamics without online adaptation.

Load-bearing premise

The claim of direct deployment without retraining rests on the assumption that the simulator's synthetic latency and GPU-utilization feedback matches real cluster behavior closely enough, and on the availability of the load-pattern identifier in the training state that a real deployment would not have.

Editorial extensions

If this is right

  • If the transfer claim holds, an operator can train an autoscaler on a single-GPU testbed and deploy the same saved policy to a production cluster without an online trial-and-error phase.
  • A single learned policy can replace per-pattern threshold tuning: the same model handles ramp, periodic, random, and spike traffic without retraining.
  • Scaling decisions can be driven by latency percentiles and GPU utilization rather than CPU/memory headroom, which are the metrics that actually determine inference quality.
  • KISim provides a reproducible environment for comparing RL algorithms, reward weights, and state features before committing to cluster changes.

Reading between the lines

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

  • A sharper test of the generalization claim would retrain the agent without the load-pattern identifier in the state vector; that feature encodes which synthetic pattern produced the current episode, so keeping it may let the policy memorize rather than generalize, and the paper reports no ablation of it.
  • The consistently reported 1000 ms KIScaler latency across all four patterns in Table IV suggests the learned policy may settle on a conservative uniform replica configuration rather than truly pattern-specific responses; the spike baseline already achieves 370 ms, where KIScaler reports 1000 ms (0.37x speedup).
  • A natural extension the paper leaves implicit is calibrating the simulator's synthetic latency and utilization feedback against real measurements from the same hardware, which would directly test how much of the training signal depends on simulator assumptions.
  • Because the policy was trained under a strict one-active-GPU constraint, scaling to multi-GPU clusters may expose actions the policy never experienced during training; testing that transition is an open step.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

5 major / 7 minor

Summary. The paper presents KIS-S, a framework combining KISim, a GPU-aware Kubernetes inference simulator that runs on a real single-GPU cluster with Triton/MobileNetV4 and Prometheus/DCGM metrics, and KIScaler, a PPO-based autoscaler that learns replica-count scaling policies in simulation and is then deployed without retraining. The authors evaluate across four synthetic traffic patterns (ramp, periodic, random, spike) and claim a 75.2% training reward improvement, P95 latency reductions up to 6.7x over CPU baselines, 23.4% higher GPU utilization, 4x faster reaction to bursts, and generalization without retraining. The paper also promises a comparison with Kubernetes HPA, though Section V reports results only against static GPU and CPU baselines.

Significance. If the central claims were fully supported, this would be a meaningful step toward safe training of RL-based Kubernetes autoscalers in a GPU-aware simulator followed by direct deployment, with implications for bursty inference workloads. The paper has concrete strengths: it integrates real NVIDIA GPU hardware, Triton inference serving, Prometheus/DCGM monitoring, and the Kubernetes API into the training loop; it provides a public repository; it reports baseline benchmarks for four traffic patterns; and it gives specific PPO configuration details. However, the load-bearing results are undermined by internal inconsistencies: a constant KIScaler P95 latency across all four traffic patterns, a spike-pattern case where KIScaler is slower than the GPU baseline, a missing HPA comparison promised in the abstract, and an admission that training used synthetic feedback under a single-GPU constraint that makes the GPU action space only partially executable. These issues prevent the current manuscript from supporting its headline claims.

major comments (5)
  1. [Section V.C, Table IV] Table IV reports KIScaler P95 latency as exactly 1000 ms for all four traffic patterns, while the GPU baseline varies from 370 ms to 5800 ms. In the spike row, KIScaler (1000 ms) is worse than the GPU baseline (370 ms), giving a speedup of 0.37x/0.47x. This directly contradicts the text's claim that 'KIScaler consistently outperforms both baselines' and undermines the general 'up to 6.7x' claim, which applies only to the ramp-vs-CPU comparison. The identical 1000 ms value across very different load shapes also needs a mechanistic explanation; please state whether these numbers are measured on the real cluster via Prometheus/DCGM or produced by the simulator, and report the full latency distribution rather than a single suspicious constant.
  2. [Abstract and Section V] The abstract and Section IV promise a comparison against 'conventional baselines including HPA and fixed-resource deployments,' but Section V contains no HPA results at all. Section VI(a) then asserts that KIScaler 'consistently outperforms threshold-based baselines such as HPA' without presenting any HPA experiment or metric. This is a load-bearing omission: the motivating claim of the paper is superiority over HPA, and the current evidence only covers static GPU/CPU deployments. Either add the HPA baseline with the same four traffic patterns and metrics, or revise the abstract and Section VI to remove the unsupported HPA comparison.
  3. [Section III.B2 and Section VI(b)] Section III.B2 states that although three GPU pods are deployed, resource constraints ensure only one GPU-enabled pod is active at a time, with the other two 'scheduled but unsatisfied.' Section VI(b) confirms a single-GPU testbed and states that training used 'synthetic feedback from the simulator.' Under these constraints, a GPU replica action of +1 or +2 cannot increase actual GPU compute capacity, so the action space is not faithfully executable on the real cluster. The manuscript does not clarify whether the Table IV latencies are real-cluster measurements after frozen-policy deployment or simulator outputs. If they are simulator outputs, the 'directly deployed without retraining' claim is unsupported; if they are real measurements, the scaling actions could not actually create additional GPU workers. Please clarify the provenance of every result in Section V and provide real-cluster measurements with a GPU action space that is actually executable.
  4. [Section III.E, Eq. (1) and Eq. (3)] The reward in Eq. (3) is a weighted combination of P95 latency and GPU utilization, and the state in Eq. (1) includes both latency and the load-pattern identifier pid. The paper reports latency improvements as the main outcome, but if the evaluation latencies come from the same synthetic feedback model used to compute the reward during training, then the reported gains are partly a restatement of the reward shape rather than evidence of a policy that transfers to real hardware. In addition, no mechanism is described for setting pid during real deployment; if pid is not observable in production, the 'generalizes without retraining' claim is fragile. Please calibrate KISim's synthetic latency and utilization model against real measurements and specify how pid would be obtained or removed from the state in a deployment.
  5. [Introduction and Section V] The Introduction claims KIScaler 'improves average GPU utilization by 23.4%' and 'reacts 4x faster to bursty traffic,' but no table or figure in Section V reports GPU utilization comparisons or defines and measures reaction time. These are stated as quantitative results without supporting evidence. Please add the corresponding measurements and definitions, or remove the claims from the Introduction and Section VI.
minor comments (7)
  1. [Section IV.B and Table IV] The baselines are introduced as 'GPU-only, CPU-only, and mixed workloads,' but Table IV only reports GPU and CPU static deployments; the mixed baseline and HPA are never shown, which makes the experimental description inconsistent with the reported results.
  2. [Table II] The CPU P95 latency is listed as '-', which appears to be a missing value rather than an intentional dash; please fill in the measurement or explain why it is unavailable.
  3. [References [13] and [15]] References [13] and [15] have the same title, venue, and identical bibliographic data; one is likely a duplicate and should be replaced with the intended citation.
  4. [Figure 2] Figure 2 shows P95 response times reaching 8000 ms for several patterns, but Table I reports GPU baseline P95 of 370 ms for spike and 2600 ms for random; please clarify whether the figure pertains to CPU baselines, mixed workloads, or some other configuration, and label the axes and series accordingly.
  5. [Section III.E.1] The state vector in Eq. (1) lists 'uGPU' without specifying whether this is the node-level or container-level GPU utilization; the text says 'both the node and container levels,' so please disambiguate the state definitions.
  6. [Section V.B] The phrase 'Specially, the spike pattern' should be 'Specifically, the spike pattern' to avoid a distracting typo.
  7. [Title/header] The running title contains an unusual space in 'K ubernetes' in the first line of the manuscript; this should be corrected to 'Kubernetes.'

Circularity Check

2 steps flagged · score 6.0 of 10

Generalization is defined by the pid label in the state, and the reported latency reductions use the same P95 term that defines the training reward; the two headline claims are therefore partly circular.

  1. self definitional [Section III.E.1 (Eq. 1), Section IV.C, Section V.B]
    "st = [nreplicas, uGPU, lp95, θreq, uCPU, umem, ∆l, ∆θ, tnorm, pid] (1) ... a categorical identifier for the current load pattern (pid) ... Training spans 100 episodes (300s each), cycling through all load patterns ... KIScaler successfully learns to distinguish between different load patterns and tailors its autoscaling behavior accordingly."

    The abstract's claim 'generalizes across all traffic patterns without retraining' is the paper's headline prediction. But the policy is trained on exactly the four patterns used in evaluation, and the state vector includes pid, the identity of the current load pattern. The evaluation therefore measures the policy's response to a label it was trained on, not its behavior on an unseen traffic shape. The paper's own V.B statement that KIScaler 'learns to distinguish between different load patterns' confirms that pattern identity is the input doing the work. No production mechanism for setting pid outside the simulator is described, so the generalization claim reduces to the training input by construction.

  2. fitted input called prediction [Section III.E.3 (Eq. 3), Section V.C (Table IV), Section VI.b]
    "rt = −α ·Latencyt + β ·GPUUtilt − γ ·ReplicaOverheadt (3) ... The reward function combines P95 latency minimization, GPU utilization maximization, and scaling penalty reduction ... To address this, we used synthetic feedback from the simulator during training ... Table IV: P95 Latency Comparison: KIScaler vs. Baselines ... Ramp 1000 5800 6700 ... Spike 1000 370 470."

    The paper's principal quantitative outcome is the P95 latency reduction in Table IV (up to 6.7×). That latency is the same quantity that appears as Latencyt in the reward function (Eq. 3), and Section VI.b states the training signal was synthetic. The paper does not identify a separate, real-cluster measurement source for the KIScaler rows of Table IV; its evaluation text only says KIScaler was 'trained solely in simulation.' If, as the text suggests, the latency feedback is generated by the same synthetic model used to compute the reward, then the reported speedup is a restatement of the optimized objective rather than an independent system-level prediction.

full rationale

The central empirical claim—that a policy trained in KISim transfers to a real cluster—is not circular in the narrow sense of Eq. X = Eq. Y if Table IV is a genuine real-cluster measurement; however, the paper's own text undercuts both headline assertions. First, the 'generalizes across all traffic patterns without retraining' claim is defined by the state's pid feature: the policy is trained on the four labeled patterns and then evaluated on those same labels, so the cross-pattern result is a conditional response to a training input, not an extrapolation. Second, the P95-latency speedups are the same quantity as the Latencyt term in the reward (Eq. 3), and Section VI.b admits the reward feedback was synthetic; without an explicit separate real-cluster latency source for Table IV, the reported reductions are indistinguishable from the training objective. The self-citations ([4], [37], [38]) are not load-bearing. Overall, partial circularity: the results as presented reduce, to a significant degree, to inputs the authors constructed (pattern labels and synthetic reward feedback).

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

The central claims rest on a small number of untested assumptions: the fidelity of the synthetic feedback, the availability of pattern identifiers, and the transfer of a policy trained under a single-GPU constraint. These are not backed by independent evidence in the paper.

free parameters (2)
  • Reward coefficients alpha, beta, gamma
    Equation (3) defines the reward as -alpha*Latency + beta*GPUUtil - gamma*ReplicaOverhead. The values are not given, but the reward values (1.05 to 1.84) and the reported latency improvements depend critically on them.
  • Stabilization period after scaling
    Section III E4 mentions a 'short stabilization period' but does not specify its duration, affecting the state observations and reward timing.
assumptions (3)
  • ad hoc to paper Synthetic feedback from KISim accurately represents real GPU inference latency and utilization
    Section VI.b states training used synthetic feedback due to single-GPU constraints; no validation against real measurements is presented, and the constant 1000 ms latency in Table IV suggests the evaluation may depend on this synthetic model.
  • domain assumption The traffic-pattern identifier pid is available at test time
    Equation (1) includes pid; in a real deployment the pattern type is unknown, so this leaks information and makes cross-pattern generalization a conditioning task rather than an adaptive one.
  • ad hoc to paper The PPO algorithm with the stated reward will learn a policy that transfers from synthetic feedback to real hardware
    The paper claims sim-to-real transfer without providing evidence that the synthetic feedback is calibrated to real measurements; Section VI.b admits hardware constraints.

how reviews work

0 comments
Cite this review

Pith. "Pith review of KIS-S: A GPU-Aware Kubernetes Inference Simulator with RL-Based Auto-Scaling." pith.science (2026). https://pith.science/paper/MAMAD3IR

@misc{pith2026250707932,
  author       = {Pith},
  title        = {Pith review of: KIS-S: A GPU-Aware Kubernetes Inference Simulator with RL-Based Auto-Scaling},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/MAMAD3IR}},
  note         = {Machine review of arXiv:2507.07932}
}
read the original abstract

Autoscaling GPU inference workloads in Kubernetes remains challenging due to the reactive and threshold-based nature of default mechanisms such as the Horizontal Pod Autoscaler (HPA), which struggle under dynamic and bursty traffic patterns and lack integration with GPU-level metrics. We present KIS-S, a unified framework that combines KISim, a GPU-aware Kubernetes Inference Simulator, with KIScaler, a Proximal Policy Optimization (PPO)-based autoscaler. KIScaler learns latency-aware and resource-efficient scaling policies entirely in simulation, and is directly deployed without retraining. Experiments across four traffic patterns show that KIScaler improves average reward by 75.2%, reduces P95 latency up to 6.7x over CPU baselines, and generalizes without retraining. Our work bridges the gap between reactive autoscaling and intelligent orchestration for scalable GPU-accelerated environments.

Figures

Figures reproduced from arXiv: 2507.07932 by the authors.

Figure 1
Figure 1. Workflow of the KIS-S Framework. algorithm for its balance of training stability and practical performance in continuous control tasks. The agent interacts with the Kubernetes cluster as its environment, issuing scaling actions that directly influence the number of active inference replicas and, in turn, overall system performance. 1) State Representation: At each time step, the agent ob￾serves a feature vector that… view at source ↗
Figure 2
Figure 2. User count and P95 latency trends for four synthetic [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Reinforcement learning progress of KIScaler. [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: P95 latency comparison across traffic patterns for [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]

Discussion (0). Sign in to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. AAPA: An Archetype-Aware Predictive Autoscaler with Uncertainty Quantification for Serverless Workloads on Kubernetes

    cs.DC 2025-07 conditional novelty 5.0 of 10

    An archetype-aware autoscaler that tailors Kubernetes scaling to four workload shapes, with confidence-based hedging, cuts SLO violations up to 50% in simulation at 2 to 8 times the resource cost.

Reference graph

Works this paper leans on

40 extracted references · 38 canonical work pages · cited by 1 Pith paper

  1. [1]

    Ai-enabling workloads on large-scale gpu-accelerated system: characterization, opportunities, and implications,

    B. Li, R. Arora, S. Samsi, T. Patel, W. Arcand, D. Bestor, C. Byun, R. B. Roy, B. Bergeron, J. Holodnak et al. , “Ai-enabling workloads on large-scale gpu-accelerated system: characterization, opportunities, and implications,” in 2022 IEEE International Symposium on High- Performance Computer Architecture (HPCA) . IEEE, 2022, pp. 1224– 1237

    work page 2022

  2. [2]

    Gslice: controlled spatial sharing of gpus for a scalable inference platform,

    A. Dhakal, S. G. Kulkarni, and K. Ramakrishnan, “Gslice: controlled spatial sharing of gpus for a scalable inference platform,” in Proceedings of the 11th ACM Symposium on Cloud Computing , 2020, pp. 492–506

    work page 2020

  3. [3]

    Cross- view feature learning via structures unlocking based on robust low-rank constraint,

    A. Li, Y . Ding, D. Chen, G. Sun, H. Jiang, and Q. Wu, “Cross- view feature learning via structures unlocking based on robust low-rank constraint,” IEEE Access, vol. 8, pp. 46 851–46 860, 2020

    work page 2020

  4. [4]

    AMP4EC: Adaptive Model Partitioning Framework for Efficient Deep Learning Inference in Edge Computing Environments

    G. Zhang, W. Guo, Z. Tan, and H. Jiang, “Amp4ec: Adaptive model partitioning framework for efficient deep learning inference in edge computing environments,” arXiv preprint arXiv:2504.00407 , 2025

    work page Pith review arXiv 2025

  5. [5]

    Luksa, Kubernetes in action

    M. Luksa, Kubernetes in action . Simon and Schuster, 2017

    work page 2017

  6. [6]

    Characterising resource management performance in ku- bernetes,

    V . Medel, R. Tolosana-Calasanz, J. ´A. Ba ˜nares, U. Arronategui, and O. F. Rana, “Characterising resource management performance in ku- bernetes,” Computers & Electrical Engineering , vol. 68, pp. 286–297, 2018

    work page 2018

  7. [7]

    A survey of kubernetes scheduling algorithms,

    K. Senjab, S. Abbas, N. Ahmed, and A. u. R. Khan, “A survey of kubernetes scheduling algorithms,” Journal of Cloud Computing, vol. 12, no. 1, p. 87, 2023

    work page 2023

  8. [8]

    Prosmart hpa: A machine learning-driven proactive resource-efficient auto-scaler for microservices,

    G. Singh et al. , “Prosmart hpa: A machine learning-driven proactive resource-efficient auto-scaler for microservices,” in Proceedings of the IEEE International Conference on Cloud Computing (CLOUD) , 2022

    work page 2022

Show all 40 references
  1. [9]

    Towards resource- efficient reactive and proactive auto-scaling for microservice architec- tures,

    H. Ahmad, C. Treude, M. Wagner, and C. Szabo, “Towards resource- efficient reactive and proactive auto-scaling for microservice architec- tures,” Journal of Systems and Software , vol. 225, p. 112390, 2025

    2025

  2. [10]

    Lsram: A lightweight autoscaling and slo resource allocation framework for microservices based on gradient descent,

    K. Hu, M. Xu, K. Ye, and C. Xu, “Lsram: A lightweight autoscaling and slo resource allocation framework for microservices based on gradient descent,” Software: Practice and Experience , vol. 55, no. 4, pp. 714– 730, 2025

    2025

  3. [11]

    Multi-objective reinforcement learning based algorithm for dynamic workflow scheduling in cloud computing,

    V . S. Rayapati et al. , “Multi-objective reinforcement learning based algorithm for dynamic workflow scheduling in cloud computing,” International Journal of Electrical and Computer Engineering (IJEEI) , vol. 12, no. 1, pp. 649–658, 2024. [Online]. Available: https: //section...

    2024

  4. [12]

    Kubeshare: A framework to manage gpus as first-class and shared resources in container cloud,

    T.-A. Yeh, H.-H. Chen, and J. Chou, “Kubeshare: A framework to manage gpus as first-class and shared resources in container cloud,” in Proceedings of the 29th international symposium on high-performance parallel and distributed computing , 2020, pp. 173–184

    2020

  5. [13]

    Horizon- tal pod autoscaling in kubernetes for elastic container orchestration,

    T.-T. Nguyen, Y .-J. Yeom, T. Kim, D.-H. Park, and S. Kim, “Horizon- tal pod autoscaling in kubernetes for elastic container orchestration,” Sensors, vol. 20, no. 16, p. 4621, 2020

    2020

  6. [14]

    Comparative study between gpu utilization and inflight requests for autoscaling gpu-based inference workloads on kubernetes,

    L. Wang, “Comparative study between gpu utilization and inflight requests for autoscaling gpu-based inference workloads on kubernetes,” Master’s thesis, Lund University, 2021. [Online]. Available: https: //lup.lub.lu.se/student-papers/search/publication/9055544

    2021

  7. [15]

    Horizontal pod autoscaling in kubernetes for elastic container orchestration,

    W. Zhang, Q. Chen, K. Fu, W. Zheng, and M. Guo, “Horizontal pod autoscaling in kubernetes for elastic container orchestration,” Sensors, vol. 20, no. 16, p. 4621, 2020

    2020

  8. [16]

    Time series forecasting-based kubernetes autoscaling using facebook prophet and long short-term memory,

    P. B. Guruge and Y . Priyadarshana, “Time series forecasting-based kubernetes autoscaling using facebook prophet and long short-term memory,” Frontiers in Computer Science , vol. 7, p. 1509165, 2025

    2025

  9. [17]

    Hetsev: Exploiting heterogeneity-aware autoscaling and resource-efficient scheduling for cost-effective machine-learning model serving,

    H. Mo, L. Zhu, L. Shi, S. Tan, and S. Wang, “Hetsev: Exploiting heterogeneity-aware autoscaling and resource-efficient scheduling for cost-effective machine-learning model serving,” Electronics, vol. 12, no. 1, p. 240, 2023

    2023

  10. [18]

    A tale of two scales: Reconciling horizontal and vertical scaling for inference serving systems,

    K. Razavi, M. Salmani, M. M ¨uhlh¨auser, B. Koldehofe, and L. Wang, “A tale of two scales: Reconciling horizontal and vertical scaling for inference serving systems,” in Proceedings of the ACM Symposium on Cloud Computing (SoCC) , 2024

    2024

  11. [19]

    A systematic study on reinforcement learning based applications,

    K. Sivamayil, E. Rajasekar, B. Aljafari, S. Nikolovski, S. Vairavasun- daram, and I. Vairavasundaram, “A systematic study on reinforcement learning based applications,” Energies, vol. 16, no. 3, p. 1512, 2023

    2023

  12. [20]

    Reinforcement learning-based application autoscaling in the cloud: A survey,

    Y . Gar ´ı, D. A. Monge, E. Pacini, C. Mateos, and C. Garc ´ıa Garino, “Reinforcement learning-based application autoscaling in the cloud: A survey,” Engineering Applications of Artificial Intelligence , vol. 95, p. 103878, 2020

    2020

  13. [21]

    Deep reinforcement learning for kuber- netes autoscaling: A survey,

    W. Chen, J. Liu, and Y . Zhang, “Deep reinforcement learning for kuber- netes autoscaling: A survey,” IEEE Transactions on Cloud Computing , 2023

    2023

  14. [22]

    Resource-aware kubernetes autoscaling using reinforcement learning,

    L. Zhou, P. Wang, and Q. Liu, “Resource-aware kubernetes autoscaling using reinforcement learning,” in Proceedings of the 29th ACM Interna- tional Conference on Information and Knowledge Management (CIKM), 2020

    2020

  15. [23]

    Reinforcement learning based au- toscaling for containerized applications in cloud,

    L. Gao, F. Chen, and H. Wang, “Reinforcement learning based au- toscaling for containerized applications in cloud,” Future Generation Computer Systems, vol. 128, pp. 113–123, 2022

    2022

  16. [24]

    Reinforcement learning for gpu- accelerated cloud workloads: Adaptive autoscaling and resource man- agement,

    W. Chen, L. Zhang, and M. Huang, “Reinforcement learning for gpu- accelerated cloud workloads: Adaptive autoscaling and resource man- agement,” IEEE Transactions on Cloud Computing , 2022

    2022

  17. [25]

    Intelligent autoscaling for gpu-enabled services using deep reinforcement learning,

    J. Wang, K. Liu, and W. Xu, “Intelligent autoscaling for gpu-enabled services using deep reinforcement learning,” in Proceedings of the ACM Symposium on Cloud Computing (SoCC) , 2021

    2021

  18. [26]

    Adaptive resource management for latency- sensitive gpu inference workloads via reinforcement learning,

    F. Li, Q. Zhao, and Y . Sun, “Adaptive resource management for latency- sensitive gpu inference workloads via reinforcement learning,” Future Generation Computer Systems , vol. 140, pp. 135–147, 2023

    2023

  19. [27]

    Resource man- agement with deep reinforcement learning,

    H. Mao, M. Alizadeh, I. Menache, and S. Kandula, “Resource man- agement with deep reinforcement learning,” in Proceedings of the 15th ACM Workshop on Hot Topics in Networks (HotNets) , 2016

    2016

  20. [28]

    Dynamic resource allocation for cloud applications using reinforcement learning,

    L. Chen, J. Wang, and K. Liu, “Dynamic resource allocation for cloud applications using reinforcement learning,” IEEE Transactions on Network and Service Management , vol. 15, no. 2, pp. 608–620, 2018

    2018

  21. [29]

    Challenges and opportunities in reinforcement learning for cloud autoscaling,

    D. Sutton, X. Wang, and L. Chen, “Challenges and opportunities in reinforcement learning for cloud autoscaling,” IEEE Transactions on Network and Service Management, vol. 18, no. 3, pp. 2879–2892, 2021

    2021

  22. [30]

    Practical challenges in deploying reinforce- ment learning for kubernetes autoscaling,

    M. Xu, J. Li, and Y . Zhao, “Practical challenges in deploying reinforce- ment learning for kubernetes autoscaling,” in Proceedings of the IEEE International Conference on Cloud Engineering (IC2E) , 2022

    2022

  23. [31]

    Deep learning workload scheduling in gpu datacenters: Taxonomy, challenges and vision,

    W. Gao, Q. Hu, Z. Ye, P. Sun, X. Wang, Y . Luo, T. Zhang, and Y . Wen, “Deep learning workload scheduling in gpu datacenters: Taxonomy, challenges and vision,” arXiv preprint arXiv:2205.11913, 2022

    2022 arXiv

  24. [32]

    Versatile, scalable, and accurate simulation of distributed applications and platforms,

    H. Casanova, A. Giersch, A. Legrand, M. Quinson, and F. Suter, “Versatile, scalable, and accurate simulation of distributed applications and platforms,” Journal of Parallel and Distributed Computing , vol. 74, no. 10, pp. 2899–2917, 2014

    2014

  25. [33]

    Openai gym,

    G. Brockman, V . Cheung, L. Pettersson, J. Schneider, J. Schul- man, J. Tang, and W. Zaremba, “Openai gym,” arXiv preprint arXiv:1606.01540, 2016

    2016 arXiv

  26. [34]

    K8ssim: A simulation tool for kubernetes schedulers and its applications in scheduling algorithm optimization,

    S. Wen, R. Han, K. Qiu, X. Ma, Z. Li, H. Deng, and C. H. Liu, “K8ssim: A simulation tool for kubernetes schedulers and its applications in scheduling algorithm optimization,” Micromachines, vol. 14, no. 3, p. 651, 2023

    2023

  27. [35]

    Open-source simulators for cloud computing: Comparative study and challenging issues,

    W. Tian, M. Xu, A. Chen, G. Li, X. Wang, and Y . Chen, “Open-source simulators for cloud computing: Comparative study and challenging issues,” arXiv preprint arXiv:1506.01106, 2015

    2015 arXiv

  28. [36]

    Cosco: Container orchestration using co-simulation and gradient based optimization for fog computing environments,

    S. Tuli, S. Poojara, S. N. Srirama, G. Casale, and N. R. Jen- nings, “Cosco: Container orchestration using co-simulation and gradient based optimization for fog computing environments,” arXiv preprint arXiv:2104.14392, 2021

    2021 arXiv

  29. [37]

    Discriminative subspace learning for cross-view classification with simultaneous local and global alignment,

    A. Li, Y . Ding, D. Chen, G. Sun, and H. Jiang, “Discriminative subspace learning for cross-view classification with simultaneous local and global alignment,” in Neural Computing for Advanced Applications: First International Conference, NCAA 2020, Shenzhen, China, July 3–5, 2...

    2020

  30. [38]

    Semi- supervised subspace learning for pattern classification via robust low rank constraint,

    A. Li, R. An, D. Chen, G. Sun, X. Liu, Q. Wu, and H. Jiang, “Semi- supervised subspace learning for pattern classification via robust low rank constraint,” Mobile Networks and Applications , vol. 25, pp. 2258– 2269, 2020

    2020

  31. [39]

    Microsecond-scale pre- emption for concurrent {GPU-accelerated}{DNN} inferences,

    M. Han, H. Zhang, R. Chen, and H. Chen, “Microsecond-scale pre- emption for concurrent {GPU-accelerated}{DNN} inferences,” in 16th USENIX Symposium on Operating Systems Design and Implementation (OSDI 22), 2022, pp. 539–558

    2022

  32. [40]

    Smart hpa: A resource-efficient horizontal pod auto-scaler for microservice archi- tectures,

    H. Ahmad, C. Treude, M. Wagner, and C. Szabo, “Smart hpa: A resource-efficient horizontal pod auto-scaler for microservice archi- tectures,” in 2024 IEEE 21st International Conference on Software Architecture (ICSA). IEEE, 2024, pp. 46–57. 8

    2024

Pith tools

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