Do 18º ao 1º lugar: O que é que o Kimi K3 fez para superar a Claude e a GPT em codificação de contexto longo?

O Kimi K2.6 ainda ocupava o 18.º lugar no ranking de avaliação de codificação do Frontend Code Arena. Depois de apenas uma iteração de versão, o Kimi K3 subiu diretamente ao topo com 1679 pontos, conquistando 6 primeiros lugares nos 7 subcampos de frontend abrangidos. Colocou o Claude Fable 5 e o GPT-5.6 Sol para trás. Este salto de ranking com 17 posições numa competição de modelos de codificação de IA não é comum na história.

Diagrama da arquitetura técnica do Kimi K3, incluindo o mecanismo de roteamento entre especialistas do Kimi Delta Attention, Attention Residuals e MoE

Em forte contraste com o salto de desempenho está a sua estratégia de preços. A API do Kimi K3 cobra 3 dólares por 1 milhão de tokens de entrada e 15 dólares por 1 milhão de tokens de saída; o preço nos acertos de cache desce para 0,3 dólares. Comparado com os 0,95 dólares de entrada e 4 dólares de saída da geração anterior K2.6, o preço unitário padrão de entrada do K3 aumenta cerca de 3 vezes, e o de saída sobe quase 4 vezes. Numa altura em que os grandes modelos nacionais estão a conquistar quota no mercado de chamadas de API através de preços extremamente baixos, o Mianhazi (lado escuro da lua) abandona de forma clara a estratégia de concorrência por baixo preço.

Com que fundamento o Kimi K3 consegue atingir o topo de forma qualitativamente superior no cenário de codificação de agentes com longos contextos? O que significa, na prática, esta estratégia de preços aparentemente elevada para os custos reais de desenvolvedores e de empresas que fazem compras?

O salto de 17 posições por trás: como o MoE de 2,8 biliões de parâmetros sustenta o 1.º lugar na codificação de frontend

A codificação de frontend é um cenário que exige capacidades extremamente elevadas dos grandes modelos. Não só exige que o modelo compreenda intenções complexas de design de UI e gere código HTML/CSS/JavaScript conforme as normas, como também deve lidar com dependências entre vários ficheiros e com gestão de estado. As avaliações do Frontend Code Arena cobrem vários subcampos, como marketing de marca, design de referência, análise de dados, produtos de consumo e simulação, entre outros, avaliando de forma abrangente o desempenho do modelo em tarefas reais de desenvolvimento. Para obter pontuações altas simultaneamente nestas dimensões, o modelo precisa de forte capacidade de geração de código, de uma compreensão apurada das linguagens de design e de estabilidade ao lidar com código em sequências longas.

O Kimi K3 consegue liderar de forma abrangente nestes subcampos graças, principalmente, à sua arquitetura MoE (mistura de especialistas) com 2,8 biliões de parâmetros. Segundo dados divulgados no blog técnico oficial, o Kimi K3 tem 896 redes de especialistas, mas em cada passada de forward ativa apenas 16. Este desenho permite ao modelo manter uma enorme capacidade de conhecimento enquanto controla a quantidade de computação real a um nível equivalente ao de modelos densos menores. No contexto da codificação de frontend, isto significa que o modelo consegue chamar redes de especialistas específicas para processar folhas de estilos, lógica de interação ou ligações de dados, alcançando melhorias de forma mais fina na qualidade gerada, sem que um volume de parâmetros demasiado grande resulte numa latência de inferência inaceitável.

No entanto, simplesmente empilhar parâmetros não se traduz diretamente num salto de capacidade na codificação de frontend. A principal inovação do K3 reside em duas melhorias arquitetónicas: o Kimi Delta Attention (KDA) e os Attention Residuals (AttnRes).

