Wahre ML-Vorträge #13 - ML-Plattform @ Cookpad

Wir sind zurück mit einer weiteren Folge von True ML Talks. In dieser Ausgabe werden wir uns eingehend mit der ML-Architektur von Cookpad, einer der weltweit größten Rezeptservice-Plattformen, befassen. Wir werden uns auch mit den Herausforderungen befassen, die mit dem Aufbau einer erfolgreichen Plattform für maschinelles Lernen verbunden sind, und wie sie den Nvidia Triton-Inferenzserver verwenden, um Modelle auszuführen.
Wir sprechen mit José Navarro

Jose ist der leitende ML-Plattformingenieur bei Cookpad und versucht, den Machine-Learning-Ingenieuren und allen ML-Praktikern zu helfen, ML-Systeme schnell und zuverlässig bereitzustellen.

📌

Unsere Gespräche mit Jose werden die folgenden Aspekte behandeln:
- Struktur der ML-Teams @ Cookpad
- GPU-basierte ML-Infrastruktur
- Automatisierte Modellbereitstellung bei Cookpad
- Feature-Store-Integration und Konfiguration für Online-Inferenz
- Datenquellen und Feature-Management bei Modellexperimenten
- Verwendung von Argo Workflows zum erneuten Training von ML-Modellen
- Der Triton Inference Server von Nvidia und seine Vorteile
- Integration von MLflow Model Registry mit Triton Inference Server
- Nutzung von LLMs und Gen AI bei Cookpad
- Anpassung der MLOps-Architektur an Ihre Bedürfnisse

Sehen Sie sich die ganze Folge unten an:

Struktur der ML-Teams @ Cookpad

1. Ingenieure für maschinelles Lernen: Das ML-Kernteam besteht aus Ingenieuren mit Fachkenntnissen sowohl im maschinellen Lernen als auch in der Softwareentwicklung. Sie sind für die Entwicklung, Schulung und Bereitstellung von Modellen für maschinelles Lernen verantwortlich und arbeiten eng mit den Produktteams zusammen.
2. Plattform-Team: Das Plattformteam unterstützt die ML-Ingenieure bei der Verwaltung der zugrunde liegenden Infrastruktur, einschließlich Kubernetes-Clustern. Sie sorgen für Skalierbarkeit, Zuverlässigkeit und Leistung von ML-Systemen. Darüber hinaus entwickeln und pflegen sie interne Tools und Frameworks, um den ML-Entwicklungsprozess zu optimieren.

GPU-basierte ML-Infrastruktur

1. Cloud-basierte Infrastruktur: Cookpad betreibt seine ML-Infrastruktur in der Cloud, hauptsächlich mithilfe von AWS, mit einigen Ressourcen in GCP. Die Infrastruktur ist so konzipiert, dass sie dem Umfang und den Anforderungen der globalen Nutzerbasis von Cookpad gerecht wird.
2. Datenverarbeitung und Merkmalsextraktion: Nutzergenerierte Inhalte und Aktionen werden über Kafka aufgenommen und in einem Streaming-Dienst verarbeitet. Funktionen werden berechnet und im Amazon SageMaker Feature Store gespeichert, wobei Amazon Redshift als Data Warehouse dient.
3. Microservice-Architektur und Inferenzschicht: Die ML-Plattform von Cookpad basiert auf einer Microservice-Architektur, die auf Kubernetes bereitgestellt wird. Die Vorverarbeitung erfolgt innerhalb von Microservices, und der Nvidia Inference Server wird für ML-Inferenz verwendet.
4. Experimentierplattform für ML-Ingenieure: Cookpad bietet eine Experimentierplattform für ML-Ingenieure, einschließlich Jupyter-Servern für Datenexploration und Modelltraining. MLflow wird für die Verfolgung von Experimenten und die Modellregistrierung verwendet.
5. Modellbereitstellung und Automatisierung: ML-Techniker registrieren Modelle in MLflow, und Automatisierungsprozesse übernehmen die Transformation und Bereitstellung von Modellen auf dem Nvidia Inference Server (Triton).
6. GPU-intensive Anwendungsfälle: Die GPU-Infrastruktur von Cookpad unterstützt verschiedene Modelle, darunter mehrsprachige Modelle und Bild-Embedder. Mehrsprachige Modelle nutzen große neuronale Netzwerke, während Bildeinbetter sehr rechenintensiv sind. Modelle werden standardmäßig auf GPUs mithilfe des Nvidia Triton Inference Servers bereitgestellt.

