Workers AI ahora ejecuta modelos grandes y Kimi K2.5 es el primero en la fila
Workers AI acaba de dar un salto que mucha gente estaba esperando.
Cloudflare anunció que su plataforma de inferencia ahora soporta modelos de lenguaje grandes, y el primero en llegar es Kimi K2.5, de Moonshot AI. Si trabajas o tienes interés en construir agentes autónomos, esta noticia cambia bastante el panorama.
No estamos hablando de un modelo genérico más en el catálogo de una plataforma cualquiera. Estamos hablando de un modelo frontier open-source con ventana de contexto de 256k tokens, soporte para tool calling multi-turno, entradas de visión y salidas estructuradas, corriendo directamente dentro del ecosistema de Cloudflare. Y con un argumento de coste que, sinceramente, es difícil ignorar. 💡
La propia Cloudflare usó el modelo internamente antes de lanzarlo al público, y los números que presentaron son bastante concretos:
- Un agente de seguridad procesando más de 7 mil millones de tokens por día
- Más de 15 problemas confirmados encontrados en una sola base de código por el agente corriendo con Kimi K2.5
- Un ahorro del 77% en comparación con modelos propietarios de nivel similar
- Y una diferencia de coste anual que llegaría a 2,4 millones de dólares en el escenario alternativo, solo para ese único caso de uso en una única base de código
Pero el lanzamiento va más allá del modelo en sí. Cloudflare trajo consigo novedades de infraestructura como el caching de prefijo con descuento en tokens cacheados, un nuevo header de afinidad de sesión y una API asíncrona rediseñada, pensadas justamente para los patrones de uso que los agentes modernos exigen. En los próximos apartados vas a entender qué es Kimi K2.5, por qué Cloudflare lo eligió, qué cambió en la infraestructura de Workers AI y cómo todo esto encaja en el movimiento mayor de convertir la plataforma en el entorno ideal para ejecutar el ciclo de vida completo de agentes de IA. 🚀
El contexto que llevó al lanzamiento: los primitivos de Cloudflare para agentes
Antes de hablar del modelo en sí, vale la pena entender por qué Cloudflare ve este lanzamiento como una pieza que faltaba en un rompecabezas mayor. La empresa lleva años construyendo lo que llama primitivos para agentes autónomos. Estos primitivos son bloques de construcción fundamentales que dan a los agentes las capacidades que necesitan para funcionar de verdad en producción.
Durable Objects ofrece persistencia de estado, es decir, la capacidad de que un agente recuerde dónde se quedó y mantenga información a lo largo de sesiones diferentes. Workflows permite orquestar tareas de larga duración, esenciales cuando un agente necesita ejecutar flujos que duran minutos o incluso horas. Dynamic Workers y los contenedores Sandbox proporcionan entornos de ejecución seguros, donde el código puede correr de forma aislada sin comprometer el resto del sistema. Y el Agents SDK funciona como una abstracción de alto nivel que conecta todo esto y facilita la vida del desarrollador a la hora de montar el agente.
Todos estos componentes resolvían el lado del entorno de ejecución. El agente tenía dónde correr, cómo mantener estado, cómo ejecutar tareas largas y cómo comunicarse con el mundo exterior. Pero faltaba el cerebro. El modelo de IA que realmente toma las decisiones, razona sobre los datos y conduce al agente necesitaba venir de fuera, generalmente de un proveedor propietario con costes que escalan rápido. Con Workers AI ahora ejecutando modelos grandes como Kimi K2.5, ese hueco se llenó. La plataforma pasó a ofrecer el ciclo de vida completo de un agente dentro de un único ecosistema, desde la inferencia hasta el almacenamiento.
Qué es Kimi K2.5 y por qué importa tanto
Kimi K2.5 es un modelo de lenguaje grande desarrollado por Moonshot AI, empresa china que ha ganado bastante atención en el panorama global de inteligencia artificial. A diferencia de muchos modelos que llegan al mercado con capacidades genéricas y promesas vagas, Kimi K2.5 fue construido con un enfoque explícito en razonamiento largo, uso de herramientas externas y ejecución de tareas complejas a lo largo de múltiples turnos de conversación. Esto lo coloca directamente en el centro de lo que los desarrolladores de agentes autónomos necesitan hoy: un modelo que no solo responde, sino que actúa, planifica e va iterando.
Reciba el mejor contenido sobre innovación en su correo electrónico.
Todas las noticias, consejos, tendencias y recursos que buscas, directamente en tu bandeja de entrada.
Al suscribirte al boletín informativo, aceptas recibir comunicaciones de Método Viral. Nos comprometemos a proteger y respetar siempre tu privacidad.
La ventana de contexto de 256k tokens es uno de los puntos más importantes del modelo. Para quien no está familiarizado con esta métrica, los tokens son fragmentos de texto que el modelo procesa de una vez. Cuanto mayor es la ventana, más información puede considerar el modelo al mismo tiempo, lo cual es fundamental para agentes que necesitan mantener un historial largo de conversaciones, rastrear acciones pasadas, interpretar documentos extensos o coordinar múltiples flujos de datos en paralelo. Con 256k tokens disponibles, Kimi K2.5 puede operar en escenarios que simplemente se bloquean o pierden coherencia en modelos con ventanas menores, convirtiéndolo en una opción naturalmente más robusta para aplicaciones reales de automatización inteligente.
Además de la ventana de contexto, el soporte a tool calling multi-turno es lo que realmente diferencia a Kimi K2.5 en el contexto de agentes autónomos. Tool calling es la capacidad que tiene el modelo de llamar funciones externas, APIs o herramientas durante la generación de una respuesta. Cuando esto ocurre en múltiples turnos, significa que el modelo puede encadenar acciones, verificar resultados, ajustar el plan y seguir operando sin perder el hilo. Sumado al soporte de visión, que permite interpretar imágenes y datos visuales, y a las salidas estructuradas, que garantizan respuestas en formatos como JSON de forma fiable, el modelo se convierte en una pieza bastante completa para quien quiere montar pipelines de IA que realmente funcionen en producción.
Por qué Cloudflare eligió este modelo para estrenar los LLMs en Workers AI
La decisión de Cloudflare de estrenar el soporte a modelos grandes con Kimi K2.5 no parece casual. La empresa ha posicionado Workers AI como una plataforma orientada al ciclo de vida completo de agentes de IA, no solo para inferencia puntual. En ese contexto, elegir un modelo frontier open-source con capacidades robustas de agentic workflows tiene todo el sentido: valida la propuesta de la plataforma y entrega un caso de uso real y concreto desde el primer día. Cloudflare no necesitó vender el modelo a base de narrativa, trajo sus propios números internos para demostrar que el caso funciona.
La empresa contó que pasó semanas probando Kimi K2.5 como motor para sus herramientas internas de desarrollo. Dentro del entorno OpenCode, ingenieros de Cloudflare usaron el modelo como driver diario para tareas de codificación con agentes. Además, el modelo fue integrado al pipeline automatizado de code review de la empresa, que es visible públicamente a través del agente Bonk en los repositorios de Cloudflare en GitHub. En producción, el modelo demostró ser una alternativa rápida y eficiente frente a modelos propietarios más grandes, sin sacrificar calidad en los resultados.
El uso interno que Cloudflare describió es bastante revelador sobre el potencial del modelo en un entorno de producción exigente. Un agente de seguridad corriendo dentro de la infraestructura de la empresa llegó a procesar más de 7 mil millones de tokens por día, lo que es un volumen expresivo por cualquier métrica. Ese agente encontró más de 15 problemas confirmados en una sola base de código. Cuando pones eso en perspectiva con el ahorro del 77% respecto a modelos propietarios de nivel equivalente, el argumento económico queda evidente. Una diferencia que llegaría a 2,4 millones de dólares al año en el escenario alternativo no es marginal. Es el tipo de cifra que entra en la hoja de presupuesto y cambia decisiones de arquitectura de sistemas enteros.
Merece la pena destacar también el hecho de que Kimi K2.5 sea open-source en esta ecuación. Los modelos propietarios cobran no solo por el uso, sino también por la dependencia que generan. Cuando construyes sobre un modelo abierto y lo alojas en una plataforma como Workers AI, mantienes el control sobre cómo se usa el modelo, por dónde circulan los datos y cómo evoluciona la arquitectura a lo largo del tiempo. Para empresas que operan en sectores con requisitos de compliance o que simplemente quieren evitar el lock-in de un proveedor específico, esta combinación de open-source con infraestructura gestionada resulta bastante atractiva.
La relación coste-beneficio que cambia las cuentas de los agentes personales y corporativos
Cloudflare se encargó de posicionar este lanzamiento no solo como una mejora técnica, sino como una respuesta directa a un problema económico que se está volviendo cada vez más urgente. A medida que crece la adopción de IA, la empresa observa un cambio fundamental en la forma en que los equipos de ingeniería e incluso los individuos operan en el día a día. Es cada vez más habitual tener un agente personal, como OpenClaw, funcionando 24 horas al día, los siete días de la semana. El volumen de inferencia se está disparando.
Esta nueva realidad de agentes personales y de codificación hace que el coste deje de ser una preocupación secundaria y se convierta en el principal obstáculo para escalar. Cuando cada empleado de una empresa tiene múltiples agentes procesando cientos de miles de tokens por hora, la factura con modelos propietarios simplemente deja de cuadrar. La expectativa de Cloudflare es que las empresas van a migrar cada vez más hacia modelos open-source que ofrezcan razonamiento de nivel frontier sin la etiqueta de precio de los modelos cerrados. Y Workers AI se posiciona como facilitador de esa transición, ofreciendo desde endpoints serverless para un agente personal hasta instancias dedicadas que alimentan agentes autónomos en toda una organización.
El stack de inferencia para modelos grandes: lo que pasa bajo el capó
Workers AI ya servía modelos, incluidos LLMs, desde su lanzamiento hace dos años, pero históricamente priorizaba modelos más pequeños. Parte de la razón era que, durante un tiempo, los LLMs open-source quedaban significativamente por detrás de los modelos de los laboratorios frontier. Eso cambió con modelos como Kimi K2.5, pero para servir este tipo de LLM muy grande, Cloudflare necesitó hacer cambios importantes en el stack de inferencia.
La empresa desarrolló kernels personalizados para Kimi K2.5, construidos sobre el motor de inferencia propietario llamado Infire. Estos kernels optimizan la forma en que se sirve el modelo, mejorando el rendimiento y la utilización de las GPUs y desbloqueando ganancias que simplemente no existen cuando ejecutas el modelo directamente de fábrica, sin ajustes.
Además, existen múltiples técnicas y configuraciones de hardware que se pueden utilizar para servir un modelo grande. Los desarrolladores típicamente combinan técnicas de paralelismo de datos, tensor y expertos para optimizar el rendimiento. Estrategias como el disaggregated prefill, en la que las etapas de prefill y generación se separan en máquinas diferentes para obtener mejor throughput y mayor utilización de GPU, también juegan un papel importante. Implementar estas técnicas e incorporarlas al stack de inferencia requiere mucha experiencia dedicada para dar en el clavo.
Ese es justamente el punto que Cloudflare quiere destacar: Workers AI ya hizo toda esa experimentación e ingeniería entre bastidores. Mucho de esto simplemente no viene listo cuando alojas un modelo open-source por tu cuenta. El beneficio de usar una plataforma gestionada como esta es que no necesitas ser un ingeniero de Machine Learning, un especialista en DevOps o un ingeniero de fiabilidad para hacer las optimizaciones necesarias. La parte difícil ya está hecha, y el desarrollador solo necesita llamar a una API. 🛠️
Caching de prefijo y afinidad de sesión: ahorro inteligente en tokens
El anuncio de Kimi K2.5 vino acompañado de mejoras de infraestructura que merecen atención especial, empezando por el caching de prefijo. Cuando trabajas con agentes, es muy probable que estés enviando una gran cantidad de tokens de entrada como parte del contexto. Pueden ser prompts de sistema detallados, definiciones de herramientas, herramientas de servidores MCP o bases de código enteras. En teoría, con la ventana de 256k tokens de Kimi K2.5, una sola petición podría contener casi 256 mil tokens de entrada. Eso es muchísimo.
Para entender cómo ayuda el caching, hay que saber cómo un LLM procesa una petición. El procesamiento se divide en dos etapas: la etapa de prefill, que procesa los tokens de entrada, y la etapa de generación, que produce los tokens de salida. Estas etapas son secuenciales, es decir, los tokens de entrada necesitan ser totalmente procesados antes de que comience la generación. En conversaciones multi-turno, cada nuevo prompt enviado por el cliente incluye todos los prompts anteriores, herramientas y contexto de la sesión. La diferencia entre peticiones consecutivas generalmente son solo unas pocas líneas nuevas de entrada, mientras que todo el resto ya pasó por la etapa de prefill en una petición anterior.
Aquí es donde el caching de prefijo entra en acción. En lugar de rehacer el prefill de toda la petición, Workers AI puede cachear los tensores de entrada de una petición anterior y hacer prefill solo de los nuevos tokens de entrada. Esto ahorra tiempo y computación en la etapa de prefill, resultando en un Time to First Token más rápido y un throughput de Tokens Per Second más alto, ya que la GPU no se queda bloqueada esperando a que termine el prefill.
Workers AI siempre hizo caching de prefijo, pero ahora está exponiendo los tokens cacheados como una métrica de uso y ofreciendo descuento en tokens cacheados en comparación con tokens de entrada normales. Además, Cloudflare introdujo un nuevo header llamado x-session-affinity. Cuando envías este header con una cadena única por sesión o por agente, la petición se enruta a la misma instancia del modelo, aumentando la tasa de acierto de la cache de prefijo. Más tokens cacheados significan TTFT más rápido, TPS más alto y costes de inferencia menores. Algunos clientes como OpenCode ya implementan esto automáticamente, y el Agents SDK starter de Cloudflare también viene configurado para usar este recurso.
API asíncrona rediseñada: inferencia durable para agentes que no necesitan tiempo real
La otra gran novedad de infraestructura es la API asíncrona rediseñada, que responde a un patrón de uso muy específico de agentes modernos: tareas que tardan en completarse y que no necesitan mantener una conexión abierta todo el tiempo.
Herramientas que usamos a diario
Cloudflare es directa sobre un hecho que muchos proveedores prefieren no admitir: la inferencia serverless es muy difícil. Con un modelo de negocio de pago por token, resulta más barato a nivel de petición individual porque no necesitas pagar por GPUs enteras para atender tus solicitudes. Pero existe un trade-off: tienes que competir con el tráfico de otras personas y con restricciones de capacidad, y no hay garantía estricta de que tu petición será procesada. Esto no es exclusivo de Workers AI, es la realidad de los proveedores serverless de modelos en general, como lo evidencian las frecuentes noticias sobre proveedores sobrecargados e interrupciones de servicio.
Para volúmenes de peticiones que exceden los límites de tasa síncronos, ahora es posible enviar lotes de inferencias para que se completen de forma asíncrona. La nueva API asíncrona funciona más como procesamiento flex que como una API de batch tradicional: las peticiones en cola se procesan en cuanto hay margen disponible en las instancias del modelo. Para casos de uso asíncronos, no vas a encontrar errores por falta de capacidad, y la inferencia se ejecutará de forma durable en algún momento. En las pruebas internas de Cloudflare, las peticiones asíncronas generalmente se ejecutaron en menos de cinco minutos, pero eso depende del volumen de tráfico en vivo.
Bajo el capó, Cloudflare migró de un sistema basado en push a un sistema basado en pull. Esto permite que las peticiones en cola sean extraídas en cuanto hay capacidad disponible. La empresa también añadió mejores controles para ajustar el throughput de las peticiones asíncronas, monitorizando la utilización de GPU en tiempo real y extrayendo peticiones asíncronas cuando la utilización es baja. De esta forma, las peticiones síncronas críticas mantienen prioridad mientras las peticiones asíncronas siguen procesándose de manera eficiente. Es una solución ideal para casos de uso que no son en tiempo real, como agentes de escaneo de código o agentes de investigación. También existe la posibilidad de configurar notificaciones de eventos para saber cuándo se completó la inferencia, en lugar de estar haciendo polling sobre la petición. 👀
Qué significa todo esto para quien construye con IA hoy
El movimiento de Cloudflare con Workers AI y Kimi K2.5 representa algo más grande que la simple adición de un nuevo modelo de IA al catálogo. Es una señal clara de que la plataforma quiere ser el entorno donde los agentes autónomos viven de punta a punta, desde la inferencia hasta el almacenamiento, pasando por el enrutamiento, la seguridad y la orquestación de flujos. Cuando consideras que Cloudflare ya ofrece Workers para ejecución de código en el borde, KV y R2 para almacenamiento, D1 para base de datos y Durable Objects para estado persistente, Workers AI con soporte a LLMs grandes cierra un bucle importante para quien quiere construir aplicaciones de IA sin necesidad de juntar piezas de cinco proveedores diferentes.
Para desarrolladores que trabajan con agentes, la combinación de un modelo con tool calling multi-turno, ventana de contexto amplia, caching de prefijo con descuento, afinidad de sesión y API asíncrona dentro de una infraestructura ya familiar reduce bastante la fricción de poner algo en producción. No se trata solo de coste, aunque el argumento económico sea fuerte. Se trata de la capacidad de iterar rápido, probar diferentes arquitecturas de agentes y escalar sin necesidad de reescribir todo cuando el volumen crece. Ese tipo de flexibilidad es lo que separa a los proyectos que se quedan en prueba de concepto de los que llegan a producción con consistencia.
El Agents SDK starter de Cloudflare ya usa Kimi K2.5 como modelo por defecto, lo que facilita las cosas a quien quiere empezar desde cero. También es posible conectar con Kimi K2.5 en Workers AI directamente a través de OpenCode y probar el modelo en el playground interactivo de Cloudflare. El ecosistema ya está montado para que el desarrollador pueda experimentar y validar antes de escalar.
El panorama general de infraestructura para IA está cambiando rápidamente, e iniciativas como esta muestran que la competencia ya no es solo entre los modelos en sí, sino entre los ecosistemas que los rodean. Tener un modelo potente disponible es el punto de partida. Lo que marca la diferencia en el día a día es la latencia, el coste por token, la facilidad de integración con el resto del stack y la fiabilidad de la plataforma en horas punta. Workers AI, con Kimi K2.5 como buque insignia, está apostando claramente por poder entregar todo eso junto, y los números que Cloudflare trajo de su uso interno sugieren que no es solo una promesa. 🚀
