Comprar tokens, alugar GPUs ou ter o rack?

Até há pouco tempo, alojar um modelo de fronteira por conta própria nem era uma pergunta séria. Os modelos de pesos abertos andavam uma geração atrás dos proprietários, por isso não havia conta nenhuma para fazer.

Depois a distância fechou-se. Não a zero, mas a cerca de trinta pontos de Elo. O Kimi K3 saiu com pesos abertos e está em segundo lugar na arena de código frontend, com 1 682, atrás do Claude Opus 5 Max com 1 712 e à frente de tudo o resto¹. Os pesos cabem, no papel, num único nó de oito GPUs. Podes descarregar o modelo hoje à noite, de graça.

A máquina já é outra história. Isto se tiveres capital para o investimento. E se, depois de fazeres as contas, ainda valer a pena.

Por isso modelei quatro maneiras de correr a mesma carga: um rack no teu escritório, hardware próprio numa instalação de colocation, GPUs dedicadas alugadas e APIs pagas por token. A este último chamo o contador, daqui em diante.

A resposta não é “compra o rack”. Abaixo de cerca de 44 engenheiros, o contador continua a ser o mais barato. Entre 44 e 95, mais ou menos, ganham as GPUs alugadas. Acima disso, ter o hardware começa a compensar, e aos 750 engenheiros bate o contador por cerca de seis para um.

O número que decide tudo é a utilização. Um rack comprado a três anos custa o mesmo às três da manhã, quer esteja a servir tokens quer esteja a aquecer o edifício.

O K3 é só o exemplo aqui. O mesmo método aplica-se ao que sair a seguir.

Quatro maneiras de comprar inferência

Opção	Tens	Alugas	Pagas por
Rack no escritório	GPUs, infraestrutura elétrica, refrigeração	nada	Capex, eletricidade, um eletricista, espaço, pessoas
Rack em colo (o teu hardware, o edifício de outro)	GPUs	Espaço, energia, refrigeração	Capex, aluguer do rack por kW2, pessoas
GPUs dedicadas / alugadas	nada	GPUs inteiras à hora	Horas reservadas, pessoas
O contador (API por token)	nada	nada	Tokens

À medida que desces nessa tabela, o compromisso fixo diminui e a flexibilidade aumenta. O que perdes é controlo e, a escala suficiente, a economia unitária. Descobrir onde essa troca se inverte é o exercício todo.

Antes da folha de cálculo, porém, uma pergunta mais básica: consegues mesmo pôr uma destas máquinas num escritório?

Podemos?

Na segunda temporada de Silicon Valley, os servidores do Gilfoyle ardem. A equipa empilha carga a mais no Anton, ele esgota a amperagem, faz saltar o quadro geral e pega fogo. Toda a gente se lembra disto como uma piada sobre arrogância. Aqui, vamos tratá-lo como um comentário sobre engenharia eletrotécnica.

Peço desculpa se nunca viste Silicon Valley. É um clássico moderno, à frente do seu tempo.

O K3 tem 2,8 biliões de parâmetros, 104 mil milhões ativos por token, 896 especialistas, quantizado em MXFP4 logo à saída do treino³. São 1 390GB de pesos no papel. Um nó de oito GPUs B200 dá-te 1 440GB, por isso, no papel, cabe com 50GB de folga. Os relatos sobre o checkpoint real apontam para perto de 1,56TB quando se conta tudo o que não é peso quantizado, e nesse caso já não cabe de todo. Este é o sonho molhado do r/selfhosted: o segundo melhor modelo de código do planeta, a zumbir num armário, teu.

Depois lês a ficha técnica.

Especificação, um DGX B200	Valor	O que significa num escritório
Consumo	14,3 kW4	Duas placas de indução inteiras, todos os discos, para sempre
Circuito doméstico do Reino Unido	7,4 kW	Um servidor quer dois circuitos inteiros só para ele
Calor emitido	~48 800 BTU/h	Três a quatro aparelhos de ar condicionado domésticos, ao máximo
Caudal de ar	2 145 CFM4	Não é um armário. É uma casa das máquinas
Peso	130 kg4	Antes do rack, das PDUs e da refrigeração
Dois nós por rack	2x 380V trifásico 32A4	Vais ligar a um eletricista, não comprar uma extensão

