Relatório preliminar. O universo pode ter mudado desde a coleta dos dados.
DeepSeek-V4-Flash & Pro: a sonda de transporte — latência, throughput e disponibilidade em 4 provedores
Este documento não pontua respostas. O post de provedor mediu acurácia — o que o endpoint disse. Esta sonda mede o transporte: quanto tempo uma resposta completa leva de ponta a ponta, quão rápido chega o primeiro token e — a parte que benchmarks de acurácia nunca veem — se o endpoint está sequer lá quando você chama. Mesmo workload, quatro provedores para Flash, três para Pro. O resultado não é um ranking de modelos; é um mapa dos canos.
Os dados vêm de d4flash_benchmark_result.json (run 2026-08-10T21:59Z). O workload é idêntico em todos os provedores: um prompt de geração JSON (5 capitais brasileiras com UF e população, mais um total), temperature 0.2, max_tokens 400, streamado. Cada braço rodou 3 vezes. Métricas registradas por run: tempo até o primeiro byte (TTFB), latência total, tokens/seg estimados e modo de entrega.
A comparação — DeepSeek-V4-Flash (mesmo modelo, 4 provedores)
| Provedor | ok | TTFB média (p50) | Total média (p50) | tok/s est. | entrega |
|---|---|---|---|---|---|
| Marvin (tripln) | 3/3 | 4,84s (4,34) | 4,85s (4,35) | 13795* | stream |
| Nous (flash) | 1/3 | 1,06s (1,06) | 4,95s (4,95) | 9,6 | stream |
| MarvinDeepSeek 1.19848845.xyz | 3/3 | 2,04s (2,13) | 2,44s (2,49) | 111,5 | stream |
| OpenRouter (flash) | 3/3 | 1,03s (1,12) | 4,71s (4,16) | 21,2 | stream |
* inflado por entrega em burst — ver a nota de TPS abaixo.
Três achados, todos de nível de transporte
1. Latência total — a métrica justa — tem um caminho mais rápido claro. MarvinDeepSeek 1.19848845.xyz completa a resposta inteira com média de 2,44s (p50 2,49s), aproximadamente metade do próximo (OpenRouter, 4,71s) e do gateway marvin tripln (4,85s). No Pro a distância é ainda maior: 3,74s contra 6,39s (Nous PRO) e 8,27s (OpenRouter PRO). A nota do próprio script do bench vale citação: "TPS só é comparável entre provedores que fazem streaming token a token. Gateways que bufferizam e emitem a resposta inteira em burst mostram um TPS artificialmente gigante. Latência total é a métrica justa entre provedores."
2. TTFB não prevê o total — o gateway tripln bufferiza. Marvin (tripln) tem o pior TTFB dos quatro (4,84s) e mesmo assim termina em 4,85s: ele bufferiza quase a resposta inteira antes de emitir qualquer coisa — o que também explica por que os 13.795 tok/s estimados são artefato de medição, não velocidade. OpenRouter tem o primeiro token mais rápido (1,03s) mas o segundo total mais lento (4,71s) — começo rápido, depois uma cauda de 3,7s. O primeiro token mais rápido e a resposta completa mais rápida são provedores diferentes. Quem construir em cima de TTFB sozinho escolheria o cano errado.
3. Disponibilidade sob carga: Nous flash respondeu 1 de 3. Duas das três chamadas contra Nous retornaram HTTP 503 — "The requested model is temporarily unavailable due to upstream capacity limits." Os outros três provedores responderam 3/3. Nesta amostra pequena (n=3), a disponibilidade da rota Nous flash é 33% — um número que um benchmark de acurácia nunca revelaria, porque benchmarks de acurácia só pontuam as respostas que chegam. O chart mostra as duas taxas: HTTP 200 por provedor e "200 com conteúdo" — porque as duas coisas não são a mesma.
HTTP 200 ≠ conteúdo
Quatro runs nesta sonda retornaram status 200 com corpo vazio (output_chars 0, delivery: burst): uma de três no MarvinDeepSeek flash, duas de três no Nous PRO, uma de três no OpenRouter PRO. Mais um run do marvin tripln que retornou o literal "..." (3 caracteres). O harness contou todas como ok porque o transporte respondeu 200 — mas o consumidor recebeu nada. Este é o mesmo defeito de 200 vazio que o post do lineup marcou como de nível de router, agora visível nos números de transporte: disponibilidade de status e disponibilidade de conteúdo são grandezas diferentes. Nous PRO marca 3/3 em HTTP 200 e 1/3 em conteúdo.
O lateral Pro — mesma história, lacunas maiores
| Provedor | ok | TTFB média (p50) | Total média (p50) | tok/s est. | conteúdo |
|---|---|---|---|---|---|
| Nous PRO | 3/3 | 1,84s (1,54) | 6,39s (6,89) | 8,0 | 1/3 |
| MarvinDeepSeek 1.19848845.xyz PRO | 3/3 | 2,01s (1,73) | 3,74s (4,50) | 66,9 | 3/3 |
| OpenRouter PRO | 3/3 | 2,40s (1,54) | 8,27s (7,27) | 9,2 | 2/3 |
Pro custa mais tempo em todo lugar exceto na rota 1.19848845.xyz, que serve Pro mais rápido que três das quatro rotas servem Flash. E é no Pro que o defeito do 200 vazio fica mais visível: duas das três runs do Nous PRO retornaram nada.
O que isso significa
O post de acurácia mostrou que o endpoint muda o produto. A sonda de transporte mostra o mesmo com os canos: a rota mais rápida para uma resposta completa é 1.19848845.xyz, o primeiro token mais rápido é OpenRouter, o mais confiável sob carga é qualquer coisa menos Nous-flash neste dia, e um 200 com corpo vazio é um defeito que só instrumentação de transporte consegue enxergar. Cada uma dessas é uma dimensão diferente, e nenhuma aparece num placar.
Leia o n antes de citar qualquer coisa daqui — são 3 runs por braço numa única tarde, e os 33% da Nous são uma amostra de três. O que é estrutural é a classe dos achados: TTFB e total se desacoplam quando um gateway bufferiza, e 200 não é conteúdo.
O Ministério Interplanetário de Infraestrutura recomenda medir o cano antes de confiar no placar, e manter os tratados frágeis.