Ein Artikel zum Verständnis des Implementierungsprozesses der nativen Wuyun-KI-Plattform KubeAI

1. Vorwort

In den letzten Jahren hat der Cloud-Native-Bereich große Aufmerksamkeit und Entwicklung erfahren. Die Implementierung der Containerisierung ist für Unternehmen ein wichtiges Mittel zur Kostensenkung und Steigerung der Effizienz Die gesamte Domain wurde im Wesentlichen fertiggestellt. Während des Containerisierungsprozesses wurden einerseits die Servicebereitstellungs- sowie Betriebs- und Wartungsmethoden reibungslos vom vorherigen ECS-Modus auf den Containerisierungsmodus umgestellt, andererseits erzielte das Unternehmen viele Effizienzgewinne in Bezug auf Ressourcennutzung und F&E-Effizienz .

Dewu ist eine neue Generation trendiger Online-Shopping-Community. Suchmaschinen und personalisierte Empfehlungssysteme auf Basis von KI und Big-Data-Technologie sind starke Unterstützungen für die Geschäftsentwicklung, daher machen Anwendungen im Algorithmus-Bereich einen großen Teil der Geschäftsanwendungen aus. Während des Containerisierungsprozesses haben wir angesichts der Unterschiede zwischen dem F&E-Prozess von Algorithmusanwendungsdiensten und gewöhnlichen Diensten und auf der Grundlage einer umfassenden Untersuchung der Bedürfnisse von F&E-Studenten im Algorithmusbereich die native KI-Plattform Dewu Cloud – die KubeAI-Plattform – erstellt F&E-Szenarien im Algorithmusbereich. Nach kontinuierlicher Iteration der Funktionen und kontinuierlicher Erweiterung der unterstützten Szenarien unterstützt KubeAI derzeit Geschäftsdomänen mit KI-Funktionen wie Lebenslauf, Suchempfehlungen, Risikokontrollalgorithmen und Datenanalyse und hat die Containerisierung erfolgreich abgeschlossen, wodurch die Ressourcennutzung und die F&E-Effizienz verbessert werden Die oben genannten Verbesserungen haben zu guten Ergebnissen geführt. Dieser Artikel wird jedem helfen, den Implementierungsprozess von KubeAI zu verstehen.

2. Containerisierungsförderung des KI-Geschäfts

2.1 KI-Algorithmus-Modellentwicklungsprozess

KI-Geschäft ist eher ein iterativer Entwicklungsprozess für Modelle. Normalerweise kann der Modellentwicklungsprozess in die folgenden Schritte zusammengefasst werden: das Nachfrageszenario: Welches Problem ist in diesem Prozess zu lösen, für welches Szenario ist die Funktion vorgesehen, was ist der Input der Funktion/des Dienstes und was ist der Output? Zum Beispiel: Welche Schuhmarke soll identifiziert bzw. qualitätsgeprüft werden, was sind die Produktmerkmale der Marke, welche Merkmalsabmessungen hat das Muster, Merkmalsarten usw. Verschiedene Szenarien stellen unterschiedliche Anforderungen an Beispieldaten und die verwendeten Verarbeitungsalgorithmen.

Datenvorbereitung: Erhalten Sie anhand der Ergebnisse der Szenariobedarfsanalyse Beispieldaten mit verschiedenen Methoden (online/offline/simuliert usw.) und führen Sie die erforderlichen Bereinigungs-, Kennzeichnungs- und anderen Vorgänge an den Daten durch. Dieser Prozess ist die Grundlage der KI-Geschäftsentwicklung, da alle nachfolgenden Prozesse auf Basis von Daten durchgeführt werden.

Bestimmen Sie den Algorithmus und schreiben Sie das Trainingsskript: Basierend auf dem Verständnis der Geschäftsziele wählen die Algorithmus-Studenten in diesem Link den geeigneten Algorithmus aus und schreiben das Modell-Trainingsskript basierend auf früheren Erfahrungen oder basierend auf Szenenforschung und Experimenten Ergebnisse.

