SubZeroCore: LLM-Guided Multi-Agent RL Scheduler
- SubZeroCore is a zero-shot, LLM-guided hierarchical multi-agent reinforcement learning controller that maps tasks to cores and adjusts DVFS for energy and thermal regulation.
- It integrates regression-based environment modeling with LLM-extracted semantic features to enable dynamic, workload-conditioned planning without extensive offline profiling.
- Empirical evaluations show significant improvements in energy efficiency, makespan reduction, and convergence speed compared to traditional utilization-based governors.
SubZeroCore is a zero-shot, LLM-guided hierarchical multi-agent reinforcement learning scheduler for task-to-core mapping and per-core DVFS on embedded platforms. In the formulation derived from "ZeroDVFS: Zero-Shot LLM-Guided Core and Frequency Allocation for Embedded Platforms," it targets multi-core embedded CPUs with per-core DVFS states, thermal sensors, performance counters, and OpenMP task runtime, and seeks to minimize energy and makespan while keeping temperatures below a safety threshold under low-latency runtime control. Its defining characteristic is the combination of hierarchical MARL, regression-based environment modeling, and LLM-extracted semantic features that permit zero-shot deployment for new workloads on trained platforms without workload-specific profiling samples (Pivezhandi et al., 13 Jan 2026).
1. Problem formulation and optimization targets
SubZeroCore is posed on a multi-core embedded CPU with discrete per-core DVFS sets , where an arriving OpenMP workload is decomposed into tasks or threads whose mapping and frequency assignment determine energy consumption, thermal trajectory, and makespan. The decision variables are a task-to-core mapping vector
or, equivalently, core selection with CPU affinity for threads or tasks, together with a per-core frequency vector
The optimization goals are explicit: energy is minimized, makespan is minimized, and thermal safety is enforced through the runtime condition for all cores (Pivezhandi et al., 13 Jan 2026).
The controller adopts canonical power and thermal relations as modeling priors and consistency checks. The dynamic power relation is
energy is
and the lumped RC thermal model is
In deployment, however, SubZeroCore does not rely on these equations alone. It uses calibrated multivariate regression models that incorporate these physics-inspired dependencies while maintaining low inference latency. This positioning is important: the system is neither a utilization-only governor nor a purely table-driven profiler, but a learned controller intended to react to stall behavior, memory effects, and thermal evolution that utilization heuristics can miss (Pivezhandi et al., 13 Jan 2026).
A central motivation is the inadequacy of two baseline families. Utilization-only governors ignore stall cycles and variations in memory behavior, while exhaustive table-based profiling requires offline profiling for each workload and platform. SubZeroCore is designed to preserve runtime adaptation and to avoid workload-specific profiling at first deployment by generating synthetic experience conditioned on program semantics. This suggests a shift from per-application lookup-table construction toward platform-calibrated, workload-conditioned planning (Pivezhandi et al., 13 Jan 2026).
2. Hierarchical control architecture
The scheduler is organized as a hierarchical multi-agent RL system with two collaborative agents. The Temperature agent is thermal-oriented: it assigns priority scores or an ordering over cores based on current and predicted thermal states, then selects the top-0 cores that minimize hotspot risk and balance thermal load. The Profiler agent is performance- and energy-oriented: it selects how many cores to activate, denoted 1, and chooses a compact per-core frequency plan from a small discrete template set. The blueprint gives examples of such abstractions as uniform-2 for top-3 prioritized cores, tapered-frequency profiles, or two-level banding for memory-bound cores versus compute-bound cores (Pivezhandi et al., 13 Jan 2026).
The final decision is composed from both outputs. The Temperature agent provides a prioritized list of cores; the Profiler agent chooses 4 and a frequency plan; the runtime then maps tasks to the top-5 prioritized cores according to the selected plan. This decomposition is intended to avoid an 6 explosion, where 7 denotes per-core DVFS levels, and it is the basis for the reported practical decision latency of approximately 8 ms for subsequent decisions (Pivezhandi et al., 13 Jan 2026).
The architecture is explicitly model-based. Two regressors form the environment model. The Profiler model predicts next-state performance observables such as makespan increment, IPC, stalls, energy, and power, given current state and action. The Thermal model predicts next-state per-core temperatures from current temperatures, power, and DVFS decisions. Lightweight FCN and Conv1D architectures are used so that prediction remains fast enough for planning. This decomposition also supports a Dyna-Q-style interaction loop in which real transitions and imaginary transitions coexist in the replay process (Pivezhandi et al., 13 Jan 2026).
The architectural split between thermal prioritization and profiler-driven frequency/core-count selection is the core systems idea. It separates hotspot avoidance from performance-energy trade-offs while still producing a single actuation decision over frequency vectors and CPU affinity. A plausible implication is that this partitioning makes the controller more tractable than a monolithic policy over the full joint space of mapping and per-core DVFS assignments.
3. State, action, reward, and learning dynamics
The state vector is defined as
9
with the more explicit form
0
Here, 1 contains per-core temperatures, 2 the current DVFS states, 3 aggregates performance counters such as IPC, stall cycles, instructions, cache references or misses, and context switches, 4 denotes the 13 LLM-extracted semantic features, and 5 contains static syntax-level features from Tree-sitter together with metadata such as problem size. Optional elements include utilization, NUMA locality metrics, and energy estimates (Pivezhandi et al., 13 Jan 2026).
The action is represented as
6
where 7 is the per-core priority vector from the Temperature agent, 8 is the number of active cores, and 9 is a compact per-core frequency template chosen from a small discrete set 0. The template instantiates a frequency vector 1 over the selected top-2 cores, yielding per-core DVFS with reduced dimensionality (Pivezhandi et al., 13 Jan 2026).
The Temperature agent uses a piecewise reward. For core 3,
4
and the aggregate reward is
5
The Profiler agent uses a thresholded two-term exponential reward with parameters 6 and 7, referenced to 8 under the powersave governor and 9 under the performance governor. If
0
then
1
Otherwise,
2
3
and
4
These rewards jointly trade off energy and makespan while thermal limits are enforced through the temperature reward and action composition (Pivezhandi et al., 13 Jan 2026).
Learning follows a Dyna-Q-style off-policy Q-learning update,
5
implemented with D3QN agents to stabilize Q-learning through double networks and dueling value-advantage decomposition. Planning uses the learned profiler model 6 and derived thermal transitions to create imaginary samples. The reported effect is approximately 7 faster convergence than model-free RL, attributed to the use of synthetic trajectories in the replay process (Pivezhandi et al., 13 Jan 2026).
4. Environment modeling and LLM-based zero-shot semantics
A distinctive aspect of SubZeroCore is its use of LLM-extracted semantic features to characterize OpenMP programs without executing them. These features condition the environment model so that synthetic samples can be generated for unseen workloads, enabling zero-shot deployment on trained platforms. Tree-sitter-derived syntactic features and workload metadata are ingested in parallel. The extraction method is described as a zero-shot prompt that requests strict JSON with constrained values, while Tree-sitter provides syntactic features concurrently (Pivezhandi et al., 13 Jan 2026).
The 13 semantic features are:
- memory_access_pattern: 8
- spatial_locality: 9
- temporal_locality: 0
- cache_behavior_pattern: 1
- numa_sensitivity: 2
- algorithmic_complexity: 3
- dominant_operation: 4
- vectorization_potential: 5
- data_dependency_type: 6
- false_sharing_risk: 7
- load_balance_characteristic: 8
- parallelization_overhead: 9
- scalability_bottleneck: 0
These features are intended to capture algorithmic complexity, memory access behavior, parallel structure, synchronization, and scalability bottlenecks without execution. In conjunction with platform telemetry, they allow the environment model to produce imaginary experiences before a new program is run. This is the basis of the system’s zero-shot claim (Pivezhandi et al., 13 Jan 2026).
The regression models themselves are calibrated on IIO power telemetry, perf_event counters, and per-core thermal sensors. The profiler next-state model is written as
1
and the thermal model as
2
The reported characteristics are inference latency under 3 ms and more than 4 lower temperature-prediction MSE than prior heuristics. In this framework, the LLM is not the scheduler itself; it is a front-end feature extractor that conditions the regression models used for planning and synthetic data generation (Pivezhandi et al., 13 Jan 2026).
5. Runtime workflow, interfaces, and deployment mechanics
The runtime decision flow is specified in four stages. First, SubZeroCore performs one-time LLM semantic feature extraction, static parsing, and metadata collection. Second, it initializes the agents and environment models and loads cached platform calibrations. Third, at each decision point it observes 5, obtains 6 from the Temperature agent and 7 from the Profiler agent, composes these into a frequency vector over the top-8 cores and a binding decision, executes the workload phase, collects 9 and rewards, updates replay memory, and, when the planning threshold is reached, runs 0 synthetic rollouts using 1 and derived thermal transitions to update the Q-networks. Fourth, it repeats this process for subsequent decisions (Pivezhandi et al., 13 Jan 2026).
The implementation relies on standard Linux interfaces. DVFS control is exposed through cpufreq with scaling_max_freq, and per-core frequency setting is enabled by Linux kernel APIs. Task-to-core binding is realized through cpuset and CPU affinity in the OpenMP runtime, with examples including OMP_PLACES and OMP_PROC_BIND. Telemetry comes from perf_event counters for instructions, cycles, IPC, and cache references or misses, from Linux in-kernel IIO power interfaces such as in_power_input in sysfs, and from per-core thermal sensors (Pivezhandi et al., 13 Jan 2026).
Latency is divided into first-decision and subsequent-decision regimes. For a new benchmark, the first decision takes 2--3 s in total, comprising LLM API time of 4--5 s, Tree-sitter time of approximately 6 ms, and RL inference of approximately 7 ms. Subsequent decisions take approximately 8 ms because the semantic features are cached and no new LLM calls are required. The deployment notes further state that the Python prototype operates at this latency, whereas optimized inference in C++ with TensorRT is expected to reduce this to sub-9 ms, provided decisions are taken at phase boundaries or coarse-grain intervals to avoid jitter (Pivezhandi et al., 13 Jan 2026).
Safety and fallback behavior are explicit. Hard thermal limits are enforced through 0, reward penalties, and action clipping; cooling-off strategies include core rotation and frequency downscaling. A watchdog can switch to a safe governor such as Linux ondemand on anomalies, and failures or sensor anomalies can trigger degradation to ondemand, performance, or powersave governors. Offline edge scenarios are also contemplated: semantic features may be pre-extracted and stored locally, and LLM inference may be done offline to avoid runtime overhead (Pivezhandi et al., 13 Jan 2026).
6. Experimental evaluation and reported performance
SubZeroCore is evaluated across NVIDIA Jetson TX2, Jetson Orin NX, RubikPi, and Intel Core i7 platforms. The Jetson TX2 configuration is listed as 6 cores with 1A57 and 2Denver2, Jetson Orin NX as 3A78AE, RubikPi as 4Kryo 585, and the Intel Core i7 platform as 4 cores, 8th generation. Benchmarks include BOTS and PolybenchC, with representative programs such as FFT, Strassen, SparseLU, GEMM, stencils, and task-parallel DAGs. Baselines are Linux ondemand and heuristic or table-based profiling schemes such as exhaustive lookup generation. Metrics comprise energy in mJ, makespan in s, temperature in 5C, decision latency in ms, convergence speed in episodes, and prediction accuracy in MSE, 6, and MAPE (Pivezhandi et al., 13 Jan 2026).
Energy is measured as
7
with IIO sensor sampling at 8 ms. Thermal data come from per-core sensors, performance data from perf_event, and DVFS states from sysfs. Within this setup, the reported quantitative outcomes are as follows (Pivezhandi et al., 13 Jan 2026):
| Quantity | Reported result |
|---|---|
Energy efficiency vs Linux ondemand |
9 better |
Makespan vs Linux ondemand |
0 better |
| Convergence vs model-free RL | approximately 1 faster |
| First decision latency | 2--3 s |
| Subsequent decision latency | approximately 4 ms |
| First decision vs table-based profiling | 5 faster |
| Temperature-model accuracy | more than 6 lower MSE than prior heuristic |
| Environment-model inference latency | less than 7 ms |
A central comparative claim concerns profiling cost. Table-based profiling is described as requiring 8--9 hours per benchmark, whereas SubZeroCore reaches a first decision in 00--01 s and subsequent decisions in approximately 02 ms. The reported 03 first-decision improvement is therefore framed not merely as a latency figure but as the condition that makes runtime adaptation practical in dynamic embedded systems (Pivezhandi et al., 13 Jan 2026).
The benchmark outcomes also sharpen the conceptual distinction between SubZeroCore and utilization-only governors. Because the controller incorporates IPC, stalls, cache behavior, context switches, and semantic code features, it is designed to distinguish compute-bound from memory-bound regimes when selecting frequencies and active cores. This suggests that the reported performance gains arise not only from learning a better static policy but from using richer state variables than conventional governors (Pivezhandi et al., 13 Jan 2026).
7. Limitations, future directions, and nomenclatural disambiguation
Several limitations are stated directly. First, the one-time LLM extraction introduces an initial overhead of roughly 04--05 s and small API fees, though caching and offline batch extraction mitigate this cost. Second, the environment models must be trained per hardware platform; zero-shot cross-platform transfer is said to work but to benefit from few-shot fine-tuning for lower MAPE. Third, thermal sensors have latency and the regressors are imperfect, so safety constraints must incorporate conservative margins. Fourth, the system is tuned for OpenMP code, and tied tasks, irregular graphs, multi-file projects, preemption, and finer-grain scheduling can reduce predictability or interfere with affinity assumptions. Future work is described as extending the method to concurrent workloads, multi-resource scheduling, GPU offloading, and uncertainty-aware policies (Pivezhandi et al., 13 Jan 2026).
The name SubZeroCore is not unique across the literature. In one unrelated use, "SubZeroCore: A Submodular Approach with Zero Training for Coreset Selection" denotes a training-free coreset selection method that unifies coverage and density in a weighted facility-location objective and uses greedy maximization under the standard 06 approximation guarantee (Moser et al., 26 Sep 2025). A related but distinct line of work on unlabeled data uses the name ZCore for zero-shot coreset selection from foundation-model embeddings (Griffin et al., 2024). The term also appears as an internal label in a diffusion-personalization specification associated with "SubZero," where it denotes the combination of orthogonalized temporal aggregation, DSOC, and projector modules for subject-style-action composition without fine-tuning (Borse et al., 27 Feb 2025).
Other occurrences are metaphorical or mapped rather than nominally canonical. One text uses SubZeroCore to describe the millikelvin core of the CUORE cryostat, emphasizing a contiguous volume at about 07 mK in the context of rare-event physics (Ouellet, 2014). Another maps the term onto an Ozone-like core-level execution resource for zero timing leakage in modern microarchitectures (Aweke et al., 2017). A further usage treats it as a design target for a sub-kelvin electronic cooling module based on cascade NIS refrigeration (Nguyen et al., 2016). These occurrences are conceptually unrelated to the embedded-systems scheduler derived from ZeroDVFS, but they establish that the label has acquired a broader, domain-dependent usage.
In the embedded-systems sense, SubZeroCore denotes a controller that operationalizes zero-shot, LLM-guided core and frequency allocation through a hierarchical MARL scheduler, calibrated environment models, and semantic feature extraction. Its distinguishing claims are the elimination of workload-specific profiling at deployment, the decomposition of action selection into temperature-aware prioritization and profiler-driven frequency planning, and the combination of low-latency runtime decisions with reported gains of 08 in energy efficiency and 09 in makespan relative to Linux ondemand (Pivezhandi et al., 13 Jan 2026).