Google firma accordi di demand-response con I&M e TVA per rendere flessibili i carichi di lavoro ML sulla rete

Dal rimandare una transcodifica YouTube al rimandare task ML

Google racconta che le sue prime funzionalità di demand-response nei data center consistevano nello spostare task di calcolo non urgenti, come l'elaborazione di un video YouTube, citata come esempio, nelle ore in cui la rete non è sotto pressione. Queste funzionalità sono state messe in campo attraverso partnership con Centrica Energy e con l'operatore di trasmissione Elia in Belgio, e con Taiwan Power Company a Taiwan.

I due nuovi accordi, con Indiana Michigan Power (I&M) e Tennessee Valley Authority (TVA), estendono la stessa idea a una categoria di lavoro più complessa. Google dichiara senza mezzi termini che questi accordi 'rappresentano la prima volta in cui offriamo demand response nei data center puntando sui carichi di lavoro di machine learning (ML)'. Il precedente è una dimostrazione con Omaha Public Power District, dove Google ha ridotto la domanda di energia legata al ML durante tre eventi di rete l'anno scorso.

Questa evoluzione conta perché il training ML e l'inferenza batch sono tra i carichi più grandi e in più rapida crescita in un data center moderno. Rendere questi task pianificabili in base alle condizioni della rete è un problema diverso dal rimandare una codifica video, ed è esattamente la capacità che Google ora si impegna a garantire per contratto.

Il prodotto è una classificazione di quali task possono aspettare

Dietro al linguaggio da utility, la vera sfida tecnica è di scheduling. Il demand response funziona solo se un sistema riesce a distinguere in modo affidabile tra ciò che deve girare subito e ciò che può essere spostato o ridotto 'durante certe ore o periodi dell'anno', come si legge nel post.

Google descrive la domanda flessibile come qualcosa che 'può essere implementato rapidamente, contribuendo a colmare il divario tra la crescita di breve periodo della domanda e le soluzioni di energia pulita di lungo periodo'. In pratica, questa velocità arriva dal software: la capacità di sospendere, limitare o spostare task ML in risposta a un segnale dell'operatore di rete. L'accordo con l'utility è il contratto; il classificatore che decide cosa è rinviabile è il meccanismo.

Un confine di affidabilità netto attorno ai servizi rivolti agli utenti

Google è esplicita sul fatto che questa flessibilità ha dei limiti. Scrive che 'ci sono limiti a quanto un dato data center possa essere flessibile, perché livelli elevati di affidabilità sono fondamentali per servizi come Search e Maps, così come per i clienti Cloud in settori essenziali come la sanità'.

Integrare i carichi di lavoro ML è un passo importante per abilitare una flessibilità della domanda su scala più ampia, offrendo benefici in termini di affidabilità della rete e risparmio sui costi nei luoghi in cui queste capacità vengono implementate.Montana Labs

Questa frase traccia con chiarezza il confine operativo. Il traffico sensibile alla latenza e rivolto agli utenti, il frontend con cui le persone interagiscono direttamente, resta fisso. La capacità rinviabile arriva dal lavoro ML in background. Il demand response scala proprio perché i task ML si trovano sul lato tollerante di quel confine, non perché Google sia disposta a rallentare Search.

Cosa segnala per lo scheduling grid-aware il fatto di contrattualizzare carichi ML flessibili

L'implicazione concreta di questi accordi con I&M e TVA è che Google tratta il calcolo ML rinviabile come una risorsa negoziabile per la rete, non solo come una leva di efficienza interna. Steve Baker di I&M descrive la flessibilità del carico come 'uno strumento estremamente prezioso' per servire il nuovo data center di Google a Fort Wayne, collegando un'interconnessione più rapida per i grandi carichi alla disponibilità di Google a ridurre la domanda su richiesta.

Google è schietta sul fatto che si tratti di una fase iniziale e legata a specifiche località: la flessibilità 'sarà disponibile solo in alcune sedi', e indica nuovi investimenti in generazione e trasmissione come parte dello stesso portafoglio. Ma il punto strutturale è che la separazione tra servizi urgenti rivolti agli utenti e lavoro ML spostabile è ora scritta nei contratti con le utility. Per i team che gestiscono grandi flotte ML, questo ridefinisce lo scheduling dei task come qualcosa che ha un valore non solo in termini di costi e throughput, ma anche di impegni verso la rete, e rende fondamentale sapere esattamente quali carichi di lavoro possono essere messi in attesa senza rischi.