Déploiement de la vision par ordinateur : cloud géré ou auto-hébergé

Le déploiement cloud géré est généralement le moyen le plus rapide de lancer un service de vision par ordinateur. L’auto-hébergement est généralement préférable lorsque la latence, les limites liées aux données ou le contrôle de l’infrastructure sont des exigences strictes. La difficulté, c’est que les équipes comparent souvent les deux avant de définir quelle partie du système elles veulent contrôler.

Une application de vision comporte au moins quatre emplacements à choisir : où les images sont stockées, où les modèles sont entraînés, où l’inférence s’exécute et où l’application environnante s’exécute. Ces choix n’ont pas besoin de coïncider. Une équipe peut conserver les images sources et l’entraînement sur sa propre infrastructure, exécuter l’inférence sur des appareils en périphérie et utiliser malgré tout une plateforme gérée pour le suivi des expériences et la gestion des modèles.

Les modèles Ultralytics YOLO prennent en charge ce type de flux de travail portable. Ultralytics Platform peut gérer le cycle de vie des données et de l’entraînement, tandis que les modèles exportés peuvent s’exécuter sur l’infrastructure adaptée à l’application. Le bon choix ne se résume donc pas toujours au cloud ou à l’auto-hébergement. Il s’agit souvent d’une architecture hybride qui définit clairement les limites de chaque composant.

Cloud géré ou auto-hébergement : aperçu#

Choisis le cloud géré si la rapidité, la demande variable et une petite équipe d’infrastructure sont tes priorités. Choisis l’auto-hébergement si la charge de travail doit rester dans un environnement contrôlé ou si l’inférence doit se poursuivre sans connexion réseau. Choisis une architecture hybride lorsque les exigences diffèrent pour les données, l’entraînement et l’inférence.

Ce que signifie le cloud géré pour la vision par ordinateur#

Dans un déploiement géré, un fournisseur exploite une partie ou la totalité de l’infrastructure qui héberge le service de modèles. L’équipe fournit un modèle ou en choisit un géré, configure un point de terminaison et paie les ressources ou les requêtes qu’elle consomme.

Le fournisseur peut prendre en charge le provisionnement des points de terminaison, les vérifications d’état, la mise à l’échelle automatique, les mises à jour de la couche de service et l’intégration à sa pile de surveillance. Cela réduit considérablement le travail sur la plateforme, mais ne dégage pas l’équipe de ses responsabilités applicatives. L’équipe reste responsable de la qualité du modèle, de la validation des entrées, de la logique métier, des politiques d’accès et de la décision concernant les images autorisées à atteindre le service.

Le cloud géré est particulièrement adapté lorsque le trafic varie considérablement au fil du temps, que l’organisation utilise déjà ce cloud et qu’un aller-retour réseau respecte le budget de latence. Il est également utile pendant un projet pilote, quand l’achat et l’exploitation d’une flotte de GPU dédiée entraîneraient des dépenses importantes avant même que la charge de travail soit comprise.

En contrepartie, tu dépends du modèle de points de terminaison, des régions, des quotas et de la structure tarifaire du fournisseur. Un service peu coûteux au volume d’un projet pilote peut devenir le principal poste de dépense en production si chaque caméra envoie chaque image au cloud.

Ce que signifie l’auto-hébergement pour la vision par ordinateur#

Un déploiement auto-hébergé signifie que l’organisation exploite l’infrastructure de service. Il peut s’agir d’un serveur dans un centre de données, d’un cluster Kubernetes, d’un ordinateur industriel à côté d’une ligne de production ou d’un appareil embarqué relié à une caméra.

L’organisation contrôle la circulation des données et le calendrier des changements logiciels. Elle est également responsable de la planification de la capacité, des pilotes GPU, de la compatibilité des environnements d’exécution, du déploiement des modèles, de l’observabilité, des mises à jour de sécurité, des sauvegardes et de la reprise après incident. « Fonctionne sur notre matériel » ne constitue pas un modèle opérationnel tant que chacune de ces tâches n’a pas de responsable.

L’auto-hébergement est particulièrement adapté lorsque l’inférence doit se poursuivre hors ligne, que les images ne peuvent pas quitter un site ou qu’une charge de travail volumineuse et prévisible rend le calcul dédié rentable. C’est aussi le choix naturel pour les applications qui doivent renvoyer un résultat dans un délai qu’un aller-retour vers le cloud ne peut respecter.