Modelltraining: Für das Algorithmusmodell können wir es als komplexe mathematische Formel verstehen. Diese Formel enthält viele Parameter, genau wie w und b in f(x)=wx+b. Beim Training wird eine große Menge an Beispieldaten verwendet, um optimale Parameter zu finden, damit das Modell eine hohe Erkennungsrate aufweist. Das Modelltraining ist ein sehr wichtiger Teil des KI-Geschäftsentwicklungsprozesses. Man kann sagen, dass das Erreichen der Geschäftsziele von der Genauigkeit des Modells abhängt. Daher erfordert dieser Link mehr Zeit, Energie und Ressourcen als andere Links und erfordert wiederholtes experimentelles Training, um die beste Modellgenauigkeit und Vorhersagegenauigkeit zu erreichen. Dieser Prozess ist nicht einmalig, sondern zyklisch. Entsprechend der Aktualisierung von Geschäftsszenarien und Datenaktualisierungen muss er regelmäßig durchgeführt werden. Für die Entwicklung und das Training von Algorithmusmodellen stehen der Branche einige gängige KI-Engines zur Auswahl, z. B. TensorFlow, PyTorch, MXNet usw. Diese Engines können ein gewisses Maß an API-Unterstützung bieten, um Algorithmenentwicklern die Verteilung komplexer Modelle zu erleichtern , oder nehmen Sie einige Optimierungen für die Hardware vor, um die Effizienz des Modelltrainings zu verbessern. Das Ergebnis des Modelltrainings ist das Abrufen der Modelldatei. Der Inhalt dieser Datei kann als Speichern der Parameter des Modells verstanden werden.

Modellbewertung: Um eine Unteranpassung des Modells aufgrund übermäßiger Abweichung oder eine Überanpassung aufgrund übermäßiger Varianz zu verhindern, sind normalerweise einige Bewertungsindikatoren erforderlich, um Entwickler bei der Bewertung der Generalisierungsfähigkeit des Modells zu unterstützen. Einige häufig verwendete Bewertungsindikatoren, wie zum Beispiel: Präzision, Rückrufrate, ROC-Kurve/AUC, PR-Kurve usw.

Modellbereitstellung: Nach wiederholter Schulung und Bewertung kann ein ideales Modell erhalten werden, das den Geschäftsprozess Online-/Produktionsdaten unterstützt. Dies erfordert, dass das Modell in Form eines Dienstes oder einer Aufgabe bereitgestellt wird, um den Zweck der Annahme von Eingabedaten und der Bereitstellung von Inferenzergebnissen zu erreichen. Wir nennen diesen Dienst einen Modelldienst. Der Modelldienst ist ein Online-Dienstskript, das das Modell lädt. Nachdem es fertig ist, führt es Inferenzberechnungen für die vorverarbeiteten Daten durch.

Nachdem ein Modelldienst online ist, muss der Modelldienst aufgrund von Änderungen der Dateneigenschaften, Algorithmus-Upgrades, Online-Inferenzdienst-Skript-Upgrades, neuen Geschäftsanforderungen für Inferenzindikatoren usw. iteriert werden. Es ist zu beachten, dass dieser iterative Prozess möglicherweise ein erneutes Training und eine Neubewertung des Modells erfordert. Möglicherweise handelt es sich auch nur um eine iterative Aktualisierung des Inferenzdienstskripts.

2.2 Containerisierungsmigration in vollem Gange

Seit letztem Jahr haben wir schrittweise die Implementierung der Containerisierung von Geschäftsdiensten in verschiedenen Domänen von Dewu vorangetrieben. Um Änderungen in den Betriebsgewohnheiten der Benutzer zu reduzieren, die durch Änderungen in den Bereitstellungsmethoden während des Containerisierungsprozesses verursacht werden, verwenden wir weiterhin den Bereitstellungsprozess der Veröffentlichungsplattform, um die Unterschiede zwischen der Containerbereitstellung und der ECS-Bereitstellung abzuschirmen.

