Benchmark do Qwen3.8 Basalt registra 153 tokens por segundo com 16GB de VRAM

Resultados do benchmark do Qwen3.8 Basalt publicados em 25 de outubro registram 153 tokens por segundo em uma RTX 5080, apesar do limite de 16GB de memória gráfica. A estação de trabalho também utilizou 54,1GB de memória do sistema. A manchete da publicação enfatiza geração acima de 250 tokens por segundo, mas esse número descreve um pico breve, e não uma produção sustentada.

A distinção importa para desenvolvedores que consideram assistentes locais de programação. Segundo o autor da publicação, a sessão processou 103 solicitações, enquanto um teste separado avaliou prompts inéditos em diferentes tamanhos de contexto. Essas cargas de trabalho fornecem indícios úteis sobre capacidade de resposta, embora nenhuma estabeleça precisão de programação ou desempenho verificado de forma independente.

A tensão central diz respeito a acomodar um modelo grande em uma estação de trabalho preservando velocidade útil e resultados aceitáveis. Basalt, um mecanismo especializado de inferência, disputa essa carga de trabalho com Strata e alternativas mais amplas, como llama.cpp. Este relatório justifica uma investigação mais detalhada dessa abordagem, em vez de uma alegação geral de que a capacidade de memória gráfica deixou de importar.

O benchmark do Qwen3.8 Basalt separa picos de velocidade sustentada

Os números de geração mais úteis são as médias relatadas: 153,0 tokens por segundo durante a programação e 154,9 na varredura de contexto.

Um token é uma unidade de texto processada ou produzida por um modelo de linguagem. Tokens por segundo medem a taxa de processamento, embora não meçam diretamente se o código gerado funciona. A distinção feita pelo autor entre produção média e de pico merece acompanhar todos os resumos desses resultados.

O benchmark da RTX 5080 identifica a configuração do modelo como Qwen3.8-Flash-Next IQ3_S. IQ3_S é um formato de quantização, o que significa que representa os pesos do modelo com precisão numérica reduzida. Essa configuração faz parte da identidade do resultado, e não é um detalhe intercambiável.

A estação de trabalho relatada combinava uma RTX 5080 com um processador Core Ultra 9 285K e 62GB de memória DDR5-6800. O consumo de memória gráfica chegou a 15,7GB. O mecanismo teria ocupado 54,1GB de memória do sistema, deixando 5,2GB livres durante a programação e 5,1GB durante a varredura.

A sessão de programação usou opencode, uma interface de agente de programação, em 103 solicitações e alcançou aproximadamente 130.000 tokens de contexto. Contexto é a informação disponível para o modelo ao produzir uma resposta. A fonte relata uma capacidade configurada de aproximadamente 262.000 tokens, superior à profundidade observada na sessão de programação.

A geração teve média de 153,0 tokens por segundo considerando os tokens gerados e o tempo de decodificação, segundo o autor. Tempo de decodificação é o período gasto para produzir tokens de saída. O pico relatado de 262 tokens por segundo captura o melhor segundo individual, e não uma solicitação ou sessão completa.

A varredura separada usou prompts inéditos entre aproximadamente 15.000 e 207.000 tokens. Sua média de geração alcançou 154,9 tokens por segundo, com pico de 186,6. O autor descreve essas medições como médias por solicitação, usando respostas de 384 tokens, temperatura de amostragem de 0,7 e duas execuções por profundidade.

Essas definições evitam uma interpretação enganosa. Um máximo de um único segundo e uma média por solicitação descrevem observações diferentes. Nenhum deve substituir o outro simplesmente porque ambos usam tokens por segundo.

Os números sustentados também tornam o relatório mais interessante do que sua manchete isoladamente sugere. Um fluxo de trabalho de programação precisa de respostas consistentes em interações repetidas. Uma breve explosão de velocidade ajuda a caracterizar o sistema, mas os desenvolvedores acabam vivenciando solicitações completas, interrupções, execução de ferramentas e correções.

Essas continuam sendo medições autodeclaradas. As evidências disponíveis estabelecem o que o autor relatou e explicam as categorias de medição. Elas não estabelecem que outra estação de trabalho reproduzirá os resultados nem que todas as solicitações mantiveram a média agregada.

