Measure Once, Model Everywhere: Model-Based Per-Request Resource Consumption for HTTP

Sintesi Tecnica: Misurare una volta, Modellare ovunque

Definizione del Problema
Le attuali proposte per la divulgazione della sostenibilità basata su HTTP si concentrano principalmente su cosa le informazioni ambientali debbano trasmettere (ad esempio, tramite gli header di risposta), ma lasciano aperta la questione pratica di come generare valori per singolo request credibili in scenari di deployment realistici. Nei contesti cloud-native, le risorse sono astratte come elastiche e on-demand, occultando i costi fisici ed ecologici dell'infrastruttura sottostante. Sebbene i provider possano desiderare la divulgazione, l'esecuzione di una richiesta spesso si estende su più sistemi e la telemetria energetica granulare è tipicamente non disponibile al confine del protocollo. Di conseguenza, client e operatori non possono distinguere tra interazioni ad alto costo e a basso costo, impedendo che i costi ecologici siano fattorizzati nelle decisioni di progettazione, come il comportamento di retry, il batching o il design dei prompt.

Metodologia
Il documento propone un approccio basato su modelli per stimare il consumo di risorse e la $CO_2e$ per singola richiesta HTTP senza richiedere una telemetria energetica di produzione granulare. Il metodo separa la misurazione offline dalla stima online:

1. Benchmarking Offline: Gli endpoint vengono caratterizzati in condizioni controllate utilizzando il Green Metrics Tool (GMT) su una macchina dedicata. I parametri del carico di lavoro (ad esempio, dimensione del payload, conteggio dei token) vengono variati sistematicamente per isolare i segnali energetici dal rumore.
2. Derivazione del Modello: Da queste misurazioni, vengono derivati modelli energetici compatti e specifici per ogni endpoint. L'approccio utilizza tre famiglie di modelli per bilanciare espressività e interpretabilità:
   • Modelli Costanti: Per endpoint in cui l'energia non varia apprezzabilmente con l'input (ad esempio, l'autenticazione).
   • Modelli Lineari: Per endpoint in cui l'energia scala proporzionalmente a una caratteristica osservabile (ad esempio, il conteggio dei token nell'inferenza AI).
   • Modelli a Curva (Piecewise): Per endpoint che esibiscono regimi di scaling distinti (ad esempio, il caricamento di file), rappresentati da punti di supporto misurati con interpolazione lineare.
3. Selezione delle Caratteristiche: I modelli si basano su caratteristiche osservabili al confine del server HTTP (ad esempio, durata della richiesta, byte trasferiti, metodo HTTP, stato della risposta) o metadati forniti dall'applicazione tramite header interni (ad esempio, il conteggio dei token per l'inferenza).
4. Calcolo delle Emissioni: L'energia prevista viene convertita in emissioni distinguendo tra:
   • Emissioni Operative: Calcolate moltiplicando l'energia prevista per l'intensità di carbonio della rete ($I$), che può essere statica o dinamica.
   • Emissioni Incorporate: Calcolate ammortizzando l'impatto della produzione dell'hardware sulla sua vita operativa e allocando una quota basata sul tempo di elaborazione della richiesta.
5. Implementazione Runtime: Il meccanismo è implementato come un'estensione nginx (utilizzando ngx_http_js_module). A runtime, il server carica un registro JSON contenente i modelli e i parametri. Per ogni richiesta, l'estensione estrae le caratteristiche rilevanti, valuta il modello appropriato ed emette metadati per singola richiesta tramite header di risposta.

Contributi Chiave

1. Identificazione del Gap: Il documento separa la questione a livello di protocollo del cosa divulgare dalla questione di sistema del come generare valori per singola richiesta, identificando quest'ultima come un gap critico nelle attuali discussioni sulla sostenibilità.
2. Pipeline dalla Misurazione al Modello: Propone una pipeline che deriva modelli energetici compatti, interpretabili ed eseguibili da benchmark offline controllati, adatti a endpoint eterogenei inclusi quelli che richiedono feature dello strato applicativo.
3. Valutazione Lato Server: Dimostra come questi modelli possano essere valutati al confine del server HTTP ed esposti come metadati di sostenibilità mantenendo espliciti le assunzioni sottostanti (ad esempio, intensità della rete, metodi di allocazione).
4. Valutazione della Fattibilità: L'approccio è valutato attraverso servizi web convenzionali e un endpoint di inferenza AI, mostrando fattibilità operativa e un basso overhead di runtime.

Risultati

• Accuratezza del Modello: I modelli adattati catturano con successo il comportamento dipendente dal carico di lavoro. Per gli endpoint CRUD, i modelli costanti sono stati sufficienti per l'autenticazione, mentre i modelli a curva hanno catturato lo scaling dipendente dal payload per il caricamento di file e il recupero dati. Per l'endpoint AI, un modello lineare utilizzando il conteggio dei token del prompt e dei token generati ha spiegato quasi tutta la variazione osservata, correggendo il comportamento non monotono visto utilizzando solo etichette di prompt grossolane.
• Validazione: Una sessione di validazione di tipo "click-path" (che simula un percorso utente realistico) ha mostrato che la stima basata sul modello (611.1 mWh) deviava solo del 2,33% dalla misurazione dell'energia a livello di macchina (597.2 mWh), preservando l'ordine di grandezza corretto.
• Overhead: L'attivazione del modulo nginx ha introdotto un overhead di runtime di circa lo 0,46% dell'energia totale della macchina, con variazioni per percorso dominate dal rumore tra una corsa e l'altra piuttosto che dal plugin stesso.
• Divulgazione: Il prototipo emette con successo header distinti per Request-Energy, Grid-Intensity, Request-Embodied-CO2e e Request-SCI, consentendo ai consumatori a valle di ricostruire il calcolo.

Significatività e Rivendicazioni
Il documento posiziona questo lavoro non come una soluzione che mira intrinsecamente a ridurre la domanda, ma come un substrato necessario per le tradizioni di design guidate dai vincoli (sufficienza, sobrietà, decrescita e design server a basso impatto). Gli autori sostengono che affinché queste strategie funzionino, il costo ambientale marginale di un'interazione debba essere leggibile all'interfaccia dove la richiesta viene emessa.

La significatività risiede nel fornire un metodo riproducibile e ispezionabile per rendere visibili le implicazioni ambientali dove vengono prese le decisioni, affrontando l'esclusione strutturale dei costi ecologici dalle attuali pratiche di progettazione del software. Gli autori mettono esplicitamente in guardia contro l'eccessiva pretesa di capacità:

• I valori sono astrazioni a livello di interfaccia, non attribuzioni fisiche di verità assoluta.
• Il metodo non risolve il greenwashing né sposta la responsabilità in modo asimmetrico; piuttosto, fornisce lo strato di visibilità necessario affinché tali critiche siano efficaci.
• L'approccio è limitato dalla sua dipendenza dall'ambiente di calibrazione (hardware, rete, co-tenancy) e richiede una ricalibrazione periodica.

In sintesi, il documento offre un percorso di implementazione pratico per la divulgazione della sostenibilità per singola richiesta, trasformando l'obiettivo astratto di "misurare una volta" in un sistema deployable che "modella ovunque".