O gráfico viral coroa o Mac, a tabela coroa o Spark: medi 43 mil chamadas e o vencedor não é máquina nenhuma

A Apple anunciou hoje o Mac Studio com M5 Ultra: 256 GB de memória unificada, 1,2 TB/s de banda, US$ 9.499. Em poucas horas ele já ocupava o primeiro lugar de um gráfico, e uma linha de uma tabela, que circulam como comparação de "valor por dólar" para rodar IA em casa — contra a RTX 5090, a RTX PRO 6000 e o DGX Spark da NVIDIA. O gráfico coroa o Mac; a tabela coroa o Spark.

Fui conferir os dois, e a primeira versão da minha conta dizia o que eu esperava: nenhuma dessas máquinas se paga contra a API do mesmo modelo, porque uma pessoa sozinha usa a máquina uma fração de 1 % do tempo. Aí o autor deste site fez a pergunta certa: "1 % de uso não me parece usual; se for, tem de ser provado". Fui provar. O 1 % não descreve ninguém — e o que decide quem ganha não é a máquina. É a regra de cobrança de uma coisa que quase ninguém olha: a releitura.

O gráfico viral mede a coisa errada, e os preços dele já morreram

O gráfico "Memory Performance Value per Dollar" faz uma conta simples: memória (GB) vezes banda (GB/s), dividido pelo preço, normalizado no DGX Spark. Refiz as sete linhas. A aritmética confere, 7 de 7. O problema não é a conta; é o que a conta multiplica.

Memória é um estoque: ou o modelo cabe, ou não cabe. Ter 256 GB quando o modelo ocupa 63 GB não gera um token a mais do que ter 96 GB. Banda é uma vazão: é ela, e só ela, que fixa o teto de velocidade de geração. Multiplicar os dois dá "GB² por segundo por dólar" — uma unidade que não corresponde a nada físico. É avaliar carro por tamanho do tanque vezes velocidade máxima: um caminhão-tanque ganha da Ferrari, e a conta não erra em lugar nenhum.

O próprio gráfico admite, no rodapé: "this is a memory-hosting value metric, not a direct tokens/sec benchmark". Mas o título diz "performance", o corpo é um pódio de 1 a 7, e ninguém lê o rodapé de um pódio.

E há um segundo defeito, independente do primeiro: os preços.

A coluna chama-se "preço" e as duas linhas chamam-se "PC", mas só a 5090 pagou o computador em volta. A placa mais cara da lista é a única que entrou nua. E o Spark — que é a régua do gráfico inteiro, "normalizado a 1,00x" — entrou com um preço que a NVIDIA reajustou em fevereiro. Corrigindo só os preços e mantendo a métrica deles intacta, o Spark cai do sexto para o último lugar, e a 5090 quase encosta na PRO 6000 (1,31x contra 1,32x) quando as duas pagam hospedeiro.

O pódio que a casa publica separa o que o gráfico fundiu:

Repare que o pódio muda conforme a régua. Em capacidade por dólar o Spark ganha por um fio do Mac (27,2 contra 27,0 GB por mil dólares) e as duas NVIDIA avulsas ficam cinco vezes atrás. Em banda por dólar a 5090 ganha com folga — e o Spark é o último. Em tokens por segundo medidos, a única das três réguas que é "tokens por dólar" de verdade, o Spark volta a ganhar; a 5090 nem entra, porque não roda o modelo, e o Mac fica fora por falta de medição. A mesma máquina é primeira, última e primeira de novo. Quem funde as três réguas num pódio só escolheu o vencedor antes de medir.

Os três portões

Antes de qualquer conta de dólar, três perguntas em ordem, e uma máquina que reprova numa não passa para a seguinte.

1. Cabe?

O modelo aberto que faz sentido comparar é o gpt-oss-120b: 116,8 bilhões de parâmetros, dos quais 5,1 bilhões trabalham por token (é um modelo de "especialistas", como a brigada de cozinha que expliquei no artigo sobre memória), e que é servido por API a US$ 0,15 por milhão de tokens de entrada e US$ 0,60 por milhão de saída. Quantizado no formato em que ele foi publicado, ocupa 62,8 GB.

A RTX 5090 tem 32 GB. Ela sai aqui, nomeada — não porque seja ruim, mas porque não roda justamente o tipo de modelo pelo qual se compra uma dessas caixas. Nas tabelas que seguem ela não aparece, e a ausência é o dado.

