Ahorros proyectados de IA/ML a 3 años con modelos open source autogestionados
Reducidas del cronograma de migración mediante oleadas de aprovisionamiento en paralelo
Reescrituras de agentes, con Bedrock accesible mediante un cambio de configuración de una sola línea
Lovelace
Pittsburgh, Pensilvania
Servicios financieros / Inteligencia de datos
Amazon EKS, Amazon Aurora PostgreSQL, Amazon S3, AWS Bedrock, Amazon SageMaker, Amazon ElastiCache, Amazon Redshift, AWS WAF, AWS Secrets Manager, AWS KMS, Observabilidad autogestionada (Grafana, Mimir, Loki, Tempo)
Lovelace, una empresa de inteligencia de datos que opera plataformas impulsadas por IA para servicios financieros y clientes empresariales multiinquilino, contrató a Avahi para realizar una evaluación integral para migrar toda su infraestructura y cargas de trabajo de IA/ML de Google Cloud Platform a AWS. La evaluación reveló que la arquitectura nativa de Kubernetes de Lovelace ya era, en gran medida, agnóstica a la nube, y que la complejidad real de la migración se concentraba en la capa de IA/ML (modelos de Vertex AI, inferencia ajustada y pipelines de embeddings) y en la capa de datos (Cloud SQL, Bigtable y BigQuery). Avahi entregó un plan maestro de migración completo que abarca la arquitectura objetivo, el benchmarking de modelos, las proyecciones de costos y un plan por oleadas y fases que reduce el cronograma de migración, estimado en aproximadamente 14 a 22 semanas, mediante aprovisionamiento en paralelo.
Lovelace opera dos plataformas principales: una plataforma de inteligencia de datos que procesa noticias y datos financieros a través de 35 feeds externos, y una plataforma multiinquilino que atiende a clientes empresariales. Su plataforma se ejecuta sobre bases de datos autogestionadas dentro del clúster, con una fuerte dependencia de Google Vertex AI para la inferencia de LLM, embeddings y modelos ajustados. Las plataformas soportan cargas de trabajo de alto rendimiento, y algunos componentes requieren hasta 2,000 consultas por segundo para operaciones de resolución de entidades y búsqueda de embeddings.
Lovelace necesitaba migrar toda su infraestructura en la nube de GCP a AWS, pero la complejidad de sus cargas de trabajo de IA/ML generaba una incertidumbre significativa en torno a los costos, el cronograma y la viabilidad técnica. Sus plataformas dependían de Vertex AI para múltiples tipos de modelos (variantes de Gemini para la orquestación de agentes, text-embedding-005 para búsqueda vectorial y modelos personalizados ajustados para la resolución de entidades), y la ruta de migración para cada uno no estaba clara.
Los modelos ajustados presentaban desafíos particulares: eran críticos para el pipeline de resolución de entidades, pero no tenían un equivalente directo en AWS, lo que requería evaluar Amazon Nova, SageMaker y opciones autogestionadas. Sin una comprensión clara de la ruta de migración, Lovelace enfrentaba el riesgo de costos extendidos de doble nube, posibles interrupciones del servicio durante el cambio a producción y la posibilidad de descubrir problemas técnicos bloqueantes a mitad de la migración.
Además, se desconocían las implicaciones de costos de cambiar de proveedor de IA/ML. Las suposiciones iniciales sugerían que migrar a AWS Bedrock sería sencillo, pero sin un análisis detallado de los volúmenes de tokens, los requisitos de QPS y las diferencias de precios entre modelos, Lovelace no podía tomar decisiones informadas sobre su arquitectura objetivo.
Lovelace eligió AWS como su plataforma de nube objetivo porque quiere integrarse al ecosistema de AWS Marketplace. Además, puede aprovechar la amplitud de servicios de IA/ML de AWS. AWS Bedrock ofrecía acceso a múltiples modelos fundacionales mediante una API unificada, mientras que Amazon SageMaker proporcionaba una vía administrada para sus necesidades de entrenamiento e inferencia de modelos ajustados. La combinación de Amazon EKS para sus cargas de trabajo de Kubernetes, Aurora PostgreSQL para su capa de datos relacional y el stack de IA/ML de AWS creó una arquitectura objetivo cohesiva que podía respaldar su crecimiento y, al mismo tiempo, reducir la complejidad operativa.
Lovelace requería un socio con profunda experiencia tanto en sistemas de IA/ML como en migración a la nube para gestionar la complejidad de su entorno multiplataforma. La experiencia de Avahi en proyectos de AWS MAP (Migration Acceleration Program) aportó la metodología estructurada necesaria para evaluar, planificar y ejecutar una migración de esta escala. La capacidad de Avahi para realizar análisis a nivel de código de la arquitectura existente, comparar modelos candidatos contra cargas de trabajo de producción y entregar proyecciones de costos accionables le dio a Lovelace la confianza para avanzar con una migración que impactaba cada capa de su stack tecnológico.
Avahi realizó una evaluación integral que abarcó cargas de trabajo de IA/ML, componentes de infraestructura y servicios de la capa de datos en todos los proyectos de GCP de Lovelace.
Análisis de arquitectura de IA/ML
La evaluación comenzó con un inventario detallado de cada modelo, proveedor de embeddings y servicio de IA en ambas plataformas. Los ingenieros de Avahi realizaron una validación a nivel de código para mapear cada componente a sus dependencias reales de modelos, corrigiendo varias suposiciones de rondas de descubrimiento anteriores. Un hallazgo clave fue que el framework de agentes de Lovelace (construido sobre Google ADK) era agnóstico al modelo por diseño: ADK incluye un adaptador LiteLLM que permite que cada agente basado en Python acceda a AWS Bedrock con un cambio de configuración de una sola línea, eliminando la necesidad de reescribir agentes.
Para los servicios basados en Go que consumían la mayor parte del volumen de tokens (Resolve Matcher, Resolve Searcher, Agents Serve y Fetch Pipeline), Avahi diseñó una implementación nativa de cliente de Bedrock siguiendo el patrón de proveedor existente en la base de código. Este enfoque mantuvo la capa de abstracción existente, a la vez que agregó Bedrock como una nueva opción de backend.
Benchmarking y selección de modelos
Avahi desarrolló un framework de benchmarking diseñado específicamente para evaluar modelos candidatos en las dos tareas de PLN más críticas para la plataforma de Lovelace: extracción de entidades y resolución de entidades. El framework capturó métricas de calidad (precisión, recall, F1), métricas de rendimiento (percentiles de latencia, tiempo hasta el primer token, solicitudes por segundo) y el costo por millón de tokens para cada candidato.
El benchmarking reveló que Amazon Nova 2.0 Lite, si bien igualaba la calidad de Gemini en algunas cargas de trabajo, más que duplicaría los costos totales de IA/ML en tres años debido a diferencias de precios en componentes de alto volumen. Los modelos open source autogestionados (Gemma 4 31B y gpt-oss-120b) surgieron como la única vía que reducía costos frente a la línea base actual de GCP, con ahorros proyectados a tres años de aproximadamente US$240,000.
Evaluación de infraestructura
La evaluación de infraestructura confirmó que la arquitectura de Lovelace de “todo es Kubernetes” ya era, en gran medida, agnóstica a la nube. Se encontraron cero servicios de Cloud Run, cero VMs de GCE y cero servicios de Dataflow en cualquiera de las plataformas. Las bases de datos se ejecutaban como despliegues autogestionados dentro del clúster, en lugar de servicios administrados de GCP, lo que significaba que podían migrar con la misma configuración de despliegue a EKS.
La superficie real de dependencia de GCP se redujo a: Vertex AI (cubierto por la evaluación de IA/ML), GCS (migración directa a S3), Cloud SQL PostgreSQL (replatform a Aurora), Bigtable (replatform a ElastiCache, ya que el análisis de código confirmó que solo funcionaba como caché L2) y BigQuery (replatform a Redshift o Athena, pendiente del análisis de patrones de consulta).
Recomendaciones para la capa de datos
Avahi recomendó Aurora PostgreSQL en lugar de RDS para la capa de datos relacional, ya que Aurora Global Database era necesaria para la estrategia de DR entre regiones. Para el almacén de datos autogestionado de alto rendimiento, Avahi diseñó un despliegue autogestionado en EKS usando pools de nodos dedicados y con taints, con instancias de NVMe local (i3en o i4i), evitando la lógica de consolidación de Karpenter que podría terminar nodos y perder datos. Se confirmó que el almacén vectorial migraría sin cambios de código usando la misma configuración de despliegue en EKS.
Plan de migración por oleadas
Avahi desarrolló un plan de migración de cuatro oleadas con compuertas técnicas específicas y criterios de estabilidad para cada transición entre oleadas. El plan estimó que el cronograma total de migración es de aproximadamente 14 a 22 semanas mediante aprovisionamiento de infraestructura en paralelo y cambios de inquilinos en paralelo en la Oleada 4. Cada transición entre oleadas requirió ventanas de estabilidad de 72 horas (disponibilidad superior al 99.5%, sin incidentes), y la Oleada 2 además requirió sincronización de GCS a S3 sin egreso durante siete días consecutivos.
Modelado de costos
La evaluación entregó dos bases de dimensionamiento de cómputo: una estimación de techo (US$126,637 al mes) dimensionada según los máximos del autoscaler de GCP para proteger el caso de financiamiento, y un piso de uso activo (US$38,496 al mes) basado en conteos de nodos de GCP en vivo. El conteo activo de 65 nodos coincidió de forma independiente con una cifra de descubrimiento separada de LucidScale de meses atrás, validando la metodología. Se proyectaron costos totales de infraestructura del Año 1 de US$1,890,090 a máxima utilización.
Informe completo de evaluación de IA/ML que cubre inventario de modelos, estrategias de migración y estimaciones de esfuerzo para todos los componentes en ambas plataformas
Informe de evaluación de infraestructura con arquitectura objetivo, matriz de componentes y recomendaciones para la capa de datos
Framework de benchmarking de modelos y resultados para tareas de extracción y resolución de entidades en modelos candidatos
Proyección de costos de IA/ML a tres años comparando Nova 2.0 Lite, modelos open source autogestionados y la línea base actual de GCP
Plan de migración de cuatro oleadas con compuertas técnicas, criterios de estabilidad y procedimientos de reversión
Análisis de dimensionamiento de cuotas de Bedrock con solicitudes específicas de aumento de cuota requeridas antes del cambio a producción
Especificación de despliegue del almacén de datos autogestionado, incluidos tipos de instancia, cantidad de nodos y configuración de taints/affinity
Matriz de costos de la estrategia de DR con objetivos de RTO/RPO y deltas de costo mensual para cada opción
La evaluación proporcionó a Lovelace un plan maestro de migración completo y validado que redujo el riesgo de su transición de GCP a AWS. El análisis a nivel de código corrigió múltiples suposiciones de rondas de descubrimiento anteriores, incluida la constatación de que el modelo cross-encoder de primera pasada (previamente estimado en 48 GB de VRAM) en realidad se ejecuta en CPU en producción, eliminando un posible requisito de infraestructura de GPU.
El enfoque de aprovisionamiento en paralelo del plan por oleadas redujo el cronograma de migración proyectado en 12 a 16 semanas en comparación con un enfoque secuencial, minimizando el período de costos de doble nube y la complejidad operativa.
Costo de IA/ML proyectado a tres años con modelos open source autogestionados: US$1,367,747 (reducción del 14.9% vs. la línea base de GCP de US$1,607,781)
Costo de IA/ML proyectado a tres años con Nova 2.0 Lite: US$3,255,506 (aumento del 102.5% vs. la línea base de GCP)
Cronograma de migración con aprovisionamiento en paralelo: 14 a 22 semanas (vs. 26 a 38 semanas en secuencia)
Utilización activa de cómputo: 65 nodos (33% del techo del autoscaler de 197 nodos)
Capacidad del almacén vectorial: aproximadamente 200 millones de vectores en 12 shards con factor de replicación de 2
Requisitos máximos de QPS validados: 2,000 QPS para búsqueda de embeddings, 500 QPS para inferencia de agentes
Lovelace
Pittsburgh, Pensilvania
Servicios financieros / Inteligencia de datos
Amazon EKS, Amazon Aurora PostgreSQL, Amazon S3, AWS Bedrock, Amazon SageMaker, Amazon ElastiCache, Amazon Redshift, AWS WAF, AWS Secrets Manager, AWS KMS, Observabilidad autogestionada (Grafana, Mimir, Loki, Tempo)
Lovelace, una empresa de inteligencia de datos que opera plataformas impulsadas por IA para servicios financieros y clientes empresariales multiinquilino, contrató a Avahi para realizar una evaluación integral para migrar toda su infraestructura y cargas de trabajo de IA/ML de Google Cloud Platform a AWS. La evaluación reveló que la arquitectura nativa de Kubernetes de Lovelace ya era, en gran medida, agnóstica a la nube, y que la complejidad real de la migración se concentraba en la capa de IA/ML (modelos de Vertex AI, inferencia ajustada y pipelines de embeddings) y en la capa de datos (Cloud SQL, Bigtable y BigQuery). Avahi entregó un plan maestro de migración completo que abarca la arquitectura objetivo, el benchmarking de modelos, las proyecciones de costos y un plan por oleadas y fases que reduce el cronograma de migración, estimado en aproximadamente 14 a 22 semanas, mediante aprovisionamiento en paralelo.
Lovelace opera dos plataformas principales: una plataforma de inteligencia de datos que procesa noticias y datos financieros a través de 35 feeds externos, y una plataforma multiinquilino que atiende a clientes empresariales. Su plataforma se ejecuta sobre bases de datos autogestionadas dentro del clúster, con una fuerte dependencia de Google Vertex AI para la inferencia de LLM, embeddings y modelos ajustados. Las plataformas soportan cargas de trabajo de alto rendimiento, y algunos componentes requieren hasta 2,000 consultas por segundo para operaciones de resolución de entidades y búsqueda de embeddings.
Lovelace necesitaba migrar toda su infraestructura en la nube de GCP a AWS, pero la complejidad de sus cargas de trabajo de IA/ML generaba una incertidumbre significativa en torno a los costos, el cronograma y la viabilidad técnica. Sus plataformas dependían de Vertex AI para múltiples tipos de modelos (variantes de Gemini para la orquestación de agentes, text-embedding-005 para búsqueda vectorial y modelos personalizados ajustados para la resolución de entidades), y la ruta de migración para cada uno no estaba clara.
Los modelos ajustados presentaban desafíos particulares: eran críticos para el pipeline de resolución de entidades, pero no tenían un equivalente directo en AWS, lo que requería evaluar Amazon Nova, SageMaker y opciones autogestionadas. Sin una comprensión clara de la ruta de migración, Lovelace enfrentaba el riesgo de costos extendidos de doble nube, posibles interrupciones del servicio durante el cambio a producción y la posibilidad de descubrir problemas técnicos bloqueantes a mitad de la migración.
Además, se desconocían las implicaciones de costos de cambiar de proveedor de IA/ML. Las suposiciones iniciales sugerían que migrar a AWS Bedrock sería sencillo, pero sin un análisis detallado de los volúmenes de tokens, los requisitos de QPS y las diferencias de precios entre modelos, Lovelace no podía tomar decisiones informadas sobre su arquitectura objetivo.
Lovelace eligió AWS como su plataforma de nube objetivo porque quiere integrarse al ecosistema de AWS Marketplace. Además, puede aprovechar la amplitud de servicios de IA/ML de AWS. AWS Bedrock ofrecía acceso a múltiples modelos fundacionales mediante una API unificada, mientras que Amazon SageMaker proporcionaba una vía administrada para sus necesidades de entrenamiento e inferencia de modelos ajustados. La combinación de Amazon EKS para sus cargas de trabajo de Kubernetes, Aurora PostgreSQL para su capa de datos relacional y el stack de IA/ML de AWS creó una arquitectura objetivo cohesiva que podía respaldar su crecimiento y, al mismo tiempo, reducir la complejidad operativa.
Lovelace requería un socio con profunda experiencia tanto en sistemas de IA/ML como en migración a la nube para gestionar la complejidad de su entorno multiplataforma. La experiencia de Avahi en proyectos de AWS MAP (Migration Acceleration Program) aportó la metodología estructurada necesaria para evaluar, planificar y ejecutar una migración de esta escala. La capacidad de Avahi para realizar análisis a nivel de código de la arquitectura existente, comparar modelos candidatos contra cargas de trabajo de producción y entregar proyecciones de costos accionables le dio a Lovelace la confianza para avanzar con una migración que impactaba cada capa de su stack tecnológico.
Avahi realizó una evaluación integral que abarcó cargas de trabajo de IA/ML, componentes de infraestructura y servicios de la capa de datos en todos los proyectos de GCP de Lovelace.
Análisis de arquitectura de IA/ML
La evaluación comenzó con un inventario detallado de cada modelo, proveedor de embeddings y servicio de IA en ambas plataformas. Los ingenieros de Avahi realizaron una validación a nivel de código para mapear cada componente a sus dependencias reales de modelos, corrigiendo varias suposiciones de rondas de descubrimiento anteriores. Un hallazgo clave fue que el framework de agentes de Lovelace (construido sobre Google ADK) era agnóstico al modelo por diseño: ADK incluye un adaptador LiteLLM que permite que cada agente basado en Python acceda a AWS Bedrock con un cambio de configuración de una sola línea, eliminando la necesidad de reescribir agentes.
Para los servicios basados en Go que consumían la mayor parte del volumen de tokens (Resolve Matcher, Resolve Searcher, Agents Serve y Fetch Pipeline), Avahi diseñó una implementación nativa de cliente de Bedrock siguiendo el patrón de proveedor existente en la base de código. Este enfoque mantuvo la capa de abstracción existente, a la vez que agregó Bedrock como una nueva opción de backend.
Benchmarking y selección de modelos
Avahi desarrolló un framework de benchmarking diseñado específicamente para evaluar modelos candidatos en las dos tareas de PLN más críticas para la plataforma de Lovelace: extracción de entidades y resolución de entidades. El framework capturó métricas de calidad (precisión, recall, F1), métricas de rendimiento (percentiles de latencia, tiempo hasta el primer token, solicitudes por segundo) y el costo por millón de tokens para cada candidato.
El benchmarking reveló que Amazon Nova 2.0 Lite, si bien igualaba la calidad de Gemini en algunas cargas de trabajo, más que duplicaría los costos totales de IA/ML en tres años debido a diferencias de precios en componentes de alto volumen. Los modelos open source autogestionados (Gemma 4 31B y gpt-oss-120b) surgieron como la única vía que reducía costos frente a la línea base actual de GCP, con ahorros proyectados a tres años de aproximadamente US$240,000.
Evaluación de infraestructura
La evaluación de infraestructura confirmó que la arquitectura de Lovelace de “todo es Kubernetes” ya era, en gran medida, agnóstica a la nube. Se encontraron cero servicios de Cloud Run, cero VMs de GCE y cero servicios de Dataflow en cualquiera de las plataformas. Las bases de datos se ejecutaban como despliegues autogestionados dentro del clúster, en lugar de servicios administrados de GCP, lo que significaba que podían migrar con la misma configuración de despliegue a EKS.
La superficie real de dependencia de GCP se redujo a: Vertex AI (cubierto por la evaluación de IA/ML), GCS (migración directa a S3), Cloud SQL PostgreSQL (replatform a Aurora), Bigtable (replatform a ElastiCache, ya que el análisis de código confirmó que solo funcionaba como caché L2) y BigQuery (replatform a Redshift o Athena, pendiente del análisis de patrones de consulta).
Recomendaciones para la capa de datos
Avahi recomendó Aurora PostgreSQL en lugar de RDS para la capa de datos relacional, ya que Aurora Global Database era necesaria para la estrategia de DR entre regiones. Para el almacén de datos autogestionado de alto rendimiento, Avahi diseñó un despliegue autogestionado en EKS usando pools de nodos dedicados y con taints, con instancias de NVMe local (i3en o i4i), evitando la lógica de consolidación de Karpenter que podría terminar nodos y perder datos. Se confirmó que el almacén vectorial migraría sin cambios de código usando la misma configuración de despliegue en EKS.
Plan de migración por oleadas
Avahi desarrolló un plan de migración de cuatro oleadas con compuertas técnicas específicas y criterios de estabilidad para cada transición entre oleadas. El plan estimó que el cronograma total de migración es de aproximadamente 14 a 22 semanas mediante aprovisionamiento de infraestructura en paralelo y cambios de inquilinos en paralelo en la Oleada 4. Cada transición entre oleadas requirió ventanas de estabilidad de 72 horas (disponibilidad superior al 99.5%, sin incidentes), y la Oleada 2 además requirió sincronización de GCS a S3 sin egreso durante siete días consecutivos.
Modelado de costos
La evaluación entregó dos bases de dimensionamiento de cómputo: una estimación de techo (US$126,637 al mes) dimensionada según los máximos del autoscaler de GCP para proteger el caso de financiamiento, y un piso de uso activo (US$38,496 al mes) basado en conteos de nodos de GCP en vivo. El conteo activo de 65 nodos coincidió de forma independiente con una cifra de descubrimiento separada de LucidScale de meses atrás, validando la metodología. Se proyectaron costos totales de infraestructura del Año 1 de US$1,890,090 a máxima utilización.
Informe completo de evaluación de IA/ML que cubre inventario de modelos, estrategias de migración y estimaciones de esfuerzo para todos los componentes en ambas plataformas
Informe de evaluación de infraestructura con arquitectura objetivo, matriz de componentes y recomendaciones para la capa de datos
Framework de benchmarking de modelos y resultados para tareas de extracción y resolución de entidades en modelos candidatos
Proyección de costos de IA/ML a tres años comparando Nova 2.0 Lite, modelos open source autogestionados y la línea base actual de GCP
Plan de migración de cuatro oleadas con compuertas técnicas, criterios de estabilidad y procedimientos de reversión
Análisis de dimensionamiento de cuotas de Bedrock con solicitudes específicas de aumento de cuota requeridas antes del cambio a producción
Especificación de despliegue del almacén de datos autogestionado, incluidos tipos de instancia, cantidad de nodos y configuración de taints/affinity
Matriz de costos de la estrategia de DR con objetivos de RTO/RPO y deltas de costo mensual para cada opción
La evaluación proporcionó a Lovelace un plan maestro de migración completo y validado que redujo el riesgo de su transición de GCP a AWS. El análisis a nivel de código corrigió múltiples suposiciones de rondas de descubrimiento anteriores, incluida la constatación de que el modelo cross-encoder de primera pasada (previamente estimado en 48 GB de VRAM) en realidad se ejecuta en CPU en producción, eliminando un posible requisito de infraestructura de GPU.
El enfoque de aprovisionamiento en paralelo del plan por oleadas redujo el cronograma de migración proyectado en 12 a 16 semanas en comparación con un enfoque secuencial, minimizando el período de costos de doble nube y la complejidad operativa.
Costo de IA/ML proyectado a tres años con modelos open source autogestionados: US$1,367,747 (reducción del 14.9% vs. la línea base de GCP de US$1,607,781)
Costo de IA/ML proyectado a tres años con Nova 2.0 Lite: US$3,255,506 (aumento del 102.5% vs. la línea base de GCP)
Cronograma de migración con aprovisionamiento en paralelo: 14 a 22 semanas (vs. 26 a 38 semanas en secuencia)
Utilización activa de cómputo: 65 nodos (33% del techo del autoscaler de 197 nodos)
Capacidad del almacén vectorial: aproximadamente 200 millones de vectores en 12 shards con factor de replicación de 2
Requisitos máximos de QPS validados: 2,000 QPS para búsqueda de embeddings, 500 QPS para inferencia de agentes
Exploremos juntos sus oportunidades de IA de alto impacto en una sesión gratuita
