Workers AI agora roda modelos grandes e o Kimi K2.5 é o primeiro da fila
O Workers AI acaba de dar um salto que muita gente estava esperando.
A Cloudflare anunciou que sua plataforma de inferência agora suporta modelos de linguagem grandes, e o primeiro a chegar é o Kimi K2.5, da Moonshot AI. Se você trabalha ou tem interesse em construir agentes autônomos, essa notícia muda bastante o cenário.
Não estamos falando de mais um modelo genérico no catálogo de uma plataforma qualquer. Estamos falando de um modelo frontier open-source com janela de contexto de 256k tokens, suporte a tool calling multi-turno, entradas de visão e saídas estruturadas, rodando direto dentro do ecossistema da Cloudflare. E com um argumento de custo que, honestamente, é difícil ignorar. 💡
A própria Cloudflare usou o modelo internamente antes de lançar para o público, e os números que eles trouxeram são bem concretos:
- Um agente de segurança processando mais de 7 bilhões de tokens por dia
- Mais de 15 problemas confirmados encontrados em uma única base de código pelo agente rodando com Kimi K2.5
- Uma economia de 77% em relação a modelos proprietários de nível similar
- E uma diferença de custo anual que chegaria a USD 2,4 milhões no cenário alternativo, apenas para esse único caso de uso em uma única base de código
Mas o lançamento vai além do modelo em si. A Cloudflare trouxe junto novidades de infraestrutura como o caching de prefixo com desconto em tokens cacheados, um novo header de afinidade de sessão e uma API assíncrona redesenhada, pensadas justamente para os padrões de uso que agentes modernos exigem. Nos próximos tópicos você vai entender o que é o Kimi K2.5, por que a Cloudflare o escolheu, o que mudou na infraestrutura do Workers AI e como tudo isso se encaixa no movimento maior de tornar a plataforma o ambiente ideal para rodar o ciclo de vida completo de agentes de IA. 🚀
O contexto que levou ao lançamento: os primitivos da Cloudflare para agentes
Antes de falar do modelo em si, vale entender por que a Cloudflare enxerga esse lançamento como uma peça que faltava em um quebra-cabeça maior. A empresa vem construindo, há anos, o que ela chama de primitivos para agentes autônomos. Esses primitivos são blocos de construção fundamentais que dão aos agentes as capacidades de que eles precisam para funcionar de verdade em produção.
O Durable Objects oferece persistência de estado, ou seja, a capacidade de um agente lembrar onde parou e manter informações ao longo de sessões diferentes. O Workflows permite orquestrar tarefas de longa duração, essenciais quando um agente precisa executar fluxos que duram minutos ou até horas. O Dynamic Workers e os containers Sandbox fornecem ambientes de execução seguros, onde código pode rodar de forma isolada sem comprometer o restante do sistema. E o Agents SDK funciona como uma abstração de alto nível que conecta tudo isso e facilita a vida do desenvolvedor na hora de montar o agente.
Todos esses componentes resolviam o lado do ambiente de execução. O agente tinha onde rodar, como manter estado, como executar tarefas longas e como se comunicar com o mundo externo. Mas faltava o cérebro. O modelo de IA que realmente toma as decisões, raciocina sobre os dados e conduz o agente precisava vir de fora, geralmente de um provedor proprietário com custos que escalam rápido. Com o Workers AI agora rodando modelos grandes como o Kimi K2.5, esse gap foi preenchido. A plataforma passou a oferecer o ciclo de vida completo de um agente dentro de um único ecossistema, da inferência ao armazenamento.
O que é o Kimi K2.5 e por que ele importa tanto
O Kimi K2.5 é um modelo de linguagem grande desenvolvido pela Moonshot AI, empresa chinesa que tem ganhado bastante atenção no cenário global de inteligência artificial. Diferente de muitos modelos que chegam ao mercado com capacidades genéricas e promessas vagas, o Kimi K2.5 foi construído com foco explícito em raciocínio longo, uso de ferramentas externas e execução de tarefas complexas ao longo de múltiplos turnos de conversa. Isso o coloca diretamente no centro do que os desenvolvedores de agentes autônomos precisam hoje: um modelo que não só responde, mas que age, planeja e itera.
- E-BOOK GRATUITO
Um guia prático para avaliar, comparar e implementar inteligência artificial com clareza — sem desperdício de tempo ou dinheiro.
Pare de contratar ferramentas sem direção. Criamos um método estruturado para decidir qual IA realmente faz sentido para o seu negócio.
Entrega em PDF no seu e-mail · Sem spam · LGPD
🔒 Seus dados são protegidos conforme a LGPD. Você pode descadastrar a qualquer momento.
A janela de contexto de 256k tokens é um dos pontos mais importantes do modelo. Para quem não está familiarizado com essa métrica, tokens são fragmentos de texto que o modelo processa de uma vez. Quanto maior a janela, mais informação o modelo consegue considerar ao mesmo tempo, o que é fundamental para agentes que precisam manter histórico longo de conversas, rastrear ações passadas, interpretar documentos extensos ou coordenar múltiplos fluxos de dados em paralelo. Com 256k tokens disponíveis, o Kimi K2.5 consegue operar em cenários que simplesmente travam ou perdem coerência em modelos com janelas menores, tornando-o uma escolha naturalmente mais robusta para aplicações reais de automação inteligente.
Além da janela de contexto, o suporte a tool calling multi-turno é o que realmente diferencia o Kimi K2.5 no contexto de agentes autônomos. Tool calling é a capacidade que o modelo tem de chamar funções externas, APIs ou ferramentas durante a geração de uma resposta. Quando isso acontece em múltiplos turnos, significa que o modelo pode encadear ações, verificar resultados, ajustar o plano e continuar operando sem perder o fio da meada. Somado ao suporte a visão, que permite interpretar imagens e dados visuais, e às saídas estruturadas, que garantem respostas em formatos como JSON de forma confiável, o modelo se torna uma peça bastante completa para quem quer montar pipelines de IA que realmente funcionem em produção.
Por que a Cloudflare escolheu esse modelo para estrear os LLMs no Workers AI
A decisão da Cloudflare de estrear o suporte a modelos grandes com o Kimi K2.5 não parece aleatória. A empresa tem posicionado o Workers AI como uma plataforma voltada para o ciclo de vida completo de agentes de IA, não só para inferência pontual. Nesse contexto, escolher um modelo frontier open-source com capacidades robustas de agentic workflows faz todo sentido: ele valida a proposta da plataforma e entrega um caso de uso real e concreto desde o primeiro dia. A Cloudflare não precisou vender o modelo na base da narrativa, ela trouxe os próprios números internos para mostrar que o caso funciona.
A empresa contou que passou semanas testando o Kimi K2.5 como motor para suas ferramentas internas de desenvolvimento. Dentro do ambiente OpenCode, engenheiros da Cloudflare usaram o modelo como driver diário para tarefas de codificação com agentes. Além disso, o modelo foi integrado ao pipeline automatizado de code review da empresa, que é visível publicamente através do agente Bonk nos repositórios da Cloudflare no GitHub. Em produção, o modelo se mostrou uma alternativa rápida e eficiente a modelos proprietários maiores, sem sacrificar qualidade nos resultados.
O uso interno que a Cloudflare descreveu é bastante revelador sobre o potencial do modelo num ambiente de produção exigente. Um agente de segurança rodando dentro da infraestrutura da empresa chegou a processar mais de 7 bilhões de tokens por dia, o que é um volume expressivo por qualquer métrica. Esse agente encontrou mais de 15 problemas confirmados em uma única base de código. Quando você coloca isso em perspectiva com a economia de 77% em relação a modelos proprietários de nível equivalente, o argumento econômico fica evidente. Uma diferença que chegaria a USD 2,4 milhões por ano no cenário alternativo não é marginal. É o tipo de número que entra em planilha de budget e muda decisão de arquitetura de sistemas inteiros.
Vale destacar também o fato de o Kimi K2.5 ser open-source nessa equação. Modelos proprietários cobram não só pelo uso, mas também pela dependência que criam. Quando você constrói sobre um modelo aberto e o hospeda numa plataforma como o Workers AI, você mantém controle sobre como o modelo é usado, onde os dados trafegam e como a arquitetura evolui ao longo do tempo. Para empresas que operam em setores com requisitos de compliance ou que simplesmente querem evitar o lock-in de um fornecedor específico, essa combinação de open-source com infraestrutura gerenciada é bastante atrativa.
A relação custo-benefício que muda a conta dos agentes pessoais e corporativos
A Cloudflare fez questão de posicionar esse lançamento não apenas como uma melhoria técnica, mas como uma resposta direta a um problema econômico que está se tornando cada vez mais urgente. À medida que a adoção de IA cresce, a empresa observa uma mudança fundamental na forma como equipes de engenharia e até indivíduos operam no dia a dia. Está se tornando cada vez mais comum ter um agente pessoal, como o OpenClaw, rodando 24 horas por dia, sete dias por semana. O volume de inferência está disparando.
Essa nova realidade de agentes pessoais e de codificação faz com que o custo deixe de ser uma preocupação secundária e se torne o principal obstáculo para escalar. Quando cada funcionário de uma empresa tem múltiplos agentes processando centenas de milhares de tokens por hora, a conta com modelos proprietários simplesmente para de fechar. A expectativa da Cloudflare é que empresas vão migrar cada vez mais para modelos open-source que ofereçam raciocínio de nível frontier sem a etiqueta de preço dos modelos fechados. E o Workers AI se coloca como facilitador dessa transição, oferecendo desde endpoints serverless para um agente pessoal até instâncias dedicadas que alimentam agentes autônomos em toda uma organização.
A stack de inferência para modelos grandes: o que rola por baixo do capô
O Workers AI já servia modelos, incluindo LLMs, desde seu lançamento há dois anos, mas historicamente priorizava modelos menores. Parte da razão era que, por algum tempo, os LLMs open-source ficavam significativamente atrás dos modelos dos laboratórios frontier. Isso mudou com modelos como o Kimi K2.5, mas para servir esse tipo de LLM muito grande, a Cloudflare precisou fazer mudanças importantes na stack de inferência.
A empresa desenvolveu kernels customizados para o Kimi K2.5, construídos sobre o motor de inferência proprietário chamado Infire. Esses kernels otimizam a forma como o modelo é servido, melhorando a performance e a utilização das GPUs e desbloqueando ganhos que simplesmente não existem quando você roda o modelo direto da caixa, sem ajustes.
Além disso, existem múltiplas técnicas e configurações de hardware que podem ser utilizadas para servir um modelo grande. Os desenvolvedores tipicamente combinam técnicas de paralelismo de dados, tensor e especialistas para otimizar a performance. Estratégias como o disaggregated prefill, em que as etapas de prefill e geração são separadas em máquinas diferentes para obter melhor throughput e maior utilização de GPU, também desempenham um papel importante. Implementar essas técnicas e incorporá-las na stack de inferência exige muita experiência dedicada para acertar.
Esse é justamente o ponto que a Cloudflare quer destacar: o Workers AI já fez toda essa experimentação e engenharia por baixo dos panos. Muito disso simplesmente não vem pronto quando você hospeda um modelo open-source por conta própria. O benefício de usar uma plataforma gerenciada como essa é que você não precisa ser um engenheiro de Machine Learning, um especialista em DevOps ou um engenheiro de confiabilidade para fazer as otimizações necessárias. A parte difícil já foi feita, e o desenvolvedor só precisa chamar uma API. 🛠️
Caching de prefixo e afinidade de sessão: economia inteligente em tokens
O anúncio do Kimi K2.5 veio acompanhado de melhorias de infraestrutura que merecem atenção especial, começando pelo caching de prefixo. Quando você trabalha com agentes, é muito provável que esteja enviando uma grande quantidade de tokens de entrada como parte do contexto. Podem ser prompts de sistema detalhados, definições de ferramentas, ferramentas de servidores MCP ou bases de código inteiras. Em teoria, com a janela de 256k tokens do Kimi K2.5, uma única requisição poderia conter quase 256 mil tokens de entrada. Isso é muita coisa.
Para entender como o caching ajuda, é preciso saber como um LLM processa uma requisição. O processamento é dividido em duas etapas: a etapa de prefill, que processa os tokens de entrada, e a etapa de geração, que produz os tokens de saída. Essas etapas são sequenciais, ou seja, os tokens de entrada precisam ser totalmente processados antes que a geração comece. Em conversas multi-turno, cada novo prompt enviado pelo cliente inclui todos os prompts anteriores, ferramentas e contexto da sessão. A diferença entre requisições consecutivas geralmente é apenas algumas linhas novas de entrada, enquanto todo o restante já passou pela etapa de prefill em uma requisição anterior.
É aqui que o caching de prefixo entra em ação. Em vez de refazer o prefill em toda a requisição, o Workers AI pode cachear os tensors de entrada de uma requisição anterior e fazer prefill apenas nos novos tokens de entrada. Isso economiza tempo e computação na etapa de prefill, resultando em um Time to First Token mais rápido e um throughput de Tokens Per Second mais alto, já que a GPU não fica bloqueada esperando o prefill terminar.
O Workers AI sempre fez caching de prefixo, mas agora está expondo os tokens cacheados como uma métrica de uso e oferecendo desconto em tokens cacheados em comparação com tokens de entrada normais. Além disso, a Cloudflare introduziu um novo header chamado x-session-affinity. Quando você envia esse header com uma string única por sessão ou por agente, a requisição é roteada para a mesma instância do modelo, aumentando a taxa de acerto da cache de prefixo. Mais tokens cacheados significam TTFT mais rápido, TPS mais alto e custos de inferência menores. Alguns clientes como o OpenCode já implementam isso automaticamente, e o Agents SDK starter da Cloudflare também já vem configurado para usar esse recurso.
API assíncrona redesenhada: inferência durável para agentes que não precisam de tempo real
A outra grande novidade de infraestrutura é a API assíncrona redesenhada, que responde a um padrão de uso muito específico de agentes modernos: tarefas que levam tempo para concluir e que não precisam manter uma conexão aberta o tempo todo.
Receba o melhor conteúdo de inovação em seu e-mail
Todas as notícias, dicas, tendências e recursos que você procura entregues na sua caixa de entrada.
Ao assinar a newsletter, você concorda em receber comunicações da Método Viral. A gente se compromete a sempre proteger e respeitar sua privacidade.
A Cloudflare é direta sobre um fato que muitos provedores preferem não admitir: inferência serverless é muito difícil. Com um modelo de negócio de pagamento por token, é mais barato em uma base de requisição individual porque você não precisa pagar por GPUs inteiras para atender seus pedidos. Mas existe um trade-off: você precisa competir com o tráfego de outras pessoas e com restrições de capacidade, e não há garantia estrita de que sua requisição será processada. Isso não é exclusivo do Workers AI, é a realidade de provedores serverless de modelos de forma geral, como evidenciado pelas frequentes notícias sobre provedores sobrecarregados e interrupções de serviço.
Para volumes de requisições que excedem os limites de taxa síncronos, agora é possível enviar lotes de inferências para serem completados de forma assíncrona. A nova API assíncrona funciona mais como processamento flex do que como uma API de batch tradicional: as requisições na fila são processadas assim que há margem disponível nas instâncias do modelo. Para casos de uso assíncronos, você não vai encontrar erros de falta de capacidade, e a inferência será executada de forma durável em algum momento. Nos testes internos da Cloudflare, as requisições assíncronas geralmente foram executadas dentro de cinco minutos, mas isso depende do volume de tráfego ao vivo.
Por baixo do capô, a Cloudflare migrou de um sistema baseado em push para um sistema baseado em pull. Isso permite que requisições enfileiradas sejam puxadas assim que há capacidade disponível. A empresa também adicionou controles melhores para ajustar o throughput das requisições assíncronas, monitorando a utilização de GPU em tempo real e puxando requisições assíncronas quando a utilização está baixa. Dessa forma, requisições síncronas críticas mantêm prioridade enquanto requisições assíncronas continuam sendo processadas de maneira eficiente. É uma solução ideal para casos de uso que não são em tempo real, como agentes de escaneamento de código ou agentes de pesquisa. Também existe a possibilidade de configurar notificações de eventos para saber quando a inferência foi concluída, em vez de ficar fazendo polling na requisição. 👀
O que isso significa para quem constrói com IA hoje
O movimento da Cloudflare com o Workers AI e o Kimi K2.5 representa algo maior do que a adição de um novo modelo de IA ao catálogo. É uma sinalização clara de que a plataforma quer ser o ambiente onde agentes autônomos vivem de ponta a ponta, da inferência ao armazenamento, passando pelo roteamento, segurança e orquestração de fluxos. Quando você considera que a Cloudflare já oferece Workers para execução de código na borda, KV e R2 para armazenamento, D1 para banco de dados e Durable Objects para estado persistente, o Workers AI com suporte a LLMs grandes fecha um loop importante para quem quer construir aplicações de IA sem precisar juntar peças de cinco fornecedores diferentes.
Para desenvolvedores que trabalham com agentes, a combinação de um modelo com tool calling multi-turno, janela de contexto ampla, caching de prefixo com desconto, afinidade de sessão e API assíncrona dentro de uma infraestrutura já familiar reduz bastante a fricção de colocar algo em produção. Não é só sobre custo, embora o argumento de custo seja forte. É sobre a capacidade de iterar rápido, testar diferentes arquiteturas de agentes e escalar sem precisar reescrever tudo quando o volume cresce. Esse tipo de flexibilidade é o que separa projetos que ficam em prova de conceito dos que chegam a produção com consistência.
O Agents SDK starter da Cloudflare já usa o Kimi K2.5 como modelo padrão, o que facilita quem quer começar do zero. Também é possível conectar ao Kimi K2.5 no Workers AI diretamente pelo OpenCode e testar o modelo no playground interativo da Cloudflare. O ecossistema já está montado para que o desenvolvedor possa experimentar e validar antes de escalar.
O cenário geral de infraestrutura para IA está mudando rapidamente, e iniciativas como essa mostram que a disputa não é mais só entre os modelos em si, mas entre os ecossistemas que os cercam. Ter um modelo poderoso disponível é o ponto de partida. O que faz a diferença no dia a dia é a latência, o custo por token, a facilidade de integração com o restante da stack e a confiabilidade da plataforma em horários de pico. O Workers AI, com o Kimi K2.5 como carro-chefe, está claramente apostando que pode entregar tudo isso junto, e os números que a Cloudflare trouxe do uso interno sugerem que não é só uma promessa. 🚀
