O gpt-oss-20b da OpenAI roda em 16GB de memória, mas a documentação deixa buracos

Um modelo aberto pensado para caber fora do data center

A OpenAI publicou o gpt-oss-20b em agosto de 2025 como o irmão menor de uma dupla open-weight: ao lado do gpt-oss-120b, ele é vendido como a opção para "latência baixa e uso local ou especializado", segundo a documentação oficial no GitHub. São 21 bilhões de parâmetros no total, mas só 3,6 bilhões ativos por inferência, porque a arquitetura é mixture-of-experts: o modelo ativa só uma fração dos seus pesos a cada passo, o que reduz custo computacional sem jogar fora a capacidade total do modelo.

A licença é Apache 2.0, sem restrições de copyleft, o que libera uso comercial e fine-tuning sem pedir permissão. O modelo vem com suporte nativo a function calling, execução de código Python↳Python56 conteúdosVSCode + Python + Alexa: Desenvolva e teste skills para alexa localmente com pythonDev (Back & Front) · out 2025Dominando decoradores em Python: um guia completo com exemplosDev (Back & Front) · jan 2025Desenvolvimento de software: diferenças entre Python, JavaScript e JavaGestão Dev & TI · nov 2024Ver tudo em Dev (Back & Front) → e uma ferramenta de busca na web, além de reasoning effort configurável (low, medium, high) para ajustar velocidade contra qualidade de resposta. Isso é relevante para quem pensa em agentes: dá pra trocar profundidade de raciocínio por latência sem trocar de modelo.

MXFP4: a quantização que faz o número de 16GB existir

O motivo do gpt-oss-20b caber em hardware doméstico tem nome: MXFP4. A OpenAI aplicou essa quantização nos pesos da camada MoE durante o pós-treinamento, e isso é o que permite ao modelo "rodar dentro de 16GB de memória", nas palavras da própria documentação. O detalhe importante, que passa batido numa leitura rápida: todas as avaliações de qualidade divulgadas pela OpenAI já foram feitas com essa mesma quantização aplicada, não com o modelo em precisão cheia depois reduzido.

Isso muda a forma de ler o anúncio. Não é "o modelo original roda bem e também dá pra comprimir"; é "o modelo testado e avaliado já é o comprimido". Na prática, isso reduz a superfície de discussão sobre perda de qualidade por quantização, porque não existe uma versão BF16 do gpt-oss-20b sendo comparada lado a lado nos materiais oficiais. Quem quiser medir essa perda por conta própria precisa rodar a implementação de referência em PyTorch, que o próprio repositório descreve como não otimizada e educacional.

Três caminhos, três hardwares diferentes

A documentação lista múltiplos jeitos de rodar o gpt-oss-20b, mas eles não são intercambiáveis em termos de exigência de hardware. Vale separar o que serve pra notebook do que serve pra servidor:

O caminho Ollama é o único que a própria OpenAI recomenda explicitamente para quem está "tentando rodar o gpt-oss em hardware de consumidor", incluindo uma ressalva direta: as implementações de referência em PyTorch e Triton não foram testadas no Windows, e quem estiver nesse sistema deve usar soluções como o Ollama em vez delas.

O que a documentação não diz: abaixo de 16GB

O número de 16GB aparece como o piso declarado para o gpt-oss-20b com MXFP4, mas o material da OpenAI não detalha o que acontece em máquinas com menos memória que isso. Não há tabela de degradação, não há modo de quantização ainda mais agressiva publicado para esse modelo, nem orientação oficial de offloading para disco ou swap. Quem tem 8GB de RAM e tenta rodar via Ollama mesmo assim está testando um cenário que a documentação simplesmente não cobre.

Em resumo: o roteiro oficial garante funcionamento numa janela específica (16GB+ de memória unificada ou VRAM, usando o caminho Ollama ou LM Studio) e silencia sobre qualquer coisa fora dela. Isso não quer dizer que seja impossível rodar com menos; quer dizer que, se rodar, o comportamento de velocidade e de eventuais cortes de contexto não vem documentado em lugar nenhum da fonte oficial. É terreno de tentativa e erro, não de promessa cumprida.

Harmony: o formato que trava quem tenta pular etapa

Um detalhe que a seção de destaques da documentação faz questão de repetir, em negrito, é que os dois modelos "foram treinados usando nosso formato de resposta harmony e devem ser usados somente com esse formato; caso contrário, não vão funcionar corretamente". Isso não é um detalhe de estilo: é um contrato de formatação que, se ignorado, produz saídas quebradas mesmo com o modelo carregado e rodando sem erro.

No caminho vLLM, isso aparece de forma explícita no código de exemplo da própria documentação: antes de gerar qualquer resposta, é preciso carregar o HarmonyEncodingName.HARMONY_GPT_OSS, montar a conversa com Conversation.from_messages, renderizar o prefill com encoding.render_conversation_for_completion e só depois parsear a saída de volta com encoding.parse_messages_from_completion_tokens. Pular esse encoding e mandar prompt cru pro modelo via vLLM é a receita mais comum pra quem abre uma issue perguntando por que o gpt-oss "não funciona direito".

Quem usa Ollama ou LM Studio não lida diretamente com esse encoding manual: a própria OpenAI recomenda essas ferramentas como caminho padrão para hardware de consumidor, dispensando o usuário de montar o pipeline harmony à mão como no exemplo vLLM acima. A documentação não detalha como cada ferramenta trata o formato internamente, mas a recomendação explícita da OpenAI para esse público sugere que essa complexidade fica, na prática, abstraída de quem usa a interface de alto nível.

Codex como cliente local: um caso de uso concreto

A documentação traz um exemplo prático que vale pra quem já usa Codex no dia a dia: dá pra apontar o Codex para uma instância local do gpt-oss-20b rodando via Ollama. Basta configurar o ~/.codex/config.toml com um provider apontando pra http://localhost:11434/v1 (a porta padrão do Ollama) e um profile oss usando model = "gpt-oss:20b". Depois disso, o comando codex -p oss passa a rodar contra o modelo local em vez de bater num endpoint de nuvem.

Isso funciona porque o servidor do Ollama expõe uma API compatível com chat completions, e qualquer cliente que fale esse protocolo consegue se conectar, não só o Codex. É um ponto de partida razoável pra quem quer medir, na própria máquina, se o gpt-oss-20b dá conta de tarefas de código sem depender de uma chave de API paga.

Por onde eu começaria

Pra quem quer só experimentar sem compromisso, o caminho de menor atrito continua sendo ollama pull gpt-oss:20b seguido de ollama run gpt-oss:20b, com pelo menos 16GB de memória disponível (unificada em Apple Silicon, ou RAM mais VRAM em PCs com GPU). Se a ideia é expor o modelo como serviço, com batching real e controle fino de parâmetros, o vLLM é o caminho certo, mas exige GPU dedicada e lidar manualmente com o formato harmony caso não se use a interface de alto nível.

O que fica em aberto, porque a fonte não resolve, é exatamente a faixa abaixo de 16GB e qualquer comparação de qualidade entre o modelo quantizado em MXFP4 e uma hipotética versão em precisão cheia. Até a OpenAI publicar esse dado, a resposta honesta pra quem pergunta "roda no meu notebook de 8GB" é: a documentação não promete isso, e ninguém oficialmente testou.

Fonte: Documentação oficial do gpt-oss (OpenAI, GitHub)