Modelo MoE de 2,8T em produção exige serving coordenado

O número de 2,8 trilhões de parâmetros parece um problema de memória. No serving, ele é um problema de coordenação. O Kimi K3, apresentado em julho de 2026, ativa cerca de 104 bilhões de parâmetros por token, seleciona 16 entre 896 experts e ainda precisa manter dois tipos de estado de atenção. A conta difícil não está na manchete. Está no caminho de cada token.

O anúncio técnico do Kimi K3, publicado em julho de 2026, explica a arquitetura. O relatório técnico no arXiv detalha a escala. O que esses documentos não resolvem sozinhos é a pergunta operacional: como transformar uma arquitetura desse tamanho em um serviço que preserve throughput, latência e utilização sem tratar a memória da GPU como um armário infinito?

A tese é simples: modelos MoE grandes chegam à produção quando a infraestrutura transforma escala total em computação ativa, memória reutilizável e tráfego distribuído. Abrir os pesos é uma decisão de disponibilidade. Torná-los servíveis é uma decisão de arquitetura.

O que muda ao servir um modelo MoE de 2,8T em produção?

Servir um modelo MoE de 2,8T muda o gargalo de uma multiplicação isolada para uma cadeia de memória, comunicação e escalonamento. Os experts ativos reduzem o cálculo por token, enquanto a distribuição entre aceleradores, a ocupação dos buffers e a consistência dos caches passam a decidir a capacidade real do serviço.

Em um modelo denso, cada token percorre praticamente o mesmo conjunto de pesos. Em um modelo MoE, o token passa por um router de experts, que escolhe os experts responsáveis pelo próximo trecho do cálculo. No caso técnico do Kimi K3, são 16 experts roteados entre 896, além dos componentes compartilhados.

Essa esparsidade explica como uma escala total tão alta pode existir sem que cada token pague a conta integral. Também cria a primeira armadilha: uma GPU silenciosa ao lado de outra congestionada não é um detalhe de implementação. É throughput perdido.

A carga não se distribui de forma perfeitamente uniforme. Um prompt de programação, um request com contexto longo e uma pergunta curta podem produzir padrões diferentes de seleção. Se muitos tokens procuram os mesmos experts, surgem filas e tráfego entre ranks mesmo quando a média do cluster parece confortável. A média de GPU é uma fotografia tirada de longe demais.

O monitoramento precisa observar, no mínimo, utilização por expert, tempo de dispatch, tráfego entre ranks, ocupação de memória, tokens processados, tempo até o primeiro token e tempo entre tokens. A arquitetura deixa de ser uma caixa que recebe texto e devolve texto. Ela vira uma pequena bolsa de valores, com ativos muito diferentes disputando a mesma liquidez.

A prévia de serving publicada pelo vLLM resume o conjunto de decisões: 2,8T de parâmetros, contexto de 1 milhão de tokens, 69 camadas KDA, 24 camadas MLA e 896 experts roteados. Cada número quebra uma hipótese comum de serving. Juntos, eles quebram várias ao mesmo tempo.

Por que um modelo MoE de 2,8T precisa de dois tipos de estado de memória?

Um modelo MoE de 2,8T pode exigir dois tipos de estado porque Kimi Delta Attention, ou KDA, mantém um estado recorrente atualizado no lugar, enquanto Multi-head Latent Attention, ou MLA, conserva um KV cache associado às posições do contexto. Um estado é mutável. O outro cresce com os tokens e pode ser paginado.

A diferença parece acadêmica até o primeiro prefixo compartilhado. No MLA, o serving guarda chaves e valores de blocos já processados. Um novo request que compartilha o prefixo reutiliza esses blocos sem recalcular tudo. O KV cache é append-only: o passado não muda quando o próximo token chega.

O estado KDA é outra criatura. Cada camada mantém uma estrutura recorrente que é sobrescrita a cada token. Um estado compartilhado não pode ser entregue diretamente a duas continuações que irão atualizá-lo. Antes de avançar, o servidor precisa restaurar o checkpoint em um slot privado. Depois, precisa capturar o novo estado em um ponto seguro para que outra request possa reutilizá-lo.

O problema operacional tem nome: copy-on-write. O servidor compartilha o checkpoint até o momento em que uma sequência diverge, copia o estado para uma área própria e permite a mutação. Na continuação, o servidor precisa preservar uma cópia privada do estado antes de permitir novas mutações. O material técnico de SGLang e Miles descreve a gestão combinada desses estados, com reutilização segura, unified memory e paralelismo por fase.

A distinção muda a contabilidade de memória. Pesos, estado KDA e KV cache MLA não têm o mesmo ciclo de vida. Reservar um único bloco chamado “memória do modelo” é a forma mais rápida de descobrir, em produção, que o modelo cabe no cluster, mas a segunda request não cabe na réplica.

Como o estado KDA e o KV cache de MLA mudam o serving?

O scheduler precisa alinhar dois estados físicos diferentes na mesma fronteira lógica do prefixo. O estado KDA é mutável e exige cópia privada antes da continuação. O KV cache MLA cresce com os tokens e pode ser paginado. Essa diferença determina quando um request reaproveita trabalho e quando paga memória e prefill outra vez.

O ponto é simples. O cache não é um bloco único.

O prefix caching tradicional parte de uma unidade simples: blocos completos de tokens. Para KDA, guardar um estado grande em cada bloco pequeno custa memória demais. Guardar apenas em blocos grandes economiza espaço, mas reduz os pontos em que um prefixo pode ser reaproveitado. Duas requests que compartilham quase todo o prompt podem divergir antes da fronteira física e perder uma reutilização valiosa.

A implementação descrita na prévia de suporte ao Kimi K3 no vLLM separa três decisões: o tamanho físico do bloco de estado, o alinhamento exigido pelo scheduler e a granularidade usada para identificar o prefixo. O estado pode ocupar um bloco físico maior, enquanto o hash reconhece uma fronteira mais fina.

Quando há um partial prefix-cache hit, o estado KDA correspondente precisa ser copiado para um destino privado antes de a continuação avançar. O KV cache pode continuar compartilhado até a escrita de novos tokens. Essa cópia não é uma falha do cache. É o preço correto para preservar uma estrutura mutável sem corromper o prefixo de outra request.

O cache também muda a economia do prefill. Em uma carga de coding, na qual várias requests reaproveitam instruções, ferramentas e histórico, um hit no prefixo evita recalcular a parte mais cara do prompt. O anúncio do Kimi informa mais de 90% de cache hit na API oficial para workloads de coding. Esse número pertence àquela arquitetura e àquela carga. Não é uma taxa que um operador possa importar para qualquer tráfego.

O que o LatentMoE economiza e o que ele torna mais difícil?

O Kimi K3 usa Stable LatentMoE para rotear 16 dos 896 experts em um espaço latente de 3.584 dimensões, segundo a descrição técnica do SGLang. A leitura de que essa representação menor pode reduzir o custo de mover e processar experts é uma inferência arquitetural, não um resultado de custo medido nas fontes. A esparsidade corta cálculo. Ela não elimina a necessidade de colocar o expert certo no acelerador certo no momento certo.

O Kimi K3 combina 896 experts e 16 experts ativos por token. A execução precisa calcular scores, selecionar experts, agrupar tokens e despachá-los para os ranks que possuem os pesos correspondentes. Depois, precisa reunir as saídas e restaurar a ordem esperada pelo restante da rede.

Esse ciclo é sensível ao formato do batch. Em batch pequeno, lançar centenas de kernels pequenos pode custar mais do que a aritmética. Em batch grande, o problema muda: a comunicação e o balanceamento começam a dominar. O trabalho do serving deixa de ser “usar a GPU” e passa a ser não criar uma procissão de microtarefas que chega atrasada ao próximo collective.

A quantização MXFP4 ajuda a manter os pesos dentro de uma pegada de memória administrável. O anúncio técnico também descreve ativações MXFP8 e treinamento consciente de quantização. A configuração de implantação publicada pela AWS mostra uma rota de referência com pesos MXFP4, paralelismo tensorial em oito aceleradores e backend MoE compatível.

Isso documenta uma configuração. Não transforma toda infraestrutura em uma fórmula universal.

Quantização não é sinônimo de memória livre. Pesos comprimidos dividem espaço com cópias de runtime, buffers temporários, ativações, gráficos CUDA, estado KDA, KV cache MLA e área de comunicação. Um servidor pode carregar os pesos e ainda falhar ao admitir uma nova sequência de contexto longo. O primeiro número diz que o modelo cabe. O segundo diz quantas requests cabem junto dele.

Onde prefill, decode e paralelismo divergem?

Prefill e decode pressionam partes diferentes do serving. Prefill processa muitos tokens e favorece lotes grandes, chunks e sobreposição de comunicação. Decode repete passos pequenos, sensíveis à latência, aos launches de kernel, ao estado recorrente e à capacidade de cache por request. O paralelismo precisa respeitar essa assimetria.

São fases diferentes.

A arquitetura de paralelismo precisa respeitar essa diferença. Usar a mesma configuração para as duas fases porque o arquivo de deployment aceita um único valor é uma decisão administrativa, não uma decisão de performance.

1. Prefill: divide o prompt em chunks e mantém as etapas ocupadas, escondendo a transferência entre estágios atrás do cálculo do próximo chunk.
2. Decode: preserva o estado KDA, acessa o KV cache MLA e reduz o tempo de cada passo. Throughput agregado não basta.
3. Expert parallelism: distribui experts por ranks e paga comunicação para enviar tokens ao expert responsável, com ganho quando o balanceamento supera esse custo.
4. Tensor parallelism: no Kimi K3, não fragmenta o KV cache da MLA porque há uma única cabeça de KV; cada rank mantém uma cópia completa, enquanto as GEMMs são divididas em oito e pagam um collective por camada, segundo o estudo do SGLang.
5. Serving disaggregated: separa trabalhadores de prefill e decode, permitindo que cada grupo seja dimensionado para o perfil de tráfego que atende.

O estudo do SGLang sobre o suporte ao Kimi K3 descreve prefill com pipeline paralelo em chunks e decode com context parallelism. Também registra uma configuração disaggregated que alcançou 2.808 tokens por segundo por GPU com pipeline paralelo em chunks, context parallelism e a topologia descrita no estudo.

O número é uma medição daquela topologia, hardware e protocolo. Não é uma promessa para qualquer cluster.

Throughput agregado pode esconder uma experiência ruim por usuário. Um cluster pode produzir muitos tokens por segundo e ainda entregar o primeiro token lentamente se o prefill estiver congestionado. Também pode ter bom TTFT e decode lento, transformando uma resposta longa em uma fila com aparência de sucesso.

Quanto de infraestrutura é necessário para hospedar os pesos?

A infraestrutura depende do formato dos pesos, do número de réplicas, do contexto admitido, do cache e da topologia de comunicação. As fontes confirmam uma escala de deployment com MXFP4 e oito aceleradores em uma instância de referência. Esse dado delimita uma configuração documentada, não uma cifra fixa para todo workload.

A conta começa pelos pesos.

A capacidade precisa ser lida em seis envelopes encadeados. Cada um limita o seguinte, e a folga desaparece quando o tráfego combina contexto longo, concorrência e comunicação entre ranks.

1. Pesos: cópia comprimida do modelo total, distribuída segundo a estratégia de paralelismo.
2. Runtime: buffers de kernels, workspace, gráficos e áreas de comunicação.
3. Estado por request: estado KDA, que cresce com o número de sequências ativas.

Os três primeiros dizem quanto custa colocar o modelo de pé. Os três seguintes dizem quanto ele suporta em serviço.

1. Contexto: KV cache MLA, que cresce com tokens armazenados e tamanho do batch.
2. Replicação: cópias adicionais para disponibilidade, regiões, picos ou isolamento de workloads.
3. Transferência: rede interna usada em tensor parallelism, expert parallelism, cache transfer e serving disaggregated.

A soma define o limite de admissão de contexto e concorrência. Se a operação reserva quase toda a memória para o cache longo, falta espaço para o estado de novas sequências. Se reserva quase tudo para estados KDA, o KV cache MLA vira o teto.

A proposta de unified memory apresentada no material do SGLang tenta reduzir essa aposta: um pool único permite que estados KDA e blocos MLA ocupem a capacidade conforme o workload muda. Isso é gestão de capacidade, não mágica de hardware. Unified memory não diminui os pesos e não faz uma GPU caber onde não cabe. Apenas evita que um pool fique cheio enquanto bytes inutilizados permanecem presos no outro.

A cifra de aproximadamente 5 TB não entra nesta análise como fato. A lista de fontes do briefing não sustenta uma decomposição verificável desse total entre pesos, runtime, estados, réplicas e comunicação. Sem essa decomposição, o número impressiona mais do que informa.

O que essa arquitetura muda para o roteamento de modelos?

Para uma camada de roteamento, a capacidade do destino vira uma variável operacional. O roteador não hospeda o Kimi K3, não controla seus kernels e não administra a memória física das GPUs. Ele pode encaminhar cada request conforme custo, latência, contexto, desempenho, disponibilidade e carga observada. A arquitetura do endpoint passa a informar a decisão de tráfego.

O nome do modelo não basta.

Um request com prefixo longo e alta probabilidade de reutilização não tem o mesmo custo operacional que uma pergunta curta sem cache. Um request que exige contexto de 1 milhão de tokens não deveria disputar o mesmo caminho de um request simples só porque ambas usam o mesmo nome de modelo. O nome do modelo é informação insuficiente para a decisão.

O Nexforce Router atua como gateway e camada de roteamento entre aplicações e modelos. Suas regras podem considerar custo, performance, latência e contexto, distribuir carga, aplicar limites por chave e fazer failover. A fronteira é importante: o Router governa o tráfego que chega a um endpoint. O fornecedor ou operador do endpoint continua responsável pela arquitetura física de serving.

Uma política de roteamento para modelos grandes precisa observar quatro sinais antes de encaminhar:

1. Elegibilidade: o destino suporta a janela de contexto, a modalidade e o formato de saída exigidos?
2. Estado provável: o request tem prefixo reutilizável ou chega como cache miss que exigirá prefill completo?
3. Carga: o destino tem capacidade de decode, memória para novos estados e margem para o batch atual?
4. Economia: o ganho de qualidade justifica o custo de ativar uma rota de grande footprint quando a latência aumenta?

Roteamento pelo menor preço, sozinho, é uma armadilha. O modelo mais barato por token pode produzir mais tokens, perder o prefixo, sofrer com uma fila de experts ou devolver uma resposta lenta demais para o SLA. A variável que importa é custo por resultado dentro do contrato de latência, não o preço isolado na tabela.

A comparação de custos de LLM em 2026 fica mais precisa quando o custo de serving entra na conta. A decisão não escolhe o modelo pelo menor preço por token. Ela pergunta qual destino entrega o resultado exigido com a combinação aceitável de cache, latência, carga e qualidade.

Quais são as limitações da análise?

A análise separa três camadas: fatos arquiteturais confirmados, configurações de infraestrutura documentadas e implicações de roteamento. As fontes sustentam a arquitetura KDA e MLA, os números do Kimi K3 e os caminhos de serving descritos. Elas não sustentam um custo universal, uma capacidade fixa por réplica ou um SLA para qualquer cluster.

A fronteira importa.

Estão confirmados: 2,8T de parâmetros, cerca de 104B ativos, 896 experts, 16 experts ativos por token, contexto de 1 milhão de tokens, combinação de KDA e MLA, pesos MXFP4 e alterações específicas no cache e nos kernels. Também estão documentados os desafios de estado mutável, unified memory, paralelismo por fase e serving disaggregated.

Não está confirmado por uma única fonte universal: o custo exato para cada empresa, a quantidade final de GPUs para cada SLA, a taxa de cache em um workload que não seja coding, a utilização média de experts em tráfego próprio ou a capacidade por réplica em outro hardware. Esses números exigem benchmark com prompts, comprimentos, concorrência e SLOs reais.

A conclusão editorial é mais estreita e mais útil: quanto maior o modelo esparso, menos sentido faz medir o serving apenas pelo número de parâmetros ou pelo preço por token. O sistema precisa medir estado, cache, comunicação, fase e destino.

O melhor argumento a favor do MoE aberto também é condicional

O argumento mais forte a favor de servir um modelo MoE aberto é direto: a empresa ganha controle sobre a colocação do modelo, pode adaptar a pilha de serving ao próprio workload e deixa de depender de uma capacidade externa cujo preço, disponibilidade e política podem mudar. A ativação esparsa torna a escala total menos assustadora por token. A quantização reduz a pressão dos pesos. O cache transforma prefixos repetidos em trabalho já pago.

Esse argumento é sólido. Seria um erro tratá-lo como uma fantasia.

O problema é que controle não elimina custo. Ele o redistribui. A empresa passa a pagar pela distribuição dos experts, pela interconexão, pela engenharia de kernels, pelo desenho de pools de memória, pela observabilidade e pela capacidade ociosa necessária para sobreviver a picos. Um modelo que parece barato na planilha de pesos pode ficar caro quando a réplica precisa manter contexto longo, reservas de failover e margem para prefill congestionado.

A conclusão condicional é esta: pesos abertos são uma vantagem de infraestrutura quando o workload tem volume, repetição de prefixos e requisitos de controle suficientes para pagar a complexidade. Para tráfego irregular ou de baixa utilização, a mesma liberdade pode virar capacidade parada.

A decisão madura não pergunta se MoE é barato. Pergunta qual parte da conta a operação está disposta a possuir.

Perguntas frequentes sobre modelo MoE de 2,8T em produção

Um modelo MoE de 2,8T não aplica todos os parâmetros a cada token, mas a operação ainda precisa distribuir os pesos totais e coordenar experts, estado KDA, KV cache MLA, memória de runtime e comunicação. A decisão de produção depende da carga, da topologia e do contrato de latência, não do número da manchete isolado.

Um modelo MoE de 2,8T usa 2,8T de parâmetros em cada token?

Não. No caso técnico do Kimi K3, 16 entre 896 experts roteados são ativados por token, com cerca de 104 bilhões de parâmetros ativos. Os pesos totais continuam precisando ser distribuídos e mantidos disponíveis para que o router escolha os experts corretos.

KDA substitui completamente o KV cache MLA?

Não. KDA e MLA têm funções e estados diferentes na arquitetura híbrida. O serving precisa manter o estado recorrente KDA e o KV cache MLA alinhados na mesma fronteira lógica do prefixo.

Prefix caching funciona do mesmo jeito em KDA e MLA?

Não. O KV cache MLA é append-only e pode ser paginado por blocos de tokens. O estado KDA é mutável e exige checkpoints, copy-on-write e cópias ordenadas antes de a continuação alterar o estado compartilhado.

MXFP4 resolve o problema de memória?

MXFP4 resolve parte do problema dos pesos, mas não encerra a conta de memória. O serving ainda reserva runtime, estado KDA, KV cache MLA, buffers, réplicas e comunicação. Por isso, o carregamento bem-sucedido do modelo não prova que a réplica sustenta a concorrência esperada.

O peso é só a entrada.

O Nexforce Router hospeda o Kimi K3?

Não. O Nexforce Router é uma camada de gateway e roteamento. Ele distribui requests entre destinos e pode aplicar regras de custo, latência, contexto, carga e failover, sem controlar kernels ou memória física do serving.

Referências e Leitura Complementar

• Kimi K3: Open Frontier Intelligence, anúncio técnico da Moonshot AI, julho de 2026.
• Kimi K3: Open Frontier Intelligence, relatório técnico, submetido em 27 de julho de 2026.
• A Preview of Production-Scale Kimi K3 Support on vLLM, 22 de julho de 2026.
• SGLang and Miles Add Day-0 Support for Kimi K3, 27 de julho de 2026.
• Deploying Kimi K3 on Amazon SageMaker HyperPod and Amazon EKS, 30 de julho de 2026.
• Kimi K3 repository, implementação e arquivos de deployment.

A próxima avaliação do serving

A próxima avaliação de um modelo desse porte não deveria começar perguntando quantos parâmetros ele tem. Deveria perguntar quantos estados cabem, quantos prefixos são reutilizados e quanto da comunicação fica no caminho crítico. A escala impressiona na apresentação. O serving decide se ela vira produto ou apenas uma fotografia muito cara de uma GPU ocupada.