Como medir a latência do Mercury 3 para além dos tokens por segundo

Meça o Mercury 3 desde o início de uma tarefa até o resultado estar pronto a ser utilizado. Registe o tempo até à primeira resposta, o tempo até à resposta completa e o tempo total, incluindo as ferramentas. Os tokens por segundo descrevem apenas uma parte da geração; podem não refletir a espera antes de surgir o resultado nem o trabalho necessário depois de o modelo terminar.

Use um pequeno conjunto de dados de teste com critérios de aceitação explícitos e mantenha registados o pedido, os ficheiros de entrada, o ambiente das ferramentas e as definições do modelo. Isso basta para estabelecer o comportamento básico e identificar os estrangulamentos. Amplie o teste apenas quando uma falha ou uma decisão difícil exigir mais dados.

Que marcas temporais devo recolher?

Use um temporizador monotónico do lado do cliente para medir as durações e registe se a transmissão em fluxo está ativada. Mantenha consistentes as condições de estabelecimento da ligação e de reutilização da ligação ao comparar fornecedores. Não deduza o comportamento do primeiro token a partir de um pedido sem transmissão em fluxo.

Como escolho um pedido de teste justo?

Escolha uma tarefa real e delimitada: extrair campos especificados de um documento aprovado ou fazer uma pequena alteração num repositório copiado. Mantenha a entrada e o resultado exigido iguais em todas as execuções. Registe o identificador do modelo, a definição de esforço e o limite de saída, para que os resultados continuem a ser interpretáveis.

A apresentação geral do Mercury 3 explica por que razão os valores de débito indicados pelos fornecedores não substituem esta medição ao nível da tarefa.

Como é que as ferramentas afetam o resultado?

Separe o tempo de espera pelo modelo da execução de ferramentas. Uma leitura lenta do NAS, a navegação entre páginas ou uma pesquisa externa podem dominar uma tarefa com várias etapas. Conte as tentativas repetidas, os argumentos de ferramentas inválidos e as leituras repetidas de ficheiros, em vez de ignorar o tempo gasto em tentativas falhadas.

Use a lista de verificação do harness do agente para identificar que componente é responsável por cada atraso. Se a chamada ao modelo representar uma pequena parte do trabalho, melhorar o acesso ao armazenamento ou a conceção da tarefa poderá ser mais importante do que mudar a arquitetura de geração.

De quantas execuções preciso?

Uma execução é útil para verificar a conectividade e detetar problemas óbvios de correção. Algumas repetições consistentes podem revelar grandes diferenças práticas, mas não justificam afirmações precisas sobre fiabilidade nem percentis de cauda estáveis. Recolha mais observações apenas se os riscos da implementação ou uma decisão de desempenho renhida o justificarem.

Mantenha sempre visíveis as falhas. Uma execução rápida bem-sucedida, selecionada entre várias tentativas falhadas, não é uma evidência representativa. O guia de verificação focada do fluxo de trabalho apresenta uma abordagem leve para a aceitação.

O que devo indicar além da latência?

Indique se o artefacto passou na revisão, os custos de utilização relevantes, as chamadas a ferramentas e as correções manuais. Inclua o ambiente e a data. Se uma execução exceder o tempo limite, registe-a como tal em vez de lhe atribuir uma pontuação de velocidade apelativa.

Para ficheiros NAS, mantenha os dados de teste e a saída aceite em diretórios separados. Use a comparação de arquiteturas para decidir o que significam as medições e o guia de preparação de ficheiros para limitar a exposição de dados no projeto-piloto.

Perguntas frequentes

Posso comparar diretamente os tokens por segundo de tokenizadores diferentes?

Interprete esses valores com cautela. As definições de tokens, o conteúdo de saída e as condições de medição podem variar consoante o fornecedor.

E se a API não transmitir os dados em fluxo contínuo?

Meça a duração da resposta completa e a conclusão da tarefa. Não afirme um resultado relativo ao primeiro token que o seu cliente não consiga observar.

As execuções falhadas devem ser excluídas?

Não. Registe os tempos limite, as novas tentativas e os artefactos rejeitados, pois afetam o tempo e o custo práticos de conclusão.

Preciso de um benchmark de grandes dimensões antes de um projeto-piloto?

Não. Comece com uma pequena tarefa representativa e amplie as medições apenas quando uma incerteza relevante o exigir.

Leitura relacionada

• Mercury 3 explicado: porque são importantes os modelos de linguagem de difusão para fluxos de trabalho rápidos com IA
• LLMs de difusão vs. autorregressivos: qual se adequa melhor ao seu fluxo de trabalho pessoal com IA?

Fontes

• Anúncio oficial e documentação do modelo — www.inceptionlabs.ai
• Documentação técnica e referência — docs.inceptionlabs.ai

Capa: imagem oficial do anúncio do Mercury 3. Fonte da imagem.