Uma incoerência que assumo: os valores de potência, peso e caudal de ar são da NVIDIA para o DGX B200, o seu aparelho integrado, enquanto os $450 000 que modelo são um preço de rua para um HGX B200 de 8 GPUs, a placa em torno da qual um OEM constrói um servidor. Um DGX custa na tabela perto de $515 000. Uso o número mais barato com o consumo da máquina mais cara, o que favorece o self-hosting no capex e o penaliza na eletricidade.

O Anton não fez saltar o quadro porque um argumentista queria um incêndio no terceiro ato. Fê-lo porque é isso que acontece quando penduras carga industrial numa instalação doméstica.

Um nó é o caso caridoso, já agora, e é caridoso de uma segunda maneira. Esses 50GB de folga não deixam nada para a KV cache, a memória de trabalho de que um modelo precisa para aguentar uma conversa longa, por isso uma implementação real em produção precisa de mais aceleradores do que isto. A Moonshot recomenda 64 ou mais⁵. São oito destas caixas, 114 quilowatts, no teu escritório. Menos uma sala de servidores do que um micro reator nuclear à espera de que alguém anuncie uma Série A à volta dele.

Modelei o nó único na mesma, porque é a coisa mais barata que poderia plausivelmente conter os pesos. Mas cuidado: não é o pior caso. O pessoal e as obras elétricas são quase fixos, por isso mais nós diluem-nos e a economia melhora. Um resultado com um nó é o teste mais duro que o self-hosting enfrenta, não o mais fácil.

Depois há o abastecimento. A alocação de Blackwell vai primeiro para os maiores compradores, por isso arranjar uma é ficar na fila atrás do Musk.

Precisas de um Gilfoyle

O Gilfoyle é o tipo dos sistemas. É dono dos racks, não confia em nada e é o único no edifício que sabe porque é que o cluster está a arder.

O que nos leva à minha ficção preferida em qualquer caso de negócio de self-hosting: uma fração de engenheiro.

Não se contrata 0,3 de uma pessoa. A função aqui corre vLLM ou SGLang em produção, sabe o que é paralelismo de especialistas, depura o NCCL às duas da manhã e mantém várias centenas de gigabytes de mixture-of-experts quentes e a servir. A Robert Half põe o engenheiro de machine learning mediano de Londres em £102 000 e o quartil superior perto de £119 000⁶. Modelei £120 000, deliberadamente uma contratação de quartil superior, porque o mediano não consegue fazer este trabalho.

Também vão ter opiniões. Sobre a tua despesa em cloud, sobre o teclado que exigem, sobre o capital devido à única pessoa no edifício que percebe a coisa de que agora todos dependem. Esse é o custo real de a correres tu, e não aparece em nenhuma ficha técnica de GPU.

Precisas de dois, porque um só é um ponto único de falha com passaporte e opiniões firmes sobre férias.

Linha	Valor (GBP)
Salário base (quartil superior)	£120 000
Multiplicador de encargos (segurança social do empregador, pensão, equipamento)	1,3
Custo total por pessoa	£156 000
Pessoas necessárias	2
Total anual	£312 000 (cerca de $396 000)

Esse número não deprecia. Não fica mais barato e não quer saber se o teu hardware está ocupado.

A carga decide mais do que o hardware

A maioria das contas de self-hosting que vi é feita contra chat, que é o pior caso possível para ter hardware e nada se parece com o que uma equipa de desenvolvimento faz o dia todo.

A programação com agentes corre a 4,17 milhões de tokens por tarefa, com uma razão entrada-saída de cerca de 153:1⁷. Nada aqui importa mais do que essa razão, exceto a utilização.

No teu próprio hardware ajuda. O prefill, a leitura do teu prompt, e o decode, a escrita da resposta, são trabalhos diferentes com custos diferentes. O vLLM regista 26 200 tokens por GPU por segundo em prefill contra 10 100 em decode⁸, por isso o prefill é duas vezes e meia mais eficiente. A programação com agentes é quase toda prefill. O trabalho da tua equipa calha ser aquilo em que as GPUs são melhores.

