Análise: 'Kimi K3 ativa só 16 dos 896 especialistas por token'

O número que importa não é 2,8 trilhões

Quando a Moonshot publicar o checkpoint do Kimi K3 em 27 de julho, será o maior modelo de pesos abertos já lançado: 2,8 trilhões de parâmetros, janela de contexto de 1 milhão de tokens, multimodalidade nativa e benchmarks que superam o Opus 4.8, ficando aproximadamente uma geração atrás do Fable 5 e do GPT-5.6. O discurso público fixou-se nos 2,8 trilhões. Mas o número mais importante é 16: o K3 ativa apenas 16 de 896 experts por token - menos de 2% dos pesos de experts tocados a cada forward pass.

A tendência mais consistente em modelos abertos

Os parâmetros totais cresceram cerca de 20x desde o Mixtral e 3x apenas nos últimos doze meses. Já os parâmetros ativos mal cresceram: uma faixa de 17 a 49B durante 27 meses. A Moonshot lançou K2, K2.5 e K2.6 em nove meses com o mesmo esqueleto - 1T total, 32B ativos - três releases, zero crescimento em parâmetros ativos. A direção é inequívoca: manter o compute por token aproximadamente plano e inflar a capacidade total implacavelmente. A razão é econômica: com um orçamento fixo de compute para treino, mais experts significam menor loss. O modelo aprende mais com os mesmos FLOPs, e a conta é paga em armazenamento - o recurso com tiers baratos - em vez de compute e largura de banda de memória, que são escassos e racionados.

Compressão de KV Cache fecha a brecha

Mesmo com experts mais esparsos, janelas de contexto maiores fazem o KV cache crescer, e o cache é carregado da memória a cada token, exatamente como os pesos. É aqui que a tendência complementar fecha a brecha: compressão de atenção (o híbrido CSA/HCA da DeepSeek, Multi-head Latent Attention, a nova arquitetura de atenção do K3) está colapsando o cache. O KV cache do V4-Pro em contexto de 1M é 10% do tamanho do predecessor. Experts mais esparsos reduzem os bytes de pesos movidos por token; atenção comprimida reduz os bytes de cache movidos por token. Nada no roadmap reduz os bytes armazenados - esse número só sobe.

Dois regimes de serving

A esparsidade é o que torna um modelo de 2,8T servível. Em MXFP4, apenas os pesos do K3 ocupam cerca de 1,4TB - mais de dez H200s só para carregá-los, antes do KV cache em janela de 1M. A Moonshot recomenda configurações de supernode com 64 ou mais aceleradores. Em ambientes de baixo batch (empresas que querem self-host), uma abordagem de memória em camadas funciona: experts mais frequentes em HBM, menos frequentes em DRAM barato. Mas em ambientes de hiperescala, um batch de produção acende a maioria dos 896 experts a cada forward pass - não existem experts confiavelmente frios. Nesse regime, a esparsidade não reduz o HBM comprado; converte demanda de bandwidth em demanda de capacidade HBM.

O futuro depende de routing

Hoje os roteadores distribuem tokens de forma aproximadamente uniforme entre experts, o que faz o tiering quente/frio falhar em escala. Se os labs treinarem roteadores com localidade deliberada - experts populares, caminhos previsíveis - o tiering verdadeiro se torna viável mesmo em batch alto, e os campos de capacidade barata em DRAM ganham muito mais. A esparsidade democratizou o compute da inferência de fronteira, mas não fez nada pela capacidade. O custo migrou de compute para armazenamento.