BenchZgxFury

Os melhores valores observados entre as medidas selecionadas. Maior rendimento (tok/s) é melhor; uma latência mais baixa (TTFT = atraso antes do primeiro token, TPOT = atraso entre dois tokens) é melhor.

Um resumo escrito automaticamente a partir das medidas exibidas (segue os filtros): o que lembrar, família por família.

Um servidor LLM atende vários usuários ao mesmo tempo: o competição é o número de solicitações simultâneas. O vazão agregada (tokens gerados por segundo, todas as solicitações combinadas) aumenta com a simultaneidade, enquanto a latência por usuário piora. O TTFT é o tempo de espera antes da primeira palavra, o TPOT o tempo entre duas palavras (p50 = valor mediano, p99 = caso desfavorável vivenciado por 1% das solicitações). Cada ponto é a mediana de várias repetições. As linhas pontilhadas cinza são figuras publicadas (referência) para o mesmo modelo e mesmo perfil.

O boa colocação é a quantidade de trabalho útil atendido respeitando um objetivo de qualidade de serviço (SLO): aqui TTFT p99 ≤ ms e latência entre tokens p99 ≤ Sra. A barra indica quantos usuários simultâneos a máquina suporta sem ultrapassar esses limites; a curva mostra a parcela de solicitações conformes (“realização”) à medida que a carga aumenta.

Micro-benchmark serverless llama.cpp: pp = processamento imediato (pré-preenchimento, tokens/s), tg = geração de texto (tokens/s). O sufixo _d4096 significa que o contexto já contém 4.096 tokens, o que retarda ambas as fases.

Pontuação (%) em tarefas padrão: raciocínio matemático (GSM8K), conhecimento e raciocínio (MMLU-Pro), ciências, codificação, compreensão de imagens. Um modelo quantificado (NVFP4, FP8, GGUF, etc.) é mais rápido e compacto, mas pode perder precisão: quando sua versão BF16 também é avaliada, a diferença (“delta”) ultrapassa pontos é relatado como um alerta.

O RTFx (fator de tempo real) indica quantos segundos de áudio são transcritos por segundo: 1000× significa que uma hora de áudio é processada em 3,6 s. O WER (taxa de erro de palavra,%) mede a precisão: menor = melhor.

Os modelos de incorporação transformam o texto em um vetor para pesquisa semântica (RAG). Medimos o número de solicitações por segundo de acordo com o comprimento do texto (256, 512 ou 2.048 tokens) e simultaneidade, latência p99 e qualidade da pesquisa (pontuação média do MTEB, maior = melhor).

Os mesmos indicadores dos LLMs, mas as solicitações contêm uma imagem (512 px ou 1024 px) ou um vídeo. O processamento de imagens aumenta especialmente o TTFT.

Número de quadros de 1.024 x 1.024 (30 etapas) produzidos por segundo com base no tamanho do lote, na latência por quadro, na memória da GPU no pico e na duração por clipe para geração de vídeo.

Latência antes da primeira resposta de áudio de acordo com o número de conversas simultâneas (trabalhadores). Se o servidor não puder ser iniciado (esperado na arquitetura aarch64 para determinadas dependências), a tabela go/no-go indica a etapa de bloqueio.

Matrix-Game 4.0 (Skywork) substitui a renderização gráfica de um jogo real por uma modelo de streaming de vídeo : o jogo nativo roda em low-poly, e a GPU “repinta” cada quadro em tempo real a partir dessa visualização e dos controles do jogador. Duas cenas são medidas: Doom (Egito Antigo, tiro em primeira pessoa) e kart (corrida, corrida). Três taxas de quadros por segundo: Modelo FPS = imagens produzidas apenas pelo modelo, FPS on-line = imagens realmente veiculadas ao cliente durante a sessão (o que o jogador vê), FPS codificado = saída de imagens do codificador de vídeo H.264. Observamos também o atraso antes da primeira imagem, inicialização do servidor, latência por bloco de imagem (pedaço) e VRAM no pico. O clipe mostra visão dupla baixo poli | renderizado julgar a olho nu. Uma renderização de software OpenGL (sem NVIDIA EGL) é relatada: seus FPS não são representativos.

Cada modelo recebe as mesmas instruções e deve produzir, na temperatura 0, sete jogos HTML5 completos em um único arquivo (snake, breakout, flappy, invaders, tetris, doom, kart), de acordo com diversas modas : habilidades (uma única resposta, com fichas de melhores práticas idênticas para todos os modelos), agente (o agente pi escreve o arquivo, testa-o e corrige-o, com as mesmas habilidades) e possivelmente tiro único (somente depósito). As legendas dizem “modelo · moda”. O arquivo gerado é carregado em um Chromium sem tela por 15 s com chaves injetadas: verificamos se assume o comando, começa e corre sem travar, contamos imagens renderizadas e erros de console. Um modelo de juiz local pontua então o código em 10 (completude em relação às instruções, jogabilidade, qualidade do código); a pontuação geral é a média. A menção “autoavaliação” indica que o juiz é o modelo avaliado, o que pode enviesar a pontuação. Clique em uma miniatura para reproduzir ao jogo gerado e compare os modelos manualmente.

A diarização divide uma gravação em turnos de fala atribuídos a cada locutor. O DER (taxa de erro de diarização, %) é a porção de tempo atribuída incorretamente: menor = melhor. Ele se divide em palavras faltou, falso alarme (fala detectada incorretamente) e confusão entre alto-falantes. O RTFx indica quantos segundos de áudio são processados por segundo; na moda streaming, também medimos a latência de processamento de cada pedaço de áudio.

Potência, temperatura e clock da GPU registrados a cada segundo durante uma medição (nvidia-smi dmon), depois, quando registrado, a atividade do processador e da memória da Estação a cada 2 s (CPU total, núcleos ocupados, contêineres de servidor e cliente, memória usada). O gráfico de dispersão relaciona potência média e rendimento para estimar a eficiência energética (tokens por segundo e por watt).

Cada linha é um registro JSON. Clique em um cabeçalho para classificar, toque para filtrar e exporte para CSV. Medições com falha exibem sua mensagem de erro ao passar o mouse.