Auteur : Chu Xingjuan
L'image ci-dessus provient du déploiement du SD basé sur le calcul fonctionnel pour obtenir des effets de lumière et d'ombre.
Avant-propos :
Le sans serveur a connu des hauts et des bas au fil des années de développement en Chine, et il est maintenant de retour aux yeux du public. De nombreuses entreprises sont très intéressées, certaines ont commencé à l'appliquer à grande échelle, d'autres sont impatientes de le mettre réellement en œuvre dans l'environnement de production.
Dans le même temps, dans la vague actuelle de technologie AIGC, comment mieux combiner Serverless avec AIGC pour exercer une plus grande valeur ?
Avec ces questions à l'esprit, les journalistes d'InfoQ se sont entretenus avec Yang Haoran, responsable de la R&D intelligente sans serveur d'Alibaba Cloud, et Sun Wei, responsable du serveur AutoNavi, pour discuter du type d'imagination qui peut être inspiré par la combinaison de Serverless et d'AIGC ?
Nouveaux développements sans serveur
Question 1 : Depuis l'accent mis l'année dernière sur le sans serveur, quels progrès Alibaba Cloud a-t-il réalisés en matière de technologie sans serveur au cours des six derniers mois ?
Yang Haoran : En 2022, Alibaba Cloud a présenté une vision très claire du sans serveur, estimant que le sans serveur est la prochaine étape du cloud computing, et Alibaba Cloud s'est engagé à rendre l'ensemble du système de produits sans serveur. Continuer principalement à se développer dans les directions suivantes :
La première direction est sans serveur du système produit. En 2022, les bases de données auront entièrement adopté la forme sans serveur, et cette année, davantage de services middleware deviendront progressivement sans serveur, y compris les centres d'enregistrement et les passerelles de microservices traditionnels. Dans le même temps, les middlewares de messages fourniront également des formulaires de produits sans serveur.
La deuxième direction est de permettre une intégration plus détaillée des services cloud via Serverless . L'objectif ultime est de faire de ces services des composants atomiques et composables permettant aux développeurs de créer des applications, permettant ainsi aux développeurs d'utiliser des composants prêts à l'emploi pour créer rapidement des applications.
La troisième direction est de continuer à développer les capacités techniques de la plateforme informatique sans serveur elle-même. Cela inclut l’amélioration de la vitesse élastique du calcul des fonctions, du moteur d’application sans serveur SAE et les progrès des GPU sans serveur. En ce qui concerne la forme de conteneurs sans serveur, Alibaba Cloud a lancé une version sans serveur récemment mise à niveau du service de conteneurs, offrant aux développeurs des choix plus riches et une prise en charge complète, des conteneurs aux applications.
Sun Wei : Du point de vue de l'application spécifique de Serverless, permettez-moi d'ajouter trois développements qui me préoccupent.
Premièrement, les produits sans serveur deviennent de plus en plus stables et prennent en charge un déploiement unifié. Dans le même temps, son observabilité et ses performances sont également très bonnes. Les indicateurs d'observation sont riches et l'essence du problème peut être vue intuitivement. En termes de performances, le délai est très faible et n'a aucun impact sur le service lui-même. le temps de démarrage à froid est également constamment optimisé. D'après nos mesures réelles, le passage des services vers Serverless augmentera en effet le temps RT (Response Time) du TP99, avec un délai d'environ 2 millisecondes. Les performances de stabilité sont très bonnes. De la conclusion pratique du passage des transactions vers Serverless, il est possible de rendre l'architecture de transaction sans serveur.
Deuxièmement, les outils et produits écologiques Serverless sont très riches, tels que : le flux des outils de support, les outils d'intégration, etc. Ce que les développeurs doivent vraiment faire, c'est la recherche et le développement d'assembleurs : séparer le code et la configuration, choisir le flux d'outils approprié, adopter le mode BFF (Backend For Frontend) et le combiner avec leur propre framework FaaS (Function as a Service) pour développer, ce qui peut grandement améliorer l'efficacité du travail, réduire les coûts de développement.
Troisièmement, il existe actuellement de nombreux produits prenant en charge le sans serveur. Parmi eux, les produits sans serveur de base de données sont plus attractifs pour AutoNavi. Si toutes les fonctions de la base de données ont été implémentées sans serveur, nous pouvons alors parvenir à une sans serveur complète du front-end au back-end de la base de données, réduisant ainsi considérablement les coûts et atteignant véritablement zéro opération, maintenance et paiement à l'utilisation.
Question 2 : En pratique, quelles difficultés techniques sont encore résolues ?
Sun Wei : Il existe de nombreuses difficultés techniques dans le développement du Serverless, et chaque entreprise explore cet aspect différemment. Chaque entreprise possède son propre cadre qui doit être combiné et invoqué à partir de l'architecture existante. Dans ce processus, pour garantir que votre architecture peut véritablement s'intégrer étroitement aux produits sans serveur, améliorer l'efficacité tout en garantissant la stabilité, vous devrez peut-être apporter quelques modifications au moteur d'exécution ou à l'architecture d'origine.
Yang Haoran : Permettez-moi d'ajouter du point de vue de la plateforme. Le démarrage à froid ou le retard mentionné tout à l'heure constituent en effet un défi relativement important pour le Serverless. L'utilisation des ressources du sans serveur est dynamique, ce qui pose des défis en termes de performances et de stabilité de latence. Résoudre ce problème est également l'une des difficultés techniques qu'Alibaba Cloud va surmonter cette année, c'est-à-dire fournir un délai TP99 très stable. Cela nécessite une optimisation de l'ensemble de la liaison de bout en bout, voire une combinaison de matériel et de logiciels, pour réduire autant que possible le délai de l'ensemble de la liaison. De plus, l'ensemble du système, y compris le système d'exploitation et les conteneurs sécurisés, doit être profondément optimisé et intégré pour maintenir l'exécution des applications d'instance, les fonctions d'instance et la puissance de calcul aussi stables que possible. De plus, sur le GPU, la nouvelle technologie de virtualisation GPU et la technologie élastique comportent également de nombreuses technologies qui doivent être abordées.
Question 3 : Quels types de problèmes les entreprises rencontrent-elles généralement en matière de candidatures ? **
Sun Wei : Chaque entreprise prend des décisions différentes en matière de Serverless et est confrontée à des problèmes différents. Je voudrais partager le problème auquel Amap a commencé à accéder, qui consiste à résoudre le problème "un ensemble de code peut résoudre le problème de l'exécution à plusieurs endroits". L'essentiel se résume en deux mots : « améliorer l'efficacité et réduire les coûts ». Par conséquent, Amap a construit l’échafaudage au début et l’ouvrira plus tard. L'objectif principal de cet échafaudage est de résoudre le problème du coût élevé de l'utilisation directe du sans serveur, afin que l'entreprise ne se soucie que de l'entreprise elle-même sans avoir besoin de gérer le mécanisme d'exploitation sous-jacent. Grâce à cet échafaudage, les applications peuvent être développées plus efficacement et plusieurs services middleware ou d'agrégation peuvent être appelés au sein des fonctions. Scaffolding implémente MQ, les événements, l'orchestration et d'autres fonctions, et prend actuellement également en charge la « base multi-cloud ».
Yang Haoran : Amap a pu investir dans le domaine du serverless dès le début et obtenir des résultats relativement bons. J'observe qu'il y a plusieurs raisons :
Tout d'abord, il s'agit d'une accumulation à long terme dans la conception architecturale de l'ensemble du serveur, y compris la sélection de la langue. Par exemple, l'ensemble de leur pile technologique utilise Go, ce qui est très cohérent avec le concept sans serveur ; deuxièmement, ils ont réalisé de nombreux échafaudages personnalisés pour des scénarios commerciaux afin de promouvoir l'efficacité de la R&D sans serveur. Certaines des implémentations sans serveur que nous voyons aujourd'hui sont principalement basées sur Golang, Node.js, Python et d'autres langages très adaptés au concept cloud natif et peuvent bénéficier de plus d'avantages.
Les capacités internes du cadre de support de R&D d'Alibaba sont relativement complètes.Notre principale direction de travail est de fournir des capacités de support R&D améliorant l'efficacité pour les clients du cloud public, afin que les clients du cloud public puissent utiliser pleinement les capacités du cloud. Et c'est de manière open source, y compris l'ouverture d'outils d'exécution liés à Golang avec Amap. Nous utiliserons une approche plus ouverte pour créer des services de performance R&D pour le sans serveur. Vous verrez certains de nos résultats cette année et opérerez dans un modèle open source et ouvert.
Question 4 : Ces fonctions peuvent-elles également être implémentées dans Knative ? En fait, derrière cela, je veux connaître la différence entre les produits du fabricant et les produits open source ?
Yang Haoran : Cela peut être réalisé. Mais essentiellement, lorsqu’ils parlent de plates-formes sans serveur, les développeurs se concentrent principalement sur le rapport coût-production. Par exemple, les utilisateurs ont plusieurs choix : l'un est basé sur le système Knative+Java, utilise Spring Boot et Spring Cloud framework et fonctionne sur ECS. Dans le scénario des microservices, cet environnement écologique est très complet, mais l'utilisation des ressources manque d'élasticité et il est plus difficile de réduire les coûts par rapport au cloud. Afin de résoudre ce problème, la conteneurisation et la mise à l'échelle élastique en mode HPA peuvent être utilisées.
L'ensemble de la plate-forme sans serveur peut être grossièrement divisé en deux niveaux. La première couche est la couche informatique, qui vise à réaliser une mise à l'échelle élastique rapide des instances, et prend même en charge la mise à l'échelle élastique de 0-N. Dans le cas d’une mise à l’échelle élastique, il est nécessaire de maintenir la stabilité du délai P99, mais cela entraînera des défis systémiques. Actuellement, il n'existe aucun produit correspondant dans le système open source qui puisse résoudre ces défis, mais les plates-formes cloud ou les services cloud peuvent mieux les résoudre car ils peuvent intégrer des systèmes logiciels et matériels et investir plus de ressources dans l'optimisation. Ces coûts d’intrants doivent être partagés par les plates-formes plus grandes afin de rendre le retour sur investissement global plus rentable.
Le deuxième niveau est la couche application, c'est-à-dire le service d'efficacité R&D prenant en charge la gestion des applications et le service d'efficacité R&D. Cela inclut l'intégration de services cloud et de logiciels open source pour fournir aux développeurs des services complets tels que les tests de diagnostic des problèmes, les tests de développement, le diagnostic des problèmes et le déploiement automatisé. L'optimisation dans ce domaine nécessite également beaucoup d'efforts de peaufinage.
À mon avis, tout le monde a la capacité de bien le faire. La clé réside dans la question de savoir si le problème est orienté vers l'entreprise, vers la technologie ou vers la plate-forme. Si l’objectif est axé sur les affaires, la rentabilité de l’action doit être prise en compte. Personnellement, je suis très optimiste quant au sans serveur. Si la valeur de l'amélioration de l'efficacité de la R&D et de la réduction des coûts peut être mieux transmise aux entreprises et aux développeurs, elle deviendra certainement très populaire, car elle correspond aux besoins essentiels des entreprises à vocation commerciale.
Question 5 : À quel stade le Serverless est-il mis en œuvre en Chine ?
Yang Haoran : D'après mon observation, de nombreuses grandes entreprises sont confrontées à des changements rapides et à une croissance rapide de leurs besoins commerciaux. Afin de répondre rapidement à ces exigences commerciales, ces entreprises ont commencé à envisager d'adopter une architecture sans serveur. Cependant, pour que l'architecture sans serveur puisse être utilisée dans la pratique, elle nécessite des services de performance R&D correspondants ainsi que les capacités de performance et de stabilité de la plate-forme elle-même. C’est le principal défi de la mise en œuvre du Serverless.
Une autre question concerne la manière de mettre en œuvre le sans serveur. Je pense que cela doit être pris en compte en fonction de circonstances spécifiques. Pour des produits comme SAE (Serverless Application Engine, produit d'hébergement d'applications extrêmement simple d'utilisation), le principal avantage de ce type de produit réside dans sa flexibilité et ses capacités de différenciation. S'il peut être compatible avec les applications existantes, alors les utilisateurs choisiront Vous ne rencontrerez pas de résistance particulièrement importante lorsque vous le ferez. Par exemple, apporte-t-il plus d’avantages aux utilisateurs en termes de réduction des coûts et d’amélioration de l’efficacité ? Si cela peut être clairement démontré, de nombreuses entreprises seront intéressées et demanderont de tels produits.
À l’heure actuelle, les principales entreprises nationales utilisent le sans serveur sur des liens très essentiels. Cependant, le principal problème est désormais de savoir comment diffuser ces fonctionnalités sur le cloud public de manière open source et ouverte, pour en faire une fonctionnalité universelle, afin qu'un plus grand nombre d'entreprises puissent bénéficier des résultats apportés par Serverless.
Sun Wei : Permettez-moi d'ajouter deux suggestions. Pour les activités frontales, en théorie, Node.js est généralement utilisé pour une adaptation multi-terminal afin de résoudre le problème de l'amélioration de l'efficacité de la R&D frontale, c'est-à-dire que la R&D client et le développement de produits, associés aux tests, peuvent fournir des services de bout en bout. -services finaux.
Pour les activités back-end, il est relativement préférable d’utiliser le langage Go. Dans le même environnement et les mêmes fonctions, le package Java sera plus grand, l'image sera plus grande et le temps de démarrage sera plus long.Cependant, le langage Go peut être lancé rapidement et convient naturellement aux activités back-end. Bien sûr, vous pouvez également envisager d'utiliser le langage Rust, mais le seuil pour Rust est relativement élevé, et pour le front-end, Node.js est généralement utilisé comme langage de fonction de FaaS, tandis que le back-end peut choisir le langage Go. Si plusieurs algorithmes sont impliqués, vous pouvez envisager d'utiliser Python, etc. C++ peut également être une option, mais le principal problème reste le coût plus élevé, et le coût des modèles est également plus élevé. Dans tous les cas, l’essentiel est de faciliter le développement.
En prenant AutoNavi comme exemple, le front-end utilise principalement Node.js, le back-end utilise C++ au niveau de la navigation, Go au niveau fonctionnel et Python est partiellement utilisé au niveau de l'algorithme. Une telle combinaison de plusieurs langues peut mieux répondre aux besoins des entreprises.
Ce qui a changé avec l'AIGC
Question 6 : Quels changements l’AIGC a-t-il apporté au travail quotidien de nos deux enseignants ? AutoNavi et Alibaba Cloud ont-ils fait des tentatives préliminaires ?
Yang Haoran : Je pense que l'AIGC a un impact énorme sur notre travail, ou qu'il aura un impact énorme à l'avenir. En tant que personne travaillant principalement dans le secteur des services, nous devons résoudre les problèmes d'élasticité, de tolérance aux pannes et de commodité de développement des applications cloud natives. Dans le cadre de l'AIGC, je pense qu'à l'avenir, les capacités de l'IA seront publiées sous la forme d'API et étroitement intégrées aux entreprises. Cela nous oblige à combiner efficacement l'évolution de l'activité avec les capacités de l'IA, ce qui est également un objectif du domaine du sans serveur auquel nous avons prêté attention.
D'un autre côté, l'une des manifestations de l'amélioration continue de l'IA est la capacité de génération de code. Nous devons réfléchir à la manière dont l'architecture des applications futures peut mieux s'adapter aux capacités et aux caractéristiques de l'AIGC. Par exemple, si vous disposez d'une application d'architecture monolithique entièrement fonctionnelle, pouvez-vous utiliser les capacités d'AIGC pour développer progressivement des fonctions sur cette architecture monolithique ? Existe-t-il d'autres architectures meilleures qui peuvent tirer pleinement parti des capacités de génération de code d'AIGC pour accélérer le développement global du code et l'efficacité des tests ?
À l’avenir, je pense que les développeurs ou les architectes devront avoir une capacité très importante, à savoir réfléchir à la manière de concevoir une architecture d’application afin qu’elle puisse s’adapter aux capacités de l’IA et mieux utiliser les capacités de l’IA. Que ce soit du point de vue de l’itération fonctionnelle rapide, de la flexibilité architecturale, de la stabilité ou du coût, c’est une question très intéressante qui mérite notre réflexion sur le long terme.
Sun Wei : Je me concentre principalement sur deux aspects.
Du point de vue des affaires et des produits commerciaux, chaque entreprise possède son propre domaine d'expertise. Par exemple, dans le domaine du marketing, vous disposez peut-être de solides capacités professionnelles et votre entreprise est également une société de marketing. Vous réfléchissez peut-être à la manière d'appliquer l'AIGC au domaine du marketing. Bien sûr, vous pourriez être confronté à certains défis, tels que comment utiliser des outils open source pour créer des applications de modèles à grande échelle, comment utiliser des méthodes d'apprentissage en profondeur et plusieurs images pour entraîner des modèles, comment créer des bases de données vectorielles et comment planifier et agréger des modèles. dans des scénarios commerciaux. Il s'agit de combiner l'idée d'une architecture de sérialisation avec l'architecture de services basée sur les API d'AIGC pour créer des applications monolithiques et fournir des services ou des API à d'autres. Les utilisateurs peuvent utiliser pleinement l'AIGC pour optimiser la conception de produits dans le domaine commercial sur la base des connaissances et de l'accumulation dans le domaine commercial.
Pour résumer, je pense qu'il y a trois éléments clés : premièrement, avoir des connaissances très professionnelles dans des domaines métiers, comme les bases de données vectorielles, l'architecture sans serveur, etc. ; deuxièmement, avoir des capacités techniques pour les grands modèles, ce qui peut nécessiter des connaissances en algorithmes ; enfin , C'est le concept commercial de l'architecture sans serveur. En combinant ces trois éléments, vous pouvez regrouper le résultat pour une réalisation commerciale.
Sans serveur+AIGC=？
Question 7 : Il y a un dicton dans l'industrie selon lequel le sans serveur est la prochaine pièce du puzzle AIGC. Pourquoi dit-on cela ? Selon vous, quelles nouvelles imaginations la combinaison avec l’AIGC apportera-t-elle ?
Sun Wei : L'AIGC a en effet laissé beaucoup de place à l'imagination dans diverses industries, couvrant le traitement d'images, le montage vidéo, la génération de texte, le matériel publicitaire, la conception de logos, le service client intelligent et la synthèse vocale. Cependant, un problème majeur existe actuellement est que les grands modèles fournis par la plupart des fabricants sont appelés quantitativement vers le monde extérieur et doivent être appelés via des interfaces API. En raison de la puissance de calcul du fabricant, un appel prend beaucoup de temps et est également soumis à une limite sur le nombre d'appels. Nous en sommes donc encore au stade exploratoire.
Cependant, on suppose que tous les grands modèles (qu'il s'agisse de la série GPT ou d'autres modèles open source) sont vendus et facturés en tant que produits et peuvent être payés sur demande tout en maximisant la solution au problème de puissance de calcul. En outre, des problèmes tels que l’isolement opérationnel et la sécurité du Big Data sont également impliqués. De ce point de vue, Serverless peut être considéré comme la prochaine pièce du puzzle pour résoudre le problème de commercialisation de l’AIGC.
Mon jugement personnel est que ces problèmes avec l'AIGC finiront par être résolus et que de nombreux produits liés à l'AIGC résoudront des problèmes tels que la puissance de calcul et la planification, favorisant ainsi le développement de produits liés à l'AIGC. Si ces produits peuvent être combinés pour effectuer des appels intégrés à l'ensemble du système, de l'ingénierie aux services de terminaux, en passant par les bases de données, les middlewares sous-jacents, l'IA et la puissance de calcul, alors la série entière sera complète.
Yang Haoran : L'adaptation de l'IA à l'architecture des applications et à l'intégration des services est un enjeu important. Pour les applications AIGC, plusieurs aspects peuvent être considérés.
Premièrement, l’architecture logicielle doit s’adapter aux capacités de l’IA. Les anciennes architectures monolithiques « tout-en-un » peuvent exploiter pleinement le potentiel de l'AIGC. Toutefois, les applications basées sur l'IA nécessitent souvent une architecture de microservices plus faiblement couplée pour atteindre un objectif unique et des entrées et sorties claires pour chaque fonction ou microservice. Cette architecture peut améliorer la précision et l'efficacité de la génération de code, mais elle pose également des problèmes de gestion et de débogage. Ce sont en fait les problèmes que l'architecture sans serveur veut résoudre. Je pense que c'est une bonne combinaison de ceux-ci.
Deuxièmement, l'AIGC joue un rôle important dans l'ensemble du processus de candidature. Pendant la phase de développement, nous pouvons utiliser les capacités de génération de code et les outils auxiliaires d'AIGC (tels que GitHub Copilot) pour accélérer les itérations. Pendant la phase de déploiement, des outils d'automatisation tels que l'Infrastructure as Code (IaC) peuvent être utilisés pour déployer rapidement différents services ou ressources cloud afin de répondre aux dépendances des applications. De plus, grâce à des définitions telles que les langages déclaratifs ou YAML, le service IaC sous-jacent peut également exécuter ces fonctionnalités automatiquement, plutôt que d'opérer manuellement sur la console.
Alors, comment Serverless aide-t-il AIGC à mieux mettre en œuvre ? Nous pouvons partir des aspects suivants.
Tout d’abord, en termes de combinaison de logique métier et de capacités d’IA, les applications d’IA peuvent être divisées en deux aspects. D’une part, ce n’est qu’en combinant les capacités de l’IA avec la logique métier qu’une réelle valeur commerciale peut être obtenue. D'un autre côté, les capacités des modèles d'IA sont généralement exposées via des API. À l'instar des applications en ligne, les applications peuvent être rapidement créées en combinant la logique métier avec les capacités des API d'IA. Dans ce cas, il est recommandé d’adopter une architecture faiblement couplée et un concept de développement d’assembly similaire à l’architecture des microservices.
En outre, l’hébergement et la servitisation des modèles d’IA sont également des considérations importantes. La conversion des capacités des modèles d'IA en services API et la fourniture de fonctions telles que la publication et la restauration en niveaux de gris peuvent permettre une utilisation plus efficace des ressources et réduire la complexité. Ce modèle permet de fournir davantage de fonctionnalités de modèle via les API. Je pense que Serverless peut réduire encore cette complexité. Cela permet de libérer davantage de capacités de modèle via l'API.
Enfin, l'itération du modèle et la gestion des versions dans AIGC sont également importantes. En particulier pour les grandes entreprises, il peut être nécessaire de créer des ressources périphériques telles que des bases de données et des bases de connaissances autour de grands modèles, d'effectuer un nettoyage, un affinement et un réglage fin des données, et enfin de les transformer en de nouveaux modèles. Cette implémentation d'itération et de déploiement de versions de manière versionnée nécessite de nombreuses capacités d'ingénierie logicielle. À cet égard, les fournisseurs de logiciels open source et de services cloud travaillent dur pour accroître leurs capacités afin de mieux intégrer les processus complexes et les piles logicielles d'AIGC et de réduire la complexité. Cette intégration est très précieuse pour AIGC et constitue un aspect important de la capacité de Serverless à apporter de la valeur à AIGC.
Question 8 : Serverless est-il utilisé pour déployer des modèles liés à l'AIGC ?
Sun Wei : Il y a deux angles à considérer. Tout d'abord, vous pouvez combiner AIGC avec Serverless. Le sans serveur peut résoudre des problèmes tels que la personnalisation à la demande des services en amont et la protection des ressources informatiques. Dans les situations où une grande quantité de ressources informatiques est consommée et où un dépassement de mémoire se produit en raison de l'exécution simultanée de plusieurs tâches informatiques, vous pouvez déployer sur Serverless et adopter une planification appropriée.
D'un autre côté, si vous souhaitez résoudre le problème des modèles associés, vous devez prendre en compte le nombre de modèles et l'endroit où les déployer. Le sans serveur peut être utilisé lors du déploiement de modèles, ce qui signifie que lorsque vous créez votre propre plate-forme d'algorithmes, vous pouvez concevoir la plate-forme d'algorithmes vous-même. Lorsque vous souhaitez déployer plusieurs modèles ou diviser des modèles, etc., vous pouvez combiner Serverless pour améliorer les performances et l'efficacité. Le sans serveur peut être utilisé à la fois pour la formation et l’automatisation.
En résumé, Serverless peut être utilisé en externe ou en interne. Lorsqu'il est utilisé en externe, il s'agit plutôt d'une boîte noire que vous pouvez interpréter à travers des informations accessibles au public. Lorsqu'il est utilisé en interne, il est principalement utilisé pour améliorer le déploiement de modèles d'algorithmes, la formation itérative automatique, y compris le nettoyage des données, etc. Son utilisation en interne ou en externe dépend du choix personnel, car Serverless en soi est un concept architectural et n'a pas de portée d'utilisation limitée.
Yang Haoran : Du point de vue des concepts architecturaux, nous pouvons discuter plus spécifiquement de la question de savoir si les plates-formes et les services informatiques sans serveur sont adaptés aux modèles d'hébergement. Je pense que ça dépend de la situation. En règle générale, les services informatiques sans serveur conviennent à l’hébergement d’un sous-ensemble de modèles, à savoir ceux capables d’exploiter pleinement l’élasticité du service.
Cependant, pour les modèles plus grands tels que Tongyi Qianwen, ChatGPT ou les versions open source, leurs exigences en ressources informatiques sont très élevées. Dans ce cas, je pense que ce type de modèle n’est peut-être pas adapté à un hébergement sur une plateforme sans serveur. L'hébergement ou non dépend en fin de compte de l'orientation en matière de puissance de calcul et des limites de la plate-forme elle-même.
Question 9 : Quelles sont les caractéristiques des candidatures AIGC ? Comment Serverless aide-t-il les développeurs à développer et déployer des applications AIGC ? De plus, quels autres cas matures ou scénarios d’application existe-t-il pour Serverless+AIGC ?
Yang Haoran : Je pense que les applications AIGC présentent de nombreuses similitudes avec les applications en ligne courantes. Dans de nombreux cas, ils combinent toujours les capacités API du modèle sous-jacent pour implémenter la logique métier. Cependant, pour un type particulier d’application AIGC, il est plus approprié d’utiliser une architecture autonome asynchrone, telle qu’un chatbot ou un framework de développement spécialisé comme LangChain. De nombreux concepts de type agent sont définis dans le framework LangChain. Ces agents interagissent avec l'API du modèle sous-jacent, comme un cerveau, mais doivent effectuer de nombreuses opérations réelles.
Ces opérations pratiques sont véritablement combinées avec des besoins et des scénarios commerciaux réels pour résoudre des problèmes pratiques. Et ces opérations sont en fait des fonctions spécifiques, sont sans état, peuvent effectuer des opérations simples, mais sont très flexibles. Dans ce mode, il est très approprié de les déployer sur des services aux fonctions similaires.
Ainsi, selon nos observations précédentes, les caractéristiques des applications AIGC sont très adaptées au concept d’architecture Serverless. Serverless fournit des outils de développement pour permettre aux clients de convertir plus facilement des modèles en services. Grâce à la plate-forme sans serveur, les utilisateurs n'ont peut-être pas besoin de beaucoup d'expérience en développement, mais ont seulement besoin de comprendre certains détails pour la configurer et l'utiliser rapidement.
J'ai déjà eu une conversation avec un client. C'est un concepteur avec une certaine expérience en développement de code, mais pas en profondeur. Il peut rapidement mettre en place des modèles open source tels que Stable Diffusion sur la plateforme Serverless et finalement obtenir des résultats commerciaux. Il s'agit d'un cas pratique de combinaison d'applications Serverless et AIGC.
Je pense qu'à l'avenir, à mesure que le cadre d'application d'IA représenté par LangChain mûrira, nous verrons de nombreuses applications similaires s'exécuter sur la plate-forme sans serveur, qui est le chemin le plus court.
Sun Wei : L'essence de l'application de l'AIGC est d'améliorer l'efficacité. Qu'il s'agisse de produire du matériel publicitaire, du contenu, des vidéos ou des logos, etc., les applications AIGC utilisent les outils existants pour améliorer l'efficacité et remplacer les coûts de main-d'œuvre traditionnels. De plus, les applications AIGC peuvent également être utilisées pour le traitement des données, notamment l'annotation et le nettoyage des données. L'utilisation de l'AIGC peut atteindre l'objectif principal de l'amélioration de l'efficacité : d'une part, il s'agit d'une amélioration intelligente de l'efficacité et, d'autre part, d'une amélioration de l'efficacité fonctionnelle.
Cependant, lors du déploiement d'AIGC, l'utilisation effective d'une plate-forme sans serveur dépend principalement du scénario prévu et du fait qu'elle soit basée sur des modèles open source ou auto-développés. Pour les applications open source, les défis de l'application doivent être pris en compte ; pour les modèles auto-développés, Serverless doit être utilisé pour l'optimisation et la protection basées sur la consommation.
Lors de l'utilisation spécifique de la plateforme sans serveur pour déployer des applications AIGC, il est nécessaire de considérer de manière exhaustive les scénarios d'utilisation et les défis associés, et d'optimiser en fonction des scénarios prévus. Pour les modèles basés sur l'open source ou auto-développés, la consommation d'énergie de calcul peut être optimisée via la plate-forme sans serveur. Surtout lorsque la consommation de chargement de modèle et de calcul d'IA est importante, l'architecture sans serveur peut être envisagée pour la réécriture. Dans le même temps, l'introduction d'autres vecteurs et la création d'une base de données de vecteurs spécifiques au domaine sur les valeurs d'entraînement peuvent également contribuer à optimiser davantage les applications AIGC.
En divisant l'architecture et en utilisant la plateforme sans serveur pour l'optimisation du développement et du déploiement, les utilisateurs peuvent apporter les améliorations appropriées au niveau du noyau en fonction des besoins de l'entreprise. Il est recommandé que lors de l'utilisation d'un packaging sans serveur, il ne soit pas seulement publié et déployé comme une boîte noire, mais qu'il soit ajusté en fonction des besoins au niveau de l'entreprise ou du noyau.
Il convient de souligner qu’il n’existe actuellement aucun cas AIGC appliqué en ligne à grande échelle. Ceux-ci sont encore au stade exploratoire. Les idées avancées constituent une direction que nous explorons et sont à titre de référence.
Question 10 : Sous la vague de l’IA, comment les services cloud de base ou les services sans serveur reflètent-ils la valeur qu’ils apportent ?
Yang Haoran : Les applications AIGC doivent combiner les capacités de l'IA avec une véritable logique métier. Les services cloud de base tels que les bases de données, le stockage d'objets et les files d'attente de messages sont toujours nécessaires, et l'interaction avec les capacités de l'IA sous-jacentes nécessite généralement l'utilisation d'API. Si ces combinaisons forment naturellement un ensemble de logique métier et de capacités d'IA, alors après avoir été étroitement intégrées à l'architecture globale du service cloud, les développeurs peuvent rapidement combiner ces fonctions pour créer des applications, ce qui correspond parfaitement.
Avec la sans serveur de l'infrastructure des services cloud et l'intégration étroite de l'architecture globale des produits cloud, cela a un énorme effet d'accélération sur le développement d'applications d'IA. Les applications d'IA ne peuvent pas se limiter aux applications en ligne traditionnelles, mais peuvent également utiliser une architecture événementielle ou des cadres de développement rapide comme LangChain pour mettre en œuvre des applications interactives dotées de capacités d'IA.
Logiquement, les applications AIGC peuvent être divisées en deux parties : la logique de prise de décision et les actions d'exécution. La logique de décision implique la capacité de l'IA à prendre des décisions en fonction des entrées, tandis que les actions d'exécution impliquent un code fragmenté tel que l'interaction avec des API tierces, mettant l'accent sur une exécution légère et fiable. Cette capacité d'exécution est idéale pour fonctionner sur des services informatiques sans serveur.
De plus, nous venons de mentionner comment affiner les modèles d'IA en fonction de scénarios commerciaux, et même créer des modèles à grande échelle exclusifs à l'entreprise. Il s’agit d’un processus complexe qui nécessite une pile technologique et une pile logicielle approfondie. À cet égard, de nombreux logiciels open source et produits cloud doivent être intégrés pour permettre aux clients de configurer l'ensemble du pipeline plus rapidement. Des capacités telles que le diagnostic des problèmes sont également très importantes. Par conséquent, l’objectif des services sans serveur est de rendre l’ensemble du système de produits cloud intégré et composable.
Grâce à des outils tels que le workflow, les pipelines peuvent être rapidement orchestrés et les services existants tels que les services de Big Data ou les services d'IA peuvent être combinés avec la logique métier et les processus de traitement des données de l'utilisateur de manière événementielle. De cette manière, les clients peuvent établir un pipeline d'apprentissage adaptatif basé sur leurs propres conditions commerciales, et ces capacités les aideront grandement.
Question 11 : La gamme de produits sans serveur d'Alibaba Cloud a-t-elle apporté les ajustements correspondants en raison de l'AIGC ?
Yang Haoran : Au cours des dernières années de planification et de développement, notre plateforme s'est concentrée sur l'adaptation de diverses fonctions, notamment la correspondance avec les frameworks d'IA open source populaires. Dans le sens du développement de l'ensemble de la plateforme, nous nous efforçons d'être cohérents avec le développement de l'IA. Du point de vue de l'ensemble de la configuration, nous avons commencé à présenter des fonctionnalités telles que GPU et Serverless il y a quelques années, à publier les produits correspondants et à continuer à itérer et à nous améliorer.
Sun Wei : À mon avis, le Serverless est essentiellement un concept architectural. Dans la vague technologique actuelle, je pense que cela a deux valeurs importantes.
Tout d'abord, l'IA présente de nombreux problèmes, tels que la puissance de calcul. En combinant le concept d'architecture orientée services, les produits d'IA peuvent être orientés services, ce qui peut effectivement résoudre le problème de centralisation actuel et réaliser la commercialisation d'un plus grand nombre de produits d'IA. .
Deuxièmement, si l'IA prend en charge la commercialisation et que l'ensemble de l'entreprise prend également en charge la commercialisation, alors grâce à la combinaison de la logique métier et de l'API AIGC, associée à la prise en charge commerciale de l'ensemble de l'algorithme, une prise en charge complète de l'avant à l'arrière peut être obtenue.Par exemple, la réalisation de diverses fonctions comme l'expansion élastique à la demande, l'orchestration de processus basée sur les événements, etc., est la véritable réalisation.
Par exemple, pour une start-up, si elle ne connaît que le front-end, Python, PHP ou Node.js, elle peut également utiliser AIGC, et peut également réaliser diverses tâches telles que le développement d'ingénierie, la fourniture de services, la conception d'interfaces, etc. ., et peut presque tout faire. En fait, Serverless protège tous les détails de la mise en œuvre sous-jacente, de l'ingénierie aux algorithmes en passant par les données et les services, libérant ainsi considérablement l'efficacité. De cette façon, certaines personnes se concentrent sur le développement de bas niveau, et d'autres se concentrent sur le développement de l'ingénierie, et je pense que c'est la fin du futur.
Question 12 : Quel impact l'évolution de la technologie sous-jacente aura-t-elle sur les dernières tendances en matière d'IA, telles que les grands modèles ?
Sun Wei : D'après mes observations, le développement comporte deux aspects principaux.
Tout d’abord, je voudrais parler du caractère inclusif de la puissance de calcul. Dans les deux ou trois prochaines années, la puissance de calcul deviendra de plus en plus populaire. La puissance de calcul constitue effectivement un problème à l’heure actuelle. Avec le développement de la technologie, la puissance de calcul sera en mesure de véritablement résoudre les problèmes de l’IA commerciale à grande échelle et d’être largement utilisée dans tous les domaines, ouvrant ainsi la voie à une ère d’inclusion.
Deuxièmement, je souhaite parler du développement de l'ingénierie technique, qui comprend les applications cloud natives, la servitisation et les bases de données cloud natives susmentionnées. Le développement de ces technologies sous-jacentes favorisera les progrès dans le domaine de la technologie de l’IA. D'avant en arrière, qu'il s'agisse du cœur de l'algorithme, du chargement du modèle ou de la partie formation, ils adopteront le concept d'équité, c'est-à-dire l'intégration des algorithmes, pour favoriser la fonctionnalisation de l'ensemble de l'AIGC ou de l'IA et le rendre plus disponible dans le commerce. En d’autres termes, la recherche et le développement deviendront plus simples grâce à la vulgarisation de la puissance de calcul, de l’IA, de l’ingénierie, du business, du front-end, etc.
Yang Haoran : Je pense que l'évolution de la technologie sous-jacente aura l'impact suivant sur les dernières tendances de l'IA telles que les grands modèles.
Tout d’abord, cela implique la génération et la formation de grands modèles et n’a pas grand-chose à voir avec la servitisation et la virtualisation. La formation de ces grands modèles nécessite généralement des clusters de calcul haute performance, similaires au modèle de calcul haute performance (HPC), qui a des exigences très élevées en matière de bande passante réseau et de performances informatiques. Cependant, une fois ces modèles formés, la manière d'exploiter leurs capacités via des méthodes telles que les API, ou de permettre aux clients de développer rapidement des applications d'IA basées sur ces grands modèles et de générer de la valeur commerciale, est étroitement liée aux technologies connexes telles que le sans serveur ou le cloud natif. Ceci est lié à ce que nous avons mentionné à plusieurs reprises auparavant, je n’entrerai donc pas dans les détails.
Le point clé ici est que l'évolution de la technologie sous-jacente implique non seulement la génération et la formation de modèles à grande échelle, mais inclut également la manière d'appliquer ses capacités à l'entreprise réelle grâce à des technologies telles que la servitisation et le cloud natif pour atteindre les objectifs de développement rapide. développement et réalisation de valeur.
Question 13 : Dans les 3 à 5 prochaines années, quelles autres réformes techniques et explorations approfondies Amap fera-t-il pour le sans serveur ? Comment Alibaba Cloud va-t-il planifier son aménagement face au développement rapide de l'AIGC ?
Yang Haoran : Je comprends que la configuration AIGC d'Alibaba Cloud est très importante, car l'IA et les capacités de grands modèles sont des stratégies essentielles pour Alibaba Cloud. Cela couvre la capacité de la formation de modèles à grande échelle à la capacité de créer des applications avec des modèles à grande échelle comme noyau, qui sont toutes des tâches très importantes pour Alibaba Cloud. Je ne suis pas un expert dans ce domaine, je ne discuterai donc pas de la formation de grands modèles, mais je pense qu'Alibaba Cloud atteindra l'objectif de créer rapidement des applications autour des capacités de grands modèles en combinant les capacités Serverless avec AIGC, ce qui est pertinent pour mon travail. .
En ce qui concerne cette combinaison, j'ai mentionné plusieurs directions. Premièrement, nous favoriserons l’adaptation de l’architecture de développement d’applications et des capacités d’IA. Nous préconisons la création d'une série de produits et d'outils d'efficacité de R&D prenant en charge une architecture de code et d'application rationalisée et faiblement couplée, afin que ces applications puissent parfaitement s'adapter aux capacités de l'AIGC.
Deuxièmement, nos outils d'efficacité R&D seront combinés avec les capacités AIGC pour permettre aux clients de générer plus facilement du code précis, y compris des définitions de flux de travail et des définitions d'infrastructure et de code (IaC) pour les ressources cloud, afin que les clients puissent mettre en œuvre plus rapidement l'ensemble du cycle de vie des applications. Profitez des améliorations d'efficacité apportées par l'AIGC au cours du cycle.
Troisièmement, nous continuerons à investir dans la recherche et le développement de GPU sans serveur. Cependant, notre objectif n'est pas d'héberger de gros modèles, mais de permettre à des modèles plus légers de s'adapter aux caractéristiques de la plateforme Serverless et de fonctionner dessus. L’objectif essentiel reste d’aider les utilisateurs à résoudre des problèmes coûteux.
Sun Wei : Amap explore actuellement les trois aspects suivants.
Premièrement, Serverless d'AutoNavi améliore et explore en profondeur les aspects événementiels et de flux de travail pour atteindre la flexibilité ultime et l'expansion infinie de Serverless, dans le but de réduire les coûts et d'améliorer l'efficacité. En termes de flux de travail, l'objectif d'AutoNavi est de séparer le code et la configuration, et de les combiner avec son propre moteur de processus métier développé pour doubler l'efficacité.
Il ne s’agit pas simplement d’un simple low-code, mais implique également l’orchestration des processus et l’intégration avec l’entreprise, ce qui est étroitement lié aux caractéristiques d’AutoNavi. La caractéristique d'AutoNavi est qu'il a un trafic important et peut fournir différents services de transaction tels que l'appel de taxi et le ravitaillement en carburant. Il s'agit d'un domaine qui couvre de multiples applications.
Deuxièmement, Amap continuera à s'intégrer à l'industrie et continuera à explorer les produits sans serveur et les bases de données vectorielles liés aux bases de données. Ces produits ont tous une particularité, qui est la séparation du stockage et du calcul. En séparant le stockage et l'informatique, vous pouvez tirer pleinement parti du sans serveur pour réduire les coûts de R&D et améliorer considérablement l'efficacité.
Cependant, une personnalisation et une recherche sans serveur peuvent être nécessaires sur la base d'outils open source. Le sans serveur ne fait pas seulement référence à l'utilisation de divers outils cloud, mais également à leur exploration et à leur combinaison avec une série de produits pour personnaliser diverses applications et fonctions. L'objectif principal est de maximiser l'efficacité de la R&D, de réduire les coûts, de réaliser des avantages commerciaux et d'atteindre les objectifs commerciaux.
Troisièmement, nous ferons de notre mieux pour masquer les différences entre plusieurs langues et rendre les connaissances multilingues. En outre, il existe un découplage sous-jacent, y compris une future dérive du cloud, et l’essentiel est de supprimer le verrouillage du fournisseur. AutoNavi s'efforcera de participer à l'open source, de créer un meilleur environnement d'exploitation et de redonner à l'écosystème afin que chacun puisse mieux accéder à ces technologies.