Divinci AI se une a Cloudflare Workers Launchpad Cohorte #6

Nos emociona compartir que Divinci AI ha sido aceptado en Cloudflare Workers Launchpad Cohorte #6! Este programa acelerador apoya a startups innovadoras que construyen sobre la plataforma de edge computing de Cloudflare, y nos sentimos honrados de ser parte de esta cohorte excepcional.

¿Por qué Cloudflare Workers?

En Divinci AI, estamos construyendo la próxima generación de herramientas de colaboración empresarial de IA con un enfoque en confiabilidad, seguridad y rendimiento. La plataforma de edge computing de Cloudflare ha sido fundamental para lograr estos objetivos, permitiéndonos ofrecer capacidades de IA sofisticadas con latencia mínima en todo el mundo.

Despliegue global en el edge permitiendo IA a la velocidad del pensamiento

Nuestra Infraestructura Impulsada por Cloudflare

Hemos arquitecturado toda nuestra plataforma alrededor del conjunto de productos de Cloudflare, creando una infraestructura poderosa y escalable que soporta nuestros pipelines avanzados de RAG (Generación Aumentada por Recuperación):

Cloudflare Workers & Workflows

La columna vertebral de nuestra plataforma, Cloudflare Workers impulsa nuestra capa de cómputo serverless, manejando millones de solicitudes con tiempos de respuesta de sub-milisegundos. Usamos Cloudflare Workflows para orquestar pipelines RAG complejos de múltiples pasos que recuperan, procesan y sintetizan información de múltiples fuentes de manera inteligente.

D1 para Almacenamiento de Fragmentos RAG

Aprovechamos Cloudflare D1, su base de datos SQL distribuida, para almacenar y consultar nuestros fragmentos RAG eficientemente. La arquitectura basada en edge de D1 asegura que los fragmentos de documentos se almacenen cerca de nuestros usuarios, reduciendo dramáticamente la latencia de recuperación y mejorando la calidad de nuestras respuestas de IA.

Vectorize para Búsqueda Semántica

Cloudflare Vectorize sirve como una de nuestras opciones de base de datos vectorial, permitiendo búsqueda semántica ultrarrápida a través de millones de embeddings de documentos. Esto permite que nuestros sistemas de IA encuentren el contexto más relevante para cualquier consulta, independientemente de cómo esté formulada.

Workers AI para Modelos de Código Abierto

Integramos Cloudflare Workers AI para proporcionar acceso a modelos de lenguaje de código abierto de vanguardia de Hugging Face, incluyendo Llama 3, Mistral y otros modelos de última generación. Esto brinda a nuestros clientes empresariales flexibilidad para elegir el modelo adecuado para sus casos de uso específicos mientras mantienen privacidad y control de datos.

R2 para Almacenamiento de Medios

Cloudflare R2 maneja todo nuestro procesamiento de audio, video y almacenamiento de carga de archivos de usuarios. Con cero tarifas de salida y APIs compatibles con S3, R2 proporciona almacenamiento de objetos de nivel empresarial que escala sin problemas con nuestra creciente base de clientes.

API Shield para Seguridad

A medida que nos preparamos para lanzar nuestras APIs públicas, Cloudflare API Shield proporciona protección esencial contra el abuso, limitación de velocidad y validación de esquemas. Esto asegura que nuestras APIs permanezcan seguras, eficientes y confiables para todos nuestros socios de integración.

Experimentando con Cloudflare Containers

También estamos explorando Cloudflare Containers mientras trabajamos para mover nuestra infraestructura completa para que sea principalmente basada en Cloudflare. Esto nos permitirá ejecutar cargas de trabajo aún más complejas en el edge mientras mantenemos el rendimiento y la confiabilidad que nuestros clientes esperan.

Cómo Divinci Realmente Usa Cloudflare — el Stack de Producción

Hemos evitado la trampa de la “prosa de marketing con sabor a Cloudflare” aquí. Lo que sigue es el stack real tal como se despliega en nuestro monorepo: 29 Workers en producción, 3 Worker Workflows, 5 modelos de Workers AI, 4 buckets de R2, 6 tipos de Queues, Hyperdrive sobre Postgres, Containers respaldados por Durable Objects para PDF y audio, y 36 tail consumers transmitiendo logs estructurados a observabilidad. Las piezas están nombradas según sus bindings reales y dominios de ruta para que los ingenieros que lean esto puedan hacer grep sobre ellas.

Capa 1 — Cinco Workers principales en el edge

Cada solicitud HTTP llega a uno de cinco Workers con dominio personalizado:

