Nadie habla del problema de la infraestructura de IA de 2 billones de dólares, y los ingenieros lo están resolviendo
Los últimos ocho trimestres de convocatorias de resultados de infraestructura de IA le han dado al público un vocabulario concreto para los costos de acumulación de capital. Colección de GPU hiperescalar. Acuerdo de compra de energía. Huella inmobiliaria. No le dieron al público el vocabulario de lo que cuesta mantener los grupos sanos de forma recurrente después de gastar el capital. Esa partida, tras una inspección más cercana, resulta ser uno de los mayores centros de costos ocultos en toda la construcción. Está creciendo más rápido que la línea de capital anterior.
Los números visibles en la conversación sobre infraestructura de IA cuentan la historia del capital. La adquisición de GPU Hyperscaler está en camino de superar los costos incrementales multimillonarios en el ciclo actual. Los acuerdos de compra de energía han entrado en el rango que históricamente caracteriza a la industria pesada. Le siguieron compromisos inmobiliarios. Los detalles de capital se detallan a lo largo de la actualización de dos años para inversionistas.
Las historias operativas son menos comunes. Describe lo que cuesta mantener los grupos sanos. El trabajo es servil y en gran medida manual. Las fallas del nodo GPU deben detectarse, clasificarse y remediarse. Es necesario redefinir los pods en torno al hardware degradado. La utilización de recursos en una flota de aceleradores debe monitorearse, equilibrarse e informarse. Cada una de estas tareas, en el entorno de fabricación actual, es realizada por una clase de ingenieros cuya remuneración es la más alta de la industria.
La magnitud del proyecto de ley es enorme. Los analistas de la industria que rastrean el uso de GPU en flotas hiperescalares han informado, durante varios años, tasas de inactividad rutinarias superiores al treinta por ciento en los aceleradores de producción. La plantilla necesaria para mantener las operaciones del clúster en funcionamiento se escala con el tamaño del clúster, de forma proporcional y no subproporcional, en un entorno donde el objetivo claro de cada equipo de infraestructura es romper esa proporcionalidad. La capa operativa, en su conjunto, es una de las partidas que convierte la tesis de la infraestructura de IA de una fuerte historia de inversión a un problema de margen estructural.
💜 de tecnología de la UE
Los últimos rumores de la escena tecnológica de la UE, una historia de nuestro sabio fundador Boris y algo de arte de inteligencia artificial dudoso. Es gratis, todas las semanas, en tu bandeja de entrada. ¡Regístrate ahora!
La tarea de abordar esto, hasta hace poco, estaba dentro de las herramientas de automatización personalizadas de los operadores más grandes, accesibles solo para los ingenieros que las construyeron. Eso está empezando a cambiar. Shasidhar Bhatt, ingeniero de software de la firma de infraestructura de big data ByteDance, ha pasado los últimos dos años desarrollando trabajos que asignan directamente a la capa operativa lo que el resto de la industria describe como un problema.
Las piezas, individualmente, parecen elementos de infraestructura comunes. Complemento de dispositivo personalizado para una programación detallada del acelerador. Herramientas de monitoreo construidas sobre el Administrador de GPU del centro de datos de NVIDIA. Lógica de reconfiguración de pod autónoma que responde a la degradación del hardware sin intervención humana. Cada uno es el tipo de cosas que se envían silenciosamente dentro de un equipo de infraestructura interna. En conjunto, describen el nivel operativo que la industria está subcontratando a ingenieros de confiabilidad del sitio, adaptado a software y reforzado contra cargas de producción.
La escala a la que opera el trabajo de Bhatt lo hace creíble como arquitectura de referencia. ByteDance, la matriz de TikTok, opera una de las implementaciones de Kubernetes más grandes del mundo. Sus clústeres se ejecutan en cientos de nodos GPU que procesan alrededor de un petabyte de datos por mes. El marco interno de Bhatt, un sistema de automatización basado en agentes llamado OpenSkill, redujo el tiempo de inactividad de la GPU en un treinta y cinco por ciento en ese entorno, frente a una línea de base que incluía picos de uso caracterizados por la capacitación de recomendadores y la entrega de contenido a gran escala.
Una cifra del treinta y cinco por ciento, según los estándares operativos sobre el terreno, es elevada. Los operadores de clase hiperescalar han estado persiguiendo mejoras porcentuales de un solo dígito en las tasas de inactividad durante años, argumentando que las mejoras de un solo dígito en el volumen hiperescalar arrojan ocho cifras. Una reducción de escala, según Bhatt, es el tipo de resultado que, cuando aparece en la producción de una empresa similar, se mantiene de cerca. El hecho de que se esté informando del incidente es parte del motivo por el que la comunidad de operadores en general está empezando a prestar atención.
La otra mitad del trabajo reciente de Bhatt apareció en el lado del código abierto. Es colaborador de Kubernetes Catalyst, un marco de gestión de recursos mantenido conjuntamente por ByteDance y la comunidad de Kubernetes en general. El proyecto Catalyst es uno de los pocos en el ecosistema nativo de la nube que aborda la programación conjunta de recursos de CPU y GPU bajo carga. La propuesta de diseño que Bhatt presentó contra el proyecto llevó la discusión en una dirección muy paralela a su trabajo interno. La combinación del trabajo de producción interno de un ingeniero y las contribuciones externas de código abierto es un patrón poco común que la comunidad de mantenimiento reconoce como sustantivo más que promocional.
La tercera parte del trabajo es Carbon-Cube, el programador de Kubernetes de código abierto que Bhatt lanzó en diciembre pasado en ByteDance con un artículo de IEEE en coautoría con Sathvik Rao Sirikonda. El programador es un proyecto separado de su función interna ByteDance y aborda la dimensión de emisiones de carbono de las operaciones del clúster en lugar de la dimensión de personal. El proyecto se envía con un archivo de extracto, un método de referencia publicado y scripts reproducibles. Las contribuciones son metodológicamente rigurosas de tal manera que la mayoría de las herramientas de infraestructura interna no molestan.
La imagen combinada es lo que justifica el caso a nivel artístico. La capa operativa de la infraestructura de IA es un centro de costos del tamaño de una economía mediana. El trabajo para abordar esto se está llevando a cabo silenciosamente dentro de las empresas más grandes, accesible solo para sus equipos internos. Eso está cambiando, gracias al trabajo de operadores como Bhatt, cuyas contribuciones abarcan implementaciones de producción interna, mantenimiento externo de código abierto y publicaciones de investigación bajo su propio nombre.
El argumento de que la capa operativa es la próxima gran frontera de margen en la infraestructura de IA, basándose en la fuerza laboral enviada durante el año pasado, es difícil de descartar. En los próximos dos o tres años, los operadores de clústeres tendrán que desarrollar sus propias soluciones o adoptar una de las fuentes abiertas disponibles actualmente. La combinación de esas respuestas remodelará los márgenes operativos de cada equipo que ejecute cargas de trabajo de IA de producción.
