Comprar tokens, alugar GPUs ou ter o rack?
Nesta página
Até pouco tempo atrás, rodar um modelo de fronteira por conta própria nem era uma pergunta séria. Os modelos de pesos abertos ficavam uma geração atrás dos proprietários, então não havia conta a fazer.
Aí a distância fechou. Não até zero, mas até uns trinta pontos de Elo. O Kimi K3 saiu com pesos abertos e está em segundo na arena de código frontend, com 1.682, atrás do Claude Opus 5 Max, com 1.712, e na frente de todo o resto1. Os pesos cabem, no papel, num único nó de oito GPUs. Você pode baixar o modelo hoje à noite, de graça.
A máquina é outra história. Supondo que você tenha capital para investir. E supondo que, depois de fazer a conta, a coisa se pague.
Então modelei quatro jeitos de rodar a mesma carga: um rack no seu escritório, hardware próprio num data center de colocation, GPUs dedicadas alugadas e APIs pagas por token. Vou chamar esta última de medidor daqui em diante.
A resposta não é “compre o rack”. Abaixo de umas 44 pessoas de engenharia, o medidor continua sendo o mais barato. Entre cerca de 44 e 95, as GPUs alugadas ganham. Acima disso, comprar começa a compensar, e com 750 pessoas ele bate o medidor por mais ou menos seis a um.
O número que decide é a utilização. Um rack comprado num plano de três anos custa a mesma coisa às três da manhã, esteja servindo tokens ou só esquentando o prédio.
O K3 é só o exemplo aqui. O mesmo método vale para o que sair depois dele.
Quatro jeitos de comprar inferência
| Opção | Você é dono de | Você aluga | Você paga por |
|---|---|---|---|
| Rack no escritório | GPUs, infraestrutura de energia, refrigeração | nada | Capex, eletricidade, um eletricista, espaço, gente |
| Rack em colo (seu hardware, o prédio de outra pessoa) | GPUs | Espaço, energia, refrigeração | Capex, aluguel do rack por kW2, gente |
| GPUs dedicadas / alugadas | nada | GPUs inteiras por hora | Horas reservadas, gente |
| O medidor (API por token) | nada | nada | Tokens |
Conforme você desce essa tabela, seu compromisso fixo cai e sua flexibilidade sobe. O que você perde é controle e, em escala suficiente, a economia unitária. Descobrir onde essa troca vira é o exercício inteiro.
Antes da planilha, porém, uma pergunta mais básica: dá mesmo para pôr uma dessas máquinas num escritório?
Dá?
Na segunda temporada de Silicon Valley, os servidores do Gilfoyle pegam fogo. O time joga carga demais no Anton, ele estoura a amperagem, derruba o disjuntor geral e queima. Todo mundo lembra como uma piada sobre soberba. Aqui, vamos tratar como comentário sobre engenharia elétrica.