• divinci-api en api.divinci.app — la frontera REST: auth, validación JWT, resolución de rutas, fan-out a workers internos. Los bindings incluyen el bucket R2 FILES, el namespace KV CACHE, la base de datos D1 de doc-elements, Workers AI, Hyperdrive, Analytics Engine, y cuatro Queues nombradas. Este es el worker que ve la solicitud primero.
• web-client-r2-server en chat.divinci.app — el frontend estático, servido directamente desde R2 a través de un Worker delgado que maneja reescrituras del lado del Worker y enrutamiento hacia el SPA.
• divinci-agent — el orquestador de composición de respuestas. Extrae contexto de D1 + KV + R2, decide qué modelo de Workers AI llamar (o si delegar a una API externa vía Hyperdrive), y compone la respuesta.
• chunks-workflow en rag-workflow.divinci.app — el punto de entrada de Worker Workflows; invocado cada vez que se necesita iniciar un pipeline RAG de larga duración.
• connector-sync-worker — el worker de ingesta externa que sincroniza desde Dropbox / Drive / conectores de terceros similares hacia el pipeline RAG.

Hay 24 workers más detrás de estos cinco (tail consumers, microservicios internos) — los cinco anteriores son los expuestos a la internet pública.

Capa 2a — Worker Workflows (tres pipelines asíncronos multi-paso)

Cloudflare Workflows reemplazó nuestros antiguos job runners basados en Durable Objects el año pasado. Tres workflows están en producción hoy, todos usando el patrón de checkpoint step.do("name", async () => {…}) para que cada paso sea reintentado independientemente en caso de fallo sin re-ejecutar todo el pipeline:

• ReindexWithVersionWorkflow — re-embebe el corpus completo de un cliente cuando cambia la versión del modelo de embedding. Versiona el índice resultante para que un roll-back sea un cambio de un solo binding.
• BrowserExtractionWorkflow — extrae texto de documentos cargados vía el container Durable Object openparse-cf, luego trocea + encola los chunks para embedding.
• AudioToRagWorkflow — transcribe audio con Workers AI Whisper, ejecuta diarización de hablantes a través del Container audio-services, trocea la transcripción y la encola para embedding.

Los tres se declaran en wrangler.toml así:

[[env.production.workflows]]
name = "reindex-with-version"
binding = "REINDEX_WITH_VERSION"
class_name = "ReindexWithVersionWorkflow"

Capa 2b — Seis Queues, ajustadas para el límite de escritor único de D1

El trabajo asíncrono fluye a través de seis Queues nombradas, cada una con max_batch_size, max_concurrency y max_retries ajustados al cuello de botella del servicio downstream. Las queues chunking y api-jobs corren a 10-batch / 5-concurrencia porque escriben a D1 (cuyo escritor por shard es de un solo hilo); las queues vectorize y reindex corren más calientes a 25/10 porque llaman a APIs externas de embedding. La queue d1-sync serializa las escrituras a los shards D1 por vector para que dos workflows no compitan por la misma fila.

La lección que ojalá hubiéramos aprendido antes: Las Queues son lo único que mantiene honesto un setup de D1 sharded por cliente. Sin ellas, un solo tenant con una carga grande mata de hambre a todos los demás en el mismo shard hasta que la solicitud expire.

Capa 3 — R2, D1, KV y Hyperdrive

La capa de almacenamiento está dividida en cuatro primitivos, cada uno elegido para un patrón de acceso diferente.

R2 (cuatro buckets por entorno) — los bindings son FILES (documentos RAG), AUDIO_FILES (audio fuente para pipelines de transcripción), PUBLIC_UPLOADS (adjuntos de chat servidos en endpoints de URL firmada) y TEMP_UPLOADS (la zona de aterrizaje para uploads presignados). Cero tarifas de egreso son la razón principal, pero la más profunda es que el mismo Worker puede firmar una URL, aceptar una carga de varios MB, iniciar el BrowserExtractionWorkflow y servir el contexto RAG resultante — todo sin salir del edge de Cloudflare.

D1 (sharded por tenant) — cada cliente obtiene su propia base de datos D1, con chunks + metadatos en tablas normales y una tabla virtual FTS5 para búsqueda solo-texto. Sharding por cliente fue la única forma de evitar el cuello de botella del escritor único en tenants calientes. El costo es que manejamos un fan-out a través de shards en la capa de aplicación; el beneficio es que el pico de un tenant no puede matar de hambre las lecturas de otro.

KV (tres namespaces) — CACHE mantiene resultados de validación JWT y config del tenant; EMBEDDING_CACHE es el mapa hash-de-contenido → bytes-de-embedding con TTL de 30 días (esta es la mayor reducción de costo que hicimos — cachear embeddings por hash de contenido redujo la factura diaria de la API de embedding en un orden de magnitud); VECTORIZE_CACHE es la capa envoltura que usa el worker vectorize-cache para memorizar lookups de vectores.

Hyperdrive — pooling de conexiones Postgres en el edge. El binding HYPERDRIVE permite a un Worker abrir una conexión Postgres sin pagar el costo del handshake TCP + auth en cada solicitud. Lo usamos para la pequeña porción de datos relacionales (estado de suscripción, ACLs a nivel de organización) que no encaja en el modelo sharded de D1.