2. Anda?

Gerar um token exige ler os pesos que participam daquele token. Por isso a velocidade de geração tem um teto físico: banda de memória dividida por bytes lidos por token. Mas o teto é limite, não promessa — o que importa é o medido, e medido separando duas coisas que a tabela viral junta: prefill (ler o que você mandou, limitado por cálculo) e decode (escrever a resposta, limitado por banda).

Duas coisas para ler nessa tabela. A primeira: a PRO 6000 é 3,2 vezes mais rápida que o Spark em decode, e 2,8 em prefill, com 6,6 vezes a banda. A segunda: o Mac não tem número. O M5 Ultra foi anunciado hoje e chega às lojas em 22 de setembro; não existe benchmark publicado. A linha dele é projeção — 1.200 GB/s divididos pelos bytes ativos do modelo, vezes a eficiência de 30 % que o M3 Ultra, o último chip Ultra medido, atinge nesse tipo de modelo. Vou marcar isso toda vez que o Mac aparecer, porque a máquina que lidera o gráfico viral é a única que ninguém mediu.

3. Compensa? — a curva que eu tinha desenhado

Numa API você paga por token. Numa máquina você paga uma vez e produz tokens até ela morrer. As duas grandezas só se comparam depois de amortizar a compra pelos tokens que ela vai gerar — e o número de tokens depende de uma variável que as tabelas virais omitem: quanto do tempo a máquina está de fato gerando.

Foi essa a primeira figura que desenhei. A 1 % de utilização — a fração que eu tinha assumido para "uma pessoa sozinha" — o Spark custa US$ 62,82 por milhão de tokens de saída contra US$ 1,05 na API, no mix de chat que essa curva usa: 60 vezes mais caro. A curva só cruza a linha da API perto de 100 %, ou seja, com a máquina gerando token 24 horas por dia, 7 dias por semana. A conclusão parecia pronta: a máquina só se paga quando você deixa de ser usuário e vira provedor.

E aí veio a pergunta: quem disse que é 1 %?

Fui procurar a fonte. Não existe. Ninguém publica quantas horas por dia uma máquina caseira gera token: o Ollama não coleta telemetria, o LM Studio coleta e não publica, e a única cifra em circulação — "2 a 5 % do tempo de relógio" — é uma estimativa de autor único, rotulada como estimativa pelo próprio autor. O 1 % era meu. Estava na minha metodologia, escrita antes dos dados, como premissa. Premissa não é prova.

Medi. O 1 % não descreve ninguém

Esta máquina roda agentes de código o dia inteiro. Cada chamada ao modelo deixa um registro de quantos tokens entraram e saíram — sem conteúdo, só a contabilidade. Escrevi um programa que lê esses registros, conta cada chamada uma vez só e soma por dia. O resultado, para a janela de 24 de julho a 25 de agosto de 2026 (33 dias de parede, 29 com atividade):

Convertendo essa carga no tempo que cada máquina levaria para produzi-la — tokens de saída divididos pela velocidade de decode, mais tokens de entrada divididos pela velocidade de prefill — sai a utilização que a carga imporia a cada uma. Não a que eu assumi; a que a carga exige.

Repare onde os pontos caíram. O 1 % que eu tinha assumido fica no meio de um vazio.

Na mesma máquina, do usuário mediano de chat ao agente de código vão 805 a 826 vezes — quase três ordens de grandeza. O 1 % fica de 27 a 85 vezes acima de quem conversa com um chatbot e de 10 a 30 vezes abaixo de quem roda agente o dia inteiro. Ele não é a média de ninguém: é o número que cai no buraco entre os dois únicos grupos que existem.

Duas ressalvas antes de seguir. Os ~1.800 tokens por dia do usuário mediano não são medição: nenhuma empresa publica tokens por pessoa, e o número é uma conta empilhada sobre uma média de mensagens e uma premissa de terceiros sobre o tamanho da resposta — vale como ordem de grandeza, nunca como dado. E os 1,35 milhão por dia medidos aqui não são um humano: são a saída de uma frota de subagentes rodando em paralelo. Um traço de produção do GitHub Copilot, com 3,2 milhões de usuários, põe um desenvolvedor humano pesado na casa de 10⁵ tokens de saída por dia; 10⁶ é volume de frota automatizada. Esta máquina está na segunda faixa, e é a carga mais intensa a que tenho acesso — o que a torna útil exatamente como teste de estresse: se nem ela paga a máquina, ninguém paga.

