Kimi K3 executa modelo de 2,78 trilhoes de parametros com 8,24 GB de memoria

Executar um modelo de 2,78 trilhoes de parametros com oito gigabytes de memoria parece um truque de magica. O repositorio kimi-k3-in-c revela o segredo: o modelo nao cabe na RAM e nem tenta caber. O motor deixa na memoria apenas o conjunto de dados de trabalho e le a maior parte dos pesos do armazenamento conforme o calculo avanca.

Segundo as medicoes do autor, uma execucao completa do Kimi K3 atinge um pico de 8,24 GB de RAM. Nao sao necessarios GPU, BLAS nem um framework de ML convencional: o nucleo foi escrito em C99 portavel. O outro lado desse numero impressionante e um checkpoint de 1,56 TB, um arquivo adicional de 109 GB com a parte densa compactada do modelo e dezenas de segundos de espera por token.

Como o modelo cabe em uma memoria comum

Imagine um armario do qual voce precisa retirar apenas uma gaveta por vez. Nao faz sentido arrastar o armario inteiro para cima da mesa: basta abrir a gaveta necessaria, processar seu conteudo e passar para a seguinte. Aqui, o NVMe rapido funciona como o armario, enquanto a RAM faz o papel da mesa.

O Kimi K3 usa uma arquitetura esparsa: apenas parte dos especialistas fica ativa em cada etapa. O motor le os pesos dos especialistas selecionados diretamente em formato compactado de quatro bits, mantem os dados usados recentemente em um cache LRU e carrega as camadas densas sequencialmente. O tamanho do cache e o numero de camadas mantidas permanentemente na memoria podem ser ajustados para cada maquina.

De acordo com a tabela publicada, uma configuracao com 8 GB de RAM produz um token em aproximadamente 26,5 segundos. Com 64 GB, o tempo cai para 19,8 segundos; com 128 GB ou mais, chega a 5,6 segundos, pois a espera pelo disco praticamente desaparece. O autor afirma que, usando a mesma solicitacao, o resultado continua identico byte a byte: o que muda e o tempo, nao os calculos.

Um exemplo simples e a continuacao da frase “The capital of France is”. Na configuracao minima, o motor gerou oito tokens em 261,5 segundos, com pico de consumo de 8,24 GB. Isso e lento demais para um chat voltado ao usuario, mas suficiente para comprovar a viabilidade da abordagem e explorar o modelo sem um rack de aceleradores.

O que e necessario na pratica

A principal barreira nao e a RAM, mas o armazenamento. O checkpoint, a parte densa compactada e os arquivos auxiliares exigem cerca de 1,7 TB de espaco livre. Recomenda-se um NVMe local rapido: quando os pesos nao cabem na memoria, a unidade participa da geracao de cada token. Em um SSD lento, o resultado demorara ainda mais.

Para compilar, sao necessarios um compilador C99, OpenMP e um processador com AVX2/FMA em x86-64 ou NEON em Arm. O repositorio oferece suporte a Linux, macOS e Windows. E possivel compilar o motor e executar o conjunto de testes sem baixar o modelo de varios terabytes: ele compara as operacoes e os tokens gerados com uma implementacao de referencia em um modelo reduzido que usa o mesmo esquema computacional.

No entanto, os numeros publicados ainda devem ser tratados como resultados do proprio autor, e nao como um benchmark independente. O modo minimo e uma demonstracao de viabilidade tecnica, nao um servidor de inferencia pronto para producao. A primeira versao nao inclui ferramentas, imagens, servidor de API nem compactacao do historico da conversa. Mesmo uma workstation potente continua significativamente mais lenta que um servico de nuvem baseado em GPU.

Por que desenvolvedores deveriam analisar este codigo

O valor do projeto nao esta na promessa de substituir uma GPU por oito gigabytes de RAM. Ele demonstra quatro tecnicas uteis em codigo concreto: carregamento de camadas por streaming, uso de pesos quantizados sem descompactar todo o array, um cache limitado de especialistas e orcamentos de memoria separados para diferentes partes do modelo.

Se voce esta desenvolvendo uma ferramenta local, uma aplicacao de edge ou um prototipo offline, essas solucoes podem ser transferidas para modelos de tamanho razoavel e oferecer velocidade pratica. Uma equipe de produto deve comecar pela latencia aceitavel: se o usuario espera uma resposta em segundos, esta execucao do Kimi K3 nao serve. Se a tarefa for um experimento em lote, uma auditoria de arquitetura ou o trabalho em um ambiente sem nenhum acelerador, o repositorio deixa de ser um truque e se transforma em um guia util de engenharia.