O reuso de cache muda o significado do tempo de resposta

O início mediano de resposta de 0,2 segundo relatado pertence a uma sessão com 99,5% de reuso do cache de tokens de prompt.

O cache de prompts reutiliza informações calculadas anteriormente a partir de uma entrada anterior, em vez de processar novamente o mesmo material. Esse comportamento importa em sessões de programação porque solicitações sucessivas frequentemente compartilham histórico de conversa, material do repositório e instruções. Reutilizar esse trabalho pode fazer uma sessão em andamento parecer substancialmente mais responsiva.

O autor relata que 99,5% dos tokens de prompt vieram do cache de prompts. O tempo mediano até o primeiro token alcançou 0,2 segundo. O tempo até o primeiro token mede o atraso antes do início da saída, e não o tempo necessário para concluir uma resposta.

Consideradas em conjunto, essas medições descrevem uma carga de trabalho favorável de interações repetidas. Elas não mostram que o mecanismo consegue ler um prompt longo e totalmente desconhecido de um repositório e começar a responder com o mesmo atraso. Uma solicitação inédita precisa ser avaliada separadamente.

A fonte aborda parcialmente essa distinção por meio de suas medições de processamento sem cache. Para a sessão de programação, o processamento de prompts teve média de 5.011 tokens por segundo e pico de 5.118. O autor afirma que esses números representam duas leituras substanciais sem cache, contendo aproximadamente 10.700 e 8.000 novos tokens.

O processamento de prompts é a computação necessária para ingerir uma entrada antes de gerar uma resposta. Sua taxa de processamento difere da taxa de geração porque o modelo realiza trabalhos diferentes nessas etapas. Combiná-las em uma única alegação de velocidade oculta informações de que os leitores precisam.

A varredura de prompts inéditos relatou taxa média de processamento de prompts de 5.475 tokens por segundo, com pico de 5.662. Isso fornece uma observação separada sobre o tratamento da entrada. Ela deve acompanhar os resultados de programação com uso intensivo de cache sempre que alguém caracterizar a capacidade de resposta do mecanismo.

Para desenvolvedores, a implicação depende de como seu trabalho acumula contexto. Um assistente que revisita repetidamente o mesmo projeto pode se beneficiar da computação retida. Um fluxo de trabalho que troca documentos com frequência ou muda de repositório apresenta uma carga diferente.

Considere um agente que lê um projeto, propõe uma edição, recebe um erro de compilação e revisa o patch. Grande parte das informações ao redor continua relevante entre essas etapas. Portanto, o comportamento do cache pode afetar a experiência mesmo quando a taxa de geração subjacente do modelo permanece inalterada.

Agora considere um analista abrindo coleções de documentos não relacionadas ao longo do dia. O material repetido pode ser menos extenso. Aplicar o atraso mediano de resposta da sessão de programação a esse fluxo de trabalho exigiria evidências que a publicação não fornece.

O cache, portanto, é uma parte substancial do resultado relatado. Ele explica por que os usuários devem examinar seus próprios padrões de solicitação antes de tratar um benchmark como previsão. A questão decisiva é quanta computação a aplicação deles realmente consegue reutilizar.

A memória do sistema concentra a contrapartida da estação de trabalho

Uma placa gráfica de 16GB sustenta essa configuração, mas a carga de trabalho relatada também depende de 54,1GB de memória do sistema.

VRAM é a memória conectada ao processador gráfico, enquanto a RAM do sistema atende ao computador de forma mais ampla. O relatório usa ambas. Descrever o resultado apenas pela placa gráfica subestima os recursos da máquina envolvidos e obscurece a restrição prática para potenciais usuários.

O projeto especializado de memória descreve Basalt como um fork do Strata voltado para hardware NVIDIA Blackwell. Ele executa um modelo de mistura de especialistas, que seleciona componentes especializados do modelo para a computação. Especialistas que excedem a capacidade da memória gráfica podem residir na RAM do sistema.

Esse projeto explica a abordagem geral sem validar independentemente este benchmark específico. A documentação do projeto estabelece que o uso da memória do sistema é intencional. As medições do Reddit fornecem a velocidade e o consumo de memória relatados para a estação de trabalho especificada.