Im CI-Prozess werden verschiedene Kompilierungs- und Konstruktionsvorlagen an unterschiedliche Entwicklungssprachentypen angepasst. Von der Quellcode-Kompilierung bis zur Container-Image-Erstellung wird dies einheitlich durch die Containerplattformschicht vervollständigt, wodurch das Problem gelöst wird Das Problem besteht darin, dass der technische Code aufgrund mangelnder Kenntnisse über Container nicht in ein Container-Image umgewandelt werden kann. Während des CD-Prozesses führen wir eine hierarchische Verwaltung von Konfigurationen auf Anwendungstypebene, Umgebungsebene und Umgebungsgruppenebene durch. Beim Ausführen der Bereitstellung führen wir die mehrschichtige Konfiguration in „values.yaml“ von Helm Chart zusammen und übermitteln die Orchestrierungsdatei an Container-Cluster. Benutzer müssen lediglich die entsprechenden Umgebungsvariablen entsprechend ihren tatsächlichen Anforderungen festlegen, die Bereitstellung senden und dann die Anwendungsclusterinstanz (Containerinstanz, ähnlich der ECS-Dienstinstanz) abrufen.

Für den Betrieb und die Wartung von Anwendungsclustern bietet die Containerplattform die Funktion, sich über WebShell bei der Containerinstanz anzumelden, genau wie die Anmeldung bei der ECS-Instanz, was für die Fehlerbehebung im Anwendungsprozess praktisch ist. Damit verbundene Probleme; die Containerplattform bietet auch die Funktion zum Hochladen und Hochladen von Dateien wie das Herunterladen, Neustarten und Wiederherstellen von Instanzen sowie die Ressourcenüberwachung.

Als relativ großes Unternehmen nehmen KI-Unternehmen (Lebenslauf, Suche und Empfehlung, Algorithmen zur Risikokontrolle usw.) zusammen mit normalen Geschäftsdienstleistungen am Containerisierungsprozess teil Basierend auf Community und Transaktion. Die Migration von Kernszenendiensten, dargestellt durch Wasserfallfluss und Vajra-Position. Nach der Containerisierung wurde die Ressourcennutzung der Testumgebung erheblich verbessert, die Produktionsumgebung wurde ebenfalls erheblich verbessert und die Betriebs- und Wartungseffizienz hat sich verdoppelt.

2.3 Algorithmenstudenten können den Schmerz nicht ertragen

Der Prozess der Containerisierung geht mit der schnellen Entwicklung des Technologiesystems des Unternehmens einher, was die frühe unausgereifte Forschung und Entwicklung von KI-Diensten erleichtert Der Prozess hat mehr Anforderungen an die Containerisierung gestellt und uns, die wir uns ursprünglich nur auf die Containerisierung von Online-Inferenzdiensten konzentrierten, ermöglicht, die Schwachstellen und Schwierigkeiten zu erkennen, mit denen Algorithmenstudenten im Modellentwicklungsprozess konfrontiert sind.

Schmerzpunkt 1: Die Verwaltung des Modells und die Verwaltung des Inferenzdienstes sind inkohärent. Die meisten CV-Modelle werden auf Desktop-Computern trainiert und dann manuell auf OSS hochgeladen. Anschließend wird die Adresse der Modelldatei auf OSS für den Online-Inferenzdienst konfiguriert. Die meisten Soutui-Modelle sind auf PAI trainiert, werden aber auch manuell auf OSS gespeichert und ähneln bei der Veröffentlichung CV. Es ist ersichtlich, dass die Verwaltung des Modellprodukts im Prozess der Modellschulung und -freigabe inkohärent ist. Es ist unmöglich zu verfolgen, auf welchen Diensten ein Modell bereitgestellt wird, und es ist unmöglich, intuitiv zu erkennen, auf welchem ​​Dienst ein Dienst bereitgestellt wird. Oder es gibt mehrere Modelle und die Modellversionsverwaltung ist unpraktisch.