Em cenários de codificação com longos contextos, a complexidade de cálculo do mecanismo de atenção cresce ao nível quadrático com o comprimento da sequência, constituindo o principal gargalo que limita o modelo no tratamento de grandes repositórios de código. Quando o contexto passa de dezenas de milhares de tokens para o patamar de milhões, a atenção total tradicional leva a um aumento drástico do uso de memória de vídeo e a uma queda acentuada da velocidade de descodificação. O KDA adota um mecanismo de atenção linear híbrida, convertendo parte dos cálculos de atenção em operações lineares para reduzir significativamente o custo computacional em sequências longas. De acordo com dados oficiais, em contexto de um milhão consegue obter uma aceleração de descodificação de 6,3 vezes. Isto significa que, quando o desenvolvedor alimenta ao modelo um grande projeto de frontend com dezenas de ficheiros, o K3 consegue completar a compreensão e a geração de código com menor latência, sem uma degradação de desempenho visível na fase de processamento de contextos longos. Para referências comuns entre ficheiros e o acompanhamento de estado global no desenvolvimento de frontend, esta capacidade de lidar com longos contextos com baixa latência determina diretamente a usabilidade do código gerado.

O AttnRes, por sua vez, melhora a eficiência do treino em cerca de 25% através de um mecanismo de recuperação seletiva entre camadas. Na arquitetura Transformer tradicional, cada camada precisa de calcular a atenção de forma independente, o que conduz facilmente a processamento redundante de informação entre camadas. O AttnRes permite reutilizar e recuperar informação chave de atenção entre camadas, reduzindo desperdício de computação durante o treino. Isto torna o modelo mais eficiente ao aprender padrões complexos de código de frontend e regras de design de UI, refletindo-se diretamente na qualidade e na precisão do código gerado. Em cenários comuns no frontend, como layouts aninhados complexos e reutilização de componentes, esta melhoria de eficiência de treino traduz-se numa compreensão mais profunda da estrutura do código, permitindo gerar código mais aderente a normas de engenharia, e não apenas uma acumulação simples de funcionalidades.

A janela nativa de contexto de 1 milhão de tokens é outro suporte fundamental. No fluxo de trabalho tradicional de codificação, ao lidar com projetos grandes, muitas vezes recorre-se a estratégias complexas de truncagem e recuperação de contexto, o que leva a perda de informação global crítica. Por exemplo, quando o modelo apenas vê parte do código dos componentes e não consegue aceder à configuração de gestão de estado global, o código gerado tende a apresentar problemas de incompatibilidade de interfaces ou conflitos de estado. Com uma janela de 1M, o K3 consegue conter de uma só vez o código-fonte do projeto intermédio, descrições dos layouts e documentação de interfaces, realizando geração e refatoração com uma visão global. Esta visão global é especialmente importante para desenvolvimento de frontend, porque a correção de projetos de frontend depende fortemente da coordenação entre componentes e da consistência de estilos. Quando o modelo consegue ver em simultâneo a configuração de rotas, a árvore de componentes e as folhas de estilos, o código que gera não só pode funcionar como também se integra diretamente na estrutura do projeto existente; é este, entre outros fatores, um pré-requisito importante para o seu topo nas avaliações de codificação de frontend.

Entrada 3 dólares, saída 15 dólares: a lógica de preços do K3 e os custos reais da tarefa

Quando os programadores veem pela primeira vez os preços de 3 dólares de entrada e 15 dólares de saída, é fácil classificá-lo como “caro”. Se apenas observarmos o preço por token, o K3 é, de facto, um dos modelos mais caros publicados pelos laboratórios de IA da China. Mas se o enquadrarmos no sistema de coordenadas de concorrência dos modelos de codificação mainstream, a conclusão muda.

Em comparação com o Claude Fable 5 da Anthropic, em que a entrada custa 10 dólares e a saída custa 50 dólares; e com o GPT-5.6 Sol da OpenAI, em que a entrada custa 5 dólares e a saída custa 30 dólares. O preço padrão do K3 é cerca de um terço do do Fable 5 e metade do do GPT-5.6 Sol. É equivalente ao preço padrão do Claude Sonnet 5. Isto significa que o K3 não foi fixado num patamar alto fora do mercado; está antes a meio do intervalo de preços dos modelos líderes a nível internacional.