A pressão prática recai sobre desenvolvedores que decidem se sua máquina atual consegue suportar um assistente local. A capacidade de memória gráfica, sozinha, oferece uma resposta incompleta. Memória do sistema disponível, outros aplicativos e os requisitos de contexto da carga de trabalho pertencem à mesma avaliação.

Os números de memória livre relatados merecem atenção especial. Deixar 5,2GB disponíveis durante a programação não comprova instabilidade, mas descreve pouca capacidade de sobra nessa máquina de teste. Um editor, navegador, processo de compilação ou outro serviço local introduz demanda adicional.

Isso não significa que toda estação de trabalho comparável falhará no desenvolvimento cotidiano. Significa que o benchmark não pode garantir multitarefa confortável. Os usuários precisam de medições realizadas enquanto seu ambiente real de desenvolvimento está em execução, e não enquanto o mecanismo de inferência opera isoladamente.

O mesmo raciocínio se aplica à leitura de memória gráfica. O uso relatado de 15,7GB se aproxima da capacidade de 16GB da placa mencionada. Essa observação deve desencorajar suposições de ampla margem disponível para cargas gráficas não relacionadas ou configurações diferentes do mecanismo.

É aqui que o apelo da manchete encontra a contrapartida operacional. O relatório descreve uma estratégia de alocação que faz a carga de trabalho caber nos recursos disponíveis. Ele não descreve um modelo operando inteiramente dentro de um orçamento modesto de memória gráfica.

Uma decisão de compra deve, portanto, começar pela estação de trabalho completa. Adicionar uma placa gráfica compatível a uma máquina limitada em outros aspectos não recria o ambiente relatado. Tampouco igualar a capacidade de memória necessariamente reproduz o comportamento do processador, as configurações de software ou a taxa de processamento sustentada.

Aplicações intensivas em conhecimento acrescentam outra consideração: organizar o material de origem permanece separado da execução do modelo. Uma base de conhecimento pesquisável trata do acesso a documentos, enquanto este benchmark diz respeito à computação após as entradas chegarem a um mecanismo.

A conclusão útil é concreta. Desenvolvedores que avaliam a configuração devem reservar memória tanto para a inferência quanto para as ferramentas ao redor. A velocidade relatada torna essa avaliação válida, mas a exigência de memória do sistema permanece central para o resultado.

Strata e llama.cpp precisam de comparações equivalentes

Este relatório de estação de trabalho não estabelece um ranking de desempenho controlado entre Basalt, Strata e llama.cpp.

O título menciona Strata e Basalt juntos, mas a descrição da carga de trabalho fornecida identifica Basalt como o mecanismo utilizado. Os leitores devem preservar essa distinção. Resultados de um fork não devem se transformar automaticamente em alegações de desempenho para seu projeto-pai.

Strata fornece a linhagem por trás do Basalt, enquanto llama.cpp oferece outro ponto de referência relevante para inferência local. Sua presença estabelece o contexto competitivo. Ela não justifica declarar um vencedor sem arquivos de modelo, configurações, hardware e sequências de solicitações equivalentes.

A documentação de benchmark de inferência separa o processamento de prompts da geração de texto e oferece suporte a testes em profundidades de contexto especificadas. Ela também registra medições repetidas. Essas categorias ilustram por que uma comparação exige mais do que colocar lado a lado números de taxa de processamento destacados em manchetes.

Uma comparação equivalente manteria a carga de trabalho reconhecível entre os mecanismos. Os mesmos prompts, comprimentos de resposta, representação do modelo e condições de contexto deveriam fundamentar o exercício. Caso contrário, uma aparente vantagem de software pode incluir diferenças em outros pontos da configuração.

As condições de cache merecem tratamento igual. Comparar uma sessão de programação já aquecida com um prompt desconhecido desfavorece a segunda antes do início da geração. Ambos os cenários são úteis, mas respondem a questões operacionais diferentes e devem aparecer como resultados separados.

A configuração de hardware também precisa permanecer fixa ao atribuir diferenças a um mecanismo. A placa mais rápida ou o maior orçamento de memória de outro usuário introduz uma variável adicional. Essas informações podem orientar a exploração, sem provar o que o software por si só oferece.

