? Engenharia

7 de setembro de 2026

Apesar de parecer simples, a realidade é bem mais complicada.

Eu opero a Olly, um assistente de IA que funciona no iMessage, utilizando modelos de código aberto através do OpenRouter. Até agora, a Olly enviou mais de 18 milhões de mensagens, sendo aproximadamente um terço delas em modelos abertos via OpenRouter. Esse volume é suficiente para encontrar todos os casos extremos pelo menos uma vez. Aqui está uma lista de coisas que eu gostaria de ter sabido antes de começar.

Primeiro, vamos esclarecer alguns termos: o modelo refere-se aos pesos, enquanto o provedor é quem o OpenRouter direciona. Eles hospedam o modelo em suas GPUs, com a precisão e otimizações que escolheram, além de seus próprios analisadores de XML/ferramentas, o que significa que cada um tem uma lista "proprietária" de bugs. Quando você solicita deepseek/deepseek-v4-flash, você recebe um de aproximadamente 20 provedores que você provavelmente nunca ouviu falar. Embora sejam o mesmo modelo em teoria, na prática são muito diferentes.

Aqui estão alguns dos cuidados que você deve ter:

1. O mesmo modelo pode ter benchmarks muito diferentes.

O OpenRouter realiza benchmarks por provedor sobre o mesmo modelo: GPQA Diamond e TAU-Bench Airline (uma tarefa de chamada de ferramenta). A tabela de hoje para o DeepSeek V4 Flash 0731, com cada provedor servindo os mesmos pesos, mostra uma variação significativa nos resultados, com alguns provedores apresentando desempenhos muito abaixo do primeiro provedor.

2. Um modelo de visão pode ter provedores com falhas.

Percebi comportamentos não determinísticos em tarefas de imagem e testei três imagens pequenas através de diferentes provedores de dois modelos de visão abertos. Alguns provedores não conseguiram interpretar as imagens corretamente, enquanto outros funcionaram bem.

3. O parâmetro de esforço é opcional para alguns provedores.

O parâmetro reasoning.effort é aceito em todos os lugares, mas a eficácia dele varia de acordo com o modelo e o provedor. Ao testar com diferentes configurações de esforço, percebi que muitos provedores respeitam as configurações, enquanto outros não.

4. Filtros de quantização não garantem qualidade.

O OpenRouter permite filtrar provedores pela precisão declarada, mas a prática mostrou que essa abordagem não é um bom indicador de qualidade, pois as pontuações dos provedores não correlacionavam bem com as quantizações que declaravam.

5. A chamada de ferramenta está no texto.

Idealmente, o modelo deve emitir uma chamada em alguma marcação, mas muitas vezes isso não acontece e você encontrará respostas que requerem parsing adicional de sua parte.

6. 200 OK, sem resposta.

Modelos de raciocínio às vezes retornam uma resposta sem conteúdo, o que indica que a solicitação foi servida, mas não há resposta útil. Isso é um sinal claro de falha.

7. Completudes vazias.

Alguns endpoints retornam 200 com conteúdo nulo e sem objetos de uso. Isso pode causar problemas significativos em suas análises de tráfego.

8. Regras de histórico diferentes para os mesmos modelos.

O DeepSeek em modo de pensamento emite um bloco de reasoning_content, mas alguns provedores podem não aceitar isso adequadamente, resultando em erros.

9. Teste a partir do ambiente de produção, não do seu laptop.

A velocidade e a latência são fatores cruciais, e os testes realizados em diferentes ambientes podem resultar em comportamentos variados, incluindo limitações de taxa.

10. Por que não fixar um único provedor?

Tentei fixar três provedores confiáveis, mas logo encontrei problemas com limitações de taxa e interrupções, fazendo com que todo o tráfego fosse direcionado a um único provedor, que eventualmente também falhou.

Boa sorte na sua jornada!