Ultraman reveló en el podcast por qué OpenAI prioriza recursos para Codex en lugar de Sora. La generación de video de Sora requiere una gran cantidad de potencia de cómputo continua, y el tiempo de GPU por tarea es difícil de reutilizar; en cambio, Codex distribuye la potencia de cómputo en múltiples etapas intercaladas mediante mecanismos como KV cache, batching continuo y llamadas a herramientas, permitiendo que la misma GPU soporte más flujos de trabajo paralelos. La capacidad de reutilización del tiempo de GPU comienza a determinar la velocidad de expansión de los productos de IA.

Autor y fuente del artículo: Leifeng.com

¿Por qué Sora perdió frente a Codex?

El 23 de agosto, Otomani mencionó espontáneamente a Sora al hablar sobre las decisiones de asignación de recursos dentro de OpenAI en el podcast de David Senra.

Él lo dijo directamente: Sora es un buen producto, y continuar con él podría convertirse en un buen negocio, pero consume demasiada capacidad de cómputo; en ese mismo período, Codex tenía una prioridad más alta, por lo que la capacidad de cómputo y el esfuerzo del equipo comenzaron a inclinarse hacia Codex.

Pero lo interesante es que Codex tampoco ahorra GPU. Sora genera un video requiriendo que el gran latent espaciotemporal pase por múltiples cálculos de Transformer; Codex, al recibir el comando “arregla este bug”, puede ejecutar en segundo plano muchas rondas de inferencia, leer código, llamar herramientas, ejecutar pruebas, y luego regresar con nuevos registros y contexto para continuar con la inferencia.

Uno concentra toda la potencia de cómputo en una sola generación de video, mientras que el otro distribuye la potencia de cómputo a lo largo de un flujo de trabajo de Agent que puede durar decenas de minutos o más. Así, la verdadera brecha entre Sora y Codex comienza a manifestarse dentro de las salas de servidores.

Con el mismo lote de GPU, ¿por qué el cómputo para generación de video es más difícil de distribuir, mientras que el Coding Agent puede reinsertar la capacidad de cómputo en más tareas concurrentes mediante KV cache, batching continuo, programación de prefill / decode y espera de herramientas?

De hecho, Sora no perdió por el valor absoluto de consumo de potencia de cálculo, sino por su arquitectura de carga de trabajo: la potencia de cálculo de Sora es continua y exclusiva, mientras que la de Codex es fragmentada y reutilizable. Es precisamente esta diferencia en el mecanismo de programación la que ha generado la disparidad en la velocidad de expansión entre ambos.

Mirando más allá de esta línea, se puede ver que la parte de recursos que perdió Sora podría ser el resultado de una elección sobre cómo deberían usarse los tiempos de GPU.

El costo de Sora probablemente ya comienza a aumentar desde el momento en que el video ingresa al modelo. Primero comprime el video original al espacio latent, luego lo divide en parches spacetime, y permite que el Transformer calcule sobre estos parches.

Los tokens de texto crecen principalmente en la dirección de la secuencia, mientras que los patches de video se distribuyen simultáneamente en el tiempo, la altura y la anchura, por lo que el video es inherentemente un estado tridimensional dentro del modelo.

En términos generales, el número de tokens visuales se puede entender como N_video ≈ T × H × W. Aquí, T, H y W ya han sido comprimidos y divididos en parches, pero la relación de multiplicación tridimensional aún persiste.

Alargar la duración del video aumenta los patch en la dirección temporal, y aumentar las dimensiones de la imagen amplía los patch espaciales. Es decir, la longitud del video y las dimensiones espaciales no aumentan el costo de forma independiente; juntas expanden la cuadrícula latent.

Después de que este bloque de cuadrícula entre en el Transformer, debe enfrentar el segundo nivel de cálculo introducido por la difusión. Sora comienza con un latent ruidoso, y en cada iteración actualiza la representación del video según el estado actual, luego envía el nuevo latent a la siguiente iteración.

El cálculo de un solo video se puede entender aproximadamente como C_video ≈ D × C_transformer(N_video), donde D es el número de iteraciones de muestreo. Cuanto mayor sea el latent del video, más pesada será cada ronda; al aumentar el número de iteraciones de muestreo, el mismo video debe ejecutarse varias veces más en la red.

