## 3 Experimental Scenarios
### Scenario II: Experimental Results  
The cloud GRU model's performance was evaluated, with a focus on its ability to produce accurate long-range AQI forecasts, using RMSE. Unlike the edge scenario, the model size was not constrained here, enabling the architecture to fully exploit the available computational resources. Furthermore, it was configured with 1280 GRU cells and connected to a sub-network with decreasing neuron counts, forming a hybrid recurrent-dense architecture. This design aims to combine the temporal learning capability of GRUs with the dense layers' hierarchical feature abstraction strengths. The dense sub-network used here mirrored the layer structure of the corresponding slideNN models: fully connected layers with neuron counts decreasing by a factor of two at each step (Figure 4). This scenario treated the number of internal GRU layers as a key hyperparameter, as deeper architectures increase model complexity and are better suited for cloud-based experimentation. An initial configuration with two layers was tested but later discarded as it failed to utilize the cloud environment's computational advantages fully. Consequently, configurations with three and four layers were selected to explore the benefits of increased model depth; ultimately, four layers proved ideal for these experimental cases. The number of training epochs also varied depending on the model setup, ranging from 25 to 40 based on the conditional training termination criterion, which is reached when a small learning rate value is achieved. Performance outcomes were analyzed compared to the best-performing edge GRU configurations. Across all configurations evaluated in the cloud-based setting, architectural and training modifications were applied to scale the models appropriately beyond their edge-based counterparts. A key adjustment involved significantly increasing the number of GRU cells, as it became evident that timestep size alone contributed relatively little to the total parameter count compared to other hyperparameters, a thing that can be assumed even by looking at the difference in memory size between the edge configurations (Table 5). The GRU cell size was scaled up for each configuration to ensure the models reached a substantial memory footprint suitable for cloud experimentation [69]. In line with this approach, the internal architecture was also deepened by increasing the number of GRU layers, typically favoring setups with three or more layers to leverage the higher capacity and representational power available in cloud environments. While the training duration varied slightly across configurations, most of the models were trained for approximately 25 to 40 epochs. However, the training histories indicated that the validation loss plateaued well before the final epoch. This suggests that the models had already captured the most relevant patterns earlier in training, implying that fewer iterations could achieve satisfactory performance. The same behavior was observed consistently across the configurations: in the first two setups, the validation performance plateaued around the 30 th to 35 th epoch, allowing the number of training epochs to be safely reduced to 25 without a loss in model quality. Similarly, in the two larger configurations, performance stabilized by the 40 th epoch, which justified reducing training to approximately 35 epochs, thereby improving training efficiency and maintaining predictive accuracy (minimal RMSE loss). The training history graph of the model with input/output configuration \(512\to 16\) is presented in Figure 9, showing the training and validation loss curves, which provided insight into both the ideal epoch for training this model and its fitting condition. None of the cloud hybrid GRU-NN configurations showed signs of overfitting as both the training and validation curves moved smoothly, linearly, and in proportion to each other. As shown in Table 9, all the \(p\)-values of \(<0.01\) indicate that the performance improvements were statistically significant.