No contador também ajuda, porque os tokens de entrada são cinco vezes mais baratos do que os de saída.

Componente	Cálculo	$/1M tokens
Entrada sem cache	0,30 × 0,9935 × $5	1,49
Entrada em cache (leituras a 0,1×)	0,70 × 0,9935 × $5 × 0,1	0,35
Saída	0,0065 × $25	0,16
Média, 70% de acertos na cache		$2,00
Média, sem cache nenhuma	0,9935 × $5 + 0,0065 × $25	$5,13

Esses 70% são um pressuposto, não uma medição, e são o segundo número mais importante deste texto. Mais do que reduzem o contador a metade, de $5,13 para $2,00. Corta a taxa de acertos para 35% e o contador fica em $3,57, o que empurra todos os pontos de cruzamento abaixo com força para o self-hosting. Vai no sentido contrário e o contador ganha quase em todo o lado.

Duas coisas mais sobre esses $2,00 antes de confiares neles. A Anthropic cobra cerca de 1,25x a entrada para escrever uma entrada de cache, e eu contei todos os tokens sem cache como uma leitura simples. Se todos os 30% sem cache fossem escritas, o contador seria $2,37 em vez de $2,00. A verdade está algures entre os dois.

Alguém vai perguntar porque comparo o K3 em self-hosting com o Opus 5 e não com a API do próprio K3, que é mais barata a $3 e $15 por milhão, com acertos de cache a $0,30⁹, cerca de $1,20 com esta mistura de tokens. Porque, para a maioria das empresas a quem este texto se dirige, enviar tráfego de produção para uma cloud chinesa não é uma opção real, diga o que disser a tabela de preços. Isso não é um juízo técnico, é um juízo de compras, e é tomado acima da tua cabeça. A escolha realista é correr o K3 tu mesmo ou comprar o Opus 5 à Anthropic, que é o que as tabelas comparam.

É também, a propósito, o mesmo instinto que leva as pessoas a fazer self-hosting. Se te fosse indiferente onde correm os pesos, usavas a API e parava de ler.

Por isso, antes de usares seja o que for disto: vai ver a tua taxa real de acertos na cache. Importa mais do que o preço de uma GPU.

O que serve de facto uma caixa

Para comparar quatro opções preciso de dois números: quanto trabalho processa um nó e quanto trabalho gera um engenheiro. Nenhum é exato, por isso aqui ficam todos os pressupostos, incluindo os que estragam a fantasia.

Passo	Cálculo	Resultado
Parte de entrada nos tokens	153 ÷ 154	0,9935
Débito combinado por GPU	média harmónica de 26 200 de prefill e 10 100 de decode a esta mistura	25 932 tok/s
Redução para K3 vs classe DeepSeek	104B de parâmetros ativos vs ~37B	× 0,35
Redução para B200 vs GB200	o benchmark correu em GB200	× 0,70
Redução para tráfego real vs benchmark	os benchmarks são arrumados, a produção não	× 0,60
Débito reduzido por GPU	25 932 × 0,147	3 812 tok/s
Por nó	× 8 GPUs	30 496 tok/s
Capacidade anual a 100% de carga	× 31 536 000 segundos	962 000M de tokens

Contra isso, a procura:

Passo	Cálculo	Resultado
Tarefas por engenheiro por dia	pressuposto de carga, não medido	6
Tokens por tarefa	Bai et al.7	4,17M
Dias úteis por ano	260 menos férias e feriados	230
Tokens por engenheiro por ano	6 × 4,17M × 230	5 755M

Ao máximo, um nó serve cerca de 167 engenheiros. Com um ciclo de carga anual de 21%, mais ou menos o uso em horário de escritório, suporta cerca de 35.

O valor exato da capacidade é discutível e vou voltar a quanto pode estar errado. Depois de o hardware estar comprado, a utilização esmaga todas as outras variáveis.

A utilização decide

