SGLang adiciona suporte ao gpt-oss-120b em GPUs Hopper e Blackwell

Quando a OpenAI lança um modelo aberto, a primeira pergunta dos engenheiros não é sobre a qualidade das respostas. É outra: em qual hardware ele vai rodar e quanto custará um milhão de tokens. Enquanto o modelo não tem suporte adequado em um motor de inferência, ele continua sendo uma frase bonita em um comunicado à imprensa. Por isso, a notícia da LMSYS Org pode parecer modesta, mas é importante para quem trabalha com essas ferramentas: o SGLang agora oferece suporte ao gpt-oss-120b em GPUs da Nvidia das gerações Hopper e Blackwell.

O que foi anunciado

A equipe LMSYS, responsável pelo SGLang, anunciou suporte ao gpt-oss-120b em duas arquiteturas de uma vez: Hopper (H100, H200) e Blackwell (a família B200). Eigen AI Labs, Nvidia, os próprios desenvolvedores do SGLang e a comunidade de código aberto participaram do trabalho. A publicação também diz que o suporte chegou poucos dias após o lançamento do modelo, mas o número exato está cortado no texto disponível, por isso não o informamos.

O contexto é o seguinte. O gpt-oss-120b usa uma arquitetura Mixture of Experts: apenas uma pequena parte dos parâmetros é ativada para cada token. Segundo a OpenAI, são cerca de 117 bilhões de parâmetros no total, com aproximadamente 5 bilhões ativos. Os pesos foram disponibilizados sob a licença Apache 2.0 e quantizados no formato MXFP4, permitindo que o modelo caiba em uma única GPU de 80 GB. Modelos assim são especialmente sensíveis à qualidade do motor: tanto a velocidade quanto o custo dependem de como ele distribui os especialistas e utiliza kernels de baixa precisão.

Por que isso importa na prática

Imagine uma situação típica. Você está criando um assistente interno para desenvolvedores ou um agente que consulta documentação e chama ferramentas. Prefere não enviar código e dados internos para uma API externa. Tem GPUs próprias ou as aluga de um provedor de nuvem. O próximo passo é escolher como servir o modelo: vLLM, TensorRT-LLM, SGLang ou alguma outra opção.

O suporte no SGLang acrescenta outra alternativa viável a essa lista. O SGLang é conhecido por reutilizar bem os prefixos das requisições, o que ajuda bastante em fluxos com agentes nos quais cada requisição repete um longo prompt de sistema e o histórico da conversa. Para o gpt-oss-120b, apresentado como um modelo voltado a raciocínio e uso de ferramentas, esse perfil de carga é bastante comum.

Blackwell merece uma menção à parte. O suporte de software a novos hardwares costuma demorar, e quem compra as novas B200 passa meses esperando kernels otimizados. Quando o suporte é anunciado desde o início tanto para Hopper quanto para Blackwell, a equipe não precisa manter duas pilhas de software diferentes para as placas antigas e as novas.

O que a publicação não traz

É preciso deixar claras as limitações. O anúncio não apresenta números: nem vazão em tokens por segundo, nem latência, nem comparações com outros motores. Também não há dados sobre o comportamento do modelo com contextos longos e alta carga de requisições simultâneas. Trata-se de um anúncio de suporte, não de um benchmark, e ele não basta, por si só, para decidir uma migração.

Além disso, "compatível" não significa "ideal". As primeiras versões de uma integração costumam funcionar corretamente, mas nem sempre extraem o máximo do hardware. Os ganhos de velocidade chegam nas versões seguintes, por isso vale acompanhar as atualizações do SGLang em vez de ficar para sempre na primeira versão.

O que fazer

Se você já hospeda seus próprios LLMs, faça um pequeno experimento. Use um fluxo real de requisições ou uma gravação desse tráfego, coloque o gpt-oss-120b para rodar no SGLang e no motor que usa atualmente e compare três aspectos: tempo até o primeiro token, tokens por segundo sob carga e custo da hora de GPU por mil requisições. Teste separadamente as chamadas de ferramentas e a saída estruturada, pois é nesses pontos que as diferenças entre motores aparecem com mais frequência.

Mesmo sem hardware próprio, a notícia continua sendo útil: quanto mais motores conseguem servir um modelo aberto, maior a concorrência entre os provedores de inferência e menor o preço por token. Optar por pesos abertos deixa de ser uma aposta arriscada quando o modelo conta com várias formas maduras de execução.