Produktive ML-Modelle mit Kubernetes und KServe on-premises betreiben

Forschung & Entwicklung, Künstliche Intelligenz, Cloud

Barista Robots - Autonomous machines

KI-Modelle werden zunehmend in Produkten und Dienstleistungen eingesetzt. Durch die hohen Anforderungen und Komplexität dieser Modelle ist die Produktivsetzung jedoch oft eine Herausforderung. In diesem Blog zeigen wir, wie das Kubernetes Framework KServe die Bereitstellung von ML-Modellen auf der eigenen Infrastruktur vereinfacht und beschreiben die reproduzierbare Implementierung eines hochskalierbaren KI-Web-Servers. Als Beispiel dient ein eigens entwickeltes Retrieval-Augmented Generation System (RAG) auf das Basis von LangChain, das die spezifische Frage nach den Teilnehmern unserer NAVIGATE-Konferenz souverän beantwortet: "According to my sources, there were 850 Participants (a new record for the organizer), 54 Speakers ..."

Die Innovationen rund um Large Language Models (LLMs) und die quelloffene Bereitstellung von Foundation-Models, wie LLama-2, Falcon oder Bert, haben die Entwicklung von KI-Modellen in den letzten Jahren stark vorangetrieben. In der Praxis sind jedoch viele Herausforderungen zu meistern, um diese Modelle produktiv einzusetzen. Denn die Bereitstellung, Skalierung und Betrieb von KI-Systemen gestaltet sich oft komplex und erfordert spezialisierte Kenntnisse in den Bereichen DevOps und Cloud-Computing.

In unseren Projekten und F&E-Tätigkeiten durften wir bereits einige KI-Systeme in die Produktion entlassen, wie bspw. einen Code-Copilot auf der Basis von Llama-2. Dabei konnten wir die Erfahrung machen, dass sich die Cloud-Plattform Kubernetes bestens für die Produktivsetzung von KI-Anwendungen eignet. Insbesondere das KServe-Framework hat sich als leistungsstarkes Werkzeug erwiesen, um Machine-Learning-Modelle in Kubernetes-Clustern und eigenen Infrastrukturen zu betreiben. KServe bietet eine Vielzahl von Funktionen, die die Produktivsetzung von KI-Modellen erleichtern, wie z.B. automatische Skalierung, Monitoring und Logging. Durch die Verwendung dieser Tools können Unternehmen ihre KI-Modelle sicher und unabhängig von Cloud-Anbietern in eigenen produktiven Umgebungen betreiben, ohne Daten oder Modelle an Dritte weitergeben zu müssen.

In diesem Blog richten wir uns an Data Scientists als auch Cloud- bzw. MLOps-Engineers und möchten zeigen, wie KServe genutzt werden kann, um ein Retrieval-Augmented Generation (RAG) System in die Produktion zu überführen. Der entstehende Web-Server mit Model-Serving ist in der Lage, Anfragen in Echtzeit zu beantworten und bei Bedarf horizontal zu skalieren. Der Beitrag soll als leicht reproduzierbares Beispiel dienen, dass Grundlage für individuelle Anwendungsfälle mit KServe sein kann.

Die KServe Inferenzplattform

KServe bietet eine Plattform für das Deployment und Inferenz von KI-Modellen auf Kubernetes. Es entspringt dem Kubeflow-Projekt, von welchem es noch immer eine Kern-Komponente ist. Mittlerweile wird als eigenständiges Open-Source-Projekt von einer Vielzahl von Unternehmen und Entwicklern weiterentwickelt.

Einmalig und zentral bereitgestellt, kann sie - wie wir in diesem Beitrag zeigen werden - einfach und schnell durch Data Scientists für die Erstellung neuer Inferenzmodelle genutzt werden. Hierbei bietet KServe viele Features, die helfen, die komplexe Produktivsetzung von ML-Anwendungen zu vereinfachen, wie bspw:

Standardisierung: KServe kann in jedem Kubernetes-Cluster unabhängig von der Cloud genutzt werden. Durch standardisierte Inferenzprotokolle wird eine hohe Portabilität gewährleistet.
Skalierbare und effiziente Ressourcennutzung: Die Plattform skaliert Workloads automatisch basierend auf eingehenden Inferenz-Anfragen (inkl. scale-to-zero) und ist in der Lage, GPUs und TPUs zu nutzen.
Einfache und flexible Bereitstellung: KServe ermöglicht eine schnelle und unkomplizierte Bereitstellung neuer Modelle inklusive Pre- und Postprocessing, sowie Monitoring und Explainability. Fortgeschrittene Rollout-Funktionen wie Canary-Rollouts bieten zusätzliche Kontrolle und Sicherheit.

