Como Executar o Kimi K3 Localmente: Hardware, Memória e Limites de Implementação

Executar o Kimi K3 completo localmente é possível com os pesos lançados, mas a implementação prática ainda requer memória, aceleradores e interconexões em escala de cluster.

Após o lançamento de pesos abertos a 27 de julho, a questão já não é se existe um ponto de verificação, mas se o seu sistema pode descarregar, carregar e servir o modelo a uma velocidade útil. O repositório público tem cerca de 1,56 TB distribuídos por 96 fragmentos safetensor, enquanto o modelo contém 2,8 triliões de parâmetros totais e ativa 104 mil milhões por token. Esses números mantêm um PC normal, Mac, NAS doméstico ou servidor com GPU única fora do alcance prático do modelo completo, por isso as secções abaixo separam armazenamento, memória, topologia de aceleradores, suporte de runtime e caminhos realistas de fallback.

O que está disponível agora que os pesos do Kimi K3 foram lançados?

O lançamento de pesos abertos do Kimi K3 inclui o ponto de verificação completo do modelo e o relatório técnico. O repositório público do modelo mostra atualmente cerca de 1,56 TB de ficheiros e 96 fragmentos safetensor numerados. Esse valor é útil para planear downloads e capacidade de disco, mas não é uma especificação mínima de VRAM.

O resumo do modelo lançado confirma 2,8T de parâmetros totais, 104B de parâmetros ativados, 93 camadas, 69 camadas de Atenção Delta Kimi e 24 camadas MLA Gated. O seu roteamento Stable LatentMoE seleciona 16 dos 896 especialistas roteados por token e também usa dois especialistas partilhados. Os pesos são MXFP4, as ativações são MXFP8, e o contexto máximo anunciado é de 1.048.576 tokens.

O suporte à implementação também é mais concreto do que antes do lançamento. vLLM, SGLang e TokenSpeed são listados como motores de inferência recomendados, mas cada um requer kernels, código de modelo, fragmentação e configurações de memória compatíveis com K3. Um comando genérico mostrado por uma biblioteca cliente não transforma o checkpoint num modelo local em escala de consumidor.

Por Que o MoE Esparso Ainda Requer Memória Enorme?

O Kimi K3 realiza o cálculo com 104B parâmetros ativados para cada token, mas todos os especialistas MoE ainda consomem armazenamento e memória de serviço. O roteador pode selecionar diferentes especialistas para o próximo token, portanto, o conjunto completo de pesos de 2,8T deve permanecer acessível em algum lugar na implementação.

Selecionar 16 dos 896 especialistas roteados reduz o trabalho do especialista realizado para um token. Isso não significa que uma máquina pode manter apenas 16 especialistas, descartar o resto e ainda assim executar o modelo lançado sem alterações. A poda de especialistas, destilação ou streaming criaria um compromisso operacional diferente e não deve ser confundido com ativação esparsa normal.

O valor de 104B ativados é, portanto, uma descrição da escala de cálculo, não um atalho para estimar o tamanho do checkpoint. Multiplicar 104B por quatro bits e afirmar que o modelo precisa de apenas cerca de 52 GB ignoraria pesos de especialistas inativos mas ainda necessários, componentes densos, especialistas compartilhados, camadas de atenção, pesos de visão e estado em tempo de execução.

Qual é o Limite Inferior Mínimo de Memória para Pesos?

Com 2,8 triliões de parâmetros, o cálculo mais simples do limite inferior é o total de parâmetros multiplicado pelos bits armazenados por parâmetro. O MXFP4 oferece um piso de carga útil de quatro bits: 2,8T × 4 bits são cerca de 1,4 TB, ou aproximadamente 1,27 TiB, apenas para a carga útil bruta dos pesos.

O repositório lançado tem cerca de 1,56 TB, o que mostra porque a memória de serviço vai além de um simples cálculo de peso. O empacotamento do ponto de verificação, escalas de bloco, alinhamento de tensores, ficheiros de configuração, ativos do tokenizador, componentes de visão e outros dados do modelo elevam o download real acima do limite teórico de quatro bits.

Quatro orçamentos diferentes devem ser planeados separadamente: armazenamento persistente para download, espaço temporário de preparação, RAM do host e HBM ou VRAM do acelerador. Um serviço em execução precisa então de espaço adicional para estado KDA, cache MLA KV, ativações, buffers de comunicação, núcleos, captura de gráfico e margem para falhas. O tamanho do repositório de 1,56 TB não é, portanto, um requisito completo de RAM nem de memória GPU.

Que Hardware Pode Realmente Executar o Kimi K3 Localmente?

