Construyendo el futuro de la construcción Analytics: Inferencia AI de Conxai en Amazon EKS

Esta es una publicación invitada coescrita con Tim Krause, Arquitecto Mlops principal en Conxai.

Conxai Technology GmbH está pionero en el desarrollo de una plataforma AI avanzada para la industria de la arquitectura, la ingeniería y la construcción (AEC). Nuestra plataforma utiliza AI avanzada para empoderar a los expertos en dominios de construcción para crear casos de uso complejos de manera eficiente.

Los sitios de construcción generalmente emplean múltiples cámaras de CCTV, generando grandes cantidades de datos visuales. Estos alimentos para la cámara se pueden analizar utilizando AI para extraer información valiosa. Sin embargo, para cumplir con las regulaciones de GDPR, todas las personas capturadas en el metraje deben ser anonimizadas enmascarando o difuminando sus identidades.

En esta publicación, profundizamos en cómo Conxai alberga el modelo de segmentación one-formador de última generación en AWS usando Servicio de almacenamiento simple de Amazon (Amazon S3), Servicio de Kubernetes de Amazon Elastic (Amazon EKS), Kserve y Nvidia Triton.

Nuestra solución de IA se ofrece en dos formularios:

• Modelo como servicio (Maas) – Nuestro modelo AI es accesible a través de una API, que permite una integración perfecta. El precio se basa en el procesamiento de lotes de 1,000 imágenes, ofreciendo flexibilidad y escalabilidad para los usuarios.
• Software como servicio (SaaS) -Esta opción proporciona un tablero fácil de usar, que actúa como un panel de control central. Los usuarios pueden agregar y administrar nuevas cámaras, ver imágenes, realizar búsquedas analíticas y hacer cumplir el cumplimiento de GDPR con el anonimización de la persona automática.

Nuestro modelo de IA, ajustado con un conjunto de datos patentado de más de 50,000 imágenes autodabeladas de sitios de construcción, logra una precisión significativamente mayor en comparación con otras soluciones MAAS. Con la capacidad de reconocer más de 40 clases de objetos especializados, como grúas, excavadoras y baños portátiles, nuestra solución de IA está diseñada y optimizada de forma única para la industria de la construcción.

Nuestro viaje a AWS

Inicialmente, Conxai comenzó con un pequeño proveedor de nubes especializado en ofrecer GPU asequibles. Sin embargo, carecía de servicios esenciales necesarios para aplicaciones de aprendizaje automático (ML), como infraestructura de frontend y backend, DNS, equilibradores de carga, escala, almacenamiento de blob y bases de datos administradas. En ese momento, la aplicación se implementó como un solo contenedor monolítico, que incluía Kafka y una base de datos. Esta configuración no era escalable ni mantenible.

Después de migrar a AWS, obtuvimos acceso a un ecosistema robusto de servicios. Inicialmente, desplegamos el contenedor de IA todo en uno en un solo Nube de cómputo elástica de Amazon (Amazon EC2) instancia. Aunque esto proporcionó una solución básica, no era escalable, lo que requería el desarrollo de una nueva arquitectura.

Nuestras principales razones para elegir AWS fueron impulsadas principalmente por la amplia experiencia del equipo con AWS. Además, los créditos de nube iniciales proporcionados por AWS fueron invaluables para nosotros como startup. Ahora utilizamos servicios administrados de AWS siempre que sea posible, particularmente para tareas relacionadas con los datos, para minimizar los gastos generales de mantenimiento y pagar solo los recursos que realmente utilizamos.

