Zero Touch Predictive Orchestration: Automating Time-Series Models for the Cloud-Edge Continuum

Unknown

Conceptio › Archive › arXiv CS

arXiv CSopen access

Zero Touch Predictive Orchestration: Automating Time-Series Models for the Cloud-Edge Continuum

Unknown · 2026 · arxiv_cs

arXiv CS · Papers · License: Open Access · 2026

Open Source ↗Direct PDF ↓

distributedsystems protocols

networking, internet, protocols, distributed systems

Z ERO T OUCH P REDICTIVE O RCHESTRATION : AUTOMATING T IME -S ERIES M ODELS FOR THE C LOUD -E DGE C ONTINUUM

arXiv:2606.09787v1 [cs.LG] 8 Jun 2026

Abd Elghani Meliani Eurecom Campus SophiaTech, Biot, France [email protected]

Arora Sagar OpenAirInterface Campus SophiaTech, Biot, France [email protected]

Adlen Ksentini Eurecom Campus SophiaTech, Biot, France [email protected]

Raymond Knopp Eurecom Campus SophiaTech, Biot, France [email protected]

A BSTRACT The Cloud-Edge Continuum (CEC) enables latency-critical applications by distributing resources to the far edge, but its extreme volatility makes proactive Zero Touch Management via time-series forecasting essential. However, orchestrators face a severe "cold start" problem: newly discovered nodes lack the historical data required to train localized predictive models, while generalized models fail to capture unique hardware and microservice behaviors. To solve this, we propose a fully automated time-series prediction architecture driven by a novel data-mixing methodology. At the infrastructure level, we introduce a lightweight, technology-agnostic Resource Exposer (RE) that dynamically discovers nodes and continuously collects customizable telemetry (e.g., compute, network, energy). To overcome the sparsity of these initial local samples, our framework automatically merges them with TimeTrack [1]—our publicly available, high-resolution dataset collected at 45second intervals. This synergizes TimeTrack’s foundational, high-frequency temporal patterns with the precise calibration of the local node data. Processed through a Neural Architecture Search (NAS) engine, the system automatically generates highly accurate baseline models. Experimental results demonstrate that merging the target data with TimeTrack effectively mitigates the cold start challenge. This specific integration significantly improves forecasting accuracy—measured in Mean Squared Error (MSE), Mean Absolute Error (MAE), and Mean Absolute Percentage Error (MAPE)—and accelerates convergence compared to training on the sparse local samples alone, training solely on generic datasets, or mixing the target data with standard alternative datasets, establishing a robust foundation for continuous MLOps deployment. Keywords Cloud-Edge Continuum · Time-Series Forecasting · Zero Touch Management · Resource Orchestration · Neural Architecture Search

Introduction

Traditional centralized cloud computing has driven digital transformation for over a decade, offering virtually limitless computational power. However, as new classes of applications emerge—such as augmented and virtual reality, autonomous vehicles, Federated Learning, and real-time video analytics—the centralized model is increasingly bottlenecked. These modern workloads are highly sensitive to high latency, bandwidth limitations, and strict data-locality requirements, making a purely central deployment unfeasible. To address these limitations, the computing paradigm is rapidly shifting toward the Cloud-Edge Continuum (CEC) [2]. The CEC unlocks unprecedented capabilities. It allows compute-intensive tasks to benefit from the central cloud’s abundance, while enabling latency-critical services to execute locally at the network edge with near-zero latency. While the CEC provides immense architectural flexibility, it

A PREPRINT - J UNE 9, 2026

also introduces profound orchestration challenges. Unlike traditional cloud environments where resources are relatively static and managed centrally, the CEC is characterized by extreme volatility and heterogeneity. Edge servers and Far-edge devices frequently fluctuate in availability, joining or leaving the network within seconds due to mobility or battery constraints. In such dynamic environments, traditional reactive resource management fails. Waiting for a node to exhaust its capacity before scaling or migrating services inevitably degrades application performance and breaches Service Level Agreements (SLAs). Consequently, infrastructure providers must adopt proactive Zero Touch Management (ZTM) [3] techniques—such as predictive autoscaling and preemptive service migration [4] —to anticipate impending bottlenecks or operational anomalies, acting before degradation occurs. Implementing this proactive strategy inherently relies on machine learning, specifically time-series forecasting models (such as LSTMs, RNNs, and GRUs). However, these models exhibit a strict dependency on high-quality data. Because usage patterns, hardware characteristics, and microservice behaviors vary drastically across the heterogeneous CEC, a model trained solely on generic, pre-existing datasets cannot accurately predict performance on unseen infrastructure. Furthermore, manually collecting data and training a bespoke model for every unique machine type is unscalable and computationally prohibitive. To manage this distributed environment efficiently, the entire machine learning pipeline must be fully automated. To overcome this barrier, we propose an architecture that relies on lightweight, plugin-based Resource Exposer (RE) [5] at the local infrastructure level. This module dynamically discovers volatile local nodes and continuously collects small, real-time telemetry samples. Crucially, the mechanism is highly customizable; instead of being limited to standard compute metrics like CPU or memory utilization, it can capture any measurable localized indicator, such as node-level energy consumption, carbon footprint, thermal thresholds, and network latency. Ultimately, the RE functions as an automated, multi-purpose data pipeline for the target machine. While training a forecasting model exclusively on data from the specific target machine yields optimal performance, time-series models inherently require a substantial volume of historical data to achieve acceptable accuracy. Collecting a sufficient number of samples directly from a newly discovered source node requires a lengthy observation period, introducing an operational delay that contradicts the rapid, dynamic requirements of the CEC. To bypass this datacollection latency while still striving for localized accuracy, our architecture employs a strategic data-mixing approach. The system automatically merges the sparse, real-time target data collected by the Exposer with TimeTrack [1], a foundational time-series dataset we collected from an operational OpenAirInterface (OAI) [6] Kubernetes cluster used generally for running CI/CD workloads [7]. This combination is highly synergistic: TimeTrack provides the algorithms with the foundational structural knowledge—teaching the model the complex temporal mechanics of when a metric is likely to surge or drop—while the small batch of specific data from the target machine calibrates the model to predict the exact magnitudes and values unique to that local environment. While other public monitoring datasets exist, they are generally not intended for time-series model training due to coarse, five-minute collection intervals. In contrast, TimeTrack is a high-resolution dataset purpose-built for training, offering a wide variety of fine-grained compute, network, and operational metrics at 45-second intervals. Supported by the Shannon–Nyquist sampling theorem [8], this high frequency ensures the capture of transient behaviors, sudden bursts, and short-lived spikes that standard datasets inevitably smooth over. Because many developers treat AI as a black box, the prevailing approach for training Deep Neural Networks (DNNs)—including time-series models—remains a manual, trial-and-error process of testing multiple architectures to select the highest-performing design. To fully automate this tedious selection, our framework integrates Neural Architecture Search (NAS) [9] methods. NAS is an automated machine learning technique that algorithmically explores a predefined search space to engineer custom network topologies for a specific dataset. By evaluating candidate configurations automatically, it eliminates the need for manual architectural engineering. Feeding our mixed, high-resolution dataset into this NAS engine completely automates initial model generation. Experimental results demonstrate that models initialized through this pipeline achieve significantly better accuracy and converge much faster than standard baselines, providing a robust, deployment-ready foundation for continuous MLOps fine-tuning. In summary, the core contributions of this work are as follows: • An Automated Prediction Architecture and Validation: We propose an end-to-end ZTM framework that automates custom time-series model generation for diverse forecasting targets ranging from resource utilization to energy consumption. Experimental benchmarking demonstrates that models generated via our framework achieve superior accuracy—measured in Mean Squared Error (MSE), Mean Absolute Error (MAE), and Mean Absolute Percentage Error (MAPE)—and faster convergence compared to traditional baselines. • An Agnostic Resource Exposer (RE): A plugin-based module deployed within local infrastructures. It allows volatile nodes to be dynamically discovered and exposes highly customized telemetry (e.g., compute, network, or energy metrics) to fuel the automated predictive modeling pipeline. 2

A PREPRINT - J UNE 9, 2026

• The TimeTrack Dataset: A comprehensive, high-resolution time-series dataset featuring continuous computing and network monitoring at 45-second intervals, capturing the short-term dynamics necessary to teach structural forecasting patterns. The dataset is publicly available on Kaggle and Zenodo [10, 11], accumulating approximately 700 downloads in less than a year across both platforms. The remainder of this paper is structured as follows. Section 2 presents the motivation and background, using an edge deployment scenario to demonstrate the problem and justify the need for telemetry exposure and high-resolution baselines. Section 3 reviews related work across three domains—predictive orchestration, resource monitoring, and datasets—to contextualize our framework. Section 4 details the architecture, encompassing the Resource Exposer, TimeTrack dataset, and NAS-driven model generation pipeline. Section 5 presents a two-phase evaluation of the data acquisition layer’s footprint and the automated ML pipeline’s performance. Finally, Section 6 concludes the paper and outlines future research directions.

Motivation and Background

To better understand the necessity of our fully automated architecture, it is essential to first examine the practical challenges of deploying predictive models in the CEC. In this section, we present a real-world scenario from our previous work that highlights the severe limitations of relying on standard, coarse-grained datasets for proactive resource management, and demonstrates why dynamic data exposure and high-resolution baselines are strictly required. 2.1

The Generalization Challenge in Proactive Orchestration

In our previous work [3], we developed a proactive system to manage the lifecycle of stateful microservices. The core idea was straightforward but effective: when a machine could no longer provide sufficient resources to meet its Service Level Agreements (SLAs), the system needed to preemptively relocate the microservice to another host. To achieve this, we designed a resource forecasting model using an LSTM time-series architecture. The model took historical CPU and memory usage as input and predicted future resource demands. A high-level architecture of this approach is illustrated in Figure 1. For the initial training, we relied on the MaternaGWA-13 [12] dataset, which yielded promising accuracy on both the training and validation sets. Output: Resource Forecasting Central TimeSeries Predictor Model Inputs: Resource Usage

Monitoring

Infra-01

Infra-02

Infra-03

Figure 1: High-level architecture of the proactive resource forecasting system presented in [3]. However, when we deployed this solution in a more realistic Cloud-Edge Continuum environment, the results degraded significantly. The fundamental reason for this failure was data distribution shift: the resource usage patterns in the generic GWA Materna dataset differed drastically from those observed on the new, highly volatile target machines. Consequently, the trained models struggled to generalize. This creates a critical “cold-start” generalization problem: how to deploy an accurate predictive model on a newly discovered edge node without waiting weeks to collect a massive local historical dataset. To overcome this issue and deploy accurate models in highly heterogeneous CEC environments, three potential strategies can be considered: 1. Training a separate model from scratch for each machine type. While theoretically feasible, this is practically impossible in edge environments. It requires repeating the entire pipeline of manual data collection, cleaning, and training for every single node, resulting in unacceptable delays and massive computational overhead. 3

A PREPRINT - J UNE 9, 2026

