Meça quatro sinais diferentes de latência
Um único número de latência oculta os pontos em que os usuários estão esperando. Um chat com streaming pode parecer rápido com um TTFT baixo, mesmo quando a conclusão completa demora mais, enquanto uma extração em lote pode se importar apenas com a duração de ponta a ponta.
- Tempo até o primeiro token: do início da solicitação ao primeiro token transmitido.
- Throughput de geração: tokens de saída divididos pelo tempo de geração.
- Duração de ponta a ponta: do início da solicitação até a resposta concluída.
- Confiabilidade: respostas bem-sucedidas divididas pelo total de tentativas.
Controle a carga de trabalho do benchmark
Use um conjunto fixo de prompts que represente a carga de trabalho pretendida. Registre o ID do modelo, a rota do provedor, a região, os parâmetros da solicitação, os tokens de entrada e o comprimento de saída solicitado.
- Execute solicitações de aquecimento antes de registrar as medições.
- Randomize a ordem dos provedores para reduzir o viés causado pelo horário do dia.
- Repita os testes durante mais de uma janela de tráfego.
- Mantenha separados os resultados com streaming e sem streaming.
Use distribuições, não uma captura de tela de classificação
Informe os valores de mediana, p90 e p95 junto com o tamanho da amostra. Uma rota com a mediana mais rápida, mas com atrasos extremos frequentes, pode proporcionar uma experiência de produção pior do que uma rota ligeiramente mais lenta, porém mais estável.
{
"sample_size": 100,
"ttft_ms": { "median": 640, "p95": 1840 },
"output_tokens_per_second": { "median": 42.1 },
"end_to_end_ms": { "median": 5120, "p95": 9080 },
"success_rate": 0.98
}Os valores acima são um formato ilustrativo de relatório, não um resultado de benchmark ativo da CometAPI.
Publique a metodologia com cada relatório
Um benchmark só é útil quando o leitor consegue entender o que foi medido e reproduzir a abordagem. Inclua as limitações e explique se a rota do provedor foi fixada ou selecionada automaticamente.