Automatisierte Modellbereitstellung bei Cookpad

1. Jupyter Hub zum Experimentieren: Die ML-Ingenieure von Cookpad haben Zugriff auf eine verwaltete Jupyter Hub-Umgebung, in der sie ihre Experimente durchführen können. Das Team unterstützt verschiedene Kernel in Jupyter Hub zu Experimentierzwecken.
2. Modelle in MLflow veröffentlichen: Sobald der ML-Ingenieur ein Modell entwickelt und zufriedenstellende Ergebnisse erzielt hat, kann er das Modell auf MLflow veröffentlichen, das als Plattform für Modellregistrierung und Versuchsverfolgung dient.
3. Durchgängige Automatisierung: Cookpad hat eine durchgängige automatisierte Pipeline für die Modellbereitstellung implementiert. Die Automatisierungspipeline übernimmt die MLflow-Modellregistrierung und führt das Modell nahtlos durch den Bereitstellungsprozess.
4. Unterstützte Backend-Frameworks: Die Automatisierungspipeline von Cookpad unterstützt eine Teilmenge von Backend-Frameworks, darunter PyTorch, TensorFlow und ONNX. Diese Frameworks werden verwendet, um die Modelle effektiv zu optimieren und bereitzustellen.
5. Standardmäßig auf PyTorch und TensorFlow eingestellt: Cookpad unterstützt zwar mehrere Backend-Frameworks, das Team verwendet jedoch aufgrund ihrer weit verbreiteten Nutzung und Kompatibilität mit der Infrastruktur standardmäßig PyTorch und TensorFlow für die Modellentwicklung und -bereitstellung.

📌

Automatisierte Modellbereitstellung mit MLflow und Backend-Unterstützung:
Wenn ein Ingenieur für maschinelles Lernen bei Cookpad experimentiert, hat er Zugriff auf einen verwalteten Jupyter-Hub, auf dem er seine Experimente durchführen und verschiedene Kernel verwenden kann. Sobald sie ein Modell entwickelt haben, veröffentlichen sie es auf MLflow, das als Modellregistrierung dient. Von dort aus ist der Prozess vollständig automatisiert.
Die Automatisierungspipeline von Cookpad unterstützt eine Liste von Backends, die sowohl mit MLflow als auch mit dem Triton Inference Server kompatibel sind. Zu den unterstützten Backends gehören PyTorch, TensorFlow, Onnx und andere. Die Automatisierungspipeline kümmert sich um die Bereitstellung der registrierten Modelle und nutzt je nach Kompatibilität das entsprechende Backend. Die Standardoptionen für die Bereitstellung sind normalerweise PyTorch oder TensorFlow, wobei Onnx zur Optimierung bestimmter neuronaler Netzwerke verwendet wird.

Feature-Store-Integration und Konfiguration für Online-Inferenz

Bei Cookpad nutzen Datenwissenschaftler den Feature Store sowohl für Experimente als auch für Online-Inferenzen. Während des Experimentierens haben sie Offline-Zugriff, um vorhandene Funktionen für das Modelltraining abzufragen. Bei der Erkundung neuer Funktionen werden Daten aus dem Data Warehouse abgerufen, transformiert und zur Erstellung neuer Funktionen verwendet. Sobald die Datenwissenschaftler mit der Leistung des Modells zufrieden sind, erstellen sie mithilfe des Repository-Schemas einfach eine neue Feature-Gruppe im Feature-Store.

Daten fließen über Kafka vom Data Warehouse zum Feature Store, sodass neu erstellte Funktionen gestreamt werden können. Um Online-Inferenzen zu ermöglichen, erweitern Datenwissenschaftler den Streaming-Dienst, um relevante Ereignisse zu verarbeiten und Transformationen durchzuführen. Bei der Modellregistrierung spezifizieren Datenwissenschaftler die Konstruktion und die verwendeten Merkmale des Modells. Der Transformationscode wird so konfiguriert, dass bestimmte Merkmale namentlich abgerufen werden.

Diese Integration zwischen Feature Store, Data Warehouse und Streaming-Dienst gewährleistet die nahtlose Integration von Funktionen in den Online-Inferenzprozess und bietet Flexibilität für Anpassungen und Aktualisierungen bei Bedarf.

Datenquellen und Feature-Management bei Modellexperimenten