Al mismo tiempo, nuestro objetivo era seguir siendo agnóstico en la nube. Para lograr esto, elegimos Kubernetes, permitiéndonos implementar nuestra pila directamente en el borde de un cliente, como en los sitios de construcción, cuando se necesita. Algunos clientes son potencialmente muy restrictivos de cumplimiento, no permiten que los datos salgan del sitio de construcción. Otra oportunidad es el aprendizaje federado, la capacitación en la ventaja del cliente y solo transfiere pesos del modelo, sin datos confidenciales, a la nube. En el futuro, este enfoque podría llevar a tener un modelo ajustado para cada cámara para lograr la mejor precisión, lo que requiere recursos de hardware en el sitio. Por el momento, usamos Amazon EK para descargar la sobrecarga de administración a AWS, pero podríamos implementar fácilmente en un clúster de Kubernetes estándar si es necesario.

Nuestro modelo anterior se estaba ejecutando en Torchserve. Con nuestro nuevo modelo, primero intentamos realizar una inferencia en Python con Flask y Pytorch, así como con Bentoml. Lograr un alto rendimiento de inferencia con una alta utilización de GPU para la rentabilidad fue muy desafiante. Exportar el modelo a formato ONNX fue particularmente difícil porque el modelo OneFormer carece de un fuerte apoyo comunitario. Nos llevó algún tiempo identificar por qué el modelo OneFormer era tan lento en el tiempo de ejecución de ONNX con Nvidia Triton. En última instancia, resolvimos el problema al convertir ONNX en Tensorrt.

Definir la arquitectura final, la capacitación del modelo y la optimización de los costos tomaron aproximadamente 2 a 3 meses. Actualmente, mejoramos nuestro modelo incorporando datos etiquetados cada vez más precisos, un proceso que toma alrededor de 3 a 4 semanas de capacitación en una sola GPU. La implementación está completamente automatizada con tuberías GitLab CI/CD, Terraform y Helm, que requiere menos de una hora para completar sin ningún tiempo de inactividad. Las nuevas versiones del modelo generalmente se implementan en modo sombra durante 1 a 2 semanas para proporcionar estabilidad y precisión antes de la implementación completa.

Descripción general de la solución

El siguiente diagrama ilustra la arquitectura de la solución.

La arquitectura consta de los siguientes componentes clave:

• El cubo S3 (1) es la fuente de datos más importante. Es rentable, escalable y proporciona almacenamiento de blob casi ilimitado. En cifrar el cubo S3, y eliminamos todos los datos con preocupaciones de privacidad después de que se realizó el procesamiento. Casi todos los microservicios leen y escriben archivos desde y a Amazon S3, que finalmente desencadena (2) Amazon Eventbridge (3). El proceso comienza cuando un cliente carga una imagen en Amazon S3 utilizando una URL presignada proporcionada por nuestra API Maneing Autenticación y autorización del usuario a través de Amazon Cognito.
• El cubo S3 está configurado de tal manera que reenvía (2) todos los eventos en EventBridge.
• Triggermesh es un controlador Kubernetes donde usamos AWSEventBridgeSource (6). Abraza la automatización de la infraestructura y crea automáticamente un Servicio de cola simple de Amazon (Amazon SQS) (5) cola de procesamiento, que actúa como un búfer de procesamiento. Además, crea una regla de eventbridge (4) para reenviar el evento S3 desde el bus de eventos en la cola de procesamiento de SQS. Finalmente, Triggermesh crea una cápsula de Kubernetes para sondear eventos de la cola de procesamiento para alimentarlo al Broker Knative (7). Los recursos en el clúster Kubernetes se implementan en una subred privada.
• El lugar central para Knative Eventing es el Broker Knative (7). Está respaldado por Transmisión administrada de Amazon para Apache Kafka (Amazon MSK) (8).
• El gatillo de knative (9) encuesta al corredor de knative basado en un CloudEventType y lo reenvía en consecuencia al kserve InferenceService (10).
• Kserve es una plataforma de inferencia de modelo estándar en Kubernetes que utiliza Knative Serving como base y es totalmente compatible con Knative Eventing. También extrae modelos de un repositorio de modelos en el contenedor antes de que comience el servidor de modelos, eliminando la necesidad de construir una nueva imagen de contenedor para cada versión del modelo.
• Utilizamos la característica de “transformador y predictor de Kserve en el mismo POD” para maximizar la velocidad y el rendimiento de inferencia porque los contenedores dentro del mismo POD pueden comunicarse sobre elhost local y el tráfico de la red nunca deja la CPU.
• Después de muchas pruebas de rendimiento, logramos el mejor rendimiento con el servidor de inferencia NVIDIA Triton (11) después de convertir nuestro modelo primero en ONNX y luego en Tensorrt.
• Nuestro transformador (12) usa Flask con Gunicorn y está optimizado para el número de trabajadores y núcleos de CPU para mantener la utilización de GPU por encima del 90%. El transformador obtiene un CloudEvent Con la referencia de la imagen de Amazon S3, la descarga y realiza inferencia de modelo a través de HTTP. Después de recuperar los resultados del modelo, realiza el preprocesamiento y finalmente carga los resultados del modelo procesado a Amazon S3.
• Usamos Karpenter Como el clúster auto escalador. Karpenter es responsable de escalar el componente de inferencia para manejar las altas cargas de solicitud del usuario. Karpenter lanza nuevas instancias de EC2 cuando el sistema experimenta una mayor demanda. Esto permite que el sistema amplíe automáticamente los recursos informáticos para cumplir con la mayor carga de trabajo.

