RAP-Optimizer: Resource-Aware Predictive Model for Cost Optimization of Cloud AIaaS Applications

Abstract

Artificial Intelligence (AI) applications are rapidly growing, and more applications are joining the market competition. As a result, the AI-as-a-service (AIaaS) model is experiencing rapid growth. Many of these AIaaS-based applications are not properly optimized initially. Once they start experiencing a large volume of traffic, different challenges start revealing themselves. One of these challenges is maintaining a profit margin for the sustainability of the AIaaS application-based business model, which depends on the proper utilization of computing resources. This paper introduces the resource award predictive (RAP) model for AIaaS cost optimization called RAP-Optimizer. It is developed by combining a deep neural network (DNN) with the simulated annealing optimization algorithm. It is designed to reduce resource underutilization and minimize the number of active hosts in cloud environments. It dynamically allocates resources and handles API requests efficiently. The RAP-Optimizer reduces the number of active physical hosts by an average of 5 per day, leading to a 45% decrease in server costs. The impact of the RAP-Optimizer was observed over a 12-month period. The observational data show a significant improvement in resource utilization. It effectively reduces operational costs from USD 2600 to USD 1250 per month. Furthermore, the RAP-Optimizer increases the profit margin by 179%, from USD 600 to USD 1675 per month. The inclusion of the dynamic dropout control (DDC) algorithm in the DNN training process mitigates overfitting, achieving a 97.48% validation accuracy and a validation loss of 2.82%. These results indicate that the RAP-Optimizer effectively enhances resource management and cost-efficiency in AIaaS applications, making it a valuable solution for modern cloud environments.

1. Introduction

The current cloud application trends demonstrate the rapid growth of AI-driven applications powered by AIaaS as the back-end [1]. As a result, the demand for efficient resource utilization has become paramount [2]. Many innovative cloud-based services, particularly those adopting the AI-as-a-service (AIaaS) model, suffer from underutilization of resources, leading to escalating operational costs [3]. The initial resource utilization assumptions regarding the resource limitation of these applications change as the number of users and API requests increases. That is why service providers face the challenge of managing their physical and virtual resources effectively while maintaining the quality of service (QoS) [4]. The RAP-Optimizer presented in this paper addresses these issues by optimizing resource allocation and minimizing the number of active hosts in AIaaS environments. This system not only reduces server costs but also improves resource efficiency. As a result, it leads to better profit margins and energy savings. The potential of the RAP-Optimizer lies in its ability to dynamically balance API request loads across cloud servers. This is how it prevents the unnecessary activation of additional resources and ensures sustainable and scalable cloud operations.

The proposed RAP-Optimizer was developed by integrating a deep neural network (DNN) [5] with the simulated annealing algorithm [6] to create a robust framework for real-time resource management. The DNN predicts the optimal configuration for virtual machines (VMs) based on real-time data analysis, while the simulated annealing algorithm helps optimize resource allocation by minimizing the number of active hosts. Additionally, the system incorporates a dynamic dropout control (DDC) algorithm to mitigate overfitting issues during the model training phase. The RAP-Optimizer operates in a multi-stage workflow, beginning with resource analysis through the resource analyzer (RAN) algorithm, which identifies underutilized hosts and redistributes API requests to ensure optimal cloud resource usage. By consolidating workloads and deactivating idle hosts, the system can enhance energy efficiency while maintaining the agreed quality of service (QoS) for users. The key contributions of this paper are summarized as follows:

• Dynamic resource optimization: A novel integration of DNN and simulated annealing for dynamically balancing API requests and resource utilization across active cloud hosts.
• Cost reduction mechanism: Demonstrated significant server cost reduction through the RAP-Optimizer, leading to improved profit margins and reduced energy consumption.
• Multi-stage optimization workflow: Introduction of a multi-stage workflow utilizing the RAN algorithm for comprehensive resource analysis, ensuring effective redistribution of workloads across physical and virtual machines.
• Handling overfitting with DDC: An innovative dynamic dropout control (DDC) algorithm integrated into the DNN to overcome overfitting during model training and enhance prediction accuracy.
• Revenue margin increase: The proposed system improved profit margins by 179% over 12 months, increasing the average profit margin from USD 600 to USD 1675.

The remainder of this paper is organized as follows. The literature review is presented in Section 2. Section 3 provides an in-depth problem analysis, identifying the challenges that led to the development of the RAP-Optimizer. Section 4 outlines the methodology, describing the integration of DNN, simulated annealing, and the RAN algorithm, along with the dataset preparation and feature normalization steps. Section 5 presents the experimental results and evaluations, including the performance analysis of the proposed system and its ability to optimize cloud resource usage. Section 6 discusses the limitations and potential future improvements for the RAP-Optimizer. Finally, Section 7 concludes the paper, summarizing the key findings and contributions.

2. Literature Review

Resource optimization in cloud computing is a widely researched topic, particularly in the context of infrastructure-as-a-service (IaaS) and platform-as-a-service (PaaS). However, there remains a significant gap in addressing optimization strategies specifically tailored for AI-as-a-Service (AIaaS) models, which are characterized by fluctuating workloads and high computational demands [7]. This section reviews recent studies on cloud resource optimization, workload balancing, and overfitting issues in deep learning models, identifying gaps that the proposed RAP-Optimizer aims to address.

2.1. Cloud Resource Optimization

According to the survey conducted by Mohammadzadeh et al. [8], resource optimization for traditional cloud services, such as virtual machine (VM) allocation and CPU/RAM resource distribution, is the predominant field of research in cloud resource optimization. AIaaS differs from traditional cloud services, which require real-time, scalable computation [9]. Furthermore, most solutions, like the hill-climbing (HC) algorithm, operate reactively and often activate new physical hosts without fully utilizing existing resources, resulting in higher operational costs [10]. The proposed RAP-Optimizer addresses this gap by integrating a DNN with simulated annealing [6] to dynamically allocate resources based on real-time workloads and optimize resource utilization.

2.2. Workload Balancing and API Request Handling

Numerous studies have examined workload balancing in cloud environments [11,12,13]. However, these approaches generally focus on static or semi-dynamic strategies that do not adapt quickly to the rapidly changing workload patterns seen in AIaaS platforms. For example, Kumar et al. [14] presented an approach for balancing workloads across cloud servers but did not consider the possibility of reducing the number of active hosts when resources are underutilized. Additionally, ref. [15] emphasized load distribution based on CPU and memory but did not consider network bandwidth and other critical factors such as disk I/O [16]. In contrast, the RAP-Optimizer efficiently reallocates API requests by utilizing fewer physical hosts while ensuring maximum CPU and memory utilization, thus overcoming the limitations of static workload balancing methods.

2.3. Overfitting in Deep Neural Networks

Handling overfitting in DNNs is an active field of research with numerous regularization techniques [17]. According to Alnagashi et al. [18] dropout is an effective way to mitigate the overfitting issue. A review conducted by Salehin et al. [19] on different dropout techniques reveals that most approaches use a fixed dropout rate. The literature shows that while dropout can be effective, it is not adaptive to different layers of the network, leading to either underfitting or overfitting in complex applications [20]. This paper fills this gap by introducing the dynamic dropout control (DDC) algorithm, which dynamically adjusts the dropout rate layer-by-layer, reducing the overfitting issue without compromising the model’s predictive performance.

2.4. Energy-Efficient Cloud Systems

The optimization of energy consumption in cloud data centers has been explored in various studies [21,22,23]. The primary focus of these is to reduce energy consumption by consolidating VMs or activating power-saving modes on underutilized hosts [24]. However, the existing methods primarily focus on reducing the number of active physical hosts without considering the trade-off between resource optimization and maintaining service quality [25]. The proposed RAP-Optimizer not only reduces the number of active hosts by an average of five per day, but it also improves resource utilization, resulting in substantial energy savings without degrading the quality of service (QoS).

