Como executar o GPT-OSS-120B a mais de 500 tokens por segundo em GPUs NVIDIA

• GPT-OSS-120B, um LLM open source da OpenAI, foi otimizado em ambiente de GPU NVIDIA para processar mais de 500 tokens por segundo
• Foram feitos testes paralelos com vários frameworks de inferência como TensorRT-LLM, vLLM e SGLang, com suporte às arquiteturas Hopper e Blackwell
• Corrigiram-se bugs de compatibilidade, integraram-se novidades como o formato de resposta Harmony, roteamento ciente do KV cache e decodificação especulativa baseada no Eagle, entre outras otimizações
• Depois de comparar Tensor Parallelism e Expert Parallelism, escolheu-se Tensor Parallelism para menor latência e o backend TensorRT-LLM MoE no Blackwell
• Há planos de otimizações futuras com maior desempenho, incluindo decodificação especulativa (Speculative) com modelos “draft” menores

---

Visão geral

• Quando o GPT-OSS-120B, o novo LLM open source da OpenAI, foi lançado, a Baseten buscou implementar desempenho de ponta
  • A Baseten é a parceira oficial de lançamento da OpenAI
• Dados de usuários reais publicados pela OpenRouter comprovaram desempenho superior em ambiente baseado em GPUs NVIDIA em relação a terceiros
• Com o Flexible Inference Stack e a expertise da equipe de engenharia de modelos, patches de otimização foram aplicados rapidamente em ritmo de horas
• Em poucas horas de escrita do artigo, houve ainda aumento adicional de 100 tokens por segundo e manutenção de 100% de uptime

Esforços de otimização de desempenho

• Foram realizados testes e benchmarks em diversos frameworks de inferência, como TensorRT-LLM, vLLM e SGLang
• Em paralelo, garantiu-se compatibilidade com as arquiteturas de GPU Hopper e Blackwell
• Foi feita integração com componentes centrais como o Flexible Inference Stack da Baseten e NVIDIA Dynamo
• Aplicaram-se técnicas de otimização validadas continuamente, como roteamento ciente de KV cache e Speculative decoding (baseado em Eagle)

Abaixo estão as etapas principais para alcançar desempenho SOTA e suporte à janela de contexto completa

Etapa 1: Execução da inferência inicial

• O ponto de partida foi rodar a inferência inicial (baseline inference) o mais rápido possível, independentemente da abordagem
• Com foco em GPU, vários engenheiros conduziram experimentos paralelos com vLLM, SGLang e TensorRT-LLM
• O TensorRT-LLM com melhor desempenho foi colocado em funcionamento rapidamente
• Foi garantido suporte ao TensorRT-LLM em Hopper (onde há mais GPUs H100) e Blackwell (acelera melhor com GPUs B200)
• Graças à flexibilidade do Baseten Inference Runtime, foi simples substituir ferramentas dentro da stack e atender a novos modelos de arquitetura

Etapa 2: Correção de bugs de compatibilidade

• Novas arquiteturas de modelo trazem com frequência bugs recorrentes durante integração de frameworks
• O GPT OSS trouxe novos recursos, como o novo formato de resposta Harmony, gerando bugs na integração com frameworks existentes
• Para preservar velocidade e precisão, foram feitas revisões e testes repetidos, e as melhorias eficazes foram contribuídas de volta ao open source
• A colaboração da comunidade open source global faz com que diferentes caminhos de otimização e correções de bugs aconteçam rapidamente

Etapa 3: Otimização da configuração do modelo

• A OpenAI informa que o GPT OSS 120B funciona em um único H100, mas, na prática, a paralelização em 4 a 8 GPUs é mais vantajosa para desempenho
• Tensor Parallelism favorece a latência, enquanto Expert Parallelism favorece o throughput de sistema
  • Como objetivo da Baseten é otimizar latência, escolheu-se Tensor Parallelism
• No Blackwell, foi aplicado o backend TensorRT-LLM MoE para melhorar o desempenho do kernel CUDA em relação ao backend Triton anterior
• Foram divulgadas configurações otimizadas para os ambientes Hopper e Blackwell, e a Model API adotou a configuração baseada em Blackwell

Otimizações de desempenho adicionais

• Mesmo apenas com a otimização inicial, já foi alcançado throughput e latência em nível SOTA, mas ainda há espaço significativo para melhoria
• A atualização principal prevista é a adoção de Speculative Decoding
  • Nesse formato, um modelo de “draft” menor e mais rápido gera os tokens previstos, enquanto o modelo principal valida
  • A Baseten recomenda o Eagle 3, mas mantém mais de 10 algoritmos no stack de inferência para operar de forma dinâmica conforme cada cenário
• A decodificação especulativa conduz inferência de múltiplos tokens de uma só vez, trazendo ganho de velocidade de forma eficiente

[jjw951215]

Eu também queria que alguém me desse um H100 pequeno e fofo...

[GN⁺]

Comentários do Hacker News