2. Fine-tuning the central model with new machine data. This is more efficient than retraining from scratch but still requires manually collecting and preparing large amounts of target-specific data before the model becomes reliable enough for deployment. 3. Mixing data to overcome the cold-start phase. Training a baseline model on a high-quality general dataset, augmented with a small, real-time sample of data collected directly from the target machine. The third solution is the only viable approach for the dynamic nature of the CEC. However, executing this strategy automatically requires solving two distinct challenges: i) how to retrieve the local target data dynamically, and ii) how to ensure the general baseline dataset is rich enough to teach structural patterns. 2.2

The Need for Automated Local Exposure and High-Resolution Baselines

To fulfill the first requirement—dynamically gathering the "small portion of samples" from the target machine—the system requires a dedicated, automated collection mechanism. This directly motivates the development of our Resource Exposer (RE). Rather than relying on manual instrumentation, the RE acts as an agnostic plugin that automatically discovers new nodes and streams specific local telemetry (compute, network, or energy) back to the central pipeline. However, mixing this local data with a public dataset is only effective if the public dataset accurately represents the rapid fluctuations of modern cloud-native systems. Unfortunately, most public datasets [12, 13, 14, 15, 16] record metrics at coarse intervals, typically every 5 minutes. As illustrated in Figure 2, significant variations—such as microservice scaling events or CPU bursts—occur within these intervals and are completely missed by coarse sampling.

Short notcaptured pattern Captured Values

X T0

T0+5 mins

T0+10 mins

Figure 2: Example of critical short-term patterns that are smoothed over and lost due to coarse 5-minute data collection intervals. From a signal processing perspective, the Shannon–Nyquist sampling theorem [8] states that to preserve the information carried by a signal, it must be sampled at least twice its highest frequency component. Sampling cluster dynamics every 5 minutes corresponds to sampling far below the effective frequency of edge operations, resulting in structurally impoverished sequences that limit the ability of models to learn meaningful temporal dependencies [17, 18, 19]. Guided by these principles, we collected TimeTrack at a 45-second interval. This resolution provides a practical balance: it is dense enough to capture transient behaviors and supply informative sequences to time-series models, yet lightweight enough to avoid monitoring overhead. 2.3

The Proposed Automated Architecture

By combining the automated local data collection of the Resource Exposer with the high-resolution structural baseline of TimeTrack, we establish a fully automated forecasting system. To clarify the role of these contributions within the broader vision of Zero Touch Management, Figure 3 illustrates the end-to-end architecture we have built. The first layer (Data Acquisition) utilizes the Resource Exposer to automatically collect samples from the target infrastructure and merge them with TimeTrack. This combined dataset is then passed to the second layer, where a Neural Architecture Search (NAS) generates an optimized initial model architecture from a predefined search space. Our experimental results confirm that this automated synergy yields models that are significantly more accurate and faster to deploy compared to existing methodologies. 4

A PREPRINT - J UNE 9, 2026

Data Acquisition Layer TimeTrack

Machine Specific Samples

Neural Architecture Search Layer Search Space

Search Strategy

Evaluation Strategy

Model Factory Layer Hyper Params Optimization

Fine Tuning

Transfer Learning

First Deployment

Initial Model

Deployment MLOps Layer Deployment

Resource Exposer

Performance Monitoring

Resource Exposer

Retraining

ReDeployment

Enhanced Model

Resource Exposer

Figure 3: Overview of the proposed solution architecture for CEC environments. The first two layers (Data Acquisition via the Exposer, and NAS model generation) automatically combine local data with TimeTrack and are the primary focus of this work.

Related Work

To fully contextualize the contributions of our proposed ZTM framework, we categorize the related literature into three distinct domains: i) automated predictive orchestration, ii) distributed resource monitoring, and iii) telemetry datasets. 3.1

Automated Predictive Orchestration and MLOps

The automation of resource management in cloud and telecommunications environments has increasingly shifted from reactive, threshold-based heuristics to machine learning-driven proactive methods. Numerous studies have explored the use of Deep Learning architectures [20], such as LSTMs [21] and GRUs, to forecast resource usage and trigger proactive autoscaling or migration . However, the majority of these solutions assume a static environment where a model, once trained on a historical dataset, maintains its accuracy over time. More recent works have recognized the need for continuous adaptation, leading to the integration of Machine Learning Operations (MLOps) [22] pipelines in 5G and edge environments. These frameworks facilitate continuous learning by retraining models as new data arrives. Furthermore, techniques such as AutoMl [23] Neural Architecture Search (NAS) [9] and transfer learning have been utilized to automatically discover optimal model structures and adapt them to new tasks. Despite these advancements, existing automated orchestration frameworks fail to address the "cold-start" generalization problem inherent to the CEC. Current MLOps pipelines focus on managing models that are already deployed; they do not automate the critical initialization phase—specifically, how to intelligently mix 5

A PREPRINT - J UNE 9, 2026

high-resolution structural datasets with dynamic target telemetry to generate a deployment-ready baseline model for unseen, heterogeneous edge nodes. Our architecture bridges this exact gap. 3.2

Resource Monitoring and Exposure Systems

Building proactive models requires robust data collection mechanisms. Numerous approaches have been proposed for systems monitoring in distributed environments. One prominent example is the DECOR system [24], which utilizes a distributed method for resource monitoring, particularly in network-based applications like redundancy elimination and traffic sampling. By distributing monitoring tasks across various network nodes, DECOR avoids the bottlenecks typically associated with centralized controllers. Similarly, Dprof [25] presents a lightweight, distributed profiling system designed to trace Remote Procedural Calls (RPC) operations and identify performance bottlenecks. Dprof gathers and analyzes RPC traces from heterogeneous components, storing them in a distributed data store. While effective for debugging at the RPC level, Dprof focuses on system-level event profiling and lacks comprehensive infrastructure monitoring capabilities. A scalable monitoring framework introduced in [26] specifically tackles the challenges of monitoring 5G network slices, with an emphasis on resource isolation, multi-tenancy, and the integration of different technological domains (e.g., RAN and cloud). Recently, both industry and academia have been advocating for standardized resource exposure solutions to improve infrastructure-aware service deployment, as emphasized by proposals from the Internet Engineering Task Force (IETF) [27]. While we share the broader goal of improving resource management and service discovery, existing tools are often deeply coupled with specific orchestrators. We advance the state-of-the-art by introducing a unified, plugin-based Resource Exposer tailored for heterogeneous CEC systems, strictly separating resource exposure from service orchestration. 3.3

Cloud and Edge Telemetry Datasets Table 1: Comparison of TimeTrack with Related Datasets, C:Compute, N:Network, S:Storage Dataset Nb Of machines Collection Interval Duration Setup Detail Level Metrics [13] 12,500 5 min 29 days Virtual medium C [15] 4,000 5 min 8 days Virtual low C [12] 1,594 5 min 3 months Virtual medium C, N, S [14] 2,013,767 5 min 30 days Virtual low C [16] 2,695,548 5 min 30 days Virtual medium C TimeTrack 7 45 sec 30 Days Physical high C, N, S

The foundational training of any automated forecasting architecture relies heavily on the training data. Several publicly available datasets—such as Google Cluster Data 2011 [13], Alibaba Cluster Traces [15], Grid Workloads Archive GWA-T-13-Materna [12], and Azure Public Traces [14, 16]—provide valuable insights into resource utilization. However, as summarized in Table 1, these datasets possess limitations that reduce their efficacy for predictive modeling in modern edge environments. Many cover only short durations or focus exclusively on computing metrics, neglecting the network and storage performance data essential for comprehensive analysis. Furthermore, most related works rely on data collected in virtualized environments, where virtualization overhead can obscure true hardware performance. Most critically, existing datasets rely on coarse data collection intervals—almost universally 5 minutes. While sufficient for general historical monitoring, this sparsity is inadequate for time-series forecasting in dynamic microservice environments, as it fails to capture rapid fluctuations and transient system behaviors. In contrast, our TimeTrack dataset was collected directly from physical machines at a fine-grained 45-second interval. This high-resolution setup eliminates virtualization artifacts and captures the exact, real-world transient behaviors necessary to pre-train robust predictive models for the CEC.

Automated Predictive Orchestration Architecture

To address the “cold-start” generalization problem in heterogeneous CEC environments, we propose a fully automated time-series forecasting pipeline. This framework intelligently merges dynamic local telemetry with a high-resolution foundational dataset to automatically generate optimized predictive models. 4.1

End-to-End Pipeline Architecture

The core workflow of our proposed solution is illustrated in Figure 4. The architecture is built upon three primary pillars that operate sequentially to eliminate the need for manual model engineering: 6

A PREPRINT - J UNE 9, 2026

1. System Discovery and Target Exposure: The pipeline begins with a Discovery Phase, which automatically identifies newly available physical or virtual nodes and registers the specific metrics they are capable of providing (e.g., CPU, memory, energy type). Once discovered, the Resource Exposer (RE) extracts real-time, localized telemetry from the target environment. 2. Data Mixing and Foundational Baseline: Because the initial telemetry gathered from a new target node is too sparse to train an accurate neural network from scratch, it is merged with TimeTrack, our pre-collected, high-resolution dataset. TimeTrack acts as the structural baseline, teaching the model the fundamental temporal mechanics of system fluctuations. 3. NAS-Driven Model Generation: The enriched, mixed dataset is fed into an automated NAS engine. The NAS explores various time-series architectures to optimize for forecasting accuracy (MSE, MAE, MAPE), outputting a deployment-ready model tailored specifically to the newly discovered edge node.

Figure 4: End-to-end architecture of the automated forecasting pipeline, illustrating the flow from System Discovery and the Resource Exposer, through Data Mixing with TimeTrack, to NAS Model Generation. 4.2

Dynamic Data Acquisition: The Resource Exposer Framework

The dynamic data acquisition layer relies on our novel, lightweight Resource Exposure framework. Deployed on target clusters, the RE is responsible for collecting real-time local resource usage and exposing it via a northbound API to the central ML pipeline.

Edge Collector

Caching Exposer API

Collector plugin

Cloud

Metric source

RFAC NBI

Local Dns

Figure 5: The lower-level architecture of the Resource Exposer, illustrating the plugin-based data collection and message broker integration. As illustrated in Figure 5, to handle the immense diversity of monitoring solutions and infrastructure types in the CEC, the RE is built upon a gRPC plugin-based architecture. These plugins serve as intermediaries between the data source (e.g., Prometheus [28], Nagios [29], Nvidia GPU exporters ... etc) and the central collector. This design ensures that the RE is completely agnostic and exceptionally customizable. It can be configured to expose any measurable target, 7

A PREPRINT - J UNE 9, 2026

ranging from standard computing resources (CPU, GPU, memory, storage) and network data (throughput, packet loss, latency) to infrastructure characteristics and energy consumption metrics. To ensure consistency across these diverse nodes, the RE employs a unified data format. Regardless of the underlying hardware or the specific plugins used, the framework normalizes all metrics into a structured, standard response. This uniformity is crucial for automated machine learning, as it allows the NAS engine to ingest data from wildly different infrastructures without requiring manual data-cleaning interventions. The internal interaction workflow of the framework is designed for efficiency and responsiveness. As detailed in Figure 6, the operational lifecycle consists of four key steps: Metric Source

Plugin

Collector

Broker

RE API

Discovery API

Local DNS

1 2

4 Discovery components

Exposer components

