When Does Deep RL Beat Calibrated Baselines?

Benchmark study examining when deep reinforcement learning outperforms calibrated baseline methods in adaptive resource control tasks.

What is Embodied AI 101?

Stay in the loop on research in AI and physical intelligence.

When Does Deep RL Beat Calibrated Baselines?.

Adaptive resource control – deciding how many servers (or containers) to run for a service – is a classic problem in cloud computing. It’s one of those places where complex deep reinforcement learning (DRL) methods are often hyped as the next big thing. After all, in theory an RL agent watching traffic and system metrics could automatically learn when to spin machines up or down. In practice, however, engineers have long relied on simpler rule-based controllers (like Kubernetes’ Horizontal Pod Autoscaler) tuned to maintain target CPU or latency. The big question is: when, if ever, does a fancy DRL agent actually outperform a well-tuned rule-based approach?.

That’s exactly what Zhang et al. set out to answer in a recent benchmark, “When Does Deep RL Beat Calibrated Baselines?”. They introduce RLScale-Bench, a rigourous evaluation framework for “adaptive resource control” tasks. The surprising bottom line is: with a properly calibrated baseline controller, none of six popular DRL algorithms beat the rule-based policy on cost across any of the six workloads tested. In fact, the DRL agents only pull ahead in one respect – reducing service-level violations on bursty workloads – and even then at a noticeably higher infrastructure cost.

This finding challenges the common assumption that DRL will automatically dominate hand-crafted autoscalers. As the authors note, many prior studies reported conflicting claims (some said RL wins, others said rule-based wins) likely because of evaluation inconsistencies: single-seed runs, uncalibrated baselines, mismatched training budgets, etc. By matching architectures, budgets, and running five seeds per condition, Zhang et al. paint a more reliable picture. The short answer is that deep RL is not a magic bullet for autoscaling – it helps only under specific conditions, and often at a cost. Below we’ll unpack how RLScale-Bench works and what insights it yielded for practitioners.

The Adaptive Resource Control Task.

At its core, autoscaling is a sequential decision task: an agent observes the current service load and makes decisions about resources (e.g. how many pod replicas to run) to balance cost vs performance SLAs. In RLScale-Bench, this is formalized as a Markov decision process using Kubernetes’ Horizontal Pod Autoscaler (HPA) environment. Concretely, at each time step the agent sees a 6-dimensional state vector: current CPU utilization, memory usage, request rate (QPS), tail latency (p95), error rate, and the current number of replicas. The action is discrete: change the replica count by -2, -1, 0, +1, or +2. (Continuous-action algorithms like DDPG or SAC are wrapped to produce these five discrete choices, e.g. by binning the [-1,1] output.) The reward balances cost vs SLA compliance: more replicas cost money, but violations of the latency/error constraints incur a fixed penalty. In effect the agent must learn to proactively scale up before bad traffic spikes to avoid penalties, while scaling down in low-demand periods to save cost.

To test generality, the authors use six different synthetic workload patterns: Constant (steady traffic), Periodic (sinusoidal), Variable (random walk), Bursty (Poisson spikes), Ramp (monotonic increase), and Flash (one big spike). These cover a range of predictability. In each scenario, the agent runs a 60-minute simulation, making decisions every few seconds. The metrics of interest are total infrastructure cost (proportional to time-weighted replica count) and total SLA violations (number of times latency or error exceeded the threshold). By training on one pattern (Variable) and then testing on others, they also probe how well an agent trained in one regime generalizes to others.

Before diving into the results, one key piece is the baseline: a calibrated rule-based autoscaler. Concretely, they use a production-style Kubernetes HPA with a 70% CPU utilization target (i.e. scale replicas to keep CPU at ~70%). This baseline is “properly calibrated” — tuned to approach the performance envelope of the task. It represents what a well-engineered industrial controller might achieve. (For reference, they also include a uniform-random policy as a low-performance floor, but the real comparison is between DRL and the tuned autoscaler.) By matching architectures, training budgets (50k steps on the Variable pattern), reward functions, etc., the only difference is algorithm vs baseline. This study follows best practices: multiple seeds (five) for each method, consistent evaluation, and error bars, to avoid the “one-shot” claims common in past RL papers.

Benchmark Results: When (and Where) RL Helps.

The headline result is striking: the tuned rule-based controller achieved the lowest cost on every workload, outperforming all six DRL algorithms. In other words, if your only goal is minimizing the infrastructure bill, the simple autoscaler wins across the board. This held true even under changing conditions; the baseline had essentially zero violations on steady workloads (Constant, Periodic, Ramp) and only trailed the best RL agents on the highly erratic bursty/flash patterns. In fact Zhang et al. report that pattern directly: on bursty traffic the baseline incurred about 30 SLA violations, whereas the best DRL (PPO) cut that down by about half (to ~14 violations) – but at the price of ramping up more pods and thus paying ~25% more in cost. In short, DRL can reduce violations in highly unpredictable scenarios, but this relief comes with a significant cost penalty. So if your priority is strict cost efficiency, the rule-of-thumb HPA target generally wins.

Another key finding was about action space formulation. RLScale-Bench compared discrete-actions (PPO, DQN, A2C) against popular continuous-action methods (SAC, TD3, DDPG) in the same setting. The result: discrete-action agents vastly outperformed continuous ones in avoiding violations. The intuition is that the environment is inherently discrete (pods are integer), so forcing a continuous-control algorithm into it causes trouble. As the authors explain, tiny output changes in a continuous policy do nothing if they remain in the same bin, whereas nudging across a threshold causes a jump, leading to unstable learning. Indeed, DDPG (a continuous-actor) degenerated into a “always-one-replica” policy: it never scaled up, so it technically minimized cost but racked up catastrophic SLO breaches. By contrast, discrete algorithms (PPO, DQN, A2C) had one-to-two orders of magnitude fewer violations. In practice this means discrete DRL is far more effective in this control setting; the continuous versions essentially failed due to action-space mismatch.