O hardware próprio custa o mesmo parado e a fundo. A depreciação corre, o aluguer do rack corre, e os teus dois Gilfoyles são pagos na mesma. A eletricidade é a única linha que acompanha a procura, e a eletricidade acaba por ser trocos.

Utilização	Rack no escritório $/1M	Colo $/1M	Contador $/1M
5%	12,23	12,81	2,00
10%	6,14	6,40	2,00
21% (só horário de escritório)	2,95	3,05	2,00
35%	1,79	1,83	2,00
50%	1,27	1,28	2,00
80%	0,81	0,80	2,00
100%	0,66	0,64	2,00

A linha do escritório cruza o contador aos 31,2% de utilização, a do colo aos 32,0%.

Uma ressalva que pertence aqui e não ao fim: esta é uma curva de um nó. Dois engenheiros de plataforma e a fatura do eletricista não escalam com o número de nós, por isso com dois nós o cruzamento desce para cerca de 21% e com cinco para cerca de 14%. Quanto maior fores, menos utilização precisas para justificar ter o hardware.

Agora põe uma equipa real contra isto. Oito horas por dia, 230 dias por ano, dá 1 840 horas num total possível de 8 760. Um ciclo de carga de 21%. Uma equipa que trabalha em horário de escritório e depois vai para casa fica abaixo do ponto de equilíbrio, e o self-hosting perde.

Por isso a pergunta nunca foi se os modelos de pesos abertos são bons o suficiente, nem se as GPUs são baratas o suficiente. Ambas estão resolvidas. A pergunta é se consegues encher o turno da noite com trabalhos em lote, avaliações, reindexações e o CI que ninguém vigia. Põe a caixa a 35% e estás a ganhar. A 50% estás a ganhar à vontade. Deixa-a parada todas as noites e compraste um aquecedor caríssimo com contrato de três anos.

Análises independentes do throughput provisionado do Azure põem o ponto de equilíbrio face ao pay-as-you-go em torno dos 80% de utilização sustentada¹⁰. Nem a AWS nem a Microsoft publicam um ponto de equilíbrio próprio, por isso trata isso como aritmética de terceiros e não como orientação do fornecedor. Isso está longe dos meus 31%, e não vou fingir o contrário. Medem coisas diferentes: o deles é um produto com margem, preçado contra a sua própria tabela, o meu é custo bruto contra a tabela de um rival. O que as duas partilham é a direção, que é a de que a capacidade reservada tem de estar ocupada a maior parte do tempo antes de compensar.

As GPUs alugadas ganham no meio

A utilização define o preço unitário. O tamanho da equipa decide qual opção ganha, porque é isso que dilui os custos fixos.

Com 25 engenheiros, um nó fica a 15% de carga e o contador ganha à vontade. Dois engenheiros de plataforma custam $396 240 por ano. A fatura inteira de tokens que substituiriam é $287 777. O pessoal custa mais do que o problema. Nada mais na folha de cálculo vale a pena ler.

Com 60 engenheiros, um nó corre a 36% de carga e a capacidade alugada passa à frente por pouco.

Linha anual (USD)	Escritório	Colo	Alugado	Contador
Depreciação do hardware11	150 000	150 000	0	0
Infraestrutura de energia	25 400	0	0	0
Eletricidade	31 821	0	0	0
Aluguer do rack	0	69 564	0	0
Aluguer de GPUs	0	0	138 382	0
Engenheiros de plataforma	396 240	396 240	396 240	0
Cobranças de tokens	0	0	0	690 664
Total	603 461	615 804	534 622	690 664
Por engenheiro	10 058	10 264	8 910	11 511
Por 1M de tokens	1,75	1,78	1,55	2,00

Repara no que falta nessa tabela: um desconto de pessoal por alugares. Todas as opções em self-hosting carregam dois engenheiros de plataforma inteiros, porque não podes chamar uma fração de pessoa às duas da manhã, seja quem for o dono do metal. Alugar poupa-te o capex, o eletricista e a fila atrás do Musk. Não te poupa a folha de salários.

