Há um ano, executar um modelo de linguagem com um trilião de parâmetros significava uma sala de servidores. Bastidores, refrigeração, uma fatura de energia que precisava da sua própria reunião. Depois a AMD publicou um artigo para programadores que mostrava quatro mini PCs em cima de uma secretária (do tipo que se conseguia transportar dois de cada vez) a fazer o mesmo trabalho. Quatro caixinhas idênticas, ligadas por cabos, a executar um modelo com mais parâmetros do que estrelas se conseguem ver de uma rua iluminada de uma cidade.
O título escreve-se sozinho: "Sem cloud. Sem centro de dados." E é verdade. A AMD executou mesmo um modelo de 1,04 triliões de parâmetros em quatro sistemas Framework Desktop com silício de consumo lá dentro.
Mas há uma parte que o título saltou, e é a parte que decide se isto é um marco ou um truque de magia. Há um detalhe de arquitetura que torna "trilião de parâmetros" tecnicamente honesto, uma armadilha que determina se conseguiria mesmo usar esta coisa, e uma razão pela qual importa mais do que tanto o entusiasmo como a reação contrária lhe dão crédito.
A versão curta
- O modelo é o Kimi K2.5, e é um design Mixture-of-Experts: 1,04 triliões de parâmetros no total, mas apenas cerca de 32 mil milhões deles disparam em qualquer token. "Modelo com um trilião de parâmetros" é exato; o cálculo por token está mais próximo de uma carga de trabalho da classe dos 32B.
- O cluster gera cerca de 8 a 9,5 tokens por segundo, com um tempo até ao primeiro token entre 39,7 e 239,1 segundos consoante o comprimento do prompt. Aceitável para trabalho em lote. Brutal para um ciclo interativo de programação.
- O que mudou não é a velocidade. É que a memória unificada colocou a inferência à escala de fronteira em hardware que se pode comprar e pôr numa prateleira, uma categoria que costumava começar em "ser dono de um centro de dados".
O Que a AMD Realmente Fez
A configuração é quase anticlimática depois de a vermos exposta. Quatro máquinas Framework Desktop , cada uma com um Ryzen AI Max+ 395 e 128 GB de memória unificada LPDDR5X. Na BIOS, cada nó pode expor até 96 GB como VRAM dedicada, ou 384 GB nos quatro nós; o guia para Linux da AMD usa depois definições de TTM/kernel para subir isso para 120 GB por nó, ou 480 GB no total. Isso importa porque a build GGUF UD_Q2_K_XL do Kimi K2.5 que a AMD usou está listada com 375 GB, não 240 GB.
A cola é o llama.cpp a correr em modo RPC: um nó controlador e três servidores RPC, com o modelo distribuído pelas quatro máquinas. A AMD indica a interligação como Ethernet a 5 Gbps, o que encaixa na porta Ethernet de 5 Gbit integrada do Framework Desktop. É todo o equipamento. Sem interligação exótica, sem placas personalizadas, nada que não pudesse encomendar esta tarde.
A palavra interessante em tudo isto é unificada. Num PC normal, a RAM do CPU e a VRAM da GPU são pools separados, e um modelo demasiado grande para a VRAM ou transborda para a memória de sistema lenta ou não corre. A memória unificada derruba essa parede: a GPU consegue endereçar todo o banco, que é a razão inteira pela qual uma secretária de 4,5 litros consegue, à partida, conter um pedaço de um modelo deste tamanho.
O próprio artigo técnico da AMD cobre a configuração em detalhe. O que não cobre realmente é porque é que "trilião de parâmetros" está a fazer mais trabalho retórico do que parece.
O Truque: Porque "Trilião de Parâmetros" É Verdade Mas Não Toda a Verdade
Eis a coisa em que a folha de especificações se apoia sem explicar: o Kimi K2.5 é um modelo Mixture-of-Experts, e isso muda o que "trilião de parâmetros" significa na prática.
Um modelo denso, do tipo que a maioria das pessoas imagina, executa cada parâmetro para cada token. Um modelo denso de 70 mil milhões de parâmetros faz contas no valor de 70 mil milhões de parâmetros em cada palavra que produz. Um modelo Mixture-of-Experts é construído de forma diferente. O Kimi K2.5 tem 384 "especialistas" separados, 8 dos quais se ativam por token mais um especialista partilhado, ao longo de 61 camadas. Por isso, embora o modelo carregue 1,04 triliões de parâmetros no total, apenas cerca de 32 mil milhões deles se acendem em qualquer passagem direta única. Um router escolhe que especialistas acordar; os restantes ficam ali sem fazer nada para esse token.
Então será que "executar um modelo de um trilião de parâmetros em quatro mini PCs" é honesto? Sim, precisa genuinamente da memória para conter todos os 1,04 triliões de parâmetros, e essa memória é a parte difícil. Mas o cálculo que o seu hardware tem de fazer por token é um trabalho da classe dos 32B, não da classe de 1T.
O que corta para os dois lados, e é aqui que fica interessante. Torna a demonstração mais impressionante do que soa, porque conter um modelo completo de um trilião de parâmetros em memória em caixas de consumo é a coisa genuinamente difícil que conseguiram. E torna-a menos impressionante do que o título sugere, porque a verdadeira carga de trabalho por token é algo que caixas individuais já processam mais depressa em modelos MoE mais pequenos. Um modelo MoE de 120B corre a mais de 50 tokens por segundo num destes nós. O número de um trilião de parâmetros é real, mas é uma exibição de memória, não uma exibição de cálculo.
A conclusão: quando estiver a dimensionar hardware para um modelo, a contagem de parâmetros ativos é o que a sua máquina tem de alimentar por token, não o total na caixa.
A Armadilha: O Que 8 Tokens por Segundo e Uma Espera de 40 Segundos a 4 Minutos Significam de Facto
Oito tokens por segundo é o número que decide tudo, por isso fique um momento com ele. O artigo da AMD reporta o cluster a gerar cerca de 8,30 t/s num contexto de 8.192 tokens e cerca de 9,45 t/s em regime estável, com o processamento do prompt por volta dos 100,77 t/s. São números aceitáveis e justos para o que são.
O que dói é o tempo até ao primeiro token. Antes de o modelo produzir uma única palavra, tem de ler o seu prompt, e a própria tabela de benchmark da AMD coloca essa espera em 39,7 segundos para um prompt de 4.096 tokens, 90,5 segundos para um prompt de 8.192 tokens e 239,1 segundos para um prompt de 16.384 tokens com o Flash Attention ativado. Por isso escreve uma pergunta, e depois espera. Possivelmente quase quatro minutos, antes de algo voltar.
Para um ciclo interativo de programação, isso é duro, e os programadores na discussão no Hacker News disseram-no claramente: mais de um minuto de silêncio antes do primeiro token não se ajusta à forma como alguém escreve código com um assistente. Mas inverta a carga de trabalho. Se estiver a correr trabalhos em lote durante a noite, a processar documentos de forma assíncrona, a gerar coisas que vai ler mais tarde, ou a fazer inferência privada em que o objetivo é que nada saia do edifício, 8 tokens por segundo são perfeitamente viáveis. Já não estava a olhar para o ecrã, de qualquer forma.
O asterisco: Não espere que estes números se reproduzam sem mais. A stack de software ROCm neste hardware é sensível à versão de formas que mordem: um issue no GitHub documentou um sistema Strix Halo preso em frequências de GPU em repouso e a arrastar-se a 0,5 t/s sob inferência de LLM em ROCm 7.1.1 e kernel Linux 6.14. Isso não é "a AMD está estragada", mas significa que o desempenho publicado depende de uma stack de software muito específica, e pode acabar a perseguir combinações de ROCm, kernel e firmware antes de o seu equipamento igualar os números do artigo.
Mais uma coisa que a reação contrária erra, que é o custo. As pessoas continuam a chamar-lhe um "cluster de 10.000 dólares", mas ninguém está a publicar isso como uma lista de materiais fixa. Faça você mesmo as contas: quatro Framework Desktops de 128 GB ao preço de lançamento de 1.999 dólares poriam só as máquinas em cerca de 8.000 dólares, enquanto um instantâneo da Liliputing de março de 2026 listava uma configuração Framework Desktop de 128GB/1TB a 2.851 dólares, ou cerca de 11.400 dólares por quatro antes da rede. Acrescente algumas centenas de dólares para switch e cablagem, e o intervalo prático fica mais próximo de aproximadamente 8,2 mil a 11,7 mil dólares consoante a configuração, a data de compra e o que já tiver. Não é nada de pouco. Também não é uma sala de servidores.
Eis onde aterro em tudo isto: o cluster funciona. Se oito tokens por segundo e uma espera de mais de um minuto são um triunfo ou um brinquedo depende inteiramente do que estiver a tentar construir. Não é uma estação de trabalho de programação interativa. Também não é um brinquedo. É uma máquina real para um tipo específico de trabalho paciente, e fingir que é mais ou menos do que isso é como toda a gente nesta discussão acaba a falar sem se entender.
Onde Isto Realmente Aterra
O enquadramento honesto não é "a AMD venceu a Nvidia". É que isto é um produto diferente para uma pessoa diferente. O leitor que quer isto é aquele que precisa de privacidade, quer offline, ou não quer pagar por token para sempre, não aquele que persegue a resposta mais rápida possível.
E o argumento mais forte contra todo o exercício merece uma resposta direta: pode simplesmente usar a API da Kimi. A Artificial Analysis lista atualmente o endpoint próprio K2.5 da Kimi por volta de 56 a 60 tokens por segundo com um preço combinado em torno de 0,49 dólares por milhão de tokens, enquanto a plataforma de API oficial da Kimi lista o preço do K2.5 a 0,10 dólares/M de tokens de entrada com cache hit, 0,60 dólares/M de tokens de entrada e 3,00 dólares/M de tokens de saída. Fornecedores terceiros de K2.5 podem ser mais rápidos ou mais baratos consoante o encaminhamento, mas o ponto básico é o mesmo: a API é mais rápida do que o cluster, evita andar a cuidar de hardware, e será a escolha certa para a maioria das pessoas na maioria dos dias.
Por isso a história local só faz sentido quando uma de três coisas é verdade: os dados não podem sair (privacidade), a ligação não pode ser dada como garantida (offline), ou o volume de tokens é alto e sustentado o suficiente para que ser dono do metal bata alugá-lo para sempre (custo à escala). Fora dessas três, a API vence. Dentro delas, o cluster é a única coisa que faz o trabalho de todo.
| Dimensão | Cluster de 4 nós da AMD | API Kimi / rota cloud |
|---|---|---|
| Velocidade de geração | ~8 a 9,5 t/s | ~56 a 60 t/s no endpoint próprio K2.5 da Kimi |
| Tempo até ao primeiro token | 39,7 a 239,1 s | dependente do fornecedor, muito mais baixo |
| Modelo de custo | ~8,2 mil a 11,7 mil dólares em hardware | preço de API por token |
| Privacidade / offline | totalmente local | alojado pelo fornecedor |
| Caso de uso mais adequado | trabalho privado, offline, em lote | uso interativo/API |
Para que conste, o DGX Spark da Nvidia é o óbvio "mas e quanto a" aqui, e vence nalguns eixos em que o cluster da AMD não vence. Isso é uma luta totalmente à parte, e que vou abordar noutro lado. Se quer o lado do aluguer da decisão hardware-versus-cloud, a página de GPU VPS da Cloudzy é o ponto de comparação mais prático.
A Parte Que Realmente Importa
Tire de cima a taxa de tokens e os argumentos de preço, e fica um facto de pé: o hardware que executa um modelo de um trilião de parâmetros é agora uma prateleira, não um edifício.
É essa a mudança, e é fácil de não notar sob a bisbilhotice da velocidade. Há um ano, a categoria de pessoas que conseguiam executar um modelo de 1,04 triliões de parâmetros era "operadores de centros de dados". Ponto final. Agora inclui qualquer pessoa com cerca de dez mil dólares e alguma paciência. A fronteira não se mexeu um pouco: um grupo inteiramente novo de pessoas acabou de atravessar uma porta que estava trancada.
O que isso abre é a parte interessante. Agentes privados que correm inteiramente em hardware que possui. Inferência que funciona num avião ou por trás de um air gap. Modelos que fisicamente não conseguem telefonar para casa porque não há para onde a chamada ir. Uma economia de IA em que o custo marginal de um token é eletricidade em vez de uma linha de API tarifada. Nada disso estava ao alcance em hardware de consumo há um ano, e a memória unificada é o que o alcançou.
Já vi este padrão vezes suficientes para desconfiar do "isto muda tudo". Normalmente não muda; normalmente é a coisa do ano passado com um logótipo novo. Esta é diferente, e não por ser rápida. É diferente porque o chão se mexeu. A versão lenta, cara e paciente da inferência local à escala de fronteira existe agora, e a versão rápida é só uma questão de as próximas gerações de hardware a irem desgastando. A parte difícil nunca ia ser a velocidade. A parte difícil era o acesso, e o acesso acabou de acontecer.
O marco aqui não é a velocidade. É quem tem autorização para entrar na sala. A máquina que executa modelos à escala de fronteira costumava ser um edifício. Agora são quatro caixas numa prateleira.
Perguntas frequentes
Consegue Mesmo Executar um Modelo de Um Trilião de Parâmetros num Cluster de Mini PCs?
Sim, com uma ressalva importante. A AMD executou o Kimi K2.5, um modelo de 1,04 triliões de parâmetros, em quatro mini PCs Ryzen AI Max+ 395. Na BIOS, os quatro sistemas conseguem expor cerca de 384 GB de VRAM dedicada no total; o guia para Linux da AMD eleva depois a alocação para 480 GB no total através de definições de TTM/kernel. Mas o Kimi K2.5 é um modelo Mixture-of-Experts: desses 1,04 triliões de parâmetros, apenas cerca de 32 mil milhões se ativam em qualquer token. Precisa da memória para os conter a todos, mas o cálculo por token está mais próximo de uma carga de trabalho de 32 mil milhões de parâmetros.
O Que É o Kimi K2.5 e Porque É Que a Arquitetura MoE Importa Aqui?
O Kimi K2.5 é um modelo de linguagem de pesos abertos da Moonshot AI com 1,04 triliões de parâmetros no total e 32 mil milhões ativos por passagem direta, construído sobre um design Mixture-of-Experts (384 especialistas, 8 ativados por token mais um partilhado). A arquitetura importa porque a contagem de parâmetros ativos, não o total, é o que o seu hardware tem de calcular para cada token. É por isso que um modelo com um trilião de parâmetros no papel consegue, à partida, correr em caixas de consumo.
8 Tokens por Segundo São Suficientemente Rápidos para IA Local?
Depende inteiramente da carga de trabalho. Para processamento em lote, trabalhos assíncronos, uso offline, ou inferência privada em que nada pode sair do seu hardware, 8 tokens por segundo são aceitáveis, não está a fixar o ecrã. Para programação interativa, é duro, sobretudo porque o tempo até ao primeiro token neste cluster vai de cerca de 40 segundos a quase 4 minutos consoante o comprimento do prompt, e esse silêncio antes da primeira palavra mata um ciclo iterativo.
Porque Não Usar Simplesmente a API da Kimi?
Para a maioria das pessoas, deveria. O endpoint próprio K2.5 da Kimi é muito mais rápido do que o cluster local nos dados atuais da Artificial Analysis, e fornecedores terceiros de K2.5 podem ser ainda mais rápidos ou mais baratos. O hardware local só faz sentido quando precisa de privacidade (os dados não podem sair), capacidade offline (sem ligação a dar como garantida), ou custo à escala (volume alto e sustentado em que ser dono bate alugar). Fora desses casos, a API é a melhor escolha.