Todo esto divide nuestra arquitectura principalmente en el servicio de datos administrado de AWS y el clúster Kubernetes:

• S3 Bucket, EventBridge y SQS Queue, así como Amazon MSK, son servicios totalmente administrados en AWS. Esto mantiene bajo nuestro esfuerzo de gestión de datos.
• Usamos Amazon EK para todo lo demás. Triggermesh, AWSEventBridgeSourceKnative Broker, Knative Trigger, Kserve con nuestro transformador Python y el servidor de inferencia de Triton también están dentro del mismo clúster EKS en una instancia de EC2 dedicada con una GPU. Debido a que nuestro clúster EKS solo se usa para el procesamiento, es totalmente estatoso.

Resumen

Desde inicialmente tener nuestro propio modelo altamente personalizado, la transición a AWS, mejorar nuestra arquitectura e introducir nuestro nuevo modelo OneFormer, Conxai ahora está orgulloso de proporcionar una inferencia de ML escalable, confiable y segura a los clientes, permitiendo mejoras y aceleraciones de sitios de construcción. Logramos una utilización de GPU de más del 90%, y el número de errores de procesamiento ha caído casi a cero en los últimos meses. Una de las principales opciones de diseño fue la separación del modelo del código de preprocesamiento y posprocesamiento en el transformador. Con esta pila de tecnología, ganamos la capacidad de reducir a cero en Kubernetes utilizando la función Knative Server sin servidor, mientras que nuestro tiempo de escala de un estado frío es de solo 5-10 minutos, lo que puede ahorrar costos de infraestructura significativos para un posible uso de inferencia por lotes casos.

El siguiente paso importante es utilizar estos resultados del modelo con análisis adecuados y ciencia de datos. Estos resultados también pueden servir como fuente de datos para características generativas de IA, como la generación de informes automatizados. Además, queremos etiquetar imágenes más diversas y capacitar al modelo en clases adicionales de dominio de construcción como parte de un proceso de mejora continua. También trabajamos en estrecha colaboración con los especialistas en AWS para traer nuestro modelo a AWS Inferentia Chipsets para una mejor rentabilidad.

Para obtener más información sobre los servicios en esta solución, consulte los siguientes recursos:

Sobre los autores

Tim Krause es el arquitecto principal de MLOPS en Conxai. Se ocupa de todas las actividades cuando la IA se encuentra con la infraestructura. Se unió a la compañía con una plataforma anterior, Kubernetes, DevOps y Big Data Knowledge y estaba entrenando LLMS desde cero.

Mehdi yosofie es un arquitecto de soluciones en AWS, trabajando con clientes de inicio y aprovechando su experiencia para ayudar a los clientes de inicio a diseñar sus cargas de trabajo en AWS.