Ultraman revelou no podcast por que a OpenAI direcionou recursos para o Codex em vez do Sora. A geração de vídeo pelo Sora exige grande quantidade de poder de processamento contínuo, e o tempo de GPU ocupado por uma única tarefa é difícil de reutilizar; já o Codex, por meio de mecanismos como KV cache, batching contínuo e chamadas de ferramentas, distribui o poder de processamento em múltiplos estágios intercaláveis, permitindo que o mesmo GPU suporte mais fluxos de trabalho paralelos. A capacidade de reutilização do tempo de GPU começa a determinar a velocidade de expansão dos produtos de IA.

Autor e fonte do artigo: LeiFeng.com

Por que Sora perdeu para Codex?

Em 23 de agosto, Otomani mencionou espontaneamente o Sora ao discutir sobre a alocação de recursos dentro da OpenAI no podcast de David Senra.

Ele foi direto: Sora é um bom produto, e continuar desenvolvendo-o poderia se tornar um bom negócio, mas consome muita computação; no mesmo período, a prioridade do Codex era maior, então a capacidade de processamento e o esforço da equipe começaram a ser direcionados para o Codex.

Mas, curiosamente, o Codex também não economiza GPU. Para gerar um vídeo, o Sora precisa fazer múltiplas iterações de cálculo Transformer sobre um latent espaciotemporal enorme; já o Codex, ao receber o comando “corrija esse bug”, pode executar inúmeras rodadas de inferência em segundo plano, ler o código, chamar ferramentas, executar testes e retornar com novos logs e contexto para continuar a inferência.

Um coloca todo o poder de processamento em uma única geração de vídeo, enquanto o outro distribui o poder de processamento ao longo de um fluxo de trabalho de Agent que pode durar dezenas de minutos ou mais. Assim, a verdadeira diferença entre Sora e Codex começa a se manifestar dentro das salas de servidores.

Mesmo sendo o mesmo lote de GPUs, por que o cálculo para geração de vídeo é mais difícil de distribuir, enquanto o Coding Agent consegue recolocar a capacidade de processamento em mais tarefas simultâneas por meio de KV cache, batching contínuo, agendamento de prefill/decode e espera por ferramentas?

Na verdade, o Sora não perdeu em termos de consumo absoluto de poder de computação, mas sim em sua arquitetura de carga de trabalho: o poder de computação do Sora é contínuo e exclusivo, enquanto o do Codex é fragmentado e reutilizável. É exatamente essa diferença no mecanismo de agendamento que explica a disparidade na velocidade de expansão entre os dois.

Olhando ao longo dessa linha, pode-se perceber que a parte de recursos que o Sora perdeu pode estar por trás de uma escolha sobre como usar o tempo de GPU.

O custo do Sora talvez já comece a aumentar desde o momento em que o vídeo entra no modelo. Ele primeiro comprime o vídeo original para o espaço latent e depois o divide em patches spacetime, permitindo que o Transformer calcule sobre esses patches.

O token de texto cresce principalmente na direção da sequência, enquanto os patches de vídeo são distribuídos simultaneamente no tempo, altura e largura, tornando o vídeo naturalmente um estado tridimensional dentro do modelo.

Em termos gerais, o número de tokens visuais pode ser entendido como N_video ≈ T × H × W. Aqui, T, H e W já foram comprimidos e divididos em patches, mas a relação de multiplicação tridimensional ainda persiste.

Alongar o tempo do vídeo aumenta os patches na direção temporal, enquanto aumentar as dimensões da imagem expande os patches espaciais. Ou seja, o comprimento do vídeo e as dimensões espaciais não aumentam o custo de forma independente; juntos, eles expandem a grade latent.

Após entrar no Transformer, este bloco de grade enfrenta uma segunda camada de cálculo trazida pela difusão. O Sora começa com um latent ruidoso e, em cada iteração, atualiza a representação do vídeo com base no estado atual, enviando o novo latent para a próxima iteração.

O cálculo de um único vídeo pode ser aproximado como C_video ≈ D × C_transformer(N_video), onde D é o número de iterações de amostragem. Quanto maior o latent do vídeo, mais pesada fica cada iteração; aumentar o número de iterações significa que o mesmo vídeo precisa passar várias vezes pela rede.