O Anton, instantes depois de o disjuntor geral desistir. Silicon Valley, HBO.
Desculpe se você nunca viu Silicon Valley. É um clássico moderno, à frente do seu tempo.
O K3 tem 2,8 trilhões de parâmetros, 104 bilhões ativos por token, 896 especialistas, quantizado em MXFP4 direto do treinamento3. São 1.390GB de pesos no papel. Um nó de oito GPUs B200 dá 1.440GB, então no papel cabe, com 50GB de sobra. Relatos sobre o checkpoint real falam em algo perto de 1,56TB quando se conta tudo o que não é peso quantizado, e nesse caso não cabe de jeito nenhum. É o sonho molhado do r/selfhosted: o segundo melhor modelo de código do planeta, zumbindo num armário, seu.
Aí você lê a ficha técnica.
| Especificação, um DGX B200 | Valor | O que isso significa num escritório |
|---|---|---|
| Consumo de energia | 14,3 kW4 | Dois fogões de indução completos, todas as bocas, o tempo todo |
| Circuito residencial do Reino Unido (ring main) | 7,4 kW | Um servidor quer dois circuitos inteiros só para ele |
| Calor gerado | ~48.800 BTU/h | Três a quatro aparelhos de ar-condicionado residenciais, no máximo |
| Vazão de ar | 2.145 CFM4 | Não é um armário. É uma casa de máquinas |
| Peso | 130 kg4 | Sem contar o rack, as PDUs e a refrigeração |
| Dois nós por rack | 2x 380V trifásico 32A4 | Você vai ligar para um eletricista, não comprar um filtro de linha |
Uma inconsistência para assumir: os números de energia, peso e vazão de ar são da NVIDIA para o DGX B200, o equipamento integrado dela, enquanto os $450.000 que eu modelo são um preço de rua para um HGX B200 de 8 GPUs, a placa em volta da qual um OEM monta o servidor. Um DGX custa perto de $515.000 na tabela. 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 derrubou aquele disjuntor porque um roteirista queria fogo no terceiro ato. Derrubou porque é isso que acontece quando você pendura carga industrial na fiação residencial.
Um nó, aliás, é o caso generoso, e generoso de um segundo jeito também. Esses 50GB de folga não deixam nada para o KV cache, a memória de trabalho que um modelo precisa para sustentar uma conversa longa, então uma implantação de produção de verdade precisa de mais aceleradores do que isso. A Moonshot recomenda 64 ou mais5. São oito dessas caixas, 114 quilowatts, no seu escritório. Menos uma sala de servidores e mais um micro reator nuclear esperando alguém anunciar uma Série A em volta dele.
Modelei o nó único mesmo assim, porque é a coisa mais barata que poderia plausivelmente guardar os pesos. Cuidado com isso, porém: não é o pior caso. Equipe e obra elétrica são quase fixas, então mais nós diluem esses custos e a economia melhora. O resultado com um nó é o teste mais duro que o self-hosting enfrenta, não o mais fácil.
Depois tem a oferta. A alocação de Blackwell vai primeiro para os maiores compradores, então conseguir uma significa entrar na fila atrás do Musk.
Você precisa de um Gilfoyle
O Gilfoyle é o cara de sistemas. Ele é dono dos racks, não confia em nada, e é a única pessoa no prédio que sabe por que o cluster está pegando fogo.
O que nos leva à minha ficção favorita num plano de negócios de self-hosting: uma fração de engenheiro.
Você não consegue contratar 0,3 de uma pessoa. O cargo aqui roda vLLM ou SGLang em produção, sabe o que é paralelismo de especialistas, depura NCCL às duas da manhã e mantém várias centenas de gigabytes de mixture-of-experts quentes e servindo. A Robert Half coloca a mediana de um engenheiro de machine learning em Londres em £102.000 e o quartil superior perto de £119.0006. Modelei £120.000, de propósito uma contratação do quartil superior, porque a mediana não dá conta desse trabalho.
Essa pessoa também vai ter opiniões. Sobre o seu gasto com nuvem, sobre o teclado que ela exige, sobre a participação societária devida à única pessoa no prédio que entende a coisa de que todo mundo agora depende. Esse é o custo real de rodar você mesmo, e ele não aparece em nenhuma ficha técnica de GPU.
Você precisa de duas, porque uma só é um ponto único de falha com passaporte e opiniões fortes sobre férias.
| Linha | Valor (GBP) |
|---|---|
| Salário base (quartil superior) | £120.000 |
| Multiplicador de encargos (INSS patronal britânico, previdência, 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 liga se o seu hardware está ocupado.
A carga decide mais do que o hardware
A maioria das contas de self-hosting que vi é feita em cima de chat, que é o pior caso possível para ter hardware e não se parece em nada com o que um time de desenvolvimento faz o dia inteiro.
Programação com agentes roda a 4,17 milhões de tokens por tarefa, com uma razão entre entrada e saída de uns 153:17. Nada aqui importa mais do que essa razão, exceto a utilização.
No seu hardware, ela ajuda. O prefill, a leitura do seu prompt, e o decode, a escrita da resposta, são trabalhos diferentes com custos diferentes. O vLLM registra 26.200 tokens por GPU por segundo no prefill contra 10.100 no decode8, então o prefill é duas vezes e meia mais eficiente. Programação com agentes é quase só prefill. O trabalho do seu time calha de ser exatamente o que as GPUs fazem melhor.
No medidor, ela ajuda também, porque os tokens de entrada custam cinco vezes menos que os de saída.
| Componente | Conta | $/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 ponderada, 70% de acertos no cache | $2,00 | |
| Média ponderada, sem cache nenhum | 0,9935 × $5 + 0,0065 × $25 | $5,13 |
Esses 70% são uma suposição, não uma medição, e é o segundo número mais importante deste post. Ele mais que reduz o medidor à metade, de $5,13 para $2,00. Reduza a taxa de acerto à metade, 35%, e o medidor sai a $3,57, o que empurra todos os pontos de virada abaixo com força para o self-hosting. Vá para o outro lado e o medidor vence quase em todo lugar.
Duas coisas a mais sobre esses $2,00 antes de você confiar neles. A Anthropic cobra cerca de 1,25x a entrada para escrever uma entrada de cache, e eu precifiquei todo token sem cache como uma leitura simples. Se todos os 30% sem cache fossem escritas, o medidor sai a $2,37 em vez de $2,00. A verdade está no meio.
Alguém vai perguntar por que comparo o K3 hospedado por mim 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,309, uns $1,20 nessa mistura de tokens. Porque, para a maioria das empresas a que este post se dirige, mandar tráfego de produção para uma nuvem chinesa não é uma opção real, seja qual for a tabela de preços. Isso não é um julgamento técnico, é de compras, e é tomado acima da sua cabeça. A escolha realista é rodar o K3 você mesmo ou comprar o Opus 5 da Anthropic, que é o que as tabelas comparam.
É também, aliás, o mesmo instinto que leva as pessoas a fazer self-hosting. Se você estivesse tranquilo com o lugar onde os pesos rodam, usaria a API e pararia de ler.
Então, antes de usar qualquer coisa daqui: vá olhar a sua taxa real de acerto de cache. Ela importa mais que o preço de uma GPU.
O que uma caixa realmente atende
Para comparar quatro opções, preciso de dois números: quanto trabalho um nó processa e quanto trabalho uma pessoa de engenharia gera. Nenhum dos dois é exato, então aqui vai cada suposição, inclusive as que estragam a fantasia.
| Passo | Conta | Resultado |
|---|---|---|
| Parcela de entrada nos tokens | 153 ÷ 154 | 0,9935 |
| Vazão média por GPU | média harmônica de 26.200 de prefill e 10.100 de decode nessa proporção | 25.932 tok/s |
| Redutor para K3 vs classe DeepSeek | 104B de parâmetros ativos vs ~37B | × 0,35 |
| Redutor para B200 vs GB200 | o benchmark rodou em GB200 | × 0,70 |
| Redutor para tráfego real vs benchmark | benchmarks são arrumadinhos, produção não | × 0,60 |
| Vazão reduzida por GPU | 25.932 × 0,147 | 3.812 tok/s |
| Por nó | × 8 GPUs | 30.496 tok/s |
| Capacidade anual a 100% de uso | × 31.536.000 segundos | 962.000M tokens |
Do outro lado, a demanda:
| Passo | Conta | Resultado |
|---|---|---|
| Tarefas por engenheiro por dia | suposição de carga, não medida | 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 |
A todo vapor, um nó atende cerca de 167 pessoas de engenharia. Com um ciclo de uso anual de 21%, mais ou menos o horário comercial, ele sustenta uns 35.
O número exato da capacidade é discutível e eu volto a quanto ele pode estar errado. Depois que o hardware é comprado, a utilização domina qualquer outra variável.
A utilização decide
Hardware próprio custa o mesmo dormindo ou a todo vapor. A depreciação corre, o aluguel do rack corre, e seus dois Gilfoyles recebem de qualquer jeito. A eletricidade é a única linha que acompanha a demanda, e a eletricidade acaba sendo troco.
| Utilização | Rack no escritório $/1M | Colo $/1M | Medidor $/1M |
|---|---|---|---|
| 5% | 12,23 | 12,81 | 2,00 |
| 10% | 6,14 | 6,40 | 2,00 |
| 21% (só horário comercial) | 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 medidor a 31,2% de utilização, a do colo a 32,0%.
Uma ressalva que cabe bem aqui e não no fim: essa é uma curva de um nó. Duas pessoas de plataforma e a nota do eletricista não crescem com o número de nós, então com dois nós o ponto de virada cai para cerca de 21% e com cinco para cerca de 14%. Quanto maior você fica, menos utilização precisa para justificar ter o hardware.
Agora ponha um time de verdade ao lado disso. Oito horas por dia, 230 dias por ano, dá 1.840 horas de um total possível de 8.760. Um ciclo de uso de 21%. Um time que trabalha em horário comercial e depois vai para casa fica abaixo do ponto de equilíbrio, e o self-hosting perde.
Então a pergunta nunca foi se os modelos de pesos abertos são bons o bastante, ou se as GPUs são baratas o bastante. As duas coisas estão resolvidas. A pergunta é se você consegue encher o turno da noite com jobs em lote, avaliações, reindexação e o CI que ninguém acompanha. Leve a caixa a 35% e você está ganhando. A 50%, ganhando com folga. Deixe ela ociosa toda noite e você comprou um aquecedor de ambiente caríssimo num contrato de três anos.
Análises independentes da capacidade provisionada da Azure colocam o ponto de equilíbrio contra o pay-as-you-go em torno de 80% de utilização sustentada10. Nem a AWS nem a Microsoft publica um ponto de equilíbrio próprio, então trate isso como conta de terceiros, não como orientação do fornecedor. Isso está longe dos meus 31%, e não vou fingir o contrário. Eles medem coisas diferentes: o deles é um produto com margem, precificado contra a própria tabela, o meu é custo bruto contra a tabela de um concorrente. O que os dois têm em comum é a direção, que é a de que capacidade reservada precisa estar ocupada na maior parte do tempo antes de compensar.
GPUs alugadas ganham no meio
A utilização define o preço unitário. O tamanho do time decide qual opção vence, porque é ele que dilui os custos fixos.
Com 25 pessoas de engenharia, um nó fica a 15% de uso e o medidor vence de lavada. Duas pessoas de plataforma custam $396.240 por ano. A conta de tokens inteira que elas substituiriam é de $287.777. A equipe custa mais que o problema. Nada mais na planilha vale a leitura.
Com 60 pessoas de engenharia, um nó roda a 36% de uso e a capacidade alugada passa na frente por pouco.
| Linha anual (USD) | Escritório | Colo | Alugado | Medidor |
|---|---|---|---|---|
| Depreciação do hardware11 | 150.000 | 150.000 | 0 | 0 |
| Infraestrutura de energia | 25.400 | 0 | 0 | 0 |
| Eletricidade | 31.821 | 0 | 0 | 0 |
| Aluguel do rack | 0 | 69.564 | 0 | 0 |
| Aluguel de GPU | 0 | 0 | 138.382 | 0 |
| Engenheiros de plataforma | 396.240 | 396.240 | 396.240 | 0 |
| Cobrança 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 |
Repare no que falta nessa tabela: um desconto de equipe por alugar. Toda opção de self-hosting carrega duas pessoas de plataforma inteiras, porque você não consegue acionar uma fração de pessoa às duas da manhã, seja quem for o dono do metal. Alugar poupa o capex, o eletricista e a fila atrás do Musk. Não poupa a folha de pagamento.
É por isso que a vitória é estreita. Do mais barato ao mais caro entre as quatro opções aqui, a diferença é de 29%, folgadamente dentro da margem de erro das minhas próprias suposições.
Fui procurar alguém que tivesse calculado essa opção contra as outras três e voltei de mãos vazias, o que me intriga, porque não há nada de obscuro em alugar GPUs. Lambda, CoreWeave, Spheron e mais uma dúzia publicam preços por hora de B200, e um agregador acompanha mais de 26 deles12. O meio está à venda de verdade, e para um time de 60 pessoas ele bate os dois extremos.
Com 750 pessoas de engenharia, cinco nós rodam a 90% de uso e alugar perde feio, porque cobra por hora e, a essa utilização, você paga quase todas. Ter o hardware custa $1.494.059 num colo ou $1.565.997 no seu escritório, contra $2.126.018 alugado e $8.633.301 no medidor. É o único ponto do modelo inteiro em que ter o hardware é obviamente certo, e ele bate o medidor por mais ou menos seis a um.
Repare como as colunas do escritório e do colo ficam próximas, no entanto. Acima de umas 95 pessoas elas ficam a poucos pontos percentuais uma da outra e trocam de lugar conforme o número de nós. Dado que minha opção de escritório não paga aluguel, a leitura honesta é que são a mesma resposta, e a escolha entre elas é sobre quem você quer que troque os filtros.
| Tamanho do time | Opção mais barata | Custo anual por engenheiro | Motivo principal |
|---|---|---|---|
| 25 | O medidor | $11.511 | A equipe de plataforma custa mais que a conta de tokens inteira |
| 60 | GPUs alugadas | $8.910 | Uso suficiente para querer capacidade, não para justificar capex |
| 750 | Hardware próprio (colo) | $1.992 | Demanda quase contínua faz as horas alugadas ficarem caras |
Tokens não são dinheiro
Existe uma suposição persistente no planejamento de tecnologia, e digo isso como alguém inegavelmente parte do problema, de que tokens são o novo barril de petróleo. A unidade universal de troca. Empresas inteiras agora fazem ciclos de planejamento denominados em tokens.
Com todos os custos e a utilização plena, o nó próprio neste modelo custa cerca de $0,66 por milhão de tokens contra $2,00 no medidor com cache. Só a eletricidade é 6,6 centavos disso, que é um décimo do total e, irritantemente, um fator de dez abaixo do número acima. Os dois estão certos.
| Linha | Conta | Valor |
|---|---|---|
| Energia do nó | 14,3 kW × 8.760 horas | 125.268 kWh/ano |
| Em tarifa empresarial 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 uso pleno | 962.000M | |
| Eletricidade por 1M de tokens | 6,6 centavos |
O ponto não é que alguém deva cobrar sete centavos. O preço de um token inclui hardware, equipe, risco, pesquisa e margem, e deve incluir. O ponto é que um token é uma abstração de cobrança no varejo sobre segundos de GPU, com uma taxa de câmbio definida por quem está vendendo. Se tokens realmente são o novo petróleo, então os hyperscalers são a OPEP, com a vantagem útil de poderem rever a física sempre que a margem precisar de ajuda.
É para onde isso vai a seguir, e é menos uma previsão do que um padrão que já rodou uma vez. A computação de IA vira ativo financeiro exatamente como a computação da Web 2.0. O EC2 foi lançado com preço por hora de instância, e em poucos anos o mercado de verdade eram instâncias reservadas, savings plans, spot e descontos por uso sustentado. Os grandes compradores pararam de pagar a tarifa sob demanda anos atrás.
Já está começando. O Bedrock vende throughput provisionado por hora de unidade de modelo, de $4,11 a $49,50 conforme o modelo, e a tarifa cai quanto mais tempo você se compromete10. A Azure vende o mesmo formato como unidades de throughput provisionado. Isso não são preços de token, são reservas de capacidade com uma curva de compromisso.
O que entrega é o que falta naquela página. Nenhum modelo Claude atual tem tarifa de throughput provisionado publicada. O mercado reservado para modelos de fronteira existe, mas é cotado e não listado, o que diz o quanto ainda é cedo.
Siga isso adiante e você deixa de comprar tokens. Você reserva capacidade para a sua base, leva o desconto por uso sustentado e transborda para o medidor quando há pico. Os tokens viram exaustão de um cano que você já pagou, e a coisa em que você orça passa a ser a hora de GPU, que pelo menos tem uma curva de oferta de verdade por trás.
Devemos?
Parte disto pode soar como um argumento para sair e comprar um pouco de metal. Não é, bem.
Você estaria comprando um ativo que deprecia enquanto o preço do medidor cai. O Opus 5 foi lançado exatamente ao preço do Opus 4.8, $5 e $25 por milhão de tokens, e é um modelo bem melhor14. A tabela de preços não se mexeu enquanto a coisa por trás dela melhorava. Então o seu capex é uma aposta de três anos de que a inteligência de fronteira fica mais barata mais devagar do que o seu hardware se desgasta, e a fronteira anda numa escala de meses. O hardware que você especificar hoje fica preso à economia de hoje até 2029.
As duas coisas são verdade ao mesmo tempo, então. Tokens carregam uma margem gorda, e comprar máquinas é um jeito ruim para a maioria das pessoas escapar dela. A saída é que você não precisa comprar um rack para parar de pagar varejo. Reserve a capacidade, não compre o prédio.
Duas coisas sobrevivem à aritmética, embora só uma delas limpa.
Soberania. Se os seus dados não podem sair do prédio, você não está comparando com $2,00, está comparando com nada, porque o medidor não está à venda para você a preço nenhum. Rode os números de utilização mesmo assim, mas você já decidiu.
Latência, mas menos do que você esperaria. Um modelo no mesmo rack poupa uma ida e volta de rede. São talvez quarenta milissegundos contra os trinta e tantos segundos que a coisa passa pensando, então para trabalho com agentes é ruído. Ela se paga nas tarefas curtas, autocomplete e sugestões em linha, em que você persegue um orçamento abaixo de 100ms e a rede é uma fatia real dele. Se não é a sua carga, não ponha isso no plano de negócios.
Então aqui vai o que eu faria de verdade: pare de escolher uma das quatro. Reserve capacidade suficiente para cobrir a sua base e use o medidor para o resto. O trabalho previsível e de alto volume roda de madrugada no cano que você já pagou, na utilização em que ele vence por dois a um ou mais. O raciocínio difícil vai para o modelo de fronteira no medidor, onde você paga por algo que não consegue reproduzir e não consegue 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 rotear entre modelos, uma camada mais abaixo na pilha.
Onde este modelo pode estar errado
Quatro coisas.
Meu redutor de vazão provavelmente é duro demais, e corrigi-lo favorece o aluguel. Cortei o benchmark do vLLM por um fator de sete para cobrir o K3 ser maior, o hardware ser refrigerado a ar e o tráfego real ser mais bagunçado que um benchmark. É conta de guardanapo, e uma checagem rápida contra os FLOPs brutos diz que o número verdadeiro pode ser três ou quatro vezes maior. Rode de novo com esse número e 200 pessoas de engenharia passam de ter para alugar, porque hardware mais rápido corta as horas de GPU alugada na hora, sem fazer nada pelo capex que você já assumiu. Isso se move contra um rack, não a favor.
Tarefas por engenheiro por dia é um palpite. Usei seis. Ele determina a demanda absoluta e, portanto, os resultados por tamanho de time. Não toca na tabela de utilização, que é por isso a afirmação mais forte e por que a coloquei primeiro.
A configuração de nó único é otimista, como sinalizei 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 ganha o prédio de graça. Ela paga o hardware, a instalação elétrica e de refrigeração, e a eletricidade. Não paga aluguel, impostos prediais, seguro, supressão de incêndio, UPS, PDUs, obra estrutural para 130kg por nó, nem a ampliação do fornecimento da DNO, e acima de uns dois nós um prédio comercial no Reino Unido vai precisar dessa ampliação, não de um eletricista. O colo paga tudo isso dentro dos £285/kW/mês. Essa diferença é parte do motivo de o escritório vencer o colo em todas as minhas tabelas, e você deve tratar os dois como mais próximos do que parecem. Cobrar da opção de escritório metade da tarifa cheia do colo ainda a deixa na frente em todos os tamanhos de time, que é o único motivo de eu não ter tentado inventar um número para ela.
Cada número tem uma fonte e uma nota de confiança na planilha por trás disto. Os de baixa confiança são os três que você acabou de ler.
Então a aritmética pode estar errada nas bordas. A física não. Catorze quilowatts são catorze quilowatts, a minha estimativa de vazão se sustente ou não, o calor tem que ir para algum lugar, e o eletricista ainda quer receber.
Eu poderia comprar tokens e nunca mais pensar em nada disso. Ou poderia pensar em tudo, e pegar uma insolação ligando mais uma placa de vídeo.
Footnotes
-
Ranking Arena WebDev, 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. Vale guardar: a posição do K3 em código o favorece. No ranking principal de texto (27 de julho de 2026), o kimi-k3-max é o 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). Ele é um especialista em código, não o melhor modelo do mundo. ↩
-
Modelo o colo a £285 por kW por mês. Tirei esse número do rabo, porque não achei uma fonte boa o bastante para sustentá-lo. Para o que vale: o colocation atacadista no Reino Unido sai a £150-300 por kW por mês a partir de 1MW, o varejo em Londres é cotado a £300-800 por gabinete, passando de £2.000 para alta densidade, e racks de GPU de alta densidade têm um prêmio que ninguém aceita pôr em número. Minha implantação é de 14 a 72kW, pequena demais para preço de atacado. Se você sabe quanto custa de verdade um rack de GPU de 30kW em Londres, me conte e eu corrijo. Trato a tarifa como tudo incluído, cobrindo espaço, refrigeração, resiliência e energia, porque cobrar eletricidade medida por cima dela contaria em dobro a maior linha de uma conta de colo. ↩
-
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. ↩
-
NVIDIA, Data Center Best Practices with DGX B200. Ficha técnica. Potência estimada do sistema de 14,3kW no máximo, peso acima de 130kg e 150 CFM por quilowatt, o que dá 2.145 CFM por nó (o documento cita 4.290 CFM para um rack de dois nós). Dois nós por rack exigem 2 alimentações de 380V trifásico 32A. O número de calor é conversão minha, não da NVIDIA: 14,3kW x 3.412 = ~48.800 BTU/h. ↩ ↩2 ↩3 ↩4
-
Moonshot AI, post de lançamento do Kimi K3: “we recommend deploying Kimi K3 on supernode configurations with 64 or more accelerators”. Uma recomendação, não um piso. A Moonshot não publica um número mínimo de GPUs. ↩
-
Robert Half, Guia Salarial 2026, engenheiro de machine learning, Londres. Percentil 50 de £102.000, percentil 75 de aproximadamente £119.000. ↩
-
Bai et al. (2026), How Do AI Agents Spend Your Money? Artigo, Figura 1. Programação com agentes tem média de 4,17M de tokens por tarefa a uma razão entrada-saída de 153,85:1, contra 1,33 para chat de código e 0,16 para raciocínio de código. O artigo também relata $1,86 por tarefa, mas é uma média de oito modelos, a maioria bem mais barata que o Opus 5, e dá em torno de $0,45 por 1M de tokens. Pego o volume de tokens e a razão do artigo e precifico eu mesmo: a mesma tarefa no Opus 5 com 70% de acerto de cache custa cerca de $8,34. Não leia os dois números de custo como comparáveis. ↩ ↩2
-
vLLM, Driving vLLM WideEP and Large-Scale Serving Toward Maturity on Blackwell (Part I), 3 de fevereiro de 2026. Link. 26,2K de tokens de prefill e 10,1K de decode por GPU-segundo em GB200 para um MoE estilo DeepSeek com 2K de entrada e 2K de saída. Duas coisas para levar junto com o número: ele 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 a vazão estabiliza em torno de um lote de 64K. Escalar isso linearmente para uma única caixa de oito GPUs refrigerada a ar é exatamente o erro que meus redutores existem para cobrir. ↩
-
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 valores são amplamente noticiados, mas não consegui confirmá-los na página de preços da própria Moonshot, então trate como indicativos. Na mistura de tokens deste post, isso dá $1,20 por milhão contra $2,00 do Opus 5. ↩
-
AWS, preços do Bedrock. As tarifas publicadas de throughput provisionado vão de $4,11 a $49,50 por hora de unidade de modelo e cobrem só modelos legados (Llama 2 a $21,18 por um mês, Cohere Command a $49,50 por um mês contra $23,77 por seis, Command Light de $8,56 até $4,11). Nenhum modelo Claude atual tem tarifa provisionada publicada. O equivalente da Azure é a unidade de throughput provisionado, cuja mecânica está documentada no Microsoft Learn, embora a página não traga valores em dólar. O ponto de equilíbrio de ~80% é análise de terceiros, não orientação do fornecedor, e nenhuma das plataformas publica esse número. ↩ ↩2
-
O preço de rua de um HGX B200 de 8 GPUs gira em torno de $400.000 a $500.000 e modelei $450.000 numa vida útil linear de três anos sem valor residual. Trate isso como suposição minha e não como citação: as únicas fontes públicas são páginas de marketing de conteúdo de fornecedores, sem autor nomeado e sem referências primárias, e uma delas admite que não existe mercado secundário funcional para conferir. Se você tem uma cotação de verdade, a sua vale mais que a minha. ↩
-
Os preços por hora publicados de B200 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 sob demanda contra $2,74 spot, enquanto a AWS p6 sai a $14,24. O getdeploying agrega mais de 26 fornecedores. Modelei $5,50, que fica entre o preço de neocloud e o de hyperscaler e não corresponde a nenhum dos dois, então trate como suposição de ponto médio e não como cotação. ↩
-
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 residencial de 24,14p/kWh no T1 de 2026, provisório, incluindo o Climate Change Levy e excluindo o IVA. Arredondei para 25p, o que faz as opções de self-hosting parecerem um pouco piores, não melhores. PUE é power usage effectiveness, a razão entre a energia total da instalação e a energia que de fato chega aos equipamentos. ↩
-
Anthropic, Models overview. O Opus 5 e o Opus 4.8 listam $5 por milhão de tokens de entrada e $25 por milhão de tokens de saída. ↩