Bei Modellexperimenten haben die Datenwissenschaftler von Cookpad zwei Optionen für die Datenbeschaffung. Wenn die erforderlichen Funktionen bereits im Feature Store verfügbar sind, können sie sie direkt offline abfragen. Bei der Erkundung neuer Funktionen greifen sie jedoch auf das Data Warehouse zu, rufen die Daten ab und erstellen die für das Training der Modelle erforderlichen Transformationen.

Die Integration neuer Funktionen in den Feature Store ist unkompliziert. Datenwissenschaftler reichen eine Pull-Anfrage (PR) mit den Schemadetails der Funktion ein, und die Automatisierung übernimmt die Erstellung der Feature-Gruppe mithilfe von AWS-Aufrufen. Die im Data Warehouse verwendeten Daten werden über Kafka gestreamt, um Online-Rückschlüsse auf die neu erstellten Funktionen zu ermöglichen. Der bestehende Streaming-Dienst wird erweitert, um Ereignisse zu verarbeiten und Transformationen anzuwenden, wodurch der Streaming-Fluss der Funktionen in den Feature Store gewährleistet wird.

Um die Feature-Konfiguration beizubehalten, fügen Datenwissenschaftler bei der Registrierung des Modells in MLflow relevante Informationen hinzu. Der Transformationscode greift direkt auf den Feature-Store zu, und im Rahmen der Konfiguration geben die Datenwissenschaftler die erforderlichen Feature-Namen an. Diese Flexibilität ermöglicht eine einfache Änderung der Feature-Konfigurationen nach Bedarf.

Verwendung von Argo-Workflows zum erneuten Training von ML-Modellen

Der Prozess der Integration von Umschulungspipelines in die Architektur ist derzeit bei Cookpad in Arbeit. Während der Schwerpunkt bisher auf der schnellen Iteration neuer ML-Funktionen lag, befindet sich die Implementierung ausgereifter Umschulungspipelines, die die Modelle täglich oder wöchentlich ersetzen oder neu schulen, noch in der Entwicklung. Die Empfehlungssysteme bei Cookpad befinden sich noch in einem frühen Stadium, und der iterative Ansatz ermöglicht ein schnelles Experimentieren und den Modellaustausch durch AB-Tests.

Obwohl das Potenzial besteht, reproduzierbare Pipelines mithilfe von Argo Workflows zu erstellen, räumt Cookpad ein, dass sie sich in einem frühen Stadium dieser Implementierung befinden. Es ist noch keine ideale Lösung, und die Reproduzierbarkeit der Pipelines ist eine Herausforderung, der sie sich aktiv stellen.

Der Beginn mit kleineren, einfacheren Experimenten und die Automatisierung kritischer Pipeline-Komponenten ermöglicht eine gut durchdachte Architektur. Cookpad hat der Automatisierung von Inferenzen Priorität eingeräumt, da es deren Wichtigkeit erkannt hat, und plant, sich in Zukunft auf die Umschulung von Pipelines zu konzentrieren. Dieser organisierte und schrittweise Ansatz beim Aufbau der Plattform ist eine wertvolle Lernerfahrung für das Publikum und unterstreicht die Effektivität der Methodik.

Der Versuch, von Anfang an ein durchgängiges System aufzubauen, führt oft zu unnötigen oder schlecht passenden Komponenten. Er schlägt vor, Alternativen zu Argo-Workflows für reproduzierbare Pipelines zu untersuchen, z. B. die Verwendung eines Python-Wrappers oder eines anderen Tools, das besser zur Vertrautheit der Machine-Learning-Ingenieure mit Kubernetes-Manifests passt und gut zu ihren CI/CD-Praktiken passt.

Der Triton Inference Server von Nvidia und seine Vorteile

1. Entscheidung, Triton Inference Server zu verwenden: Cookpad entschied sich für Triton Inference Server, um die Herausforderungen bei der Ausführung von Inferenzen auf GPUs in Kubernetes zu bewältigen, Kosten und Leistung zu optimieren und gleichzeitig das Gleichgewicht zwischen Kosten und Geschäftswert zu berücksichtigen.
2. Vorteile von Triton Inference Server: Triton Inference Server bietet Kostenoptimierung, indem Modelle aggregiert, GPU-Ressourcen gemeinsam genutzt und Anfragen intelligent weitergeleitet werden, um die Kosten zu senken. Es verbessert standardmäßig die Leistung, indem Modelle auf GPUs bereitgestellt werden, was zu schnelleren Inferenzen führt. Es verbessert die Benutzererfahrung für ML-Techniker, indem es die Bereitstellung durch eine einzige Konfigurationszuordnungszeile und das nahtlose Abrufen und Laden von Modellen vereinfacht.