Problempunkt 2: Die Vorbereitung der Modellentwicklungsumgebung dauert lange und es mangelt an flexiblen Mechanismen für die Ressourcenanwendung und -nutzung. Vor der Containerisierung wurden Ressourcen im Allgemeinen in Form von ECS-Instanzen bereitgestellt. Sie mussten den Prozess zur Beantragung von Ressourcen durchlaufen. Nach der Beantragung mussten Sie verschiedene Initialisierungsarbeiten durchführen, Software installieren, Abhängigkeiten installieren und Daten übertragen (die meisten davon). (Softwarebibliotheken, die in der Algorithmenforschung verwendet werden, sind groß, die Installation ist auch komplizierter). Wenn nach der Installation eines ECS die Ressourcen später nicht ausreichen, müssen Sie sich erneut bewerben und den gleichen Prozess erneut durchlaufen, was ineffizient ist. Gleichzeitig unterliegt die Ressourcenverwendung Quotenbeschränkungen (Budgetbeschränkungen) und es fehlt ein Mechanismus für autonomes Management und flexible Anwendung und Freigabe bei Bedarf.

Problempunkt 3: Es ist schwierig, einige von Cloud Native unterstützte Modelllösungen auszuprobieren. Da Cloud-native-Technologie weiterhin in verschiedenen Bereichen implementiert wird, bieten Lösungen wie Kubeflow und Argo Workflow eine gute Unterstützung für KI-Szenarien. Beispiel: tfjob-operator kann verteilte Trainingsaufgaben basierend auf dem TensorFlow-Framework in Form von CRD verwalten. Benutzer müssen lediglich die Parameter der entsprechenden Komponenten (Chief, PS, Worker usw.) festlegen, bevor sie Trainingsaufgaben an Kubernetes senden Cluster. Wenn Algorithmenstudenten vor der Containerisierung diese Lösung ausprobieren wollten, mussten sie mit Docker, Kubernetes und anderen Container-bezogenen Kenntnissen vertraut sein und diese beherrschen und konnten diese Fähigkeit nicht als normaler Benutzer nutzen.

Schmerzpunkt 4: Wenn Nicht-Algorithmen-Abteilungen einen Algorithmus schnell verifizieren wollen, finden sie keine Plattform, die ihn gut unterstützen kann. Die Fähigkeiten der KI werden offensichtlich in verschiedenen Geschäftsfeldern genutzt, insbesondere einige ausgereifte Algorithmen. Geschäftsteams können sie problemlos nutzen, um einige Basisindikatorvorhersagen oder Klassifizierungsvorhersagen zu erstellen, die dem Unternehmen helfen, bessere Ergebnisse zu erzielen. Derzeit ist eine Plattform erforderlich, die KI-bezogene Funktionen bereitstellen kann, um die Anforderungen dieser Szenarien an heterogene Ressourcen (CPU/GPU/Speicher/Netzwerk usw.) und Algorithmenmodellverwaltung zu erfüllen und Benutzern gebrauchsfertige Funktionen bereitzustellen. Funktionen nutzen.

Basierend auf der Durchkämmung und Analyse der oben genannten Schwachstellen und schwierigen Probleme und basierend auf anderen Anforderungen an die Containerplattform, die von Algorithmenstudenten während des Containerisierungsprozesses vorgebracht wurden (z. B. einheitliche Verwaltungsanforderungen für Modelle, Anforderungen an die Protokollsammlung, Ressourcenpool). Anforderungen, Anforderungen an die Datenpersistenz usw. ), haben wir jedes einzelne Problem einzeln besprochen und gelöst. Während wir die aktuellen Probleme gelöst haben, haben wir auch die langfristige Funktionsplanung der Plattform berücksichtigt und nach und nach eine KubeAI-Plattformlösung basierend auf dem Container erstellt Plattform und auf das KI-Geschäft ausgerichtet. 3. KubeAI-Plattformlösung Containerisierung Entwarf und implementierte schrittweise die Cloud-native KI-Plattform KubeAI-Plattform. Die KubeAI-Plattform konzentriert sich auf die Lösung der Schmerzpunktbedürfnisse von Algorithmenstudenten, indem sie die notwendigen Funktionsmodule während der gesamten Modellentwicklungs-, Freigabe-, Betriebs- und Wartungsprozesse bereitstellt und Algorithmenentwicklern dabei hilft, schnell und kostengünstig KI-Infrastrukturressourcen zu erhalten und zu nutzen und Algorithmen schnell und effizient auszuführen effizientes Modelldesign, Entwicklung und Experimentieren.