En contrepartie, les exigences opérationnelles sont importantes. Un conteneur fonctionnel sur un seul GPU ne garantit pas un service de production fiable sur de nombreux sites.

Comparer le coût réel#

Ne compare pas le prix par requête d’un point de terminaison cloud au prix d’achat d’un serveur. Compare le coût total du système pour une même période et une même charge de travail.

Pour le cloud géré, inclus :

• le calcul nécessaire à l’inférence et toute capacité minimale provisionnée ;
• le stockage et le transfert de données ;
• la surveillance, la journalisation et les artefacts conservés ;
• les points de terminaison de développement et de préproduction ;
• les ressources inactives qui restent actives entre les pics de charge ; et
• le temps d’ingénierie consacré à l’intégration du service et à la maîtrise des coûts.

Pour l’auto-hébergement, inclus :

• serveurs, appareils périphériques, accélérateurs et capacité de réserve ;
• installation, alimentation électrique, refroidissement et accès au site ;
• infrastructure d’orchestration, de surveillance et de mise à jour ;
• temps consacré par le personnel aux pilotes, aux environnements d’exécution, à la sécurité et aux incidents ;
• matériel de remplacement et assistance ; et
• la capacité réservée aux pics d’activité ou aux défaillances.

La nature de la charge de travail change la réponse. Le cloud est intéressant lorsque la demande est incertaine ou irrégulière, car tu peux augmenter la capacité sans acheter de matériel. Une infrastructure dédiée devient plus intéressante lorsque son taux d’utilisation est élevé et prévisible, à condition que l’organisation dispose déjà du personnel nécessaire pour l’exploiter.

Comparer la latence et la bande passante#

Les charges de travail de vision par ordinateur sont particulièrement sensibles aux transferts de données. Les images et les vidéos sont beaucoup plus volumineuses que les charges utiles habituelles des API, et une caméra peut générer plus d’images que l’application n’a besoin d’en analyser.

Commence par définir le budget de latence de bout en bout de l’application. Prends en compte la capture, l’encodage, le transfert réseau, la mise en file d’attente, l’inférence et le temps nécessaire pour renvoyer la décision à la machine ou à l’utilisateur. Si le résultat commande un robot, une ligne de production ou une alerte de sécurité, l’inférence locale peut être nécessaire, même si la gestion du modèle reste dans le cloud.

La bande passante est une contrainte distincte. Envoyer un flux vidéo continu à un point de terminaison distant peut représenter l’essentiel des coûts et échouer lorsque la connectivité est instable. Un système périphérique peut exécuter l’inférence localement et n’envoyer en amont que des événements, des métadonnées ou des images sélectionnées.

Comparer la confidentialité et les limites des données#

« Sur site » et « privé » ne sont pas synonymes. Un système auto-hébergé peut être mal sécurisé, et un service géré peut offrir des contrôles rigoureux. La décision commence par une cartographie des données :

• où les images sources sont capturées et stockées ;
• si les images dérivées ou les recadrages quittent le site ;
• où les étiquettes et les annotations sont stockées ;
• quels artefacts de modèle encodent des informations apprises à partir des données ;
• quels membres du personnel et quels systèmes peuvent accéder à chaque niveau ; et
• combien de temps les journaux, les requêtes et les résultats sont conservés.

L’intégration On Premise d’Ultralytics Platform montre pourquoi les limites doivent être définies avec précision. Les pixels des jeux de données sources et dérivés restent sur l’ordinateur connecté pendant l’ingestion, la prévisualisation et l’entraînement. Les classes, les étiquettes et les annotations sont stockées sous forme de métadonnées Platform, les métriques d’entraînement sont transmises en continu à la Platform et le meilleur point de contrôle est téléversé pour les flux de travail ultérieurs. Cette conception garde les pixels des jeux de données localement sans prétendre que tous les artefacts restent locaux.

Avant de considérer la documentation actuelle sur Ultralytics Platform On Premise comme une mesure de conformité, vérifie qu’elle répond aux exigences de l’organisation.

Comparer la mise à l’échelle et la fiabilité#

Les plateformes gérées peuvent réduire le travail nécessaire pour augmenter la capacité des points de terminaison, mais la mise à l’échelle automatique n’est pas instantanée et chaque service a ses limites. Mesure les démarrages à froid, le comportement des files d’attente et la capacité disponible dans la région requise.