O mais importante, porém, é que, em cenários de codificação de agentes, o que determina o custo de aquisição para empresas não é o preço por token, mas sim o custo total para concluir uma tarefa de desenvolvimento real. Os dados de avaliação da Artificial Analysis fornecem uma referência crucial: em conjuntos de tarefas de codificação equivalentes, o custo por tarefa do Kimi K3 é 0,94 dólares e o do GPT-5.6 Sol é 1,04 dólares, enquanto o do Claude Fable 5 chega a 2,75 dólares. Em custo por tarefa, o K3 não só fica abaixo do Fable 5 como também abaixo do GPT-5.6 Sol.

A vantagem do K3 em custo por tarefa deve-se, principalmente, ao seu mecanismo de cache. No fluxo de trabalho de codificação de agentes, o modelo precisa de ler repetidamente o prompt do sistema, o contexto do repositório de código e os registos do historial de interações. Em múltiplas rondas de conversa, este conteúdo permanece frequentemente inalterado, constituindo a base para acertos de cache. O preço de acerto de cache do K3 é apenas 0,3 dólares por 1 milhão de tokens. O blog técnico oficial indica que, em cenários de codificação, a taxa de acerto de cache pode exceder 90%.

Isto significa que, em interações contínuas de codificação, a maior parte dos tokens de entrada é efetivamente faturada a 0,3 dólares e não a 3 dólares. Se considerarmos uma taxa de acerto de cache de 90%, o custo efetivo de entrada desce para cerca de 0,57 dólares por 1 milhão de tokens. Esta mudança de lógica de preços de “preço por token” para “custo por tarefa” é a base que permite ao K3 dispensar a estratégia de baixo preço. Para equipas empresariais que já estabeleceram fluxos de trabalho estáveis de codificação de agentes, o custo real de utilização do K3 poderá ser muito inferior ao que sugerem os preços aparentes.

Mas esta estratégia também enfrenta desafios. Em cenários com chamadas pouco frequentes ou com variações de contexto muito acentuadas, torna-se difícil manter uma taxa de acerto de cache elevada; nesses casos, o custo real de utilização do K3 fica significativamente acima dos modelos de baixo preço nacionais. Para programadores independentes que estejam apenas a começar ou para pequenas equipas de startups, se não tiverem formado um fluxo de trabalho estável de codificação de agentes, o limiar inicial de utilização do K3 ainda é relativamente alto. Além disso, o preço de saída do K3 é 15 dólares; em cenários com geração de grandes volumes de código e tokens de raciocínio, a proporção do custo de saída não pode ser ignorada. Os programadores precisam de avaliar o potencial de acerto de cache do seu próprio fluxo de trabalho para decidir se o K3 é realmente mais custo-efetivo do que modelos de baixo preço.

Longo contexto e codificação de agentes: uma estratégia de gestão de contexto que muda a toolchain

O Kimi K3 tem um foco explícito em cenários de codificação de agentes com longos contextos; isto não é apenas uma definição de funcionalidades, mas também um juízo sobre a direção de evolução do ecossistema de ferramentas de codificação de IA atual.

Nos atuais fluxos de trabalho de codificação de agentes, os programadores normalmente precisam de depender de ferramentas externas para gerir o contexto do repositório de código. Por exemplo, usando ferramentas como Codebase memory mcp para lidar com problemas de memória e recuperação do repositório; depois extraem-se os excertos de código relevantes e alimenta-se o modelo. Isto acontece porque as janelas de contexto dos modelos tradicionais são limitadas e não conseguem acomodar todo o projeto de uma só vez. Assim, o desenvolvedor tem de construir fluxos complexos de geração aumentada por recuperação (RAG), usando bases de dados vetoriais e pesquisa semântica para filtrar excertos de código relevantes. Isto aumenta a complexidade do sistema e introduz o risco de falhas por omissão na recuperação.