Runs Inside the RO

Runs on every cluster

Figure 6: Interaction workflow between the different framework components, highlighting registration, continuous collection, exposure, and memory management. 1. Exposer Registration: When a new RE is deployed, it uses a Local DNS system to self-register with the centralized Discovery Module. This decentralized method allows the system to scale flexibly, tracking nodes as they dynamically join or leave the network. 2. Data Collection: The internal collector component periodically accesses source metrics via the plugins and temporarily stores them in a lightweight message broker (e.g., RabbitMQ, Kafka, Redis). 3. Data Exposure: The Discovery Module requests specific information, prompting the RE to retrieve the latest metrics from the broker and expose them. This short-term caching mechanism ensures that the ML pipeline has instantaneous access to near real-time data under peak conditions. 4. Broker Purge: To maintain optimal memory usage on constrained edge devices, the RE automatically purges the broker if the API remains unused for a defined period, preventing unnecessary data accumulation. 4.3

Foundational Baseline: The TimeTrack Dataset

While the RE calibrates the model with real-time local constraints, the ML algorithms require a dense structural baseline to learn complex temporal dependencies. This is provided by TimeTrack, a high-resolution dataset collected over a 30-day period. We provide the following overview of its environment, structure, and key analytical patterns to assist researchers who may wish to utilize the dataset independently for their own machine learning and forecasting tasks. For a more exhaustive system-level analysis of the collected metrics, we refer the reader to the original dataset paper [1]. 4.3.1

Environment and Data Structure

TimeTrack was collected from an OpenAirInterface (OAI) testing cluster used for CI/CD pipelines of 5G components (e.g., gNB, UE, and CN). The physical cluster comprises seven machines equipped with a total of 437.5 GB of RAM, 8

A PREPRINT - J UNE 9, 2026

236 CPU cores, 1800 GB of SSD storage, and 38 physical network interfaces. Utilizing the same RE plugin mechanism described above interfacing with Prometheus, data was collected at highly granular **45-second intervals**. The distribution of resources across the machines is detailed in Table 2. Table 2: Resource Distribution Across the OAI Cluster Machines Machine (No) 1 2 3 4 5 6 7

Cores 36 48 36 36 24 36 20

RAM (GB) 62.5 62.5 62.5 62.5 62.5 62.5 62.5

Disk (GB) 278.37 222.50 278.37 278.37 222.50 278.37 222.50

Physical IF (No) 4 6 6 4 6 6 6

The dataset is available online [11], [10] consists of four comprehensive traces: • Compute Metrics: Available and used memory, average CPU consumption, and read/write disk throughputs at both cluster and machine levels. • CPU Core Utilization: Granular availability and utilization tracking for each of the 236 individual CPU cores. • Network Latency Metrics: Minimum, maximum, average, and mean deviation (mdev) of RTT, alongside jitter measurements. • Network Interface Metrics: Dropped packets, error rates, and transmitted/received throughput for physical interfaces. 4.3.2

Structural Analysis and ML Applicability

To validate TimeTrack’s utility as a structural training baseline, we analyzed its temporal patterns and metric correlations. Figure 7 presents the correlation matrix for the compute metrics. 1.00

0.75

0.50

0.25

0.00

0.25

0.50

0.75

1.00

M07 DWT

M06 DWT

M05 DWT

M04 DWT

M03 DWT

M02 DWT

M07 DRT

M01 DWT

M06 DRT

M05 DRT

M04 DRT

M03 DRT

M02 DRT

M07 CF

M01 DRT

M06 CF

M05 CF

M04 CF

M03 CF

M02 CF

M01 CF

M07 CU

M06 CU

M05 CU

M04 CU

M03 CU

M02 CU

M01 CU

M07 UM

M06 UM

M05 UM

M04 UM

M03 UM

M02 UM

M07 AM

M01 UM

M06 AM

M05 AM

M04 AM

M03 AM

M02 AM

M01 AM