2.5. Revenue Impact and Cost Optimization

Revenue impact and corresponding cost optimization is an under-explored field of research for AIaaS [26]. Multiple studies revolve around traditional cloud services [27,28,29]. However, these studies do not account for the dynamic and unpredictable nature of AIaaS platforms, where the operational cost can escalate quickly due to inefficient resource management [30]. The RAP-Optimizer directly addresses this gap by significantly reducing server costs—by 45% on average—while maintaining consistent service delivery. This allows AIaaS platforms to stabilize their profit margins over time, which is often overlooked in traditional cloud optimization research.

2.6. Comparison with Existing Technologies

Current cloud resource optimization techniques, including conventional autoscaling [31] and rule-based allocation models [32], offer reliable performance in predictable workloads but struggle in complex AI-as-a-service (AIaaS) applications where demand can be highly variable and unpredictable. Many approaches activate additional resources reactively without assessing overall resource utilization, leading to increased operational costs and underutilized resources [33].

In contrast, the proposed RAP-Optimizer is uniquely equipped to handle such dynamic conditions by integrating a deep neural network (DNN) for predictive VM configuration alongside the simulated annealing algorithm, which efficiently minimizes active host usage. Additionally, the dynamic dropout control (DDC) mechanism prevents overfitting during model training, ensuring accurate, real-time predictions even as workloads fluctuate. This combination allows RAP-Optimizer to consolidate workloads onto fewer hosts, dynamically redistribute API requests, and deactivate idle hosts, achieving up to 45% reduction in server costs, as shown in our experimental analysis. These attributes demonstrate RAP-Optimizer’s ability to maintain high resource utilization and reduce costs effectively in challenging AIaaS scenarios. The summary of the comparison of the proposed system with existing technology is listed in

Table 1. Comparison of RAP-Optimizer with existing resource optimization methods.

Optimization Model	Advantages	Limitations
Hill-Climbing (HC) Algorithm	Simple and effective for static resource allocation.	Operates reactively; does not maximize existing resource utilization; high cost in dynamic workloads
CEDULE+	Predictive analytics for burstable instances, good for CPU optimization	Limited in API request reallocation; moderate cost savings; does not address DNN overfitting issues
Conventional Autoscaling	Reliable for predictable workloads; quick resource activation	Activates new hosts frequently without utilization check; costly in AIaaS with variable workloads
RAP-Optimizer (Proposed)	Predictive DNN with dynamic dropout control; proactive host deactivation; 45% cost savings	Initial setup complexity requires training data; potential cost without mobility-aware routing.

.

3. Problem Analysis and Objective

This paper developed a solution for an AI-driven image enhancement web application. It follows the AI-as-a-service model with a pay-as-you-go billing method. The initial margin between server cost and the overall subscription fee of the application is convenient which is illustrated in Figure 1. This figure shows the relationship among server cost, return, and revenue margin over a 12-month period of time. However, eventually, with the popularity, the margin narrowed down. As a result, the application’s revenue flow started impacting the business model’s overall sustainability. Figure 1. The reason behind this fall in revenue is the increase in the number of active hosts. Further investigation shows the computing resources in the active hosts are not fully utilized. Although there are scopes for handling more API calls with the existing hosts, the system activates new hosts. As a result, the operational cost increases. The challenge is identifying the under-utilized host servers, allocating the new requests to these hosts, and reducing the number of active hosts. In this way, the operational cost can be minimized, increasing the profit margin at a sustainable level. The proposed methodology was developed to achieve this objective.

4. Methodology

The overview of the proposed methodology is illustrated in Figure 2. It starts with dataset processing, constructed from the experiment’s AIaaS application log files. Later, a well-optimized DNN architecture is developed to predict the appropriate configuration for a service request. After that, an innovative approach of reducing the overfitting effect and shifting to balance learning is incorporated into the network during the training process. The trained DNN was used to develop the RAP-Optimizer, which consists of a resource analysis module, resource space landscape, and a novel deep-annealing algorithm.

4.1. Application-Specific Adaptability and Resource Requirements

The RAP-Optimizer is designed to dynamically adapt to the characteristics of the AIaaS application it manages, with specific consideration given to image size, processing complexity, and frequency of API requests. In this study, the AIaaS application performs image enhancement, which demands substantial processing power depending on the size and quality of the images processed. For example, larger images or those requiring high-resolution outputs necessitate more virtual CPU cores and memory allocation due to increased computational demands.

The system determines the resource allocation based on these application-specific parameters. For instance, when processing high-resolution images, the DNN model predicts a configuration with additional CPU and memory resources for the corresponding VMs. This ensures the required computational power is available without over-provisioning resources. Additionally, the RAP-Optimizer monitors ongoing resource utilization to adjust allocations as image processing demands fluctuate, preventing unnecessary host activations and optimizing the allocation of VMs based on workload intensity.

4.2. Dataset Preparation

This study uses a unique dataset prepared from the AIaaS application log and a sample of the dataset is presented in

Table 2. A modified sample of the dataset with all target variables.

Peak Frequency	Active Time (hours)	API Initiation Count	Service Requests	vCPU	vRAM (GB)	vDisk (GB)	Energy Usage (Wh)	Cloud Configuration
2	0.25	12	1500	2	1.5	0.6	10	Basic
4	0.45	30	1800	4	2.5	1	40	Standard
7	1.5	220	6200	5	4	2.5	50	Intermediate
8	3.2	340	8300	7	6	3.5	75	Advanced
11	5.8	550	11,200	9	8	5	95	Premium

. The application maintains three types of log files, which are the activity log ($Lo{g}_{ac}$), system log ($Lo{g}_{st}$), and application log ($Lo{g}_{ap}$). The relationships among these logs are illustrated in Figure 3. The $Lo{g}_{ac}$ keeps track of the user interaction, $Lo{g}_{st}$ is responsible for keeping track of computational resource usage, and $Lo{g}_{ap}$ is dedicated to application-related data. All data from these logs are converted into comma-separated value (CSV) format [34]. After that, the instances are categorized into five classes as presented in Table 2. The Pearson correlation coefficient (PCC) score, calculated using Equation (1), was used to identify the relevant features that have a strong correlation with the five classes [35].

$$r={\displaystyle \frac{{\sum }_{i=1}^n(X_i-\overline{X})(Y_i-\overline{Y})}{\sqrt{{\sum }_{i=1}^n{(X_i-\overline{X})}^2}\sqrt{{\sum }_{i=1}^n{(Y_i-\overline{Y})}^2}}}$$

(1)

In Equation (1), $X_i$ represents the individual feature values, $Y_i$ stands for the individual target variable, $\overline{X}$ denotes the mean of the features, $\overline{Y}$ denotes the mean of the target variable, and n denotes the total data points. It generates the linear correlation score (r) between X and Y with a range from $-1$ to $+1$, where the former represents a perfect negative correlation and the latter denotes a perfect positive correlation.

4.2.1. Dataset Description

The dataset contains records of the experimental application for 365 days. After cleaning, there are 142,784 instances in the dataset. The feature variables are peak frequency, active time (hours), API initiation count, service requests, virtual CPU, virtual RAM (GB), virtual disk (GB), energy usage (Wh), and cloud configuration. Except for the target variable, all other features are numerical. The target variable is categorical, which has five categories.

4.2.2. Dataset Cleaning

The CSV file constructed from $Lo{g}_{a}c$, $Lo{g}_{s}t$, and $Lo{g}_{a}p$ contains numerous incomplete rows. These rows were created for multiple reasons, including incomplete service requests, API initialization failure, and network issues. In addition, there are multiple duplicate rows. The uncleaned dataset has 163,150 instances. This dataset was cleaned by following the mathematical principle defined in Equation (2).