KServe eignet sich somit besonders für Unternehmen, die bereits Kubernetes-Cluster betreiben und regelmäßig ML-Modelle in die Produktion entlassen und dabei Unterstützung suchen.

kserve.drawio (1)

Die Inferenzplattform KServe basiert auf dem bekannten Serverless- bzw. Kubernetes-Framework KNative. Sie vereinfacht Modell-Deployments durch Standard-Spezifikationen und nützliche Features.

Installation und Konfiguration von KServe

Um KServe zu installieren, wird lediglich ein Kubernetes-Cluster benötigt. Dieses kann zum Nachstellen unseres Beispiels lokal mit Minikube oder Rancher-Desktop eingerichtet werden, oder in der Cloud mit Anbietern wie AWS, GCP oder Azure. Anschließend kann KServe mit einem einfachen Befehl installiert werden.

Nach kurzer Wartezeit sollte KServe installiert sein. Wir konfigurieren KServe passend zu unserem lokalen Setup, um die benötigten Dienste (“Servings”) lokal erreichen zu können. Hierfür passen wir die Konfiguration von Knative Serving und KServe wie folgt an:

Modelle, die mit KServe bereitgestellt werden, können nun über die URL http://localhost:31080 abgerufen werden.

Erstellen unseres RAG-LangChain-Sytems

KServe kann, wie zuvor erwähnt, mit einer Vielzahl von ML-Frameworks und Modellen genutzt werden und unterstützt diese ohne zusätzlichen Konfigurationsaufwand, wie dem Bauen eigener Images oder dem Schreiben von Code. In unserem Beispiel möchten wir jedoch ein eigenes, speziell entwickeltes KI-System bereitstellen und damit zeigen, dass KServe auch für nicht-standard Anwendungsfälle genutzt werden kann.

Als Beispiel für ein solches Modell nutzen wir ein Retrieval-Augmented Generation (RAG) System, das auf Basis von LangChain und LLama-2 betrieben wird. RAGs kombinieren die Stärken intelligenter Suchen bzw. Vektor-Embeddings und LLMs, um einen natürlichsprachlichen Zugang zur eigenen Wissensbasen zu erschließen (mehr dazu in unserem vorigen Blog). Es soll in der Lage sein, spezifische Fragen zu unserer NAVIGATE-Konferenz zu beantworten, indem es unsere NAVIGATE-Website als Wissensbasis nutzt.

RAG (1)

Die High-Level Architektur eines RAG-Systems. Im Detail nutzen wir LangChain - eine Open-Source-Bibliothek für die Entwicklung von KI-Systemen - um unser RAG-System zu implementieren. Es nutzt den llama.cpp Web-Server, um unser LLama-LLM bereitzustellen. Wir entscheiden uns für das Modell llama-2-7b-chat.Q4_K_M.gguf; eine optimierten bzw. quantized Chat-Version des LLama-2-Modells, das geringe Hardwareanforderungen stellt (Download hier). Unsere Wissensbasis wird durch eine in-memory FAISS-Datenbank angetrieben. Sie wird mit Dokumenten aus der Webseite der NAVIGATE-Konferenz gefüllt, die wir über einen Web-Loader abrufen, chunken und schließlich in einen Vektorraum embedden.

Das entsprechende Python-Skript, das die in oben dargelegte Architektur umsetzt, sieht wie folgt aus:

Das Skript stellt ein stark vereinfachtes aber funktionales Beispiel dar, das die Funktionsweise unseres KServe-RAG-Systems verdeutlicht. Vor einer echten Produktivsetzung bestünde weiterer Verbesserungsbedarf; so sollte bspw. eine zentrale Vektordatenbank wie Chroma oder Qdrant genutzt werden, um Redundanzen zu vermeiden und die Effizienz zu steigern. Zudem sollte die Qualität, Stabilität und Zuverlässigkeit des LangChain-Systems gründlich getestet und ggf. eigene zugeschnittene Komponenten entwickelt werden.

Bereitstellung eines Containers

Bevor wir ein eigenes KI-System per KServe bereitstellen können, müssen wir es containerisieren, also allen Anwendungscode inkl. Abhängigkeiten in ein isoliertes Softwareartefakt packen. Container sind zwingend notwendig, um Workloads in Kubernetes-Clustern ausführen zu können. Hierfür erstellen wir ein Dockerfile, das die notwendigen Abhängigkeiten installiert und unser Python-Skript ausführt. Zudem nutzen wir die KServe-Python-Bibliothek, um einen gültigen Einstiegspunkt für KServe bereitzustellen. Der hiermit gestartete Server leitet Anfragen an unsere LangChain-System weiter, das die Anfrage an die Vektordatenbank und das LLM steuert.

