A Baseten oferece suporte desde o primeiro dia para o Kimi K3 em nossas Model APIs. 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 ao longo do processo de desenvolvimento.
O Kimi K3 está disponível hoje nas Model APIs 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 vários desafios para construir uma API de inferência de alto desempenho. Novas técnicas arquitetônicas permitem que o Kimi K3 ultrapasse o limite de trilhões de parâmetros dos modelos abertos de fronteira anteriores:
- Kimi Delta Attention (KDA) e Attention Residuals (AttnRes) como uma 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 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 desde o primeiro dia, um passo inicial é portar os pesos para NVFP4 para melhorar o desempenho e a compatibilidade com 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 com a RadixArk no SGLang. Antes de executar o Kimi K3 na Baseten Inference Stack, precisávamos estabelecer uma linha de base em colaboração com os principais mecanismos de inferência de código aberto.
Adicionar suporte a um modelo em um mecanismo de inferência não é trivial. 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 funcionalidades, passar em avaliações iniciais e definir uma meta de desempenho de linha de base. Este trabalho de acomodação de recursos arquitetônicos 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 um forte desempenho em tarefas agênticas, 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 pontos de verificação ú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 requer uma avaliação comparativa mais rigorosa.
A equipe da Moonshot AI opera o Kimi Vendor Verifier, que ajuda os provedores de inferência a garantir o serviço preciso e de alta fidelidade dos pesos do modelo. Passar no Kimi Vendor Verifier foi um marco inicial essencial no desenvolvimento de nossa API e foi uma ferramenta extremamente útil em todo o processo de desenvolvimento.
Existem muitas oportunidades de errar ao servir 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 é executado na CPU na frente 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ínio 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 desde o primeiro dia. Verificações robustas como o Kimi Vendor Verifier avaliam o desempenho em modos de falha comuns, como chamadas de ferramentas, para garantir que o modelo seja servido com um 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 Kimi Vendor Verifier em marcos subsequentes para garantir que as otimizações de desempenho não tivessem introduzido 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 para diferentes modelos, hardware, 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 Tensor Parallelism (TP) e Expert Parallelism (EP), alternância de Attention Data Parallelism (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.
Tensor Parallelism e Expert Parallelism dividem modelos grandes em várias 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 Tensor Parallelism não é tradicionalmente possível entre nós, pois interconexões lentas tornam as operações all-reduce caras um gargalo para a inferência – o sistema GB300 NVL72 tem uma interconexão suficientemente rápida entre nós para que possamos executar inferência com Tensor Parallelism e Expert Parallelism entre nós.
Essas decisões de configuração são decorrentes da 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 para os 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 observamos:
- Especulação: Usar um modelo de rascunho pequeno para prever vários 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 solicitações, permitindo que solicitaçõ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 de 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, os 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 material para o tempo de preenchimento, pois a tokenização deve ocorrer independentemente de a sequência de entrada ser um cache hit.
Construímos um tokenizador personalizado que é até 18x mais rápido que o tiktoken para longas sequências de entrada e o implementamos 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 de superfície para melhoria adicional de desempenho em todas as principais técnicas de engenharia de inferência e em todas as camadas da pilha de inferência.
Marco 5: Implantar em escala
Há uma empolgação imensa em todo o setor pelo Kimi K3. Isso será acompanhado por uma enorme onda de demanda pela API no lançamento. Consequentemente, o throughput de todo o sistema, e não apenas a latência por usuário, é uma prioridade máxima.
Em um sistema GB300 NVL72, um nó tem 4 GPUs individuais, ou seja, existem 18 nós. Como uma instância, o Kimi K3 ocupa 2 nós (8 GPUs); cada rack NVL72 pode hospedar 9 réplicas do modelo. Cada cluster tem vários 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 cache hit 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 solicitaçã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 o Kimi K3 na Baseten
Estamos animados em oferecer acesso desde o primeiro dia por meio das Model APIs 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 da equipe da Moonshot AI inclui vários 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 agênticas 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 sediando um briefing executivo sobre casos de uso do Kimi K3 ao lado de Joey Zwicker, que lidera toda a engenharia de implantação avançada na Baseten.
O Kimi K3 está disponível hoje nas Model APIs da Baseten. Bem-vindo à nova fronteira da inteligência de peso aberto.
Agradeço aos muitos engenheiros por trás de nossa API Kimi K3 por me permitirem documentar seu trabalho árduo neste artigo, incluindo muitas pessoas para nomear em todas as equipes de desempenho de modelo, infraestrutura, capacidade, treinamento, produto e engenharia de implantação avançada. Além disso, agradeço às equipes da Moonshot AI, Inferact e RadixArk por sua colaboração e apoio.
