Una guía del arquitecto para crear una arquitectura de referencia para un lago de datos de IA/ML

Una versión abreviada de esta publicación apareció en The New Stack el 19 de marzo de 2024. En inteligencia artificial empresarial, existen dos tipos principales de modelos: discriminativos y generativos. Los modelos discriminativos se utilizan para clasificar o predecir datos, mientras que los modelos generativos se utilizan para crear nuevos datos. Aunque la IA generativa ha dominado las noticias últimamente, las organizaciones todavía buscan ambos tipos de IA. La IA discriminatoria sigue siendo una iniciativa importante para las organizaciones que desean operar de manera más eficiente y buscar fuentes de ingresos adicionales. Estos diferentes tipos de IA tienen mucho en común, pero al mismo tiempo, existen diferencias significativas que deben tenerse en cuenta al construir su infraestructura de datos de IA. Las organizaciones no deberían construir una infraestructura dedicada a la IA y a la IA únicamente mientras dejan que cargas de trabajo como Business Intelligence, Data Analytics y Data Science se las arreglen por sí mismas. Es posible construir una infraestructura de datos completa que respalde todas las necesidades de la organización: inteligencia empresarial, análisis de datos, ciencia de datos, IA discriminativa e IA generativa. En otra publicación, presentamos una arquitectura de referencia para un lago de datos moderno capaz de satisfacer las necesidades de inteligencia empresarial, análisis de datos, ciencia de datos e IA/ML. Repasemos la arquitectura de referencia moderna de Datalake y resaltemos las capacidades que tiene para admitir cargas de trabajo de IA/ML. El lago de datos moderno Comencemos por definir un Datalake moderno, ya que servirá como base para nuestra arquitectura de referencia. Esta arquitectura no es "reciclada", sino que refleja los primeros principios de ingeniería que son ampliamente aplicables. Un Datalake moderno es mitad almacén de datos y mitad lago de datos y utiliza almacenamiento de objetos para todo. Usar almacenamiento de objetos para un lago de datos tiene mucho sentido ya que el almacenamiento de objetos es para datos no estructurados, que es lo que debe almacenar un lago de datos. Sin embargo, usar almacenamiento de objetos para un almacén de datos puede parecer extraño, pero un almacén de datos construido de esta manera representa la próxima generación de almacenes de datos. Esto es posible gracias a las Especificaciones de formato de tabla abierta (OTF) creadas por Netflix, Uber y Databricks, que facilitan el empleo del almacenamiento de objetos dentro de un almacén de datos. Los OTF son Apache Iceberg, Apache Hudi y Delta Lake. Fueron escritos por Netflix, Uber y Databricks, respectivamente, porque no había productos en el mercado que pudieran satisfacer sus necesidades de datos. Básicamente, lo que todos hacen (de diferentes maneras) es definir un almacén de datos que se puede construir sobre el almacenamiento de objetos (MinIO). El almacenamiento de objetos proporciona una combinación de capacidad escalable y alto rendimiento que otras soluciones de almacenamiento no pueden ofrecer. Dado que se trata de especificaciones modernas, tienen características avanzadas que los almacenes de datos antiguos no tienen, como evolución de particiones, evolución de esquemas y ramificación sin copia. Finalmente, dado que el almacén de datos está construido con almacenamiento de objetos, puede usar este mismo almacén de objetos para datos no estructurados como imágenes, archivos de video, archivos de audio y documentos. Los datos no estructurados suelen almacenarse en lo que la industria llama lago de datos. El uso de un almacén de objetos como base tanto para su lago de datos como para su almacén de datos da como resultado una solución capaz de almacenar todos sus datos. El almacenamiento estructurado reside en el almacén de datos basado en OTF y el almacenamiento no estructurado reside en el lago de datos. Se podría utilizar la misma instancia de MinIO para ambos. En MinIO, llamamos a esta combinación de un almacén de datos basado en OTF y un lago de datos el lago de datos moderno, y lo vemos como la base para todas sus cargas de trabajo de IA/ML. Es donde se recopilan, almacenan, procesan y transforman los datos. Los modelos de entrenamiento que utilizan IA discriminativa (aprendizaje supervisado, no supervisado y reforzado) a menudo requieren una solución de almacenamiento que pueda manejar datos estructurados que puedan vivir en el almacén de datos. Por otro lado, si está entrenando modelos de lenguaje grande (LLM), debe administrar datos o documentos no estructurados en su forma sin procesar y procesada en el lago de datos. : Fuente Arquitectura de referencia moderna de Datalake Esta publicación se centra en aquellas áreas de la arquitectura de referencia moderna de Datalake para AI/ML que admiten las diferentes cargas de trabajo de AI/ML. Estas áreas funcionales se enumeran a continuación. Arriba se muestra una representación visual del Modern Datalake. Se han resaltado las capas en las que se pueden encontrar estas áreas funcionales. IA discriminativa Almacenamiento de datos no estructurados Almacenamiento de datos semiestructurados Ramificación de copia cero en el almacén de datos IA generativa Creación de un corpus personalizado con una base de datos vectorial Construyendo una canalización de documentos Recuperación de Generación Aumentada (RAG) Ajuste de modelos de lenguaje grandes Medición de la precisión del LLM Operaciones de aprendizaje automático Esta publicación también analiza el estado actual de las GPU y cómo afectan su infraestructura de datos de IA. También veremos un par de escenarios que ilustran cómo construir su infraestructura y cómo no construirla. Finalmente, esta publicación presenta algunas recomendaciones para construir su propia infraestructura de datos de IA. El estado actual de las GPU El problema de la GPU hambrienta Almacenamiento de objetos sobrealimentado Una historia de dos organizaciones Un plan para construir su infraestructura de datos de IA IA discriminativa Los modelos de IA discriminativos requieren datos de todo tipo para su entrenamiento. Los modelos de clasificación de imágenes y reconocimiento de voz utilizarán datos no estructurados en forma de imágenes y archivos de audio. Por otro lado, los modelos de detección de fraude y diagnóstico médico realizan predicciones basadas en datos estructurados. Veamos las opciones disponibles dentro de Modern Datalake para almacenar y manipular los datos que necesita la IA discriminativa. Almacenamiento de datos no estructurados Los datos no estructurados residirán en el lago de datos, donde se pueden utilizar para entrenar y probar modelos. Los conjuntos de entrenamiento que pueden caber en la memoria se pueden cargar antes del entrenamiento (antes de que comience el ciclo de época). Sin embargo, si su conjunto de entrenamiento es grande y no cabe en la memoria, tendrá que cargar una lista de objetos antes del entrenamiento y recuperar los objetos reales mientras procesa cada lote en su ciclo de época. Esto podría ejercer presión sobre su Data Lake si no lo construye utilizando una red de alta velocidad y unidades de disco de alta velocidad. Si está entrenando modelos con datos que no caben en la memoria, considere construir su Data Lake con una red de 100 GB y unidades NVMe. Almacenamiento de datos semiestructurados Hay algunas opciones disponibles dentro de Modern Datalake para almacenar archivos semiestructurados como archivos Parquet, archivos AVRO, archivos JSON e incluso archivos CSV. Lo más fácil es almacenarlos en su Data Lake y cargarlos de la misma manera que carga objetos no estructurados. Si los datos de estos archivos semiestructurados no son necesarios para otras cargas de trabajo compatibles con Modern Datalake (inteligencia empresarial, análisis de datos y ciencia de datos), entonces esta es la mejor opción. Otra opción es cargar estos archivos en su almacén de datos, donde otras cargas de trabajo pueden utilizarlos. Cuando los datos se cargan en su almacén de datos, puede utilizar con tus datos. Zero Copy Branching para realizar experimentos Ramificación de copia cero en el almacén de datos La ingeniería de características es una técnica para mejorar los conjuntos de datos utilizados para entrenar un modelo. Una característica muy ingeniosa que poseen los almacenes de datos basados en OTF es la ramificación sin copia. Esto permite que los datos se bifurquen de la misma manera que se bifurca el código dentro de un repositorio Git. Como sugiere el nombre, esta función no realiza una copia de los datos; más bien, utiliza la capa de metadatos del formato de tabla abierta utilizada para implementar el almacén de datos para crear la apariencia de una copia única de los datos. Los científicos de datos pueden experimentar con una rama; si sus experimentos tienen éxito, pueden fusionar su rama nuevamente con la rama principal para que la utilicen otros científicos de datos. Si el experimento no tiene éxito, se puede eliminar la rama. IA generativa Todos los modelos, ya sean modelos pequeños creados con Scikit-Learn, redes neuronales personalizadas creadas con PyTorch o TensorFlow, o modelos de lenguaje grandes basados en la arquitectura Transformer, requieren números como entradas y producen números como salidas. Este simple hecho impone algunos requisitos adicionales a su infraestructura de IA/ML si está interesado en la IA generativa, donde las palabras deben convertirse en números (o vectores, como veremos). Una solución de IA generativa se vuelve aún más complicada si desea utilizar documentos privados que contienen el conocimiento exclusivo de su empresa para mejorar las respuestas producidas por los LLM. Esta mejora podría adoptar la forma de generación aumentada de recuperación o ajuste fino de LLM. Esta sección analizará todas estas técnicas (convertir palabras en números, RAG y ajuste fino) y su impacto en la infraestructura de IA. Comencemos analizando cómo crear un corpus personalizado y dónde debería residir. Crear un corpus personalizado con una base de datos vectorial Si se toma en serio la IA generativa, entonces su corpus personalizado debería definir su organización. Debe contener documentos con conocimientos que nadie más tiene y sólo contener información verdadera y precisa. Además, su corpus personalizado debe construirse con una base de datos vectorial. Una base de datos vectorial indexa, almacena y proporciona acceso a sus documentos junto con sus incrustaciones vectoriales, que son las representaciones numéricas de sus documentos. (Esto resuelve el problema numérico descrito anteriormente). Las bases de datos vectoriales facilitan la búsqueda semántica. Cómo se hace esto requiere muchos conocimientos matemáticos y es complicado. Sin embargo, la búsqueda semántica es conceptualmente fácil de entender. Supongamos que desea encontrar todos los documentos que tratan cualquier tema relacionado con la "inteligencia artificial". Para hacer esto en una base de datos convencional, sería necesario buscar todas las abreviaturas, sinónimos y términos relacionados posibles de "inteligencia artificial". Su consulta se vería así: SELECT snippet FROM MyCorpusTable WHERE (text like '%artificial intelligence%' OR text like '%ai%' OR text like '%machine learning%' OR text like '%ml%' OR ... and on and on ... La búsqueda manual de similitudes no sólo es ardua y propensa a errores, sino que la búsqueda en sí es muy lenta. Una base de datos vectorial puede aceptar una solicitud como la siguiente y ejecutar la consulta más rápido y con mayor precisión. La capacidad de ejecutar consultas semánticas de forma rápida y precisa es importante si desea utilizar la generación aumentada de recuperación. { Get { MyCorpusTable(nearText: {concepts: ["artificial intelligence"]}) {snippet} } } Otra consideración importante para su corpus personalizado es la seguridad. El acceso a los documentos debe respetar las restricciones de acceso a los documentos originales. (Sería desafortunado que un pasante pudiera obtener acceso a los resultados financieros del director financiero que aún no se han publicado en Wall Street). Dentro de su base de datos vectorial, debe configurar la autorización para que coincida con los niveles de acceso del contenido original. Esto se puede hacer integrando su base de datos Vector con la solución de administración de acceso e identidad de su organización. En esencia, las bases de datos vectoriales almacenan datos no estructurados. Por lo tanto, deberían utilizar su Data Lake como solución de almacenamiento. Construyendo una canalización de documentos Desafortunadamente, la mayoría de las organizaciones no cuentan con un repositorio único con documentos limpios y precisos. Más bien, los documentos se distribuyen por toda la organización en varios portales de equipo en muchos formatos. En consecuencia, el primer paso para crear un corpus personalizado es crear un canal que tome solo documentos que hayan sido aprobados para su uso con IA generativa y colocarlos en su base de datos vectorial. Para las grandes organizaciones globales, esta podría ser la tarea más difícil de una solución de IA generativa. Es habitual que los equipos tengan documentación en formato borrador en sus portales. También puede haber documentos que sean reflexiones aleatorias sobre lo que podría ser. Estos documentos no deben formar parte de un corpus personalizado ya que no representan con precisión el negocio. Desafortunadamente, filtrar estos documentos será un esfuerzo manual. Una canalización de documentos también debería convertir los documentos a texto. Afortunadamente, algunas bibliotecas de código abierto pueden hacer esto para muchos de los formatos de documentos comunes. Además, una canalización de documentos debe dividir los documentos en pequeños segmentos antes de guardarlos en la base de datos vectorial. Esto se debe a las limitaciones en el tamaño de los mensajes cuando estos documentos se utilizan para la generación aumentada de recuperación, que se analizará en una sección posterior. Ajuste fino de modelos de lenguaje grandes Cuando ajustamos un modelo de lenguaje grande, lo entrenamos un poco más con información del corpus personalizado. Esta podría ser una buena manera de obtener un LLM específico de un dominio. Si bien esta opción requiere computación para realizar el ajuste fino en su corpus personalizado, no es tan intensiva como entrenar un modelo desde cero y se puede completar en un período de tiempo modesto. Si su dominio incluye términos que no se encuentran en el uso diario, realizar ajustes puede mejorar la calidad de las respuestas del LLM. Por ejemplo, los proyectos que utilizan documentos de investigación médica, investigación ambiental y cualquier cosa relacionada con las ciencias naturales pueden beneficiarse de un ajuste. El ajuste fino toma la lengua vernácula altamente específica que se encuentra en sus documentos y la integra en los parámetros paramétricos del modelo. Se deben comprender las ventajas y desventajas del ajuste antes de decidirse por este enfoque. Desventajas El ajuste fino requerirá recursos informáticos. La explicabilidad no es posible. Periódicamente necesitarás realizar ajustes con nuevos datos a medida que tu corpus evolucione. Las alucinaciones son una preocupación. La seguridad a nivel de documentos es imposible. Ventajas El LLM tiene conocimientos de su corpus personalizado mediante ajustes. El flujo de inferencia es menos complicado que RAG. Si bien el ajuste es una buena manera de enseñarle a un LLM sobre el lenguaje de su negocio, diluye los datos ya que la mayoría de los LLM contienen miles de millones de parámetros y sus datos se distribuirán entre todos estos parámetros. La mayor desventaja del ajuste es que la autorización a nivel de documento es imposible. Una vez que un documento se utiliza para el ajuste, su información pasa a formar parte del modelo. No es posible restringir esta información según los niveles de autorización del usuario. Veamos una técnica que combina sus datos personalizados y datos paramétricos en el momento de la inferencia. Recuperación de Generación Aumentada (RAG) La generación aumentada de recuperación (RAG) es una técnica que comienza con la pregunta que se formula: utiliza una base de datos vectorial para unir las preguntas con datos adicionales y luego pasa la pregunta y los datos a un LLM para la creación de contenido. Con RAG, no se necesita capacitación porque educamos al LLM enviándole fragmentos de texto relevantes de nuestro corpus de documentos de calidad. Funciona así mediante una tarea de respuesta a preguntas: un usuario hace una pregunta en la interfaz de usuario de su aplicación. Su aplicación tomará la pregunta (específicamente las palabras que contiene) y, utilizando una base de datos vectorial, buscará en su corpus de documentos de calidad fragmentos de texto que sean contextualmente relevantes. Estos fragmentos y la pregunta original se envían al LLM. Este paquete completo: pregunta más fragmentos (contexto) se conoce como mensaje. El LLM utilizará esta información para generar su respuesta. Esto puede parecer una tontería: si ya conoce la respuesta (los fragmentos), ¿por qué molestarse con el LLM? Recuerde, esto sucede en tiempo real y el objetivo es generar texto, algo que pueda copiar y pegar en su investigación. Necesita el LLM para crear el texto que incorpora la información de su corpus personalizado. Esto es más complicado que un ajuste fino. Sin embargo, la autorización del usuario se puede implementar ya que los documentos (o fragmentos de documentos) se seleccionan de la base de datos de vectores en el momento de la inferencia. La información de los documentos nunca pasa a formar parte de los parámetros paramétricos del modelo. Las ventajas y desventajas de RAG se enumeran a continuación. Desventajas El flujo de inferencia es más complicado. Ventajas El LLM tiene conocimiento directo de su corpus personalizado. La explicabilidad es posible. No es necesario ningún ajuste fino. Las alucinaciones se reducen significativamente y pueden controlarse examinando los resultados de las consultas de la base de datos de vectores. Se puede implementar la autorización. Operaciones de aprendizaje automático (MLOps) Para comprender mejor la importancia de MLOps, resulta útil comparar la creación de modelos con el desarrollo de aplicaciones convencionales. El desarrollo de aplicaciones convencionales, como la implementación de un nuevo microservicio que agrega una nueva característica a una aplicación, comienza con la revisión de una especificación. Cualquier estructura de datos nueva o cualquier cambio en las estructuras de datos existentes se diseña primero. El diseño de los datos no debería cambiar una vez que comienza la codificación. Luego se implementa el servicio y la codificación es la actividad principal de este proceso. También se codifican las pruebas unitarias y las pruebas de un extremo a otro. Estas pruebas demuestran que el código no es defectuoso e implementa correctamente la especificación. Pueden ejecutarse automáticamente mediante una canalización de CI/CD antes de implementar toda la aplicación. Crear un modelo y entrenarlo es diferente. El primer paso es comprender los datos sin procesar y la predicción necesaria. Los ingenieros de ML tienen que escribir algún código para implementar sus redes neuronales o configurar un algoritmo, pero la codificación no es la actividad dominante. La experimentación repetida es la actividad principal. Durante la experimentación, el diseño de los datos, el diseño del modelo y los parámetros utilizados cambiarán. Después de cada experimento, se crean métricas que muestran cómo se desempeñó el modelo mientras fue entrenado. También se generan métricas para el rendimiento del modelo frente a un conjunto de validación y un conjunto de prueba. Estas métricas se utilizan para demostrar la calidad del modelo. Una vez que un modelo está listo para incorporarse a una aplicación, es necesario empaquetarlo e implementarlo. MLOps, abreviatura de Machine Learning Operations, es un conjunto de prácticas y herramientas destinadas a abordar estas diferencias. El seguimiento de experimentos y la colaboración son las características más asociadas con los MLOP, pero las herramientas MLOP más modernas de la industria actual pueden hacer mucho más. Por ejemplo, pueden proporcionar un entorno de ejecución para sus experimentos y pueden empaquetar e implementar modelos una vez que estén listos para integrarse en una aplicación. A continuación se muestra un superconjunto de funciones que se encuentran en las herramientas MLOps actuales. Esta lista también incluye otras cosas a considerar, como soporte e integración de datos. : las técnicas y características de MLOps están en constante evolución. Quiere una herramienta que esté respaldada por un actor importante, lo que garantiza que la herramienta esté en constante desarrollo y mejora. Soporte de un jugador importante : los experimentos generan una gran cantidad de datos estructurados y no estructurados. Idealmente, esto podría almacenarse en el almacén de datos y el lago de datos. Sin embargo, muchas herramientas MLOps existían antes de los formatos de tabla abierta que dieron origen al Modern Datalake, por lo que la mayoría tendrá una solución separada para sus datos estructurados. Integración moderna de Datalake : realice un seguimiento de los conjuntos de datos, modelos, hiperparámetros y métricas de cada experimento. El seguimiento de los experimentos también debería facilitar la repetibilidad. Seguimiento de experimentos : permita a los miembros del equipo ver los resultados de todos los experimentos realizados por todos los ingenieros de ML. Facilite la colaboración : empaquete el modelo de manera que sea accesible desde otros entornos de programación. Empaquetado del modelo : implementación de modelos en los entornos formales de una organización. No necesitará esto si ha encontrado una manera de incorporar sus modelos a una canalización de CI/CD existente. Servicio de modelos : mantenga todas las versiones de todos los modelos. Registro de modelos : algunas herramientas proporcionan funciones que permiten anotar el código de tal manera que una función o modelo se pueda implementar como un servicio en contenedores para ejecutar experimentos en un clúster. Funciones sin servidor : algunas herramientas MLOps tienen como objetivo proporcionar capacidades completas de extremo a extremo y tienen características que le permiten crear canalizaciones para recuperar y almacenar sus datos sin procesar. No necesitará esto si ya tiene una canalización de datos. Capacidades de canalización de datos : la capacidad de orquestar sus funciones sin servidor en un gráfico acíclico dirigido. También permite la programación y ejecución de canales de capacitación. Capacidades de canalización de capacitación El impacto de las GPU en su infraestructura de datos de IA Una cadena es tan fuerte como su eslabón más débil, y su infraestructura de IA/ML es tan rápida como su componente más lento. Si entrena modelos de aprendizaje automático con GPU, entonces su eslabón débil puede ser su solución de almacenamiento. El resultado es lo que llamamos el "problema de la GPU hambrienta". El problema de la GPU hambrienta ocurre cuando su red o su solución de almacenamiento no pueden entregar datos de entrenamiento a su lógica de entrenamiento lo suficientemente rápido como para utilizar completamente sus GPU. Los síntomas son bastante obvios. Si monitorea sus GPU, notará que nunca llegan a estar cerca de ser utilizadas por completo. Si ha instrumentado su código de entrenamiento, notará que el tiempo total de entrenamiento está dominado por IO. Desafortunadamente, hay malas noticias para quienes luchan con este problema. Las GPU son cada vez más rápidas. Veamos el estado actual de las GPU y algunos avances que se están logrando con ellas para comprender cómo este problema solo empeorará en los próximos años. El estado actual de las GPU Las GPU son cada vez más rápidas. No sólo está mejorando el rendimiento bruto, sino que también aumentan la memoria y el ancho de banda. Echemos un vistazo a estas tres características de las GPU más recientes de Nvidia: , el y el . A100 H100 H200 GPU ACTUACIÓN MEMORIA ANCHO DE BANDA DE MEMORIA A100 624 TFLOPS 40GB 1.555 GB/s H100 1.979 TFLOPS 80GB 3,35 TB/s H200 1.979 TFLOPS 141GB 4,8 TB/s Nota: La tabla anterior utiliza las estadísticas que se alinean con una solución de socket PCIe (Peripheral Component Interconnect Express) para el A100 y la solución de socket SXM (Server PCI Express Module) para el H100 y el H200. Las estadísticas de SXM no existen para el A100. Con respecto al rendimiento, se utiliza la estadística de núcleo tensor de punto flotante 16 para la comparación. Vale la pena destacar algunas observaciones comparativas sobre las estadísticas anteriores. En primer lugar, el H100 y el H200 tienen el mismo rendimiento (1.979 TFLOPS), que es 3,17 veces mayor que el A100. El H100 tiene el doble de memoria que el A100 y el ancho de banda de la memoria aumentó en una cantidad similar - lo cual tiene sentido, de lo contrario, la GPU se moriría de hambre. El H200 puede manejar la friolera de 141 GB de memoria y su ancho de banda de memoria también aumentó proporcionalmente con respecto a las otras GPU. Veamos cada una de estas estadísticas con más detalle y analicemos lo que significa para el aprendizaje automático. : un teraflop (TFLOP) equivale a un billón (10^12) de operaciones de punto flotante por segundo. Es un 1 seguido de 12 ceros (1.000.000.000.000). Es difícil equiparar los TFLOP con la demanda de IO en gigabytes, ya que las operaciones de punto flotante que ocurren durante el entrenamiento del modelo involucran matemáticas tensoriales simples, así como primeras derivadas contra la función de pérdida (también conocida como gradientes). Sin embargo, son posibles comparaciones relativas. Si observamos las estadísticas anteriores, vemos que el H100 y el H200, que funcionan a 1979 TFLOPS, son tres veces más rápidos y potencialmente consumen datos 3 veces más rápido si todo lo demás puede seguir el ritmo. Rendimiento : también conocida como RAM de vídeo o RAM de gráficos. La memoria de la GPU está separada de la memoria principal del sistema (RAM) y está diseñada específicamente para manejar las tareas intensivas de procesamiento gráfico realizadas por la tarjeta gráfica. La memoria de la GPU determina el tamaño del lote al entrenar modelos. En el pasado, el tamaño del lote disminuía cuando la lógica de entrenamiento pasaba de una CPU a una GPU. Sin embargo, a medida que la memoria de la GPU alcance a la memoria de la CPU en términos de capacidad, el tamaño del lote utilizado para el entrenamiento de la GPU aumentará. Cuando el rendimiento y la capacidad de la memoria aumentan al mismo tiempo, el resultado son solicitudes más grandes en las que cada gigabyte de datos de entrenamiento se procesa más rápido. Memoria GPU : piense en el ancho de banda de la memoria de la GPU como la "autopista" que conecta la memoria y los núcleos de cálculo. Determina cuántos datos se pueden transferir por unidad de tiempo. Así como una carretera más ancha permite que pasen más automóviles en un período de tiempo determinado, un mayor ancho de banda de memoria permite mover más datos entre la memoria y la GPU. Como puedes ver, los diseñadores de estas GPU aumentaron el ancho de banda de la memoria para cada nueva versión de manera proporcional a la memoria; por lo tanto, el bus de datos interno del chip no será el cuello de botella. Ancho de banda de memoria Almacenamiento de objetos sobrecargado para entrenamiento de modelos Si tiene el problema de la GPU hambrienta, considere utilizar una red de 100 GB y unidades NVMe. A El uso de MinIO con dicha configuración logró 325 GiB/s en GET y 165 GiB/s en PUT con solo 32 nodos de SSD NVMe disponibles en el mercado. punto de referencia reciente A medida que el mundo de la informática ha ido evolucionando y Descubrimos que las configuraciones del servidor suelen venir con 500 GB o más de DRAM. Cuando se trata de implementaciones más grandes, incluso aquellas con unidades NVMe ultradensas, la cantidad de servidores, multiplicada por la DRAM en esos servidores, puede sumar rápidamente, a menudo hasta muchos TB por instancia. Ese grupo de DRAM se puede configurar como un grupo de memoria compartido distribuido y es ideal para cargas de trabajo que exigen IOPS y rendimiento masivos. Como resultado, creamos MinIO Cache para permitir a nuestros clientes Enterprise y Enterprise Lite configurar su infraestructura para aprovechar este grupo de memoria compartida para mejorar aún más el rendimiento de las cargas de trabajo principales de IA, como el entrenamiento de GPU, y al mismo tiempo conservar la persistencia total. El precio de la DRAM se ha desplomado. Una historia de dos organizaciones Como experimento mental final, contemos la historia de dos organizaciones que adoptan enfoques muy diferentes en su viaje AI/ML. La organización n.° 1 tiene una cultura de "mejoras iterativas". Creen que todas las grandes iniciativas pueden dividirse en proyectos más pequeños y manejables. Estos proyectos más pequeños luego se programan de tal manera que cada uno se basa en los resultados del proyecto anterior para resolver problemas cada vez más complejos. También les gustan estos pequeños proyectos organizados de tal manera que cada uno aporte valor al negocio. Han descubierto que los proyectos que tratan exclusivamente de mejorar la infraestructura o modernizar el software sin ninguna característica nueva para el negocio no son muy populares entre los ejecutivos que controlan los presupuestos. En consecuencia, han aprendido que solicitar dispositivos de almacenamiento y clústeres de cómputo sofisticados para una prueba de concepto de IA generativa no es la mejor manera de orquestar mejoras de infraestructura y nuevas capacidades de software. Más bien, comenzarán poco a poco con productos de infraestructura que puedan escalar a medida que crecen, y comenzarán con modelos simples de IA para que puedan implementar sus herramientas de MLOP y descubrir cómo trabajar con los equipos de DevOps y los canales de CI/CD existentes. La organización n.° 2 tiene una cultura de “objetos brillantes”. Cuando la idea más nueva ingresa a la industria, primero aborda el desafío de más alto perfil para demostrar su poder técnico. Han descubierto que estos proyectos son muy visibles tanto interna como externamente. Si algo se estropea, las personas inteligentes siempre pueden arreglarlo. La organización n.° 1 estructuró su primer proyecto construyendo una parte de su infraestructura de datos de inteligencia artificial mientras trabajaba en un modelo de recomendación para su sitio principal de comercio electrónico. El modelo de recomendación fue relativamente sencillo de entrenar. Es un modelo discriminativo que utiliza conjuntos de datos que ya existen en un archivo compartido. Sin embargo, al final de este proyecto, el equipo también había creado un lago de datos moderno pequeño (pero escalable), había implementado herramientas MLOP y había implementado algunas de las mejores prácticas para entrenar e implementar modelos. Aunque el modelo no es complicado, añadió muchas eficiencias a su sitio. Utilizaron estos resultados positivos para conseguir financiación para su próximo proyecto, que será una solución de IA generativa. La organización n.° 2 creó un chatbot para su sitio de comercio electrónico que respondía las preguntas de los clientes sobre los productos. Los modelos de lenguaje grande son bastante complicados (el equipo no estaba familiarizado con el ajuste fino o la generación aumentada de recuperación), por lo que todos los ciclos de ingeniería para este proyecto se centraron en avanzar rápidamente a través de una curva de aprendizaje pronunciada. Cuando el modelo estuvo completo, produjo buenos resultados, nada espectacular. Desafortunadamente, tuvo que cargarse manualmente en los entornos de preproducción y producción porque no había herramientas MLOps para implementarlo. Esto provocó una pequeña fricción con el equipo de DevOps. El modelo en sí también tuvo algunos problemas de estabilidad durante la producción. El clúster en el que se ejecutaba no tenía suficiente computación para una carga de trabajo de IA generativa. Hubo algunas llamadas de gravedad uno, lo que resultó en una mejora de emergencia en el clúster para que el LLM no fallara en condiciones de mucho tráfico. Después del proyecto, una retrospectiva determinó que necesitaban aumentar su infraestructura si querían tener éxito con la IA. Un plan para construir su infraestructura de datos de IA/ML La historia corta anterior es una narración simple de dos circunstancias extremas. La construcción de modelos de IA (tanto discriminativos como generativos) es significativamente diferente del desarrollo de software convencional. Esto debe tenerse en cuenta al poner en cola un esfuerzo de IA/ML. El siguiente gráfico es una representación visual de la historia contada en la sección anterior. Es una comparación lado a lado del enfoque AI Data Infrastructure First frente al modelo Model First. Como lo mostró la historia anterior, cada uno de los siguientes elementos del primer enfoque de infraestructura no tiene por qué ser un proyecto independiente. Las organizaciones deben buscar formas creativas de implementar la IA mientras se construye su infraestructura; esto se puede lograr entendiendo todas las posibilidades de la IA, comenzando de manera simple y luego eligiendo proyectos de IA de complejidad creciente. Conclusión Esta publicación describe nuestra experiencia trabajando con empresas para construir una arquitectura de referencia de Datalake moderna para AI/ML. Identifica los componentes centrales, los componentes clave y las compensaciones de los diferentes enfoques de IA. El elemento fundamental es un lago de datos moderno construido sobre un almacén de objetos. El almacén de objetos debe ser capaz de ofrecer rendimiento a escala, donde la escala es de cientos de petabytes y, a menudo, exabytes. Siguiendo esta arquitectura de referencia, anticipamos que el usuario podrá construir una infraestructura de datos flexible y extensible que, si bien está dirigida a AI y ML, tendrá el mismo rendimiento en todas las cargas de trabajo OLAP. Para obtener recomendaciones específicas sobre los componentes, no dude en comunicarse conmigo en . keith@min.io