Aquí se puede ver la diferencia clave entre la difusión de video y los LLM. Al generar tokens siguientes, los modelos de lenguaje pueden guardar las claves y valores anteriores en la caché KV, por lo que el modelo no necesita reconstruir todo el estado histórico en cada paso.

Cada vez que se completa una actualización de video diffusion, el latent principal ya ha cambiado, y la siguiente ronda se enfrenta a un nuevo estado espaciotemporal, por lo que aún se deben realizar grandes cálculos sobre el sujeto del video.

Por lo tanto, el costo de Sora es difícil de reducir significativamente mediante la "reutilización del historial". Es más como una secuencia de efectos visuales que pasa por múltiples procesamientos, donde cada etapa debe manejar una imagen completa que ya ha cambiado. Cuanto más larga sea la video, mayor sea su resolución y más muestras se tomen, más pesada se vuelve esta ruta de generación.

Precisamente porque cada tarea es lo suficientemente intensa, la utilización de la GPU de Sora puede ser muy buena. Los cálculos de matrices de gran tamaño permiten que los Tensor Core permanezcan ocupados durante mucho tiempo, y en los gráficos de monitoreo, la GPU casi no se detiene.

Una alta utilización solo indica que el chip ha estado funcionando continuamente, pero no significa que se hayan entregado muchas tareas por unidad de tiempo. Si un video ocupa un conjunto de GPU durante mucho tiempo, incluso si la utilización parece excelente, el consumo de GPU-seconds por solicitud sigue siendo alto.

El servicio de video aún se verá afectado por diferencias de forma. Duraciones, resoluciones y relaciones de aspecto distintas generan diferentes formas de tensor. Para mejorar la eficiencia por lotes, el servidor debe agrupar solicitudes con dimensiones similares en el mismo bucket. Esperar un poco más permite formar lotes más densos, pero aumenta la latencia de cola; ejecutar inmediatamente reduce el tiempo de espera, pero el lote puede no llenarse por completo.

Por lo tanto, la mayor parte del costo de cómputo de Sora ya está bloqueada en la propia ruta de generación de un video. Se pueden reducir las rondas de muestreo, comprimir aún más los latent, distilar el modelo y optimizar los kernel, pero lo que el scheduler puede modificar principalmente es "cómo ordenar estas tareas intensivas", y es difícil cambiar el hecho de que "un video en sí mismo requiere una gran cantidad de cálculos continuos".

Este también es el punto de entrada para comprender Codex. Codex también es costoso, pero no carga todo el costo en un solo bloque de cálculo continuo; en su lugar, divide la tarea en muchas etapas que pueden pausarse, reanudarse y volver a combinarse.

El usuario le da a Codex la instrucción "arregla este bug"; la tarea no termina con una sola llamada al modelo. El agente puede primero leer el repositorio, hacer que el modelo determine el siguiente paso y luego ejecutar un shell; después de obtener el error, incorporar los registros al contexto y volver a llamar al modelo; posteriormente, modificar el código, ejecutar pruebas y continuar razonando según los nuevos resultados.

Entonces, una tarea de Codex se acerca más a la acumulación de muchas rondas Prefill + Decode + Tool. La clave es que, tras completar cada ronda de llamada a herramientas, el contexto que ve el modelo en la siguiente ronda suele ser más extenso que en la anterior.

Al inicio de la tarea, el modelo solo tiene los requisitos del usuario y un pequeño código. Después de ejecutarse durante un tiempo, más archivos, diff, salida de terminal, registros de pruebas y resultados de herramientas ingresan continuamente al prompt.

Lo que el usuario ve finalmente puede ser solo unas pocascientas palabras de instrucciones completas, pero el contenido procesado por la GPU puede haberse vuelto ya muy extenso. La presión sobre el consumo de tokens del agente se esconde en esta trayectoria de trabajo en constante crecimiento.

Si cada inferencia vuelve a procesar todo el historial, las tareas largas se ralentizarán rápidamente por el prefill repetido, por lo que el almacenamiento en caché de prompts es crucial para Codex.

