RunPod publica guia para sair da API da OpenAI e migrar para uma LLM própria com pesos abertos

A RunPod publicou um guia para migrar da API da OpenAI para um modelo de linguagem de pesos abertos hospedado pela própria equipe. O público-alvo são times cansados dos limites de requisições e de contas que crescem junto com o tráfego. O anúncio não traz números concretos de economia. O material é de um fornecedor: a RunPod vende nuvem de GPU, e a lógica do guia reflete isso. Mesmo assim, o caminho da migração se tornou quase padrão nos últimos dois anos, e vale analisá-lo com cabeça fria.

Por que os times abandonam a API

Uma API gerenciada tem três problemas crônicos. O primeiro são os limites: os ttetos de requisições e de tokens por minuto são atingidos pelo crescimento do produto mais rápido do que se gostaria. O segundo é a imprevisibilidade da conta: paga-se por cada token, e uma funcionalidade de sucesso pode virar de repente a maior linha de despesa. O terceiro é a dependência de decisões alheias: o fornecedor pode mudar o comportamento do modelo, aumentar o preço ou descontinuar uma versão. Para parte das empresas, soma-se ainda a questão de para onde vão os dados.

O self-hosting troca o pagamento por token pelo aluguel de GPU por tempo de uso. A conta fecha quando a placa trabalha de forma estável e com carga densa. Se as requisições são raras e irregulares, o hardware ocioso consome facilmente toda a vantagem, e a API continua mais barata.

Como é a migração

O esquema que a RunPod descreve, e que a maioria dos times segue, é curto. Primeiro, escolhe-se um modelo aberto para a tarefa: Llama, Qwen, Mistral ou, por exemplo, o gpt-oss, da própria OpenAI. Depois, sobe-se um servidor de inferência como o vLLM, capaz de expor um endpoint compatível com a OpenAI. Com isso, o código do cliente quase não é tocado: troca-se o endereço, a chave e o nome do modelo.

Na RunPod, há duas formas de implantar: em um pod dedicado com GPU ou em modo serverless, em que os workers escalam conforme a carga e não são cobrados enquanto estão ociosos.

Referências de hardware e compatibilidade:

• No código, mudam três parâmetros: base_url, chave de API e nome do modelo.
• O gpt-oss-120b, segundo a OpenAI, cabe em uma única GPU de 80 GB de memória e tem licença Apache 2.0.
• O gpt-oss-20b foi dimensionado para cerca de 16 GB de memória.
• Pod é indicado para carga estável, Serverless para carga variável.
• A cobrança é pelo tempo de operação da GPU, não por tokens.

Onde estão as armadilhas

Um modelo aberto não é obrigado a se comportar como o GPT nos seus prompts. Em raciocínio complexo e contexto longo, a diferença pode ser perceptível, e function calling e saída estruturada são implementados de formas distintas em cada modelo. O endpoint compatível com a OpenAI garante o formato da requisição, mas não a qualidade da resposta.

O segundo grupo de riscos é a operação. No serverless existe o cold start: a primeira requisição após um período ocioso pode demorar bem mais que o normal. Monitoramento, filas, atualização de pesos e de versões do servidor passam a ser responsabilidade sua, e não do fornecedor. Para um time pequeno, isso pode custar mais do que os tokens economizados.

Como testar com o seu tráfego

Antes de migrar a produção, é prudente seguir alguns passos:

1. Ativar o registro de requisições e respostas reais, para montar um conjunto de testes fiel. 2. Rodar esse conjunto no modelo candidato e comparar com o modelo atual pelos seus critérios, e não pelos benchmarks públicos. 3. Executar o novo modelo em modo sombra (shadow) em uma pequena fatia do tráfego, por exemplo 5–10%. 4. Calcular o custo de mil requisições com a carga real da GPU, incluindo o tempo ocioso. 5. Manter a API da OpenAI como rota de reserva, caso haja falha ou queda de qualidade.

Se, depois disso, os números fecharem, a migração se justifica. Se não, o guia da RunPod continua útil: ele mostra quanto custa, de fato, a independência de uma API alheia.