Durch die Nutzung des Triton Inference Servers von Nvidia erreicht Cookpad eine Kostenoptimierung, verbessert die Leistung der Modellinferenz und vereinfacht die Bereitstellung für ML-Techniker.

Integration von MLflow Model Registry mit Triton Inference Server

Cookpad hat MLflow Model Registry und Triton Inference Server integriert, um die Bereitstellung von Modellen in großem Maßstab zu optimieren. So haben sie es geschafft:

1. MLFlow-Modellspeicher: Wenn ein Modell in MLflow registriert ist, wird es in einem S3-Bucket mit einer bestimmten Ordnerstruktur gespeichert, die auf den Konventionen von MLflow basiert. Das Modell kann im TensorFlow- oder PyTorch-Format vorliegen, jedes mit seiner eigenen Struktur.
2. Tritons Modellstruktur: Triton Inference Server erwartet eine andere Ordnerstruktur für das Laden von Modellen, einschließlich Konfigurationsdateien. Diese Fehlausrichtung erfordert einige Anpassungen, um ein Modell von MLflow nach Triton zu verschieben.
3. Einsatz von Beiwagen: Cookpad entwickelte eine Sidecar-Komponente, die zusammen mit dem Triton Inference Server eingesetzt wurde. Dieser kleine Python-Container fragt jede Minute die MLflow-API ab, um alle neu registrierten Modelle zu identifizieren. Er fragt auch die Triton-API ab, um zu überprüfen, welche Modelle derzeit geladen sind.
4. Modellkonsolidierung: Wenn in MLFlow ein neues Modell erkannt wird, das in Triton nicht vorhanden ist, ruft der Sidecar die Modelldatei aus dem S3-Bucket ab. Es führt die notwendigen Dateiverschiebungen durch und stellt sicher, dass die Ordnerstruktur den Erwartungen von Triton entspricht.
5. Modelle werden geladen: Der Sidecar platziert dann die Modelldateien im entsprechenden Ordner auf dem Triton-Volume und ruft die Triton-API auf, um das Modell zu laden. Das Modell wird nahtlos in den Triton Inference Server geladen, ohne dass ein Serverneustart oder manuelles Eingreifen erforderlich ist.

Durch die Nutzung dieser Integration ermöglicht Cookpad eine effiziente Modellbereitstellung von MLflow auf dem Triton Inference Server, was Skalierbarkeit und einfache Aktualisierungen ermöglicht, ohne den laufenden Inferenzbetrieb zu unterbrechen.

Nutzung von LLMs und Gen AI bei Cookpad

Cookpad untersucht aktiv die potenziellen Anwendungsfälle und Anwendungen von Sprachmodellen (LLMs) und generativer KI-Technologie (Gen AI) innerhalb seiner Plattform. Bestimmte Implementierungen befinden sich zwar noch in der Explorationsphase, aber hier sind einige Bereiche, in denen Cookpad plant, diese Fortschritte zu nutzen:

1. Vereinfachung der Rezepterstellung: Cookpad zielt darauf ab, die Barriere für Benutzer zu senken, Rezepte zu erstellen, indem es LLMs nutzt. Beispielsweise können Benutzer Spracherkennungsanwendungen auf ihren Smartphones verwenden, um beim Kochen Rezeptanweisungen zu diktieren. Die Transkriptionen werden dann über LLMs weitergeleitet, um einen formatierten Rezepttext zu generieren, wodurch der Aufwand für die genaue und effiziente Dokumentation von Rezepten reduziert wird.
2. Intelligente Zutatenerkennung: Cookpad plant die Integration von Gen-KI-Funktionen, damit Benutzer ein Foto von den Zutaten in ihrem Kühlschrank oder ihrer Speisekammer machen und sich nach Rezeptvorschlägen erkundigen können. Das KI-System würde die erkannten Zutaten identifizieren und mithilfe des Cookpad-Suchsystems Rezeptempfehlungen geben.
3. Rezeptunterstützung und Anpassung: Mithilfe von LLMs plant Cookpad, Funktionen zu entwickeln, die Unterstützung und Anpassung von Rezepten bieten. So können Benutzer beispielsweise den Ersatz oder die Änderung von Inhaltsstoffen beantragen, um sie an ihre Vorlieben oder die verfügbaren Zutaten anzupassen. Das auf LLM basierende System würde alternative Vorschläge unterbreiten und den Garvorgang rationalisieren.