Aqui é possível ver a diferença-chave entre diffusion de vídeo e LLM. Ao gerar tokens subsequentes, os Key e Value anteriores podem ser armazenados no KV cache, e o modelo não precisa reconstruir todo o estado histórico em cada etapa.

Após cada ciclo de atualização da difusão de vídeo, o latent principal já mudou, e o próximo ciclo enfrenta um novo estado espaciotemporal; portanto, grande parte do cálculo do objeto do vídeo ainda precisa ser executado.

Portanto, o custo do Sora é difícil de reduzir significativamente por meio da “reutilização de histórico”. Ele é mais como um segmento de efeitos visuais passando por múltiplas etapas de processamento, onde cada etapa precisa lidar com uma imagem inteira que já mudou. Quanto mais longo for o vídeo, maior for a resolução e maior for a amostragem, mais pesada se torna essa rota de geração.

Justamente porque cada tarefa é suficientemente pesada, a utilização da GPU do Sora pode ser muito boa. Cálculos de matrizes de grande tamanho permitem que os Tensor Cores permaneçam ocupados por longos períodos, e os gráficos de monitoramento mostram a GPU quase sempre ativa.

Alta utilização apenas indica que o chip está sempre em funcionamento, mas não significa que muitas tarefas foram entregues por unidade de tempo. Se um único vídeo ocupar um conjunto de GPUs por muito tempo, mesmo que a utilização pareça excelente, o consumo de GPU-seconds por solicitação ainda será alto.

O serviço de vídeo ainda será bloqueado por diferenças de forma. Duração, resolução e proporção de aspecto diferentes criam diferentes formas de tensor. Para aumentar a eficiência do lote, o servidor precisa agrupar solicitações com dimensões semelhantes no mesmo bucket. Esperar um pouco mais permite formar lotes mais densos, mas aumenta a latência na fila; executar imediatamente reduz o tempo de espera, mas o lote pode não ser preenchido completamente.

Portanto, a maior parte do custo de computação do Sora já está vinculada ao próprio caminho de geração de um vídeo. O número de amostragens pode ser reduzido, os latent podem ser comprimidos ainda mais, o modelo pode ser distilado e os kernels podem ser otimizados continuamente, mas o que o scheduler pode alterar principalmente é “como essas tarefas pesadas são agendadas”, dificilmente conseguindo mudar o fato de que “um único vídeo exige uma grande quantidade de cálculos contínuos”.

Este também é o ponto de entrada para entender o Codex. O Codex também é caro, mas não repassa todo o custo para um único bloco de cálculo contínuo; em vez disso, divide a tarefa em muitas etapas que podem ser pausadas, retomadas e recombinações.

O usuário deu ao Codex a instrução “corrija esse bug”; a tarefa não termina com uma única chamada ao modelo. O agente pode primeiro ler o repositório, fazer com que o modelo determine o próximo passo e, em seguida, executar um shell; após obter o erro, adicionar os logs ao contexto e chamar o modelo novamente; posteriormente, modificar o código, executar os testes e continuar raciocinando com base nos novos resultados.

Então, uma tarefa do Codex é mais próxima da soma de muitas rodadas Prefill + Decode + Tool. A chave é que, após cada rodada de chamada de ferramenta, o contexto visto pelo modelo na próxima rodada geralmente é mais amplo do que na anterior.

No início da tarefa, o modelo pode ter apenas o pedido do usuário e um pequeno trecho de código. Após rodar por algum tempo, mais arquivos, diffs, saídas do terminal, logs de testes e resultados de ferramentas são continuamente adicionados ao prompt.

O que o usuário viu por último pode ser apenas algumas centenas de palavras de instrução final, mas o conteúdo processado pelo GPU pode já ter se tornado muito extenso. A pressão do consumo de tokens do agente está escondida nessa trajetória de trabalho em constante crescimento.

Se cada inferência reprocessar todo o histórico, tarefas longas serão rapidamente lentas devido ao pré-carregamento repetido, tornando o cache de prompt essencial para o Codex.