M01 AM 1.00 0.15 0.47 0.57 0.01 0.31 0.29 -0.99 -0.15 -0.48 -0.57 -0.01 -0.31 -0.29 -0.53 -0.01 -0.39 -0.31 -0.00 -0.10 -0.04 0.53 0.01 0.39 0.31 0.00 0.10 0.04 -0.01 0.00 -0.05 -0.09 -0.01 -0.04 -0.01 -0.07 -0.01 -0.01 -0.07 -0.01 -0.04 -0.01 M02 AM 0.15 1.00 0.06 0.10 0.12 0.38 0.52 -0.15 -1.00 -0.07 -0.08 -0.12 -0.38 -0.52 -0.06 -0.09 0.01 -0.06 0.00 0.05 -0.09 0.06 0.09 -0.01 0.06 -0.01 -0.05 0.08 0.25 0.00 0.01 -0.03 0.00 -0.02 0.00 -0.06 -0.02 0.04 -0.10 -0.01 -0.02 -0.00 M03 AM 0.47 0.06 1.00 0.32 0.06 0.08 0.04 -0.47 -0.06 -0.93 -0.31 -0.06 -0.07 -0.04 -0.15 -0.01 -0.65 -0.10 -0.02 -0.10 -0.01 0.15 0.01 0.65 0.10 0.03 0.10 0.01 0.04 0.00 -0.07 0.00 0.00 -0.04 0.00 0.00 0.00 -0.05 0.01 -0.01 -0.04 -0.00 M04 AM 0.57 0.10 0.32 1.00 0.04 0.10 0.11 -0.57 -0.10 -0.32 -0.96 -0.04 -0.10 -0.11 -0.74 -0.01 -0.23 -0.74 -0.01 -0.07 -0.02 0.74 0.01 0.23 0.74 0.00 0.07 0.02 0.05 0.00 -0.02 -0.26 -0.00 -0.03 -0.01 -0.10 -0.00 0.02 -0.21 -0.01 -0.03 -0.00 M05 AM 0.01 0.12 0.06 0.04 1.00 -0.22 0.07 -0.00 -0.12 -0.08 -0.04 -1.00 0.22 -0.07 -0.07 0.02 -0.12 -0.07 -0.18 -0.02 -0.03 0.07 -0.02 0.12 0.07 0.17 0.02 0.03 -0.18 -0.01 -0.04 -0.04 -0.01 -0.03 0.00 -0.02 0.02 -0.13 -0.06 -0.01 -0.02 -0.00 M06 AM 0.31 0.38 0.08 0.10 -0.22 1.00 0.67 -0.31 -0.38 -0.08 -0.08 0.22 -1.00 -0.67 -0.02 -0.01 -0.02 -0.04 0.08 -0.06 -0.06 0.01 0.01 0.02 0.04 -0.09 0.06 0.06 0.08 -0.01 0.00 -0.01 -0.01 -0.02 -0.01 0.02 -0.04 0.02 -0.06 -0.01 -0.02 -0.02 M07 AM 0.29 0.52 0.04 0.11 0.07 0.67 1.00 -0.29 -0.52 -0.05 -0.09 -0.07 -0.67 -1.00 -0.04 -0.02 -0.06 -0.08 0.03 -0.03 -0.14 0.04 0.02 0.07 0.08 -0.04 0.03 0.14 0.08 -0.00 -0.02 -0.02 -0.01 -0.02 -0.01 -0.01 -0.04 -0.03 -0.09 -0.02 -0.02 -0.03 M01 UM -0.99 -0.15 -0.47 -0.57 -0.00 -0.31 -0.29 1.00 0.15 0.48 0.56 0.00 0.31 0.29 0.53 0.01 0.39 0.31 0.00 0.10 0.04 -0.53 -0.01 -0.39 -0.31 0.00 -0.09 -0.04 0.01 -0.00 0.05 0.09 0.01 0.04 0.01 0.07 0.01 0.01 0.07 0.01 0.04 0.01 M02 UM -0.15 -1.00 -0.06 -0.10 -0.12 -0.38 -0.52 0.15 1.00 0.07 0.08 0.12 0.38 0.52 0.06 0.09 -0.01 0.06 -0.00 -0.05 0.09 -0.06 -0.09 0.01 -0.06 0.01 0.05 -0.08 -0.25 -0.00 -0.01 0.03 -0.00 0.02 -0.00 0.06 0.02 -0.04 0.10 0.01 0.02 0.01 M03 UM -0.48 -0.07 -0.93 -0.32 -0.08 -0.08 -0.05 0.48 0.07 1.00 0.32 0.08 0.08 0.05 0.15 0.01 0.65 0.10 0.02 0.10 0.01 -0.15 -0.01 -0.64 -0.10 -0.03 -0.10 -0.01 -0.03 -0.00 0.06 -0.00 -0.00 0.04 -0.00 -0.00 -0.00 0.05 -0.01 0.01 0.05 0.00 M04 UM -0.57 -0.08 -0.31 -0.96 -0.04 -0.08 -0.09 0.56 0.08 0.32 1.00 0.04 0.08 0.09 0.73 0.01 0.23 0.74 0.01 0.07 0.02 -0.73 -0.01 -0.23 -0.74 -0.00 -0.07 -0.02 -0.04 -0.00 0.03 0.26 0.00 0.03 0.01 0.10 -0.00 -0.02 0.21 0.01 0.03 0.00 M05 UM -0.01 -0.12 -0.06 -0.04 -1.00 0.22 -0.07 0.00 0.12 0.08 0.04 1.00 -0.22 0.07 0.07 -0.02 0.12 0.07 0.18 0.02 0.03 -0.07 0.02 -0.12 -0.07 -0.17 -0.02 -0.03 0.18 0.01 0.04 0.04 0.01 0.03 -0.00 0.02 -0.02 0.13 0.06 0.01 0.02 0.00 M06 UM -0.31 -0.38 -0.07 -0.10 0.22 -1.00 -0.67 0.31 0.38 0.08 0.08 -0.22 1.00 0.67 0.01 0.01 0.02 0.04 -0.08 0.05 0.06 -0.01 -0.01 -0.02 -0.04 0.09 -0.05 -0.06 -0.09 0.01 -0.00 0.01 0.01 0.02 0.01 -0.02 0.04 -0.02 0.06 0.01 0.02 0.02 M07 UM -0.29 -0.52 -0.04 -0.11 -0.07 -0.67 -1.00 0.29 0.52 0.05 0.09 0.07 0.67 1.00 0.04 0.02 0.06 0.08 -0.03 0.03 0.14 -0.04 -0.02 -0.07 -0.08 0.04 -0.03 -0.14 -0.08 0.01 0.02 0.02 0.01 0.02 0.01 0.01 0.04 0.03 0.09 0.02 0.02 0.03 M01 CU -0.53 -0.06 -0.15 -0.74 -0.07 -0.02 -0.04 0.53 0.06 0.15 0.73 0.07 0.01 0.04 1.00 0.00 0.13 0.70 0.02 0.06 0.01 -1.00 -0.00 -0.12 -0.70 -0.02 -0.06 -0.01 -0.03 -0.00 0.02 0.29 -0.00 0.03 0.01 0.20 -0.00 -0.01 0.18 0.00 0.04 0.00 M02 CU -0.01 -0.09 -0.01 -0.01 0.02 -0.01 -0.02 0.01 0.09 0.01 0.01 -0.02 0.01 0.02 0.00 1.00 0.00 0.00 0.33 0.01 0.39 -0.00 -0.98 -0.00 -0.00 -0.33 -0.01 -0.39 -0.02 0.03 0.01 0.02 -0.00 0.03 0.03 0.02 0.14 0.01 0.02 0.01 0.02 0.02 M03 CU -0.39 0.01 -0.65 -0.23 -0.12 -0.02 -0.06 0.39 -0.01 0.65 0.23 0.12 0.02 0.06 0.13 0.00 1.00 0.09 0.03 0.10 0.03 -0.12 -0.00 -0.97 -0.09 -0.04 -0.09 -0.03 0.01 0.00 0.13 -0.00 -0.00 0.04 -0.00 0.02 0.00 0.39 -0.01 0.01 0.03 0.01 M04 CU -0.31 -0.06 -0.10 -0.74 -0.07 -0.04 -0.08 0.31 0.06 0.10 0.74 0.07 0.04 0.08 0.70 0.00 0.09 1.00 0.01 0.05 0.01 -0.70 -0.00 -0.09 -0.99 -0.01 -0.05 -0.01 -0.03 -0.00 0.01 0.27 -0.00 0.03 0.01 0.18 -0.00 -0.03 0.32 0.01 0.03 0.00 M05 CU -0.00 0.00 -0.02 -0.01 -0.18 0.08 0.03 0.00 -0.00 0.02 0.01 0.18 -0.08 -0.03 0.02 0.33 0.03 0.01 1.00 0.03 0.28 -0.02 -0.33 -0.04 -0.01 -0.80 -0.03 -0.28 0.06 0.01 0.02 0.04 0.02 0.05 0.01 0.06 0.02 0.05 0.04 0.05 0.03 0.01 M06 CU -0.10 0.05 -0.10 -0.07 -0.02 -0.06 -0.03 0.10 -0.05 0.10 0.07 0.02 0.05 0.03 0.06 0.01 0.10 0.05 0.03 1.00 0.02 -0.06 -0.01 -0.09 -0.05 -0.03 -1.00 -0.02 -0.01 -0.00 0.03 0.05 -0.00 0.13 0.01 0.03 0.00 0.06 0.03 0.01 0.13 0.01 M07 CU -0.04 -0.09 -0.01 -0.02 -0.03 -0.06 -0.14 0.04 0.09 0.01 0.02 0.03 0.06 0.14 0.01 0.39 0.03 0.01 0.28 0.02 1.00 -0.01 -0.40 -0.03 -0.01 -0.28 -0.02 -0.98 -0.01 0.02 0.02 0.02 0.00 0.02 0.07 0.03 0.04 0.04 0.03 0.01 0.02 0.11 M01 CF 0.53 0.06 0.15 0.74 0.07 0.01 0.04 -0.53 -0.06 -0.15 -0.73 -0.07 -0.01 -0.04 -1.00 -0.00 -0.12 -0.70 -0.02 -0.06 -0.01 1.00 0.00 0.12 0.70 0.02 0.06 0.01 0.03 0.00 -0.02 -0.29 0.00 -0.03 -0.01 -0.20 0.00 0.01 -0.18 -0.00 -0.04 0.00 M02 CF 0.01 0.09 0.01 0.01 -0.02 0.01 0.02 -0.01 -0.09 -0.01 -0.01 0.02 -0.01 -0.02 -0.00 -0.98 -0.00 -0.00 -0.33 -0.01 -0.40 0.00 1.00 0.00 0.00 0.33 0.01 0.39 0.02 -0.03 -0.02 -0.02 0.00 -0.03 -0.03 -0.02 -0.14 -0.01 -0.02 -0.01 -0.02 -0.02 M03 CF 0.39 -0.01 0.65 0.23 0.12 0.02 0.07 -0.39 0.01 -0.64 -0.23 -0.12 -0.02 -0.07 -0.12 -0.00 -0.97 -0.09 -0.04 -0.09 -0.03 0.12 0.00 1.00 0.09 0.04 0.09 0.03 -0.01 -0.00 -0.14 0.00 0.00 -0.04 0.00 -0.02 -0.00 -0.39 0.01 -0.01 -0.03 -0.01 M04 CF 0.31 0.06 0.10 0.74 0.07 0.04 0.08 -0.31 -0.06 -0.10 -0.74 -0.07 -0.04 -0.08 -0.70 -0.00 -0.09 -0.99 -0.01 -0.05 -0.01 0.70 0.00 0.09 1.00 0.01 0.05 0.01 0.03 0.00 -0.01 -0.27 0.00 -0.03 -0.01 -0.18 0.00 0.03 -0.32 -0.01 -0.03 -0.00 M05 CF 0.00 -0.01 0.03 0.00 0.17 -0.09 -0.04 0.00 0.01 -0.03 -0.00 -0.17 0.09 0.04 -0.02 -0.33 -0.04 -0.01 -0.80 -0.03 -0.28 0.02 0.33 0.04 0.01 1.00 0.03 0.29 -0.05 -0.02 -0.02 -0.04 -0.02 -0.04 -0.02 -0.06 -0.02 -0.05 -0.04 -0.05 -0.04 -0.01 M06 CF 0.10 -0.05 0.10 0.07 0.02 0.06 0.03 -0.09 0.05 -0.10 -0.07 -0.02 -0.05 -0.03 -0.06 -0.01 -0.09 -0.05 -0.03 -1.00 -0.02 0.06 0.01 0.09 0.05 0.03 1.00 0.02 0.01 0.00 -0.03 -0.05 0.00 -0.13 -0.01 -0.03 -0.00 -0.06 -0.03 -0.01 -0.13 -0.01 M07 CF 0.04 0.08 0.01 0.02 0.03 0.06 0.14 -0.04 -0.08 -0.01 -0.02 -0.03 -0.06 -0.14 -0.01 -0.39 -0.03 -0.01 -0.28 -0.02 -0.98 0.01 0.39 0.03 0.01 0.29 0.02 1.00 0.01 -0.02 -0.02 -0.02 -0.00 -0.03 -0.07 -0.03 -0.04 -0.04 -0.03 -0.01 -0.02 -0.11 M01 DRT -0.01 0.25 0.04 0.05 -0.18 0.08 0.08 0.01 -0.25 -0.03 -0.04 0.18 -0.09 -0.08 -0.03 -0.02 0.01 -0.03 0.06 -0.01 -0.01 0.03 0.02 -0.01 0.03 -0.05 0.01 0.01 1.00 -0.00 0.03 -0.02 -0.01 -0.01 -0.01 -0.04 -0.01 0.02 -0.04 -0.00 -0.00 -0.01 M02 DRT 0.00 0.00 0.00 0.00 -0.01 -0.01 -0.00 -0.00 -0.00 -0.00 -0.00 0.01 0.01 0.01 -0.00 0.03 0.00 -0.00 0.01 -0.00 0.02 0.00 -0.03 -0.00 0.00 -0.02 0.00 -0.02 -0.00 1.00 0.01 0.00 0.01 0.02 0.06 0.00 0.03 0.01 0.00 0.00 -0.00 0.00 M03 DRT -0.05 0.01 -0.07 -0.02 -0.04 0.00 -0.02 0.05 -0.01 0.06 0.03 0.04 -0.00 0.02 0.02 0.01 0.13 0.01 0.02 0.03 0.02 -0.02 -0.02 -0.14 -0.01 -0.02 -0.03 -0.02 0.03 0.01 1.00 0.03 0.00 0.05 0.01 0.03 0.00 0.07 -0.00 0.00 0.01 0.01 M04 DRT -0.09 -0.03 0.00 -0.26 -0.04 -0.01 -0.02 0.09 0.03 -0.00 0.26 0.04 0.01 0.02 0.29 0.02 -0.00 0.27 0.04 0.05 0.02 -0.29 -0.02 0.00 -0.27 -0.04 -0.05 -0.02 -0.02 0.00 0.03 1.00 -0.00 0.11 -0.00 0.16 0.00 -0.01 0.23 0.00 0.03 -0.00 M05 DRT -0.01 0.00 0.00 -0.00 -0.01 -0.01 -0.01 0.01 -0.00 -0.00 0.00 0.01 0.01 0.01 -0.00 -0.00 -0.00 -0.00 0.02 -0.00 0.00 0.00 0.00 0.00 0.00 -0.02 0.00 -0.00 -0.01 0.01 0.00 -0.00 1.00 0.01 0.05 -0.00 0.01 -0.00 -0.00 0.01 -0.00 0.00 M06 DRT -0.04 -0.02 -0.04 -0.03 -0.03 -0.02 -0.02 0.04 0.02 0.04 0.03 0.03 0.02 0.02 0.03 0.03 0.04 0.03 0.05 0.13 0.02 -0.03 -0.03 -0.04 -0.03 -0.04 -0.13 -0.03 -0.01 0.02 0.05 0.11 0.01 1.00 0.00 0.03 0.01 0.03 0.01 0.01 0.16 0.00 M07 DRT -0.01 0.00 0.00 -0.01 0.00 -0.01 -0.01 0.01 -0.00 -0.00 0.01 -0.00 0.01 0.01 0.01 0.03 -0.00 0.01 0.01 0.01 0.07 -0.01 -0.03 0.00 -0.01 -0.02 -0.01 -0.07 -0.01 0.06 0.01 -0.00 0.05 0.00 1.00 0.00 0.00 -0.00 -0.00 0.01 -0.00 0.07 M01 DWT -0.07 -0.06 0.00 -0.10 -0.02 0.02 -0.01 0.07 0.06 -0.00 0.10 0.02 -0.02 0.01 0.20 0.02 0.02 0.18 0.06 0.03 0.03 -0.20 -0.02 -0.02 -0.18 -0.06 -0.03 -0.03 -0.04 0.00 0.03 0.16 -0.00 0.03 0.00 1.00 0.01 0.04 0.24 0.01 0.03 -0.00 M02 DWT -0.01 -0.02 0.00 -0.00 0.02 -0.04 -0.04 0.01 0.02 -0.00 -0.00 -0.02 0.04 0.04 -0.00 0.14 0.00 -0.00 0.02 0.00 0.04 0.00 -0.14 -0.00 0.00 -0.02 -0.00 -0.04 -0.01 0.03 0.00 0.00 0.01 0.01 0.00 0.01 1.00 0.00 0.01 0.01 0.00 0.00 M03 DWT -0.01 0.04 -0.05 0.02 -0.13 0.02 -0.03 0.01 -0.04 0.05 -0.02 0.13 -0.02 0.03 -0.01 0.01 0.39 -0.03 0.05 0.06 0.04 0.01 -0.01 -0.39 0.03 -0.05 -0.06 -0.04 0.02 0.01 0.07 -0.01 -0.00 0.03 -0.00 0.04 0.00 1.00 -0.03 0.00 0.00 0.00 M04 DWT -0.07 -0.10 0.01 -0.21 -0.06 -0.06 -0.09 0.07 0.10 -0.01 0.21 0.06 0.06 0.09 0.18 0.02 -0.01 0.32 0.04 0.03 0.03 -0.18 -0.02 0.01 -0.32 -0.04 -0.03 -0.03 -0.04 0.00 -0.00 0.23 -0.00 0.01 -0.00 0.24 0.01 -0.03 1.00 0.00 0.01 0.00 M05 DWT -0.01 -0.01 -0.01 -0.01 -0.01 -0.01 -0.02 0.01 0.01 0.01 0.01 0.01 0.01 0.02 0.00 0.01 0.01 0.01 0.05 0.01 0.01 -0.00 -0.01 -0.01 -0.01 -0.05 -0.01 -0.01 -0.00 0.00 0.00 0.00 0.01 0.01 0.01 0.01 0.01 0.00 0.00 1.00 0.01 0.01 M06 DWT -0.04 -0.02 -0.04 -0.03 -0.02 -0.02 -0.02 0.04 0.02 0.05 0.03 0.02 0.02 0.02 0.04 0.02 0.03 0.03 0.03 0.13 0.02 -0.04 -0.02 -0.03 -0.03 -0.04 -0.13 -0.02 -0.00 -0.00 0.01 0.03 -0.00 0.16 -0.00 0.03 0.00 0.00 0.01 0.01 1.00 0.00 M07 DWT -0.01 -0.00 -0.00 -0.00 -0.00 -0.02 -0.03 0.01 0.01 0.00 0.00 0.00 0.02 0.03 0.00 0.02 0.01 0.00 0.01 0.01 0.11 0.00 -0.02 -0.01 -0.00 -0.01 -0.01 -0.11 -0.01 0.00 0.01 -0.00 0.00 0.00 0.07 -0.00 0.00 0.00 0.00 0.01 0.00 1.00