Supongamos que un agente ya tiene 100K tokens de contexto, y después de ejecutar la herramienta, solo se agregan 3K tokens de registro; si el prefijo estable anterior puede coincidir con la caché, el cálculo adicional de esta ronda se concentrará principalmente en esta última parte; si un cambio en la parte inicial del prompt provoca un cache miss, el sistema podría enfrentar nuevamente un prefill muy pesado.

Aquí ha ocurrido un cambio importante: el número de tokens lógicos ya no puede representar directamente el costo real de la GPU. Ambas solicitudes muestran 100K tokens de entrada, pero una tiene la mayor parte del contenido ya en caché, mientras que la otra requiere cálculo nuevamente, lo que genera una carga completamente distinta en la GPU. La carga del agente depende, por lo tanto, de la velocidad de crecimiento del contexto, el porcentaje de aciertos en caché y cuántas veces se repite una tarea dentro del modelo.

Después de ingresar a una inferencia única, el prefill y el decode tienen diferentes requisitos de hardware. El prefill procesa muchos tokens de entrada a la vez, con matrices de tamaño grande, lo que facilita la formación de una carga de trabajo intensiva en cómputo; el decode genera solo unos pocos tokens por secuencia por ciclo, pero debe acceder repetidamente a los pesos del modelo y al KV cache, por lo que depende más del ancho de banda HBM y la escala de concurrencia.

Esto significa que decodificar una sola secuencia por separado sería muy ineficiente. Los pesos del modelo siguen siendo tan grandes que, para generar un solo token, se requiere una ejecución completa de la forward pass. El servidor solo puede hacer que un solo acceso a los pesos avance múltiples solicitudes al agrupar muchas secuencias en un mismo batch forward.

Sin embargo, el lote no puede seguir aumentando debido a la limitación del KV cache. Cuanto más larga sea la secuencia, más HBM ocupará. Después de aumentar la cantidad de agentes, la GPU puede aún tener capacidad de cálculo disponible, pero la memoria显存 ya no puede contener más estados activos.

Los diseños como PagedAttention gestionan la caché KV mediante paginación, reduciendo la fragmentación de memoria y, en esencia, aumentando el número de secuencias activas que una GPU puede alojar simultáneamente.

La llamada a herramientas divide aún más la carga de Codex. Cuando el agente ejecuta pruebas, compila código o espera I/O, la GPU ya no necesita seguir trabajando para él; el CPU, los contenedores y el sistema de archivos asumen la tarea. Una vez que los resultados regresan, el agente entra en la siguiente ronda de inferencia.

Entonces, un agente que se ejecuta durante 60 minutos no significa que ocupe continuamente la GPU durante 60 minutos. Su tiempo de tarea se divide en cálculo del modelo y ejecución externa, lo que le da al programador un espacio que Sora difícilmente puede proporcionar: cuando un agente ejecuta una herramienta, la GPU puede inmediatamente servir a otra secuencia.

Por supuesto, esto también generará nuevos problemas de memoria de vídeo. ¿Debe el agente que espera la herramienta conservar la caché KV? Conservarla permite una recuperación más rápida, pero ocupa HBM a largo plazo; expulsarla libera espacio, pero cuando la tarea regrese, debe asumir el costo de recuperación. Cuantos más agentes haya, más este equilibrio se asemeja a cómo un sistema operativo gestiona una gran cantidad de procesos que entran y salen del estado de suspensión.

Aquí, la diferencia entre Codex y Sora ya no está en "cuál es más pesado", sino en si los costos han sido desglosados. La capacidad de cómputo de Sora está concentrada en una ruta de generación continua, mientras que la capacidad de cómputo de Codex está distribuida en varias etapas. Precisamente por estar desglosado, Codex puede acceder a la siguiente capa de optimización: permitir que el programador decida cómo compartir estas etapas el mismo conjunto de GPU.

Durante la ejecución en línea de modelos grandes, los pesos generalmente deben permanecer persistentemente en la GPU, además de mantener el tensor parallel, la comunicación entre nodos y el estado de caché. Por lo tanto, la competencia por recursos entre Sora y Codex ocurre principalmente a nivel de flota: una parte de las GPU permanece constantemente en el pool de servicio de video, mientras que otra parte permanece constantemente en el pool de LLM, y el sistema de capacidad superior decide dónde escalar o reducir.

