Quando uma requisição bem-sucedida ainda é uma falha
Imagine conversar com o mesmo personagem há semanas. A voz dele é familiar, o idioma é consistente e as respostas parecem inteligentes e cheias de vida.
Então, sem trocar o personagem nem o modelo, algo começa a parecer errado.
A resposta seguinte leva dez segundos para começar. Um recurso que depende de saída estruturada para de funcionar. O personagem começa a divagar, insere trechos de outro idioma ou responde num estilo que parece vir de um modelo muito mais fraco.
Do ponto de vista do servidor, nada falhou. A API retornou 200 OK, os tokens chegaram e a requisição foi cobrada.
Do ponto de vista do usuário, o modelo acabou de piorar.
Essa diferença é o motivo pelo qual criamos para a Reverie um sistema de sondas canário e quarentena de rotas por provedor.
Um nome de modelo, muitos ambientes de inferência
O OpenRouter é o nosso principal gateway de modelos. Um de seus pontos fortes é permitir que um único modelo seja executado por vários provedores de inferência independentes. Se um deles estiver indisponível, outro pode atender à requisição. Isso oferece mais capacidade, preços competitivos e maior resiliência do que depender de um único endpoint.
Mas também cria uma variável invisível.
O nome do modelo pode continuar igual, enquanto a infraestrutura que o executa muda de uma requisição para outra. Cada provedor pode usar um mecanismo de inferência, hardware, nível de quantização, parser, template de chat, fila ou camada adicional de políticas diferente.
A documentação de roteamento de provedores do OpenRouter explica que a rota padrão considera disponibilidade recente e preço, mantendo outros provedores como fallbacks. Esses sinais são importantes, mas um endpoint pode estar online, ser barato e ainda produzir um resultado inaceitável para um produto específico.
O OpenRouter também já discutiu publicamente as diferenças mensuráveis entre provedores que executam o mesmo modelo. Em teoria, pesos idênticos na mesma precisão deveriam se comportar de maneira semelhante. Na produção, executar um grande modelo é complexo, e diferenças aparecem.
O que queremos dizer com “degradação do modelo”
“Degradação do modelo” não é um diagnóstico único e padronizado, nem significa automaticamente que um provedor substituiu de propósito o modelo por outro menor.
Usamos o termo de forma operacional: um endpoint de inferência está degradado quando deixa de preservar o comportamento, as capacidades ou o desempenho interativo que esperamos do modelo solicitado em prompts representativos, mesmo que a requisição seja tecnicamente bem-sucedida.
Para a Reverie, as formas mais claras são:
- Degradação de latência: a conexão funciona, mas o tempo até o primeiro token é longo o suficiente para quebrar a sensação de uma conversa ao vivo.
- Degradação de capacidade: um endpoint que deveria oferecer saída estruturada retorna texto malformado ou deixa de cumprir o schema.
- Degradação de comportamento: as respostas ficam corrompidas, incoerentes, inesperadamente repetitivas ou passam visivelmente para outro idioma.
- Incompatibilidade de política: um host adiciona sua própria camada de filtro e transforma uma cena aceita pela Reverie em recusa, resposta vazia ou texto truncado.
Há muitas causas possíveis. A quantização de menor precisão pode afetar prompts difíceis, como observam a documentação do OpenRouter e pesquisas publicadas sobre quantização. Mas ela não é uma explicação universal: bugs no mecanismo de inferência, parsers de ferramentas, erros no tokenizer ou no template de chat, filas sobrecarregadas e middleware do provedor podem ser igualmente importantes. O OpenRouter observou que, em chamadas de ferramentas, os parsers costumam gerar mais variação do que a precisão por si só.
A pergunta importante não é “qual causa parece mais suspeita?”, mas “conseguimos isolar o endpoint e reproduzir a falha?”.
Dois casos que tornaram o problema concreto
Essa não era uma preocupação teórica.
Em uma comparação fixada por provedor, um deles corrompeu o início de 19 entre 20 respostas, inserindo pontuação ou um fragmento de token sem relação. Nos outros quatorze hosts do mesmo modelo, o problema apareceu 0 vezes em 49 respostas. No roleplay, em que o primeiro caractere costuma ser um marcador de ênfase Markdown, um único byte estranho também podia quebrar a formatação da resposta inteira.
Em outro teste, um endpoint produziu uma mistura grave de português e espanhol em 3 de 3 gerações. O mesmo prompt permaneceu em português no host oficial do modelo e nos outros provedores testados com a mesma classe de precisão. “O modelo é apenas inconsistente” deixou de ser uma explicação convincente: o defeito acompanhava o endpoint.
Essas falhas são sutis porque nem sempre geram exceções. O monitoramento tradicional de disponibilidade vê uma API saudável. O usuário vê um personagem que, de repente, não consegue mais falar direito.
Nossa resposta: testar cada rota, não apenas o modelo
A cada trinta minutos, nosso canário descobre os provedores ativos do modelo de chat padrão da Reverie. Em seguida, envia um pequeno conjunto de requisições sintéticas para cada provedor, fixadas exclusivamente nele e com os fallbacks desativados.
Fixar a rota é essencial. Se a sonda puder usar fallback, um segundo provedor saudável poderá esconder a falha do primeiro. Precisamos saber exatamente qual ambiente produziu o resultado.
O sistema testa quatro contratos específicos que podem ser avaliados por código.
1. Tempo até o primeiro token
Numa conversa em streaming, o throughput representa apenas metade da experiência. O primeiro token determina quanto tempo o usuário fica olhando para um indicador de carregamento.
Medimos isso diretamente no stream. Um provedor que não produz texto em dez segundos falha na sonda de latência. O limite é intencionalmente generoso, e uma única rodada lenta não basta para remover um host; pressão temporária nas filas acontece.
2. Filtros e recusas silenciosas
Enviamos uma continuação fixa de roleplay, representativa do tráfego aceito pela Reverie. A sonda verifica o motivo de conclusão, padrões de recusa de alta confiança e respostas vazias.
Também executamos a sonda contra hosts conhecidos por filtrar conteúdo, como controles positivos. Se um controle passar inesperadamente, não declaramos todos os outros provedores saudáveis: marcamos a própria sonda como fraca. Um teste que não consegue mais detectar sua falha conhecida não comprova saúde.
3. Saída estruturada
Solicitamos um pequeno objeto com schema fixo e validamos o resultado. Erros de transporte e saída malformada são tratados de formas diferentes: uma conexão quebrada indica que o provedor estava inacessível; uma geração concluída que não atende ao schema demonstra regressão de capacidade.
“O endpoint declara suporte ao parâmetro” e “o endpoint respeita esse parâmetro de maneira confiável” não são a mesma promessa.
4. Integridade do idioma
A Reverie oferece suporte a 17 idiomas de interface, então um teste rápido apenas em inglês deixaria escapar problemas que nossos usuários realmente enfrentam.
O canário alterna entre os idiomas aceitos usando prompts sintéticos de roleplay. Um detector local e determinístico procura mudanças claras no idioma dominante da resposta, mistura persistente de idiomas e corrupção óbvia de codificação. Ele não usa conversas reais nem pede a outro modelo uma avaliação subjetiva.
Saídas ambíguas ou curtas demais são inconclusivas, não falhas. Quando uma anomalia de idioma é detectada, o canário executa imediatamente duas tentativas de confirmação e exige maioria. O mesmo idioma é repetido na rodada seguinte para que o provedor não escape da regra de rodadas consecutivas só porque a rotação avançou.
Criamos o sistema para desconfiar das próprias conclusões
Remover capacidade de inferência automaticamente é útil, mas um falso positivo pode causar uma interrupção maior do que o defeito original. Por isso o canário possui vários freios:
- Erros de transporte não contam como falhas de qualidade. Timeouts, rate limits e respostas 5xx congelam a pontuação em vez de avançar uma sequência de suspensão.
- Uma rodada ruim não basta. Um provedor deve falhar em duas rodadas consecutivas executadas a cada meia hora.
- Observação e aplicação são separadas. Podemos executar o sistema em modo de observação, registrar quais hosts seriam suspensos, notificar administradores e medir falsos positivos antes de ativar ações automáticas.
- A capacidade tem um piso. O canário não suspende um provedor se isso deixar menos de dois hosts em produção. Nesse caso, alerta um administrador.
- A recuperação também é testada. Provedores suspensos continuam recebendo sondas. Duas rodadas limpas consecutivas restauram um host antecipadamente.
- Falhas repetidas aumentam de forma gradual. As suspensões duram um dia no primeiro incidente, três dias no seguinte e sete dias depois disso. Após catorze dias sem nova suspensão, o histórico perde peso e a escala recomeça.
O objetivo não é punir provedores. É desviar o tráfego dos usuários de uma rota comprovadamente problemática e manter um caminho claro de volta quando o problema for corrigido.
Três camadas de proteção
A decisão final de roteamento combina três tipos de exclusão:
- Exclusões internas revisadas para defeitos ou incompatibilidades de política que já medimos e não queremos reintroduzir por acidente.
- Exclusões de incidentes em tempo de execução que um administrador pode adicionar imediatamente, sem esperar por um novo deploy.
- Suspensões temporárias do canário para provedores que ultrapassam o limite automático de falhas.
Essas listas são combinadas na preferência provider.ignore do OpenRouter quando a Reverie cria uma requisição. O usuário não precisa tentar novamente até que o acaso escolha um provedor melhor; a rota problemática deixa de ser considerada.
Cada decisão automática é registrada, administradores são notificados em mudanças relevantes e uma suspensão pode ser removida manualmente quando necessário.
O que este sistema garante — e o que não garante
O canário é deliberadamente específico. O código consegue avaliar latência, validade do schema, filtros de alta confiança, integridade de idioma e codificação. Ele não finge saber se um personagem é engraçado o bastante, emocionalmente perceptivo ou fiel a uma personalidade complexa.
Essas questões mais amplas ainda exigem avaliações com prompts representativos, revisão humana, telemetria de produção e, acima de tudo, relatos dos usuários.
O sistema também não significa que toda resposta estranha prove uma degradação. Modelos generativos são probabilísticos. Uma conversa longa pode acumular contexto conflitante, e uma definição de personagem pode conter instruções concorrentes. Às vezes, uma resposta estranha é apenas uma resposta estranha.
O que mudou é que “é o mesmo modelo” não encerra mais nossa investigação. Agora podemos isolar a rota, reproduzir falhas objetivas e manter o tráfego seguinte longe dela.
Confiabilidade significa preservar a experiência
O roteamento entre vários provedores continua valioso. Ele dá à Reverie capacidade e resiliência para manter conversas disponíveis quando endpoints individuais ficam fora do ar.
Mas resiliência não é apenas receber uma resposta HTTP. Uma resposta que chega tarde demais, perde sua estrutura obrigatória, recusa conteúdo aceito ou muda de idioma não é saudável só porque a fatura diz que a requisição teve sucesso.
Para um produto de personagens de IA, confiabilidade significa algo mais humano: o personagem deve continuar parecendo o mesmo personagem, independentemente da máquina que esteja falando por ele.
Esse é o padrão que nossas novas proteções de roteamento foram criadas para preservar.
Se você perceber uma mudança repentina na qualidade ou no idioma das respostas, envie um relato com o nome do modelo e o horário aproximado. Isso nos ajuda a ligar a experiência que você viu à rota exata que a produziu.