La mise à l’échelle d’un système auto-hébergé nécessite une ingénierie réfléchie. L’équipe décide comment empaqueter les modèles, répartir les requêtes, planifier l’utilisation des GPU et gérer les défaillances d’un nœud. Kubernetes peut aider à coordonner cette infrastructure, mais ne détermine ni le nombre de réplicas adapté, ni la stratégie de déploiement, ni l’objectif de latence.

Pour les flottes de périphériques, la fiabilité ne se limite pas à la disponibilité des points de terminaison. Les appareils peuvent perdre la connectivité, fonctionner avec différentes révisions matérielles et manquer des mises à jour. Un plan de production doit prévoir la gestion des versions de modèles, les déploiements progressifs, le retour à une version précédente et un moyen de diagnostiquer les défaillances sans se rendre sur chaque site.

Trois modèles de déploiement pratiques#

Entraînement géré et inférence gérée#

Choisis ce modèle si l’équipe veut passer le plus rapidement possible d’un jeu de données à un point de terminaison et si la latence du cloud est acceptable. Il réduit au minimum la gestion de l’infrastructure et convient aux projets pilotes, aux outils internes et aux services dont la demande varie.

Les principaux contrôles portent sur les limites de coûts, le traitement des données par région, l’accès aux points de terminaison et une possibilité d’export si le service doit être déplacé ultérieurement.

Entraînement géré et inférence auto-hébergée#

Choisis ce modèle si le calcul dans le cloud simplifie le développement des modèles, mais que l’inférence doit s’exécuter localement. Entraîne et évalue le modèle dans l’environnement géré, exporte un modèle testé, puis déploie-le à la périphérie ou dans le centre de données.

Ce modèle est courant dans l’industrie manufacturière et la robotique, car l’itération des modèles bénéficie du calcul géré, tandis que les décisions de production ne peuvent pas dépendre d’un aller-retour réseau.

Données et entraînement locaux avec des outils de gestion du cycle de vie gérés#

Choisis ce modèle lorsque les données sources doivent rester sur une infrastructure contrôlée, mais que l’équipe souhaite tout de même disposer d’une interface partagée pour l’annotation, les métriques et la gestion des modèles. Ultralytics Platform On Premise est conçu pour cette répartition : les pixels des jeux de données et les ressources de calcul pour l’entraînement restent sur l’ordinateur connecté, tandis que certaines métadonnées, les métriques et le point de contrôle final sont reliés à la Platform.

Décris clairement les limites dans la documentation opérationnelle. Précise ce qui reste local, ce qui est téléversé et quels flux de travail dans le cloud traitent les images soumises séparément.

Un parcours décisionnel pour les charges de travail courantes#

Inspection en usine. Privilégie l’inférence locale ou en périphérie lorsque le résultat doit arrêter ou détourner une pièce à la vitesse de la ligne. L’entraînement géré peut rester pertinent.

Analyse dans le commerce de détail ou les bâtiments. Utilise un prétraitement en périphérie si la vidéo en continu complique la gestion de la bande passante ou de la confidentialité. Envoie des événements ou des images sélectionnées vers le cloud lorsque c’est pertinent.

Analyse d’images par lots. Le cloud géré convient souvent lorsque la latence n’a pas besoin d’être interactive et que les tâches arrivent par vagues.

Sites isolés du réseau ou connectés de manière intermittente. Héberge toi-même l’environnement d’exécution complet nécessaire à l’inférence et aux opérations. N’intègre pas un plan de contrôle cloud au chemin critique.

API de vision destinée aux développeurs. Les points de terminaison gérés peuvent réduire le délai de mise en service, surtout lorsque le trafic est incertain. Définis les limites des requêtes, l’observabilité et une solution de sortie avant que le volume n’augmente.

Prévoir la sortie avant le déploiement#

La portabilité ne se prouve pas en téléchargeant un fichier de modèle. Teste l’ensemble du processus :

1. Exporte le modèle dans un environnement d’exécution pris en charge par le matériel cible.
2. Reproduis le prétraitement et le post-traitement en dehors du service d’origine.
3. Vérifie la parité des résultats sur un jeu de test fixe.
4. Recrée les procédures de surveillance, de contrôle d’accès et de déploiement progressif.
5. Mesure la latence et l’utilisation des ressources dans l’environnement cible.
6. Documente les déplacements des données, des étiquettes, des versions de modèles et des journaux d’audit.

Cet exercice améliore aussi le déploiement actuel. Il révèle les dépendances cachées avant qu’une panne, une modification tarifaire ou une nouvelle exigence relative aux données n’impose une migration précipitée.