OpenAI priorizaría Codex sobre Sora por la eficiencia de sus GPU

OpenAI estaría priorizando Codex sobre Sora no necesariamente porque el agente de programación consuma menos cómputo, sino porque puede fragmentar y reutilizar mejor el tiempo de GPU. La diferencia plantea cómo la arquitectura de una carga de trabajo, desde la caché KV hasta las llamadas a herramientas, puede influir en qué productos de inteligencia artificial escalan con mayor facilidad.
***

• Sora concentra grandes cantidades de cómputo en una generación de video continua y difícil de reutilizar.
• Codex divide sus tareas entre inferencia, herramientas, pruebas y espera, lo que podría permitir intercalar más agentes en una misma flota de GPU.
• La eficiencia puede evaluarse con métricas como GPU-segundos por tarea, latencia, caché de prefijos, ocupación de KV cache y rendimiento efectivo.

OpenAI estaría desplazando recursos de cómputo y parte del esfuerzo de su equipo desde Sora hacia Codex, según un análisis difundido por KuCoin a partir de una conversación de Sam Altman en el podcast de David Senra. La conversación puede consultarse en el sitio del podcast de David Senra. En publicaciones asociadas al episodio también se describe una priorización de Codex frente a Sora y Atlas, aunque los resultados disponibles no detallan una cantidad concreta de GPU reasignadas.

La explicación atribuida a Altman no tendría que interpretarse como una prueba de que Sora sea un mal producto o de que Codex consuma menos cómputo en todos los casos. El argumento apunta más bien a que ambas herramientas utilizan la capacidad de maneras diferentes: Sora concentra una generación audiovisual continua, mientras Codex puede distribuir sus operaciones entre lecturas de código, inferencias, llamadas a herramientas, ejecución de pruebas y nuevas rondas de razonamiento.

La propia OpenAI ha descrito el uso de Codex para desarrollar la aplicación de Sora para Android en 28 días, según una publicación oficial disponible en su sitio. Por ello, una eventual priorización de Codex no implica necesariamente que ambos productos sean completamente independientes ni que Sora haya dejado de utilizar herramientas de programación basadas en IA.

Una carga de video difícil de fragmentar

La generación de video comienza antes de que el modelo produzca una imagen reconocible para el usuario. El video crudo debe comprimirse en un espacio latente y dividirse en parches espacio-temporales que el Transformer procesa como una estructura tridimensional; por eso, el número de tokens visuales puede aproximarse como N_video ≈ T × H × W, donde las dimensiones temporal y espacial ya fueron comprimidas y segmentadas. Si aumenta la duración, la resolución o el tamaño del cuadro, crece la cuadrícula latente que debe atravesar el modelo.

El proceso tampoco termina necesariamente en una sola pasada de inferencia, porque los sistemas de difusión parten de una representación con ruido y la actualizan durante múltiples iteraciones de muestreo. De forma aproximada, el costo de un video puede expresarse como C_video ≈ D × C_transformer(N_video), con D como número de iteraciones y N_video como el volumen de tokens visuales. Cada nueva ronda trabaja sobre un estado espacio-temporal modificado, de modo que la red debe continuar calculando sobre el video en lugar de reutilizar de manera amplia el historial anterior.

Ahí aparece una diferencia conceptual frente a los modelos de lenguaje, que pueden almacenar las claves y valores previos en una caché KV cuando generan tokens posteriores. En la difusión de video, el latent principal cambia después de cada iteración, por lo que la siguiente ronda debe procesar nuevamente una representación audiovisual alterada; la posibilidad de ahorrar cómputo mediante la reutilización del historial puede ser más limitada. Un video largo, de alta resolución y con más pasos de muestreo tiende a hacer más pesada esa ruta, aunque el costo exacto depende de la arquitectura y de la configuración del servicio.

Una utilización de GPU cercana al máximo tampoco demostraría por sí sola que Sora esté atendiendo muchas solicitudes por unidad de tiempo. Los cálculos matriciales pueden mantener ocupados los Tensor Cores durante largos periodos, pero un solo video podría retener un grupo de GPU mientras acumula un consumo elevado de GPU-segundos por solicitud. Además, las diferencias de duración, resolución y relación de aspecto obligan al servidor a agrupar solicitudes en conjuntos de dimensiones similares, lo que enfrenta una tensión entre esperar un lote más eficiente y responder rápido con un lote incompleto.

Codex divide el trabajo y comparte la capacidad

Una instrucción como “arregla este bug” no representa una única llamada al modelo cuando la procesa Codex como agente. El sistema puede leer un repositorio, decidir el siguiente paso, ejecutar un comando de terminal, recibir un error, incorporar los registros al contexto, modificar el código y correr pruebas antes de volver a razonar sobre los resultados. La tarea se parece así a una secuencia de rondas de prefill, decode y herramientas, con pausas que permitirían al planificador reorganizar el uso de la GPU.

El rastro de trabajo interno puede ser mucho mayor que la respuesta que finalmente lee el usuario. Al pedido inicial se suman archivos, diferencias de código, salidas de terminal, registros de pruebas y resultados de herramientas, mientras el contexto crece durante la ejecución; una tarea que concluye con unos cientos de palabras puede haber procesado un volumen considerable de información. Por esa razón, el consumo lógico de tokens no refleja por sí solo el costo real de hardware, especialmente cuando el agente regresa repetidamente al modelo.