$$C^{*}=\{y\in C\mid \forall z_j\in Z,y_j\ne \mathrm{null}\}$$

(2)

In Equation (2), C represents the uncleaned dataset. It contains n records, where $C=y_1,y_2,\dots ,y_n$ and each $y_i$ corresponds to the $i^{th}$ observation vector across all variables $Z=z_1,z_2,\dots ,z_p$. The cleaned dataset $C$ includes only those observations from C where no variable in the observation vector is missing, denoted by “null”. Additionally, outliers from C, determined using the mean ${\mu }_c$ and standard deviation ${\sigma }_c$, are eliminated based on the rule in Equation (3) [36]. A data point $y\in C$ is classified as an outlier if it satisfies $y<{\mu }_c-b·{\sigma }_c\mathrm{or}y>{\mu }_c+b·{\sigma }_c$, where b is a constant set to 3 according to the empirical 68-95-99.7 rule. The result is a dataset $C$ with no outliers [37].

$$C^{*}=\{y\in C\mid {\mu }_c-b·{\sigma }_c\le y\le {\mu }_c+b·{\sigma }_c\}$$

(3)

To clarify, in this context, C consistently denotes the uncleaned dataset with missing values and outliers, while $C^{*}$ represents the cleaned dataset that is devoid of any missing values or outliers. This distinction between C and $C^{*}$ helps to clearly understand the process of dataset preparation for the training phase. Although this cleaning process reduces the number of entries, the final count is 142,784 instances after cleaning, which is sufficient to train a deep neural network (DNN) to classify the target variables using the input features.

4.2.3. Feature Normalization

The feature variables exhibit a wide range of variations in the dataset, so feature normalization is essential [38]. Z-score normalization was chosen to normalize the features because it effectively handles data with varying scales and distributions. Figure 4 illustrates the difference in data range before and after performing the normalization. The Z-score normalization process for a feature $x_i$ is defined in Equation (4) [39].

$$x_i^{\prime }={\displaystyle \frac{x_i-{\mu }_x}{{\sigma }_x}}$$

(4)

In Equation (4), $x_i$ denotes the original feature value, ${\mu }_x$ denotes the mean of the feature x, ${\sigma }_x$ denotes the standard deviation of the feature x, and $x_i^{\prime }$ denotes the normalized feature value. Here, i denotes the range, which is from 1 to 142,784. After applying Z-score normalization, the feature values are transformed, such that the dataset has a mean of zero and a standard deviation of one, ensuring all features contribute equally during model training [40].

4.2.4. Dataset Splitting

Ullah et al. [41] conducted a systematic review of machine learning (ML) applications, showing that most state-of-the-art approaches use a 70:15:15 dataset splitting ratio for training, testing, and validation datasets, respectively. The same ratio was used in this study. There are a total of 142,784 instances in the cleaned dataset. At the 70:15:15 ratio, there are 99,948 instances for training, 21,417 instances for training, and the same number for validation.

4.2.5. Dataset Characteristics and Generalizability

The dataset used in this study originates from an AI-driven image enhancement web application operating under the AI-as-a-service (AIaaS) model. That means the dataset represents real-world characteristics. The AI-driven application from which the data were collected processes a high volume of real-time API requests. Depending on the type of processing, the resource demands fluctuate. The user activity and the workload intensity have a significant impact on this fluctuation. The real-world workload patterns reflected in the dataset represent regular and peak activities, which are essential for rapid resource scaling. This dataset contains the consumption history of computing resources, including CPU, memory, and network resource allocation, which is typical of many AIaaS applications. Resource utilization needs are also diverse, with some processes intermittently requiring high computational power. These characteristics are common for various AIaaS applications. When the applications are designed to enhance images, these are the essential characteristics. Moreover, these features reflect the common properties of real-time AIaaS applications. Considering everything, the dataset prepared and utilized in this experiment supports generalization when applied for AIaaS application resource optimization.

4.3. Network Architecture

A deep neural network (DNN) was designed as the resource predictor of the proposed RAP-Optimizer. It is a six-layer network designed using the concept of a fully connected network architecture. It is illustrated in Figure 5. There are a total of four hidden layers. Including the input and output layers, the overall network is a six-layer network. The input layer supports an 8-dimensional feature vector defined as $[x_1,x_2,\dots ,x_8]$. The hidden layers in Figure 5 are expressed by $h_1$, $h_2$, $h_3$, and $h_4$. Each layer has 32 neurons, which allows the network to intercept complex representations of the data. The network architecture was carefully designed to predict the cloud configuration requirements when AIaaS applications are initiated. The optimal dropout rate plays a crucial role in ensuring the reliable performance of the network. That is why an innovative dynamic dropout control (DDC) algorithm was prepared in this study. It was designed and integrated with the network to adjust the dropout rate of each layer dynamically for optimal unbiased performance. The working principle of the input layer is expressed by Equation (5). The input layer simply transposes the input vectors [42].

$$\mathit{\xi }={[{\xi }_1,{\xi }_2,\dots ,{\xi }_{\eta }]}^T$$

(5)

The input layer, after transposing the feature vectors, passes them to the hidden layers. The input vector, expressed as ${\mathit{\chi }}^{[l-1]}$, is processed by the hidden layers using a weight matrix ${\mathsf{\Omega }}^{[l]}$, a bias vector ${\mathit{\zeta }}^{[l]}$, and the rectified linear unit (ReLU) activation function, denoted as $\phi (·)$, described in Equation (7). For layer l, the transformation is formulated in Equation (6), where $l=1,2,\dots ,5$, and the dimensions of the weight matrices and bias vectors are ${\mathsf{\Omega }}^{[l]}\in {\mathbb{R}}^{32\times 8}$ and ${\mathit{\zeta }}^{[l]}\in {\mathbb{R}}^{32}$, respectively, [43].

$${\mathit{\chi }}^{[l]}=\phi ({\mathsf{\Omega }}^{[l]}{\mathit{\chi }}^{[l-1]}+{\mathit{\zeta }}^{[l]})$$

(6)

