Relatório preliminar. O universo pode ter mudado desde a coleta dos dados.
Confiabilidade inverte o sinal — o trade-off do Marvin Router em produção
O post do provedor documentou o delta incômodo: o mesmo peso DeepSeek-V4-Flash, servido por dois endpoints, perde 62 pontos em AIME ao trocar de provedor (0.867 via openrouter vs 0.244 via marvin, delta pareado -0.622, intervalo de 95% [-0.767, -0.478]). Também documentou a inversão — mas como seção final, como se fosse nota de rodapé. Não é. O dado mais interessante da safra W32 é o trade-off em si: o endpoint que vence o placar bruto é o que você não quer na frente de um usuário.
Este post trata o trade-off como decisão de engenharia. Os números vêm do run 2026-W32-public (suíte 1d2792e98840, 188 chamadas por braço) — as mesmas figuras, o mesmo n, os mesmos intervalos de 95% pareados, nada novo foi medido.
Duas forças, direções opostas
| Endpoint | Marvin Score | Confiabilidade | Erros | TTFT p50 | Latência p50 | tok/s |
|---|---|---|---|---|---|---|
| DeepSeek-V4-Flash@openrouter | 0.756 | 91.0% | 9.0% | 15.3s | 20.1s | 792 |
| DeepSeek-V4-Flash@marvin | 0.568 | 98.9% | 1.1% | 1.4s | 6.6s | 126 |
Nenhuma coluna sozinha conta a história. O placar diz openrouter, a tabela de operação diz marvin, e ambos estão certos — no regime certo.
A métrica: throughput efetivo
O benchmark registra o que um leaderboard ingênuo joga fora: taxa de erro, taxa de timeout e defeitos de transporte. Uma primeira tentativa de métrica de decisão dobra tudo isso num número só:
Throughput efetivo = (1 − error_rate) × tokens_per_second × (1 − timeout_rate)
- marvin: (1 − 0.011) × 125.8 × (1 − 0.0) = ~124 tok/s efetivo
- openrouter: (1 − 0.090) × 792.5 × (1 − 0.0) = ~721 tok/s efetivo
Por essa métrica, openrouter vence por 5.8×. Isso é real: para um job em lote — avaliação offline, geração em massa, uma fila de prompts que tolera retries e roda em paralelo — o endpoint rápido e instável domina. Seus 9% de erro custam menos que a vantagem de 6× na velocidade. Esse é o regime de capacidade, e a métrica o captura bem.
Mas repare no que a fórmula assume silenciosamente: paralelismo ilimitado. Ela é a lente certa para um job que amortiza streams lentos entre requisições concorrentes, e a lente errada para um turno interativo único — o segundo regime.
O regime em que o placar bruto perde
Para um gateway interativo — Curio, um assistente, qualquer loop em que um humano (ou um agente) espera esta chamada — as grandezas relevantes não são tokens por segundo:
- TTFT p50: 1.4s (marvin) vs 15.3s (openrouter) — onze vezes mais até o primeiro token.
- Latência p50: 6.6s vs 20.1s, e a cauda é pior: p95 de 18.6s vs 205.9s. O caminho openrouter tem uma cauda de três minutos e meio. Um humano já foi embora muito antes; um loop de agente já deu timeout.
- Erros: 1.1% vs 9.0%, com 4 vs 46 retries nas mesmas 188 chamadas. Uma em cada onze chamadas openrouter precisa de retry antes que o usuário veja resposta.
Nesse regime, a fórmula de throughput efetivo não é apenas inútil — ela fica de cabeça para baixo. Throughput assume muitas chamadas em voo; um gateway interativo não esconde um TTFT de 15.3s atrás de concorrência. A latência é sentida diretamente, em série, pela pessoa no terminal. O marvin vence esse regime por uma ordem de magnitude — e o placar de math nunca aparece na interação.
Não existe "endpoint melhor". Existem dois regimes com funções objetivo diferentes:
- Regime de capacidade (lote, offline, paralelizável): placar bruto e throughput efetivo dominam → openrouter vence, em AIME e em qualidade ajustada por confiabilidade (0.867 × 0.910 ≈ 0.79 vs 0.244 × 0.989 ≈ 0.24).
- Regime de interação (gateway, assistente, loop de agente): SLO de TTFT e de erro domina → marvin vence, 11× no primeiro token e 8× em falhas.
Aviso de poder (LiveCodeBench, n=18): este post usa o delta AIME (n=90, CI [-0.767,-0.478], sinal forte) para sustentar os regimes. A LiveCodeBench do mesmo run mediu Δ=-0.046 com CI 95% [-0.306,+0.204] — intervalo que cruza zero. Com n=18, isso é ruído de amostra, não sinal; não use LiveCodeBench para contestar o trade-off. Veja a tabela completa em /laboratorio/deepseek-v4-flash-provedor-diferente.
O chart de regimes
O scatter abaixo plota o par comparável contra os dois limiares: o piso de SLO de produção (confiabilidade ≥ 95%) e a barra de benchmark de capacidade (Marvin Score ≥ 0.70). Os braços comparáveis caem em quadrantes opostos; os outros braços da W32 aparecem apenas como contexto, com o fingerprint da suíte — scores de suítes diferentes não se comparam.
O quadrante vazio é o achado: nenhum braço desta safra cruza as duas barras ao mesmo tempo. Você não escolhe o melhor endpoint; escolhe o regime, e depois o endpoint que o serve. "É só usar o melhor modelo" descreve um mundo de regime único — que produção não é.
O que isso significa
O Marvin Score resume qualidade × confiabilidade num número só, e essa é exatamente a sua limitação: ele esconde o regime. Para quem opera um gateway (como o Marvin Router opera), a escolha do endpoint é uma decisão em dois passos — em qual regime esta tarefa está? — e só então qual endpoint a serve melhor. Meça valor entregue por tarefa bem-sucedida, não tokens por segundo no abstrato: um stream rápido que começa 15 segundos atrasado, ou falha uma vez em onze, entrega menos valor a um usuário interativo do que um mais lento que responde em 1.4s e falha uma vez em cem.
O Ministério Interplanetário de Infraestrutura recomenda manter duas colunas em todo placar — uma para o benchmark, uma para o SLO — e tratar com suspeita qualquer endpoint que não saiba dizer qual regime ele serve.