Third, no single DRL algorithm was a clear overall winner. Performance rankings shuffled substantially depending on the workload. For example, the HPA baseline ranked top on constant and periodic traffic, but fell to fifth place under bursty patterns. PPO was generally stable (ranked 2–3 in most cases), SAC did very well on the “Variable” random traffic but poorly on a ramp, and DQN/A2C shuffled around. The upshot is that an agent tuned to one traffic profile might not generalize; the authors coin this a “transfer tax”. Even the best DRL agent on bursts (PPO) gave up its advantage when deployed off-policy to a different pattern. Concretely, the benchmark shows rankings shifting by up to four places between workload types.

To sum up these results succinctly: (i) a well-tuned rule-based autoscaler is the cost champion everywhere, (ii) DRL’s big win is reducing SLA breaches during sharp spikes, and (iii) the choice of RL algorithm itself matters less than having the right tool for the workload. In fact, Zhang et al. conclude that “the bottleneck in RL-based resource control is not algorithm selection but baseline calibration, reward engineering, and realistic evaluation protocols”. Any advantage DRL has is narrow – for unpredictable bursts – and comes with trade-offs. In stable conditions, the simple CPU-threshold policy rules.

Implications and Insights.

These findings carry several lessons for practitioners and researchers. First, they underline how powerful a calibrated baseline can be. Before deploying DRL, one should fully tune the rule-based controller. In this work, that meant setting the HPA target to 70% CPU (a production-faithful choice) and clamping replicas between 1 and 10. Such a policy held SLOs under control in steady traffic with minimal cost. The implication is that many prior RL papers may have oversold their gains simply because the baseline wasn’t as carefully tuned. As the authors note, inconsistent comparisons in the literature (different hyperparameters, single seed trials, etc.) have fuelled confusion. By doing a head-to-head with a hardened baseline, RLScale-Bench shows that “old-school” still works remarkably well for much of the domain.

Second, the study makes clear that DRL shines on the unpredictable corner of the problem space. When traffic patterns suddenly spike or flash – cases where a static threshold policy reacts too slowly – adaptive RL can improve SLO compliance. The example given is PPO on the bursty workload: it cut the violations rate by over half compared to baseline. However, this came at 24% higher infrastructure cost. This highlights a fundamental trade-off: if you’re willing to spend more on servers to cover your goals, DRL can buy you better reliability under stress. In practical terms, one might choose DRL for mission-critical services where any outage costs a lot, whereas for cost-sensitive scenarios ripe with stable demand, stick with clever heuristics.

The continuous vs. discrete split is also instructive. It’s a cautionary tale about action-space alignment. Cloud autoscaling naturally has discrete actions (“add one pod, remove two pods,” etc.), so forcing a continuous-control algorithm onto it caused great difficulty. This mismatch echoes broader RL wisdom: the choice of action representation must fit the problem. In other words, for tasks that are inherently stepwise or categorical, discrete-action methods (even if originally designed for continuous settings) may work far better. For developers, that might mean preferring DQN/A2C/PPO over SAC/TD3 for any integer-control task.

Another implication is about generalization and robustness. The fact that each RL algorithm’s rank flipped across workloads suggests you can’t pick “the best DRL” once and for all. If the real-world traffic shifts unexpectedly (which it often does), the agent trained on past patterns may no longer be optimal. In contrast, a rule-engine tied to current CPU or latency will at least adapt via its built-in feedback. The authors’ “transfer tax” analogy is apt: more sophisticated agents need careful retraining/tuning as conditions change, which incurs practical overhead.

Finally, the big-picture takeaway is one of humility. The TL;DR from Zhang et al. is almost a warning: “Avoid overestimating deep RL for resource control”. Even though DRL is a hot topic, this benchmark reminds us that the architecture (including baseline design) matters more than the parameter count or algorithmic bells and whistles. The machinebrief summary aptly notes that “sometimes, simplicity wins”. For ML researchers, this is a call to rigor: always compare new algorithms to strong, tuned baselines and test under variation. For engineers, it suggests that operational simplicity and predictable behavior (like a tuned HPA rule) may often be preferable to an opaque neural controller.

In sum, “RLScale-Bench” reframes the narrative around RL in cloud autoscaling. It doesn’t say “never use RL”, but it clarifies when it might help. Namely, in volatile, bursty environments where reducing SLA violations is worth higher cost, RL (especially discrete-action PPO) can outperform. In calm waters, well-calibrated heuristics suffice. This nuanced view is crucial for deciding how to allocate research effort or engineering resources. If we push too hard on DRL without acknowledging its limits, we risk overcomplicating systems that already work well. Zhang et al.’s benchmark teaches us to recognize that “in the pursuit of new technology, we should not overlook tried-and-true methods that deliver just as well, if not better”.

Overall, the study emphasizes robust evaluation. By matching workloads, running multiple trials, and penalizing both cost and SLA violations, it provides a transparent picture. It suggests future DRL research in resource control should include similar fidelity checks: sensible reward shaping, distribution-shift tests, and error bars. Only then can we honestly gauge whether a new RL agent truly beats the calibrate-it-first baseline. As we integrate learning agents into real systems (cloud deployments, data centers, or even robot swarms managing battery vs. performance), these lessons – of calibration, clarity, and context – become invaluable.

References: Zhang et al. (2026) provide the primary benchmark results. Pandey et al. (2025) discuss RL approaches versus fixed-threshold autoscalers. A recent news write-up of RLScale-Bench (“Why Rule-Based Autoscalers Still Hold Their Ground Against DRL”) also summarizes these points.