E quase não paga. Para empatar com a API, cada máquina precisa de uma utilização sustentada de 50 % a 60 % — de 2,24 a 8,53 milhões de tokens de saída por dia, todo dia, por três anos. A carga medida aqui é 60 % do necessário no Spark, 28 % no Mac, 16 % na PRO 6000. Mas "quase" aqui esconde a reviravolta do artigo, e ela está na última linha daquela tabela de 33 dias.

Nove de cada dez tokens que um agente processa são releitura

Volte à tabela da carga. O modelo escreveu 44,6 milhões de tokens. Leu pela primeira vez 247,7 milhões. E releu 6.374,3 milhões — tokens que já tinha lido numa chamada anterior e leu de novo na seguinte.

Isso não é desperdício; é o jeito como um agente funciona. Pense num estagiário a quem você entrega uma pasta de duzentas páginas e pede uma tarefa. Ele lê a pasta, escreve uma linha, e antes de escrever a linha seguinte relê a pasta inteira — porque a linha seguinte depende de tudo que veio antes. A cada chamada, o modelo recebe a conversa inteira desde o começo: as instruções, os arquivos abertos, o que ele mesmo escreveu. O que cresce a cada passo é o que ele lê; o que ele escreve é uma linha.

Aqui, de cada 100 tokens que entraram no modelo, 96 eram releitura. O mix entrada:saída medido é de 5,6 para 1 contando só o que é novo, e de 148,6 para 1 contando tudo que o modelo viu. Não é 3:1, o mix de chat que quase toda comparação assume; não é 10:1, o que se costuma chamar de "mix de agente". É duas ordens de grandeza a favor da entrada.

Não é peculiaridade desta máquina. O único traço de produção em escala que existe — o do GitHub Copilot, publicado em agosto (3,2 milhões de usuários, uma semana, stack independente do que uso aqui) — mede a mesma coisa: razão entrada:saída mediana acima de 275 para 1, com 95,4 % do prompt vindo de cache. Duas confirmações de caso, ambas com o Claude Code: a migração do Bun de Zig para Rust (64 agentes, 11 dias, 92,4 % de releitura) e uma sessão de exemplo na documentação da Anthropic (99,4 % — é uma sessão de exemplo, não uma população; entra aqui como ilustração). Quatro medições, quatro stacks ou casos diferentes, todas acima de 90 %.

Nove de cada dez tokens que um agente de código processa são releitura. Guarde esse número: é ele que a comparação de tokens por dólar não vê.

Quem paga a releitura decide o vencedor

Agora a pergunta que a tabela viral não faz. Um provedor de API cobra a releitura — mas cobra barato: no gpt-oss-120b, um token relido custa US$ 0,015 por milhão, um décimo do token novo, porque o provedor guarda em memória o que já processou (o "cache") e não refaz a conta. A máquina local relê de graça, se o resultado da leitura anterior ainda estiver na memória dela quando a chamada seguinte chegar. Se não estiver, ela reprocessa tudo, e paga em tempo.

Ou seja: a mesma carga tem três preços, conforme a regra que se aplica à releitura. Coloquei a carga de 33 dias, projetada plana por três anos, contra o preço de compra de cada máquina (menos 30 % de valor residual) mais a energia do tempo gerando, a US$ 0,12 por kWh — o preço dos Estados Unidos, onde a conta favorece a máquina; no Brasil ela fica ainda mais a favor da API.

O regime A não existe no mercado — nenhum provedor isenta a releitura — e está aí só como controle: é o que a comparação viral faz sem dizer, quando compara o decode local com o preço de saída da API. O regime D também não é o preço de um provedor nomeado: é o limite superior, "e se a releitura custasse o mesmo que leitura nova?". A tabela de preços de um dos provedores lista o cache com um travessão, e não fui atrás de saber se o travessão significa "grátis" ou "não oferecemos"; por isso D entra como sensibilidade declarada, não como fatura.

O garfo real é B contra C, e ele é o mesmo hardware:

Trocar a regra de cobrança da releitura move o lado da API 16 vezes (de US$ 2.120 a US$ 33.847). Trocar de máquina move o lado do hardware 3,6 vezes (de US$ 3.423 a US$ 12.431). A pergunta "qual máquina?" — a única que a tabela viral faz — é a menos importante das duas. E os 6 de cada 10 dólares da fatura de API desta carga (US$ 95,62 de US$ 159,51) são releitura: o item mais barato da tabela de preços, a US$ 0,015, é o maior da conta, porque é multiplicado por 6,4 bilhões.

É isso que eu chamo de métrica incompatível, e é o mesmo pecado do gráfico viral em outra roupa. Comparar o decode de uma máquina com o preço de saída da API — o que toda comparação de "tokens por dólar" faz — é cobrar de um lado o que se isenta do outro. Com a regra declarada, o Spark sai de "perde 1,6x" (A) para "ganha 1,5x" (B) para "não cabe no dia" (C) para "ganha 9,9x" (D). O hardware não mudou uma vez sequer.

"Reter o cache" tem um orçamento, e ele cabe apertado

O regime B, o único em que a máquina mais barata ganha, supõe que a memória da máquina guarda o resultado da leitura anterior entre uma chamada e a seguinte. Isso ocupa espaço, e dá para calcular quanto, porque a arquitetura do modelo é pública.

No gpt-oss-120b, cada token de contexto retido custa 36 KiB de memória no formato padrão do llama.cpp — metade das 36 camadas do modelo só enxerga os últimos 128 tokens e não acumula nada; as outras 18 acumulam. (Com a opção de guardar tudo em todas as camadas, 72 KiB.) Um contexto cheio, 131.072 tokens, custa 4,8 GB. Descontados os 62,8 GB do modelo e a margem de execução, no Spark sobram uns 46 GB: cerca de 10 contextos cheios retidos ao mesmo tempo.

No dia de pico desta janela (20 de agosto: 8.145 chamadas), havia 9 projetos ativos — e um projeto pode ter vários subagentes vivos ao mesmo tempo, então 9 é um piso. O orçamento de cache do Spark fecha no limite; na PRO 6000 (33 GB livres, ~4 contextos com margem) não fecha. Na prática o cache é descartado e reprocessado, e a verdade do dia de pico cai em algum lugar entre B e C — entre "ganha 1,5x" e "não cabe no dia". Quem afirma "a máquina local relê de graça" está assumindo cache infinito.

O relógio e o contexto: o único regime em que a máquina ganha, ela não aguenta

Fica o fecho de capacidade, que é o mais simples e o mais duro. O dia tem 86.400 segundos. Converti o dia mais pesado da janela no tempo que cada máquina levaria para produzi-lo, em lote 1 — uma requisição de cada vez, que é como uma pessoa usa a máquina:

No regime B, o pico cabe na PRO 6000 e no Mac; só o Spark não cabe — a única das três que ganha no preço. No regime C, não cabe em nenhuma. Nenhuma das três ganha no preço e cabe no próprio dia de pico ao mesmo tempo. E a carga aqui é concorrente — vários agentes ao mesmo tempo —, o que ajudaria o decode se a máquina servisse em lote; não ajuda o prefill, que no regime C é 82 % do tempo no Spark.

A última linha da tabela merece uma frase própria. Todas as velocidades deste artigo são de contexto curto — o melhor caso do local. A única medição de contexto longo que existe para uma dessas máquinas é a do Spark a 32 mil tokens: o decode cai de 60,57 para 40,55 tokens por segundo, o prefill de 1.956 para 1.027. Com ela, o dia de pico vai a 188 % do dia. Para a PRO 6000 e o Mac não há medição de contexto longo em fonte nenhuma; fica declarado como não medido.

E contexto longo é o que esta carga pede:

A chamada média desta carga tem 151,9 mil tokens de entrada. O gpt-oss-120b aceita 131.072. A mediana (125,3 mil) cabe por pouco; 47,8 % das chamadas não cabem, e elas carregam 74,9 % de todos os tokens de entrada. A máquina que ganha no regime B não aceita quase metade das requisições da carga em que ganha — e a metade que ela recusa é a que tem o trabalho.

Há um último dado que nenhuma conversão captura: a carga medida foi produzida por um modelo de fronteira, que nenhuma dessas máquinas roda. A conversão para o gpt-oss-120b assume que o mesmo trabalho seria feito por ele; é o melhor caso do local, e é uma suposição.

O que eu faria com isso