• GPUs H100 amplamente disponíveis

  Então, procurando na gaveta de peças de casa e insistindo bastante, por que não aparece uma GPU H100 de US$ 25.000?

  • Eu confirmei diretamente na página de produtos da NVIDIA que o H100 realmente é classificado como GPU. Acho que precisamos de nomes que deixem mais claro o tipo de hardware de nível de consumidor, usado principalmente para games mas com capacidade de inferência de LLM apenas muito limitada, e o hardware profissional para negócios em que o objetivo principal é treinamento de IA e inferência de LLM.
  • Testei o modelo de 20B no Ollama com 8 GPUs TitanX (de 2015). O Ollama distribuiu os 15 GB de VRAM totais de forma equilibrada entre as 8 placas, e a velocidade de tokens até ficou maior que a de leitura.
  • Essas GPUs podem ser alugadas de forma realmente fácil. Se você não vai rodar GPU 24/7 por muito tempo, alugar hospedagem costuma ser muito mais econômico do que comprar. Para uso pessoal, nem sempre faz sentido usar placas de datacenter de última geração; nesses casos, um Mac Studio ou um Strix Halo já é suficiente, embora seja um pouco mais lento.
  • Esse comentário deu uma alegria enorme ao meu dia. É uma discussão claramente do ponto de vista de datacenter, e meu hardware mais rápido na gaveta provavelmente é um velho iPhone 8.
  • Dizer que “não tenho uma GPU de US$ 25.000 em casa” não significa, de fato, que não seja possível comprar uma. Quer dizer que há estoque e dá para conseguir, não necessariamente que você tenha dinheiro suficiente para comprar.

• Usei GPT-OSS-120B em um MacBook Pro (M4, 128GB RAM) durante um voo transatlântico. É rápido só quando a janela de contexto é pequena e o total de tokens também é baixo. Depois de passar de 10 mil tokens, quase tudo fica demorado e vai para a fila. MCPs, pesquisa web e patch de URL já se tornaram muito importantes na experiência de uso de LLM. Sem essas funcionalidades, a utilidade do LLM cai bastante. As ferramentas de codificação CLI/TUI pré-configuradas para ambiente offline (como o opencode) não funcionaram de forma confiável junto com o modelo. Além dos pontos sobre modelos OSS já mencionados em comentários anteriores, também há este:

  • A Wikipédia antiga também já podia ser guardada e usada localmente. Então, em breve muita gente vai expor muitos dados via MCP para que as IAs façam busca local como fazem com “web search”. 99% das buscas web acontecem apenas nos mesmos 100~1000 sites. Resumindo, alguns GB armazenados já cobrem isso, então sobra a questão de direitos autorais.
  • Fiquei curioso para saber qual vocês usam entre Ollama, LM Studio e llama.cpp tweet do ggerganov
  • Fiquei curioso de como foi feita a configuração do iogpu.wired_limit_mb. No padrão, só cerca de 70% da RAM, ou seja, uns 90 GB, pode ser usado pelo núcleo da GPU. Para usar mais, precisa ajustar essa configuração.
  • Usei processador M2 Max. Em conversa curta, vi mais de 60 tokens/s, mas quando ela ficou longa caiu para 30. Fiquei curioso sobre o que causa essa queda de velocidade. Não parecia ser problema térmico.
  • Penso que é a diferença entre prefill com viés computacional (quando a largura de banda/operações do CPU está alta) e decodificação. Mesmo com 10k de contexto, o primeiro token saiu em menos de 0,5 s.

• Vários engenheiros testaram vLLM, SGLang e TensorRT-LLM em paralelo. Fala-se que o TensorRT-LLM é o mais rápido, mas geralmente é o mais difícil de configurar, também não reflete bem arquiteturas novas e ainda é um incômodo porque precisa compilar o modelo diretamente no stack hardware-driver-biblioteca igual ao de produção. Multimodal ficou praticamente impossível por um tempo, e até modelos multimodais emblemáticos da Llama não funcionaram direito. Fico em dúvida se isso vale a pena, porque, por exemplo, com GPT-OSS-120B no H100 em vLLM tudo roda sem problema e rende consistentemente 130~140 t/s. Pelo título, parecia que sairia 500 t/s por GPU, mas na prática era tensor parallel. Fizeram também uma embalagem separada de TRT-LLM para gpt-oss, o que é meio cômico. O próprio TRT-LLM já é uma ferramenta meio confusa.

  • Quando experimento TRT-LLM, surgem muitos desafios do ponto de vista de DX. Para multimodal, ainda se usa bastante vLLM. Mas para tráfego em escala e baixa latência como o que servimos, o benchmark mostrou o TRT-LLM melhor sempre, então investimos bastante nesse tooling.