Lo realmente complejo ocurre dentro del pool de Codex. Supongamos que en el sistema existen simultáneamente 200 secuencias de Agent, algunas en proceso de decode, otras esperando herramientas, y decenas que acaban de regresar del entorno de herramientas y necesitan procesar nuevos contextos largos. El scheduler enfrenta restricciones que no solo incluyen FLOPs, sino también capacidad de HBM, ancho de banda de memoria, residencia de KV cache y presupuesto de latencia.

Continuous batching primero resuelve el problema de utilización del decode. El batch estático tradicional vincula un conjunto de solicitudes juntas; después de que las secuencias cortas terminen, las solicitudes largas restantes aún ocupan el batch.

El agrupamiento continuo realiza intercambios dinámicos a nivel de iteración de tokens; una secuencia se retira al completarse, y nuevas solicitudes se incorporan inmediatamente. Cuanto más grande sea el lote, más secuencias pueden avanzarse en un solo cálculo del modelo, lo que permite distribuir mejor los costos de acceso a los pesos del modelo y el ancho de banda de memoria.

Pero aquí pronto se encontrará con el límite de memoria de video. Los grandes cachés KV de Agent prolongados ocuparán continuamente la HBM, y es posible que una GPU aún no haya llenado completamente los Tensor Cores, pero la memoria ya no pueda alojar más secuencias. En este punto, seguir aumentando la potencia de cálculo no tiene sentido; lo que realmente limita la concurrencia es la capacidad de caché y la gestión de la memoria de video.

Existe otro conflicto entre prefill y decode. Suponga que decenas de secuencias están decodificando de manera estable, cuando un agente regresa con un nuevo contexto de 100K tokens que requiere un prefill masivo. Si este prefill ocupa un intervalo de ejecución prolongado, el TPOT de las solicitudes adyacentes se deteriorará notablemente.

Chunked prefill divide la entrada larga en varios bloques pequeños para permitir la ejecución intercalada de prefill y decode; una práctica aún más avanzada consiste en separar prefill y decode en distintos pools de GPU.

La razón es que ambas fases tienen distintas limitaciones de hardware: prefill se enfoca más en el rendimiento de cálculo, mientras que decode depende más del ancho de banda HBM, el caché KV y una latencia estable por token. Al separarlas, se pueden configurar los recursos según sus necesidades específicas.

Esto indica que el núcleo de Agent serving va más allá de “hacer más rápido el kernel del modelo”. Muchos aumentos de capacidad provienen de reorganizar cuándo y dónde ejecutar las tareas, qué estados valen la pena mantener en la memoria de la GPU y quién debería incluirse en el lote actual.

Por lo tanto, la utilización de la GPU ya no es suficiente aquí. El equipo de capacidad debe monitorear simultáneamente GPU-seconds per task, TTFT (latencia del primer token, que determina si el usuario percibe lentitud), TPOT (tiempo de generación por token, que determina qué tan rápido “habla” el modelo), latencia de cola, tasa de acierto del prefix cache, ocupación del KV cache y SLO goodput (throughput efectivo, que representa la capacidad de cómputo realmente rentable).

Estos indicadores responden conjuntamente a una pregunta: ¿cuántas tareas efectivas puede mantener una GPU durante una hora bajo la latencia aceptable para el usuario?

La escalabilidad de Codex se manifiesta aquí. El prefijo estable reduce la reutilización de prefill, el decode permite batch continuo, la caché KV puede ser paginada y expulsada, y mientras el agente espera herramientas, puede ceder la GPU. Su carga de trabajo es muy fragmentada, pero estos fragmentos pueden ser reorganizados por el programador.

Esto lleva naturalmente la pregunta a la capa de recursos: si el mismo conjunto de GPU puede atender intercaladamente a más Agentes a largo plazo, entonces el tiempo de trabajo real que una hora de GPU puede soportar podría ser superior a una hora.

Supongamos que un Codex Agent tarda 60 minutos en completar una tarea desde su inicio hasta su finalización, pero solo una parte de ese tiempo se utiliza realmente para prefill y decode del modelo; el resto se dedica a compilación, pruebas, lectura/escritura de archivos o espera de herramientas. La proporción exacta variará según la tarea, pero la estructura es importante: el tiempo de reloj del agente y el tiempo de cómputo en GPU no son equivalentes uno a uno.

