Modèles d'inférence de l'IA
Les capacités d’IA et d’apprentissage automatique étant de plus en plus considérées comme essentielles pour stimuler l’innovation et l’efficacité dans les entreprises de toutes tailles, les organisations doivent déterminer la meilleure façon de fournir à leurs développeurs d’applications l’accès à ces capacités. Dans de nombreux cas, un service d’inférence d’IA sera utilisé, c’est-à-dire : « un service qui invoque des modèles d’IA pour produire une sortie basée sur une entrée donnée » (comme prédire une classification ou générer du texte), le plus souvent en réponse à un appel d’API provenant d’un autre code d’application.
Vous pouvez créer et utiliser ces services d’inférence de nombreuses façons, même au sein d’une même organisation. Vous pouvez développer entièrement ces services en interne, les consommer en SaaS, vous appuyer sur des projets open source, ou utiliser des modèles ouverts ou commerciaux. Ils peuvent faire partie d’une « plateforme de Machine Learning » pleinement fonctionnelle qui soutient des efforts étendus en science des données et création de modèles, ou vous fournir simplement un point d’accès API pour invoquer les modèles. Ces services peuvent fonctionner dans un centre de données privé, sur un cloud public, dans une salle de colocation, ou via une combinaison de ces options. Les grandes entreprises ont souvent recours à plusieurs options pour l’inférence IA, surtout lorsque leur maturité organisationnelle sur ce sujet reste limitée. Il n’existe pas de solution universelle valable pour tous, mais quelques schémas communs se dégagent.
Aperçu du modèle
Nous examinerons trois grands modèles de consommation d’inférences de l’IA, ainsi que leurs différentes forces et faiblesses :
- Inférence IA en tant que SaaS – Les applications se connectent à un fournisseur de services d’inférence IA externe dédié.
- Inférence d’IA gérée dans le cloud – Les applications se connectent à des services d’inférence d’IA entièrement gérés exécutés dans le cloud public.
- Inférence d’IA autogérée – Les applications consomment des inférences d’IA gérées par l’organisation elle-même, soit dans le cadre d’un service centralisé, soit directement au niveau de l’application.
Principaux points de décision
Lors de l’évaluation des compromis entre les modèles d’exploitation suivants, il convient de garder à l’esprit quelques facteurs clés :
Considérations opérationnelles
- Évolutivité – Qui est responsable et dans quelle mesure une option donnée évolue-t-elle à mesure que les besoins en capacité évoluent au fil du temps ? Existe-t-il des limites d’échelle ou des plafonds de capacité ?
- Coût – Les services entièrement gérés peuvent sembler plus chers à première vue, mais la prise en compte du coût total de possession (y compris le matériel et le personnel spécialisés) peut rendre la décision moins claire. Comment les coûts opérationnels évoluent-ils à mesure que la capacité augmente ou diminue ; existe-t-il des planchers pour les coûts ?
- Maintenance / Support – Qui est responsable de la maintenance du service d’inférence ? Votre organisation devra-t-elle embaucher des employés ou rémunérer des consultants ayant une expertise dans ce domaine, ou une offre de services gérés serait-elle plus judicieuse ?
Considérations relatives au développement
- Facilité d’intégration de la charge de travail – À quelle vitesse le service d’IA peut-il être intégré aux charges de travail consommatrices ? L'offre de services fonctionne-t-elle avec votre modèle d'utilisation attendu (par exemple, inférence hors ligne/par lots) et vos environnements d'exploitation ?
- Agilité – À quelle vitesse l’application globale peut-elle être adaptée aux besoins changeants de l’entreprise ? Quels aspects de l’architecture sont plus ancrés et seraient difficiles à modifier ?
Considérations relatives aux performances
- Performances – L’emplacement physique du service (par rapport aux consommateurs de services) et la latence de l’inférence sont-ils importants pour vos cas d’utilisation ?
- Disponibilité du matériel – Existe-t-il des exigences matérielles particulières pour le service et, si oui, avez-vous la capacité de répondre aux demandes attendues (applicables aux environnements sur site et dans le cloud) ?
Considérations relatives aux données
- Fuite de données – Existe-t-il un risque que des données sensibles soient envoyées au service d’inférence ou soient présentes dans le résultat de l’inférence ? Si tel est le cas, la circulation peut-elle être inspectée et des garde-corps peuvent-ils être installés ?
- Gouvernance des données – Où géographiquement sont envoyées les données d’application (et comment) ? Le contrôle direct reste-t-il au sein de l’organisation ou est-il envoyé à des tiers ? Existe-t-il des réglementations spéciales ou des politiques de conformité qui s’appliquent à la manière dont vous devez traiter les données ?
Modèle SaaS
Les organisations peuvent choisir de consommer des services auprès d’un fournisseur SaaS dédié qui se concentre sur l’hébergement de modèles d’IA pour l’inférence (tels qu’OpenAI ou Cohere). Dans ce cas, les charges de travail exécutées sur l’infrastructure d’une organisation (qu’il s’agisse d’un centre de données privé, d’une colocation ou d’un cloud public) exploitent les API publiées par le fournisseur SaaS. Avec ce modèle, la charge associée à l’exploitation de l’infrastructure requise pour héberger les modèles incombe entièrement au fournisseur SaaS, et le temps nécessaire à la mise en place et au fonctionnement peut être très bref. Ces avantages ont cependant pour prix un certain contrôle, ce modèle étant le moins « flexible » de ceux que nous aborderons. De même, le contrôle des données sensibles est généralement le plus faible avec ce modèle, où l’Internet public est généralement utilisé pour se connecter au service, et le fournisseur SaaS externe est moins susceptible de pouvoir répondre aux préoccupations strictes en matière de conformité réglementaire.
Bien adapté pour
- Délai de mise sur le marché : Prototypage rapide, versions MVP.
- Organisations ne disposant pas d’une expertise/expérience significative en interne en matière d’inférence d’IA.
- Applications sans besoins importants ou stricts en matière de sécurité/gouvernance des données.
Points forts
- Délai de mise sur le marché court : Un modèle opérationnel simple peut conduire à des temps d’intégration courts.
- Les fournisseurs de services ciblés sont bien équipés pour relever les défis de mise à l’échelle des inférences.
- Ne nécessite pas d’investissement en matériel ou en personnel spécialisé.
Défis
- Problèmes de latence et de connectivité relatifs aux services colocalisés avec les charges de travail des applications.
- Les problèmes de confidentialité, de gouvernance et de sécurité des données dépendent (ou peuvent être incompatibles avec) d'un fournisseur SaaS externe.
- Les coûts d’exploitation à plus grande échelle peuvent être plus élevés que ceux des modèles d’auto-hébergement.
- Les services d'hébergement de modèles personnalisés et de personnalisation de modèles peuvent ne pas être pris en charge.
Modèle géré par le cloud
Dans ce modèle, les organisations exploitent les services gérés fournis par les fournisseurs de cloud public (par exemple, Azure OpenAI, Google Vertex, AWS Bedrock). Comme pour le premier modèle, la charge opérationnelle liée au déploiement, à la mise à l’échelle et à la maintenance des modèles d’IA incombe au fournisseur de cloud plutôt qu’à l’organisation consommatrice. La principale différence entre ce modèle et le modèle SaaS ci-dessus est que, dans ce cas, les points de terminaison de l'API d'inférence sont généralement accessibles via des réseaux privés et les charges de travail des consommateurs d'IA peuvent être colocalisées avec le service de modèle d'IA (par exemple, la même zone, la même région). Par conséquent, les données ne transitent généralement pas par l’Internet public, la latence est susceptible d’être plus faible et les mécanismes de connexion à ces services sont similaires à ceux des autres services gérés par les fournisseurs de cloud (c’est-à-dire les comptes de service, les politiques d’accès, les listes de contrôle d’accès réseau). Les organisations qui exploitent les réseaux multicloud peuvent bénéficier de certains de ces mêmes avantages même dans les cas où les charges de travail et les services d’inférence d’IA sont hébergés dans des clouds différents.
Bien adapté pour
- Organisations disposant déjà d’investissements dans le cloud public.
- Applications exécutées ou se connectant à d’autres services gérés dans le cloud.
Points forts
- De nombreuses organisations savent déjà comment connecter leurs charges de travail à d’autres services gérés par des fournisseurs de cloud (par exemple, des bases de données, des magasins d’objets, etc.).
- La charge opérationnelle et infrastructurelle liée à l’exécution et à la mise à l’échelle des modèles incombe principalement au fournisseur de cloud.
- Les problèmes de latence et certains problèmes de confidentialité des données peuvent être plus faciles à résoudre.
Défis
- Les applications cloud multi/hybrides nécessitent des efforts supplémentaires pour se connecter et se sécuriser.
- Le manque d’uniformité entre les services gérés dans le cloud et les API peut conduire à un verrouillage des fournisseurs.
- Les organisations ne disposant pas d’une présence étendue dans le cloud public peuvent être confrontées à des difficultés.
- Les coûts d’exploitation à plus grande échelle peuvent être plus élevés que ceux des modèles d’auto-hébergement.
- Les services d'hébergement de modèles personnalisés et de personnalisation de modèles peuvent ne pas être pris en charge.
Modèle autogéré
Pour le modèle autogéré, nous discuterons d’abord du cas où l’inférence du modèle d’IA est exécutée en tant que « service partagé » centralisé, puis nous examinerons le cas où aucun service centralisé n’existe et les préoccupations opérationnelles sont laissées aux équipes d’application individuelles.
Service autogéré et partagé
Dans la variante « Service partagé » du modèle autogéré, une organisation peut disposer d'une ou plusieurs équipes dédiées chargées de maintenir l'infrastructure d'inférence, les modèles qui s'exécutent dessus, les API utilisées pour s'y connecter et tous les aspects opérationnels du cycle de vie du service d'inférence. Comme pour les autres modèles, les charges de travail des applications d’IA consommeraient des services d’inférence via des appels d’API. L'infrastructure de service du modèle peut fonctionner dans des centres de données privés, dans un cloud public ou dans une installation de colocation. Les équipes chargées d’exploiter le service d’inférence peuvent tirer parti de plateformes d’apprentissage automatique auto-hébergées (telles que Anyscale Ray ou MLFlow). Alternativement, ils pourraient s'appuyer sur des outils d'inférence plus ciblés comme le serveur d'inférence de génération de texte de Hugging Face ou sur des logiciels développés en interne. Avec l'inférence autogérée, les organisations sont limitées à l'utilisation de modèles qu'elles ont elles-mêmes formés ou qu'elles peuvent exécuter localement (les modèles propriétaires d'un service orienté SaaS peuvent donc ne pas être une option).
Bien adapté pour
- Organisations matures avec une vaste expérience en gestion d’infrastructure.
- Organisations ayant de lourdes exigences d'inférence qui justifient le coût total de possession d'un service autogéré.
- Applications avec les exigences les plus strictes en matière de confidentialité et de conformité des données.
Points forts
- Les organisations ont un contrôle total sur tous les aspects du service d’inférence.
- Les défis liés à la confidentialité des données sont généralement plus faciles à résoudre avec des modèles auto-hébergés.
- Le coût à grande échelle peut être plus efficace que les services d’inférence gérés dans le cloud ou basés sur SaaS.
Défis
- Les organisations ont un contrôle total sur tous les aspects du service d’inférence (des investissements importants en matière d’infrastructure et de personnel sont susceptibles d’être nécessaires, ainsi que des problèmes continus de maintenance, de développement et d’évolutivité).
- Généralement pas rentable pour les organisations ayant des besoins d'inférence minimes et des préoccupations minimales en matière de confidentialité des données.
- Aucun accès aux modèles fermés/propriétaires qui peuvent être disponibles sous forme de services SaaS ou gérés dans le cloud.
Autogéré, pas un service partagé
Les organisations sans équipe centrale chargée d’exécuter les services d’inférence d’IA pour les applications à consommer constituent l’autre variante du modèle autogéré. Dans cette version, les équipes d’application individuelles peuvent exécuter leurs modèles sur la même infrastructure qui leur a été allouée pour la charge de travail de l’application. Ils peuvent choisir d’accéder à ces modèles via API ou de les consommer directement de manière « hors ligne ». Avec ce modèle, les développeurs peuvent bénéficier de certains des mêmes avantages que le modèle autogéré « Service partagé » à une plus petite échelle.
Bien adapté pour
- Applications nécessitant un traitement par lots et une inférence hors ligne.
- Organisations avec une consommation d'inférence très légère, mais des exigences strictes en matière de confidentialité et de conformité des données.
Points forts
- Le plus flexible pour les développeurs d'applications, permettant un large éventail de possibilités d'intégration avec les charges de travail.
- Peut atteindre les objectifs de confidentialité des données et de latence à petite échelle.
- Peut être plus rentable que les autres modèles évoqués dans certains cas (comme une équipe unique avec des besoins de consommation importants).
Défis
- La charge opérationnelle du cycle de vie du modèle repose sur les équipes d’application individuelles.
- Vous ne profitez pas des économies d'échelle à mesure que la consommation d'inférences IA de votre organisation augmente (manque de cohérence, mauvaise utilisation des ressources du serveur, etc.)
Résumé des compromis entre les modèles
Sécurisation des applications d'IA et des services d'inférence de modèles
À la base, les applications d'IA ressemblent beaucoup à n'importe quelle autre application moderne. Elles sont conçues à partir d'un mélange de composants orientés utilisateur et back-end, s'appuient souvent sur des magasins de données externes, font un usage intensif des appels d'API, etc. Ces applications héritent des mêmes défis de sécurité communs à toutes les applications modernes et nécessitent les mêmes protections appliquées de la même manière (par exemple, AuthNZ, protections DDoS, WAF, pratiques de développement sécurisées, etc.). Cependant, les applications d’IA, et en particulier celles qui exploitent l’IA générative, sont également soumises à un certain nombre de préoccupations uniques qui peuvent ne pas s’appliquer à d’autres applications (par exemple, voir OWASP Top 10 For LLMs ). La nature généralement imprévisible de ces modèles peut conduire à de nouveaux problèmes, en particulier dans les cas d’utilisation où les modèles bénéficient d’une autonomie importante.
Heureusement, en raison de la forte dépendance aux interactions pilotées par API avec l’inférence du modèle d’IA dans les modèles décrits ci-dessus, de nombreuses organisations sont déjà bien placées pour mettre en œuvre ces nouvelles mesures de sécurité. Par exemple, une passerelle API qui fournit des fonctionnalités traditionnelles de limitation de débit, d’authentification, d’autorisation et de gestion du trafic peut être étendue pour prendre en charge des limites de débit basées sur des jetons afin de contribuer au contrôle des coûts (soit sortant au niveau de l’application vers un service géré par SaaS/fournisseur, soit une autorisation RBAC entrante comme protection devant un service d’inférence autogéré). De même, l’infrastructure qui exécute actuellement des services de pare-feu d’application Web (WAF) traditionnels, tels que la vérification des injections SQL ou XSS, pourrait être un endroit logique pour ajouter des protections contre les injections rapides et les attaques similaires. La plupart des pratiques d’observabilité modernes sont directement applicables aux cas d’utilisation spécifiques d’inférence d’IA pilotée par API, et les équipes devraient être en mesure de faire bon usage des outils et pratiques existants dans cet espace.
Conclusion
L'enthousiasme autour des applications et services d'inférence alimentés par l'IA est récent, mais les principes fondamentaux pour les déployer et les sécuriser existent depuis longtemps. Vous devrez évaluer les compromis pour tirer le meilleur parti des capacités de l'IA, comme vous le faites pour toute autre technologie, en fonction de vos cas d’usage, ressources disponibles et objectifs à long terme. De même, même si les cas liés à l’IA, notamment générative, posent des défis de sécurité inédits, les besoins partagés avec d’autres applications modernes et la forte dépendance aux interactions via API sont une excellente occasion d’adopter et d’étendre les modèles, pratiques et outils déjà éprouvés. Qu’elle soit auto-hébergée ou en service managé, offrez aux développeurs une solution sécurisée, évolutive et performante qui répond précisément à vos exigences métier pour valoriser pleinement vos investissements en IA.