Por isso a vitória é estreita. Do mais barato ao mais caro, entre as quatro opções, a diferença é de 29%, bem dentro da margem de erro dos meus próprios pressupostos.

Fui à procura de alguém que tivesse feito as contas a esta opção contra as outras três e fiquei sem resposta, o que me intriga, porque alugar GPUs não tem nada de obscuro. A Lambda, a CoreWeave, a Spheron e mais uma dúzia publicam preços à hora de B200, e um agregador acompanha mais de 26¹². O meio está bem à venda, e para uma equipa de 60 engenheiros bate os dois extremos.

Aos 750 engenheiros, cinco nós correm a 90% de carga e alugar perde por muito, porque fatura à hora e a essa utilização estás a pagar quase todas. Ter o hardware custa $1 494 059 num colo ou $1 565 997 no teu próprio escritório, contra $2 126 018 alugado e $8 633 301 no contador. É o único sítio de todo o modelo onde ter o hardware é obviamente o certo, e bate o contador por cerca de seis para um.

Repara, ainda assim, como as colunas do escritório e do colo estão próximas. Acima de cerca de 95 engenheiros ficam a poucos por cento uma da outra e trocam de lugar consoante o número de nós. Dado que a minha opção de escritório não paga renda, a leitura honesta é que são a mesma resposta, e a escolha entre elas é sobre quem queres que mude os filtros.

Tamanho da equipa	Opção mais barata	Custo anual por engenheiro	Razão principal
25	O contador	$11 511	O pessoal de plataforma custa mais do que a fatura de tokens inteira
60	GPUs alugadas	$8 910	Carga suficiente para querer capacidade, não o bastante para justificar capex
750	Hardware próprio (colo)	$1 992	A procura quase contínua torna caras as horas de aluguer

Tokens não são dinheiro

Há um pressuposto persistente no planeamento tecnológico, e digo-o como alguém que é inequivocamente parte do problema, de que os tokens são o novo barril de petróleo. A unidade universal de troca. Há empresas inteiras que já planeiam em ciclos denominados em tokens.

Com todos os custos e plena utilização, o nó próprio deste modelo custa cerca de $0,66 por milhão de tokens contra $2,00 no contador com cache. Só a eletricidade são 6,6 cêntimos disso, que é um décimo do total e, irritantemente, um fator de dez abaixo do número acima. Ambos estão certos.

Linha	Cálculo	Valor
Potência do nó	14,3 kW × 8 760 horas	125 268 kWh/ano
A tarifas empresariais do Reino Unido13	× £0,25	£31 317
Com sobrecarga de refrigeração de escritório (PUE 1,6)	× 1,6	£50 107
Em dólares	× 1,27	$63 636
Tokens produzidos a carga plena		962 000M
Eletricidade por 1M de tokens		6,6 cêntimos

O ponto não é que alguém deva cobrar sete cêntimos. O preço de um token inclui hardware, pessoal, risco, investigação e margem, e deve incluir. O ponto é que um token é uma abstração de faturação a retalho sobre GPU-segundos, com uma taxa de câmbio definida por quem o vende. Se os tokens são mesmo o novo petróleo, então os hiperescaladores são a OPEP, com a vantagem útil de poderem rever a física sempre que as margens precisam de ajuda.

O que nos leva ao que vem a seguir, e que é menos uma previsão do que um padrão que já correu uma vez. A computação de IA financeiriza-se exatamente como a computação da Web 2.0. O EC2 lançou-se preçado à hora de instância, e em poucos anos o mercado real eram instâncias reservadas, savings plans, spot e descontos de uso sustentado. Os grandes compradores deixaram de pagar a tarifa on-demand há anos.

Já está a começar. O Bedrock vende throughput provisionado por hora de unidade de modelo, de $4,11 a $49,50 consoante o modelo, e o preço desce quanto mais tempo te comprometes¹⁰. O Azure vende a mesma forma como unidades de throughput provisionado. Isso não são preços de tokens, são reservas de capacidade com uma curva de compromisso.

O sinal está no que falta nessa página. Nenhum modelo Claude atual tem um preço de throughput provisionado publicado. O mercado reservado para modelos de fronteira existe, mas é cotado em vez de listado, o que diz bem como isto ainda é recente.