Bei der Entwicklung und Implementierung dieser Anwendungsfälle legt Cookpad großen Wert auf den Schutz und die Einhaltung von Benutzerdaten.

Wir müssen diesen Prozess befolgen und sicherstellen, dass sie den Sicherheitsbestimmungen entsprechen.

Anpassung der MLOps-Architektur an Ihre Bedürfnisse

Wenn es darum geht, einen Echtzeit-Inferenzstapel mit MLOps aufzubauen, gibt es keinen einheitlichen Ansatz. Jose Navarro betont, wie wichtig es ist, die Architektur an die spezifischen Anforderungen und den Reifegrad der Praxis des maschinellen Lernens (ML) in einem Unternehmen anzupassen. Hier sind einige wichtige Erkenntnisse zu den wesentlichen Komponenten einer MLOps-Architektur:

1. Reife verstehen: Der aktuelle Stand der ML-Implementierung spielt eine entscheidende Rolle bei der Bestimmung der unverzichtbaren Komponenten. Befindet sich ein Unternehmen in einem frühen Stadium und konzentriert sich stark auf Experimente und Modellbereitstellung, kann der Schwerpunkt auf der Bereitstellung des Modells und dem Aufbau der Inferenzebene liegen. Auf der anderen Seite sind reproduzierbare Pipelines, Feature-Stores und die Beobachtbarkeit von Modellen von entscheidender Bedeutung für Unternehmen, deren ML-Modelle bereits in der Produktion sind und für das Unternehmen von entscheidender Bedeutung sind.
2. Vermeidung von Überkomplikationen: Jose schlägt vor, die Tendenz zu vermeiden, dem MLOps-Stack unnötige Tools oder Komponenten hinzuzufügen. Stattdessen ist es wichtig, sich auf Vereinfachung und Problemlösung durch Subtraktion zu konzentrieren. Durch das Entfernen unwesentlicher Elemente oder die Vereinfachung des Problems können Unternehmen oft schneller zu einer Lösung gelangen. Dieser Ansatz ermöglicht es Teams, der Wertschöpfung Priorität einzuräumen und die Auswirkungen ihrer ML-Initiativen zu bewerten, bevor sie Zeit in komplexe Tools investieren.
3. Einführung agiler Tools: Anstatt einer vordefinierten Liste von Must-Haves zu folgen, empfiehlt Jose, bei Bedarf Tools einzuführen. Identifizieren Sie zunächst die wichtigsten Herausforderungen und Anforderungen und führen Sie dann schrittweise Tools ein, die auf diese spezifischen Bedürfnisse zugeschnitten sind. Anstatt beispielsweise viel Zeit mit der Recherche und Integration eines Feature-Speichers zu verbringen, sollten Sie erwägen, einen schnellen Key-Value-Store mit einem Dienst wie DynamoDB aufzubauen, um das Projekt zu starten und seinen Wert zu bewerten. Dieser iterative Ansatz ermöglicht eine schnellere Validierung von ML-Initiativen und minimiert gleichzeitig unnötige Komplexität.

Lesen Sie unsere vorherigen Blogs in der True ML Talks-Reihe:

‍

True ML Talks #11 - LLMs, LLMops and Generative AI

Deep dive into LLMs, LLMops, Generative AI and ChatGPT. We talk with Micheal, CTO at GreenHouse about the trends in the Machne Learning Space.

TrueFoundry Blog TrueFoundry

Schaue weiter TrueML YouTube-Serie und das TrueML lesen Blog-Serie.

Wahre Gießerei ist ein ML Deployment PaaS über Kubernetes, um die Workflows von Entwicklern zu beschleunigen und ihnen gleichzeitig volle Flexibilität beim Testen und Bereitstellen von Modellen zu bieten und gleichzeitig die volle Sicherheit und Kontrolle für das Infra-Team zu gewährleisten. Über unsere Plattform ermöglichen wir Teams für maschinelles Lernen bereitstellen und überwachen Modelle innerhalb von 15 Minuten mit 100% iger Zuverlässigkeit, Skalierbarkeit und der Möglichkeit, innerhalb von Sekunden rückgängig zu machen. So können sie Kosten sparen und Modelle schneller für die Produktion freigeben, wodurch ein echter Geschäftswert erzielt wird.