Kimi K3 open source: 2,8 trilhões e a conta de GPU

O Kimi K3 open source apareceu na minha timeline com 2,8 trilhões de parâmetros no título, e a primeira coisa que fiz com esse número foi dividir, não ler leaderboard.

A conta é curta. Parâmetro em fp16 ocupa 2 bytes, então 2,8 trilhões deles somam 5,6 TB de pesos. Numa H100 de 80 GB, isso dá 70 GPUs só pra segurar o modelo de pé, sem sobra pra mais nada. Nenhuma das manchetes que li trazia essa divisão no texto.

Antes de qualquer coisa, de onde vieram os números que uso aqui, porque isso importa mais que o tom confiante de quem escreve. A contagem de parâmetros e a janela de contexto de 1 milhão de tokens vêm do comunicado da Moonshot. O tamanho da H100 é ficha técnica da NVIDIA. Bytes por parâmetro é aritmética de representação binária, não opinião. O resto, como você vai ver, é regra de três com as premissas escritas na tela, justamente pra você discordar com calculadora na mão.

O que a Moonshot anunciou, e o que ficou fora do comunicado

O texto oficial divulgou quatro coisas concretas: o total de parâmetros, a janela de contexto, uma arquitetura que a empresa chama de Mixture-of-Experts e a frase que acompanha todo lançamento grande desde 2023, a de que o desempenho seria comparável ao GPT e ao Claude.

O silêncio da nota diz mais. Não veio ficha de avaliação completa com metodologia explicada. Não veio lista de dados de treino. E faltou o item que mais interessa pra quem vai colocar isso em produção: a licença. Também não ficou claro se os pesos estão de fato disponíveis pra download ou se o que existe é um modelo acessível por API com a etiqueta “aberto” colada por cima.

Não é acusação, é o roteiro que se repete. A nota chega com o número que vira manchete e empurra os detalhes chatos (licença, ficha de avaliação, dados de treino) pra uma página secundária no repositório, que a maioria abre três semanas depois, já no meio da prova de conceito. Um caso comum: o time comemora na segunda que achou um modelo aberto bom no ranking e descobre na sexta que a cláusula comercial proibia exatamente o caso de uso dele. Aí já tem código escrito em cima.

Kimi K3 open source: aberto pra quem, exatamente?

Aqui eu troco o adjetivo do marketing pela régua. A Open Source AI Definition, da Open Source Initiative, não se contenta com pesos publicados. Ela pede dados de treino utilizáveis e redistribuíveis, código de treino e de inferência disponível e licença que não restrinja uso por área de atuação. Nada de “só pra pesquisa”, nada de “exceto concorrentes”.

Open weights não é open source. São categorias diferentes, e a indústria embaralha as duas com uma promiscuidade que já cansou. Modelo com pesos baixados em formato fechado, treinado em dados secretos e distribuído sob licença com cláusula de concorrência é open weights, no melhor cenário. Chamar isso de código aberto é esticar a palavra até ela perder o sentido.

Na prática, o que eu leio antes de considerar adotar qualquer coisa:

• O nome exato da licença e a versão, não o resumo do blog.
• Se o uso comercial está liberado sem teto de faturamento ou de número de usuários.
• Se há política de uso aceitável anexa, porque ela costuma ser mais restritiva que a licença em si.
• Se os pesos estão baixáveis de fato, com hash e versão, ou se o “download” é um formulário de contato comercial.

A resposta pra “o que eu posso fazer com isso” mora na licença. O leaderboard não responde essa pergunta, ele só responde “quão bonito ficou o gráfico”.

A conta de guardanapo: memória, KV cache e GPU de verdade

Voltando à aritmética, porque é ela que sustenta o resto do texto.

Precisão	Bytes por parâmetro	Total para 2,8 T	GPUs de 80 GB (mínimo teórico)
fp16	2	~5,6 TB	70
8 bits	1	~2,8 TB	35
4 bits	0,5	~1,4 TB	18

Isso é o piso, e piso não é o que roda em produção. Só os pesos não bastam. Falta o KV cache, e é aí que a janela de 1 milhão de tokens cobra o preço dela.

