Unité 8 / 11

Hébergement sur site, VPC et Openweight

Gains :

  • Capacité à évaluer les compromis entre l'API gérée, le VPC et l'hébergement sur site
  • Possibilité de décider de l'hébergement en fonction de la souveraineté des données, du volume et de la capacité opérationnelle
  • Possibilité de calculer le coût total de possession (TCO) avec des éléments complets et de concevoir une architecture hybride

Pour certaines organisations, « l’envoi de données à un fournisseur » – aussi sécurisé soit-il – n’est pas acceptable. Dans l’industrie de la défense, dans le secteur public, dans le secteur bancaire et dans certains scénarios de santé, les données ne devraient jamais dépasser les frontières de l’institution. À ce stade, l’hébergement de votre propre modèle passe au premier plan : des modèles ouverts, fonctionnant sur votre propre réseau cloud (VPC) ou sur vos propres serveurs (sur site). Dans cette unité, nous apprendrons les compromis entre l'API gérée et l'auto-hébergement, lorsque cela est logique, ainsi que le coût total de possession (TCO).

notions

  • API gérée : s'exécute sur l'infrastructure du fournisseur de modèles ; Vous envoyez une demande et obtenez une réponse. La surcharge opérationnelle est minime, mais les données vont au fournisseur.
  • Modèle à poids ouvert : les paramètres du modèle (poids) peuvent être téléchargés ; Vous pouvez l'exécuter sur votre propre matériel. Ce n'est pas forcément la même chose que "open source" (la licence peut être différente).
  • Hébergement VPC (Virtual Private Cloud) : exécution du modèle dans votre propre réseau cloud isolé ; Les données restent à la limite de votre réseau, mais l'infrastructure est toujours dans le cloud.
  • Sur site (sur site) : exécution du modèle entièrement sur le matériel de votre propre centre de données ; contrôle le plus élevé, charge opérationnelle la plus élevée.
Attention : « Propre hébergement est toujours plus sûr » est une idée fausse. La sécurité dépend moins de l’endroit où vous conservez les données que de la manière dont vous les gérez. Un serveur sur site non corrigé et mal configuré est plus risqué qu'une API gérée mature.

Axe de décision : lequel, quand ?

Trois questions guident la décision :

  1. Souveraineté des données : la loi ou le contrat interdit-il aux données de quitter l'institution/le pays ? Si oui, vous serez poussé vers le VPC/on-prem.
  2. Volume et coût : l’utilisation est-elle très élevée et prévisible ? Des volumes très élevés d’auto-hébergement peuvent réduire les coûts unitaires ; L'API gérée à un volume faible ou irrégulier est presque toujours bon marché.
  3. Capacité opérationnelle : disposez-vous de l'équipe nécessaire pour maintenir l'infrastructure GPU, la mise à jour des modèles, la mise à l'échelle et les correctifs de sécurité ? Sinon, votre propre hébergement représente un coût caché.

Tableau des compromis

Taille

API gérée

VPC

Sur site (poids ouvert)

Souveraineté des données

Faites confiance au fournisseur

Élevé (à la limite de votre réseau)

Le plus haut (ne monte jamais)

Charge de fonctionnement

trop bas

moyen

haut

Coût initial

Faible (payez au fur et à mesure)

moyen

Élevé (matériel)

mise à l'échelle

automatique

Géré

votre responsabilité

Qualité/devise du modèle

le plus récent, automatique

Cela dépend

Vous mettez à jour

contrôle

faible

haut

plein

Étape par étape : décision d'hébergement

  1. Déterminez la classe de données. À quel niveau de confidentialité les données seront-elles traitées ?
  2. Vérifier la contrainte légale. Les données peuvent-elles sortir ? (KVKK, réglementation sectorielle, contrat.)
  3. Estimez le volume. Volume mensuel de requêtes/tokens et courbe de croissance.
  4. Calculez le coût total de possession. Pas seulement le GPU ; énergie, maintenance, équipe, sécurité, redondance.
  5. Pensez hybride. Un modèle hybride qui traite les données sensibles dans le VPC sur site et les données non sensibles dans l'API gérée est souvent le plus stable.

Quatre modèles copiables

Invite de décision d’hébergement :

Décidez de l'hébergement pour l'utilisation suivante : {{ scénario }}Questions : - Quelle est la classe de confidentialité des données à traiter ? (public/interne/confidentiel/top secret)- La loi/le contrat autorise-t-il la sortie des données en dehors de l'organisation ?- Prévisions et prévisibilité des volumes mensuels ?- Existe-t-il une capacité d'exploitation/équipe GPU ? Recommandation : « API managée / VPC / On-prem / Hybride » + justification.

