18 milhões de mensagens mostram que provedores de LLM diferem muito

O mesmo modelo, provedores diferentes

O autor mantém Olly, um assistente de IA que vive no iMessage e roda sobre modelos abertos via OpenRouter. Até hoje o assistente transacionou mais de 18 milhões de mensagens, cerca de um terço delas em modelos abertos via OpenRouter - volume suficiente, segundo ele, para esbarrar em cada caso extremo pelo menos uma vez. O texto reúne o que ele gostaria de saber antes de começar.

A distinção básica: o modelo são os pesos; o provedor é quem o hospeda, com sua própria precisão, otimizações “proprietárias”, parsers de XML e de chamadas de ferramenta - e, portanto, sua própria lista de bugs. Pedir deepseek/deepseek-v4-flash entrega um entre cerca de 20 provedores. São o mesmo modelo no papel, diz ele, mas modelos bem diferentes na prática.

Benchmarks variam por provedor

OpenRouter mantém quadros por provedor do mesmo modelo, com GPQA Diamond e TAU-Bench Airline (tarefa de chamada de ferramenta). No DeepSeek V4 Flash 0731, a primeira parte (DeepSeek) marca 90,2% no GPQA e 81,3% no TAU; a DigitalOcean, com os mesmos pesos, 75,3% e 58,4%. A maioria dos hosts fica 5 a 7 pontos abaixo da primeira parte em chamada de ferramenta, e quatro caem de forma acentuada em conhecimento. Para um agente, o TAU é a métrica que importa, e uma variação de 20 pontos não é ruído - em julho a situação era pior, com a Fireworks em 46% no TAU, uma lacuna de 30 pontos. Ele recomenda conferir o quadro do benchmark mais próximo da carga de trabalho antes de confiar em um provedor e refazer a checagem ao trocar de modelo: os mesmos provedores pareciam completamente diferentes no GLM-5.3.

Visão, esforço e quantização

Em modelos de visão há provedores cegos: no Qwen3.5 122B, a DeepInfra leu um K como R/I e chamou vermelho de azul, enquanto outros quatro hosts dos mesmos pesos acertaram tudo; no MiniMax M3, Venice e Together responderam que nenhuma imagem havia sido fornecida. O erro de cor do MiniMax ocorreu em todos os hosts, inclusive na primeira parte, o que aponta para o modelo, não para o provedor.

O parâmetro reasoning.effort é aceito em todos os lugares, mas seu efeito depende do modelo e do provedor; em um teste com DeepSeek V4 Flash 0731, digitalocean, gmi-cloud, mancer e venice não parecem responder ao ajuste. Já o filtro de quantização (fp8 em vez de fp4) não indica qualidade: os três piores GPQA do DeepSeek incluem um host fp4, um fp8 e um que não declara precisão; o melhor do GLM 5.3, Wafer, não declara nada. Um filtro rígido também reduz o conjunto de reserva para quando um provedor sai do ar.

Falhas silenciosas e contrato por provedor

Às vezes o parser do provedor erra e a chamada de ferramenta vaza como texto; a recorrência varia muito por provedor e exige parsing do lado do cliente, com casos que pedem tratamentos opostos. Outras vezes a resposta chega com 200 OK e content nulo, finish_reason “stop” e 345 tokens de completion, sem nada para mostrar ao usuário: o autor trata ausência de conteúdo e de chamada de ferramenta como falha e refaz a requisição. Há ainda completions ocas, com content e reasoning nulos e sem objeto usage - em julho, a StreamLake concentrava cerca de 20% do tráfego e 92% das completions vazias; um mês depois a Together fez o mesmo.

O contrato de histórico também é por provedor: um bloco reasoning_content vazio devolvido ao SiliconFlow gera erro 400 (código 20015), enquanto Baidu, Alibaba e Cloudflare aceitam o mesmo histórico. Por fim, ele alerta para testar da produção, não do laptop - Venice e Novita funcionavam do Mac mas devolviam 429 quase sempre na infraestrutura, o que ele atribui a limite por IP - e relata que fixar três provedores confiáveis com allow_fallbacks: false deixou o serviço fora do ar duas semanas depois, quando dois falharam e o terceiro também passou a limitar.