$$\phi (\xi )=\left\{\begin{array}{cc}\xi \hfill & \mathrm{if}\xi >0,\hfill \\ 0\hfill & \mathrm{otherwise}.\hfill \end{array}\right.$$

(7)

The dataset has five target classes. The output layer of the network designed in this section was prepared to predict those classes. That is why it has five nodes. Each node represents one of the five target classes. The activation function used in this layer is the Softmax function, which is defined in Equation (8). The only role of this activation function is to convert the raw output values into probabilities. Given an input, $\mathit{\xi }$, the logits ${\varsigma }_i$ are obtained through a linear transformation, followed by the Softmax function to compute the probabilities ${\upsilon }_i$ for each class i, where $i=1,\dots ,5$ [44].

$${\upsilon }_i={\displaystyle \frac{exp({\varsigma }_i)}{{\sum }_{j=1}^{5}exp({\varsigma }_j)}}$$

(8)

Optimal VM Configuration Predicted by DNN

The main purpose of the DNN designed in this section is to work as a VM configuration predictor. It is integrated with the RAP-Optimizer, and it predicts the optimal configuration for virtual machines (VMs) by analyzing real-time data on system load and resource availability. Multiple parameters participate in the prediction. These parameters are CPU cores, memory, storage, and expected API request load. The DNN was trained on these parameters as well. As a result, it is capable of predicting the VM configurations for a certain combination of these parameters. The primary goal of the DNN is to predict the configuration to minimize idle time and maximize resource utilization on active hosts. By accurately forecasting the configuration needed for each VM, the DNN prevents unnecessary resource allocation. As a result, each VM is provisioned with the optimal amount of resources for its workload.

4.4. Training the Network

The network is trained using the backpropagation algorithm [45]. During the forward pass, input data $\mathit{\xi }$ propagate through the network, and each layer l calculates its output ${\mathit{\chi }}^{[l]}$ as a function of the input from the previous layer ${\mathit{\chi }}^{[l-1]}$, employing its weight matrix ${\mathsf{\Omega }}^{[l]}$, bias vector ${\mathit{\zeta }}^{[l]}$, and activation function ${\sigma }^{[l]}$. This process continues through all layers until the output prediction $\widehat{\mathit{\upsilon }}$ is made. The prediction is then compared to the true labels $\mathit{\upsilon }$ using a loss function, defined in Equation (9), which measures the difference between predicted and actual values [46]. In this equation, $\Gamma$ represents the number of output classes, ${\upsilon }_i$ denotes the true label, and ${\widehat{\upsilon }}_i$ denotes the predicted probability for class i [47].

$$\mathcal{L}(\mathit{\upsilon },\widehat{\mathit{\upsilon }})=-{\displaystyle \sum _{i=1}^{\Gamma }}{\upsilon }_{i}log({\widehat{\upsilon }}_i)$$

(9)

4.4.1. Learning Algorithm

The adaptive moment estimation (ADAM) optimizer is used to update the weights of the network’s hidden nodes. Initially, the vectors ${\mu }_0$ and ${\nu }_0$ are set to zero, and the time step $\tau$ is initialized to zero. The learning rate is represented by $\alpha$, and ${\beta }_1$, and ${\beta }_2$ are the decay rates for moment estimates, initialized to 0.90. At each time step $\tau$, the gradients ${\nabla }_{\theta }\mathcal{J}(\theta )$ with respect to the parameters $\theta$ are calculated. The updates for ${\mu }_{\tau }$ and ${\nu }_{\tau }$ are defined by Equations (10) and (11) [48].

$${\mu }_{\tau }={\beta }_1{\mu }_{\tau -1}+(1-{\beta }_1){\nabla }_{\theta }\mathcal{J}(\theta )$$

(10)

$${\nu }_{\tau }={\beta }_2{\nu }_{\tau -1}+(1-{\beta }_2){({\nabla }_{\theta }\mathcal{J}(\theta ))}^2$$

(11)

The bias-corrected estimates for ${\mu }_{\tau }$ and ${\nu }_{\tau }$ are given by Equations (12) and (13).

$${\widehat{\mu }}_{\tau }={\displaystyle \frac{{\mu }_{\tau }}{1-{\beta }_1^{\tau }}}$$

(12)

$${\widehat{\nu }}_{\tau }={\displaystyle \frac{{\nu }_{\tau }}{1-{\beta }_2^{\tau }}}$$

(13)

Finally, the weights $\omega$ are updated using Equation (14), where $ϵ$ is a small constant for numerical stability.

$$\omega =\omega -\alpha {\displaystyle \frac{{\widehat{\mu }}_{\tau }}{\sqrt{{\widehat{\nu }}_{\tau }}+ϵ}}$$

(14)

At the 70:15:15 ratio, there are 99,948 instances for training, 21,417 instances for training, and the same number for validation.

4.4.2. Learning Curve

The training dataset contains 99,948 instances. To enhance training efficiency, mini-batches of size 64 are utilized. The learning curve, depicting the progress of both accuracy and loss for training and validation, is presented in Figure 6. It showcases the network’s performance over 50 epochs with 111,550 iterations, taking approximately 8 h and 27 min to complete. The validation accuracy achieved is 97.48%, with a validation loss of 2.82%, while the training accuracy and loss are 95.15% and 4.85%, respectively.

4.4.3. DDC Algorithm

During the development phase of the RAP-Optimizer, it was observed that the network overfits after training. The number of hidden layers and nodes of the existing layers was reduced to minimize overfitting. After the modification, the network exhibits underfitting characteristics.

Table 3. Impacts of different network configurations on overfitting and underfitting characteristics in the RAP-Optimizer.

Network Configuration	Number of Hidden Layers	Neurons per Layer	Characteristics	Observed Behavior
Initial Configuration	6	32	Overfitting	High training accuracy, low validation accuracy.
Modified Configuration 1	5	32	Overfitting	Overfitting persists, validation accuracy slightly improves but still significantly lower than training.
Modified Configuration 2	4	32	Overfitting	Moderate overfitting; slight improvement in validation performance, but gap remains.
Modified Configuration 3	3	16	Overfitting	Reduced overfitting but validation accuracy still does not match training accuracy.
Modified Configuration 4	4	8	Underfitting	Model starts underfitting; both training and validation accuracy are low.
Modified Configuration 5	4	4	Underfitting	Significant underfitting; both accuracies remain low, model complexity too reduced.
Modified Configuration 6	2	16	Underfitting	Underfitting persists, accuracy too low for both training and validation.
Modified Configuration 7	1	32	Underfitting	Severe underfitting; network too shallow to capture complex patterns.

shows different configurations explored during the development and the characteristics of the network along with other parameters. To ensure balanced fitting, the innovative DDC algorithm, presented as Algorithm 1, was developed and integrated into the network. It gradually discovers the optimal number dropout rate for different hidden layers and balances an overfitting network.

The initial dropout rate $p_0$ and the threshold $\delta$ were chosen based on empirical testing. Starting with a moderate value for $p_0$, set to 0.2, provided a balanced starting point that allowed sufficient dropout without a sharp reduction in performance. This value was selected after trials indicated that lower dropout rates (e.g., below 0.1) had limited impact on overfitting, while higher rates (e.g., above 0.3) led to underfitting. The threshold $\delta$, which determines the acceptable accuracy gap between training and validation, was set based on performance analysis; a value of 0.02 (or 2%) was found effective in preventing overfitting without sacrificing validation performance. These parameters are adjustable to account for specific data characteristics and can be tuned further as required by different workloads or applications.

Algorithm 1 Dynamic dropout control (DDC) algorithm.

1: Input: Trained network $\mathcal{N}$, Training set $X_{train}$, Validation set $X_{val}$, Initial dropout rate $p_0$, Number of layers L, Dropout increment $\Delta p$, Threshold $\delta$   2: Output: Modified network with minimized overfitting   3: Initialize $p\leftarrow p_0$   4: Compute initial accuracies ${\mathrm{Acc}}_{train},{\mathrm{Acc}}_{val}$   5: $\Delta \leftarrow {\mathrm{Acc}}_{train}-{\mathrm{Acc}}_{val}$   6: while $\Delta >\delta$ do   7:     for $l=1$ to L do   8:         if first iteration then   9:            ${\mathbf{h}}^{[l]}\leftarrow \mathrm{Dropout}({\mathbf{h}}^{[l]},p)$ 10:         else 11:            Increase dropout: $p\leftarrow p+\Delta p$ 12:            ${\mathbf{h}}^{[l]}\leftarrow \mathrm{Dropout}({\mathbf{h}}^{[l]},p)$ 13:         end if 14:     end for 15:     Recompute ${\mathrm{Acc}}_{train},{\mathrm{Acc}}_{val}$ 16:     Update $\Delta \leftarrow {\mathrm{Acc}}_{train}-{\mathrm{Acc}}_{val}$ 17: end while 18: Return $\mathcal{N}$ with reduced overfitting

4.4.4. Achieving Optimal Unbiased Performance with DDC

The dynamic dropout control (DDC) algorithm is designed to maintain an optimal unbiased performance by dynamically adjusting dropout rates to mitigate overfitting or underfitting. Unbiased performance is defined by balanced training and validation accuracy, where the gap between these accuracies remains within 2–3%. Overfitting is indicated when training accuracy significantly exceeds validation accuracy, while underfitting is evident when both accuracies are low. The DDC algorithm progressively adjusts dropout rates for each layer, reducing the gap between training and validation accuracy and achieving a stable performance level where neither overfitting nor underfitting dominates.

4.4.5. VM Resource Requirements for AIaaS Workloads

The AIaaS application’s resource indicators are determined by the processing demands of each incoming task. For image enhancement applications, the system assesses metrics such as image size (in pixels) and required processing time to establish optimal VM configurations. VMs with varying CPU, memory, and storage allocations are configured to meet these processing requirements efficiently. For instance, tasks involving high-resolution images may require up to 8 CPU cores and 64 GB of memory, while lower-resolution tasks may only require 2 cores and 16 GB of memory. This dynamic configuration ensures that the RAP-Optimizer adapts VM allocations according to workload intensity, promoting efficient resource usage even as demand fluctuates.

4.5. RAP-Optimizer

The proposed RAP-Optimizer is an innovative approach that starts with resource analysis. After that, the resource space landscape is generated to evaluate the resource distribution. Finally, it combines DNN with the simulated annealing optimization to optimize the cloud resource without compromising the service quality.

4.5.1. Resource Analysis

The RAP-Optimizer starts with resource analysis, performed using the resource analyzer (RAN) algorithm, presented as Algorithm 2, developed in this study. The RAN algorithm requires access and scanning permission for both virtual machines (VMs) and their physical hosts. Initially, it scans the entire system, identifies the active VMs through their unique ID (VID), retrieves their current configurations, and fetches the resource consumption history. The resource consumption history is stored in the VM log, which is fetched by the $re{s}_{h}ist(vm)$ function. After that, it explores the physical hosts supporting the VMs. It performs similar operations on physical hosts. Finally, it scans the idle physical hosts. The RAN algorithm maintains a resource status table (RT) which is frequently updated. Based on the resource consumption, it generates a Resource Space (RS) represented by bar graphs.

Algorithm 2 Resource analyzer (RAN) algorithm

1: procedure RAN_Optimizer   2:     Input: Access permissions for VMs and physical hosts   3:     Output: $RS$, Updated $RT$   4:     Initialize: $RT\leftarrow Init(RoutingTable)$   5:     Scan system and fetch VMs and Hosts   6:     for $vm\in VMs$ do                                                                                       ▹ For each VM   7:         Identify active VMs: $vm\leftarrow ID(vm)$   8:         Get VM configurations: $cfg(vm)$   9:         Fetch resource history: $res\_hist(vm)$ 10:     end for 11:     for $host\in Hosts$ do                                                                                    ▹ For each host 12:         Get host configurations: $cfg(host)$ 13:         Fetch resource history: $res\_hist(host)$ 14:     end for 15:     Scan idle hosts: $idle\_hosts\leftarrow Scan(Hosts)$ 16:     Update: $RT\leftarrow Update(cfg,res\_hist)$ 17:     Generate: $RS\leftarrow (VID,Resource)$ 18:     return $RS,RT$                                  ▹ Return both Resource Space and Routing Table 19: end procedure

4.5.2. Resource Space Landscape (RSL)

The RAN algorithm returns the RS and RT, where the VM configurations, current resource consumption rate, IDs of the VMs ($VID$), corresponding physical hosts, and other relevant data are available. These data are used to prepare the RSL, showing active VMs in physical hosts. The RSL of a random instance is illustrated in Figure 7. The data center offering the AIaaS consists of 16 physical hosts in each server rack. The experimental environment has 3 server racks. According to the organization’s policy, a maximum of 10 VMs are allowed concurrently in a single host to maintain the terms of services (TOS). Each physical host is powered by a 10-core CPU with 128 GB primary memory.

4.5.3. Deep-Annealing Algorithm

The RAP-Optimizer combines the DNN presented in Section 4.3 and the simulated annealing algorithm, which was named deep-annealing and presented in Algorithm 3. The process starts by connecting to the AIaaS Data Center (AIDC) with permission to access the status of all physical and virtual devices. It applies the RAN Analyzer algorithm to retrieve the resource space (RS) and resource table (RT), which include the VM configurations, current resource usage, and corresponding physical hosts. These outputs provide a comprehensive view of the system’s resource space ($RSS$). After that, the deep-annealing algorithm utilizes the DNN to predict the VM configuration and respond to the request for subsequent AI services. The deep-annealing algorithm identifies hosts for VM deployment. It explores potential hosts iteratively, evaluating the cost ($cost$) and objective ($obj$) functions to select a suitable host. The ($cost$) looks for the lowest possible value, whereas the role of the ($obj$) function is to find out the highest possible value on the resource space. The process begins at a high-temperature state, allowing probabilistic acceptance of less optimal solutions to escape local minima. The $HasCapacity()$ function is used to check whether the current host has sufficient resources for the new VM whose configuration was predicted by the DNN. When sufficient resources are available, the $CreateInstance()$ function is used to deploy the VM. It may happen that the current host does not have enough resources. In this case, the algorithm uses the $NextHost()$ function. This function uses the probability distribution influenced by the current temperature. This process allows a broader exploration of the available configurations.

The proposed method, the RAP-Optimizer, is periodically called with an interval of 15 min. Every time it is called, it monitors the resources and optimizes them. The user pattern shows that the average active period of the users is 15 min. That is why this period was used. This interval ensures that the proposed system maintains a real-time adaptation to the changing workloads. It further minimizes the excessive computational overhead. Every time the RAP-Optimizer is initialized, it is called the deep-annealing method. However, it depends on the need for resource distribution. The RAP-Optimizer performs an initial resource analysis. This analysis identifies the underutilized hosts or overloaded hosts. When it is necessary to optimize the resources, the RAP-Optimizer invokes the deep-annealing method. It adjusts the allocation of virtual machines across hosts. As a result, the system minimizes the number of active hosts while maintaining performance requirements.

Algorithm 3 Deep-annealing algorithm

1: $\mathit{AIDC}\leftarrow \mathrm{Connect}(credentials)$   2: $(RS,RT)\leftarrow \mathrm{RAN}\mathrm{Analyzer}(\mathit{AIDC})$   3: ${\widehat{C}}_{VM}\leftarrow \mathrm{DNN}(\mathit{RS},\mathit{RT})$   4: $\mathit{RSS}\leftarrow \mathrm{RetrieveResourceSpace}(\mathit{RS},\mathit{RT})$   5: Initialize temperature T   6: $(H_{start})\leftarrow \mathrm{SimulatedAnnealing}(\mathit{RSS},\mathit{obj},\mathit{cost},T)$   7: while $\neg \mathrm{InstanceCreated}$ and $T>T_{\min }$ do   8:     if $\mathrm{HasCapacity}(H_{start},{\widehat{C}}_{VM})$ then   9:         $\mathrm{CreateInstance}(H_{start},VM)$ 10:         $\mathit{InstanceCreated}\leftarrow \mathrm{True}$ 11:     else 12:         $H_{start}\leftarrow \mathrm{NextHost}(H_{start},\mathit{RSS},T)$ 13:         Decrease temperature $T\leftarrow \alpha T$ 14:     end if 15: end while 16: for $vm\in \mathit{AIDC}$ do 17:     if $\mathrm{CanMigrate}(vm,H_{start})$ then 18:         $\mathrm{Migrate}(vm,H_{start})$ 19:     end if 20: end for

If the initially selected host lacks sufficient resources for the VM deployment, $NextHost()$ identifies alternative hosts based on a probability distribution influenced by the current temperature T. This ensures the search process avoids local optima and explores a wider range of configurations. As the temperature gradually decreases with each iteration by a factor $\alpha$, the exploration process narrows down to focus on optimal hosts for VM deployment. Once a suitable host is found and the VM instance is deployed, the algorithm evaluates potential migrations for existing VMs to optimize overall resource usage. The function $CanMigrate()$ checks whether a VM can be moved to a host that offers better resource efficiency, and if migration is feasible, the $Migrate()$ function performs the transfer. The $CanMigrate()$ function evaluates both the feasibility of migrating a VM and the suitability of potential target hosts. This function checks migration feasibility based on the current resource utilization, performance requirements, and network stability. If a VM’s migration is feasible without disrupting service quality, the function proceeds to identify a suitable host. The target host is selected based on its available CPU, memory, and network capacity, ensuring it meets the requirements of the migrating VM. Additionally, the CanMigrate() function prioritizes hosts with higher resource availability and lower current workloads to maximize efficiency and maintain balanced resource utilization across the data center. The $Migrate()$ function initiates VM migration to optimize resource allocation. To ensure system stability and avoid overloading resources, a limit is applied to the number of simultaneous VM migrations. This cap allows the RAP-Optimizer to manage migrations efficiently, preventing potential performance degradation caused by excessive concurrent migrations. This process ultimately aims to consolidate workloads, improve resource utilization, and reduce the operational costs associated with idle hosts.

4.5.4. Criteria for Optimal Resource Usage

The RAP-Optimizer establishes optimal cloud resource usage by evaluating key metrics such as CPU, memory, and bandwidth utilization across active hosts. Optimal usage is achieved when resources are maximally utilized without exceeding predefined thresholds that could lead to performance degradation or resource contention. Specifically, CPU and memory utilization levels above 85% but below 95% are considered optimal, ensuring sufficient headroom for unexpected loads while maximizing efficiency. Bandwidth utilization is similarly monitored, with an upper threshold set to prevent network bottlenecks. The RAP-Optimizer dynamically manages these resources to maintain this balance, activating additional hosts only when existing hosts reach their optimal utilization limits.

4.6. Mobility-Aware Resource Allocation

To optimize routing costs and enhance the efficiency of RAP-Optimizer in resource-limited networks, we introduce a mobility-aware component to the resource allocation process. This enhancement considers not only the current utility of host servers but also their physical proximity to service requesters. Inspired by recent advancements in mobility-aware routing, as discussed in [49], this modification enables RAP-Optimizer to prioritize host servers that are geographically closer to service requesters, thereby reducing the overall routing costs.

Specifically, this approach calculates the distance-based routing cost $R_c$ using Equation (15), where $d_{ij}$ represents the distance between the service requester i and the host server j, and w is a weighting factor that adjusts the impact of distance on the overall resource allocation cost:

$$R_c=w\times d_{ij}$$

(15)

During the request allocation phase, RAP-Optimizer now evaluates both resource availability and routing cost, selecting host servers that offer low utility but are also in close proximity to the requester, thereby minimizing latency and operational costs. This adjustment ensures that the RAP-Optimizer remains effective even under resource constraints, maintaining performance gains while addressing network distance considerations.

5. Experimental Result and Evaluation

5.1. Evaluation Metrics

The overall performance of the RAP-Optimizer depends on the prediction quality of the DNN developed in this study. The performance of this DNN was evaluated using accuracy, precision, recall, and F1 score. These are the most frequently used evaluation metrics for machine learning approaches [50]. These metrics are defined in Equations (16), (17), (18), and (19), respectively, which are dependent on true positive (TP), true negative (TN), false positive (FP), and false negative (FN). This study retrieves these values from the confusion matrix illustrated in Figure 8.

$$\mathrm{Accuracy}={\displaystyle \frac{\mathrm{TP}+\mathrm{TN}}{\mathrm{TP}+\mathrm{TN}+\mathrm{FP}+\mathrm{FN}}}$$

(16)

$$\mathrm{Precision}={\displaystyle \frac{\mathrm{TP}}{\mathrm{TP}+\mathrm{FP}}}$$

(17)

$$\mathrm{Recall}={\displaystyle \frac{\mathrm{TP}}{\mathrm{TP}+\mathrm{FN}}}$$

(18)

$$\mathrm{F}1\mathrm{Score}={\displaystyle \frac{2\times (\mathrm{Precision}\times \mathrm{Recall})}{\mathrm{Precision}+\mathrm{Recall}}}$$

(19)

Apart from ML performance evaluation metrics, the RAP-Optimizer performance was evaluated based on the capability of reducing the number of active hosts, improving API request management, and resource optimization [11,51]. Moreover, the overall objective achievement was used as an evaluation metric as well.

5.2. Confusion Matrix Analysis

The confusion matrix analysis reveals the performance of the classification model across five target classes: Basic, Standard, Intermediate, Advanced, and Premium, with an overall accuracy of 96.1%. The precision values vary slightly among the classes, with Basic achieving the highest precision at 97.7%, followed by Premium at 97.7%, Intermediate at 97.4%, Advanced at 97.3%, and Standard at 96.9%. Recall values indicate how well the model identifies each class, with Premium leading at 98.0%, followed by Basic at 97.3%, Standard at 97.2%, Intermediate at 97.4%, and Advanced at 97.2%. The F1 scores, which balance precision and recall, are consistent across the classes, with Basic at 97.5%, Standard at 97.0%, Intermediate at 97.4%, Advanced at 97.3%, and Premium at 97.8%. These metrics suggest that the model performs well overall, but slight variations exist between classes in terms of how accurately they are classified and identified.

5.3. K-Fold Cross-Validation

K-fold cross-validation is a robust method used to evaluate the performance of machine learning models by splitting the dataset into multiple folds. In this analysis, six folds were used, as shown in

Table 4. Performance Evaluation using K-Fold Cross-Validation.

Metrics	Fold 1	Fold 2	Fold 3	Fold 4	Fold 5	Fold 6	Average
Accuracy	0.962	0.961	0.964	0.96	0.963	0.961	0.9618
Precision	0.975	0.976	0.973	0.977	0.974	0.976	0.9751
Recall	0.97	0.969	0.971	0.968	0.97	0.969	0.9695
F1 score	0.972	0.971	0.973	0.97	0.972	0.971	0.9715

, with slight variations observed across each fold for metrics such as accuracy, precision, recall, and F1 score. The average values were calculated across all folds to provide a reliable overall assessment. Accuracy remained consistent, ranging from 96.0% to 96.4%, while precision ranged between 97.3% and 97.7%. Recall and the F1 score also showed slight variations, with recall values between 96.8% and 97.6% and F1 scores between 97.0% and 97.3%. The spider chart in Figure 9 visually represents the performance across the metrics, emphasizing the stability and effectiveness of the model across the different folds, providing confidence in its generalizability.

5.4. Active Physical Host

Table 5. The number of active hosts per 24 h before and after using the deep-annealing algorithm.

Weeks	Number of Active Host Per 24 h		Reduction
	Without Deep-Annealing	With Deep-Annealing
1	36	30	6
2	29	22	7
3	37	33	4
4	31	27	4
5	35	29	6
6	33	27	6
7	39	34	5
8	30	25	5
9	38	32	6
10	32	27	5
11	34	28	6
12	29	24	5
Average	33	28	5

presents a comparative analysis of the number of active hosts per 24 h before and after the implementation of the deep-annealing algorithm over a twelve-week period. The results presented in Table 5 correspond to the input activity measured in terms of API requests and application load handled by the AIaaS platform. Specifically, these results reflect the distribution and handling of a standardized set of API calls generated by the applications hosted on VMs. Each VM instance processed a varying number of requests depending on its allocated resources and current workload, and the table captures the system’s performance in terms of resource utilization and API handling efficiency both before and after applying the RAP-Optimizer. The input activities were kept consistent across evaluations to ensure a fair comparison between the baseline and optimized states. Before the introduction of the algorithm, the average number of active hosts per day was recorded at 33. With the deployment of the deep-annealing algorithm, this average was reduced to 28 active hosts per day, signifying an average reduction of 5 hosts. This demonstrates the efficacy of the deep-annealing algorithm in optimizing resource utilization within the data center environment.

A closer examination, illustrated in Figure 10, reveals a fluctuating yet consistently positive impact of the deep-annealing algorithm across the weeks. The most notable improvement was observed in the second week, where the number of active hosts was reduced by 7, from 29 without the algorithm to 22 with it. The least improvement was seen in weeks 3 and 4, where a reduction of 4 hosts was achieved. Weeks 1, 5, 6, 9, and 11 saw a reduction of 6 hosts, while weeks 7, 8, 10, and 12 observed a decrease of 5 hosts. These results underscore the capacity of the deep-annealing algorithm to effectively manage and reduce the number of active hosts required to support the operational demands of a SaaS application data center.

5.5. Request Optimization

Table 6. API request handling and resource optimization before and after using the deep-annealing algorithm.

Host	Resource Capacity		API Requests Before RAP-Optimizer		API Requests After RAP-Optimizer
	CPU (Cores)	RAM (GB)	Processed	CPU Cores	Processed	CPU Cores
1	10	128	12	8	18	10
2	10	128	15	9	20	9
3	10	128	16	10	22	10
4	10	128	7	5	Handled by Host 1–3	Idle Mode
5	10	128	14	9	19	10
6	10	128	6	4	Handled by Host 1–3	Idle Mode
7	10	128	9	7	18	9
8	10	128	13	8	20	9
9	10	128	10	6	16	9
10	10	128	5	3	Handled by Host 5–9	Idle Mode
11	10	128	8	6	Handled by Host 5–9	Idle Mode
12	10	128	4	3	Handled by Host 5–9	Idle Mode

presents the resource utilization and API request handling before and after implementing the proposed RAP-Optimizer. Initially, all physical hosts were active, handling a random number of API requests, with some hosts underutilized in terms of CPU and RAM. The number of API requests generated follows a Poisson distribution, commonly used to model request rates in cloud environments, with a mean parameter $\lambda =15$, which represents the average number of API requests per host per time unit. This distribution was chosen to simulate typical variations in API traffic experienced in the experimenting cloud-based AIaaS environment [52]. After applying the RAP-Optimizer, the system efficiently allocated API requests to fewer hosts, maximizing resource utilization before activating additional hosts. As a result, five physical hosts were placed into idle mode, conserving resources and reducing energy consumption. The remaining hosts handled the same workload but at higher efficiency, utilizing their CPU and RAM to near full capacity. Before the method was implemented, many hosts processed fewer API requests, with CPU cores and RAM underutilized. For example, hosts 4, 6, and 10 handled only a fraction of their capacity, running only 3 to 7 API requests, leaving a significant portion of resources idle. After applying the deep-annealing method, these API requests were consolidated onto hosts with higher resource availability, allowing some physical hosts to transition into idle mode. This approach optimized resource utilization across the active hosts while reducing operational overhead. The results, as shown in Table 6, demonstrate that the proposed system can handle the same number of API requests using fewer physical hosts, which leads to significant resource savings and improved data center efficiency.

5.6. Resource Optimization

The RAP-Optimizer demonstrates significant resource optimization potential. Figure 11 shows the before and after effect comparison. Initially, before implementing the RAP-Optimizer, the server costs steadily increased from USD 200 to USD 2600 over the 12 months, as the system inefficiently activated additional hosts to handle the growing number of API requests. This led to underutilized resources and inflated operational costs. After applying the proposed RAP-Optimizer, the server cost was reduced each month, stabilizing at around USD 1250 by the 12th month. This reduction is attributed to the system’s ability to consolidate API requests to fully utilize existing active hosts before activating new ones. As a result, unnecessary activation of hosts was minimized, leading to significant cost savings.

Despite the optimization, the application’s return remained consistent, showing that user demand and subscription revenues were unaffected by the changes. The table highlights a clear increase in the revenue margin after optimization—from an initial margin of USD 300 in the first month, the margin grew to USD 1750 by the 12th month. This improvement demonstrates the effectiveness of the proposed system in reducing operational costs while maintaining consistent service delivery, thus ensuring the profitability and sustainability of the AI-driven image enhancement web application over time. By efficiently managing resources and reducing the number of active hosts, the system successfully increases profit margins, even as server usage grows.

5.7. Objective Achievement

The primary objective of this study is to increase the profit margin. After implementing the proposed RAP-Optimizer, server cost, return, and revenue margin were observed for 12 months. During this observation period, the existing approach and the system with RAP-Optimizer were active simultaneously. The number of users allowed to use the optimized system was kept similar to the existing system for fair comparison. The data observed over the 12-month period are listed in

Table 7. Numerical analysis of the objective achievement.

Months	Server Cost in USD		Return in USD		Revenue Margin in USD
	Before	After	Before	After	Before	After
1	200	150	500	500	300	350
2	500	400	1200	1200	700	800
3	800	650	1800	1900	1000	1250
4	1100	800	2200	2300	1100	1500
5	1500	900	2500	2600	1000	1700
6	1800	1000	2600	2700	800	1700
7	2000	1100	2700	2800	700	1700
8	2100	1150	2750	2800	650	1650
9	2200	1200	2800	2850	600	1650
10	2400	1200	2900	2900	500	1700
11	2500	1250	2900	2950	400	1700
12	2600	1250	3000	3000	400	1750

. After using the RAP-Optimizer, on average, the server cost was reduced by approximately 45%, dropping from an initial USD 2600 to a stable USD 1250 by the 12th month. This resulted in an average monthly cost reduction of USD 1150. In parallel, the profit margin increased from an average of USD 600 per month before optimization to USD 1675 after optimization, reflecting a 179% increase in profit over the 12-month period. Additionally, the reduction in the number of active hosts, as shown in Table 6, led to more efficient resource utilization, ensuring that the same number of API requests were handled with fewer servers, further driving operational cost savings and profit maximization.

5.8. Case Study Analysis

To highlight the RAP-Optimizer’s performance, we conducted a case study comparing its efficiency with traditional methods, such as Kubernetes’ Horizontal Pod Autoscaler (HPA) [53] and Amazon Web Services (AWS) Auto Scaling [54], within high-demand periods for a large-scale AI image processing application. During peak loads, RAP-Optimizer reduced the number of active physical hosts by 20% in comparison to Kubernetes HPA and AWS Auto Scaling, while ensuring sub-100 ms response times. Additionally, RAP-Optimizer achieved a 28% reduction in server costs over AWS Auto Scaling, attributed to its predictive configuration adjustment model, which proactively manages resources to match API request patterns. The RAP-Optimizer’s approach reduced latency by an average of 15%, leveraging real-time workload analysis and minimizing idle resource allocations, outperforming existing methods like the Google Kubernetes Engine’s (GKE) default resource scaling by dynamically consolidating workloads [55]. These results demonstrate the RAP-Optimizer’s unique capability to handle dynamic and unpredictable workloads typical of AIaaS environments, achieving operational savings, enhanced resource utilization, and improved performance beyond what is currently possible with industry-standard tools.

5.9. Comparative Performance Evaluation

The performance of the proposed RAP-Optimizer was compared with other CEDULE+, which is considered a state-of-the-art method [56]. This quantitative performance analysis establishes the benchmark to perceive the level of improvement the proposed RAP-Optimizer can introduce. The experimental data are presented in

Table 8. Comparative analysis of RAP-Optimizer and CEDULE+.

Metric	RAP-Optimizer	CEDULE+	Percentage Improvement
Cost Savings (%)	45%	32%	+13%
Active Host Reduction (%)	40%	30%	+10%
Prediction Accuracy (%)	96.1%	92.5%	+3.6%
Response Time (ms)	85 ms	120 ms	−29.2%

. This comparison summarizes the quantitative results. It compares RAP-Optimizer with CEDULE+ across multiple key performance metrics. These metrics are cost savings, reduction in active hosts, prediction accuracy, and response time. Both systems were deployed under similar conditions so that the performance data remained unbiased. The experiment was conducted in a dynamic workload environment representative of typical AIaaS scenarios.

The experimental data in Table 8 show that the proposed RAP-Optimizer saves 13% of costs compared to the CEDULE+. The main contributor behind this improvement is the effective consolidation of API requests onto fewer active hosts offered by the RAP-Optimizer. This method reduces the overall energy consumption, which, in other words, reduces the cost. Moreover, the experimental data show that the proposed RAP-Optimizer introduces the capability of reducing additional active hosts by 10%. From the response time perspective, the RAP-Optimizer is more responsive than the CEDULE+. Overall, the proposed RAP-Optimizer demonstrates better performance in the experimenting environment.

5.10. Mobility-Aware Performance Comparison

The mobility-aware routing enhancement method was integrated into the proposed RAP optimizer to ensure network resource optimization. In this approach, the distance between the host servers and the service requesters was considered. Reducing the routing cost is another way of optimizing AIaaS resources [57]. The performance of the mobility-aware approach is listed in

Table 9. Performance comparison of RAP-Optimizer with and without the mobility-aware component.

Metric	Standard RAP- Optimizer	With Mobility-Aware Component	Percentage Improvement
Cost Savings (%)	45%	50%	+5%
Active Host Reduction (%)	40%	42%	+2%
Prediction Accuracy (%)	96.1%	96.3%	+0.2%
Response Time (ms)	85 ms	70 ms	+18%
Routing Cost Reduction (%)	-	15%	-

, which provides a summary of the experimental results under similar conditions. The key metrics of this analysis are cost savings, reduction in active hosts, prediction accuracy, response time, and routing cost. The experimental data show that the mobility-aware RAP-Optimizer improves the performance. It reduces the response time and lowers the routing cost. To be precise, according to the experimental data, the distance-aware approach achieved a 15% reduction in routing costs. It is an 18% improvement in response time compared to the standard RAP-Optimizer.

The experimental results presented in Table 9 indicate that mobility-aware RAP-Optimizer dynamically hosts requests to the host server to minimize network overhead. That is why the network resources are optimized when it is incorporated with the proposed RAP-Optimizer. This enhanced capability helps maintain a high level of efficiency, particularly for AI-driven applications with unpredictable and geographically diverse workloads.

6. Limitations and Future Scope

While the proposed RAP-Optimizer has shown promising results in reducing operational costs and optimizing resource utilization, there are several areas where the approach can be further improved. This section outlines the key limitations of the current system and proposes future directions to enhance its functionality, scalability, and efficiency in handling cloud-based AI services.

6.1. Resource Utilization Focus

One limitation of the proposed RAP-Optimizer is that it primarily focuses on optimizing CPU and memory utilization, while other critical factors, such as network bandwidth, disk I/O, and latency, are not fully considered. These elements play some role in the overall system performance. When the number of traffic increases, the impact of these elements becomes more vital. One of the approaches to overcome the limitations is to expand the dataset features and incorporate these elements as well. However, the scope of this extension will be explored in the subsequent version of this study.

6.2. Uniform API Request Handling

The experimenting AIaaS application offers image processing services only. As a result, the cloud servers do not have any configuration variations. However, applications that offer multi-modal services, such as audio and video processing, will depend on multiple different hardware configurations at the back end. As a result, selecting the appropriate hardware to transfer the API call will require an additional logical layer to make appropriate decisions. The proposed RAP-Optimizer does not incorporate this complexity. This is another limitation of this approach. A potential solution to overcome this weakness is categorizing the API requests based on their nature, which will be explored in the future of this method.

The RAP-Optimizer considers that all API requests can be uniformly distributed across available hosts, without accounting for hardware differences or the geographical location of hosts, which may affect response times or performance. Addressing this limitation could involve enhancing the system to factor in host-specific attributes like hardware capabilities and geographic proximity, allowing for smarter resource allocation that reduces latency and improves service quality.

6.3. Predictive Optimization Approach

The current version of the proposed RAP-Optimizer is a predictive approach. The overall effectiveness of the process depends on the accuracy of the prediction. One of the major weaknesses of this approach is if the configurations are predicted incorrectly, the RAP-Optimizer fails to handle it. One of the solutions to overcome this limitation is to incorporate the false positive rate into the decision-making process. The potential of this solution will be explored in the future scope of this study.

6.4. Single-Cloud Focus

Multi-cloud or hybrid architectures offer more flexibility and cost-effective structure. The proposed AIaaS application runs on a single-cloud architecture, so the entire experiment is conducted on it. The findings are relevant, and the proposed approach is suitable for single-cloud architecture only. This is one of the weaknesses of the proposed system. However, hundreds of AIaaS run on single-cloud architecture, which makes the proposed approach feasible and effective. The subsequent version of this paper will focus on multi-cloud or hybrid-cloud architecture in the future.

7. Conclusions

The RAP-Optimizer presented in this paper demonstrates an effective way to overcome the challenge of resource utilization and cost optimization in AIaaS applications. Although it focuses on an image enhancement application only, this study plays an instrumental role in creating the blueprint for optimization techniques for similar applications. This study also demonstrated an innovative application of the combination of DNN and simulated annealing algorithm in cloud resource optimization. The experimental results presented in this paper show significant reductions in the number of active physical hosts and server costs without compromising service quality. Over a twelve-month observation period, the RAP-Optimizer achieved an average reduction of 45% in server costs. It further shows a 179% increase in profit margins, clearly highlighting the practical benefits of the system. The DNN was designed and trained in this study to predict the resource configuration and maintain high classification accuracy across all five service classes. The confusion matrix shows that the DNN achieved 97.48% validation accuracy. K-fold cross-validation was performed to validate the performance. In the cross-validation, the performance of the DNN prediction remained consistent for all folds. That means the DNN is both accurate and well-trained and has good generalization capability. Moreover, the introduction of the unique dynamic dropout control (DDC) algorithm contributed to mitigating the overfitting effects. Combining the simulated annealing algorithm with the DNN unblocked a new dimension of AIaaS cloud resource optimization, which dynamically manages the cloud resources. It effectively reduces the number of active hosts, which maximizes the existing resource utilization without activating new physical hosts, which saves a significant amount of resources and energy. This efficiency directly translates into improved sustainability and cost-effectiveness for AIaaS applications.

The innovative design, effective performance, and real-world positive impact on enlarging profit margin in AIaaS application business demonstrated the potential of the proposed RAP-Optimizer. Despite multiple advantages, the RAP-Optimizer suffers from certain limitations. Excluding other resources except for CPU and memory utilization, lack of heterogeneous API request management analysis, and experiment on the single-cloud environment are some of the limitations of the experiment presented in this paper. In conclusion, the RAP-Optimizer provides a scalable, efficient, and cost-effective solution for resource management in cloud-based AI services, offering substantial improvements in operational efficiency, energy savings, and profit margins. As AI-driven applications continue to grow in scale and complexity, solutions like the RAP-Optimizer will play a crucial role in ensuring that cloud resources are utilized to their fullest potential, paving the way for more sustainable and profitable cloud-based business models.