Como o GPT‑5.6 alia inteligência e eficiência de fronteira

Concebemos a família de modelos GPT‑5.6 para equilibrar capacidade e custo em todo o leque de tarefas para as quais as pessoas utilizam os nossos modelos. O nosso modelo principal, GPT‑5.6 Sol, com raciocínio Max, supera o Claude Fable 5 no Artificial Analysis Coding Agent Index por menos de metade do custo. O Terra iguala o desempenho do GPT‑5.5 em testes de referência de inteligência por metade do preço, e o Luna é o nosso modelo mais rápido e económico, com um preço 80% inferior ao do Sol. Para alcançar estes níveis de eficiência, as nossas equipas técnicas e de investigação realizaram otimizações significativas em todas as principais camadas da nossa stack. Estas melhorias abrangem os nossos modelos, a inferência (a forma como executamos modelos para gerar resultados) e o nosso harness de agentes, utilizado tanto pelo Codex como pelo ChatGPT Work.

À medida que, nos últimos quatro anos, expandimos os nossos modelos para mil milhões de utilizadores ativos e mais de dois milhões de empresas, a eficiência tem sido essencial para levar os benefícios da inteligência a todos. A nossa missão é garantir que a inteligência artificial geral beneficia toda a humanidade. Ao longo destes anos, temos procurado obter continuamente maiores otimizações em toda a nossa stack, para disponibilizar os modelos com melhor desempenho em todos os pontos da curva entre custo e inteligência. Com o GPT‑5.6, alcançámos a nossa melhor eficiência de inteligência por token até à data, graças a um treino orientado para realizar mais trabalho por token. Durante o treino, otimizamos tanto o êxito na tarefa como a eficiência, orientando o modelo para seguir um percurso mais direto ao executar uma tarefa.

Este artigo vai além dos nossos modelos para explicar como concebemos a eficiência através de avanços noutras duas partes fundamentais da stack: 1) a inferência, otimizando processos como o balanceamento de carga, a descodificação especulativa, a cache e os kernels para obter mais resultados com o mesmo hardware; e 2) o nosso harness de agentes, incluindo uma melhor gestão do excesso de contexto, da utilização de ferramentas e do trabalho repetido. Explicaremos também o papel do GPT‑5.6 Sol na concretização autónoma de vários destes ganhos. Embora cada melhoria isolada possa parecer limitada, estes ganhos acumulam-se e permitem-nos chegar à fronteira tanto da inteligência como da eficiência.

Num mundo com recursos computacionais limitados, em que a procura de modelos cresce mais depressa do que a capacidade, a eficiência é essencial à conceção de todos os sistemas. Isto é especialmente verdade na nossa stack de inferência, que executa modelos treinados para gerar respostas. O nosso principal objetivo é processar mais tokens com o mesmo hardware, preservando a inteligência, a latência, a disponibilidade e a fiabilidade que os utilizadores esperam.

Para o conseguir, é necessário otimizar todo o sistema. Um modelo pode ser muito eficiente isoladamente, mas continuar a ser dispendioso de disponibilizar se os pedidos forem mal distribuídos, o hardware ficar inativo ou a movimentação de dados atrasar a computação. As melhorias em cada camada acumulam-se, com ganhos provenientes da otimização do encaminhamento (para onde são enviados os pedidos), do agendamento (quando são enviados), dos kernels (software executado nas GPUs), da cache (trabalho guardado e reutilizado) e da implementação do modelo (a ordem do código executado nas GPUs). O GPT‑5.6 Sol no Codex teve um papel decisivo em todas estas otimizações.

O primeiro exemplo importante é o balanceamento de carga. À escala global, encaminhamos os pedidos com base em fatores como a localização geográfica, a capacidade disponível e o tipo de acelerador (o tipo de GPU ou chip especializado que executa o modelo). Dentro de um cluster, distribuímos o trabalho pelas instâncias do modelo com base na carga, na extensão do contexto, na disponibilidade da cache e noutras propriedades dos pedidos. Em cada instância, o trabalho tem depois de ser repartido de forma eficiente pelos aceleradores, pelas sub-redes do modelo e pelos núcleos de processamento. O GPT‑5.6 Sol no Codex ajuda-nos a analisar o tráfego de produção, identificar fontes de desequilíbrio anteriormente ignoradas, testar novas estratégias de encaminhamento e ajustar continuamente estas heurísticas. Só estas melhorias no balanceamento de carga reduziram drasticamente o custo de disponibilização dos nossos modelos.

Também utilizámos o GPT‑5.6 Sol para otimizar a passagem direta do modelo: a computação que transforma as entradas em previsões do token seguinte. Mesmo quando as operações individuais são rápidas, a movimentação excessiva de memória, a sincronização e disposições de dados ineficientes podem deixar as GPUs inativas. Para o evitar, o GPT‑5.6 Sol identificou trabalho que podia ser pré-calculado, evitado ou executado em paralelo. Com o Codex, o GPT‑5.6 Sol reescreveu e otimizou autonomamente os nossos kernels de produção, o código central que executa as operações matemáticas que constituem o modelo. Isto funcionou, em parte, porque treinámos o GPT‑5.6 para escrever e melhorar eficazmente kernels em Triton⁠(abre numa nova janela) e Gluon⁠(abre numa nova janela), duas linguagens de programação de GPUs de código aberto mantidas pela OpenAI. Estes esforços, combinados com avanços mais abrangentes nos kernels obtidos pelo GPT‑5.6 Sol, reduziram em 20% os custos de disponibilização de extremo a extremo. Também investimos fortemente em ferramentas de verificação, como a ferramenta de código aberto FpSan⁠(abre numa nova janela) (Floating-Point Sanitizer), para ajudar a validar a correção dos kernels escritos pelo GPT‑5.6 Sol.