Não existe uma lista honesta de GPUs mínimas orientadas ao consumidor para o modelo completo. Um sistema que tecnicamente pode mapear ou transmitir o ponto de verificação não é automaticamente capaz de um serviço estável e interativo. Os requisitos práticos de hardware para o Kimi K3 dependem da residência do peso, núcleos MXFP4 suportados, largura de banda de interconexão, capacidade de cache, comprimento do contexto, concorrência e motor de serviço.

O suporte day-zero Kimi K3 publicado coloca a classe inicial realista num nó empresarial com oito aceleradores. Os materiais atuais do vLLM descrevem aceleradores da classe GB300 ou MI350X/MI355X como pontos de partida, enquanto o SGLang publica exemplos conscientes da topologia incluindo B300 1×8, GB300 2×4, B200 2×8, H200 2×8, H100 4×8 e MI350X/MI355X 1×8.

Estas são receitas de runtime publicadas e configurações iniciais, não um mínimo certificado único para cada carga de trabalho. Aceleradores mais antigos ou menores podem exigir mais nós, diferentes núcleos de quantização, contexto reduzido ou paralelismo especializado adicional. O tráfego de produção também precisa de capacidade para pedidos concorrentes, trabalhadores falhados e margem de desempenho, e não apenas para caber o ponto de verificação uma vez.

Porque é que um único posto de trabalho ou NAS continua a ser a topologia errada?

A divisão bruta da capacidade subestima o problema. Mesmo que memória agregada suficiente seja montada, o paralelismo por especialistas transforma o encaminhamento em tráfego de rede. Os tokens devem chegar aos aceleradores que detêm os seus especialistas selecionados e depois regressar ao resto do pipeline do modelo.

Os nós aceleradores empresariais fornecem mais do que memória. Combinam ligações GPU de alta largura de banda, redes com capacidade RDMA, bibliotecas de comunicação coletiva e kernels desenhados para paralelismo tensorial, de especialistas, de dados ou de pipeline. Uma coleção de GPUs de consumo ligadas por PCIe comum ou rede doméstica pode mostrar capacidade nominal suficiente, mas ser demasiado lenta ou frágil para um serviço útil.

Um NAS é valioso para armazenar fragmentos de checkpoints, logs, conjuntos de dados, índices de recuperação e dados de aplicação, mas o armazenamento em rede não substitui a largura de banda da memória do acelerador. O papel melhor para um servidor doméstico é geralmente manter os dados privados e a recuperação perto do utilizador, deixando a inferência de modelos de ponta para um cluster adequado ou ponto final alojado. Nesse design, um servidor doméstico separa a camada local de dados da inferência de ponta.

Como é que o Estado KDA, o Cache KV MLA e o Comprimento do Contexto aumentam o orçamento?

O Kimi K3 não usa um cache de atenção total uniforme em todas as 93 camadas. As suas 69 camadas KDA e 24 camadas MLA com gate criam duas demandas diferentes de memória de serviço: um pool de estado KDA com geometria fixa do modelo para pedidos admitidos, e um pool paginado de memória KV MLA que cresce com os tokens armazenados.

Esta divisão significa que o KDA pode reduzir o crescimento do contexto longo encontrado na atenção convencional, mas não torna um pedido de um milhão de tokens gratuito. Como o estado KDA e a memória KV MLA competem pela capacidade do acelerador, o lado KDA pode limitar os pedidos admitidos enquanto o lado MLA limita o total de tokens em cache.

O tamanho do lote, concorrência, comprimento médio do prompt, comprimento do raciocínio gerado, entradas multimodais, precisão do cache e estratégia de pré-preenchimento/decodificação alteram todos a capacidade utilizável. A cifra de 1M tokens é uma capacidade máxima do modelo, não um padrão recomendado. Uma primeira implementação deve começar com um contexto máximo mais curto, lote um e baixa concorrência antes de medir falhas por falta de memória, tempo de pré-preenchimento, velocidade de decodificação e tráfego entre nós.

Como Pode Executar o Kimi K3 Localmente Após o Lançamento do Peso Aberto?

Executar o Kimi K3 localmente agora significa construir um serviço de inferência distribuída em torno do checkpoint lançado, não instalar uma aplicação de ambiente de trabalho normal. A sequência mais segura é validar o armazenamento, suporte ao runtime, topologia e um ponto de operação pequeno antes de aumentar o contexto ou o tráfego.