Figure 7: Correlation matrix demonstrating relationships between CPU usage (CU), memory usage (UM), disk throughput (DRT/DWT), and disk usage (UD). The analysis reveals a notable positive correlation between CPU usage and memory consumption across several machines (e.g., 0.65 for machine 03, and 0.74 for machine 04). This indicates that the dataset successfully captures the coupled nature of CPU- and memory-intensive workloads, providing ML models with realistic multivariate relationships. Furthermore, forecasting models rely heavily on recognizing cyclical behavior. Figure 8 illustrates memory utilization across the cluster over a standard week. 9

A PREPRINT - J UNE 9, 2026

Monday

1e10

2 00h

02h

04h

06h

08h

10h

12h

14h

16h

18h

20h

22h

14h

16h

18h

20h

22h

14h

16h

18h

20h

22h

14h

16h

18h

20h

22h

14h

16h

18h

20h

22h

14h

16h

18h

20h

22h

14h

16h

18h

20h

22h

Tuesday

1e10

2 00h

02h

04h

06h

08h

10h

12h

Wednesday

1e10

2 00h

02h

04h

06h

08h

10h

12h

Thursday

1e10

2 00h

02h

04h

06h

08h

10h

12h

Friday

1e10

2 00h

02h

04h

06h

08h

10h

12h

Saturday

1e10

2 00h

02h

04h

06h

08h

10h

12h

Sunday

1e10

2 00h

02h

04h

06h

08h

10h

12h

Time of Day

Figure 8: Memory utilization across the cluster over a week, showing distinct usage spikes during weekdays versus low, stable background utilization over the weekend.

A PREPRINT - J UNE 9, 2026

The temporal patterns are highly distinct: during the weekend, memory usage remains low and stable, reflecting an idle operational state. Conversely, during weekdays, utilization rises significantly during working hours, indicating high demand from active workloads, before returning to a stable baseline. This regular daily and weekly cycle provides highly predictable demand patterns. By feeding these cyclical patterns—along with the fine-grained 45-second transient behaviors—into our automated NAS pipeline, the resulting models inherit a robust structural understanding of infrastructure dynamics, allowing them to rapidly adapt to the new environments exposed by the RE.

Evaluation and Results

To comprehensively assess the performance of our automated predictive orchestration framework, we divide our evaluation into two main phases. First, we profile the Resource Exposer to ensure it operates efficiently on low-resource edge nodes without inducing monitoring overhead. Second, we evaluate the end-to-end Machine Learning pipeline, demonstrating how the integration of TimeTrack improves NAS efficiency, model accuracy, and post-deployment computational constraints compared to widely used public datasets. 5.1

Profiling the Resource Exposer on Edge Hardware

The RE must operate continuously on every computing node within the Cloud-Edge Continuum. Therefore, it is strictly required to have a minimal resource footprint. To validate its edge-readiness, we deployed the RE on a low-resource Raspberry Pi 4 model (Broadcom BCM2711 quad-core Cortex-A72 64-bit CPU at 1.5 GHz, 8 GB RAM) running Ubuntu 22.04 and a standard containerd-based edge runtime. Redis Stack was utilized as the local message broker. Because the RE is highly sensitive to the frequency of data extraction, we measured the CPU and memory consumption of both the exposer and the broker over a one-week period, varying the data collection interval from a standard 20 seconds down to an extreme 1-second interval.

Figure 9: CPU consumption (left) and memory usage (right) of the Resource Exposer and the internal broker across varying data collection intervals. As illustrated in Figure 9 (left), even under the most aggressive 1-second collection scenario, both the exposer and the broker consume less than 0.04 CPU cores. Figure 9 (right) reveals that the exposer’s memory footprint remains exceptionally stable regardless of the collection frequency. While the broker exhibits a slight increase in memory usage as the interval tightens to 1 second, it peaks at merely 8.51 MB. This extreme memory efficiency is a direct result of the broker purge mechanism detailed in Section 4.2. Finally, we evaluated the response latency of the RE’s northbound API. We benchmarked it against Prometheus [28], a standard time-series monitoring toolkit, over 50 trials with varying concurrent request loads. As depicted in Figure 10, while response times for both systems increase under heavy concurrency, the Prometheus API takes approximately twice as long to respond. This validates our architectural choice to utilize a lightweight message broker for short-term caching, allowing the RE to serve near real-time telemetry significantly faster than solutions relying on heavy Time Series Databases (TSDBs). 5.2

Automated CPU Model Generation and NAS Evaluation

Having established the lightweight footprint of the data acquisition layer, we now evaluate the core automated model generation pipeline. To contextualize this evaluation, we leverage Neural Architecture Search, an automated subfield of machine learning designed to eliminate human bias and the tedious trial-and-error typically associated with manual 11

A PREPRINT - J UNE 9, 2026

Figure 10: Comparison of API response times under concurrent request loads, demonstrating the efficiency of the RE’s short-term caching versus Prometheus.

network design. A NAS framework is fundamentally governed by two core components: the search space, which defines the bounded universe of all valid network configurations, layers, and hyperparameters available for selection; and the search strategy, which dictates the optimization algorithm used to navigate and sample from this space to discover high-performing architectures. The primary objective of this subsection is to determine whether mixing a target node’s sparse local data with a high-resolution structural baseline (TimeTrack, 45s interval) yields superior NAS convergence and predictive accuracy compared to standard, coarse-grained public datasets. For the purpose of this evaluation, we utilize CPU usage as our representative target metric. While CPU utilization frequently exhibits strong correlations with other system parameters, such as memory consumption as shown in figure 7, we intentionally isolate CPU data to maintain a controlled experimental environment. The objective of this specific experiment is not to engineer an exhaustive, production-ready multivariate predictor, but rather to strictly isolate and compare the models’ structural accuracy and convergence behavior across different underlying datasets. For comparative benchmarking, we selected the Grid Workloads Archive Materna-13 (GWA-M13) [12] and the Alibaba Cluster Traces v2018 (ACTv2018) [15], both of which rely on 5-minute sampling intervals. To power the automated pipeline, we utilized Microsoft NNI [30] as the underlying NAS engine. The architectural search space (detailed in Table 3) was intentionally designed to be highly heterogeneous, encompassing Multi-Layer Perceptrons (MLP), standard Recurrent Neural Networks (RNN), Long Short-Term Memory (LSTM) networks, Gated Recurrent Units (GRU), Convolutional Neural Networks (CNN), Temporal Convolutional Networks (TCN), and Transformers. This diverse selection is justified by the complex, multi-scalar nature of cloud workload telemetry. While sequential models like LSTM and GRU excel at capturing long-term temporal dependencies and seasonal trends, CNNs and TCNs utilize parallelized receptive fields to isolate transient, short-term burstiness. Transformers leverage self-attention to map global contextual correlations across extended horizons, and MLPs provide a minimal non-linear baseline. By broadening the search space to include these fundamentally distinct inductive biases alongside micro-hyperparameters (e.g., window size, learning rate, and attention heads), we ensure that the pipeline can adaptively synthesize the optimal model topology for any given data composition. To guarantee that our subsequent performance evaluations are algorithmically robust and invariant to the biases of a single optimization routine, we executed the experiments across five distinct search strategies, each representing a fundamentally unique paradigm of space exploration: • Grid Search: A deterministic, exhaustive strategy that systematically evaluates every predefined combination within the discrete bounds. It establishes a rigid performance baseline, though it is inherently constrained by the curse of dimensionality. • Random Search: A non-deterministic strategy that samples configurations completely at random. Statistically, it serves as a powerful benchmark by exploring continuous dimensions (such as learning rate) more effectively than Grid Search without getting trapped in redundant parameter coordinates. 12

A PREPRINT - J UNE 9, 2026

Table 3: Neural Architecture Search (NAS) hyperparameter search space. Parameter

Type

Model type

choice

Units Number of layers Dropout Activation Learning rate Window size Batch size Epochs Kernel size Attention heads

choice choice choice choice loguniform choice choice choice choice choice

Values / Range LSTM, GRU, CNN, RNN, TCN, Transformer, MLP 16, 32, 64, 128, 256 1, 2, 3, 4 0.0, 0.1, 0.2, 0.3, 0.5 relu, tanh, sigmoid, elu [10−5 , 10−2 ] 2–30 16, 32, 64, 128 5, 10, 15, 20 2, 3, 5, 7 2, 4, 8

• Tree-structured Parzen Estimator (TPE): A Sequential Model-Based Optimization (SMBO) approach rooted in Bayesian inference. TPE constructs a probabilistic model of architecture performance based on historical evaluation history, actively guiding the search toward regions with a high probability of improvement while minimizing computational waste. • Evolutionary Algorithm: A population-based heuristic inspired by natural selection. By maintaining a pool of architectures and applying iterative mutations and crossovers to the top-performing individuals, it is uniquely suited for navigating highly non-convex, discontinuous search spaces and escaping local minima. • Simulated Annealing: A single-state metaheuristic inspired by metallurgy. It initially explores the search space aggressively by probabilistically accepting lower-performing candidate architectures (at a high virtual "temperature"), gradually cooling over time to tighten its focus around the global optimum. By evaluating our proposed data-mixing methodology against this spectrum of exhaustive, stochastic, probabilistic, and heuristic search regimes, we ensure that the resulting predictive accuracies reflect genuine structural data advantages rather than artifacts of a specific optimization algorithm. 5.2.1

Resource-Constrained NAS Performance and Accuracy

Before deploying machine learning models in dynamic cloud environments, it is critical to ensure that the automated pipeline can bootstrap highly accurate initial models rapidly and without relying on expensive GPU clusters. To validate this, our first experiment evaluates the best outcome of all search methods within our defined search space using strictly limited computing resources (a standard commercial Intel Core i7 CPU) over severely restricted search intervals ranging from 5 to 30 minutes (300 to 1800 seconds). Demonstrating convergence within these short windows proves the framework’s ability to provide robust initial models that can be immediately deployed and fine-tuned on the fly. To provide a holistic view of predictive performance, we evaluate the generated architectures using three distinct, complementary metrics: • Mean Absolute Percentage Error (MAPE): Our primary scale-independent metric, enabling uniform accuracy comparisons across target nodes with varying absolute resource capacities. • Mean Absolute Error (MAE): Quantifies error in tangible operational units (e.g., absolute CPU percentages) to establish a concrete baseline of physical resource inaccuracy. • Mean Squared Error (MSE): Disproportionately penalizes large deviations, explicitly highlighting a model’s vulnerability to missing catastrophic workload spikes that risk Service Level Agreement (SLA) violations. To conduct a rigorous ablation study and validate the necessity of our data-mixing approach, we executed the NAS search across seven distinct data scenarios. In the Mixed scenarios, the NAS engine was constrained to the maximum of 1,500 samples: 1,000 structural samples from a generic dataset (TimeTrack, GWA-M13, or ACTv2018) seamlessly merged with 500 localized samples dynamically extracted from the target machine. To establish absolute baselines, we also tested the framework using the Target Local Data alone, TimeTrack alone, GWA-M13 alone, and ACTv2018 alone. The empirical outcomes of these scenarios across the different time intervals are visualized in Figure 11. A granular analysis of the isolated baselines confirms that relying exclusively on coarse-grained public datasets yields severely degraded predictive accuracy. The Alibaba (ali_only) trace displays the worst overall baseline performance; at a 13

A PREPRINT - J UNE 9, 2026

0.01490.01440.01380.01320.01300.0129

0.0200

0.01420.01370.01360.01330.01320.0131

0.0175

0.03250.01610.01370.01350.01360.0132

0.020 0.015 0.010

s 00 18

s 00 15

s 00 12

0s 90

0.01130.01250.01130.01110.01140.0113 0s

0.0100

0.0125

0.01330.01250.01110.01130.01120.0122

0.0150

s 00 18

s 00 15

0s 90

0.01480.01150.01210.01110.01160.0115 60

0.0100

0.0125

s 00 18

s 00 15

0s 90

00 18

00 15

00 12

0.01450.01520.01130.01150.01110.0113

0.015

Ali+Local 0.01630.01600.01550.01610.01680.0156

0.01160.01170.01160.01130.01120.0114

0.02910.01510.01270.01290.01300.0111

0.0150

0.0175

0.01550.01270.01140.01180.01130.0114

0.03100.01580.01240.01110.01220.0142

0.020

0.025

0.01530.01460.01320.01320.01310.0113

Mat+Local 0.01300.01260.01250.01250.01250.0123

Ali 0.05070.05350.04260.04870.04970.0492

0.030

00 18

00 15

00 12

0.014

0.01020.01010.01010.00990.00990.0098

0.013

0.01140.01360.01230.01260.01230.0124 0.01500.01290.01480.01130.01190.0115 0.01210.01150.01130.01120.01150.0113 0.01310.01150.01160.01160.01130.0113

0.012 0.011 0.010

0.0200

Mat 0.01470.01400.01530.01400.01450.0149

0.025

0.01020.01040.01050.01020.00990.0099

0.0225

0.01060.01040.01030.01010.01010.0099

0.0250

0.01030.01050.01010.01020.00990.0099

0.035

0.015

0.01120.01120.01110.01110.01120.0112

0.040

0.01110.01120.01110.01100.01120.0112

TT+Local 0.01140.01140.01130.01130.01110.0110

0.030

0.01140.01140.01110.01120.01120.0111

0.01130.01110.01120.01110.01120.0111

0.0250

0.0275

0.01140.01140.01110.01110.01120.0112

0.01140.01110.01090.01110.01110.0110

0.0275

0.0300

0.01140.01110.01200.01120.01140.0111

0.01140.01140.01120.01110.01100.0111

0.045

0.050

TT 0.01210.01220.01210.01150.01190.0124

00 18

Local 0.01290.01310.01240.01120.01120.0112

20.0

27.42 22.95 22.32 22.64 22.24 22.91

23.80 23.49 22.15 22.64 22.06 23.02

22.5

26.94 24.96 23.08 22.68 24.51 23.67

30.25 25.33 22.65 22.72 23.18 25.28

25.0

33.09 28.94 32.73 22.28 25.66 22.26

38.70 22.57 26.13 22.56 22.59 22.21

27.5

22.31 30.83 24.59 28.36 27.30 24.69

25.20 22.36 22.19 22.35 22.84 23.25

21.58 21.56 20.63 20.13 19.33 19.12

30.0

20.49 20.22 19.85 20.15 20.01 19.04

00 18

00 15

00 12

30.56 24.68 25.52 22.93 23.91 23.49

22.33 22.81 22.60 22.26 22.40 23.44

32.5

25.18 24.43 23.04 22.27 22.21 23.24

35.0

41.39 33.17 23.03 27.81 25.45 22.30

34.18 28.87 25.57 24.35 23.63 23.22

22.38 21.70 21.29 20.90 20.18 19.42

00 18

00 15

31.59 34.90 22.24 23.49 22.91 23.12

35.69 28.54 22.73 23.27 22.19 22.29

45.63 26.71 22.69 23.11 22.55 32.07

00 18

00 15

0s 90

0s 60

0s 30

Ali 57.50 52.94 41.57 53.54 55.46 54.50

35.30 27.34 26.46 25.97 25.82 23.21

Mat 33.68 31.88 34.91 31.96 33.26 34.02

21.17 20.99 20.50 20.45 19.82 19.33

TT+Local 22.49 21.25 20.87 20.91 20.53 20.18

23.46 24.23 22.53 22.52 21.86 22.12

22.28 22.20 22.45 22.25 22.51 22.72

22.83 23.05 22.29 22.04 22.19 22.22

22.84 23.08 26.02 22.29 22.30 22.28

37.5

evolution

22.98 22.19 22.14 22.17 22.25 22.22

TT 25.91 25.58 25.52 24.16 25.25 25.77

40.0 37.5 35.0 32.5 30.0 27.5 25.0 22.5 20.0

23.63 22.50 22.18 22.18 22.47 22.06

Ali+Local 36.39 35.49 34.48 35.40 37.45 34.40

2.17 2.09 2.10 2.06 2.07 2.07

2.08 2.09 2.07 2.05 2.16 2.08

3.50

2.26 2.13 2.08 2.09 2.07 2.07

2.10 2.10 2.10 2.09 2.08 2.11

3.25

1.73 1.77 1.70 1.68 1.64 1.64

2.08 2.06 1.94 1.99 1.93 1.90

2.07 2.00 1.93 1.91 1.88 1.82

3.00

3.21 3.11 3.08 2.71 2.25 2.10

2.82 2.79 2.44 2.54 2.46 2.60

2.75

3.65 2.64 3.11 2.13 2.28 2.23

2.50

2.41 2.18 2.12 2.11 2.20 2.23

2.25

2.80 2.25 2.25 2.16 2.18 2.16

2.00

00 18

00 15

s 00 18

s 00 15

s 00 12

0s 90

2.13 2.65 2.15 2.08 2.12 2.09 60

s 00 18

s 00

00 12

3.71 2.22 2.41 2.07 2.17 2.19

2.82 2.45 2.08 2.13 2.11 2.40

2.31 2.20 2.17 2.13 2.10 2.20

14.30 2.99 2.99 2.20 2.13 2.07

12.62 3.50 2.61 2.62 2.40 2.09

3.31 3.20 3.05 2.91 2.76 2.45

1.89 1.90 1.83 1.87 1.84 2.10

s 00 18

s 00 15

3.29 3.44 2.17 2.26 2.08 2.10 00

3.56 2.61 2.22 2.33 2.19 2.18

s 00 18

s 00 15

s 00 12

0s 90

0s 60

Ali+Local 4.14 3.96 3.80 4.00 4.33 3.83

9.33 3.77 2.49 2.07 2.44 3.24

Mat+Local 2.72 2.55 2.54 2.50 2.51 2.48

3.12 2.99 2.80 2.72 2.67 2.56

Ali 28.49 31.48 20.99 26.55 27.52 26.99

Mat 3.31 3.03 3.48 3.07 3.26 3.37

TT+Local 2.41 2.33 2.29 2.27 2.27 2.39

2.19 2.14 2.08 2.09 2.10 2.15

2.14 2.12 2.02 2.07 2.07 2.05

2.11 2.07 2.47 2.07 2.13 2.08

2.24 2.14 2.11 2.07 2.08 2.07

TT 2.39 2.42 2.36 2.20 2.30 2.51

Local 2.72 2.77 2.44 2.10 2.10 2.08

MAE

anneal

Mat+Local 26.89 25.41 26.20 25.15 25.62 25.92

MSE (×10 )

tpe

22.68 22.20 22.41 22.12 22.36 22.35

random 55

MAPE (%)

GridSearch Local 26.29 26.68 26.25 22.23 22.24 22.27

Figure 11: Performance heatmap of NAS CPU models comparing error metrics (MAPE, MAE, MSE) across varying search methods, durations, and data-mixing scenarios.

300-second search duration, its MAPE spans from an elevated 33.09% under Evolutionary search to an appalling 57.49% using Grid Search, accompanied by a high MSE of 0.002849. The Materna (mat_only) baseline behaves similarly, with Grid Search remaining stagnant at roughly 33.67% to 34.01% MAPE across all time intervals. We attribute this severe performance degradation to their coarse 5-minute sampling intervals, which mathematically act as a low-pass filter, smoothing out transient micro-bursts and high-frequency volatility. Consequently, models trained on these baselines lack the structural resolution to track sharp, short-term temporal variations. Conversely, the high-resolution TimeTrack baseline (tt_only) leverages its dense 45-second sampling interval to achieve significantly better baseline stability, stabilizing around 22.12% to 22.28% MAPE under TPE and Simulated Annealing. However, even this dense generic trace fails to outperform the Target Local Data alone (local_only), which hits a minimum MAPE of 22.04% and an MSE of 0.000204 within 1200 seconds under Evolutionary search. The most definitive and impactful finding of this evaluation is the universal efficacy of our proposed data-mixing framework. Across all test cases, merging target local data with any generic baseline yielded substantial performance gains over using those generic datasets in isolation. For instance, the local_plus_ali and local_plus_mat configurations successfully reclaimed predictive accuracy, dropping error rates well below their isolated counterparts. However, these configurations remained bounded by a distinct performance ceiling, failing to match the accuracy of the local_plus_tt mixture. We attribute this performance delta directly to the telemetry collection intervals: while local data injects node-specific context, the underlying 5-minute sampling interval of the Alibaba and Materna traces fundamentally bottlenecks the model’s ability to extract high-frequency structural motifs. Conversely, by blending local samples with the dense, 45-second intervals of TimeTrack, the local_plus_tt configuration breaks the 20% accuracy barrier. Under Simulated Annealing at 1800 seconds, it achieves the absolute best performance across the entire experiment, downscaling to a highly precise 19.04% MAPE and a remarkably low MAE of 0.000994. Interestingly, the data-mixing strategy also introduces an unexpected regularizing effect that alters search space topology. In the local_plus_tt domain, Random Search matches sophisticated meta-heuristics, dropping smoothly from 21.17% MAPE (300s) to 19.32% MAPE (1800s), while yielding the lowest recorded variance with an MSE of 0.000163. This implies that high-resolution data-mixing smooths the loss landscape, making optimal architectural configurations highly abundant and accessible even to stochastic sampling routines. Furthermore, evaluating performance across the three tracking metrics uncovers a vital diagnostic divergence between MAE and MSE. For instance, in the local_plus_mat dataset at 1800 seconds, Simulated Annealing records a competitive MAE of 0.01219, yet its MSE deteriorates to 0.000240 compared to its 1500-second mark (0.000210). This indicates that while the model’s average absolute error remained stable, it began generating isolated, high-magnitude prediction errors—a behavior that would trigger catastrophic SLA violations in a production environment. 14