Der Einstiegscode für KServe, der einen kompatiblen Web-Server im Container startet, sieht wie folgt aus:

Das Dockerfile fügt die notwendigen Abhängigkeiten hinzu und kopiert das Modell sowie die zuvor definierten Skripte in den Container:

Das Image wird lokal gebaut mit: docker build -t my-registry.com/kserve-llama-rag:local ..

Erstellen des KServe-Servings

Um unsere containerisierte LangChain mit integriertem Llama-Server und Vektordatenbank in KServe bereitzustellen, erstellen wir mittels kubectl apply -f <isvc.yaml> einen sogenannten InferenceService, der auf unser Container-Image verweist. KServe wird sich fortan um die Skalierung und Bereitstellung unseres Modells kümmern. In dieser YAML-Datei lassen sich viele weitere Konfigurationen vornehmen, die das Model-Serving weiter anpassen und optimieren können.

Testen des Servings

Nachdem der InferenceService angelegt wurde, erstellt KServe die benötigten Kubernetes-Komponenten wie bspw. Pods, die das Modell hosten können. Hierfür senden wir eine Anfrage an die URL des Servings, die uns KServe bereitstellt. Der request-body enthält die gewünschte Anfrage und steuern mittels n_predict, wie viele Tokens das LLM in seiner Antwort generieren soll. Die Antwort enthält die vom Modell generierte Antwort auf unsere Anfrage. Da KServe virtuelles Routing nutzt, müssen wir in unserer lokalen Installation den Host-Header setzen, um die Anfrage an das richtige Serving weiterzuleiten. In einer produktiven Umgebung würde dies automatisch geschehen.

Anschließend erhalten wir ein Ergebnis im JSON-Format mit dem gewünschten und korrekten Ergebnis “result”. Zudem erhalten wir mit “source_documents” Auskunft darüber, welche Dokumente bzw. Textfragmente das RAG-System dem LLM vorzeigte, um die gestellte Frage zu beantworten. Hier offenbart sich im Übrigen ein Problem von RAGs, denn es wurden zwei Dokumente aus verschiedenen Jahren gefunden, die Auskunft über die Teilnehmenden erteilen. In unserem Beispiel hat das RAG lediglich zufällig das richtige Dokument herangezogen; im echten Szenario würde man explizit nach einem Jahr fragen oder Techniken wie Reranking und co verwenden. Nutzer:innen von RAGs sollten folglich eine gewisse Medienkompetenz besitzen, um die Systeme effizient bedienen zu können und zu wissen, wo Limitationen des Ansatzes liegen. Wir helfen gern im Rahmen unseres Seminars “Generative KI gezielt nutzen - die eigene Wissensbasis erschließen”.

Fazit und Ausblick

In diesem Blog zeigen wir, wie ein eigenes KI-System auf Basis von LangChain und KServe in die Produktion überführt werden kann. Dabei entstand ein skalierbarer, intelligenter Webserver, der in beliebigen Kubernetes- und Cloud-Umgebungen betrieben werden kann. Es wurde deutlich, dass KServe ein leistungsstarkes Werkzeug ist, das die Bereitstellung und Skalierung von ML-Modellen mit standardisierten Prozessen, nützlichen Funktionen, sowie performanten und hochskalierbaren Komponenten erleichtert, die für den produktiven Einsatz von KI-Systemen unerlässlich sind.

Trotzdem ist zu beachten, dass die Komplexität des Model-Servings sich durch die Nutzung von Kubernetes und KServe nicht auflöst, sondern eher in Richtung der Wartung und Skalierung von Kubernetes-Clustern verlagert. Es ist daher ratsam, ein spezialisiertes Plattform-Team zu etablieren, das sich auf die Wartung und Skalierung der Kubernetes-Cluster fokussiert, um die Verfügbarkeit und Sicherheit des Servings zu gewährleisten. Dies lohnt sich insbesondere für die unternehmensweite Etablierung einer KI-Infrastruktur und best-practices im Bereich der MLOps.

Testen und erweitern Sie doch gern unser Beispiel und erfahren, wie leicht es ist, ein erstes eigenes KI-System in die Produktion zu überführen. Wir freuen uns auf Ihr Feedback und stehen Ihnen bei Fragen gern zur Verfügung. Viel Erfolg bei der Produktivsetzung Ihrer KI-Modelle!