Implantando o Kimi K3 na AWS

Um novo marco em modelos de IA de código aberto

Modelos de IA com pesos abertos (open-weight) evoluíram a ponto de suportar tarefas complexas como fluxos de trabalho agênticos de múltiplas etapas, raciocínio avançado e programação de longa duração. Mas à medida que essas capacidades crescem, a infraestrutura necessária para hospedá-los também cresce — e chegamos a um ponto em que arquiteturas com trilhões de parâmetros exigem hardware de ponta, GPUs de alto desempenho e frameworks de serving otimizados.

Em 27 de julho de 2026, a Moonshot AI lançou o Kimi K3: um modelo com 2,8 trilhões de parâmetros baseado em arquitetura Mistura de Especialistas (MoE — Mixture of Experts) e que se tornou o primeiro modelo open-weight a atingir a classe dos 3 trilhões de parâmetros. O diferencial do Kimi K3 é entregar inteligência de nível frontier mantendo os pesos publicamente disponíveis — o que permite que organizações hospedem um dos modelos mais capazes do mundo em sua própria infraestrutura.

A AWS publicou um guia técnico detalhando como implantar o Kimi K3 utilizando duas abordagens: o Amazon SageMaker HyperPod e o Amazon Elastic Kubernetes Service (Amazon EKS).

O que é o Kimi K3

O Kimi K3 é construído sobre uma arquitetura diferenciada que combina três componentes principais: Kimi Delta Attention (KDA), Gated Multi Head Latent Attention (MLA) e o framework Stable LatentMoE. O modelo distribui seus 2,8 trilhões de parâmetros entre 896 especialistas, ativando apenas 16 por token — o que significa que aproximadamente 104 bilhões de parâmetros ficam ativos em cada passagem direta (forward pass). Esse design resulta em uma melhoria de 2,5x na eficiência de escalonamento em relação ao seu predecessor, o Kimi K2.

Confira as principais especificações técnicas do modelo:

Total de Parâmetros: 2,8 trilhões
Parâmetros Ativos por Token: 104 bilhões
Arquitetura: Mistura de Especialistas (MoE)
Quantidade de Especialistas: 896 (16 ativados por token)
Janela de Contexto: 1 milhão de tokens
Modalidade: Multimodal nativo (Texto + Visão)
Data de Lançamento: 27 de julho de 2026

O modelo se destaca em tarefas de programação de longa duração, fluxos de trabalho agênticos e raciocínio complexo. Suporta nativamente chamadas de ferramentas (tool calling), saída estruturada e um modo de raciocínio sempre ativo para resolução de problemas em múltiplas etapas.

Disponibilidade e formato do modelo

Os pesos abertos do Kimi K3 estão disponíveis no Hugging Face sob o identificador moonshotai/Kimi-K3. Os pesos são distribuídos no formato MXFP4 (Microscaling Floating Point 4-bit), que oferece um equilíbrio eficiente entre qualidade do modelo e eficiência de memória para implantações de inferência em larga escala.

Dado o tamanho e a arquitetura do modelo, o serving do Kimi K3 requer um container de inferência vLLM day-0. No momento da publicação do guia original, os commits do vLLM para o Kimi K3 estavam disponíveis em vllm/vllm-openai:kimi-k3, com previsão de integração ao container principal do vLLM nas próximas versões. O vLLM oferece suporte nativo a arquiteturas MoE, paralelismo tensorial (tensor parallelism) e ao formato de quantização MXFP4, sendo o engine de serving recomendado para esse modelo.

Requisitos de infraestrutura

Implantar um modelo dessa escala exige GPU compute substancial. O Kimi K3 requer a instância p6-b300 (ml.p6-b300.48xlarge), que oferece 8 GPUs NVIDIA B300 Blackwell Ultra com interconexões de alta largura de banda — necessárias para inferência tensorial paralela eficiente em todo o pool de especialistas.

A AWS disponibiliza dois mecanismos principais para provisionar essa capacidade:

Flexible Training Plans (para SageMaker HyperPod): Fornecem reservas de capacidade comprometida que podem ser alocadas ao seu cluster HyperPod, garantindo que os recursos de GPU estejam disponíveis para cargas de trabalho de inferência contínuas.
Capacity Blocks: Permitem reservar instâncias EC2 GPU por um período definido, garantindo acesso à capacidade p6-b300 sem compromissos de longo prazo. As cargas de trabalho no Amazon EKS consomem essas reservas direcionando-se à capacidade reservada.

Opção 1: Implantando no Amazon SageMaker HyperPod