3.1 Gesamtarchitektur

Die KubeAI-Plattform bietet die folgenden Funktionsmodule rund um den gesamten Lebenszyklus des Modells:

Datensatzverwaltung: Hauptsächlich für die Kompatibilität mit verschiedenen Datenquellen und bietet außerdem Funktionen zur Beschleunigung des Daten-Caches.

Modellschulung: Es stellt nicht nur Notebook für die Modellentwicklung und -schulung bereit, sondern unterstützt auch die Verwaltung einmaliger/periodischer Aufgaben. Dabei werden heterogene Ressourcen (CPU/GPU/Speicher) elastisch beantragt und freigegeben.

Modellverwaltung: Einheitliche Verwaltung von Modellmetadaten (grundlegende Modellinformationen, Versionsliste usw.), nahtlos verbunden mit Modellservice-Release- sowie Betriebs- und Wartungsprozessen.

Inferenzdienstverwaltung: Entkoppelt das Modell vom Inferenzcode, sodass das Modell nicht mehr in das Image gepackt werden muss, was die Effizienz von Inferenzdienstaktualisierungen verbessert und Modellaktualisierungen für Onlinedienste unterstützt.

AI-Pipeline-Engine: Unterstützt die Anordnung von Aufgaben in einer Pipeline, um den Anforderungen der Datenanalyse, regelmäßigen Routinetrainingsaufgaben, Modelliteration und anderen Szenarien gerecht zu werden.

Die KubeAI-Plattform unterstützt nicht nur einzelne Benutzer, sondern auch Plattformbenutzer. Einzelne Entwickler verwenden das Notebook von KubeAI, um Modellskripte zu entwickeln. Kleinere Modelle können direkt im Notebook trainiert werden, und komplexe Modelle können durch Aufgaben trainiert werden. Nachdem das Modell erstellt wurde, wird es einheitlich auf KubeAI verwaltet, einschließlich der Veröffentlichung als Inferenzdienst und der Iteration neuer Versionen. Die Geschäftsplattform eines Drittanbieters erhält die Funktionen von KubeAI über OpenAPI für Geschäftsinnovationen auf der oberen Ebene.

Im Folgenden konzentrieren wir uns auf die Funktionen der vier Module Datensatzmanagement, Modelltraining, Modelldienstmanagement und AI-Pipeline Engine.

3.2 Datensatzverwaltung

Nach dem Aussortieren werden die von den Algorithmus-Studenten verwendeten Daten entweder im NAS gespeichert, von ODPS gelesen oder von OSS abgerufen. Um die Datenverwaltung zu vereinheitlichen, basiert KubeAI auf Kubernetes PVC-Ressourcen (Persistent Volume Claim), um Benutzern das Konzept von Datensätzen zu vermitteln, und ist mit verschiedenen Datenquellenformaten kompatibel. Um gleichzeitig das Problem des hohen Datenzugriffsaufwands zu lösen, der durch die Trennung von Rechen- und Speicherarchitektur entsteht, konfigurieren wir mit Fluid einen Cache-Dienst für den Datensatz. Die Daten können für die nächste Runde lokal zwischengespeichert werden Iterative Berechnungen oder Aufgaben können so geplant werden, dass der Datensatz auf dem Rechenknoten zwischengespeichert wird.

3.3 Modelltraining

Für das Modelltraining erledigen wir hauptsächlich drei Aspekte der Arbeit:

(1) Basierend auf JupyterLab können Benutzer eine Shell- oder Web-IDE verwenden, um dem lokalen Entwicklungsmodus zu entsprechen unsere Arbeit an der Entwicklung von Algorithmusmodellen.