Segue isto para a frente e deixas de comprar tokens. Reservas capacidade para a tua base, ficas com o desconto de uso sustentado e vais ao contador quando há picos. Os tokens passam a ser escape de um tubo que já pagaste, e aquilo em que orçamentas passa a ser a hora de GPU, que pelo menos tem uma curva de oferta real por trás.

Devemos?

Parte disto pode soar a argumento para sair e comprar uns quantos metais. Não é, bem.

Estarias a comprar um ativo que deprecia enquanto o preço do contador desce. O Opus 5 lançou-se exatamente ao preço do Opus 4.8, $5 e $25 por milhão de tokens, e é um modelo materialmente melhor¹⁴. A tabela de preços não se mexeu enquanto a coisa por trás melhorava. Portanto o teu capex é uma aposta a três anos de que a inteligência de fronteira fica mais barata mais devagar do que o teu hardware se gasta, e a fronteira tem-se movido à escala de meses. O hardware que especificares hoje fica preso à economia de hoje até 2029.

As duas coisas são verdadeiras ao mesmo tempo, então. Os tokens trazem uma margem gorda, e comprar máquinas é uma má maneira de a maioria das pessoas lhe escapar. A saída é que não tens de comprar um rack para deixares de pagar a retalho. Reserva a capacidade, não compres o edifício.

Duas coisas sobrevivem à aritmética, mas só uma delas sem mácula.

Soberania. Se os teus dados não podem sair do edifício, então não estás a comparar com $2,00, estás a comparar com nada, porque o contador não está à venda para ti a preço nenhum. Faz as contas de utilização na mesma, mas já decidiste.

Latência, mas menos do que esperavas. Um modelo no mesmo rack poupa-te uma viagem de rede. São talvez quarenta milissegundos contra as trinta e tal segundos que a coisa passa a pensar, por isso para trabalho com agentes é ruído. Vale a pena nas coisas apertadas, autocomplete e sugestões em linha, onde persegues um orçamento abaixo dos 100ms e a rede é uma parte real dele. Se a tua carga não é essa, não a ponhas no caso de negócio.

Por isso aqui está o que eu faria de facto: deixa de escolher uma das quatro. Reserva capacidade suficiente para cobrir a tua base e mede o resto no contador. O trabalho previsível e de grande volume corre de noite no tubo que já pagaste, a uma utilização em que ganha dois para um ou melhor. O raciocínio difícil vai para o modelo de fronteira no contador, onde pagas por algo que não consegues reproduzir nem depreciar.

Na prática, a colocação e não a escolha do modelo é a principal alavanca económica. Foi o argumento que fiz sobre encaminhar entre modelos, um nível mais abaixo na pilha.

Onde este modelo pode estar errado

Quatro coisas.

A minha redução de débito é provavelmente demasiado dura, e corrigi-la favorece o aluguer. Cortei o benchmark do vLLM por um fator de sete para cobrir o K3 ser maior, o hardware ser arrefecido a ar e o tráfego real ser mais sujo do que um benchmark. É matemática de guardanapo, e uma verificação grosseira contra os FLOPs brutos diz que o valor verdadeiro pode ser três ou quatro vezes mais alto. Volta a correr com esse número e os 200 engenheiros passam de ter o hardware a alugar, porque hardware mais rápido corta de imediato as horas de GPU alugadas e não faz nada pelo capex que já comprometeste. Move-se contra um rack, não a favor.

Tarefas por engenheiro por dia é um palpite. Usei seis. Determina a procura absoluta e por isso os resultados por tamanho de equipa. Não toca na tabela de utilização, e é por isso que essa é a afirmação mais forte e a pus primeiro.

A configuração de nó único é otimista, como assinalei antes. A Moonshot quer 64 aceleradores para produção e eu modelei oito, que é a leitura mais generosa que o self-hosting poderia pedir.