O comportamento de saída apresenta outra complicação. A decodificação especulativa usa tokens de rascunho que um modelo verifica antes de aceitar a saída. Qualquer comparação que envolva essa aceleração deve divulgar suas configurações e verificar qual comportamento a configuração medida preserva.

O padrão relevante é a transparência sobre a execução exata. Os leitores devem conseguir identificar o artefato do modelo, a revisão do software, a configuração e o método de medição. Um nome conhecido de modelo não garante representações numéricas idênticas nem saídas idênticas.

A mesma cautela se aplica a declarações sobre substituir serviços hospedados de programação. Este relatório mede o comportamento de inferência local durante uma sessão de programação. Ele não fornece uma avaliação equivalente de tarefas concluídas, intervenção de desenvolvedores, confiabilidade do serviço ou esforço de integração em comparação com uma alternativa hospedada.

Para os responsáveis pela manutenção dos mecanismos, a pressão competitiva ainda é real em um sentido mais restrito. Um relatório promissor sobre uma estação de trabalho dá aos usuários um motivo para investigar implementações especializadas. A resposta que importa é evidência reproduzível mostrando onde cada mecanismo apresenta bom desempenho.

Para desenvolvedores, uma lista curta é mais defensável do que um ranking. Basalt merece testes em hardware compatível porque as taxas sustentadas relatadas são relevantes para o trabalho interativo. Strata e llama.cpp continuam sendo candidatos à comparação cujo comportamento exige medição nas mesmas condições.

A Geração Rápida Não Comprova a Qualidade de Programação

O elo ausente é o desempenho em tarefas: o relatório mede a velocidade de saída sem estabelecer quão confiavelmente o código gerado resolve problemas.

Uma sessão de programação oferece uma carga de trabalho mais reconhecível do que a geração isolada de texto. Ela mostra que uma interface de agente emitiu solicitações repetidas. No entanto, a contagem de solicitações por si só não revela edições bem-sucedidas, testes aprovados, novas tentativas desnecessárias ou correções humanas.

Essa distinção se torna especialmente importante com a quantização. Reduzir a precisão numérica altera a representação do modelo que está sendo executada. Uma configuração mais rápida ou menor ainda precisa ser avaliada nas tarefas que os usuários pretendem atribuir.

A avaliação publicada do modelo quantizado oferece evidência limitada de qualidade usando trechos de texto e uma referência de maior precisão. Essa comparação ajuda a caracterizar o comportamento do modelo. Ela não estabelece precisão em reparos de repositórios, uso confiável de ferramentas ou programação bem-sucedida com contexto longo.

O contexto longo cria uma lacuna de verificação relacionada. Um sistema pode aceitar um prompt extenso sem aplicar de forma confiável todos os detalhes relevantes. A capacidade de processamento e a precisão de recuperação dentro dessa entrada são propriedades diferentes, mesmo quando ambas afetam a mesma experiência do usuário.

Portanto, a varredura de contexto sustenta uma interpretação limitada. Ela relata throughput em prompts novos de diferentes extensões. Não estabelece que o modelo localizou de forma consistente um requisito oculto, conciliou instruções conflitantes ou preservou restrições do projeto ao editar código.

As taxas agregadas de geração também deixam pouco clara a distribuição das experiências. Uma média pode resumir uma sessão enquanto oculta solicitações mais lentas. Um desenvolvedor aguardando uma edição difícil pode se importar mais com esses atrasos do que com o melhor pico.

A mesma limitação se aplica ao valor mediano de início de resposta. Uma mediana descreve a observação central. Ela não estabelece as esperas mais longas, o comportamento após uma falha de cache ou o tempo necessário para receber um patch completo e utilizável.

A concorrência, isto é, solicitações simultâneas, acrescenta outro limite. O resumo identifica concorrência de um. Isso torna o resultado relevante para um fluxo individual, mas não fornece base para estimar a capacidade de uma equipe compartilhada ou o desempenho sob solicitações sobrepostas de agentes.

Essas lacunas devem orientar a interpretação sem apagar a realização relatada. A fonte fornece definições explícitas de medição e separa os tipos de carga de trabalho. Esses detalhes tornam as alegações mais avaliáveis do que uma captura de tela sem explicação que mostra apenas uma velocidade máxima.