(2) Das Modelltraining wird in Form von Aufgaben durchgeführt, wodurch Ressourcen flexibler beantragt und freigegeben, die Ressourcennutzung verbessert und die Kosten des Modelltrainings erheblich gesenkt werden können. Aufgrund der guten Skalierbarkeit von Kubernetes können verschiedene TrainingJob-CRDs in der Branche problemlos verbunden werden und Trainings-Frameworks wie Tensorflow, PyTorch und xgbost können alle unterstützt werden. Aufgaben unterstützen die Stapelplanung und Aufgabenprioritätswarteschlangen.

(3) Arbeitete mit dem Algorithmenteam zusammen, um das Tensorflow-Trainingsframework teilweise zu optimieren, und erzielte einige Verbesserungen bei der Effizienz beim Lesen von Batch-Daten und der Kommunikationsgeschwindigkeit zwischen PS/Workern bei Problemen wie PS-Lastungleichgewicht und langsamen Workern usw. Einige wurden vorgenommen Lösungen.

3.4 Modelldienstverwaltung

Im Vergleich zu normalen Diensten besteht das größte Merkmal von Modelldiensten darin, dass der Dienst eine oder mehrere Modelldateien laden muss. In den frühen Tagen der Containerisierung packten die meisten CV-Modelldienste aus historischen Gründen Modelldateien und Inferenzskripte direkt in Container-Images, was zu relativ großen Container-Images und umständlichen Modellversionsaktualisierungen führte.

KubeAI ändert das obige Problem. Basierend auf der standardisierten Verwaltung des Modells wird der Modelldienst durch die Konfiguration mit dem Modell verknüpft. Beim Veröffentlichen ruft die Plattform die entsprechende Modelldatei zum Laden ab Inferenzskript. Diese Methode verringert den Druck auf die Entwickler von Algorithmusmodellen, Abbilder/Versionen von Inferenzdiensten zu verwalten, reduziert die Speicherredundanz, verbessert die Effizienz der Modellaktualisierung/-rollbacks, verbessert die Wiederverwendungsrate von Modellen und hilft Algorithmenteams, Modelle und die damit verbundenen Online-Modelle bequemer und schneller zu verwalten Inferenzdienste.

3.5 AI-Pipeline Engine

Das eigentliche Geschäftsszenario wird beispielsweise kein einzelner Aufgabenknoten sein, der Datenverarbeitung und Modellschulung umfasst Verwenden Sie das neue Modell, um den Online-Inferenzdienst, den Link zur Überprüfung des kleinen Datenverkehrs und den offiziellen Veröffentlichungslink zu aktualisieren. Die KubeAI-Plattform bietet eine Workflow-Orchestrierungs-Engine basierend auf Argo Workflow-Knoten, die benutzerdefinierte Aufgaben, voreingestellte Vorlagenaufgaben der Plattform und verschiedene Deep-Learning-KI-Trainingsaufgaben (TFJob, PyTorchJob usw.) unterstützen.

4. Typische Fälle von KI-Geschäftsszenarien, die auf KubeAI implementiert werden

4.1 Entwicklungsprozess für CV-Algorithmusmodelle

# 🎜🎜#

Der Entwicklungsmodus des CV-Algorithmusmodells besteht im Allgemeinen darin, theoretische Algorithmen zu studieren und gleichzeitig Algorithmenmodelle für die technische Praxis zu entwickeln und diese jederzeit zu debuggen. Da Modelle im Allgemeinen kleiner sind, sind die Schulungskosten niedriger als bei Such- und Push-Modellen, sodass CV-Studenten eher daran gewöhnt sind, direkt in Notebook zu trainieren, nachdem sie Schulungsskripts in Notebook entwickelt haben. Benutzer können Ressourcen wie CPU, GPU-Karte und Netzwerkspeicherfestplatte für Notebooks unabhängig auswählen und konfigurieren.

Nachdem das Trainingsskript durch Entwicklung und Debugging die Anforderungen erfüllt, kann der Benutzer die von KubeAI bereitgestellte Aufgabenverwaltungsfunktion verwenden, um das Trainingsskript als eigenständige Trainingsaufgabe oder verteilte Trainingsaufgabe zu konfigurieren Senden Sie es an die KubeAI-Plattform. Die Plattform plant die Ausführung der Aufgabe in einem Ressourcenpool mit ausreichenden Ressourcen. Nach erfolgreichem Betrieb wird das Modell in das Modelllager verschoben und in der Modellliste von KubeAI registriert, oder das Modell wird an einem bestimmten Ort zur Erstellung gespeichert Auswahl und Bestätigungen.