Não compre por economia. Nesta carga — a mais pesada a que tenho acesso —, a três anos e no melhor regime do local, o resultado é empate técnico com um hardware que não aguenta o dia de pico nem aceita a chamada média. Se a sua carga é de chat, a máquina custa dezenas de vezes a API; se é de agente, a decisão fica na mão de uma regra de cobrança que não é sua.

Compre por soberania. Dado que não sai de casa, disponibilidade sem contrato, teto de gasto que não escala com o uso. São razões boas, e nenhuma delas se mede em tokens por dólar — se a decisão é por elas, a métrica está errada, e o gráfico viral não tem como ajudar.

Meça a sua própria carga antes de qualquer tabela. O programa que produziu os números deste artigo lê os registros de uso do agente e devolve só agregados — tokens novos, relidos e escritos por dia, e a distribuição de contexto por chamada. É isso que decide em que ponto da curva você está, e ninguém pode medir por você.

Olhe a fração de releitura do seu provedor antes de olhar o preço de saída. Se 9 de cada 10 tokens são releitura, o número que importa na tabela de preços é o último, o do cache — não o primeiro.

E, se comprar, escolha pelo portão, não pelo pódio. Cabe? Anda no modelo que você vai usar, com o contexto que você vai usar? Só então: compensa? A ordem importa, e a tabela viral a inverte.

Nota de verificação. Preços e especificações das quatro máquinas foram conferidos nas páginas oficiais dos fabricantes e na NVIDIA Marketplace em 25 de agosto de 2026; os preços de API, nas páginas de preço da Together, da Fireworks e da Groq na mesma data. As velocidades medidas vêm de benchmarks públicos do llama.cpp com modelo, quantização, contexto e versão declarados; a linha do Mac M5 Ultra é projeção, marcada em toda aparição, porque não existe benchmark do chip. A carga desta máquina foi extraída por código determinístico dos registros de uso do agente, contando cada chamada uma vez e sem ler conteúdo de conversa; a medição foi encerrada às 18h21 do dia 25 de agosto, antes de eu começar a analisá-la, e os registros brutos estão sujeitos à retenção da ferramenta — uma segunda extração, feita 96 minutos depois, encontrou 2,3 % menos chamadas, e os números publicados são os dessa segunda extração, com os dois arquivos consistentes entre si. O tokenizador do modelo que produziu a carga não é o do gpt-oss-120b; a diferença é da ordem de 20 % e não muda nenhuma razão deste texto. A energia é contada só no tempo gerando; o ócio medido das máquinas somaria, em três anos ligada 24/7, US$ 69-142 no Spark e US$ 1-18 no Mac — e, na PRO 6000, US$ 54-63 só da placa, porque o hospedeiro não foi medido em ócio por ninguém. Não medi nenhuma das quatro máquinas pessoalmente. Toda conta sai dos programas do dossiê; a prosa não faz aritmética.

Fontes

• Apple — anúncio do Mac Studio com M5 Max e M5 Ultra · especificações
• NVIDIA — DGX Spark · reajuste de preço, fevereiro/2026 · RTX PRO 6000 Blackwell · RTX 5090
• Preço da RTX PRO 6000 a US$ 16.000 — Igor's Lab · Tom's Hardware
• Benchmarks — llama.cpp, discussão #16578 (DGX Spark) · llama.cpp, discussão #15396 (RTX PRO 6000, M3 Ultra) · ServeTheHome — review do DGX Spark
• Preços de API — Together.ai · Fireworks.ai · Groq
• Modelo — openai/gpt-oss-120b no Hugging Face (config.json) · llama.cpp, src/models/openai-moe.cpp
• Releitura em agentes — traço de produção do GitHub Copilot, arXiv 2608.00101 · migração do Bun de Zig para Rust, via Simon Willison
• Uso de chat por pessoa — How People Use ChatGPT (NBER w34255, OpenAI + Harvard) · Pew Research — Americans and AI 2026 (levantamento de fevereiro/2026)
• Ócio medido — Tom's Hardware, DGX Spark pós-firmware · naveen.ing, RTX PRO 6000 · Apple, relatório ambiental do Mac Studio

Preços, especificações e velocidades verificados em 25/08/2026. Os números da carga desta máquina são agregados de uso, publicados sem nenhum conteúdo de conversa. Não reverifiquei a contagem de likes das duas imagens virais.