## 3 Related Work  
To reduce function cold starts, some research [3; 6; 14] focuses on addressing the underlying factors contributing to cold start latency, such as CPU, memory, and network. These studies identify these elements and propose solutions aimed at optimizing their performance. In a related study [15], the researchers argue that the network component is the dominant factor in cold start latency. They claim that the creation and initialization of network connections is a shared stage among most serverless functions and significantly contributes to cold start delays. Their proposed solution involves creating a pool of empty network containers (paused containers) that remain connected to the currently active containers and share the same network configuration, making them ready for immediate use when needed. Some other works have focused on warming or prewarming the runtime in cache, based on the principle that caching containers can reduce initialization time. [16] Present Faa$T, a transparent auto-scaling distributed cache for serverless applications. Faa$T maintains an in-memory cache for each active function, reducing initialization time by pre-warming the cache with objects likely to be accessed. [PERSON] et al. [17] proposed HotC, which aims to reduce cold start latency and optimize network performance by integrating an exponential smoothing model with a Markov chain approach to predict future demand and dynamically create a pool of active containers at runtime. While these scheduling strategies effectively reduce cold start rates, they do not consider the resource state, either within a single invoker or across multiple invokers, in their scheduling decisions. As a result, pre-warmed containers naturally compete with busy (active) containers for CPU and memory resources, which can overload certain invokers and increase load imbalance across the system. Although reducing cold starts is a primary goal of our research, the two-tier scheduling approach we propose aims to reduce resource contention by prioritizing invokers with the most balanced resource usage, thereby avoiding overloading invokers that could delay container initialization. Several recent studies have applied load forecasting to proactively pre-warm a certain number of containers, thereby minimizing the occurrence of cold starts. For example, [18; 19] implemented approaches using ARIMA as the prediction algorithm to forecast upcom  
Figure 2: Utilizations and latency relationship of different scheduling strategies. ing invocations and initialize containers in advance to handle the anticipated workload. They demonstrated that this approach can reduce latency; however, these studies used limited datasets that do not reflect real-world workloads, and they lacked experimental comparisons with other prediction models against ARIMA. While ARIMA is a powerful, lightweight time-series forecasting tool, it relies on a linear assumption, capturing only linear relationships in the data. In contrast, serverless workloads frequently exhibit non-linear patterns, such as sudden spikes during specific events or significant decay following bursts. These irregularities are often misforecasted by ARIMA and treated as random noise. Furthermore, ARIMA cannot explicitly incorporate contextual feature variables into the prediction model. These limitations motivated us to combine ARIMA with Random Forest (RF) to leverage ARIMA's lightweight nature and ability to model temporal causality, while using RF to correct ARIMA's linear bias by incorporating time-based features and lagged residuals. Another prediction approach was introduced by [20], which uses a lightweight regression-based incremental learning mechanism to anticipate workload fluctuations online. This method eliminates the need for individual profiling of each serverless function. Long Short-Term Memory (LSTM) is another well-documented forecasting method widely used in traditional cloud platforms [4; 21]. In [5], LSTM is employed as a time series prediction model to forecast function invocation times.