Suponha que um agente já possua 100K tokens de contexto e que a execução da ferramenta adicione apenas 3K tokens de log. Se o prefixo estável anterior puder acertar o cache, o cálculo adicional desta rodada concentrar-se-á principalmente nesta última parte; caso uma alteração na parte inicial do prompt cause cache miss, o sistema poderá enfrentar novamente um prefill muito pesado.

Ocorreu uma mudança importante: o número de tokens lógicos já não pode representar diretamente o custo real da GPU. Ambas as requisições mostram 100K tokens de entrada, mas uma delas tem grande parte do conteúdo já em cache, enquanto a outra precisa ser recalculada, resultando em pressões totalmente diferentes sobre a GPU. A carga do agente depende, portanto, da velocidade de crescimento do contexto, da taxa de acerto no cache e de quantas vezes uma tarefa é repetidamente inserida no modelo.

Após entrar na inferência única, o prefill e o decode apresentam diferentes requisitos de hardware. O prefill processa muitos tokens de entrada de uma vez, com matrizes de grande tamanho, tornando-se mais propenso a gerar cargas de trabalho intensivas em computação; o decode gera apenas poucos tokens por sequência a cada etapa, mas precisa acessar repetidamente os pesos do modelo e o KV cache, sendo, portanto, mais dependente da largura de banda HBM e da escala de concorrência.

Isso significa que decodificar uma única sequência separadamente seria muito ineficiente. Os pesos do modelo ainda são tão grandes que, para gerar um único token, é necessário realizar um cálculo completo para frente. O servidor só consegue fazer com que uma única acessa aos pesos avance múltiplos pedidos ao agrupar várias sequências em um único batch forward.

E o lote ainda pode ser aumentado, mas será limitado pelo cache KV. Quanto mais longo o contexto de cada sequência, mais HBM será consumido. Após aumentar o número de agentes, a GPU pode ainda ter capacidade de processamento disponível, mas a memória de vídeo já não consegue acomodar mais estados ativos.

Projetos como o PagedAttention gerenciam o cache KV de forma paginada, reduzindo a fragmentação de memória GPU e, essencialmente, aumentando o número de sequências ativas que uma GPU pode acomodar simultaneamente.

A chamada de ferramentas divide ainda mais a carga do Codex. Enquanto o Agente executa testes, compila código ou aguarda I/O, a GPU não precisa continuar trabalhando para ele — o CPU, o contêiner e o sistema de arquivos assumem. Quando os resultados retornam, o Agente entra na próxima rodada de inferência.

Então, um Agent que executa por 60 minutos não significa que ocupa continuamente o GPU por 60 minutos. Seu tempo de tarefa é dividido em cálculo do modelo e execução externa, permitindo ao scheduler um espaço que o Sora dificilmente pode oferecer: quando um Agent executa uma ferramenta, o GPU pode imediatamente atender outra sequência.

Claro, isso também criará novos problemas de memória de vídeo. O agente que aguarda a ferramenta deve manter ou não o KV cache? Mantê-lo permite recuperação mais rápida, mas ocupa permanentemente o HBM; evitá-lo libera espaço, mas quando a tarefa retornar, será necessário enfrentar o custo de recuperação. Quanto maior o número de agentes, mais essa escolha se assemelha ao gerenciamento de um sistema operacional de diversos processos que entram e saem do sono.

Até aqui, a diferença entre Codex e Sora não está mais em "qual é mais pesado", mas sim em se os custos foram separados. A capacidade de processamento do Sora está concentrada em um caminho de geração contínuo, enquanto a capacidade de processamento do Codex está distribuída em várias etapas. Justamente por estar separada, o Codex pode entrar na próxima camada de otimização: permitir que o scheduler decida como essas etapas compartilham o mesmo conjunto de GPUs.

Durante a execução online de modelos grandes, os pesos geralmente permanecem permanentemente na GPU e precisam manter o tensor parallel, comunicação entre nós e estado de cache. Portanto, a competição por recursos entre Sora e Codex ocorre principalmente no nível da frota: parte das GPUs permanece permanentemente no pool de serviço de vídeo, enquanto outra parte permanece permanentemente no pool de LLM, e o sistema de capacidade superior decide onde expandir ou reduzir.