O K3, com a sua janela nativa de contexto de 1 milhão de tokens, está a alterar este paradigma. Quando o modelo consegue conter por si mesmo o repositório de código de um projeto intermédio, os programadores podem reduzir a dependência de ferramentas externas de recuperação. Podem fornecer diretamente ao modelo como entrada o enquadramento do projeto, os ficheiros essenciais e as definições de interfaces. Isto reduz a complexidade de gestão de contexto e diminui erros de geração causados por falhas de recuperação. Para projetos de frontend, heranças de estilos entre componentes e relações de passagem de eventos muitas vezes são difíceis de captar totalmente apenas com recuperação de excertos; com janelas de contexto longas, o modelo consegue ver de uma só vez a árvore completa de componentes e as folhas de estilos, gerando código mais consistente.

Para frameworks de orquestração de agentes como o Agently, modelos com longos contextos oferecem maior espaço para orquestração. O framework pode aproveitar as capacidades do K3 para lidar com fluxos de tarefas de codificação mais complexos, por exemplo, analisar simultaneamente layouts de design de frontend, definições de interfaces de backend e estruturas de bases de dados para gerar código de integração full-stack. No modo de orquestração tradicional, o framework precisa de dividir a tarefa em várias sub-tarefas, chamando o modelo separadamente e depois juntando os resultados via intervenção manual ou scripts. Com longos contextos, o framework consegue lidar com uma cadeia de tarefas mais completa numa única chamada, reduzindo perda de informação nas etapas intermédias de junção. Com a abertura de pesos do K3, ferramentas deste tipo ganham mais autonomia na seleção do modelo, podendo alternar de forma flexível entre chamadas via API e deployment self-hosted conforme a complexidade da tarefa.

Mas longos contextos também trazem novos problemas. Numa experiência, Simon Willison descobriu que, ao gerar uma imagem SVG de um pelicano, o K3 consumiu 16658 tokens de saída, dos quais 13241 foram tokens de raciocínio. O K3 mantém sempre o modo de raciocínio no nível máximo e não permite desligar o “pensar”. Este consumo elevado de tokens de raciocínio, em tarefas de codificação complexas, pode tornar-se ainda mais significativo. Embora assegure a qualidade gerada, também aumenta o custo da fase de saída. Os programadores precisam de encontrar um equilíbrio entre qualidade de geração e consumo de tokens, e o K3 atualmente não oferece opções para ajustar a profundidade do raciocínio. Para cenários que exigem iteração rápida e chamadas frequentes, esta profundidade de raciocínio não ajustável pode tornar-se um gargalo de eficiência.

Abertura de pesos a 27 de julho: expectativa de self-hosting e limiares de hardware

A oficial anunciou a abertura dos pesos do modelo Kimi K3 para 27 de julho de 2026. Esta é a ação mais impactante para a indústria deste modelo para além do seu acesso via API comercial.

A abertura de pesos oferece às empresas com recursos de computação uma opção de self-hosting com garantia de privacidade de dados. Em setores sensíveis como financeiro e saúde, as empresas têm preocupações de conformidade ao enviar repositórios de código para APIs de terceiros. Com a abertura de pesos, estas empresas podem fazer deployment local do K3 e usar as suas capacidades de codificação com longos contextos para construir plataformas internas de desenvolvimento de agentes. Para grandes empresas de tecnologia, o self-hosting também evita limites de taxa nas chamadas de API, garantindo estabilidade do assistente de codificação durante picos de procura.

No entanto, o seu tamanho de 2,8 biliões de parâmetros determina um limiar de deployment extremamente alto. Com base em discussões na comunidade e em experiências de deployment de modelos com escala semelhante, há análises que indicam que para executar o K3 com fluidez pode ser necessário mais de 64 aceleradores. Isto significa que, para a maioria dos programadores e equipas de startups médias e pequenas, o self-hosting não é realista. A abertura de pesos é mais uma libertação de influência tecnológica para a comunidade do que uma mudança direta do modelo de negócio centrado em chamadas de API. Mesmo para empresas que queiram fazer self-hosting, é necessário avaliar cuidadosamente o equilíbrio de custos entre aquisição de hardware e chamadas de API no longo prazo.

