Cómo Tomofun bajó costos de inferencia de modelos vision-language con Inferentia2

Introducción

Tomofun, la startup con sede en Taiwán detrás de la cámara para mascotas Furbo, utiliza modelos de visión e integración lenguaje-imagen para detectar comportamientos como ladrido, carrera o actividad inusual y alertar a los dueños en tiempo real. Originalmente sus inferencias corrían sobre instancias GPU de Amazon EC2; eso ofrecía alto rendimiento, pero resultaba costoso cuando el servicio debe estar siempre activo para cientos de miles de cámaras.

El caso de Tomofun es útil para equipos en América Latina que enfrentan presiones similares: ofrecer detección en tiempo real con modelos complejos sin multiplicar costos operativos. En respuesta, Tomofun adoptó EC2 Inf2 —instancias impulsadas por los chips personalizados AWS Inferentia2— para ejecutar modelos vision-language como BLIP (Bootstrapping Language-Image Pre-Training) conservando precisión y flexibilidad.

El desafío: inferencia continua a escala sin romper el presupuesto

Ejecutar modelos avanzados tipo BLIP en GPUs funcionó, pero no era eficiente para un servicio siempre activo. El reto fue doble: sostener una vigilancia casi continua sobre cientos de miles de dispositivos y, al mismo tiempo, mantener la fidelidad y el throughput del modelo. Además, Tomofun no quería reescribir extensamente el código BLIP que ya estaba optimizado en PyTorch.

La necesidad era clara: reducir el costo por inferencia sin sacrificar latencia ni cambiar la experiencia del usuario final ni la lógica de alertas existente.

Arquitectura de alto nivel en AWS

Tomofun diseñó una arquitectura que permite direccionar solicitudes de inferencia a backends basados en GPU o en Inferentia2 sin modificar la API pública de Furbo. Los componentes clave son:

• Furbo API: orquesta los flujos de imagen desde las cámaras de los clientes hacia los endpoints de inferencia.
• Amazon CloudFront y Elastic Load Balancing (ELB): enrutan y balancean las solicitudes de imágenes.
• EC2 Auto Scaling: dos capas de grupos autoescalables; la primera ejecuta la API y preprocesa imágenes, la segunda está dedicada a la inferencia del modelo.
• Inf2 (EC2 Inf2) y GPU EC2: contenedores con BLIP pueden desplegarse en ambas familias de instancias; la API puede dirigir tráfico a uno u otro backend en tiempo real.
• Amazon CloudWatch: colecta métricas de latencia, throughput y errores para alimentar decisiones de escalado.

Este enfoque permite alternar entre GPU e Inferentia2 según demanda y costo, mantener alta disponibilidad y conservar la misma superficie de API para usuarios y sistemas aguas abajo.

Cómo adaptaron BLIP para correr en Inferentia2

BLIP se compone de tres bloques principales: Image Encoder, Text Encoder y Text Decoder. Tomofun aplicó una estrategia modular para mantener la arquitectura original del modelo intacta y facilitar la compilación para Inferentia2.

Pasos principales que siguieron:

1. Modularizar los componentes: aislaron cada subcomponente de BLIP (encoder de imagen, encoder de texto y decoder) y envolvieron cada uno con wrappers ligeros que normalizan entradas y salidas. De este modo no fue necesario cambiar la lógica preentrenada del modelo.

2. Compilación independiente: cada componente fue compilado por separado usando el Neuron SDK (y herramientas como torch_neuronx) para generar artefactos optimizados para Inferentia2.

3. Cadena de inferencia secuencial: los módulos compilados fueron encadenados en el pipeline de inferencia, permitiendo que los tensores fluyan de un componente al siguiente sin alterar la semántica del modelo original.

4. Transparencia para la API: la API de Furbo ahora puede enrutar llamadas a contenedores que ejecutan ya sea los módulos GPU o los compilados para Inferentia2, sin cambios en el contrato de entrada/salida ni en la lógica de alertas.

Un ejemplo concreto en la implementación fue aislar el Text Encoder original dentro de una clase wrapper que estandariza la salida para facilitar su trazado y compilación con Neuron. Esa técnica permitió compilar el submódulo manteniendo la misma interfaz funcional.

Observabilidad y escalado

La observabilidad se maneja con Amazon CloudWatch, que monitorea latencia, throughput y tasas de error a lo largo del clúster de inferencia. Las métricas alimentan políticas de Auto Scaling para dimensionar la flota en función del volumen real de peticiones de imágenes.

Tomofun prefirió conducir el escalado por conteo de solicitudes porque ya habían medido el throughput de cada tipo de instancia mediante pruebas de carga. Con esas referencias, pueden traducir directamente el volumen de imágenes a la cantidad adecuada de instancias, optimizando costos sin sorpresas.

Beneficios observados y relevancia para LatAm

Al mover la inferencia a EC2 Inf2 con modelos compilados para Inferentia2, Tomofun pudo reducir costos operativos manteniendo la precisión y el rendimiento necesario para alertas en tiempo real. La capacidad de alternar entre GPU e Inferentia2 permitió una transición progresiva y mayor resiliencia operativa.

Para empresas y equipos en América Latina que buscan desplegar modelos vision-language en producción, este caso ofrece lecciones aplicables:

• Considere hardware especializado (como Inferentia2) para cargas de inferencia continuas: puede reducir costo por inferencia frente a GPUs generales cuando la aplicación requiere operación 24/7.
• Mantenga la compatibilidad de la API: encapsular y modularizar el modelo facilita la migración sin reescribir toda la lógica de aplicación.
• Invierta en observabilidad y pruebas de throughput: conocer el rendimiento por instancia permite escalar de manera coste-eficiente.

Conclusión

El trabajo de Tomofun ilustra cómo combinar diseño de arquitectura, compilación modular con el Neuron SDK y aprovechamiento de hardware especializado puede convertir una carga de inferencia costosa en una operación escalable y más económica sin sacrificar la calidad del servicio. Para equipos en la región que enfrentan restricciones presupuestarias y demandas de baja latencia, la aproximación modular y basada en métricas para migrar cargas hacia Inferentia2 ofrece un camino factible y probado.

Si su organización opera modelos vision-language en producción, evaluar alternativas de hardware e invertir en modularidad y observabilidad son pasos prácticos que ayudan a controlar costos y mantener la eficacia del servicio.