As coisas realmente complexas ocorrem dentro do Codex pool. Suponha que haja 200 sequências de Agent simultaneamente no sistema, algumas em processo de decode, outras aguardando ferramentas e dezenas acabaram de retornar do ambiente da ferramenta, precisando processar novos contextos longos. O scheduler enfrenta restrições que não incluem apenas FLOPs, mas também capacidade HBM, largura de banda de memória, residência do KV cache e orçamento de latência.

O batching contínuo resolve primeiro o problema de utilização da decodificação. O batching estático tradicional vincula um conjunto de solicitações juntas, e após as sequências curtas terminarem, as solicitações mais longas ainda ocupam o batch.

O batching contínuo realiza troca dinâmica no nível da iteração de tokens; assim que uma sequência é concluída, ela é removida e novas requisições são imediatamente inseridas. Quanto maior o lote, mais sequências podem ser avançadas em um único ciclo de cálculo do modelo, tornando mais fácil amortizar os custos de acesso aos pesos do modelo e largura de banda de memória.

Mas aqui logo se encontrará com o limite de memória de vídeo. O cache KV de muitos Agentes longos ocupará continuamente a HBM; um GPU pode ainda não ter utilizado completamente os Tensor Cores, mas a memória de vídeo já estará cheia e não conseguirá acomodar mais sequências. Nesse ponto, aumentar ainda mais a capacidade de processamento não faz sentido; o que realmente limita a concorrência é a capacidade de cache e o gerenciamento de memória de vídeo.

Existe outro conflito entre prefill e decode. Suponha que dezenas de sequências estejam sendo decode de forma estável, quando um Agente retorna com um novo contexto de 100K tokens, exigindo um grande prefill. Se esse prefill ocupar um longo intervalo de execução, o TPOT das solicitações adjacentes deteriorará significativamente.

O prefill fragmentado divide a entrada longa em vários blocos pequenos, permitindo que o prefill e o decode sejam executados de forma intercalada; uma abordagem ainda mais avançada é separar o prefill e o decode em pools de GPU diferentes.

A razão é que os dois estágios têm diferentes gargalos de hardware: prefill é mais dependente de throughput computacional, enquanto decode depende mais da largura de banda HBM, do cache KV e da latência estável por token. Ao separá-los, é possível configurar recursos de acordo com as necessidades específicas de cada um.

Isso indica que o núcleo do Agent serving vai além de “escrever o kernel do modelo mais rápido”. Muitos aumentos de capacidade vêm do reagendamento de quando e onde as tarefas são executadas, quais estados valem a pena manter na memória da GPU e quem deve ser incluído no batch atual.

Portanto, a utilização da GPU já não é suficiente aqui. A equipe de capacidade precisa monitorar simultaneamente GPU-seconds per task, TTFT (latência do primeiro token, que determina se o usuário sente lentidão), TPOT (tempo de geração por token, que determina quão rápido o modelo “fala”), latência de fila, taxa de acerto do prefix cache, ocupação do KV cache e SLO goodput (throughput efetivo, que representa a capacidade de processamento realmente rentável).

Esses indicadores respondem coletivamente a uma pergunta: quantas tarefas eficazes uma GPU pode manter por hora dentro da latência aceitável pelo usuário.

A escalabilidade do Codex é evidente aqui. O prefixo estável reduz o prefill repetitivo, o decode permite batch contínuo, o KV cache pode ser paginado e expulso, e o agente pode liberar a GPU enquanto aguarda ferramentas. Sua carga de trabalho é muito fragmentada, mas esses fragmentos podem ser reorganizados pelo scheduler.

Isso também leva naturalmente a questão para a camada de recursos: se o mesmo conjunto de GPUs puder alternar o serviço a mais Agentes de longo prazo, o tempo de trabalho real que uma hora de GPU pode suportar pode ser superior a uma hora.