Si en el sistema existen muchos agentes simultáneamente, no todos necesitarán GPU en el mismo segundo. Algunos están en prefill, otros en decode, algunos ejecutan pruebas y otros esperan el sistema de archivos. Si el programador puede entrelazar estas fases, una cantidad limitada de GPU puede mantener un número mucho mayor de flujos de trabajo activos que el número de GPU.

Se puede entender aproximadamente esta relación como: las horas de agente dependen de las horas de GPU, la relación de uso del modelo de inferencia y la eficiencia de programación. Cuanto más tiempo se dedique a la ejecución de herramientas, mayor sea el tamaño del lote y mayor sea la tasa de aciertos en caché, más oportunidad tendrá una hora de GPU de soportar un mayor tiempo de reloj del agente.

Esto cambiará directamente el significado de agregar nuevas GPU. Añadir un conjunto de GPU a Codex no solo acelerará tareas individuales, sino que también podría permitir que el sistema mantenga simultáneamente más agentes. Un ingeniero puede iniciar múltiples tareas en paralelo: una para modificar el backend, otra para completar pruebas, y otra para manejar otro repositorio; siempre que estas tareas no tengan dependencias fuertes entre sí, el tiempo de trabajo de la máquina puede crecer en paralelo.

La curva de capacidad de Sora es más directa. El largo tiempo de reloj de un video impulsa directamente la difusión en la GPU, integrando más estrechamente la tarea individual y el uso de la GPU. Se puede aumentar directamente el rendimiento de video añadiendo más GPU, pero es difícil lograr una gran diferencia entre el tiempo de GPU de una hora y el tiempo de cálculo del video.

Una tarea de software de Codex se mueve entre GPU, CPU, contenedores, sistemas de archivos y entornos de herramientas. La GPU se encarga de la inferencia del modelo, mientras que otros sistemas se encargan de la ejecución, y múltiples Agentes comparten intercaladamente la capacidad de inferencia a través del programador. Así, la GPU deja de ser simplemente un dispositivo de generación y se convierte en un recurso escaso de “pensamiento” dentro de todo el sistema de Agentes.

Por eso Codex, aunque también puede consumir grandes cantidades de compute, tiene más facilidad para obtener nuevo compute. OpenAI debe considerar no solo el costo de inferencia individual, sino también si la capacidad adicional puede convertirse rápidamente en mayor volumen de trabajo paralelo.

Cuando un lote de GPU puede soportar más agentes a largo plazo, y estos agentes pueden recibir continuamente nuevas tareas de software, los recursos fácilmente continuarán fluyendo en esta dirección.

El significado técnico de esa frase de Altman se vuelve claro así. La gran cantidad de poder de cómputo de Sora está bloqueada en una sola ruta de generación, mientras que el poder de cómputo de Codex se divide en múltiples etapas intercalables. Ambos son igualmente costosos, pero sus curvas de retorno de recursos son distintas.

Sora y Codex: instrucciones sobre la transferencia de recursos; los productos de IA comienzan a tener una variable adicional que afecta directamente la velocidad de expansión: workload architecture.

Al utilizar GPU costosas, una categoría de tareas bloquea gran cantidad de capacidad de cómputo en una sola ruta de generación, mientras que otra categoría puede aprovechar caché, batching, ejecución de herramientas y programación para intercalar la misma capacidad de inferencia entre más flujos de trabajo; sus curvas de recursos naturalmente se separarán.

Entonces, algunos problemas que parecen muy básicos en el futuro se acercarán cada vez más a cuestiones de producto: ¿cómo almacenar el KV cache?, ¿cómo dividir el prefill?, ¿qué tan denso puede ser el decode batch?, ¿deben expulsar la caché los Agentes que esperan herramientas? Estas decisiones determinarán cuántas tareas puede mantener simultáneamente un conjunto de GPU.

La diferencia entre Sora y Codex no es solo la diferencia entre video y código.

Están compitiendo por la misma hora de GPU, ¿cuánto trabajo puede soportar realmente?