Il problema dell'infrastruttura AI da 2 trilioni di dollari di cui nessuno parla, e l'ingegnere che lo sta risolvendo

      Le chiamate sugli utili dell'infrastruttura AI degli ultimi otto trimestri hanno fornito al pubblico un vocabolario preciso per i costi di costruzione in capitale. Approvvigionamento di GPU hyperscaler. Contratti di acquisto di energia. Impronte immobiliari. Il vocabolario che non hanno fornito al pubblico è quello relativo ai costi per mantenere i cluster in salute su base ricorrente dopo che il capitale è stato speso. Questa voce, a un'attenta analisi, è diventata uno dei più grandi centri di costo nascosti nell'intera costruzione. Sta crescendo più velocemente della voce di capitale sopra di essa.

      I numeri visibili nella conversazione sull'infrastruttura AI descrivono la storia del capitale. L'approvvigionamento di GPU hyperscaler è sulla buona strada per superare la spesa cumulativa di diversi trilioni di dollari nel ciclo attuale. I contratti di acquisto di energia sono entrati nell'intervallo che storicamente descriveva l'industria pesante. Gli impegni immobiliari hanno seguito. La narrazione del capitale è stata raccontata in dettaglio attraverso due anni di aggiornamenti per gli investitori.

      La storia operativa è meno visibile. Descrive cosa costa mantenere i cluster in salute. Il lavoro è poco glamour e per lo più manuale. I guasti dei nodi GPU devono essere rilevati, triageati e rimediati. I pod devono essere riprogrammati attorno all'hardware degradato. L'utilizzo delle risorse in una flotta di acceleratori deve essere monitorato, bilanciato e riportato. Ognuno di questi compiti è, negli attuali ambienti di produzione, svolto da una classe di ingegneri la cui retribuzione è tra le più alte del settore.

      L'ammontare della fattura è enorme. Gli analisti del settore che monitorano l'utilizzo delle GPU nelle flotte hyperscaler hanno, per diversi anni, riportato tassi di inattività di routine superiori al trenta percento sugli acceleratori di produzione. Il numero di personale necessario per mantenere le operazioni del cluster è aumentato con la dimensione del cluster, in proporzione piuttosto che in sub-proporzione, in ambienti in cui l'obiettivo esplicito di ogni team di infrastruttura è rompere quella proporzionalità. Il livello operativo, in aggregato, è una delle voci che trasforma la tesi dell'infrastruttura AI da una forte storia di investimento a un problema di margine strutturale.

      Il 💜 della tecnologia UE Gli ultimi rumori dalla scena tecnologica dell'UE, una storia del nostro saggio fondatore Boris e alcune opere d'arte AI discutibili. È gratuito, ogni settimana, nella tua casella di posta. Iscriviti ora! Il lavoro per affrontarlo è, fino a poco tempo fa, rimasto all'interno degli strumenti di automazione su misura dei più grandi operatori, accessibile solo agli ingegneri che lo hanno costruito. Questo sta iniziando a cambiare. Shashidhar Bhat, un ingegnere del software nell'organizzazione dell'infrastruttura big-data di ByteDance, ha trascorso gli ultimi due anni producendo un corpo di lavoro che si mappa direttamente sul livello operativo che il resto dell'industria ha descritto come un problema.

      I pezzi, individualmente, sembrano componenti di infrastruttura ordinari. Plugin per dispositivi personalizzati per una programmazione più dettagliata degli acceleratori. Strumenti di osservabilità costruiti sopra il Data Center GPU Manager di NVIDIA. Logica di riprogrammazione autonoma dei pod che reagisce al degrado dell'hardware senza escalation umana. Ognuno è il tipo di cosa che viene spedita silenziosamente all'interno di un team di infrastruttura interno. Presi insieme, descrivono il livello operativo che l'industria ha esternalizzato agli ingegneri di affidabilità del sito, portato nel software e indurito contro il carico di produzione.

      La scala alla quale opera il lavoro di Bhat è parte di ciò che lo rende credibile come architettura di riferimento. ByteDance, madre di TikTok, gestisce uno dei più grandi deployment di Kubernetes al mondo. I suoi cluster funzionano su centinaia di nodi GPU che elaborano circa un petabyte di dati ogni mese. Il framework interno di Bhat, un sistema di automazione basato su agenti chiamato OpenSkill, ha ridotto il tempo di inattività delle GPU del trentacinque percento in quell'ambiente, rispetto a una linea di base che includeva i picchi di utilizzo caratteristici dell'addestramento di raccomandazioni su larga scala e distribuzione di contenuti.

      Una cifra del trentacinque percento è, secondo gli standard operativi del settore, elevata. Gli operatori di classe hyperscaler da anni stanno cercando miglioramenti a una cifra nei tassi di inattività, ragionando sul fatto che miglioramenti a una cifra a volumi hyperscaler ripagano in otto cifre. Una riduzione su scala come quella riportata da Bhat è il tipo di risultato che, quando appare in produzione in un'azienda concorrente, viene tenuto segreto. Il fatto che sia stato riportato è parte del motivo per cui la comunità degli operatori più ampia ha iniziato a prestare attenzione.

      L'altra metà del lavoro recente di Bhat è apparsa sul lato open-source. È stato un collaboratore di Kubewharf Katalyst, il framework di gestione delle risorse mantenuto congiuntamente da ByteDance e dalla più ampia comunità Kubernetes. Il progetto Katalyst è uno dei pochi nell'ecosistema cloud-native a trattare la programmazione congiunta delle risorse CPU e GPU sotto carico. Le proposte di design che Bhat ha presentato contro il progetto hanno spostato la discussione in direzioni che parallele al suo lavoro interno. La convergenza tra il lavoro di produzione interno di un ingegnere e i contributi open-source esterni è il raro tipo di modello che la comunità dei manutentori riconosce come sostanziale piuttosto che promozionale.

      Il terzo pilastro del corpo di lavoro è Carbon-Kube, il pianificatore Kubernetes open-source che Bhat ha rilasciato lo scorso dicembre insieme a un articolo IEEE co-autore con Sathwik Rao Sirikonda, anche lui di ByteDance. Il pianificatore è un progetto distinto dal suo lavoro interno di ByteDance e affronta la dimensione delle emissioni di carbonio delle operazioni del cluster piuttosto che la dimensione del personale. Il progetto viene fornito con un file di citazione, una metodologia di benchmark pubblicata e script riproducibili. Il contributo è metodologicamente rigoroso in un modo che la maggior parte degli strumenti di infrastruttura interni non si preoccupa mai di essere.

      Il quadro complessivo è ciò che rende il caso degno di essere presentato a livello industriale. Il livello operativo dell'infrastruttura AI è un centro di costo delle dimensioni di un'economia media. Il lavoro per affrontarlo è stato svolto silenziosamente all'interno delle più grandi aziende, accessibile solo ai loro team interni. Questo sta cambiando, in parte grazie al lavoro di operatori come Bhat, i cui contributi spaziano dalle implementazioni di produzione interne, alla manutenzione open-source esterna, e pubblicazioni di ricerca a nome proprio.

      L'argomento che il livello operativo è il prossimo grande confine di margine nell'infrastruttura AI è, sulla base del lavoro che è stato realizzato nell'ultimo anno, difficile da ignorare. Gli operatori di cluster nei prossimi due o tre anni dovranno decidere se costruire la propria risposta o adottare una delle soluzioni open-source che stanno diventando disponibili. La composizione di quella risposta rimodellerà il margine operativo di ogni team che gestisce carichi di lavoro AI in produzione.