Cloudflare incorporó modelos abiertos de gran escala a Workers AI, empezando por Kimi K2.5 con 256k de contexto, tool calling y capacidades multimodales. El cambio apunta a un problema operativo concreto: sostener agentes en producción sin que los costos de inferencia y los límites de capacidad rompan pipelines, revisiones de código y flujos asíncronos.
Introducción
En 2026, muchas organizaciones ya no evalúan IA solo por calidad de respuesta, sino por su viabilidad operativa: latencia consistente, costo por token, gobernanza y capacidad de integrarse con flujos existentes de plataforma. En ese contexto, Cloudflare anunció que Workers AI pasa a soportar modelos abiertos de mayor tamaño, iniciando con Kimi K2.5 de Moonshot AI.
La noticia es relevante para equipos de DevOps, SRE y plataforma porque no se limita a “agregar un modelo más” al catálogo. Cloudflare acompaña este lanzamiento con cambios en su stack de inferencia y en su capa de operación (afinidad de sesión, métricas de tokens cacheados y API asíncrona rediseñada), todos puntos con impacto real en costo, throughput y confiabilidad de workloads agentic.
Qué ocurrió
Según Cloudflare, Workers AI ahora ofrece Kimi K2.5 como modelo “frontier” abierto dentro de su plataforma serverless. El modelo se publica con una ventana de contexto de 256k tokens, soporte de tool calling multi-turn, entradas de visión y salidas estructuradas.
La compañía afirma que usó Kimi en flujos internos de ingeniería (incluida revisión automatizada de código) y reporta una reducción de costos significativa frente a alternativas propietarias para tareas equivalentes. También detalla mejoras de infraestructura para manejar inferencias de gran escala y picos de tráfico en escenarios de agentes permanentes.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos técnicos, el impacto se ve en cuatro planos:
1. **FinOps de IA aplicada a operaciones**: si los agentes se vuelven parte del día a día (revisión de PRs, triage, análisis de incidentes), el costo deja de ser marginal y pasa a ser una línea presupuestaria operativa.
2. **Rendimiento y experiencia de desarrollo**: mejoras en TTFT y tokens por segundo pueden acelerar ciclos de feedback en CI/CD y tooling interno.
3. **Resiliencia de la plataforma**: una API asíncrona más robusta ayuda a desacoplar picos de demanda y reduce fallas por capacidad en procesos no interactivos.
4. **Gobernanza y trazabilidad**: exponer métricas de caché y patrones de afinidad de sesión facilita observar por qué sube o baja el costo real de inferencia.
Detalles técnicos
En el plano técnico, Cloudflare describe tres cambios importantes:
– **Optimización del serving de modelos grandes**: menciona kernels personalizados sobre su motor de inferencia para mejorar utilización de GPU y throughput.
– **Aprovechamiento explícito de prefix caching**: ahora expone tokens cacheados como métrica de uso y propone usar el header `x-session-affinity` para subir el hit-rate de caché en conversaciones multi-turn.
– **API asíncrona renovada**: orientada a workloads que no requieren respuesta inmediata, con ejecución diferida para mitigar errores de capacidad en escenarios serverless.
Desde la documentación pública de Workers AI se observa además un marco operativo concreto: límites por tipo de tarea (por ejemplo, text generation) y un esquema de precios basado en “neurons”, con cupo diario gratuito y facturación incremental. Este modelo facilita estimaciones de costo, pero exige disciplina de observabilidad para evitar desviaciones cuando escalan agentes o contextos largos.
En términos de arquitectura, la combinación de contexto amplio (256k), tool calling y colas/eventos habilita patrones útiles para ingeniería de plataformas: agentes que leen grandes historiales de incidentes, validan políticas, ejecutan chequeos y publican resultados sin bloquear caminos síncronos críticos.
Qué deberían hacer los administradores o equipos técnicos
Los equipos de administración e ingeniería pueden convertir esta novedad en acciones prácticas inmediatas:
– **Definir perfiles de workload**: separar casos síncronos (chat operativo, asistencia en guardia) de casos asíncronos (auditorías, revisión masiva, análisis nocturno).
– **Instrumentar costo por flujo**: medir input/output tokens, tokens cacheados, latencia y tasa de reintento por tipo de agente.
– **Aplicar afinidad de sesión de forma consistente**: sin una estrategia estable de session affinity, se pierden beneficios de caché y sube el costo.
– **Establecer presupuestos y guardrails**: umbrales por equipo/proyecto, fallback de modelo y control de contexto máximo por caso de uso.
– **Integrar eventos en observabilidad**: consumir eventos de batch y errores en pipelines de alerting para detectar degradaciones temprano.
– **Probar con carga real antes de adopción amplia**: validar comportamiento en ventanas pico (deploys grandes, incidentes, cierres de sprint) y no solo en pruebas aisladas.
Conclusión
El movimiento de Cloudflare apunta a una tendencia clara: la conversación en IA para plataformas está migrando de “qué modelo razona mejor” a “qué stack permite operar agentes en producción con costos y SLOs controlados”. Para DevOps y SRE, la señal importante no es solo Kimi K2.5, sino el paquete completo de medidas operativas alrededor del serving, la caché y la asincronía.
Si esta aproximación se consolida, veremos más equipos tratando a la inferencia como otro servicio crítico de plataforma: con presupuestos, políticas de capacidad, observabilidad de extremo a extremo y procesos de mejora continua, igual que hoy se hace con CI/CD, colas o bases de datos administradas.
Fuentes
- https://blog.cloudflare.com/workers-ai-large-models/
- https://developers.cloudflare.com/workers-ai/platform/pricing/
- https://developers.cloudflare.com/workers-ai/platform/limits/