A descodificação especulativa é outra forma de melhorar a velocidade e a eficiência. A técnica consiste em executar um modelo de rascunho mais pequeno (ou «especulador») em paralelo com o modelo principal, propondo vários tokens para o modelo principal verificar em simultâneo. Quando essas propostas são aceites, o sistema pode produzir vários tokens de saída numa única passagem do modelo principal, reduzindo a computação sequencial dispendiosa. O GPT‑5.6 Sol melhorou o seu próprio modelo de rascunho ao conceber e executar centenas de experiências na respetiva arquitetura, testando alterações de dimensão, estrutura e funcionalidades. Além disso, o GPT‑5.6 Sol iniciou e monitorizou o processo de treino do especulador, intervindo autonomamente quando surgiam problemas, incluindo falhas de hardware e instabilidade no treino. As melhorias resultantes aumentaram a eficiência da geração de tokens em mais de 15%.

Ao processar tokens de entrada não presentes na cache, o modelo cria a cache de chave-valor (KV) numa única passagem intensiva em computação; ao gerar a saída, lê e amplia repetidamente essa cache. A configuração ideal de disponibilização, incluindo o processamento em lotes, a fragmentação e a gestão de KV, depende muito da carga de trabalho: extensão do prompt e da saída, tamanho do lote, taxa de acerto da cache, características das consultas, entre outros fatores. Contudo, o espaço de configurações era demasiado vasto para um ajuste sistemático, obrigando os engenheiros a recorrer a heurísticas gerais. Com o GPT‑5.6 Sol no Codex, conseguimos analisar cargas de trabalho de produção, gerar e avaliar configurações candidatas e hiperotimizar a configuração do motor e do modelo para cada cenário. Isto torna viável um novo nível de otimização específico para cada carga de trabalho, permitindo obter mais inferência útil com o mesmo hardware.

A otimização da inferência é um ciclo contínuo de feedback. Medimos o comportamento em produção, identificamos as maiores lacunas, implementamos alterações e verificamos se melhoram todo o sistema, e não apenas um teste de referência isolado. O GPT‑5.6 Sol e o Codex aceleram todas as etapas desse ciclo. Assim, a nossa equipa pode explorar mais ideias, responder mais depressa a mudanças nas cargas de trabalho e criar uma stack de inferência com menor latência, maior capacidade e custos mais baixos para os utilizadores.

O ChatGPT Work e o Codex concluem tarefas complexas através de uma série de pedidos ao modelo e chamadas de ferramentas. Numa única interação — desde o pedido do utilizador até à resposta final —, o Codex pode inspecionar código-fonte, pesquisar o histórico de implementações, ler relatórios de incidentes, editar um ficheiro e executar testes. Cada passo pode exigir um pedido.

Preparar o contexto, transmitir dados, executar a inferência, chamar ferramentas e iniciar processos exigem tempo e recursos computacionais. Se uma tarefa exigir 30 pedidos ao modelo, um segundo adicional por pedido acaba por se acumular. Melhorar o desempenho global significa reduzir o trabalho repetido em todo o sistema, e não apenas tornar o modelo mais rápido.

Estes fatores multiplicadores orientaram a conceção do nosso harness de agentes, uma camada de orquestração em Rust que liga os nossos modelos e ferramentas ao ambiente do utilizador. Em seguida, explicamos como evitar o excesso de contexto, carregar ferramentas e reutilizar trabalho torna cada pedido mais eficiente.

À medida que os agentes obtêm acesso a mais ferramentas, competências, plug-ins e histórico de conversas, as janelas de contexto podem aumentar facilmente. Isto aumenta os custos, distrai o modelo e desencadeia raciocínio desnecessário. O harness pode reduzir esta sobrecarga através da descoberta diferida, que só permite apresentar integrações, ferramentas MCP personalizadas, competências e plug-ins quando são necessários. O harness também impede que ferramentas individuais e integrações MCP consumam inesperadamente a janela de contexto. Por predefinição, a saída das ferramentas está limitada a 10 000 tokens, salvo se o modelo pedir um limite diferente.

Como referido anteriormente, um ciclo de agente pode enviar várias vezes para as GPUs, numa única interação, as mesmas instruções, o histórico da conversa, as definições das ferramentas e os resultados anteriores. Processar estas entradas repetidas é dispendioso, pelo que a cache de prompts reutiliza a computação associada ao prefixo de um prompt processado anteriormente. Para preservar esse prefixo, o harness trata todo o histórico visível para o modelo como sendo apenas de anexação: as novas mensagens, os resultados das ferramentas e as atualizações do ambiente são adicionados no fim, em vez de inseridos no contexto anterior. As ferramentas também são apresentadas numa ordem determinística, enquanto as definições de execução, como as políticas de aprovação, são aplicadas durante a execução em vez de incorporadas nas definições das ferramentas. Esta opção de conceção contribui para as elevadas taxas globais de acerto da cache de prompts do Codex e do ChatGPT Work.

Os ganhos de eficiência que alcançámos com o GPT‑5.6 resultam de anos de melhorias cumulativas em toda a stack, abrangendo a investigação, a inferência e o nosso harness de agentes. O papel do GPT‑5.6 na concretização de muitas destas melhorias deixa-nos otimistas quanto à aceleração do ritmo das otimizações. Continuaremos a realizar otimizações mais profundas em áreas como os kernels, a par de melhorias fundamentais na nossa stack. Esperamos poder disponibilizar aos nossos utilizadores e clientes estas melhorias contínuas e invisíveis sob a forma de inteligência mais acessível e económica.

Um agradecimento especial a Matthew Ferrari, Philippe Tillet, Ahmed Ibrahim, Joe Gershenson e Steve Coffey, membros da equipa técnica, pelos seus contributos para este artigo.