A PREPRINT - J UNE 9, 2026

local_only

random

Min MAPE

local_plus_tt

GridSearch

35.0

32.5

20 0

100

200 300 400 Local Data Size (Samples)

500

anneal

100

200 300 400 Local Data Size (Samples)

evolution 34

27.5

local_plus_ali

30.0

local_plus_mat

tpe

25.0

22.5

20.0

500

100

200 300 400 Local Data Size (Samples)

500

20 0

100

200 300 400 Local Data Size (Samples)

500

100

200 300 400 Local Data Size (Samples)

500

Figure 12: Impact of target data size (10 to 500 samples) on the minimum achieved MAPE across isolated and mixed data configurations using various NAS search strategies. local_only

Min MAPE

random 34

tt_only

local_plus_tt

26 24

3 Horizon Steps

anneal

35.0 26

32.5 30.0

27.5 22

25.0

3 Horizon Steps

22.5

20 1

evolution

37.5

20 1

local_plus_ali

local_plus_mat

ali_only

tpe

mat_only

GridSearch

3 Horizon Steps

20.0 1

3 Horizon Steps

Figure 13: Minimum prediction error (MAPE) across different forecasting horizons (from 1 to 5 steps ahead) for all dataset combinations and search strategies. Finally, the temporal trajectories of the optimization strategies highlight a stark operational contrast between dynamic search heuristics and deterministic Grid Search. Across all datasets, heuristic and probabilistic strategies (TPE, Evolution, Annealing) demonstrate consistent, smooth asymptotic convergence as search duration increases from 300 to 1800 seconds. Grid Search, by contrast, suffers from severe dimensional paralysis. In the local_only scenario, Grid Search exhibits a sudden, step-function phase change, stagnating at ∼26.68% MAPE before abruptly plummeting to 22.23% at the 1200-second mark once it finally evaluates a viable hyperparameter coordinate. However, when confronted with sparse or mixed environments like local_plus_ali, Grid Search remains totally paralyzed, flatlining at an unusable ∼34.40% to 37.45% MAPE across the entire 30-minute window. Exhaustive grid approaches waste precious CPU cycles evaluating known poor architectural configurations sequentially, proving that intelligent, adaptive search strategies are strictly necessary for resource-constrained, rapid edge deployment. In summary, the empirical evidence demonstrates that our data-mixing approach successfully bootstraps initial model accuracy under strict computational and temporal constraints. However, while these results confirm the structural viability of blending datasets, this baseline evaluation relied on a static configuration of exactly 500 target local samples. To determine whether this specific volume represents an optimal operational threshold, or if predictive accuracy can be further optimized with a smaller local footprint or a different mixing ratio, it is necessary to analyze the framework’s sensitivity to data volume. Consequently, we next isolate the localized data size as our primary independent variable, systematically evaluating its direct impact on NAS convergence and model accuracy to uncover the ideal data-provisioning boundaries. 5.2.2

Sensitivity Analysis of Local Data Volume

While the previous evaluation used a fixed amount of local data, this experiment systematically varies the Target Local Data volume from 10 to 500 samples. This analysis serves two main purposes: first, to identify the minimum number of local samples required to generate accurate models; and second, to evaluate how effectively high-resolution generic data can compensate for data scarcity at the target node. For this study, we focus exclusively on Mean Absolute Percentage Error (MAPE) as our primary metric, as its scale-independent nature allows for a uniform comparison across different data sizes and search strategies. The empirical trajectory of model accuracy as a function of localized data size is visualized in Figure 12. The resulting dataset exposes a clear, universal correlation: scaling the local data volume from 10 to 500 samples consistently drives down the minimum achieved MAPE across all data compositions. However, the performance delta 15

A PREPRINT - J UNE 9, 2026

between isolated and mixed data strategies at the ultra-sparse edge reveals the true structural value of the high-resolution baseline. In the local_only baseline configuration at 10 samples, the NAS engine struggles significantly, returning elevated MAPEs across all search regimes, with Grid Search recording a highly inaccurate 34.47% MAPE and the best-performing stochastic search (Random) bounded at 24.72% MAPE. This confirms that 10 telemetry points provide an entirely insufficient history for a network to deduce basic autoregressive properties in isolation. This bottleneck is profoundly broken when introducing the local_plus_tt configuration. By injecting 1,000 dense, high-resolution structural samples from TimeTrack, the pipeline achieves remarkable accuracy even when restricted to only 10 local samples. Under this extreme data constraint, TPE achieves a 23.23% MAPE, and Random search marks 24.38% MAPE. Strikingly, these mixed configurations utilizing a mere 10 local samples match or outperform the predictive accuracy of models trained on 500 samples of localized data alone (local_only at 500 samples hovers between 22.06% and 22.28% MAPE). This crossover effect proves that high-density generic data effectively shifts the search landscape, allowing the NAS framework to discover high-performing structural motifs that generalize perfectly to the target node despite near-zero initial local telemetry. Conversely, analyzing the coarse-grained public mixtures highlights the strict limitations of large collection intervals. When mixed with 10 local samples, both local_plus_mat and local_plus_ali exhibit severe performance penalties. The Alibaba mixture (local_plus_ali) shows a catastrophic 57.97% MAPE under Grid Search and a restricted 36.12% MAPE under TPE at the 10-sample mark. While scaling the local data volume to 500 samples does allow these coarse-grained mixtures to recover—eventually converging down to ∼22.29% for Materna and ∼22.91% for Alibaba—they never break the 20% performance ceiling. In sharp contrast, the high-resolution TimeTrack mixture scales cleanly as local context accumulates, with Simulated Annealing unlocking the absolute global optimum of 19.04% MAPE at the 500-sample milestone. This clear delta validates our hypothesis: while local data provides essential contextual alignment, the collection interval of the structural baseline dictates the model’s ultimate accuracy ceiling. In summary, this sensitivity analysis demonstrates that mixing data creates an incredibly resilient pipeline capable of accurate deployments even during the earliest phases of target node bootstrapping. However, all evaluations conducted up to this point have operated under a single-step forecast horizon, testing only the immediate look-ahead capability of the models. While a 1-step horizon validates the fundamental data-mixing mechanics, real-world cluster management requires broader predictive horizons to safely absorb scheduling and migration overheads. Having thoroughly mapped the ideal data-provisioning boundaries, we proceed to our final experiment to evaluate how these data compositions withstand the compounding errors associated with multi-step-ahead forecasting. 5.2.3

Predictive Accuracy Across Horizons

In this experiment, we test how well our models predict multiple steps into the future. We vary the forecasting horizon from 1 step ahead up to 5 steps ahead. We run these tests across five different data setups: local data only (local_only), external datasets alone (tt_only, mat_only, ali_only), and mixed data combinations (local_plus_tt, local_plus_mat, local_plus_ali). For each setup, we also test various tuning methods like Random Search, Grid Search, TPE, Annealing, and Evolution to find the lowest possible error. Predicting the immediate next step is usually easy for machine learning models because recent patterns are highly relevant. However, in real-world deployments, systems need to plan multiple steps in advance. This experiment is necessary because forecasting errors tend to compound and grow over longer time windows. By testing horizons 1 through 5, we can pinpoint exactly when a model’s predictions stop being reliable and discover which data combinations best prevent the model from losing accuracy over time. As shown in Figure 13, we evaluate the performance using the Mean Absolute Percentage Error (MAPE). The data reveals several critical trends: • The Compounding Error Trend: Across all datasets, error increases as the horizon grows from 1 to 5. For example, in the local_only dataset, the best MAPE starts at 22.06% (using TPE at horizon 1) and degrades to 23.28% (using Annealing at horizon 5). This confirms the expected difficulty of longer-term forecasting. • The Clear Superiority of Telemetry Data: The mixed dataset combining local and telemetry data (local_plus_tt) completely outperforms every other setup. At horizon 1, it achieves the lowest overall error in the entire experiment at 19.04% (via Annealing). Remarkably, its error at horizon 5 (20.45%) is still significantly lower than any other dataset can achieve even at horizon 1. This shows that telemetry data provides a strong, stable signal that protects the model from severe error growth. • Standalone Dataset Weaknesses: Relying purely on external data without local context yields poor results over time. The mat_only dataset starts at 23.21% and jumps to 26.16% by horizon 5. The ali_only dataset 16

A PREPRINT - J UNE 9, 2026

degrades even worse, starting at 22.21% and scaling up to a high error of 26.27% at horizon 5. Grid Search on these standalone datasets performs exceptionally poorly, spiking up to 58.43% MAPE on ali_only. • Incompatible Combinations: Interestingly, mixing local data with mat or ali data does not replicate the success of the telemetry mix. The local_plus_mat setup stays hovering around 22.29% to 24.32%, showing that not all external data sources combine well with local node data. The results of this horizon optimization test prove that multi-step forecasting accuracy depends heavily on the type of data used rather than just the optimization method. While all models suffer from rising errors as the prediction window lengthens, combining local data with telemetry data uniquely flattens this error growth curve. We can conclude that for multi-step forecasting tasks up to horizon 5, the local_plus_tt architecture is the only configuration that maintains a high level of predictive reliability for an initial model deployment. 5.3

Post-Deployment Computational Footprint

While high-resolution training drastically improves automated model generation, it inevitably forces the final deployed algorithm to process more data points in real-time. Specifically, a 45-second sampling interval yields 6.67× more data over a given time window compared to a 5-minute interval. To ensure this does not violate edge computing constraints, we evaluated the real-time resource footprint of various fixed architectures (CNN, GRU, LSTM, RNN, Transformer) as data volume scaled up proportionally. Computational Resources Comparison: TimeTrack vs GWA-Materna-13 vs Alibaba-CD-2018 GRU

LSTM

TimeTrack GWA-Materna-13 Alibaba-CDV-2018

101

25 24 23

18 16 14

10 ;30 (90 0) ;6 (18 00) 0;1 (36 200) 0;2 (72 400) 0;4 (14 800 40 ) (28 ;960 80 0) ; (57 1920 60 0) ;38 40 0)

(45

;30 (90 0) ;6 (18 00) 0;1 (36 200) 0;2 (72 400) 0;4 (14 800 40 ) (28 ;960 80 0) ; (57 1920 60 0) ;38 40 0)