• O GPT-OSS 20B é realmente fácil de instalar. Graças ao Llama, deu para rodar no meu Mac em 5 minutos.

  • Se houver CPU suficiente, até o 120B roda sem dificuldade. Em casa, para meu servidor de inferência LLM em CPU, bastou baixar o arquivo GGUF, dar um git pull e recompilar só o llama-server; assim já rodava em 40 t/s sem ajuste, e em 50 t/s com pouquíssimo tuning. Infelizmente, já existem modelos melhores que o 120B, então não há tanta necessidade de rodá-lo. O ggerganov e o time do llama.cpp realmente foram incríveis ao democratizar o uso de LLM também no ambiente de computação pessoal.
  • As pessoas dizem que configurar LLM é difícil, mas não é justamente deixar o próprio LLM fazer a configuração? Se nem para isso ele não resolve, qual o sentido do LLM?
  • Rodei ontem, e em todas as sessões veio informação factualmente incorreta. Velocidade e conveniência são boas, mas se a precisão for sacrificada não faz sentido.
  • Se houver memória suficiente, o 120B também roda muito fácil.

• Lendo isso, aprendi que para o modelo funcionar bem são necessários muita etapa de pré-processamento e muito tuning. Eu achava que ia funcionar bem no padrão.

  • Na minha visão, as big techs deveriam colaborar ativamente com desenvolvedores dos motores de inferência mais populares antes de lançar seus LLM para que seus próprios LLMs fossem suportados. Ainda é tudo experimental, então talvez seja isso, mas os devs estão realmente fazendo um esforço grande para permitir LLM em hardware mais barato.

• No AI Action Plan dos EUA, “incentivar IA open source e open-weight” vem logo antes de “fazer a frontier AI proteger a liberdade de expressão e os valores americanos”. Não é muito racional, mas a leitura de modelo open-source da OpenAI nesse momento me dá um arrepio. Ainda assim, é bom que os desenvolvedores de modelo OSS falem de hardware; para a maioria dos desenvolvedores, hardware é uma barreira de entrada, então é ótimo ouvirmos isso.

  • O item “fazer a frontier AI proteger a liberdade e os valores americanos” também foi citado. Eu ainda estou no meio de organizar minhas ideias, então peço um pouco de paciência. Modelos de IA vão carregar um viés de mundo, e eu prefiro um viés ocidental. Há muitos casos em que isso levou a uma sociedade melhor. Pelo menos que o modelo documente seu viés e siga isso, sem tentar conduzir social engineering para mudar o pensamento do usuário escondido.

• Alguém conhece um site que diga claramente, por OS e por GPU, quais modelos de LLM rodam melhor? A fórmula empírica mais confiável para estimar VRAM que encontrei era parâmetro × (Precisão/8) × 1,2 (referência)

  • Eu tentei montar uma calculadora parecida, mas na prática há variáveis demais (como tráfego simultâneo, etc). A fórmula funciona em média, mas com tráfego concorrente é seguro multiplicar por 2.
  • No huggingface, inserindo especificação de hardware/software, existe um recurso que mostra na página de detalhes de cada modelo se ele pode ser usado ou não configuração do huggingface
  • Minha internet é boa, então baixar os arquivos de peso do modelo e testar em vários runners (llama.cpp, LM Studio, vLLM, SGLang etc.) foi o caminho mais rápido. Existem variáveis demais em runner/implementação/hardware, então nenhuma calculadora bateu certinho com a experiência real. A abordagem é só testar na prática.
  • Agradeço os comentários de vocês. Se a estimativa for difícil, pensei que poderia ser criado um site DB da comunidade para experimentação e compartilhamento de runner, hardware, modelo, parâmetro, quantização, se funciona ou não e métricas como tokens/s. Filtrar por combinação de hardware/runner e já usar seria bem prático.

• Quero dizer que ficou surpreendentemente difícil encontrar métricas exatas, como o tamanho real do arranjo do modelo GPT-OSS-120B. Em uma linguagem tipada estaticamente, dá para enxergar o tamanho do array de relance, e quero entender melhor como os dados (além dos pesos) fluem e quão larga é a saída em stream. Tenho curiosidade sobre qual é a largura de banda máxima de “token output” em gigabit Ethernet, e por isso procurei no repositório do Github gpt-oss, mas não apareceu direito.

  • Quero saber quais aplicações fazem streaming de logits para todos os tokens sequenciais, fazendo também o token sampling em conformidade com o protocolo. E é bom lembrar que normalmente, antes da próxima inferência, precisa fazer a manipulação dos logits e retorno de tokens para corrigir coisas como gramática.
  • No configuração do modelo do huggingface há 2880 valores (multiplicação do dtype).

• O GPT-OSS roda mais rápido em chips Blackwell com suporte a fp4. Estamos fazendo um engine de treinamento/inferência em Rust e adicionando suporte de fp8 e fp4 no cudarc e no candle. Também estou fazendo isso para suportar esses modelos no engine da Mixlayer.

  • Sou usuário de RTX Pro 6000 e fico curioso para saber se a inferência do gpt-oss-120b já está possível agora. As PRs parecem já estar mergeadas, mas quero saber se na prática já dá para rodar.