Capa 4a — Workers AI (cinco modelos en producción)

Workers AI es la capa de inferencia en plataforma; la usamos donde el modelo es lo suficientemente pequeño para que el ida-y-vuelta a un proveedor externo no valga la latencia o el costo:

Para generación de escala frontera (Claude, clase GPT-4) todavía enrutamos a proveedores externos a través de Hyperdrive — el catálogo de Workers AI está creciendo pero todavía no incluye los modelos más grandes que necesitamos para las consultas más difíciles.

Capa 4b — Containers, Email, Analytics, Tail Consumers

Containers Durable Object son la pieza más nueva del stack: imágenes Docker completas corriendo en el runtime de Workers, con scope por instancia DO. Ejecutamos dos:

• openparse-cf es un parser de PDF en Python empaquetado como Container, llamado por el BrowserExtractionWorkflow para troceo de documentos.
• audio-services-container ejecuta ffmpeg + pyannote-audio para diarización de hablantes, llamado por el AudioToRagWorkflow. Tier de memoria standard-2 (6 GB) para que los modelos más pesados carguen sin OOM.

Email Workers — un Worker transaccional de notificación envía email de producto, y un Worker de enrutamiento gestiona el correo entrante en email.divinci.app/verified-emails. Ambos usan el primitivo de Email Routing de Cloudflare en lugar de una API de email externa.

Analytics Engine — un dataset de Workers Analytics Engine es el sink de eventos estructurados para analítica de producto. Cualquier cosa que antes hubiéramos enviado a Segment/Amplitude aterriza aquí primero, luego se reenvía downstream.

Tail Consumers (36 workers) — cada worker de producción tiene su lista tail_consumers poblada con un consumidor *_tail dedicado. Cada consumidor parsea los logs de invocación del Worker y reenvía eventos estructurados a nuestro pipeline de observabilidad. El fan-out es lo que hace depurable la topología de microservicios de ocho workers.

Cron Triggers — producción ejecuta un trabajo de limpieza de huérfanos cada 30 minutos; stage corre cada 10 minutos para feedback más ajustado mientras iteramos sobre la lógica de limpieza.

Una nota sobre Vectorize — qué no usamos, y por qué

Evaluamos Cloudflare Vectorize durante la migración y finalmente no lo adoptamos como nuestro almacén vectorial principal. La decisión no tuvo nada que ver con Vectorize en sí — ha mejorado significativamente a través de 2025–2026. La razón por la que aterrizamos en D1 FTS5 + un servicio de embedding externo fue que nuestra arquitectura de recuperación es híbrida (léxica + semántica con un re-ranker calibrado encima), y FTS5 en D1 nos dio la mitad léxica de eso gratis, en el mismo shard que los metadatos del documento. Añadir Vectorize habría introducido un segundo modelo de consistencia — un índice separado que tiene que mantenerse en sincronía con D1 — por una mejora marginal de recall en los volúmenes en los que operamos. El nombre del namespace KV VECTORIZE_CACHE es un remanente del período de evaluación; el worker detrás de él ahora cachea lookups de embedding, no resultados de Vectorize.

Si nuestro modelo de recuperación se desplaza hacia recuperación solo-densa a muy gran escala, Vectorize es el siguiente paso natural. Una respuesta honesta supera a una afirmación de marketing.

Qué Significa Esto para Nuestros Clientes

Ser parte del acelerador Workers Launchpad significa que tendremos una colaboración aún más profunda con el equipo de ingeniería de Cloudflare, acceso temprano a nuevas funciones y los recursos para empujar los límites de lo que es posible con edge computing e IA.

Para nuestros clientes, esto se traduce en:

• Respuestas de IA más rápidas con despliegue global en el edge
• Confiabilidad mejorada a través del SLA de uptime del 99.99% de Cloudflare
• Mejor privacidad de datos con procesamiento en el edge
• Funciones innovadoras impulsadas por productos de vanguardia de Cloudflare
• Infraestructura escalable que crece con tus necesidades

Mirando Hacia Adelante

Estamos increíblemente emocionados por esta asociación y las oportunidades que trae. A medida que continuamos construyendo el futuro de la colaboración empresarial impulsada por IA, la plataforma de Cloudflare permanecerá en el corazón de nuestra infraestructura, permitiéndonos ofrecer experiencias excepcionales a equipos alrededor del mundo.

Innovación a través de las eras: Construyendo el futuro con principios atemporales

¿Quieres aprender más sobre cómo Divinci AI puede transformar el flujo de trabajo de IA de tu equipo? Solicita una demo para ver nuestra plataforma en acción.

Acerca del Cloudflare Workers Launchpad

El Workers Launchpad es el programa de startups de Cloudflare que proporciona financiamiento, soporte técnico y recursos de comercialización a empresas que construyen sobre la plataforma Workers. Aprende más sobre la Cohorte #6 y las otras empresas innovadoras que se unen a este programa.