A Moonshot fala em atenção com poucos KV heads, o truque de GQA que virou padrão justamente pra segurar contexto longo. Ele encolhe o cache, não o elimina. O que fica guardado por token depende do número de camadas e da largura desses heads, e cresce de forma linear e teimosa conforme a janela enche. Com um milhão de tokens disponíveis, essa parte da conta deixa de ser detalhe e passa a disputar espaço com os próprios pesos. E é por sequência ativa: duas conversas longas ao mesmo tempo e a memória reservada dobra.

Some tudo: os pesos em 4 bits, o cache, as ativações e o runtime. Aplique uma folga generosa, porque rodar no limite exato é receita pra OOM no pior momento possível. O total não fecha num nó de 8 GPUs nem no papel; você precisa de vários nós interligados, com NVLink ou InfiniBand no meio, e o número sobe conforme o contexto enche.

Tem outro detalhe que quase ninguém coloca na tabela: pegar um MoE de 2,8 trilhões e jogar em 4 bits não é gratuito em qualidade. O roteador de especialistas é sensível a quantização agressiva, e o modelo que brilha no gráfico em fp16 não é necessariamente o mesmo que responde na sua máquina em 4 bits. Sem ficha de avaliação divulgada, você descobre isso testando por conta própria.

Cluster alheio: quando o Kimi K3 open source vira conta de aluguel

Aluguel de H100 em nuvem pública fica na casa de US$ 2 a US$ 3 por GPU/hora, olhando as tarifas públicas do período do anúncio. Trinta e duas GPUs, o mínimo pra rodar isso com contexto longo e alguma folga, dá algo entre US$ 64 e US$ 96 por hora. Ligado 24/7, um mês passa de US$ 50 mil. E nessa conta ainda não entrou quem opera: gente pra cuidar de nó caído, atualizar driver, requantizar quando a qualidade cai, monitorar latência de rede entre nós.

Do outro lado, uma API fechada cobra por token. Você paga só o que consome, sem contrato de tráfego mínimo, sem time de infraestrutura, sem esperar o cluster subir. Pra qualquer volume que não seja altíssimo e constante, a API ganha a conta com folga. A virada costuma acontecer quando o consumo é grande, previsível e o time já tem infraestrutura de GPU montada pra outras cargas. Fora desse cenário, o modelo “aberto” de 2,8 trilhões sai mais caro que o fechado.

É aqui que a tese se fecha. Acima de um certo tamanho, aberto deixa de ser sobre liberdade e passa a ser sobre quem tem o data center. Você não baixa 2,8 trilhões de parâmetros e roda na sua workstation; você acessa esse modelo se tiver acesso a um cluster que não é seu, ou se pagar por um. E depender do cluster de outra pessoa pra usar um modelo que chamam de aberto é uma forma de dependência bem parecida com a que o rótulo prometia resolver.

O veredito: a licença decide, não o parâmetro

Depois de fazer as contas, o que sobra pra quem desenvolve é o mesmo de sempre. A pergunta útil não é quantos parâmetros o Kimi K3 tem, e sim se a licença permite o que você precisa fazer, se os pesos estão realmente lá pra baixar e se o custo de rodar cabe no seu orçamento. Se as três respostas forem sim, o tamanho do modelo vira detalhe de engenharia. Se a primeira for não, o resto é gráfico bonito que não paga aluguel de GPU.

Meu resumo pessoal: modelo aberto de escala absurda é ótimo pra pesquisa, pra benchmark e pra marketing de quem publica. Pra produto, o que decide é a licença e a conta de infraestrutura, nessa ordem. Parâmetro grande é vaidade de release note. Licença clara é o que paga a conta no fim do mês.

Fontes consultadas

• VentureBeat: China’s Moonshot AI releases Kimi K3, the largest open-source model ever, rivaling top U.S. systems link
• OpenRouter: Kimi K3 – API Pricing & Benchmarks link
• Hugging Face (blog): Kimi K3 Model Overview: 2.8T Parameters, MXFP4 Quantization, and What the Open Weights Mean for the Community link
• NVIDIA: H100 GPU (ficha técnica oficial) link
• Open Source Initiative: The Open Source AI Definition link
• Intuition Labs: H100 Rental Prices Compared: Across 15+ Cloud Providers, 2026 link