Nachdem das Modell generiert wurde, können Benutzer das Modell direkt als Inferenzdienst im Modelldienstmanagement von KubeAI bereitstellen. Wenn später eine neue Version des Modells erstellt wird, können Benutzer eine neue Modellversion für den Inferenzdienst konfigurieren. Abhängig davon, ob die Inferenz-Engine das Modell-Hot-Update unterstützt, können Sie dann das Upgrade des Modells im Inferenzdienst abschließen, indem Sie den Dienst erneut bereitstellen oder eine Modell-Upgrade-Aufgabe erstellen.

Im Geschäftsszenario zur Maschinenidentifizierung wird der obige Prozess durch den AI-Pipeline-Workflow orchestriert und Modelliterationen werden regelmäßig durchgeführt, wodurch die Effizienz der Modelliteration um etwa 65 % erhöht wird. Nachdem die CV-Szene mit der KubeAI-Plattform verbunden wurde, wird die bisherige lokale Trainingsmethode aufgegeben und die flexible On-Demand-Ressourcenerfassungsmethode auf der Plattform verbessert die Ressourcennutzung in Bezug auf Modellverwaltung, Inferenzdienstverwaltung und Modelliteration erheblich. Die F&E-Effizienz wird um etwa 50 % verbessert.

4.2 Migration von Souti-Modelltrainingsaufgaben von PAI zur KubeAI-Plattform

Im Vergleich zu CV-Modellen sind die Trainingskosten für Souti-Modelle höher, was sich hauptsächlich in den großen Datenproben widerspiegelt. Die Trainingszeit ist lang und eine einzelne Aufgabe erfordert eine große Menge an Ressourcen. Da unsere Daten vor dem Start von KubeAI auf ODPS (einer von Alibaba General Computing Platform bereitgestellten Data Warehouse-Lösung, jetzt umbenannt in MaxCompute) gespeichert wurden, befanden sich die meisten Such- und Push-Algorithmus-Studenten in Dataworks (Big Data basierend auf ODPS Build-Daten). Verarbeitungsaufgaben auf der Konsole der Development Management Platform) und übermitteln Sie Modelltrainingsaufgaben an die PAI-Plattform. Da es sich bei PAI jedoch um ein öffentliches Cloud-Produkt handelt, sind die Kosten für eine einzelne Aufgabe höher als die für die Aufgabe selbst erforderlichen Ressourcen Das Cloud-Produkt hat auch die internen Kostenkontrollanforderungen des Unternehmens nicht erfüllt.

Nachdem KubeAI schrittweise implementiert wurde, werden wir die Modelltrainingsaufgaben von Such- und Push-Szenarien auf PAI auf zwei Arten schrittweise auf unsere Plattform migrieren. Methode 1 besteht darin, die Gewohnheit des Benutzers beizubehalten, in Dataworks zu arbeiten, dennoch einige SQL-Aufgaben in Dataworks auszuführen und die Aufgaben dann über Shell-Befehle an die KubeAI-Plattform zu senden. Methode 2 besteht darin, dass Benutzer Aufgaben direkt an die KubeAI-Plattform senden. Wir hoffen, dass wir mit der Verbesserung der Data-Warehouse-Infrastruktur schrittweise auf die zweite Methode umsteigen werden.

Der Entwicklungsprozess für Modelltrainingsaufgaben von Soutui nutzt die von KubeAI bereitgestellte Entwicklungsumgebung und Tools vollständig aus. Durch das selbst entwickelte Trainingsprojekt Framwork kann die Trainingszeit bei ausschließlicher Verwendung der CPU mit der Verwendung des GPU-Trainings auf PAI identisch sein. Die Trainings-Engine-Seite unterstützt auch große Modelltrainings- und Echtzeit-Trainingsszenarien und arbeitet mit mehreren Typen zusammen der Speicherlösung (OSS/Dateispeicher) und der Modellverteilungslösung, um die Erfolgsquote großer Modellschulungsaufgaben sicherzustellen und Modellaktualisierungen für Online-Dienste effizient durchzuführen.