1. Prepare o armazenamento. Reserve pelo menos a pegada do repositório de cerca de 1,56 TB mais espaço extra para downloads parciais, caches, imagens de contentores, registos e ficheiros temporários.
2. Selecione um motor suportado. Use um caminho de implementação vLLM, SGLang ou TokenSpeed específico para Kimi K3 com o código do modelo, kernels e versão do contentor ou ramo necessários.
3. Combine a topologia. Escolha uma configuração empresarial multi-GPU ou multi-nó com HBM suficiente e o caminho NVLink, MNNVL ou RDMA esperado pelas definições de paralelismo tensorial e especializado.
4. Comece abaixo dos limites principais. Reduza o comprimento máximo do modelo, o tamanho do lote e a concorrência, depois verifique o carregamento, comportamento de falta de memória (OOM), correção da saída, velocidade de pré-preenchimento, velocidade de decodificação e tráfego all-to-all.
5. Escale apenas após medição. Adicione contexto, pedidos concorrentes, funcionalidades de cache, entradas multimodais ou decodificação especulativa uma variável de cada vez.

Um comando como vllm serve ou sglang serve descreve como iniciar um runtime distribuído compatível; não elimina o requisito de hardware. Quando a classe de acelerador necessária não está disponível, as escolhas realistas são uma API hospedada, uma arquitetura híbrida que mantém os ficheiros e a recuperação local, ou um modelo local mais pequeno que se ajuste à memória e fiabilidade reais do servidor doméstico.

Perguntas Frequentes

Posso executar o Kimi K3 localmente num PC normal, Mac ou NAS doméstico?

Não na velocidade prática do modelo completo. O repositório tem cerca de 1,56 TB antes da sobrecarga de serviço, enquanto um sistema local normal também não possui a memória aceleradora nem a topologia de alta largura de banda esperadas pelos runtimes atuais. Streaming experimental especializado ou descarregamento pesado podem provar que um lançamento é tecnicamente possível, mas não é equivalente a um serviço responsivo ou pronto para produção.

Quanta capacidade de armazenamento e memória o Kimi K3 requer?

O piso transparente de carga útil de peso MXFP4 é cerca de 1,4 TB, enquanto o repositório público é cerca de 1,56 TB. Depois precisa de espaço extra em disco, RAM do anfitrião, HBM ou VRAM do acelerador, estado KDA, cache MLA KV, ativações, espaço de trabalho de comunicação e margem operacional. Não existe um único número que represente todas essas camadas.

Qual é a configuração mínima de GPU publicada para o Kimi K3?

As configurações publicadas mais pequenas do dia zero são nós empresariais com oito aceleradores, com os caminhos atuais vLLM e SGLang centrados em hardware da classe B300, GB300 ou MI350X/MI355X. Considere esses como pontos de partida para o runtime, não um mínimo universal garantido; contexto, concorrência, versão do motor e objetivos de produção podem exigir mais recursos.

O Kimi K3 pode ser executado a partir de SSD ou descarregamento NAS?

O armazenamento SSD ou NAS pode conter fragmentos do checkpoint, e ambientes experimentais podem transmitir pesos através da memória do anfitrião. A questão limitadora é o movimento repetido dos pesos e estado dos especialistas através do armazenamento, rede, RAM e ligações PCIe. Esses caminhos são muito mais lentos do que a HBM do acelerador e as redes de alta velocidade da GPU, por isso um lançamento experimental pode apresentar latência inutilizável.

O Ollama executa o modelo completo Kimi K3 localmente?

A atual entrada Ollama Kimi K3 usa a etiqueta kimi-k3:cloud. Executar um cliente Ollama local não significa que o checkpoint de 1,56 TB está carregado na máquina local; a rota listada é suportada na cloud.

Conclusão Final

O Kimi K3 está agora genuinamente disponível como um modelo de pesos abertos, para que os operadores de cluster possam descarregar e implementar o checkpoint completo em vez de depender de estimativas pré-lançamento. O lançamento altera a verificação e a disponibilidade de ferramentas, mas não altera a escala física de um modelo de 2,8T parâmetros.

Os números de memória mais úteis do Kimi K3 respondem a diferentes questões: cerca de 1,4 TB é o piso transparente apenas para pesos de quatro bits, cerca de 1,56 TB é a pegada atual do repositório, e 104B é a escala de computação ativada por token. Nenhum desses números isoladamente descreve a memória completa necessária para um serviço em funcionamento.

Para a maioria dos indivíduos e utilizadores de servidores domésticos, o limite é claro: sem um nó empresarial com oito aceleradores ou um cluster distribuído, utilize inferência hospedada, mantenha os dados privados e a camada de recuperação local, ou escolha um modelo mais pequeno. Essa é a forma prática de beneficiar do Kimi K3 sem tratar um NAS, estação de trabalho ou GPU única como um supernó de modelo de fronteira.