El problema de infraestructura de IA de $2 billones del que nadie está hablando, y el ingeniero que lo está resolviendo.

      Las llamadas de ganancias de infraestructura de IA de los últimos ocho trimestres han dado al público un vocabulario preciso sobre lo que cuestan los gastos de construcción en capital. Adquisición de GPU de hiperescaladores. Acuerdos de compra de energía. Huellas inmobiliarias. El vocabulario que no han dado al público es sobre lo que cuesta mantener los clústeres saludables de manera recurrente después de que se gasta el capital. Ese concepto, al ser examinado de cerca, se ha convertido en uno de los centros de costo ocultos más grandes en toda la construcción. Está creciendo más rápido que la línea de capital que está por encima de él.

      Los números visibles en la conversación sobre infraestructura de IA describen la historia del capital. La adquisición de GPU de hiperescaladores está en camino de superar el gasto acumulado de varios billones de dólares durante el ciclo actual. Los acuerdos de compra de energía se han movido al rango que históricamente describía la industria pesada. Los compromisos inmobiliarios han seguido. La narrativa de capital se ha contado en detalle a lo largo de dos años de actualizaciones para inversores.

      La historia operativa es menos visible. Describe lo que cuesta mantener los clústeres saludables. El trabajo es poco glamuroso y en gran medida manual. Las fallas de nodos de GPU deben ser detectadas, clasificadas y remediadas. Los pods deben ser reprogramados alrededor del hardware degradado. La utilización de recursos en una flota de aceleradores debe ser monitoreada, equilibrada e informada. Cada una de estas tareas es, en los entornos de producción actuales, realizada por una clase de ingeniero cuya compensación está entre las más altas de la industria.

      La magnitud de la factura es enorme. Los analistas de la industria que rastrean la utilización de GPU en flotas de hiperescaladores han informado, durante varios años, tasas de inactividad rutinarias superiores al treinta por ciento en aceleradores de producción. El número de empleados requerido para mantener las operaciones de clúster ha aumentado con el tamaño del clúster, en proporción y no en subproporción, en entornos donde el objetivo explícito de cada equipo de infraestructura es romper esa proporcionalidad. La capa operativa, en conjunto, es uno de los conceptos que convierte la tesis de infraestructura de IA de una sólida historia de inversión en un problema estructural de margen.

      El 💜 de la tecnología de la UE Las últimas novedades de la escena tecnológica de la UE, una historia de nuestro sabio fundador Boris y un arte de IA cuestionable. Es gratis, cada semana, en tu bandeja de entrada. ¡Regístrate ahora! El trabajo para abordarlo ha estado, hasta hace poco, dentro de las herramientas de automatización personalizadas de los operadores más grandes, accesibles solo a los ingenieros que las construyeron. Eso está comenzando a cambiar. Shashidhar Bhat, un ingeniero de software en la organización de infraestructura de big data en ByteDance, ha pasado los últimos dos años produciendo un cuerpo de trabajo que se mapea directamente a la capa operativa que el resto de la industria ha estado describiendo como un problema.

      Las piezas, individualmente, parecen componentes de infraestructura ordinarios. Plugins de dispositivo personalizados para una programación de aceleradores más detallada. Herramientas de observabilidad construidas sobre el Administrador de GPU de Centro de Datos de NVIDIA. Lógica de reprogramación de pods autónoma que reacciona a la degradación del hardware sin escalada humana. Cada uno es el tipo de cosa que se envía silenciosamente dentro de un equipo de infraestructura interno. Juntas, describen la capa operativa que la industria ha estado externalizando a ingenieros de confiabilidad del sitio, portadas a software y endurecidas contra la carga de producción.

      La escala a la que opera el trabajo de Bhat es parte de lo que lo hace creíble como una arquitectura de referencia. ByteDance, matriz de TikTok, opera uno de los despliegues de Kubernetes más grandes del mundo. Sus clústeres funcionan en cientos de nodos de GPU procesando aproximadamente un petabyte de datos cada mes. El marco interno de Bhat, un sistema de automatización basado en agentes llamado OpenSkill, ha reducido el tiempo de inactividad de GPU en un treinta y cinco por ciento en ese entorno, contra una línea base que incluía los picos de uso característicos del entrenamiento de recomendadores a gran escala y la distribución de contenido.

      Una cifra del treinta y cinco por ciento es, según los estándares operativos del campo, grande. Los operadores de clase hiperescaladora han estado durante años persiguiendo mejoras de un solo dígito porcentual en las tasas de inactividad, con el razonamiento de que las mejoras de un solo dígito a volúmenes de hiperescaladores se recuperan en cifras de ocho dígitos. Una reducción a la escala que informa Bhat es el tipo de resultado que, cuando aparece en producción en una empresa par, se mantiene en secreto. El hecho de que se haya informado en absoluto es parte de por qué la comunidad de operadores más amplia ha comenzado a prestar atención.

      La otra mitad del trabajo reciente de Bhat ha aparecido en el lado de código abierto. Ha sido un contribuyente a Kubewharf Katalyst, el marco de gestión de recursos mantenido conjuntamente por ByteDance y la comunidad más amplia de Kubernetes. El proyecto Katalyst 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. Las propuestas de diseño que Bhat ha presentado contra el proyecto han movido la discusión en direcciones que paralelan estrechamente su trabajo interno. La convergencia entre el trabajo de producción interno de un ingeniero y las contribuciones externas de código abierto es el raro tipo de patrón que la comunidad de mantenedores reconoce como sustantivo en lugar de promocional.

      La tercera pata del cuerpo de trabajo es Carbon-Kube, el programador de Kubernetes de código abierto que Bhat lanzó el pasado diciembre junto con un artículo de IEEE coescrito con Sathwik Rao Sirikonda, también en ByteDance. El programador es un proyecto distinto de su trabajo interno en ByteDance y aborda la dimensión de las emisiones de carbono de las operaciones de clúster en lugar de la dimensión del número de empleados. El proyecto se envía con un archivo de citación, una metodología de referencia publicada y scripts reproducibles. La contribución es metodológicamente rigurosa de una manera que la mayoría de las herramientas de infraestructura internas nunca se molestan en ser.

      La imagen combinada es lo que hace que el caso valga la pena presentar a nivel de la industria. La capa operativa de infraestructura de IA es un centro de costos del tamaño de una economía media. El trabajo para abordarlo ha estado ocurriendo silenciosamente dentro de las empresas más grandes, accesible solo a sus equipos internos. Eso está cambiando, en parte gracias al trabajo de operadores como Bhat, cuyas contribuciones abarcan implementaciones de producción internas, mantenimiento externo de código abierto y publicaciones de nivel 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 es, a la luz del trabajo que se ha enviado en el último año, difícil de desestimar. Los operadores de clúster en los próximos dos a tres años deberán decidir si construir su propia respuesta o adoptar una de las de código abierto que ahora están disponibles. La composición de esa respuesta remodelará el margen operativo de cada equipo que ejecute cargas de trabajo de IA en producción.