Patrones de inferencia de IA
A medida que las capacidades de inteligencia artificial y aprendizaje automático se consideran cada vez más fundamentales para impulsar la innovación y la eficiencia en empresas de todos los tamaños, las organizaciones deben determinar cuál es la mejor manera de brindar a sus desarrolladores de aplicação acceso a esas capacidades. En muchos casos, se utilizará un servicio de inferencia de IA, es decir: “un servicio que invoca modelos de IA para producir un resultado basado en una entrada determinada” (como predecir una clasificación o generar texto), generalmente en respuesta a una llamada API desde otro código de aplicação .
Estos servicios de inferencia pueden crearse y consumirse de una amplia variedad de formas (incluso dentro de una sola organización). Estos servicios pueden desarrollarse íntegramente internamente o consumirse como SaaS, aprovechar proyectos de código abierto y utilizar modelos abiertos o comerciales. Pueden venir como parte de una “plataforma de aprendizaje automático” completamente funcional que respalde esfuerzos más amplios de creación de modelos y ciencia de datos, o pueden proporcionarle nada más que un punto final de API para invocar los modelos. Pueden ejecutarse en un centro de datos privados, en una nube pública, en una instalación de coubicación o como una combinación de estos. Es probable que las organizaciones más grandes dependan de más de una única opción para la inferencia de IA (especialmente en los niveles más bajos de madurez organizacional en este espacio). Si bien no existe un enfoque único que funcione para todos, están surgiendo algunos patrones comunes.
Resumen del patrón
Examinaremos tres amplios patrones de consumo de inferencia de IA, así como sus diversas fortalezas y debilidades:
- Inferencia de IA como SaaS : las aplicações se conectan a un proveedor de servicios de inferencia de IA dedicado externo.
- Inferencia de IA administrada en la nube : las aplicações se conectan a servicios de inferencia de IA totalmente administrados que se ejecutan en la nube pública.
- Inferencia de IA autogestionada : las aplicações consumen inferencia de IA gestionada por la propia organización, ya sea como parte de un servicio centralizado o directamente en el nivel de la aplicação .
Puntos clave de decisión
Al evaluar las ventajas y desventajas entre los siguientes patrones operativos, hay algunos factores clave a tener en cuenta:
Consideraciones operativas
- Escalabilidad : ¿Quién es responsable de que una opción determinada se amplíe o reduzca a medida que las necesidades de capacidad cambian con el tiempo? ¿Existen límites de escala o topes de capacidad?
- Costo : los servicios totalmente administrados pueden parecer más costosos a primera vista, pero tener en cuenta el costo total de propiedad (incluido cualquier hardware y personal especializado) puede hacer que la decisión sea menos clara. ¿Cómo se escalan los costos operativos a medida que aumenta o disminuye la capacidad? ¿Existen límites mínimos para los costos?
- Mantenimiento / Soporte – ¿Quién es responsable del mantenimiento del servicio de inferencia? ¿Su organización necesitará contratar empleados o pagar consultores con experiencia en esta área, o tendría más sentido una oferta de servicios gestionados?
Consideraciones de desarrollo
- Facilidad de integración de la carga de trabajo : ¿Con qué rapidez se puede integrar el servicio de IA con las cargas de trabajo que lo consumen? ¿La oferta de servicios funciona con su patrón de uso esperado (por ejemplo, inferencia por lotes o fuera de línea) y entornos operativos?
- Agilidad : ¿Con qué rapidez se puede adaptar la aplicação general a los cambiantes requisitos del negocio? ¿Qué aspectos de la arquitectura están más arraigados y serían difíciles de cambiar?
Consideraciones de rendimiento
- Rendimiento : ¿La ubicación física del servicio (en relación con los consumidores del servicio) y la latencia de la inferencia son importantes para sus casos de uso?
- Disponibilidad de hardware : ¿Existen requisitos de hardware especiales para el servicio y, de ser así, tiene la capacidad para satisfacer las demandas previstas (aplicable tanto a entornos locales como a entornos en la nube)?
Consideraciones sobre los datos
- Fuga de datos : ¿Existe la preocupación de que se envíen datos confidenciales al servicio de inferencia o que estén presentes en el resultado de la inferencia? Si es así, ¿se puede inspeccionar el tráfico y colocar barandillas?
- Gobernanza de datos : ¿Dónde se envían geográficamente los datos de la aplicação (y cómo)? ¿ El control directo permanece dentro de la organización o se transmite a terceros? ¿Existen regulaciones especiales o políticas de cumplimiento que se apliquen a cómo debe tratar los datos?
Patrón SaaS
Las organizaciones pueden optar por consumir servicios de un proveedor de SaaS dedicado que se centra en alojar modelos de IA para inferencia (como OpenAI o Cohere). En este caso, las cargas de trabajo que se ejecutan en la infraestructura de una organización (ya sea un centro de datos privados, una ubicación conjunta o una nube pública) aprovechan las API publicadas por el proveedor de SaaS. Con este patrón, la carga asociada con la operación de la infraestructura requerida para alojar los modelos recae completamente sobre el proveedor de SaaS, y el tiempo que lleva ponerse en funcionamiento puede ser muy breve. Sin embargo, estos beneficios se obtienen a costa del control, siendo este patrón el menos “flexible” de los que analizaremos. Asimismo, el control sobre datos sensibles suele ser mínimo con este modelo, en el que se suele utilizar Internet público para conectarse con el servicio y es menos probable que el proveedor externo de SaaS pueda abordar cuestiones de cumplimiento normativo estricto.
Muy adecuado para
- Tiempo de comercialización: Prototipado rápido, lanzamientos de MVP.
- Organizaciones sin experiencia ni conocimientos significativos en inferencia de IA interna.
- Aplicações sin necesidades significativas o estrictas de seguridad de datos.
Fortalezas
- Corto plazo de comercialización: Un modelo operativo simple puede conducir a tiempos de integración cortos.
- Los proveedores de servicios especializados están bien equipados para abordar los desafíos de escalamiento de inferencia.
- No requiere inversión en hardware ni personal especializado.
Retos
- Preocupaciones de latencia y conectividad relativas a los servicios ubicados junto con las cargas de trabajo de las aplicaciones.
- Las preocupaciones sobre la privacidad, la gobernanza y la seguridad de los datos dependen de (o pueden ser incompatibles con) un proveedor de SaaS externo.
- Los costos de gastos operativos a mayor escala pueden ser más altos que los de los modelos de autohospedaje.
- Es posible que no se admitan los servicios de alojamiento y personalización de modelos personalizados.
Patrón gestionado en la nube
En este patrón, las organizaciones aprovechan los servicios administrados proporcionados por proveedores de nube pública (por ejemplo, Azure OpenAI, Google Vertex, AWS Bedrock). Al igual que con el primer patrón, la carga operativa para implementar, escalar y mantener los modelos de IA recae en el proveedor de nube en lugar de en la organización consumidora. La principal diferencia entre este patrón y el patrón SaaS mencionado anteriormente es que, en este caso, los puntos finales de la API de inferencia generalmente son accesibles a través de redes privadas, y las cargas de trabajo de los consumidores de IA se pueden ubicar junto con el servicio de modelo de IA (por ejemplo, la misma zona o región). Como resultado, los datos generalmente no transitan por Internet público, la latencia probablemente sea menor y los mecanismos para conectarse a estos servicios son similares a los de otros servicios administrados proveedor de nube (es decir, cuentas de servicio, políticas de acceso, ACL de red). Las organizaciones que aprovechan las redes multicloud pueden lograr algunos de estos mismos beneficios incluso en casos donde las cargas de trabajo y los servicios de inferencia de IA están alojados en diferentes nubes.
Muy adecuado para
- Organizaciones con inversiones en nube pública existentes.
- Aplicações que se ejecutan o se conectan a otros servicios administrados en la nube.
Fortalezas
- Muchas organizaciones ya están familiarizadas con la conexión de sus cargas de trabajo a otros servicios administrados proveedor de nube (por ejemplo, bases de datos, almacenes de objetos, etc.).
- La carga operativa y de infraestructura para ejecutar y escalar modelos recae principalmente sobre el proveedor de nube.
- Las preocupaciones sobre latencia y algunas preocupaciones sobre privacidad de datos pueden ser más fáciles de abordar.
Retos
- Las aplicações en nube híbrida requieren un esfuerzo adicional para conectarse y protegerse.
- La falta de uniformidad entre los servicios administrados en la nube y las API puede generar dependencia del proveedor.
- Las organizaciones sin una amplia presencia en la nube pública pueden enfrentar dificultades.
- Los costos de gastos operativos a mayor escala pueden ser mayores que los de los modelos autohospedados.
- Es posible que no se admitan los servicios de alojamiento y personalización de modelos personalizados.
Patrón autogestionado
Para el modelo autogestionado, primero analizaremos el caso en el que la inferencia del modelo de IA se ejecuta como un “servicio compartido” centralizado, luego examinaremos el caso en el que no existe un servicio centralizado y las preocupaciones operativas se dejan en manos de equipos de aplicação individuales.
Servicio compartido y autogestionado
En la variante de “Servicio compartido” del patrón autogestionado, una organización puede tener equipos dedicados responsables de mantener la infraestructura de inferencia, los modelos que se ejecutan en ella, las API utilizadas para conectarse a ella y todos los aspectos operativos del ciclo de vida del servicio de inferencia. Al igual que con los otros patrones, las cargas de trabajo de las aplicação de IA consumirían servicios de inferencia a través de llamadas API. El modelo de infraestructura de servicio podría ejecutarse en centros de datos privados, en una nube pública o en una instalación de coubicación. Los equipos responsables de operar el servicio de inferencia pueden aprovechar plataformas de aprendizaje automático autohospedadas (como Anyscale Ray o MLFlow). Como alternativa, podrían confiar en herramientas de inferencia con un enfoque más específico, como el servidor de inferencia de generación de texto de Hugging Face o un software desarrollado internamente. Con la inferencia autogestionada, las organizaciones están limitadas a usar modelos que ellas mismas han entrenado o que están disponibles para ejecutar localmente (por lo que los modelos propietarios de un servicio orientado a SaaS pueden no ser una opción).
Muy adecuado para
- Organizaciones maduras con amplia experiencia en gestión de infraestructura.
- Organizaciones con altos requisitos de inferencia que justifican el TCO de un servicio autogestionado.
- Aplicações con los requisitos más estrictos de privacidad y cumplimiento de datos.
Fortalezas
- Las organizaciones tienen el control total de todos los aspectos del servicio de inferencia.
- Los desafíos en materia de privacidad de datos suelen ser más fáciles de abordar con modelos autohospedados.
- Los costos a gran escala pueden ser más eficientes que los servicios de inferencia basados en SaaS o administrados en la nube.
Retos
- Las organizaciones tienen el control total de todos los aspectos del servicio de inferencia (es probable que se requieran grandes inversiones en infraestructura y personal, además de preocupaciones constantes de mantenimiento, desarrollo y escalabilidad).
- Normalmente no resulta rentable para organizaciones con necesidades mínimas de inferencia y preocupaciones mínimas de privacidad de datos.
- Sin acceso a modelos cerrados o propietarios que pueden estar disponibles como SaaS o servicios administrados en la nube.
Servicio autogestionado, no compartido.
Las organizaciones que no tienen un equipo central responsable de ejecutar servicios de inferencia de IA para que las aplicações los consuman son la otra variante del patrón autogestionado. En esta versión, los equipos de aplicação individuales pueden ejecutar sus modelos en la misma infraestructura que se les ha asignado para la carga de trabajo de la aplicação . Pueden optar por acceder a esos modelos a través de API o consumirlos directamente de manera “sin conexión”. Con este patrón, los desarrolladores podrán obtener algunos de los mismos beneficios que el modelo autogestionado de “Servicio compartido” en una escala más pequeña.
Muy adecuado para
- Aplicações que requieren procesamiento por lotes e inferencia fuera de línea.
- Organizaciones con un consumo de inferencia muy bajo, pero con requisitos estrictos de privacidad y cumplimiento de datos.
Fortalezas
- Más flexible para desarrolladores de aplicação , permitiendo una amplia gama de posibilidades de integración con cargas de trabajo.
- Puede alcanzar objetivos de privacidad y latencia de datos a pequeña escala.
- Puede resultar más rentable que los otros modelos analizados en algunos casos (como en el caso de un solo equipo con grandes requisitos de consumo).
Retos
- La carga operativa del ciclo de vida del modelo recae sobre los equipos de aplicação individuales.
- No aprovecha las economías de escala a medida que crece el consumo de inferencia de IA de una organización (falta de consistencia, utilización ineficiente de recursos, etc.)
Resumen de las compensaciones de patrones
Protección de aplicaciones de IA y servicios de inferencia de modelos
En esencia, las aplicações de IA son muy similares a cualquier otra aplicación moderna. Se crean con una combinación de componentes de usuario y backend, suelen depender de almacenes de datos externos y hacen un uso intensivo de llamadas a API, etc. Estas aplicações heredan los mismos desafíos de seguridad comunes a todas las aplicaciones modernas y necesitan las mismas protecciones aplicadas de la misma manera (por ejemplo, AuthNZ, protecciones DDoS, WAF, prácticas de desarrollo seguras, etc.). Sin embargo, las aplicaciones de IA, y especialmente aquellas que aprovechan la IA generativa, también están sujetas a una serie de preocupaciones únicas que pueden no aplicarse a otras aplicações (por ejemplo, consulte OWASP Top 10 For LLMs ). La naturaleza generalmente impredecible de estos modelos puede dar lugar a problemas nuevos, especialmente en casos de uso donde se les otorga una autonomía significativa.
Afortunadamente, debido a la gran dependencia de las interacciones impulsadas por API con la inferencia de modelos de IA en los patrones analizados anteriormente, muchas organizaciones ya están bien posicionadas para implementar estas nuevas medidas de seguridad. Por ejemplo, una puerta de enlace API que brinda funciones tradicionales de limitación de velocidad, autenticación, autorización y gestión de tráfico se puede ampliar para admitir límites de velocidad basados en tokens para ayudar con el control de costos (ya sea de salida a nivel de aplicación a un servicio administrado por SaaS/proveedor o de autorización RBAC de entrada como protección frente a un servicio de inferencia autogestionado). De la misma manera, la infraestructura que actualmente realiza servicios tradicionales de firewall de aplicação web (WAF), como verificar inyecciones de SQL o XSS, podría ser un lugar lógico para agregar protecciones contra inyecciones rápidas y ataques similares. La mayoría de las prácticas de observabilidad modernas son directamente aplicables a casos de uso específicos de inferencia de IA impulsadas por API, y los equipos deberían poder hacer un buen uso de las herramientas y prácticas existentes en este espacio.
CONCLUSIÓN
Si bien el revuelo en torno a las aplicações impulsadas por IA y los servicios de inferencia es ciertamente nuevo, los principios fundamentales que entran en juego al implementarlos y protegerlos existen desde hace mucho tiempo. Las organizaciones deberán evaluar las ventajas y desventajas a la hora de determinar cuál es la mejor manera de aprovechar las capacidades de la IA, tal como lo hacen cuando consumen cualquier otra tecnología, en función de sus casos de uso específicos, los recursos disponibles y los objetivos a largo plazo. De manera similar, si bien los casos de uso de IA (y particularmente de IA generativa) presentan algunos desafíos de seguridad novedosos, las necesidades que comparten con otras aplicações modernas y la fuerte dependencia de la interacción de modelos impulsada por API presentan una gran oportunidad para usar y ampliar patrones, prácticas y herramientas existentes. Ya sea un servicio autohospedado o administrado, garantizar que los desarrolladores tengan acceso a una solución segura, escalable y de alto rendimiento que satisfaga sus requisitos comerciales específicos es fundamental para maximizar el valor y el impacto de sus inversiones en IA.