Além disso, a oficial ainda não esclareceu de forma específica o protocolo de abertura de pesos. Diferentes licenças open-source têm diferentes restrições para uso comercial, o que afetará diretamente se as ferramentas de codificação a jusante se sentirão dispostas a adotar o K3 como modelo base por defeito. Se a licença for permissiva, é possível que o K3 se espalhe rapidamente no ecossistema de ferramentas open-source de codificação; se existirem restrições comerciais, a sua influência ecológica ficará principalmente limitada a investigação e a áreas não comerciais. A expectativa da comunidade de programadores para a abertura de pesos não está apenas em poder usar gratuitamente, mas também em conseguir fazer fine-tuning e personalização com base nos pesos para atender necessidades de codificação de linguagens de programação ou frameworks específicos.

Raízes tecnológicas do Mianhazi: da janela de longos contextos à escolha estratégica pela codificação de agentes

O posicionamento do produto do Kimi K3 não surgiu do nada; é uma extensão natural da linha técnica do Mianhazi desde o seu início.

O Mianhazi foi fundado em março de 2023. O fundador Yang Zhilin tem uma base profunda em processamento de linguagem natural e foi primeiro autor de artigos de grande peso como Transformer-XL e XLNet. Uma das direções centrais destas investigações é como permitir que os modelos lidem com sequências mais longas. Desde a criação da empresa, o Mianhazi apostou na rota de longos contextos. Naquela altura, com o mercado de IA dominado por conversas de texto curto, tratava-se de uma escolha não mainstream.

Do Kimi Chat inicial, que se focava no processamento de textos longos, à série K2 que expandiu a janela de contexto, e até ao K3 que combina profundamente longos contextos com codificação de agentes, a linha técnica do Mianhazi é coerente. Esta firmeza estratégica tem obtido retorno no mercado de capitais. Segundo reportagens públicas, após o financiamento de maio de 2026, a avaliação do Mianhazi já atingiu cerca de 20 mil milhões de dólares e o montante total angariado ultrapassou 37,6 mil milhões de renminbi.

O apoio de capital suficiente permite ao Mianhazi treinar e otimizar grandes arquiteturas MoE em escala, além de fornecer uma “almofada financeira” para a sua estratégia de não concorrer em “corrida ao baixo preço”. A estratégia de preços do K3 reflete a tentativa do Mianhazi de construir posicionamento de marca por prémio de capacidade em vez de volume por preço baixo. No mercado de modelos de codificação, a sensibilidade dos programadores à qualidade do código e à taxa de conclusão de tarefas é muito maior do que ao preço por token. O K3 prova a sua capacidade ao conquistar o topo no Frontend Code Arena e, depois, usa a vantagem em custo por tarefa para persuadir empresas a comprar, um caminho de comercialização completamente diferente do seguido por modelos de baixo preço nacionais.

Mas este caminho também tem riscos. As capacidades dos modelos de codificação de IA evoluem a um ritmo muito rápido; a posição de topo do Frontend Code Arena pode ser retomada a qualquer momento pela próxima geração de Claude ou GPT. Se perder a liderança em desempenho absoluto, o seu preço elevado deixa de ter sustentação. Além disso, a oficial também reconheceu que o K3 ainda fica atrás do Fable 5 e do GPT-5.6 Sol na experiência global do utilizador. Em cenários difusos, o modelo pode tornar-se demasiado proativo a decidir por utilizadores e é altamente sensível ao historial de pensamento; estas limitações precisam ser tratadas com cuidado nos fluxos de trabalho reais de desenvolvimento.

O facto de o Kimi K3 ter chegado ao topo prova o potencial da combinação entre MoE com 2,8 biliões de parâmetros e longos contextos em cenários de codificação, e a lógica de preços baseada no custo real da tarefa oferece uma nova referência para a comercialização de grandes modelos. Contudo, para manter-se à frente face ao cerco de Claude e GPT, o Mianhazi ainda precisa de colmatar mais fragilidades em experiência de utilizador e construção de ecossistema.