O Amazon SageMaker HyperPod com o Inference Operator oferece o caminho mais direto para implantar o Kimi K3. O Inference Operator é instalado automaticamente durante a criação do cluster e abstrai toda a complexidade de orquestração de containers, carregamento do modelo e gerenciamento de endpoints.

Pré-requisito 1: Criando o cluster SageMaker HyperPod com orquestração EKS

Antes de implantar o modelo, é necessário provisionar um cluster HyperPod. Os passos são:

Acesse o console do Amazon SageMaker AI e selecione HyperPod Clusters > Cluster Management > Create HyperPod cluster.
Escolha Orchestrated by Amazon EKS.
Selecione Quick setup para provisionar com configurações padrão de rede, armazenamento e IAM, ou Custom setup para integrar com VPC, subnets e grupos de segurança existentes.
Em Orchestration, crie um novo cluster EKS ou anexe um existente.
Verifique se a opção Use default Helm charts and add-ons está selecionada para que o Inference Operator e outros operadores necessários sejam instalados automaticamente.
Em Instance groups, adicione um grupo de workers configurado com o tipo de instância ml.p6-b300.48xlarge.
Revise a configuração e clique em Submit para iniciar o provisionamento.

Para o guia completo, consulte a documentação Criando um cluster SageMaker HyperPod com orquestração Amazon EKS.

Pré-requisito 2: Provisionando capacidade com um Flexible Training Plan

O tipo de instância ml.p6-b300.48xlarge requer capacidade reservada. Um Flexible Training Plan (FTP) fornece uma reserva de capacidade comprometida para os nós com GPU Blackwell, garantindo que as instâncias p6-b300 estejam disponíveis ao seu cluster sem concorrência com o pool sob demanda geral.

Acesse o console do SageMaker e selecione um bloco FTP com base no seu cronograma e quantidade de instâncias.
Na configuração do grupo de instâncias, escolha Training plan como fonte de capacidade.
Selecione um plano existente que cubra capacidade ml.p6-b300.48xlarge ou crie uma nova reserva especificando a quantidade de instâncias e a duração desejadas.
Defina a Target Availability Zone para corresponder à zona onde a capacidade do seu training plan está alocada.

Quando o cluster atingir o estado Active com nós p6-b300 saudáveis, o ambiente estará pronto para implantar o modelo.

Implantando o modelo no HyperPod

Para implantar o Kimi K3 no HyperPod, aplique o seguinte manifesto InferenceEndpointConfig ao seu cluster. O YAML também está disponível no repositório GitHub:

apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
  name: kimik3
spec:
  modelName: Kimi-K3
  instanceType: ml.p6-b300.48xlarge
  invocationEndpoint: v1/chat/completions
  replicas: 1
  modelSourceConfig:
    huggingFaceModel:
      modelId: moonshotai/Kimi-K3
      modelSourceType: huggingface
  worker:
    image: vllm/vllm-openai:kimi-k3
    modelInvocationPort:
      containerPort: 8000
      name: http
    modelVolumeMount:
      mountPath: /opt/ml/model
      name: model-weights
    resources:
      limits:
        nvidia.com/gpu: 8
      requests:
        nvidia.com/gpu: 8
    args:
      - "--model"
      - "moonshotai/Kimi-K3"
      - "--trust-remote-code"
      - "--load-format"
      - "fastsafetensors"
      - "--enable-prefix-caching"
      - "--enable-auto-tool-choice"
      - "--tool-call-parser"
      - "kimi_k3"
      - "--reasoning-parser"
      - "kimi_k3"
      - "--served-model-name"
      - "Kimi-K3"
      - "--moe-backend"
      - "auto"
      - "--tensor-parallel-size"
      - "8"
      - "--no-enable-flashinfer-autotune"
    environmentVariables:
      - name: "VLLM_ENABLE_K3_LATENT_MOE_TAIL_FUSION"
        value: "1"

Aplique essa configuração com:

kubectl apply -f kimi-k3.yaml

O Inference Operator cuida do download do modelo a partir do Hugging Face, agendamento do container, verificações de saúde e prontidão do endpoint. Quando o endpoint atingir o estado de pronto, ele expõe uma API compatível com OpenAI no caminho de invocação configurado.

Opção 2: Implantando no Amazon EKS

Para equipes que preferem gerenciar sua própria infraestrutura Kubernetes, é possível implantar o Kimi K3 em um cluster Amazon EKS independente, provisionando a capacidade de GPU via EC2 Capacity Blocks — que permitem reservar instâncias p6-b300 por uma duração definida sem compromissos de longo prazo.

O projeto AI on EKS fornece uma receita de cluster pronta para inferência que automatiza o provisionamento de ponta a ponta. Em linhas gerais, a implantação envolve as seguintes etapas:

1. Provisionar o cluster EKS

Use os módulos Terraform fornecidos para criar um cluster EKS otimizado para GPU, incluindo rede VPC, node groups gerenciados e as funções e políticas IAM necessárias para cargas de trabalho com GPU.

2. Reservar capacidade de GPU com Capacity Blocks

Crie uma reserva de Capacity Block para instâncias p6-b300.48xlarge na sua Zona de Disponibilidade alvo. Os Capacity Blocks garantem que os nós GPU solicitados estarão disponíveis durante a janela de tempo reservada. Quando a reserva se tornar ativa, as instâncias ingressam no cluster EKS como nós workers.

3. Instalar drivers de GPU e o device plugin

A receita instala o NVIDIA device plugin e os drivers de GPU no node group, permitindo que o Kubernetes descubra e agende workloads nas GPUs disponíveis.

4. Implantar o servidor de inferência vLLM

Um Helm chart ou manifesto Kubernetes implanta o container vLLM com os argumentos específicos para o Kimi K3, incluindo tensor-parallel size de 8, o formato de carregamento MXFP4 e a configuração do backend MoE. O identificador do modelo aponta para o repositório do Hugging Face ou, alternativamente, é possível sincronizar os pesos do modelo para o Amazon Simple Storage Service (Amazon S3) para carregamento mais rápido. Os argumentos de serving espelham os mostrados na configuração do HyperPod acima.

5. Expor o endpoint de inferência

Um Kubernetes Service (tipo LoadBalancer ou via controller de Ingress) expõe o servidor vLLM na porta 8000, disponibilizando o endpoint /v1/chat/completions compatível com OpenAI para as aplicações.

6. Validar a implantação

Confirme a implantação enviando uma requisição de teste ao endpoint e verificando uma resposta bem-sucedida do modelo.

Para o guia completo de implantação, incluindo módulos Terraform, valores do Helm e instruções passo a passo, consulte a receita Kimi K3 no AI on EKS.

Invocando o endpoint

Após a implantação, o endpoint do Kimi K3 expõe uma API de chat completions compatível com OpenAI. É possível invocá-lo usando o SDK Python da OpenAI ou um simples comando curl.

Usando o SDK Python da OpenAI

from openai import OpenAI

client = OpenAI(
    base_url="http://:8000/v1",
    api_key="not-needed"
)

response = client.chat.completions.create(
    model="Kimi-K3",
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "Explain the benefits of mixture of experts architectures."}
    ],
    temperature=0.7,
    max_tokens=1024
)

print(response.choices[0].message.content)

Usando curl

curl -X POST http://:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Kimi-K3",
    "messages": [
      {"role": "system", "content": "You are a helpful assistant."},
      {"role": "user", "content": "Explain the benefits of mixture of experts architectures."}
    ],
    "temperature": 0.7,
    "max_tokens": 1024
  }'

Substitua <ENDPOINT_URL> pelo endpoint de serviço exposto pelo seu HyperPod Inference Operator ou pela configuração de ingress do EKS.

Limpeza dos recursos

Para evitar cobranças contínuas, é recomendável excluir os recursos criados durante a implantação quando não forem mais necessários.

Para implantações no SageMaker HyperPod:

Exclua o InferenceEndpointConfig executando kubectl delete -f kimi-k3.yaml.
No console do SageMaker AI, navegue até HyperPod Clusters, selecione seu cluster e escolha Delete.
Libere ou cancele sua reserva de Flexible Training Plan, se não for mais necessária.

Para implantações no Amazon EKS:

Exclua o deployment do vLLM e os Kubernetes Services associados.
Encerre o node group de GPU ou exclua o cluster EKS usando Terraform (terraform destroy).
Libere sua reserva de Capacity Block, se ainda não tiver expirado.

Para detalhes de preços sobre instâncias p6-b300 e reservas de Capacity Block, consulte a página de preços do Amazon EC2.

Links úteis

Conclusão

O Kimi K3 representa uma nova fronteira em capacidades de modelos open-weight, e a AWS disponibiliza a infraestrutura e os serviços gerenciados para implantá-lo em escala. Seja pela abordagem simplificada do HyperPod Inference Operator ou pela flexibilidade de um cluster EKS autogerenciado, a combinação de instâncias GPU p6-b300, serving com vLLM e pesos quantizados em MXFP4 entrega uma implantação com verificações de saúde integradas, recuperação automática e verificação de prontidão do endpoint para o maior modelo aberto do mundo.

Fonte

Deploying Kimi K3 on AWS (https://aws.amazon.com/blogs/machine-learning/deploying-kimi-k3-on-aws/)