Liste des éléments TCO (pour l'auto-hébergement) :

Calculez le coût total de possession par : - Achat/location de matériel (GPU) - Énergie et refroidissement - Humain : MLOps + temps de l'équipe de sécurité - Main-d'œuvre de mise à jour et de test du modèle - Redondance/reprise après sinistre - Correctifs de sécurité et surveillance Comparez cela à la facture mensuelle de l'API gérée sur un horizon de 12 à 24 mois.

Règle de routage hybride :

Acheminez chaque requête en fonction de la classe de données : - Données "secrètes/top secrètes" -> Modèle sur site/VPC - Données "publiques / internes" -> API gérée (plus puissante/moins chère) Écrivez la décision de transfert et la classe de données dans le journal d'audit.

Ouvrir l'invite de contrôle de sécurité du poids :

Évaluez notre modèle auto-hébergé : - La licence autorise-t-elle une utilisation commerciale et dans notre scénario ? - Les pondérations du modèle proviennent d'une source fiable, l'intégrité (hachage) est vérifiée ?

Invite faible/Invite forte

mauvaise approche

Approche forte

"Le sur site est plus sûr, utilisez-le toujours"

Décision basée sur la souveraineté des données + volume + capacité

Il suffit de regarder le coût du GPU

TCO complet (énergie, équipage, mises à jour, sécurité)

Être enfermé dans un modèle d’hébergement unique

Hybride : routage par classe de données

Courir sans baisser le poids ouvert et le vérifier

Licence + intégrité + patch + contrôle de trace

Trois mini-étuis

Cas 1 — Le mandat sur site était la bonne décision. Un entrepreneur de la défense devait traiter des documents hautement classifiés ; Le contrat interdisait de sortir des données hors du pays. L'API gérée a été supprimée dès le début. Le modèle de poids ouvert sur site a été établi ; Le coût était élevé, mais c’était la seule option compatible.

Cas 2 — Décision confidentielle annulée par TCO. Une startup envisageait de passer à l’auto-hébergement car « l’API coûte cher ». Dans le calcul du TCO, vous n’incluez pas seulement le GPU ; Ajoutez 2 ingénieurs MLOps à temps plein, la charge de mise à jour et la redondance, et le total sur 24 mois est le double de celui de l'API gérée. Ils sont restés dans l’API car leurs volumes étaient faibles et sporadiques.

Cas 3 — L'hybride a donné le meilleur. L'assistant du centre d'appels d'une banque traitait deux types de données : des questions générales sur les produits et des données de compte spécifiques au client. Les données du compte sont dirigées vers le modèle au sein du VPC, les questions générales sont dirigées vers la puissante API gérée. Les données sensibles ne sont jamais sorties, la qualité du modèle le plus solide a été utilisée pour des questions générales ; le coût et l’ajustement sont optimisés ensemble.

Astuce : La décision ne doit pas nécessairement être binaire (tout ou rien). L'architecture hybride (routage des données par classe) résout simultanément la conformité et les coûts dans la plupart des scénarios d'entreprise.

Erreurs courantes

  • Supposons que « votre propre hébergement soit automatiquement plus sûr » ; alors que la sécurité dépend de la qualité de la gestion.
  • Penser que le TCO n’est qu’un coût GPU ; équipe, énergie, mise à jour et oubli de la sécurité.
  • Passer à l’auto-hébergement à volume faible/irrégulier et augmenter le coût unitaire.
  • Utilisation du modèle de poids ouvert sans vérifier la licence et l'intégrité (hachage).
  • Ne pas installer de surveillance/journalisation aussi mature que l'API gérée sur le serveur sur site.
  • Prendre une décision binaire sans considérer du tout l’option hybride.

En résumé

  • L'API gérée est la plus simple sur le plan opérationnel, mais les données vont au fournisseur ; VPC/sur site conserve les données à votre frontière.
  • Trois questions guident la décision : la souveraineté des données, la prévisibilité du volume et des coûts et la capacité opérationnelle.
  • « L'auto-hébergement est plus sécurisé » est une idée fausse ; La sécurité ne dépend pas de l'endroit où vous conservez les données, mais de la manière dont vous les gérez.
  • Calculez le TCO exact : énergie, équipe, mise à jour, redondance et sécurité, ainsi que GPU.
  • L'architecture hybride (routage des données par classe) équilibre simultanément conformité et coûts dans la plupart des scénarios d'entreprise.

Tâche de candidature

Choisissez une utilisation de l'IA et séparez les données à traiter dans une classe de confidentialité. Générez une recommandation avec l’invite de décision d’hébergement. Remplissez ensuite la liste des éléments TCO pour votre propre hébergement et comparez le total sur 24 mois à la facture de l'API gérée. Enfin, rédigez un projet de règle de routage hybride : quelles données vont où ?

liste de contrôle

  • [ ] J'ai déterminé la classe de confidentialité et les restrictions légales des données à traiter.
  • [ ] J'ai pris la décision d'hébergement en fonction de la souveraineté + du volume + de la capacité.
  • [ ] J'ai calculé le TCO avec des éléments complets (y compris non GPU).
  • [ ] J'ai vérifié la licence, l'intégrité, les correctifs et la surveillance sur l'auto-hébergement.
  • [ ] J'ai envisagé l'option de routage hybride.
  • [ ] J'ai documenté la décision et son raisonnement.