A opção de escritório recebe o edifício de graça. Paga o hardware, a instalação elétrica e de refrigeração, e a eletricidade. Não paga renda, taxas comerciais, seguro, supressão de incêndio, UPS, PDUs, obras estruturais para 130kg por nó, nem uma ampliação de fornecimento do DNO, e acima de cerca de dois nós um edifício comercial do Reino Unido vai precisar dessa ampliação em vez de um eletricista. O colo paga tudo isso dentro dos £285/kW/mês. Essa diferença é parte da razão pela qual o escritório bate o colo em todas as minhas tabelas, e deves tratar os dois como mais próximos do que parecem. Cobrar à opção de escritório metade da tarifa tudo incluído do colo ainda a deixa à frente em todos os tamanhos de equipa, que é a única razão por que não tentei inventar um número para ela.

Cada número tem uma fonte e uma classificação de confiança no livro de cálculo por trás disto. Os de baixa confiança são os três que acabaste de ler.

Portanto a aritmética pode estar errada nas margens. A física não. Catorze quilowatts são catorze quilowatts, quer a minha estimativa de débito aguente quer não, o calor tem de ir para algum lado, e o eletricista continua a querer ser pago.

Eu podia comprar tokens e nunca mais pensar em nada disto. Ou podia pensar em tudo, e apanhar uma insolação a ligar mais uma placa gráfica.

Footnotes

1. Arena WebDev leaderboard, 28 de julho de 2026, 492 170 votos. claude-opus-5-max 1 712, kimi-k3-max 1 682, claude-opus-5-high 1 669, claude-fable-5 1 628, gpt-5.6-sol-xhigh 1 623, claude-opus-4-8-thinking 1 568. Convém reter isto: a posição do K3 em código favorece-o. No leaderboard principal de texto (27 de julho de 2026) o kimi-k3-max é décimo primeiro com 1 486 ±10, atrás do claude-fable-5 (1 508) e do claude-opus-5-max (1 495), e em empate estatístico com o claude-opus-4-8-thinking (1 484 ±5). É um especialista em código, não o melhor modelo do mundo. ↩

2. Modelo o colo a £285 por kW por mês. Tirei esse número do rabo, porque não encontrei uma fonte suficientemente boa para o defender. Para o que valer: o colocation grossista no Reino Unido anda em £150-300 por kW por mês a partir de 1MW, o retalho em Londres é cotado a £300-800 por armário, passando os £2 000 com densidade, e os racks de GPU de alta densidade levam um prémio a que ninguém põe número. A minha implementação tem 14 a 72kW, demasiado pequena para preços grossistas. Se souberes quanto custa de facto um rack de GPU de 30kW em Londres, diz-me e corrijo isto. Trato o preço como tudo incluído, a cobrir espaço, refrigeração, resiliência e energia, porque cobrar eletricidade medida por cima dele contaria a dobrar a maior linha de uma fatura de colo. ↩

3. Moonshot AI, Kimi-K3 model card. Hugging Face. 2,8T de parâmetros no total, 104B ativos (16 de 896 especialistas), pesos MXFP4 com ativações MXFP8, contexto de 1 048 576 tokens. ↩

4. NVIDIA, Data Center Best Practices with DGX B200. Ficha técnica. Potência estimada do sistema 14,3kW no máximo, peso >130kg e 150 CFM por quilowatt, o que dá 2 145 CFM por nó (o documento indica 4 290 CFM para um rack de dois nós). Dois nós por rack exigem 2x alimentações de 380V trifásicas 32A. O valor do calor é uma conversão minha, não da NVIDIA: 14,3kW x 3 412 = ~48 800 BTU/h. ↩ ↩² ↩³ ↩⁴

5. Moonshot AI, Kimi K3 launch post: “we recommend deploying Kimi K3 on supernode configurations with 64 or more accelerators”. É uma recomendação, não um mínimo. A Moonshot não publica um número mínimo de GPUs. ↩

6. Robert Half, 2026 Salary Guide, machine learning engineer, London. Percentil 50: £102 000, percentil 75: aproximadamente £119 000. ↩

