O que 2.122 tokens por segundo revelam — e o que deixam de fora

Em 27 de setembro, a NaiveAI publicou seu artigo técnico sobre o Naive-N0.5-Flash. Segundo a empresa, o NaiveRT, otimizado para decodificação de fluxo único nos rollouts de aprendizado por reforço, chega a 2.122 tokens por segundo usando um modelo de rascunho DFlash fundido para decodificação especulativa. As condições declaradas importam: oito GPUs, o melhor intervalo de um segundo entre 41 solicitações HTML/SVG, o modo de pensamento desativado e a etapa de pré-preenchimento (prefill) excluída. Trata-se de uma medição da própria desenvolvedora, que a SlateMoth não reproduziu de forma independente. [1]

A pergunta útil é que parte da espera real de uma pessoa essa medição cobre. Uma taxa máxima de decodificação descreve apenas parte de uma solicitação. Ela não responde diretamente quanto tempo leva para concluir uma alteração de código, um relatório ou uma tarefa de agente. Para equipes que avaliam modelos, separar essas perguntas ajuda a julgar com justiça um resultado de engenharia promissor.

Sugerimos três relógios. O primeiro vai do envio da solicitação até a primeira saída utilizável e inclui a espera e o processamento da entrada percebidos por quem fez a solicitação. O segundo mede o tempo restante de geração, da primeira saída até a conclusão da resposta. O terceiro acompanha a tarefa inteira, do envio à aceitação, incluindo chamadas de ferramentas, testes e novas tentativas necessárias. Melhorar uma parte desse percurso não significa reduzir o tempo total na mesma proporção.

Considere uma tarefa hipotética de edição de código: carregar o projeto e chegar à primeira saída leva 12 segundos, a geração leva 8 segundos e os testes levam 40 segundos. Mesmo que a geração fique quatro vezes mais rápida, o total cai apenas de 60 para 54 segundos, uma economia de 10%. Esses números são ilustrativos, não medições da NaiveAI. A lição é medir onde o tempo é gasto antes de projetar um ganho de velocidade anunciado sobre todo o fluxo de trabalho.

Um pico breve também não mostra se a geração mantém essa velocidade ao longo de uma resposta extensa ou sob solicitações simultâneas. Peça tempos de resposta completos e distribuições de latência sob a carga esperada pela sua equipe. Distinga a velocidade de uma única solicitação da capacidade agregada: atender mais solicitações por segundo e concluir mais cedo a tarefa de uma pessoa resolvem problemas diferentes.

A ficha do modelo lista 309 bilhões de parâmetros no total e 15,5 bilhões de parâmetros ativos. As orientações para implantação em FP8 dizem que os pesos ocupam aproximadamente 315 GB e que a inferência exige memória adicional de GPU. Elas também afirmam que o projeto de atenção esparsa mantém todo o cache KV. Esses dados evitam uma interpretação equivocada comum: a quantidade de parâmetros ativos não quer dizer que o modelo completo caiba na memória necessária para um modelo denso desse tamanho. [2]

Para tomar uma decisão de implantação, registre os pesos e a precisão efetivamente usados, o hardware e suas interconexões, a versão do ambiente de execução, o tamanho do contexto e as solicitações simultâneas. Depois, meça o uso de memória e as falhas nessa configuração. Um caminho de cálculo com menos parâmetros ativos pode ser valioso sem tornar toda implantação pequena. Quantização, transferência de componentes para outra memória ou outro mecanismo de serviço devem ser avaliados como configurações separadas; seu desempenho não deve herdar o pico original.

Há um limite da publicação que precisa ficar claro. O artigo técnico descreve o NaiveRT como código aberto, mas também diz que o conteúdo do código-fonte mencionado estará disponível até 12 de outubro. Em nossa verificação de 28 de setembro, o repositório do NaiveRT indicado no artigo retornou 404. Por isso, não pudemos examinar naquele endereço o ambiente de execução nem seus scripts de teste de desempenho. Isso não demonstra que o resultado seja falso nem que os pesos do modelo não estejam disponíveis. Apenas limita o que podemos verificar hoje. [1] [3]

Até que seja possível examinar os materiais relevantes e repetir o experimento, trate a velocidade como um resultado informado pela desenvolvedora sob condições específicas. Desativar o pensamento nesse teste de velocidade também não comprova o desempenho em trabalhos que exigem raciocínio prolongado. Qualidade e tempo devem ser medidos juntos no modo realmente usado para a tarefa.

Comece com um pequeno conjunto de tarefas representativas e defina o sucesso antes de executá-las. Para uma alteração de código, isso pode significar que o comportamento solicitado funciona, os testes de regressão passam e nenhum arquivo alheio à tarefa é modificado. Para um documento, pode significar que os fatos necessários estão presentes e as citações os sustentam. Meça a tentativa inteira, incluindo falhas e retrabalho, em vez de guardar apenas a conclusão mais impressionante.

Mantenha fixos o conjunto de tarefas, as permissões das ferramentas e os critérios de aceitação ao mudar o modelo ou a configuração do serviço. Registre o tempo até a primeira saída, o tempo total decorrido, a taxa de tarefas aceitas e o custo por tarefa aceita. Inclua entradas curtas e longas, concorrência habitual e execuções repetidas. Uma amostra rápida pode justificar uma investigação mais aprofundada; ela não descreve a experiência de todos os usuários.

A melhor oportunidade para uma decodificação mais rápida está em cargas de trabalho nas quais a geração realmente domina a espera. Uma geração longa e principalmente sequencial pode se beneficiar muito, se a qualidade for mantida. Um fluxo dominado por busca de informações, ferramentas lentas ou revisão humana pode se beneficiar menos. Nenhuma dessas observações diminui o trabalho de engenharia; elas mostram onde a equipe deve testá-lo primeiro.

O relatório da NaiveAI oferece às equipes uma hipótese concreta que vale testar: outro projeto de inferência pode encurtar trabalhos dominados pela geração. Lemos a metodologia publicada, mas não executamos o modelo nem reproduzimos o pico. As próximas evidências a procurar são código acessível do ambiente de execução, uma configuração reproduzível e resultados em tarefas representativas. Uma decisão útil de adoção depende da rapidez com que o sistema entrega um resultado aceitável para a sua carga de trabalho.