La caché de prefijos se vuelve relevante en ese escenario. Si un agente ya posee un contexto de 100.000 tokens y una herramienta agrega 3.000 tokens de registros, un prefijo estable almacenado en caché permitiría concentrar el cálculo nuevo en la parte añadida; si un cambio temprano provoca un fallo de caché, el sistema podría enfrentar nuevamente un prefill pesado. Dos solicitudes con 100.000 tokens de entrada pueden producir cargas de GPU muy distintas, dependiendo de cuánto contenido reutilicen, cuántas rondas ejecuten y a qué velocidad crezca su contexto. Las cifras de este ejemplo son ilustrativas, no una medición pública de Codex.

Prefill y decode también ejercen presiones diferentes sobre el hardware. El primero procesa muchos tokens de entrada en paralelo y favorece cargas intensivas de cómputo, mientras el segundo genera pocos tokens por secuencia y depende más del ancho de banda de la memoria HBM, de la caché KV y de la concurrencia; sin agrupamiento, decodificar una sola secuencia puede resultar ineficiente porque cada token exige un recorrido completo por los pesos del modelo. Diseños como el batching continuo y PagedAttention buscan que más secuencias compartan accesos y que la memoria se administre con menor fragmentación.

La planificación define qué producto escala

Las llamadas a herramientas ofrecen otra ventaja estructural a los agentes de programación. Cuando Codex compila código, ejecuta pruebas, lee archivos o espera una operación de entrada y salida, la GPU puede ceder el turno mientras la CPU, los contenedores y el sistema de archivos realizan el trabajo externo. Un agente que permanece activo durante 60 minutos no necesariamente ocupa la GPU durante todo ese periodo, porque su tiempo de reloj alterna entre inferencia y actividades que ocurren fuera del modelo.

La consecuencia potencial es que una flota limitada pueda sostener más flujos de trabajo activos si el planificador intercala sus etapas. Mientras algunos agentes ejecutan un prefill, otros decodifican, varios esperan herramientas y otros reciben resultados de pruebas que deben incorporarse al contexto, esa mezcla podría reutilizar el mismo lote de capacidad de inferencia. El cálculo exacto depende de cada tarea, pero la relación general conecta las horas de agente con las horas de GPU, la proporción de tiempo dedicado a inferencia y la eficiencia de planificación.

Ese diseño introduce, sin embargo, decisiones complejas sobre la memoria. Un agente que espera una herramienta puede conservar su caché KV para reanudar con rapidez, aunque esa reserva ocupa HBM durante un periodo prolongado; desalojarla libera espacio, pero obliga a pagar un costo de recuperación cuando la tarea vuelve al modelo. A medida que aumenta el número de agentes, el sistema se parece a un sistema operativo que administra procesos dormidos y activos, con estados que deben conservarse, paginarse o reconstruirse.

Por eso, la capacidad ya no se evalúa únicamente con el porcentaje de utilización de GPU. Los equipos deben observar los GPU-segundos por tarea, el tiempo hasta el primer token, el tiempo por token de salida, la latencia de cola, la tasa de aciertos de la caché de prefijos, la ocupación de la caché KV y el rendimiento efectivo sujeto a los objetivos de nivel de servicio. En conjunto, esas métricas pueden indicar cuántas tareas monetizables sostiene una GPU por hora sin deteriorar la experiencia del usuario.

La separación entre prefill y decode puede reforzar esa flexibilidad, ya sea mediante fragmentos de prefill que se intercalan con decode o con grupos distintos de GPU para cada etapa. El prefill tiende a exigir mayor rendimiento de cómputo, mientras el decode necesita ancho de banda de HBM, espacio para cachés y latencia consistente por token; configurar ambos procesos de manera independiente puede evitar que un contexto de 100.000 tokens detenga la respuesta de otras secuencias.

Desde la perspectiva de producto, añadir GPU a Codex puede incrementar la cantidad de agentes concurrentes además de acelerar tareas individuales. Un ingeniero podría lanzar trabajos paralelos para modificar un backend, crear pruebas o atender repositorios distintos, siempre que no existan dependencias fuertes entre ellos; en Sora, por el contrario, añadir GPU aumenta de forma más directa el rendimiento de videos, pero no separa con la misma facilidad el tiempo de generación de la ocupación del hardware.

La decisión atribuida a Altman refleja, en última instancia, una hipótesis sobre la forma de las cargas de trabajo y no una comparación pública y concluyente de consumo energético, FLOP o rentabilidad entre ambos productos. Sora concentra recursos en una secuencia audiovisual que requiere cálculo continuo, mientras Codex fragmenta su actividad y podría permitir que el planificador intercale inferencia, caché y herramientas entre numerosos agentes. Si OpenAI efectivamente está reasignando capacidad, la pregunta decisiva sería cuántas tareas adicionales puede soportar cada nuevo lote de GPU dentro de una latencia aceptable; con la información disponible, que esa respuesta favorezca a Codex es una explicación plausible, no un dato operativo confirmado.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín