Maison  >  Article  >  Périphériques technologiques  >  Un article pour comprendre le processus de mise en œuvre de la plateforme d'IA native Wuyun-KubeAI

Un article pour comprendre le processus de mise en œuvre de la plateforme d'IA native Wuyun-KubeAI

王林
王林avant
2023-04-12 11:34:111818parcourir

1. Avant-propos

Au cours des dernières années, le domaine cloud natif représenté par la technologie des conteneurs a reçu une grande attention et un grand développement. La mise en œuvre de la conteneurisation est jusqu'à présent un moyen important pour les entreprises de réduire les coûts et d'augmenter l'efficacité. le domaine entier est pratiquement terminé. Au cours du processus de conteneurisation, d'une part, les méthodes de déploiement du service et d'exploitation et de maintenance sont passées en douceur du mode ECS précédent au mode de conteneurisation, d'autre part, l'entreprise a réalisé de nombreux gains d'efficacité en termes d'utilisation des ressources et d'efficacité de la R&D ; .

Dewu est une nouvelle génération de communauté d'achat en ligne tendance. Les moteurs de recherche et les systèmes de recommandation personnalisés basés sur l'IA et la technologie du Big Data sont de solides supports pour le développement commercial, de sorte que les applications dans le domaine des algorithmes représentent une grande proportion des applications commerciales. Au cours du processus de conteneurisation, compte tenu des différences entre le processus de R&D des services d'application d'algorithmes et des services ordinaires, et sur la base d'une enquête approfondie sur les besoins des étudiants en R&D dans le domaine de l'algorithme, nous avons construit la plateforme d'IA native Dewu Cloud-plateforme KubeAI pour le Scénarios R&D dans le domaine des algorithmes. Après une itération continue des fonctions et une expansion continue des scénarios pris en charge, KubeAI prend actuellement en charge les domaines commerciaux impliquant des capacités d'IA tels que les CV, les recommandations de recherche, les algorithmes de contrôle des risques et l'analyse des données, et a terminé avec succès la conteneurisation, améliorant ainsi l'utilisation des ressources et l'efficacité de la R&D. les améliorations ci-dessus ont donné de bons résultats. Cet article amènera tout le monde à comprendre le processus de mise en œuvre de KubeAI.

2. Promotion de la conteneurisation des activités d'IA

2.1 Processus de développement de modèles d'algorithmes d'IA

Les activités d'IA sont davantage un processus de développement itératif de modèles. Habituellement, le processus de développement de modèles peut être résumé dans les étapes suivantes :

Un article pour comprendre le processus de mise en œuvre de la plateforme dIA native Wuyun-KubeAI

Déterminer. le scénario de demande : quel est le problème à résoudre dans ce processus, quel scénario la fonction est-elle prévue, quelle est l'entrée de la fonction/service et quelle est la sortie ? Par exemple : quelle marque de chaussures doit être identifiée ou dont la qualité doit être inspectée, quelles sont les caractéristiques du produit de la marque, quelles sont les dimensions des caractéristiques de l'échantillon, les types de caractéristiques, etc. Différents scénarios ont des exigences différentes en matière d'échantillons de données et d'algorithmes de traitement utilisés.

Préparation des données : selon les résultats de l'analyse de la demande du scénario, obtenez des échantillons de données par diverses méthodes (en ligne/hors ligne/simulé, etc.) et effectuez le nettoyage, l'étiquetage et d'autres opérations nécessaires sur les données. Ce processus constitue la base du développement commercial de l’IA, car tous les processus ultérieurs sont exécutés sur la base de données.

Déterminez l'algorithme et rédigez le script de formation : sur la base de la compréhension des objectifs commerciaux, dans ce lien, les étudiants en algorithme sélectionneront l'algorithme approprié et rédigeront le script de formation modèle en fonction de l'expérience passée ou en fonction de la recherche sur scène et de l'expérimentation. résultats.

Formation du modèle : pour le modèle d'algorithme, nous pouvons le comprendre comme une formule mathématique complexe. Il y aura de nombreux paramètres dans cette formule, tout comme w et b dans f(x)=wx+b. La formation est le processus d'utilisation d'une grande quantité d'échantillons de données pour trouver des paramètres optimaux afin de donner au modèle un taux de reconnaissance élevé. La formation des modèles est une partie très importante du processus de développement commercial de l'IA. On peut dire que la réalisation des objectifs commerciaux dépend de la précision du modèle. Par conséquent, ce lien nécessite plus de temps, d’énergie et de ressources que les autres liens, et nécessite une formation expérimentale répétée afin d’obtenir la meilleure précision du modèle et de prédiction. Ce processus n'est pas un événement ponctuel, mais cyclique en fonction de la mise à jour des scénarios métiers et des mises à jour des données, il doit être effectué périodiquement. Pour le développement et la formation de modèles d'algorithmes, il existe certains moteurs d'IA grand public parmi lesquels choisir dans l'industrie, tels que TensorFlow, PyTorch, MXNet, etc. Ces moteurs peuvent fournir un certain degré de prise en charge des API pour permettre aux développeurs d'algorithmes de distribuer des modèles complexes. . formation, ou effectuer quelques optimisations pour le matériel afin d'améliorer l'efficacité de la formation du modèle. Le résultat de la formation du modèle est d'obtenir le fichier modèle. Le contenu de ce fichier peut être compris comme la sauvegarde des paramètres du modèle.

Évaluation du modèle : afin d'éviter le sous-ajustement du modèle en raison d'un écart excessif ou le surajustement dû à une variance excessive, certains indicateurs d'évaluation sont généralement nécessaires pour guider les développeurs dans l'évaluation de la capacité de généralisation du modèle. Certains indicateurs d'évaluation couramment utilisés, tels que : la précision, le taux de rappel, la courbe ROC/AUC, la courbe PR, etc.

Déploiement du modèle : après une formation et une évaluation répétées, un modèle idéal peut être obtenu pour aider l'entreprise à traiter les données en ligne/de production. Cela nécessite que le modèle soit déployé sous la forme d'un service ou d'une tâche pour atteindre l'objectif d'accepter des données d'entrée et de donner des résultats d'inférence. Nous appelons ce service un service de modèle. Le service de modèle est un script de service en ligne qui charge le modèle une fois prêt, il effectue des calculs d'inférence sur les données prétraitées.

Après le lancement d'un service modèle, le service modèle devra être itéré en raison des changements dans les caractéristiques des données, des mises à niveau des algorithmes, des mises à niveau des scripts du service d'inférence en ligne, des nouvelles exigences commerciales pour les indicateurs d'inférence, etc. Il convient de noter que ce processus itératif peut nécessiter un recyclage et une réévaluation du modèle ; il peut également s'agir simplement d'une mise à niveau itérative du script du service d'inférence.

2.2 La migration vers la conteneurisation bat son plein

Depuis l'année dernière, nous avons progressivement favorisé la mise en œuvre de la conteneurisation des services aux entreprises dans divers domaines de Dewu. Afin de réduire les changements dans les habitudes de fonctionnement des utilisateurs causés par les changements dans les méthodes de déploiement au cours du processus de conteneurisation, nous continuons à utiliser le processus de déploiement de la plate-forme de publication pour masquer les différences entre le déploiement de conteneurs et le déploiement ECS.

Dans le processus CI, différents modèles de compilation et de construction sont personnalisés en fonction des différents types de langage de développement. De la compilation du code source à la production d'images de conteneur, il est complété uniformément par la couche de plate-forme de conteneur, ce qui résout le problème des étudiants R&D ordinaires qui le font. Je ne comprends pas les connaissances liées au conteneur. Le problème de ne pas pouvoir transformer le code du projet en image de conteneur. Au cours du processus CD, nous effectuons une gestion hiérarchique des configurations au niveau du type d'application, au niveau de l'environnement et au niveau du groupe d'environnements. Lors de l'exécution du déploiement, nous fusionnons la configuration multicouche dans le fichier Values.yaml de Helm Chart et soumettons le fichier d'orchestration au fichier d'orchestration. cluster de conteneurs. Les utilisateurs doivent uniquement définir les variables d'environnement correspondantes en fonction de leurs besoins réels, soumettre le déploiement, puis obtenir l'instance de cluster d'application (instance de conteneur, similaire à l'instance de service ECS).

Pour l'exploitation et la maintenance des clusters d'applications, la plate-forme de conteneur fournit la fonction de connexion à l'instance de conteneur via WebShell, tout comme la connexion à l'instance ECS, ce qui est pratique pour dépanner les problèmes liés au processus d'application ; fournit également des fonctions de téléchargement et de téléchargement de fichiers, de redémarrage d'instance et de fonctions d'exploitation et de maintenance telles que la reconstruction et la surveillance des ressources.

Les entreprises d'IA (CV, recherche et recommandation, services d'algorithmes de contrôle des risques, etc.), en tant qu'entreprise relativement importante, participent au processus de conteneurisation avec les services commerciaux ordinaires. Nous avons progressivement complété le flux en cascade et la position en diamant des communautés et. transactions. Migration de services représentant des scénarios de base. Après la conteneurisation, l'utilisation des ressources de l'environnement de test a été considérablement améliorée, l'environnement de production a également été considérablement amélioré et l'efficacité d'exploitation et de maintenance a doublé.

2.3 Les étudiants en algorithme ne peuvent pas supporter la douleur

Le processus de conteneurisation de Dewu s'accompagne du développement rapide du système technologique de l'entreprise, ce qui impose davantage d'exigences à la conteneurisation pour le processus de recherche et de développement de services d'IA immature qui se concentrait à l'origine uniquement sur. Avec la conteneurisation des services d'inférence en ligne, nous avons constaté les problèmes et les difficultés rencontrés par les étudiants en algorithme dans le processus de développement de modèles.

Un article pour comprendre le processus de mise en œuvre de la plateforme dIA native Wuyun-KubeAI

Pain point 1 : La gestion du modèle et la gestion du service d'inférence sont incohérentes. La plupart des modèles de CV sont formés sur des ordinateurs de bureau, puis téléchargés manuellement sur OSS, puis l'adresse du fichier modèle sur OSS est configurée sur le service d'inférence en ligne. La plupart des modèles Soutui sont formés sur PAI, mais sont également stockés manuellement sur OSS et sont similaires au CV lors de leur sortie. On peut constater que la gestion du produit modèle est incohérente dans le processus de formation et de publication du modèle. Il est impossible de suivre sur quels services un modèle est déployé, et il est impossible de voir intuitivement sur quel service un service est déployé. Ou bien il existe plusieurs modèles et la gestion des versions de modèles n’est pas pratique.

Point problématique 2 : la préparation de l'environnement de développement du modèle prend beaucoup de temps et il y a un manque de flexibilité dans l'application et l'utilisation des ressources. Avant la conteneurisation, les ressources étaient généralement fournies sous la forme d'instances ECS. Vous deviez suivre le processus de demande de ressources. Après avoir postulé, vous deviez effectuer divers travaux d'initialisation, installer des logiciels, installer des dépendances et transférer des données (la plupart du temps). les bibliothèques de logiciels utilisées dans les travaux de recherche sur les algorithmes sont de grande taille), l'installation est également plus compliquée). Après l’installation d’un ECS, si les ressources s’avèrent insuffisantes par la suite, vous devez postuler à nouveau et recommencer le même processus, ce qui est inefficace. Dans le même temps, l’utilisation des ressources est soumise à des contraintes de quotas (budget) et manque d’un mécanisme de gestion autonome et d’application flexible et de libération à la demande.

Point problématique 3 : Il est difficile d'essayer certaines solutions modèles prises en charge par le cloud natif. Alors que la technologie cloud native continue d'être mise en œuvre dans divers domaines, des solutions telles que Kubeflow et Argo Workflow offrent un bon support pour les scénarios d'IA. Par exemple : tfjob-operator peut gérer des tâches de formation distribuées basées sur le framework TensorFlow sous forme de CRD. Les utilisateurs n'ont qu'à définir les paramètres des composants correspondants (Chief, PS, Worker, etc.) avant de soumettre les tâches de formation à Kubernetes. grappe. Avant la conteneurisation, si les étudiants en algorithmie voulaient essayer cette solution, ils devaient connaître et maîtriser Docker, Kubernetes et d'autres connaissances liées aux conteneurs, et ne pouvaient pas utiliser cette fonctionnalité en tant qu'utilisateur ordinaire.

Point difficile 4 : lorsque les départements non-algorithmes souhaitent vérifier rapidement un algorithme, ils ne trouvent pas de plate-forme capable de bien le prendre en charge. Les capacités de l'IA sont évidemment utilisées dans divers domaines commerciaux, en particulier certains algorithmes matures. Les équipes commerciales peuvent facilement les utiliser pour effectuer des prédictions d'indicateurs de base ou des prédictions de classification afin d'aider l'entreprise à obtenir de meilleurs résultats. À l'heure actuelle, il est nécessaire de disposer d'une plate-forme capable de fournir des capacités liées à l'IA pour répondre aux besoins de ces scénarios en matière de ressources hétérogènes (CPU/GPU/stockage/réseau, etc.) et de gestion de modèles d'algorithmes, et de fournir aux utilisateurs une solution prête à l'emploi. -fonctions à utiliser.

Basé sur le examen et l'analyse des points faibles et des problèmes difficiles ci-dessus, et sur la base d'autres exigences pour la plate-forme de conteneurs avancées par les étudiants en algorithme pendant le processus de conteneurisation (telles que : exigences de gestion unifiée pour les modèles, exigences de collecte de journaux, pool de ressources exigences, exigences de persistance des données, etc. ), nous avons discuté et résolu chacun un par un. Tout en résolvant les problèmes actuels, nous avons également examiné la planification fonctionnelle à long terme de la plateforme et avons progressivement construit une solution de plateforme KubeAI basée sur le conteneur. plateforme et orienté vers le business de l'IA.

3. Solution de plate-forme KubeAI

Basée sur une recherche et une étude approfondies de l'architecture de base et de la forme de produit de la plate-forme d'IA de l'industrie, en se concentrant sur le scénario commercial de l'IA et ses besoins commerciaux environnants, l'équipe de technologie des conteneurs est en train de conteneurisation Conception et mise en œuvre progressive de la plateforme d'IA cloud-native-KubeAI. La plate-forme KubeAI se concentre sur la résolution des besoins des étudiants en algorithmique, en fournissant les modules fonctionnels nécessaires tout au long des processus de développement, de publication, d'exploitation et de maintenance du modèle, en aidant les développeurs d'algorithmes à obtenir et à utiliser rapidement et de manière rentable les ressources de l'infrastructure d'IA, et à exécuter des algorithmes rapidement et efficacement. efficacement. Conception, développement et expérimentation de modèles.

3.1 Architecture globale

Un article pour comprendre le processus de mise en œuvre de la plateforme dIA native Wuyun-KubeAI

La plateforme KubeAI fournit les modules fonctionnels suivants tout au long du cycle de vie du modèle :

Gestion des ensembles de données : principalement pour la compatibilité avec différentes sources de données, et fournit également des capacités d'accélération de la mise en cache des données.

Formation de modèles : il fournit non seulement Notebook pour le développement et la formation de modèles, mais prend également en charge la gestion de tâches ponctuelles/périodiques dans ce processus, les ressources hétérogènes (CPU/GPU/stockage) sont appliquées et libérées de manière élastique ;

Gestion des modèles : gestion unifiée des métadonnées du modèle (informations de base sur le modèle, liste des versions, etc.), connectée de manière transparente aux versions de service du modèle et aux processus d'exploitation et de maintenance.

Gestion du service d'inférence : dissocie le modèle du code d'inférence, éliminant ainsi le besoin de regrouper le modèle dans l'image, ce qui améliore l'efficacité des mises à jour du service d'inférence ; prend en charge les mises à niveau de modèle pour les services en ligne.

Moteur AI-Pipeline : prend en charge l'organisation des tâches de manière pipeline pour répondre aux besoins d'analyse des données, de modélisation des tâches de formation de routine périodiques, d'itération du modèle et d'autres scénarios.

La plateforme KubeAI prend non seulement en charge les utilisateurs individuels, mais prend également en charge les utilisateurs de la plateforme. Les développeurs individuels utilisent le Notebook de KubeAI pour développer des scripts de modèle. Les modèles plus petits peuvent être formés directement dans le Notebook, et les modèles complexes peuvent être formés via des tâches. Une fois le modèle produit, il est géré uniformément sur KubeAI, y compris sa publication en tant que service d'inférence et l'itération des nouvelles versions. La plate-forme commerciale tierce obtient les capacités de KubeAI via OpenAPI pour l'innovation commerciale de couche supérieure.

Ci-dessous, nous nous concentrons sur les fonctions des quatre modules de gestion des ensembles de données, de formation des modèles, de gestion des services de modèles et du moteur AI-Pipeline.

3.2 Gestion des ensembles de données

Après le tri, les données utilisées par les étudiants en algorithme sont soit stockées dans le NAS, lues depuis ODPS ou extraites de OSS. Afin d'unifier la gestion des données, KubeAI s'appuie sur les ressources Kubernetes PVC (Persistent Volume Claim) pour fournir aux utilisateurs la notion d'ensembles de données et est compatible avec différents formats de sources de données. Dans le même temps, afin de résoudre le problème de la surcharge élevée d'accès aux données causée par la séparation de l'architecture informatique et de stockage, nous utilisons Fluid pour configurer un service de cache pour l'ensemble de données. Les données peuvent être mises en cache localement pour le prochain cycle de données. des calculs itératifs ou des tâches peuvent être planifiées. L'ensemble de données a été mis en cache sur le nœud informatique.

Un article pour comprendre le processus de mise en œuvre de la plateforme dIA native Wuyun-KubeAI

3.3 Formation de modèles

Pour la formation de modèles, nous effectuons principalement trois aspects du travail :

(1) Basé sur JupyterLab, il fournit une fonction Notebook. Les utilisateurs peuvent utiliser un shell ou un IDE Web pour équivaloir au mode de développement local. nos travaux de développement de modèles d'algorithmes.

(2) La formation sur modèle est effectuée sous forme de tâches, qui peuvent demander et libérer des ressources de manière plus flexible, améliorer l'utilisation des ressources et réduire considérablement le coût de la formation sur modèle. Grâce à la bonne évolutivité de Kubernetes, divers CRD TrainingJob du secteur peuvent être facilement connectés et des cadres de formation tels que Tensorflow, PyTorch et xgbost peuvent tous être pris en charge. Les tâches prennent en charge la planification par lots et les files d'attente prioritaires.

(3) Coopération avec l'équipe d'algorithmes pour optimiser partiellement le cadre de formation Tensorflow et obtenu quelques améliorations dans l'efficacité de la lecture des données par lots et la vitesse de communication entre PS/Workers dans des problèmes tels que le déséquilibre de charge PS et les travailleurs lents, etc. solutions.

3.4 Gestion des services de modèles

Par rapport aux services ordinaires, la plus grande caractéristique des services de modèles est que le service doit charger un ou plusieurs fichiers de modèle. Au début de la conteneurisation, pour des raisons historiques, la plupart des services de modèles CV regroupaient directement les fichiers de modèle et les scripts d'inférence dans des images de conteneurs, ce qui entraînait des images de conteneurs relativement volumineuses et des mises à jour fastidieuses des versions de modèles.

KubeAI modifie le problème ci-dessus. Sur la base de la gestion standardisée du modèle, le service de modèle est associé au modèle via la configuration lors de la publication, la plateforme extraira le fichier de modèle correspondant en fonction de la configuration du modèle pour le chargement par le script d'inférence. Cette méthode réduit la pression exercée sur les développeurs de modèles d'algorithmes pour gérer les images/versions du service d'inférence, réduit la redondance du stockage, améliore l'efficacité de la mise à jour/restauration des modèles, améliore le taux de réutilisation des modèles et aide les équipes d'algorithmes à gérer plus facilement et plus rapidement les modèles et leurs associés en ligne. services d'inférence.

3.5 AI-Pipeline Engine

Le scénario commercial réel ne sera pas un nœud de tâche unique. Par exemple, un processus complet d'itération de modèle comprend approximativement des liens de traitement de données, des liens de formation de modèles, l'utilisation de nouveaux modèles pour mettre à jour les services d'inférence en ligne et de petits. Lien de vérification du trafic et lien de sortie officiel. La plate-forme KubeAI fournit un moteur d'orchestration de flux de travail basé sur les nœuds Argo Workflow prenant en charge les tâches personnalisées, les tâches de modèle prédéfinies de la plate-forme et diverses tâches de formation d'IA d'apprentissage en profondeur (TFJob, PyTorchJob, etc.).

Un article pour comprendre le processus de mise en œuvre de la plateforme dIA native Wuyun-KubeAI

4. Cas typiques de scénarios commerciaux d'IA implémentés sur KubeAI

4.1 Processus de développement de modèles d'algorithmes CV

Un article pour comprendre le processus de mise en œuvre de la plateforme dIA native Wuyun-KubeAI

Le mode de développement du modèle d'algorithme CV consiste généralement à étudier les algorithmes théoriques tout en développant des modèles d'algorithmes de pratique d'ingénierie. à tout moment. Étant donné que les modèles sont généralement plus petits, le coût de formation est inférieur à celui des modèles de recherche et de poussée, de sorte que les étudiants CV sont plus habitués à se former directement dans le Notebook après avoir développé le script de formation dans le Notebook. Les utilisateurs peuvent choisir et configurer indépendamment des ressources telles que le processeur, la carte GPU et le disque de stockage réseau pour Notebook.

Une fois que le script de formation répond aux besoins grâce au développement et au débogage, les utilisateurs peuvent utiliser la fonction de gestion des tâches fournie par KubeAI pour configurer le script de formation en tant que tâche de formation autonome ou tâche de formation distribuée, et le soumettre à la plateforme KubeAI pour exécution. La plate-forme planifiera l'exécution de la tâche dans un pool de ressources avec suffisamment de ressources. Après une opération réussie, le modèle sera poussé vers l'entrepôt de modèles et enregistré dans la liste des modèles de KubeAI ou le modèle sera enregistré dans un emplacement désigné pour que les utilisateurs puissent le créer ; sélections et confirmations.

Une fois le modèle généré, les utilisateurs peuvent directement déployer le modèle en tant que service d'inférence dans la gestion des services de modèles de KubeAI. Lorsqu'une nouvelle version du modèle est produite ultérieurement, les utilisateurs peuvent configurer une nouvelle version du modèle pour le service d'inférence. Ensuite, selon que le moteur d'inférence prend en charge la mise à jour à chaud du modèle, vous pouvez terminer la mise à niveau du modèle dans le service d'inférence en redéployant le service ou en créant une tâche de mise à niveau du modèle.

Dans le scénario commercial d'identification de machine, le processus ci-dessus est orchestré via le flux de travail AI-Pipeline et les itérations du modèle sont effectuées périodiquement, augmentant l'efficacité des itérations du modèle d'environ 65 %. Une fois la scène CV connectée à la plate-forme KubeAI, la méthode de formation locale précédente est abandonnée et la méthode flexible d'acquisition de ressources à la demande sur la plate-forme améliore considérablement l'utilisation des ressources en termes de gestion des modèles, de gestion des services d'inférence et d'itération du modèle ; L'efficacité de la R&D est améliorée d'environ 50 %.

4.2 La tâche de formation du modèle de recherche et de poussée est migrée de PAI vers la plateforme KubeAI

Par rapport au modèle CV, le coût de formation du modèle de recherche et de poussée est plus élevé, ce qui se reflète principalement dans le grand échantillon de données, le long temps de formation, et la grande quantité de ressources nécessaires pour une seule tâche. Avant le lancement de KubeAI, puisque nos données étaient stockées sur ODPS (une solution d'entrepôt de données fournie par Alibaba General Computing Platform, désormais renommée MaxCompute), la plupart des étudiants en algorithmes de recherche et de push étaient dans Dataworks (big data basé sur les données de Build). tâches de traitement sur la console de la plateforme de gestion du développement) et soumettre des tâches de formation de modèles à la plateforme PAI. Cependant, étant donné que PAI est un produit de cloud public, le coût d'une seule tâche qui lui est soumise est supérieur au coût des ressources requises par la tâche elle-même. La partie la plus élevée peut en fait être comprise comme des frais de service technique en plus de ce type de service public ; Le produit cloud a Les besoins internes de contrôle des coûts de l'entreprise ne sont pas non plus satisfaits.

Un article pour comprendre le processus de mise en œuvre de la plateforme dIA native Wuyun-KubeAI

Après la mise en œuvre progressive de KubeAI, nous migrerons progressivement les tâches de formation des modèles de scénarios de recherche et de push sur PAI vers notre plateforme de deux manières. La méthode 1 consiste à maintenir l'habitude de l'utilisateur de travailler dans Dataworks, tout en effectuant certaines tâches SQL dans Dataworks, puis à soumettre les tâches à la plate-forme KubeAI via des commandes shell ; la méthode 2 permet aux utilisateurs de soumettre des tâches directement à la plate-forme KubeAI. Nous espérons qu'à mesure que l'infrastructure de l'entrepôt de données s'améliorera, nous passerons progressivement à la deuxième méthode.

Le processus de développement de tâches de formation modèles de Soutui utilise pleinement l'environnement de développement et les outils fournis par KubeAI. Grâce au projet de formation auto-développé Framwork, lorsque vous utilisez uniquement le CPU, le temps de formation peut être le même que celui de l'utilisation de la formation GPU sur PAI ; le côté moteur de formation prend également en charge la formation de grands modèles et les scénarios de formation en temps réel, et coopère avec plusieurs types. de solution de stockage (OSS/stockage de fichiers) et de distribution de modèles pour garantir le taux de réussite des tâches de formation de modèles volumineux et effectuer efficacement les mises à jour de modèles vers les services en ligne.

En termes de planification et de gestion des ressources, KubeAI utilise pleinement la fédération de clusters, le mécanisme de survente, le regroupement de tâches et d'autres moyens techniques pour transformer progressivement l'utilisation de pools de ressources dédiés pour les tâches de formation en allouant des ressources élastiques aux pods de tâches et en les planifiant pour Pools de ressources en ligne. Exploitez pleinement les caractéristiques de l'exécution périodique des tâches de production et des principales tâches de développement au cours de la journée, et mettez en œuvre une planification décalée et différenciée (par exemple, en utilisant des ressources élastiques pour les petites tailles et des ressources régulières pour les grandes tailles, etc.). À en juger par les données des derniers mois, nous avons pu continuer à entreprendre une augmentation plus importante des tâches alors que l'augmentation totale des ressources n'a pas beaucoup changé.

4.3 Scénario de prédiction d'indicateur de base

Un article pour comprendre le processus de mise en œuvre de la plateforme dIA native Wuyun-KubeAI

Il s'agit d'un scénario commercial non algorithmique typique utilisant les capacités de l'IA. Par exemple, utilisez l'algorithme du prophète de Facebook pour prédire une certaine référence d'indicateur commercial. KubeAI fournit des capacités d'IA de base pour les besoins de ces scénarios, résolvant ainsi leur problème de « difficulté à vérifier rapidement les algorithmes matures ». Les utilisateurs doivent simplement implémenter le modèle d'algorithme de manière technique (en utilisant les meilleures pratiques existantes ou un développement secondaire), puis créer une image de conteneur, soumettre une tâche sur KubeAI, démarrer l'exécution et obtenir les résultats souhaités ou effectuer périodiquement une formation et une inférence ; obtenir des résultats de prédiction de base.

Les utilisateurs peuvent configurer à la demande les ressources informatiques nécessaires aux tâches ou autres ressources hétérogènes et les utiliser. Actuellement, en prenant comme exemple 12 indicateurs d'un scénario commercial en ligne, près de 20 000 tâches sont exécutées chaque jour. Par rapport aux coûts de ressources précédents pour des besoins similaires, KubeAI permet d'économiser près de 90 % des coûts et d'améliorer l'efficacité de la R&D de 3 fois environ. .

5. Outlook

Dewu a réussi à conteneuriser son activité en peu de temps, grâce à la technologie cloud native de plus en plus mature et à notre compréhension approfondie de nos propres scénarios commerciaux. des solutions ciblées. La plate-forme KubeAI est basée sur notre analyse approfondie des exigences des scénarios commerciaux algorithmiques, basée sur la façon d'améliorer continuellement l'efficacité de l'ingénierie des scénarios commerciaux d'IA, d'améliorer l'utilisation des ressources et de réduire le seuil de développement de modèles/services d'IA. puis implémentez-le progressivement de manière itérative.

À l'avenir, nous continuerons à travailler dur sur l'optimisation du moteur de formation, la planification raffinée des tâches d'IA et la formation de modèles élastiques pour améliorer encore la formation des modèles d'IA et l'efficacité des itérations et améliorer l'utilisation des ressources.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Déclaration:
Cet article est reproduit dans:. en cas de violation, veuillez contacter admin@php.cn Supprimer