A Baseten oferece suporte desde o primeiro dia para o Kimi K3 em nossas APIs de Modelo. Agradecemos à Moonshot AI por compartilhar os pesos do Kimi K3 conosco para acesso antecipado, bem como às equipes da Inferact e RadixArk pela colaboração durante todo o processo de desenvolvimento.
O Kimi K3 está disponível hoje nas APIs de Modelo da Baseten com entrada de visão e janela de contexto completa de 1 milhão de tokens.
O Kimi K3 é um novo modelo de fronteira aberto. Com 2,8 trilhões de parâmetros, é muito maior do que qualquer modelo aberto anterior, introduzindo diversos desafios para a construção de uma API de inferência de alto desempenho. Novas técnicas arquiteturais permitem que o Kimi K3 escale além do limite de trilhões de parâmetros dos modelos abertos de fronteira anteriores:
- Atenção Delta Kimi (KDA) e Resíduos de Atenção (AttnRes) como espinha dorsal escalável para a Arquitetura Kimi.
- Especialistas extremamente esparsos, com apenas 16 dos 896 especialistas ativos por vez, organizados usando Stable LatentMoE.
- Um novo codificador de visão para processar entradas de imagem e mapear informações visuais para o espaço latente.
Este artigo descreve o trabalho técnico necessário para executar a nova arquitetura de modelo e os enormes pesos do Kimi K3 em escala a tempo para o lançamento.
Marco 1: Gerar um token
Após receber o acesso antecipado aos pesos do Kimi K3 da equipe da Moonshot AI, nossa primeira prioridade foi simplesmente colocar o modelo em funcionamento.
Gerar nossos primeiros tokens do Kimi K3 exigiu:
- Provisionamento de hardware: Dado o tamanho do Kimi K3, decidimos executar o modelo em sistemas NVIDIA GB300 NVL72.
- Carregamento de pesos: Em MXFP4, os pesos do Kimi K3 têm mais de 1,4 TB de dados.
- Inicialização de um mecanismo de inferência: Trabalhamos com as equipes por trás do vLLM e SGLang para executar versões de pré-lançamento dos mecanismos de inferência para o Kimi K3.
Frequentemente, ao construir APIs do primeiro dia, um passo inicial é portar os pesos para NVFP4 para melhorar o desempenho e a compatibilidade com a NVIDIA Blackwell e nossa pilha de inferência. No entanto, o Kimi K3 usa pesos nativos MXFP4 com ativações MXFP8, e conseguimos usar esses pesos diretamente.
Com os pesos em mãos, trabalhamos em estreita colaboração com a Inferact no vLLM e a RadixArk no SGLang. Antes de executar o Kimi K3 na Pilha de Inferência da Baseten, precisávamos estabelecer uma linha de base em colaboração com os principais mecanismos de inferência de código aberto.
Adicionar suporte para um modelo a um mecanismo de inferência não é trivial. Isso requer implementar o código de modelagem central, kernels otimizados para novas arquiteturas como KDA e construir compatibilidade de frontend para o Kimi K3 em tudo, desde tokenização até chamadas de ferramentas.
A imagem de acesso antecipado do vLLM para GPUs NVIDIA Blackwell nos ajudou a estabelecer a completude básica de recursos, passar nas avaliações iniciais e definir uma meta de desempenho de linha de base. Este trabalho de acomodar características arquiteturais do Kimi K3 como KDA, AttnRes e Stable LatentMoE formou uma base sólida para construirmos. Também realizamos uma validação extensiva do mecanismo de inferência vLLM para o Kimi K3 e fizemos contribuições de volta ao mecanismo de código aberto com base em nosso trabalho.
A imagem de acesso antecipado do SGLang forneceu uma referência para servir o Kimi K3 de forma rápida e confiável. O SGLang tem um histórico de forte suporte para modelos de linguagem de visão, e o Kimi K3 não é exceção. Com a equipe da RadixArk, focamos na compatibilidade de frontend e otimização de kernel, e nossa equipe de engenharia contribuiu com correções para bugs de frontend relacionados ao tratamento de chamadas de ferramentas e saídas estruturadas para apoiar a prontidão para o lançamento.
Agradecemos às equipes da Inferact e RadixArk por construírem lado a lado conosco durante o período de pré-visualização. Este trabalho forneceu uma base essencial para nossa API Kimi K3 e uma oportunidade de contribuir de volta para a comunidade de código aberto.
Marco 2: Validar o mecanismo de inferência
O Kimi K3 é o modelo aberto mais inteligente já criado. É essencial entregar essa inteligência durante a inferência.
Os benchmarks do Kimi K3 mostram forte desempenho em tarefas de agente, que dependem de chamadas de ferramentas precisas e saídas de modelo de alta qualidade.
A validação de qualidade pode ocorrer em diferentes níveis de rigor. Verificações de sanidade simples, como chamar o modelo com um prompt conhecido ou executar um benchmark leve como gsm8k ou BFCL e verificar se os resultados estão dentro da margem de erro, são marcos úteis durante o processo de desenvolvimento para garantir que as coisas não estão saindo dos trilhos. Mas lançar uma API pública exige um benchmarking mais rigoroso.
A equipe da Moonshot AI opera o Verificador de Fornecedores Kimi, que ajuda provedores de inferência a garantir o serviço preciso e de alta fidelidade dos pesos do modelo. Passar no Verificador de Fornecedores Kimi foi um marco inicial essencial em nosso desenvolvimento de API e foi uma ferramenta extremamente útil durante todo o processo de desenvolvimento.
Existem muitas oportunidades de errar no serviço de modelos. Embora a narrativa popular seja que a quantização é a raiz de todos os problemas de qualidade, na prática isso não é verdade. A maioria dos problemas de qualidade, especialmente com chamadas de ferramentas e outros comportamentos estruturados do modelo, vem do frontend do servidor de inferência.
O frontend fica na frente do mecanismo de inferência e processa as entradas e saídas.
O frontend é um código determinístico que roda na CPU antes do loop de inferência. Ele é responsável por aceitar entradas e retornar saídas. O frontend deve:
- Operar e validar a API
- Tokenizar prompts e destokenizar saídas
- Renderizar o template de chat
- Analisar raciocínios e chamadas de ferramentas
- Formatar a saída para ChatCompletions, mensagens ou outro padrão
Essas tarefas são sutilmente diferentes de modelo para modelo, e é muito comum introduzir bugs e degradação de desempenho ao construir rapidamente para suporte no primeiro dia. Verificações robustas como o Verificador de Fornecedores Kimi avaliam o desempenho em modos de falha comuns, como chamadas de ferramentas, para garantir que o modelo seja servido com alto grau de fidelidade tanto no loop de inferência quanto na superfície da API.
À medida que continuávamos a desenvolver a API, usamos o Verificador de Fornecedores Kimi em marcos subsequentes para garantir que as otimizações de desempenho não introduzissem bugs que degradassem a precisão.
Marco 3: Encontrar a configuração correta
Os mecanismos de inferência oferecem uma ampla gama de opções de configuração para ajustar o desempenho a diferentes modelos, hardwares, formatos de tráfego e compensações de latência/throughput. Essas opções e as interações entre elas são complexas.
Para descobrir a configuração correta, fazemos uma varredura em várias opções, como configurações de Paralelismo de Tensor (TP) e Paralelismo de Especialista (EP), alternância de Paralelismo de Dados de Atenção (ADP), dimensionamento de lote, comprimentos de rascunho do decodificador especulativo, intervalos de cache de camada linear, parâmetros de roteamento e configurações do mecanismo de inferência.
O Paralelismo de Tensor e o Paralelismo de Especialista dividem modelos grandes em múltiplas GPUs.
Executar o Kimi K3 requer oito GPUs NVIDIA GB300 para caber os enormes pesos do modelo na VRAM. No entanto, ao contrário de muitas outras GPUs NVIDIA que vêm em nós de oito, as GB300 vêm em nós de quatro. Embora isso possa inicialmente parecer limitar as estratégias de paralelismo possíveis – o Paralelismo de Tensor tradicionalmente não é possível entre nós, pois interconexões lentas tornam operações caras de all-reduce um gargalo para inferência – o sistema GB300 NVL72 tem uma interconexão suficientemente rápida entre nós para que possamos executar inferência com Paralelismo de Tensor e Paralelismo de Especialista entre nós.
Essas decisões de configuração são posteriores à escolha do mecanismo de inferência. Engenheiros trabalharam em paralelo para configurar vLLM, SGLang e nosso próprio mecanismo interno, compartilhando descobertas e aplicando aprendizados de volta ao nosso mecanismo de inferência interno, enquanto também contribuíam com PRs de volta aos mecanismos de código aberto.
Marco 4: Otimizar o desempenho
Depois que um modelo está em funcionamento em uma configuração otimizada, há um grande número de técnicas de engenharia de inferência que podem melhorar materialmente a latência, o throughput ou uma combinação de ambos. Para APIs de modelo, geralmente consideramos:
- Especulação: Usar um modelo de rascunho pequeno para prever múltiplos tokens e, em seguida, validá-los como parte do forward pass. Essa otimização sem perdas melhora o TPS por usuário na decodificação.
- Desagregação: Mover o preenchimento e a decodificação para workers separados. Isso evita a competição por recursos, permite uma configuração mais direcionada e torna a proporção de computação de preenchimento para decodificação ajustável para corresponder ao tráfego.
- Cache: Alocar memória para salvar o cache KV e os estados KDA entre requisições, permitindo que requisições subsequentes com prefixos compartilhados em sequências de entrada pulem todo ou parte do preenchimento. Isso melhora o TTFT e o throughput geral do sistema.
Ter o modelo em funcionamento a partir de marcos anteriores é uma dependência para este trabalho. Por exemplo, treinar um modelo especulador usando um método como DSpark, DFlash ou EAGLE-3 requer gerar estados ocultos do modelo alvo (Kimi K3) usando um conjunto de prompts que se assemelham ao uso real esperado. Para fazer isso, você precisa de uma instância do modelo com throughput razoavelmente alto, ativa e executando inferência.
Uma otimização de desempenho inovadora foi no tokenizador. Por anos, engenheiros de inferência puderam desconsiderar o tempo de tokenização como insignificante. Para um modelo como o Kimi K3, com longas sequências de entrada e altas taxas de reutilização de cache KV, isso realmente muda, e a tokenização pode se tornar relevante para o tempo de preenchimento, pois a tokenização deve ocorrer independentemente de a sequência de entrada ser um acerto de cache.
Construímos um tokenizador personalizado que é até 18x mais rápido que o tiktoken para longas sequências de entrada e o lançamos junto com nossa API Kimi K3.
O Basetenkenizer é até 18x mais rápido que o Tiktoken para longas sequências de entrada.
Ainda há mais trabalho a ser feito no desempenho. Com cada modelo que lançamos, continuamos a investir em otimizações de latência e throughput nas semanas seguintes ao lançamento. Com o tamanho sem precedentes do Kimi K3, há uma enorme área para melhoria adicional de desempenho em cada técnica principal de engenharia de inferência e em cada camada da pilha de inferência.
Marco 5: Implantar em escala
Há uma enorme empolgação em toda a indústria pelo Kimi K3. Isso será acompanhado por uma enorme onda de demanda pela API no lançamento. Consequentemente, o throughput de todo o sistema, não apenas a latência por usuário, é uma prioridade máxima.
Em um sistema GB300 NVL72, um nó é composto por 4 GPUs individuais, o que significa que existem 18 nós. Como instância, o Kimi K3 ocupa 2 nós (8 GPUs); cada rack NVL72 pode hospedar 9 réplicas do modelo. Cada cluster possui múltiplos racks GB300 NVL72, e servimos o modelo em várias regiões e provedores de nuvem para acessar mais capacidade.
Cada sistema NVL72 pode executar nove réplicas do Kimi K3.
O fator mais consequente para o throughput de uma determinada réplica é a taxa de acerto do cache de prefixo. Dada a escala da implantação, isso torna o roteamento ciente de KV o principal desafio a ser resolvido na infraestrutura. Quando um usuário envia uma sequência de tokens de entrada que já vimos antes, precisamos rotear essa requisição para uma réplica que possa acessar o cache KV salvo para pular o preenchimento.
Nosso sistema de roteamento ciente de KV, construído com o kit de ferramentas NVIDIA Dynamo, garante que sejamos capazes de rotear o tráfego para réplicas com caches aquecidos para consultas repetidas. Como codificação e agentes de múltiplas voltas são casos de uso comuns para o Kimi K3, este sistema de roteamento ciente de cache é crítico para economizar dinheiro dos usuários e manter um alto throughput total do sistema.
Construa com Kimi K3 na Baseten
Estamos animados em oferecer acesso desde o primeiro dia por meio das APIs de Modelo e ansiosos para continuar otimizando nossa implementação deste modelo para alcançar os mais altos padrões de desempenho e confiabilidade.
O anúncio do Kimi K3 pela equipe da Moonshot AI inclui uma série de testes interessantes para o modelo, incluindo tarefas de codificação como otimização de kernel e desenvolvimento de jogos com visão no loop, tarefas de pesquisa e tarefas de agente como edição de vídeo e trabalho de conhecimento. Na terça-feira, 28 de julho, às 11h (horário do Pacífico), estarei organizando um briefing executivo sobre casos de uso do Kimi K3 ao lado de Joey Zwicker, que lidera toda a engenharia de implantação direta na Baseten.
O Kimi K3 está disponível hoje nas APIs de Modelo da Baseten. Bem-vindo à nova fronteira em inteligência de pesos abertos.
Agradeço aos muitos engenheiros por trás da nossa API Kimi K3 por me permitirem documentar seu trabalho árduo neste artigo, incluindo muitas pessoas para nomear nas equipes de desempenho de modelo, infraestrutura, capacidade, treinamento, produto e engenharia de implantação direta. Agradeço também às equipes da Moonshot AI, Inferact e RadixArk por sua colaboração e apoio.
