prerrequisitos
cuando me propuse construir un sistema de gestión de contenido (cms) moderno para artículos tecnológicos y financieros, rápidamente me encontré con un desafío arquitectónico fundamental: ¿cómo equilibrar la lentitud inherente de la inferencia de ia con la demanda de cargas de página instantáneas? la generación de contenido financiero multilingüe, como los resúmenes matutinos o los informes sectoriales, implica orquestar llamadas a servicios como la api de gemini para la redacción, tavily para la investigación web y nuestra api interna de análisis técnico (ta) para obtener información del mercado. este proceso tiene estado, consume muchos recursos y puede tardar fácilmente varios minutos. sin embargo, para el usuario final, cualquier cosa que no sea una carga de página en milisegundos se siente lenta. esta tensión entre el procesamiento dinámico y computacionalmente intensivo del backend y la experiencia de usuario ultrarrápida fue el problema central que intenté resolver.
en este artículo, te guiaré a través de mi enfoque para construir un sistema de este tipo en google cloud platform (gcp). diseñé una arquitectura modular sin servidor que aprovecha los patrones basados en eventos para desacoplar las tareas de ia de larga duración de la entrega de contenido. exploraremos el uso estratégico de los servicios de gcp para el enrutamiento global en el borde, la orquestación asincrónica de ia y la seguridad de nivel empresarial. mi objetivo era crear un sistema que no solo generara de manera eficiente contenido financiero de alta calidad impulsado por ia, sino que también lo entregara a usuarios de todo el mundo con velocidad y confiabilidad sin compromisos.
para comprender los conceptos que discutiré y posiblemente aplicarlos en sus propios proyectos, necesitará:
- una cuenta de google cloud platform (gcp) con la facturación habilitada. puede registrarse para obtener una cuenta de nivel gratuito de gcp si no tiene una.
- la cli
gcloudinstalada y configurada. asegúrese de estar autenticado en su proyecto de gcp. puede encontrar las instrucciones de instalación en la documentación de la cligcloudde gcp. - terraform cli instalado (versión 1.0.0+). las instrucciones están disponibles en la documentación de terraform.
- python 3.12+ instalado en su máquina de desarrollo.
- permisos iam apropiados dentro de su proyecto de gcp para crear y administrar servicios como cloud run, temas de pub/sub, buckets de cloud storage y balanceadores de carga de aplicaciones externas globales.
arquitectura y conceptos: desacoplamiento de la ia de la entrega
la construcción de un cms que combine eficazmente la sofisticada generación de contenido de ia con la entrega estática de baja latencia exige un enfoque arquitectónico bien pensado. mi estrategia de diseño se basó en desacoplar los procesos de ia de larga duración de la entrega de contenido orientada al usuario, utilizando un patrón sin servidor y basado en eventos en gcp. así es como lo estructuré:
1. ia dinámica frente a entrega estática: el conflicto central
el conflicto fundamental al que me enfrenté fue la naturaleza de la generación de contenido frente al consumo de contenido. la generación de artículos impulsada por ia implica una secuencia compleja de operaciones: investigación web en tiempo real, redacción con modelos de lenguaje grandes, creación de imágenes con modelos de difusión y traducción multilingüe. todo este proceso es inherentemente vinculado a e/s y con uso intensivo de cpu, a menudo tardando varios minutos en completarse. mi diseño tuvo que separar completamente este 'trabajo pesado' de la experiencia del usuario final. los lectores esperan que las páginas web estáticas se carguen en milisegundos, servidas desde una ubicación de borde cercana a ellos.
esto me llevó a implementar un modelo híbrido: generación dinámica para autores y editores, y entrega estática, almacenada en caché en el borde para los lectores. la tubería de ia es asíncrona y desvinculada, empujando el contenido finalizado a una capa de entrega rápida. esto asegura que el costoso trabajo de ia computacionalmente nunca impacte la latencia orientada al usuario.
2. diseño modular sin servidor con cloud run
mi elección para la capa de computación fue google cloud run. descubrí que era una plataforma sin servidor potente y totalmente administrada que me permitía implementar aplicaciones en contenedores que escalan automáticamente de cero a miles de instancias. esto significaba que solo pagaba por la computación utilizada, lo que se alineaba perfectamente con nuestros objetivos de finops. para mí, la belleza de cloud run radica en su simplicidad para implementar microservicios sin administrar ninguna infraestructura subyacente.
el cms en sí se ejecuta como varios servicios de cloud run distintos, cada uno de los cuales maneja una parte específica del sistema:
- backend (
backend-svc-prod): un servicio de api rest de fastapi que maneja las principales tuberías de contenido, ingiere webhooks y administra la ejecución asíncrona de tareas. aquí reside la lógica de orquestación de la ia. - frontend (
frontend-admin-svc-prod): una interfaz administrativa basada en nicegui. esto permite a mi equipo monitorear, revisar y activar manualmente la generación de contenido de ia, dándonos un control preciso sobre el proceso editorial. - servidor de documentación (
mcp-docs-svc-prod): un servidor de protocolo de contexto de modelo (mcp). lo construí para proporcionar recuperación de contexto para el backend, actuando esencialmente como un servicio de generación aumentada de recuperación (rag) para nuestros modelos de ia, alimentándolos con información de mercado actualizada y relevante.
al empaquetar estos componentes como microservicios en contenedores a partir de una única imagen de docker, garantice la coherencia entre los entornos y simplifique considerablemente nuestros flujos de trabajo de implementación.
3. orquestación de la tubería de generación de ia con pub/sub
el principal desafío de ingeniería que encontré fue la gestión de los tiempos de espera de ejecución. una tubería completa de generación de artículos puede superar fácilmente el tiempo de espera de solicitud síncrona típico de un servicio web (por ejemplo, cloud run tiene un tiempo de espera máximo de solicitud de 900 segundos). para sortear esto, implementé una tubería asíncrona y basada en eventos utilizando cloud scheduler y google cloud pub/sub.
este patrón me permitió dividir la carga de trabajo en un disparador rápido y síncrono y una fase de procesamiento asíncrona y desacoplada. cloud scheduler actúa como un disparador basado en el tiempo, enviando una solicitud autenticada a nuestro backend a intervalos predefinidos. el backend inicia rápidamente el proceso de redacción de contenido, persiste su estado y luego publica un mensaje en un tema de pub/sub. esto permite que la solicitud inicial se complete rápidamente, liberando el frontend o el programador.
pub/sub luego entrega de manera confiable este mensaje a otra instancia de nuestro servicio de backend (configurada como una suscripción push), que maneja las tareas de larga duración como la obtención de investigación, la generación de imágenes y la traducción de contenido. esto no solo resuelve el problema del tiempo de espera, sino que también proporciona una forma resistente y escalable de procesar nuestras tareas de generación de contenido.
4. entrega global en el borde y seguridad de confianza cero
para la entrega de contenido público, el html, css e imágenes estáticas generados por la tubería de ia se escriben directamente en los depósitos de google cloud storage (gcs). configuré un balanceador de carga de aplicaciones externo global para enrutar el tráfico público (/*) directamente a este backend de gcs. fundamentalmente, cloud cdn almacena en caché este contenido a nivel global, lo que garantiza una latencia de un solo dígito en milisegundos para los usuarios finales, independientemente de su ubicación geográfica. este diseño desacopla completamente el procesamiento dinámico de ia de la entrega de contenido, cumpliendo eficazmente nuestro requisito de baja latencia.
para el acceso administrativo al cms, implementé un modelo de confianza cero utilizando identity-aware proxy (iap). los puntos finales administrativos (por ejemplo, admin.thecloudarchitect.io) comparten el mismo balanceador de carga, pero enrutan el tráfico a los grupos de puntos finales de red (negs) sin servidor de cloud run. antes de que cualquier solicitud llegue al servicio de cloud run, iap la intercepta, aplicando la autenticación de la cuenta de google y políticas iam granulares. esto proporciona un perímetro de seguridad robusto, reduciendo significativamente la superficie de ataque. para proteger las credenciales sensibles, como las claves de api para gemini o tavily, las almaceno de forma segura en secret manager y las inyecto en los servicios de cloud run en tiempo de ejecución, mejorando aún más nuestra postura de seguridad.
resumen arquitectónico
5. la tubería de agentes de ia: un flujo de trabajo de varias etapas
construí el cms para tratar la ia no simplemente como una simple llamada a la api, sino como un sofisticado flujo de trabajo de varias etapas, todo orquestado dentro del servicio cloudrunbackend. esto me permitió desglosar la compleja generación de artículos en pasos manejables y observables:
- ingesta y fundamentación de datos: primero, inyecto datos de mercado relevantes (por ejemplo, los mayores ganadores/perdedores, datos ochlv) en la ventana de contexto del mensaje. estos datos suelen provenir de nuestra api ta interna o de un servicio de datos de mercado dedicado, lo que proporciona información precisa y en tiempo real para que la ia trabaje.
- investigación (tavily): dependiendo del tipo de artículo, configuré el sistema para realizar de 1 a 10 llamadas a la api de tavily. para un "enfoque sectorial", por ejemplo, esto ayuda a recuperar catalizadores en tiempo real, noticias de la noche a la mañana o anuncios específicos de la empresa, asegurando que los modelos de ia tengan la información externa más actualizada.
- escritor (gemini 2.5 flash): utilizo una plantilla de mensaje inicial (generalmente basada en jinja2) para dirigir a gemini 2.5 flash a redactar la carga útil json sin procesar del artículo. gemini 2.5 flash ofrece un excelente equilibrio entre rendimiento y rentabilidad, lo que lo hace ideal para generar borradores iniciales de forma rápida y económica.
- editor (gemini 2.5 pro): una vez que el borrador está completo, un modelo más potente y capaz, gemini 2.5 pro, lo revisa. este paso crítico verifica el tono, la precisión, la consistencia fáctica y el formato adecuado. este enfoque de múltiples modelos me permite aprovechar las fortalezas específicas de cada modelo al tiempo que optimiza los costos generales.
- elementos visuales (imagen 3): durante el proceso de redacción, gemini 2.5 flash también genera mensajes distintos y descriptivos para los activos visuales, típicamente una imagen de héroe 16:9 y una imagen de apoyo 1:1. estos mensajes se envían luego a imagen 3, el modelo de difusión de texto a imagen avanzado de google, para generar elementos visuales de alta calidad para el artículo.
- traducción: finalmente, el texto en inglés se pasa de nuevo a gemini (ya sea flash o pro, dependiendo de la relación calidad-costo requerida para la traducción) para su localización en idiomas objetivo como alemán (de), español (es), francés (fr), italiano (it) y neerlandés (nl). estas versiones traducidas también forman parte del contenido estático entregado a través de cloud cdn.
6. finops: equilibrar el coste y el rendimiento
ejecutar grandes modelos de lenguaje e infraestructura global en la nube puede volverse rápidamente prohibitivo si no se gestiona con cuidado. mi arquitectura emplea estrictos controles finops para mantener la eficiencia, asegurando que obtenemos el máximo valor por nuestro gasto.
6.1. economía unitaria de un artículo de ia
al seleccionar cuidadosamente los modelos y optimizar las llamadas a la api, he logrado mantener el costo por artículo excepcionalmente bajo. el uso de gemini 2.5 flash para la redacción de grandes volúmenes y la ingeniería de mensajes, y la reserva de gemini 2.5 pro solo para la fase editorial crítica, tiene un impacto significativo en el costo total. aquí hay un desglose basado en los precios actuales (aproximadamente 1 $ ≈ 0,92 €):
- tavily (investigación): normalmente ~0,02 € – 0,07 € (~0,02 $ – 0,08 $) por artículo, dependiendo del número de búsquedas.
- gemini (escritor/editor/mensajes/traducciones): aproximadamente ~0,05 € (~0,055 $) por todas las interacciones de gemini.
- imagen (2 imágenes): la generación de dos imágenes de alta resolución cuesta ~0,05 € – 0,07 € (~0,06 $ – 0,08 $).
- costo total por artículo multilingüe completamente publicado: ~0,13 € – 0,15 € (~0,14 $ – 0,16 $).
esto demuestra el poder de una tubería de ia finamente ajustada para lograr una eficiencia de costos notable.
optimización del uso de modelos de ia para la eficiencia de costos
cuando comencé a integrar la ia generativa, inicialmente consideré usar los modelos más potentes para cada paso. sin embargo, rápidamente me di cuenta de que al seleccionar estratégicamente los modelos en función de sus fortalezas específicas de la tarea y sus perfiles de costos, como usar gemini 2.5 flash para borradores iniciales y reservar gemini 2.5 pro para la edición crítica, podría reducir drásticamente los costos por artículo sin sacrificar la calidad. este enfoque escalonado me permitió escalar mi generación de contenido de manera eficiente mientras manteníamos nuestro presupuesto bajo control. agregué telemetría para monitorear los tokens de mensaje, salida y pensamiento, estableciendo un presupuesto para estos últimos (¡cuidado, el pensamiento está habilitado de forma predeterminada y consume mucho!)
6.2. escalado a cero y mitigación de arranques en frío
la capacidad de cloud run de escalar a cero instancias cuando está inactivo es una gran victoria para finops, lo que reduce significativamente los costos de computación fuera de los períodos de uso pico. sin embargo, esto introduce la posibilidad de arranques en frío (normalmente de 5 a 15 segundos de latencia) para los servicios orientados al usuario, en particular nuestro frontend de administración o los disparadores de api intradiarios. para mitigar esto sin incurrir en costos continuos de instancias siempre activas, implementé un trabajo dedicado de "mantenimiento en caliente" de cloud scheduler.
este trabajo hace ping tanto al backend (/health?deep=true) como al frontend (/health) cada 14 minutos, estrictamente durante el horario comercial europeo (06:00 – 22:00 cet). esto asegura que durante nuestras horas operativas, los servicios críticos estén "calientes" y respondan, al tiempo que les permite escalar a cero durante la noche y los fines de semana, maximizando el ahorro de costos.