In Bezug auf die Ressourcenplanung und -verwaltung nutzt KubeAI die Cluster-Föderation, den Oversold-Mechanismus, die Aufgabenbindung und andere technische Mittel voll aus, um die Nutzung dedizierter Ressourcenpools für Trainingsaufgaben schrittweise in die Zuweisung elastischer Ressourcen umzuwandeln Task-Pods planen für Online-Ressourcenpools und öffentliche Ressourcenpools. Nutzen Sie die Merkmale der periodischen Ausführung von Produktionsaufgaben und der Hauptentwicklungsaufgaben während des Tages voll aus und implementieren Sie Spitzenverschiebungen und differenzierte Planungen (z. B. Verwendung elastischer Ressourcen für kleine Größen und regulärer Ressourcen für große Größen usw.). Den Daten der letzten Monate nach zu urteilen, konnten wir weiterhin eine größere Aufgabenzunahme durchführen, während sich an der Gesamtzunahme der Ressourcen nicht viel geändert hat.

4.3 Basisindikator-Vorhersageszenario

Dies ist ein typisches nicht-algorithmisches Geschäftsszenario unter Verwendung von KI-Funktionen. Verwenden Sie beispielsweise den Prophet-Algorithmus von Facebook, um eine bestimmte Basislinie für Geschäftsindikatoren vorherzusagen. KubeAI bietet grundlegende KI-Funktionen für die Anforderungen dieser Szenarien und löst das Problem der „Schwierigkeit, ausgereifte Algorithmen schnell zu verifizieren“. Benutzer müssen das Algorithmusmodell lediglich auf technische Weise implementieren (unter Verwendung vorhandener Best Practices oder sekundärer Entwicklung), dann ein Container-Image erstellen, eine Aufgabe an KubeAI senden, mit der Ausführung beginnen und die gewünschten Ergebnisse erzielen oder regelmäßig Schulungen und Schlussfolgerungen durchführen Erhalten Sie grundlegende Vorhersageergebnisse.

Benutzer können die für Aufgaben benötigten Rechenressourcen oder andere heterogene Ressourcen bei Bedarf konfigurieren und nutzen. Nimmt man derzeit 12 Indikatoren eines Online-Geschäftsszenarios, werden täglich fast 20.000 Aufgaben ausgeführt. Im Vergleich zu den vorherigen Ressourcenkosten für ähnliche Anforderungen hilft KubeAI dabei, fast 90 % der Kosten einzusparen und die F&E-Effizienz um das Dreifache zu verbessern .

5. Ausblick

Dewu hat die Containerisierung seines Geschäfts in relativ kurzer Zeit erfolgreich umgesetzt, was auf die zunehmend ausgereifte Cloud-native-Technologie zurückzuführen ist Andererseits profitiert es von unserem tiefgreifenden Verständnis der Anforderungen unserer eigenen Geschäftsszenarien und unserer Fähigkeit, zielgerichtete Lösungen anzubieten. Die KubeAI-Plattform basiert auf unserer eingehenden Analyse der Schwachstellenanforderungen algorithmischer Geschäftsszenarien, basierend auf der Frage, wie die technische Effizienz von KI-Geschäftsszenarien kontinuierlich verbessert, die Ressourcennutzung verbessert und die Schwelle für die Entwicklung von KI-Modellen/-Diensten gesenkt werden kann. und es dann schrittweise iterativ umsetzen.

Wir werden auch in Zukunft intensiv an der Optimierung der Trainings-Engine, der verfeinerten KI-Aufgabenplanung und dem elastischen Modelltraining arbeiten, um das KI-Modelltraining sowie die Iterationseffizienz und Ressourcennutzung weiter zu verbessern.

Das obige ist der detaillierte Inhalt vonEin Artikel zum Verständnis des Implementierungsprozesses der nativen Wuyun-KI-Plattform KubeAI. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!