APIs de LLM gratuitas: o verdadeiro comparativo (e a opção locale)

#Por que este comparativo

Ao criar um protótipo, o primeiro impulso costuma ser buscar uma API de LLM gratuita: você quer testar uma ideia sem tirar o cartão do bolso, conectar um modelo a um script e ver se funciona. A boa notícia é que existem opções gratuitas, às vezes bastante generosas. A má notícia é que “gratuito” pode significar coisas muito diferentes: um plano gratuito permanente, créditos de teste que expiram ou um acesso oferecido pela comunidade com velocidade limitada.

O foco desse guia não é dizer 'o local é melhor'. É fornecer os números para você decidir sozinho: o que cada oferta gratuita realmente permite, o que ela exige em troca, e a partir de qual volume ou restrição de confidencialidade um endpoint local se torna a escolha racional. Muitas vezes, a melhor resposta não é nem uma nem a outra, mas as duas, com roteamento conforme a tarefa.

#Panorama das APIs de LLM gratuitas

É possível classificar as ofertas gratuitas em quatro famílias. Entender a qual família pertence uma oferta evita surpresas desagradáveis quando o contador chega a zero no meio de um sprint.

Plano gratuito permanente

Um acesso gratuito que não expira, mas com limites de requisições por minuto e por dia. É o caso do Google AI Studio (API Gemini) ou do Groq, que oferecem modelos abertos (Llama, Qwen, gpt-oss) com acesso gratuito, mas com limites de taxa de requisições.

Agregadores e modelos :free

OpenRouter oferece dezenas de modelos, alguns com sufixo «:free». O acesso é real, mas a velocidade depende de um recurso compartilhado e pode cair durante horários de pico.

Crédito de teste

Um valor oferecido (geralmente alguns dólares) ao criar a conta, que expira após algumas semanas. Útil para um teste pontual, inútil para um projeto de longa duração.

Inferência comunitária

Hugging Face Inference e serviços semelhantes: acesso gratuito a muitos modelos, mas com inicialização a frio (cold start), filas de espera e taxa de transferência não garantida.

#As cotas reais, sem filtro

A palavra “grátis” esconde três limites distintos que, juntos, determinam se a oferta atende ao seu uso. Uma faixa de oferta pode ser generosa em um deles e muito restritiva nos outros dois.

Requisições por minuto (RPM)

O número de chamadas permitidas por minuto. Os planos gratuitos costumam ter cerca de algumas dezenas de RPM — bastante para um desenvolvedor testando, mas insuficiente para atender vários usuários simultaneamente.

Tokens por dia (TPD)

O limite que realmente determina o uso. Uma cota diária de tokens se esgota muito rapidamente assim que você envia prompts grandes, contexto RAG ou percorre um conjunto de dados em um loop.

Taxa de geração e latência

Em ofertas gratuitas compartilhadas, a velocidade de geração nunca é garantida. Nas horas de baixa demanda, a geração é fluida; nos picos, a latência explode ou as requisições são rejeitadas (erro 429).

Na prática: para prototipagem manual, com algumas requisições de vez em quando, as cotas gratuitas são suficientes para trabalhar com folga. Assim que você automatiza um processamento em lote com um script — classificar mil tickets, resumir uma caixa de e-mails, gerar testes em um repositório — você esbarra no limite de TPD em poucos minutos, e a limitação da taxa de processamento transforma um lote de 10 minutos em uma espera de uma hora intercalada com erros 429.

#O que você realmente paga

Uma API gratuita não é isenta de custos: o preço é simplesmente transferido do bolso para outras categorias. Três delas pesam muito para um projeto de desenvolvimento.

Seus dados

Em muitos níveis gratuitos, os prompts e respostas são conservados e podem ser usados para treinar ou melhorar os modelos. O que é aceitável para testes com dados fictícios não é aceitável com código proprietário, dados de clientes ou informações pessoais (RGPD).

Dependência

Construir sobre uma cota gratuita é como construir sobre um solo que pode ceder: mudanças nas condições, modelo removido, nível eliminado. Seu código, seus prompts e suas configurações estão calibrados para um provedor; migrar custa tempo que você não previu.

Imprevisibilidade

Latência variável, filas de espera, interrupções: é difícil cumprir uma promessa de qualidade de serviço quando o componente central está fora do seu controle e não oferece nenhuma garantia de serviço na oferta gratuita.

#Opção local com Ollama

Diante do gratuito com condições, há o gratuito de verdade: executar o modelo em sua própria máquina. Ollama é a ferramenta mais simples para isso. Trata-se de um daemon que baixa modelos com pesos abertos e expõe uma API HTTP local em http://localhost:11434, incluindo um endpoint compatível com a OpenAI, o que significa que o código escrito para uma API de nuvem geralmente funciona apenas alterando a URL de base.

# Installer Ollama (Linux/macOS)
curl -fsSL https://ollama.com/install.sh | sh

# Tirer et lancer un modèle 7-8B quantifié Q4_K_M
ollama pull qwen2.5:7b
ollama run qwen2.5:7b

# Le daemon écoute sur http://localhost:11434

No código, o endpoint compatível com a OpenAI conecta-se em três linhas. Sem chave de API para gerenciar, sem limite de uso, sem dados saindo da máquina.

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",  # endpoint local Ollama
    api_key="ollama",  # ignoré en local, mais requis par le client
)

resp = client.chat.completions.create(
    model="qwen2.5:7b",
    messages=[{"role": "user", "content": "Explique la récursion en une phrase."}],
)
print(resp.choices[0].message.content)

A contrapartida é o hardware. Um modelo local exige VRAM (ou memória unificada no Mac Apple Silicon). Na quantização Q4_K_M, a referência de memória é fácil de lembrar: um modelo de 3B cabe em ~2 GB, um de 7B em ~5 GB, um de 14B em ~9 GB, um de 32B em ~19 GB e um de 70B exige ~40 GB. Uma RTX 3060 de 12 GB roda modelos de 7 a 14B com conforto; uma RTX 4090 de 24 GB ou um Mac M4 Pro com 24 a 48 GB de memória unificada permite o uso de modelos de 32B.

Confidencialidade total

Nenhum prompt sai da máquina. Código proprietário, dados dos clientes, informações pessoais: tudo permanece com você, o que simplifica drasticamente a conformidade com o RGPD.

Sem cota de uso

Nenhum RPM, nenhum TPD. Você processa dez mil documentos à noite sem se preocupar com a contagem e sem erro 429.

Custo marginal nulo

Depois que você já tem o hardware, cada requisição é gratuita. O custo da eletricidade de uma GPU de desktop continua sendo desprezível em comparação com uma conta de API cobrada por uso.

Estabilidade

Sem mudanças nas condições, sem modelos retirados. A versão que você baixou permanece idêntica enquanto você não a atualizar.

#O ponto de virada para o uso local

A pergunta útil não é 'gratuito ou local?' mas 'a partir de quando o local se torna a melhor opção?'. Quatro sinais indicam que você ultrapassou o limiar.

1. 01
   Você processa dados que não pode expor

   Assim que houver código proprietário, dados de clientes ou informações pessoais no prompt, a cláusula de treinamento de uma API gratuita torna-se inaceitável. A solução local resolve o problema na raiz: nada sai.
2. 02
   Você atinge os limites com frequência

   Se seus scripts terminarem com erros 429, se você dividir seus lotes para permanecer abaixo do TPD ou se alternar entre várias contas gratuitas, você já está gastando o tempo que a execução local lhe devolveria.
3. 03
   O volume é previsível e contínuo

   O uso regular — geração contínua de testes, pipeline RAG interno, classificação permanente — compensa rapidamente quando feito localmente. O hardware é um custo fixo amortizado; a API cobrada por uso é um custo variável que aumenta com o sucesso do projeto.
4. 04
   Você quer latência controlada

   Em uma máquina dedicada, a latência depende apenas de você, não da carga de um serviço compartilhado. Para uma ferramenta interna usada o dia todo, essa previsibilidade é valiosa.

#Manter os dois: o roteamento inteligente

A arquitetura mais sólida para um projeto de desenvolvimento não se limita a uma única opção: ela direciona cada tarefa para o endpoint mais adequado. O processamento local cuida da maior parte do volume e de tudo o que é sensível; a nuvem é reservada para tarefas que realmente ultrapassam a capacidade da máquina.

Para uso local

Tarefas de alto volume, dados sensíveis, laços de processamento, iterações de desenvolvimento, tudo o que deve permanecer confidencial. Um modelo local de 7-14B atende à grande maioria das necessidades comuns de desenvolvimento.

Para a nuvem

Raciocínio complexo que exige um modelo muito grande, pico de carga pontual ou funcionalidade multimodal indisponível localmente. Só se envia para lá o que justifica esse uso, e nunca dados sensíveis.

Como o Ollama expõe uma API compatível com a OpenAI, esse roteamento é simples de implementar em código: dois clientes e uma regra de seleção conforme a tarefa. Para ir além, um proxy como o LiteLLM centraliza vários backends por trás de uma única interface, com fallback automático da nuvem para a execução local (ou o inverso) e acompanhamento de custos.

from openai import OpenAI

local = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")
cloud = OpenAI(base_url="https://api.exemple.com/v1", api_key="VOTRE_CLE")

def router(sensible: bool, gros_raisonnement: bool):
    # Données sensibles OU volume : local par défaut
    if sensible or not gros_raisonnement:
        return local, "qwen2.5:7b"
    # Sinon, cloud pour un modèle plus puissant
    return cloud, "modele-frontiere"

client, model = router(sensible=True, gros_raisonnement=False)
resp = client.chat.completions.create(
    model=model,
    messages=[{"role": "user", "content": "Résume ce ticket interne..."}],
)

#Iniciar localmente em 4 etapas

1. 01
   Instalar Ollama

   Um comando no Linux/macOS (curl -fsSL https://ollama.com/install.sh | sh) ou o instalador oficial no Windows. O daemon inicia e escuta em http://localhost:11434.
2. 02
   Escolher um modelo de acordo com o seu hardware

   Verifique sua VRAM disponível e escolha um modelo em Q4_K_M com margem para o contexto: 7B (~5 GB) para 8-12 GB de VRAM, 14B (~9 GB) para 12-16 GB, 32B (~19 GB) para 24 GB. Com menos, um 3B (~2 GB) continua útil para tarefas simples.
3. 03
   Baixar o modelo e testar

   ollama pull qwen2.5:7b e depois ollama run qwen2.5:7b para verificar se ele responde. Um pull é feito apenas uma vez; depois, o modelo fica no cache local.
4. 04
   Conectar seu código

   Aponte seu cliente OpenAI existente para http://localhost:11434/v1. O restante do código — mensagens, streaming, chamadas de funções — funciona como com uma API na nuvem, sem chave nem cota.

#Para se aprofundar

Com o Ollama instalado, três guias do site ajudam você a dar continuidade a essa transição. O guia de integração da API REST do Ollama em Python detalha streaming, modo JSON e chamadas de função no endpoint local. O comparativo de custos de um servidor GPU calcula o ponto de equilíbrio entre a compra de hardware e o uso de APIs na nuvem. E, para um roteamento em escala de produção entre o ambiente local e a nuvem, o guia LiteLLM mostra como unificar os dois por trás de um proxy com fallback e acompanhamento de custos.