(45

(18

(45

;30

(90 0) ;60 0) 0;1 (36 200) 0;2 (72 400) 0;4 (14 800 40 ) (28 ;960 80 0) ; (57 1920 60 0) ;38 40 0)

Data Injection

10 ;30 (90 0) ;6 (18 00) 0;1 (36 200) 0;2 (72 400) 0;4 (14 800 40 ) (28 ;960 80 0) ; (57 1920 60 0) ;38 40 0)

(45

;30 (90 0) ;6 (18 00) 0;1 (36 200) 0;2 (72 400) 0;4 (14 800 40 ) (28 ;960 80 0) ; (57 1920 60 0) ;38 40 0)

(45

(18

(45

;30 (90 0) ;6 (18 00) 0;1 (36 200) 0;2 (72 400) 0;4 (14 800 40 ) (28 ;960 80 0) ; (57 1920 60 0) ;38 40 0)

Data Injection

;30 (90 0) ;6 (18 00) 0;1 (36 200) 0;2 (72 400) 0;4 (14 800 40 ) (28 ;960 80 0) ; (57 1920 60 0) ;38 40 0)

(45

;30 (90 0) ;6 (18 00) 0;1 (36 200) 0;2 (72 400) 0;4 (14 800 40 ) (28 ;960 80 0) ; (57 1920 60 0) ;38 40 0)

;30 (90 0) ;60 0) 0;1 (36 200) 0;2 (72 400) 0;4 (14 800 40 ) (28 ;960 80 0) ; (57 1920 60 0) ;38 40 0)

(18

(45

;30 (90 0) ;6 (18 00) 0;1 (36 200) 0;2 (72 400) 0;4 (14 800 40 ) (28 ;960 80 0) ; (57 1920 60 0) ;38 40 0)

(45

;30 (90 0) ;6 (18 00) 0;1 (36 200) 0;2 (72 400) 0;4 (14 800 40 ) (28 ;960 80 0) ; (57 1920 60 0) ;38 40 0)

55 50

(45

(90 0) ;60 0) 0;1 (36 200) 0;2 (72 400) 0;4 (14 800 40 ) (28 ;960 80 0) ; (57 1920 60 0) ;38 40 0)

;30

44 42 40 38 36 34 32 30

(45

(18

;30

9.5 9.0 8.5 8.0 7.5 7.0 6.5 6.0

;30 (90 0) ;6 (18 00) 0;1 (36 200) 0;2 (72 400) 0;4 (14 800 40 ) (28 ;960 80 0) ; (57 1920 60 0) ;38 40 0)

100

(45

Memory Used (MB)

Transformer

101

100

Average CPU Usage (%)

RNN

101 101

(90 0) ;60 0) 0;1 (36 200) 0;2 (72 400) 0;4 (14 800 40 ) (28 ;960 80 0) ; (57 1920 60 0) ;38 40 0)

Training Time (s)

CNN

Data Injection

Figure 14: Training time, memory, and CPU usage for deployed models. The graphs scale proportionally to represent the 6.67× data density difference of the 45-second TimeTrack interval vs. 5-minute intervals. As depicted in Figure 14, processing the denser TimeTrack data logically increases computation time and memory usage compared to the sparse datasets. However, the absolute costs remain highly predictable and negligible for modern edge hardware. For instance, LSTMs—one of the most demanding architectures tested—required only 49 seconds to process a massive window of 38,400 TimeTrack samples, peaking at roughly 50-55 MB of RAM. CPU usage remained similarly steady between 10-15%. CNNs proved to be the most computationally efficient, while Transformers showed moderate memory usage that scaled predictably with sequence length. Ultimately, these results prove that the massive gains in prediction accuracy and NAS automation achieved by utilizing 45-second intervals far outweigh the minor, easily accommodated increase in post-deployment computational cost. 17

A PREPRINT - J UNE 9, 2026

Conclusion and Future Work

In this paper, we presented a fully automated predictive orchestration architecture designed to overcome the cold-start generalization problem and manage the extreme volatility of the Cloud-Edge Continuum. Our framework establishes a robust, data-driven foundation for proactive Zero Touch Management across highly heterogeneous environments. To achieve this, we first introduced a lightweight, plugin-based Resource Exposer (RE) framework. The RE enables dynamic, infrastructure-agnostic telemetry extraction through a decentralized self-registration mechanism and a unified data format. Our performance evaluations demonstrated that the RE operates with minimal CPU and memory footprints and maintains low-latency API responses—even under aggressive 1-second data collection intervals—proving its exceptional suitability for resource-constrained edge and far-edge nodes. Furthermore, we solved the automated model generation challenge by merging this dynamic local telemetry with TimeTrack, our highly detailed, 45-second resolution structural dataset. We proved that leveraging TimeTrack as a foundational baseline within a Neural Architecture Search engine significantly improves both search efficiency and the predictive accuracy of the resulting forecasting models when compared to standard, coarse-grained public datasets. While processing high-resolution data inherently increases the post-deployment computational footprint, we demonstrated that this overhead remains highly predictable, stable, and well within acceptable bounds for modern edge hardware. Despite these promising results, certain limitations remain that outline clear pathways for future work. 1. First, although our experiments demonstrated how the volume of localized target data injected into the pipeline directly influences the initial model accuracy, the current framework lacks a mechanism to dynamically calculate the optimal number of telemetry samples required to achieve a predefined target accuracy within a strict time constraint. 2. Second, the feature selection process is not yet automated; depending on the specific forecasting output and the telemetry metrics available via the Resource Exposer, the architecture cannot automatically determine which data columns should be included in the training phase based on cross-field correlations. To transition toward a more automatic framework, our future research will focus on automating both dimensions: implementing an optimization layer to dynamically bound the required target sample sizes based on SLA performance targets, and developing a correlation-driven automated feature-selection mechanism to optimize input training configurations for maximum precision.

References [1] Meliani Abd Elghani, Sagar Arora, Adlen Ksentini, and Raymond Knopp. Timetrack: A dataset for exploring temporal patterns and predictive insights into openairinterface (oai) ci/cd cluster. In IEEE, editor, ICC 2025, IEEE International Conference on Communications 2025, 8-12 June 2025, Montreal, Canada, Montreal, 2025. [2] Abd Elghani Meliani, Adlen Ksentini, Mohamed Mekki, Abdelhak Kadouma, Dimitrios Amaxilatis, Amadou Ba, Eduardo Ojeda Coronado, John Beredimas, Vrettos Mouloss, Souvik Sengupta, Dimitris Klonidis, and Christos Verikoukis. Ai-native cecc management architecture: Enabling scalable and intelligent cloud-edge computing. Athens, 2025. [3] Abd Elghani Meliani, Mohamed Mekki, and Adlen Ksentini. Resiliency focused proactive lifecycle management for stateful microservices in multi-cluster containerized environments. Computer Communications, 236:108111, 2025. [4] Miloud Bagaa, Adlen Ksentini, et al. Layer-reuse aware optimization for efficient microservice migration in uav edge systems. In ICC 2026, IEEE International Conference on Communications, 2026. [5] Abd Elghani Meliani and Adlen Ksentini. Lightweight resource exposure framework for efficient service and resource orchestration in the cloud-edge continuum. In IEEE, editor, ICC 2025, IEEE International Conference on Communications, 2nd Workshop on the Path Towards 6G: Standardization and Research Vision, 8-12 June 2025, Montreal, Canada, Montreal, 2025. [6] OpenAirInterface. OpenAirInterface: 5G Software Alliance for Democratising Wireless Innovation, 2023. Accessed: 2024-10-30. [7] OpenAirInterface. OpenAirInterface Ci/Cd webpage, 2023. Accessed: 2024-10-30. [8] A.J. Jerri. The shannon sampling theorem—its various extensions and applications: A tutorial review. Proceedings of the IEEE, 65(11):1565–1596, 1977. 18

A PREPRINT - J UNE 9, 2026

[9] Dilyara Baymurzina, Eugene Golikov, and Mikhail Burtsev. A review of neural architecture search. Neurocomputing, 474:82–93, 2022. [10] Abdelghani Meliani. Timetrack: Openairinterface (oai) ci/cd time series dataset, 2025. Accessed: Feb 13, 2025. [11] Abdelghani Meliani. Timetrack: Openairinterface (oai) ci/cd time series dataset, 2025. Accessed: Aug 26, 2025. [12] Delft University of Technology. Grid Workloads Archive GWA-T-13-Materna. Accessed: 2024-08-27. [13] Google Inc. Google Cluster Data 2019, 2019. Accessed: 2024-08-27. [14] Microsoft Corporation. Microsoft Azure Public Dataset V1, 2019. Accessed: 2024-10-30. [15] Alibaba Inc. Alibaba Cluster Trace v2018, 2018. Accessed: 2024-08-27. [16] Microsoft Corporation. Microsoft Azure Public Dataset V2, 2020. Accessed: 2024-10-30. [17] J. Mai et al. Is sampled data sufficient for anomaly detection? In Proceedings of IMC, 2006. [18] Antonio Libri. Towards High-Resolution Monitoring for HPC and Data Center Analytics, Automation and Control. PhD thesis, ETH Zurich, 2019. [19] Jennifer Garland. Effects of resampled data on time series forecasting accuracy. 2019. [20] Yann LeCun, Yoshua Bengio, and Geoffrey Hinton. Deep learning. Nature, 521(7553):436–444, May 2015. [21] Sepp Hochreiter and Jürgen Schmidhuber. Long short-term memory. Neural Computation, 9(8):1735–1780, 11 1997. [22] Sridhar Alla and Suman Kalyan Adari. What is mlops? In Beginning MLOps with MLFlow: Deploy Models in AWS SageMaker, Google Cloud, and Microsoft Azure, pages 79–124. Springer, 2020. [23] Shubhra Kanti Karmaker, Md Mahadi Hassan, Micah J Smith, Lei Xu, Chengxiang Zhai, and Kalyan Veeramachaneni. Automl to date and beyond: Challenges and opportunities. Acm computing surveys (csur), 54(8):1–36, 2021. [24] Shan-Hsiang Shen and Aditya Akella. Decor: A distributed coordinated resource monitoring system. In 2012 IEEE 20th International Workshop on Quality of Service, pages 1–9, 2012. [25] Tuan Nguyen and Manish Pandey. Dprof-distributed system profiling and tracing. [26] Mohamed Mekki, Sagar Arora, and Adlen Ksentini. A scalable monitoring framework for network slicing in 5g and beyond mobile networks. IEEE Transactions on Network and Service Management, 19(1):413–423, 2022. [27] Sabine Randriamasy, Luis M. Contreras, Jordi Ros-Giralt, and Roland Schott. Operational compute metrics, 2024-07-07. [28] Prometheus. Prometheus: Monitoring system and time series database, n.d. [29] Nagios. Nagios - the industry standard in it infrastructure monitoring, 2024. Accessed: 2024-09-12. [30] Microsoft. Neural Network Intelligence, 1 2021.

Record · ID 267597 · SHA-256 cdac4ed33cc1a1e4
Retrieved via Conceptio — every document is proof-bundled with source, license, and retrieval metadata.