A reprodução independente deve acrescentar resultados de tarefas às categorias de throughput existentes. Uma avaliação útil de programação registraria se os testes são aprovados, se as alterações atendem à solicitação e com que frequência uma pessoa intervém. Ela deve preservar as falhas, em vez de relatar apenas execuções bem-sucedidas.

Para o benchmark Qwen3.8 Basalt, a questão não resolvida é se a responsividade relatada acompanha um trabalho confiável. Até que apareçam evidências equivalentes sobre tarefas, a velocidade continua sendo evidência sobre execução, e não evidência de que a configuração oferece um assistente de programação melhor.

Três Sinais Determinarão Até Onde o Resultado Chega

As próximas evidências devem estabelecer reprodutibilidade, confiabilidade de programação e desempenho sob condições operacionais menos favoráveis, nessa ordem.

O primeiro sinal é uma reprodução independente em uma estação de trabalho RTX 5080 comparável. A publicação útil incluiria o artefato exato do modelo, a revisão do mecanismo, a configuração, a sequência de solicitações e os registros brutos de tempo. Execuções repetidas devem distinguir sessões com forte uso de cache de entradas novas.

Uma reprodução próxima reforçaria o argumento de que essa configuração oferece uma opção repetível para desenvolvedores individuais. Uma diferença substancial exigiria investigação antes de atribuí-la ao hardware, ao software ou à carga de trabalho. Qualquer um dos resultados melhoraria as evidências disponíveis aos usuários.

A reprodução deve manter as distinções de medição originais. A geração média por sessão, a geração média por solicitação e os picos de um único segundo devem permanecer separados. Igualar apenas o maior pico observado deixaria sem resposta a alegação mais importante sobre desempenho sustentado.

O segundo sinal é uma avaliação de programação usando a mesma configuração quantizada. Seu valor viria de tarefas concluídas e correções registradas, em vez de outro gráfico de velocidade de geração. A avaliação deve incluir o contexto do projeto de que um agente realmente precisa.

Resultados sólidos em tarefas tornariam o relatório de throughput mais relevante para o desenvolvimento de software. Falhas frequentes reduziriam seu apelo, mesmo que a geração permanecesse rápida. Produzir mais depressa um patch inutilizável não reduz o trabalho necessário para concluir uma tarefa.

O terceiro sinal é o desempenho sob um conjunto mais amplo de condições operacionais. Entre as evidências relevantes estão prompts longos e desconhecidos, saídas mais extensas, aplicações comuns de desenvolvimento executadas junto com a inferência e solicitações sobrepostas. Cada condição testa se a experiência relatada resiste a uma mudança na carga de trabalho.

Um comportamento estável reforçaria o argumento para usar a configuração além de uma sessão individual cuidadosamente observada. Pressão de memória, esperas mais longas ou saída degradada identificariam seus limites práticos. Esses limites ajudariam os usuários a selecionar cargas de trabalho, em vez de descartar o mecanismo de imediato.

Nenhum desses sinais exige inventar uma data de lançamento ou prever um vencedor inevitável. Eles são formas concretas de evidência que responsáveis pela manutenção e usuários independentes podem publicar nos próximos meses. A publicação atual oferece um ponto de partida útil para esse trabalho.

A implicação mais ampla permanece específica. Uma estação de trabalho com 16GB de memória gráfica teria sustentado a geração interativa ao também comprometer uma quantidade substancial de memória do sistema. Isso torna a avaliação do sistema completo mais relevante do que julgar a inferência local apenas pela capacidade de memória gráfica.

Antes de mudar sua configuração, compare o benchmark Qwen3.8 Basalt com uma sessão extraída do seu próprio trabalho. Preserve os prompts, observe o que o cache reutiliza e registre se as edições resultantes passam nas suas verificações. Inclua os aplicativos que você normalmente mantém abertos, pois a máquina relatada tinha pouca memória livre do sistema. Mantenha o atraso até o início da resposta separado do tempo de conclusão e compare saída sustentada com saída sustentada. A decisão deve depender de trabalho útil concluído nas suas condições. Uma execução reproduzível consegue entregar alterações corretas, esperas aceitáveis e memória livre suficiente para o restante do seu ambiente de desenvolvimento?