Suponha que um Codex Agent leve 60 minutos para concluir uma tarefa desde o recebimento até a conclusão, mas apenas uma parte desse tempo é realmente gasta em prefill e decode do modelo; o restante é usado para compilação, teste, leitura/escrita de arquivos ou espera por ferramentas. A proporção exata varia conforme a tarefa, mas a estrutura é importante: o tempo de relógio do Agent e o tempo de computação da GPU não são um para um.

Se houver muitos Agentes simultaneamente no sistema, eles não precisarão todos de GPU na mesma segunda. Alguém está fazendo prefill, alguém está decode, alguém está executando testes e alguém está aguardando o sistema de arquivos. Desde que o scheduler consiga intercalar essas fases, um número limitado de GPUs pode sustentar um número muito maior de fluxos de trabalho ativos do que o número de GPUs.

Essa relação pode ser aproximadamente entendida como: Agent-hours depende de GPU-hours, taxa de utilização do modelo de inferência e eficiência de agendamento. Quanto mais tempo for gasto na execução das ferramentas, maior o batch e maior a taxa de acerto no cache, mais tempo de trabalho wall-clock do agente uma hora de GPU poderá suportar.

Isso alterará diretamente o significado da adição de novas GPUs. Adicionar um conjunto de GPUs ao Codex não apenas acelera tarefas individuais, mas também pode permitir que o sistema mantenha simultaneamente mais Agentes. Um engenheiro pode iniciar vários trabalhos em paralelo — um ajustando o backend, outro completando testes, outro lidando com outro repositório — desde que essas tarefas não tenham dependências fortes entre si, o tempo de trabalho da máquina pode aumentar em paralelo.

A curva de capacidade do Sora é mais direta. O grande período de tempo wall-clock de um vídeo já está avançando a difusão no GPU, integrando mais estreitamente a tarefa única e a utilização do GPU. GPUs adicionais podem aumentar diretamente o throughput de vídeos, mas é difícil ampliar significativamente a diferença entre uma hora de GPU e o tempo de cálculo do vídeo.

Uma tarefa de software do Codex se move entre GPU, CPU, contêineres, sistema de arquivos e ambientes de ferramentas. A GPU é responsável pela inferência do modelo, enquanto outros sistemas executam as tarefas, e vários Agentes compartilham alternadamente a capacidade de inferência por meio do scheduler. Assim, a GPU deixa de ser apenas um dispositivo de geração e se torna um recurso escasso de “pensamento” em todo o sistema de Agentes.

É por isso que o Codex, embora consiga consumir grande quantidade de compute, consegue obter mais compute mais facilmente. A OpenAI precisa considerar não apenas o custo de inferência única, mas também se a capacidade adicional pode ser rapidamente convertida em maior volume de trabalho paralelo.

Quando um lote de GPU puder suportar mais Agentes de longo prazo, e esses Agentes puderem continuar recebendo novas tarefas de software, os recursos facilmente continuarão fluindo nessa direção.

O significado técnico da frase de Altman torna-se assim claro. A grande quantidade de poder computacional do Sora está bloqueada em um único caminho de geração, enquanto o poder computacional do Codex é dividido em múltiplos estágios intercaláveis. Ambos são igualmente caros, mas as curvas de retorno de recursos são diferentes.

Sora e Codex: instruções de transferência de recursos; produtos de IA agora têm um novo fator que afeta diretamente a velocidade de expansão: workload architecture.

Usando GPUs caras da mesma forma, uma categoria de tarefas bloqueia grande quantidade de poder de processamento em um único caminho de geração, enquanto outra categoria pode, por meio de cache, batching, execução de ferramentas e agendamento, intercalar a mesma capacidade de inferência entre mais fluxos de trabalho; suas curvas de recurso naturalmente se separam.

Então, problemas que parecem muito básicos no futuro se tornarão cada vez mais próximos de questões de produto: como armazenar o KV cache, como dividir o prefill, quão denso pode ser o decode batch, se os agents aguardando ferramentas devem expulsar o cache — essas escolhas determinarão quantas tarefas um conjunto de GPUs pode manter simultaneamente.

A diferença entre Sora e Codex não é apenas a diferença entre vídeo e código.

Eles estão competindo pela mesma hora de GPU, e realmente quantos trabalhos conseguem suportar.