Pobierz PDF

Green or Fast? Learning to Balance Cold Starts and Idle Carbon in Serverless Computing

Metadane

• Autorzy: Bowen Sun, Christos D. Antonopoulos, Evgenia Smirni, Bin Ren, Nikolaos Bellas, Spyros Lalis
• Afiliacje: William & Mary (USA), University of Thessaly (Greece)
• Rok: 2026
• Źródło: CCGrid 2026 (26th IEEE International Symposium on Cluster, Cloud, and Internet Computing), Sydney, Australia
• arXiv: 2602.23935
• Status: read
• Kategoria: Systems
• Tagi: #carbon-awareness #serverless #faas #reinforcement-learning #cold-start #keep-alive #dqn #energy-measurement #project/js-runtime-energy

Streszczenie

LACE-RL (Latency-Aware and Carbon-Efficient serverless management via Reinforcement Learning) to framework optymalizujący czas keep-alive kontenerów FaaS metodą DQN, jednocześnie minimalizując cold-start latency i emisje CO₂ z utrzymywania ciepłych podów. Kluczowa obserwacja: te dwa cele są antagonistyczne — dłuższy keep-alive redukuje cold starts, ale zwiększa idle carbon emissions; przy czym idle carbon może przekraczać carbon z samego wykonania funkcji (Fig. 2 prawa strona).

LACE-RL formalizuje zarządzanie podami jako MDP: agent DQN wybiera czas keep-alive z dyskretnego zbioru {1, 5, 10, 30, 60} sekund na podstawie wektora stanu zawierającego: prawdopodobieństwa reuse dla różnych czasów keep-alive, zasoby (mem, CPU), cold-start latency, bieżącą intensywność węgla CI(t) i tunowalną wagę λ_carbon ∈ [0,1]. Nagroda R = −[(1−λ_carbon)·C_cold(k) + λ_carbon·C_carbon(k)] interpoluje między minimalizacją latencji a minimalizacją emisji.

Ewaluacja na Huawei Public Cloud Trace (31 dni, 300M+ requestów) z kalibracją na FunctionBench zmierzonym przez Kepler na HPE ProLiant DL385: LACE-RL redukuje cold starts o 51.69% i idle keep-alive carbon o 77.08% vs statyczna polityka Huawei (60s), przy latencji 1.05s vs 1.43s. Zbliża się do Oracle (degradacja tylko 6.18% carbon, 7.20% cold starts) przy koszcie inferencji ~15 µs/wywołanie, co jest 4600× szybsze niż heurystyczny DPSO (EcoLife).

Kluczowe Wnioski

• Idle carbon > execution carbon: dla niektórych funkcji utrzymywanie ciepłego poda generuje więcej CO₂ niż samo wykonanie — fundamentalny argument za adaptacyjnym keep-alive
• λ_idle = 0.21–0.83: zmierzony zakres stosunku idle/active power w FunctionBench — duże zróżnicowanie między typami workloadów; w modelu przyjęto konserwatywne 0.2
• Runtime metadata w Huawei Trace: dataset zawiera typ runtime (Python, Custom, etc.) per funkcja — potencjał dla analiz specyficznych dla runtimes
• Long-tailed cold start latency: 0.1s–10s+ w zależności od runtimes i kontekstu; RL poradzi sobie z tym heterogenizmem, statyczne polityki nie
• DQN adaptuje się do carbon intensity: podczas niskich godzin CI agent wybiera 60s keep-alive; podczas wysokich — 1s; interpretowalna strategia
• FunctionBench cold-start outliers: Image Processing (2441ms/11.13J cold), Video Processing (12415ms/19.05J cold), Classification (8643ms/21.39J cold) — zdominowane przez inicjalizację bibliotek i ładowanie modeli; analogia do JS runtime warm-up JIT
• Fundamentalna luka dla JE: model energetyczny zakłada jednorodne runtimes — nie różnicuje energii cold-start per typ runtime (Python vs Custom vs Node.js/Deno/Bun); Huawei Trace ma metadata runtimeów, ale nie analizuje ich energetycznych różnic

Metodologia

Hardware: HPE ProLiant DL385 Gen10 Plus v2 (dual AMD EPYC 7513, 32 cores/socket = 64 cores total, 256GB RAM). Deployment: Knative na Kubernetes. Pomiar energii: Kepler (Kubernetes-based Efficient Power Level Exporter) — raportuje node-level active i idle energy na poziomie CPU package.

Model energetyczny — trzy fazy:

• Wykonanie: E_exec(f) = (J^MB_DRAM·mem_f + J^core_CPU·cpu_f)·T_exec(f)
• Keep-alive: E_idle_scaled(f) = λ_idle·(J^MB_DRAM·mem_f + J^core_CPU·cpu_f)·T_idle(f); λ_idle = 0.2
• Cold start: E_cold(f) = P_cold(f)·T_cold(f)
• Carbon: C_x(f,t) = E_x(f)·CI(t); dane CI z Electricity Maps (gCO₂eq/kWh, hourly)

Dataset: Huawei Public Cloud Trace — dzień 30 (300M+ requestów, 1500+ unikalnych funkcji). Podział: 80% train, 10% validation, 10% test (po podID). Cold start lookup table z runtime i trigger type.

Baseline’y: Latency-Min (statyczna minimalizacja cold starts), Carbon-Min (minimalizacja idle carbon), Huawei static 60s, DPSO/EcoLife (PSO-based carbon-aware, stan-of-the-art).

Metryki kompozytowe: LCP = latency × total_carbon; IRI = cold_starts × keep-alive_carbon (analogia do Energy-Delay Product z HPC).

Główne Koncepcje

• LACE-RL: DQN agent zarządzający keep-alive per pod; offline training (~5 min/epizod), microsecond-level online inference
• Reward function: R = −[(1−λ_carbon)·(1−p_k)·L^cold_i + λ_carbon·E^idle_i·CI_t]; interpolacja latencja ↔ carbon
• State vector: S_t = [p_k1,…,p_kn, r^mem_i, r^cpu_i, L^cold_i, CI_t, λ_carbon] — kompaktowa reprezentacja workload + carbon context
• λ_carbon: tunowalny parametr wbudowany w stan; Q-network uczy się strategii warunkowej bez retreningu przy zmianie preferencji
• LCP (Latency-Carbon Product): 178.84 (LACE-RL) vs 478.64 (Huawei) vs 217.96 (DPSO)
• IRI (Idle Reuse Inefficiency): 683k (LACE-RL) vs 6169k (Huawei)
• Oracle gap: tylko 6.18% (carbon) i 7.20% (cold starts) poniżej Oracle z doskonałą wiedzą przyszłości
• EcoLife/DPSO: najlepszy baseline; PSO-based, ale 4600× wolniejszy przy inferencji niż LACE-RL

Wyniki FunctionBench (profiling energetyczny)

Outliers cold start: Image Processing, Video, Classification — zdominowane przez inicjalizację bibliotek (~2s–12s cold vs ~0.1s dla Float Ops).

Wyniki porównawcze (General Workload: 99,140 wywołań)

Przydatne Cytaty

“Both our empirical characterization and recent studies show that aggressive keep-alive strategies can incur a substantial ‘hidden’ carbon cost, in some cases exceeding the emissions associated with function execution itself.” (str. 1)

“No existing system optimizes keep-alive decisions at function-instance granularity under time-varying carbon intensity.” (str. 2)

“The keep-alive-to-compute power ratio (λ_idle) spans 0.21–0.83, indicating that warm retention consumes a significant fraction of active power.” (str. 6)

“LACE-RL models runtime-dependent cold-start latency rather than assuming a fixed cost.” (str. 10 — Related Work)

Datasety

• Huawei Public Cloud Trace — 31-day trace, 300M+ requests, 1500+ functions z runtime metadata; używany jako główny evaluation dataset; dzień 30 jako primary; cold start logs + request-level logs + runtime/trigger metadata
• FunctionBench — 10 funkcji benchmark do kalibracji modelu energetycznego (cold start, compute, keep-alive phases); Kepler na HPE ProLiant DL385

Powiązane Tematy

• Fundamentalna luka dla JE-6: LACE-RL modeluje cold-start latency per runtime (lookup table z Huawei Trace), ale nie cold-start ENERGY per runtime — krok do rozszerzenia: JS-specific cold-start energy profiling (Bun vs Node.js vs Deno init overhead)
• Huawei Trace Runtime Metadata: dataset ma typ runtime per funkcja (Python/Custom/etc.) — naturalny punkt wejścia do analizy energetycznej per runtime
• λ_idle variance (0.21–0.83) w FunctionBench jest bezpośrednio relevantna dla pomiaru idle energy JS runtimeów — analogia do JE-1 (idle energy po warm JIT cache)
• EcoLife [22] = baseline dla LACE-RL; [#JE-7] runtime-aware carbon scheduling rozszerzyłby EcoLife/LACE-RL o wymiar efektywności runtimes
• Kepler jako narzędzie pomiarowe (Kubernetes-based) — alternatywa dla PowerJoular w środowiskach cloudowych; zbieżne z JE-1 metodologią

Notatki