7. Bai et al. (2026), How Do AI Agents Spend Your Money? Artigo, Figura 1. A programação com agentes tem em média 4,17M de tokens por tarefa, com uma razão entrada-saída de 153,85:1, contra 1,33 no chat de código e 0,16 no raciocínio de código. O artigo indica também $1,86 por tarefa, mas isso é uma média de oito modelos, a maioria bem mais baratos do que o Opus 5, e dá cerca de $0,45 por 1M de tokens. Tiro do artigo o volume de tokens e a razão e preço-os eu: a mesma tarefa no Opus 5 com 70% de acertos na cache custa cerca de $8,34. Não leias os dois valores de custo como comparáveis. ↩ ↩²

8. vLLM, Driving vLLM WideEP and Large-Scale Serving Toward Maturity on Blackwell (Part I), 3 de fevereiro de 2026. Ligação. 26,2K tokens de prefill e 10,1K de decode por GPU-segundo em GB200 para MoE ao estilo DeepSeek com 2K de entrada / 2K de saída. Duas coisas a levar com o número: vem de uma topologia desagregada de 16 GPUs (quatro instâncias de prefill de duas GB200 cada, uma instância de decode de oito), e o débito estabiliza por volta de um tamanho de lote de 64K. Escalá-lo linearmente para uma única caixa de oito GPUs arrefecida a ar é exatamente o erro que as minhas reduções existem para cobrir. ↩

9. O Kimi K3 na API da Moonshot custa $3 por milhão de tokens de entrada e $15 por milhão de saída, com acertos de cache a $0,30, igual em todo o contexto de 1M. Os preços são amplamente noticiados, mas não consegui confirmá-los na página de preços da própria Moonshot, por isso trata-os como indicativos. Com a mistura de tokens deste texto, a média dá $1,20 por milhão contra $2,00 do Opus 5. ↩

10. AWS, Bedrock pricing. Os preços publicados de throughput provisionado vão de $4,11 a $49,50 por hora de unidade de modelo e cobrem apenas modelos antigos (Llama 2 $21,18 por um mês, Cohere Command $49,50 por um mês contra $23,77 por seis, Command Light de $8,56 a $4,11). Nenhum modelo Claude atual tem preço provisionado publicado. O equivalente do Azure é a unidade de throughput provisionado, cujo funcionamento está documentado no Microsoft Learn, embora a página não traga valores em dólares. O ponto de equilíbrio de ~80% é análise de terceiros, não orientação do fornecedor, e nenhuma das plataformas publica um número desses. ↩ ↩²

11. O preço de rua de um HGX B200 de 8 GPUs ronda os $400 000 a $500 000 e modelei $450 000 numa vida linear de três anos sem valor residual. Trata isto como pressuposto meu e não como citação: as únicas fontes públicas são páginas de marketing de fornecedores sem autor nomeado nem referências primárias, e uma delas admite que não existe mercado secundário funcional contra o qual verificar. Se tiveres um orçamento real, o teu vale mais do que o meu. ↩

12. Os preços à hora de B200 publicados variam enormemente por fornecedor e compromisso, de cerca de $2,14 a $27,04 por GPU-hora. A Lambda lista $4,99 e a Spheron $3,70 on demand contra $2,74 em spot, enquanto o AWS p6 custa $14,24. O getdeploying agrega mais de 26 fornecedores. Modelei $5,50, que fica entre os preços das neoclouds e dos hiperescaladores e não corresponde a nenhum, por isso trata-o como pressuposto de ponto médio e não como orçamento. ↩

13. DESNZ, Quarterly Energy Prices, junho de 2026, tabelas 3.4.1 a 3.4.2. Preço médio ponderado por volume da eletricidade não doméstica de 24,14p/kWh no 1.º trimestre de 2026, provisório, com o Climate Change Levy e sem IVA. Arredondei para 25p, o que faz as opções de self-hosting parecerem ligeiramente piores e não melhores. PUE é a eficácia do uso de energia, a razão entre a potência total da instalação e a potência que chega de facto ao equipamento. ↩

14. Anthropic, Models overview. O Opus 5 e o Opus 4.8 têm ambos preço de tabela de $5 por milhão de tokens de entrada e $25 por milhão de tokens de saída. ↩