Articles

Zugänglich für alle

Das 8B-Modell von Llama 3.1 stellt einen großen Fortschritt für Hardware in Verbraucherqualität dar. Es übertrifft die Leistung von GPT 3.5 bei vielen Benchmarks und kann gleichzeitig lokal und kostenlos betrieben werden. Dieser Fortschritt ermöglicht es Entwicklern und Forschern, auf dem neuesten Stand der Technik zu sein, und gibt ihnen die Möglichkeit, Innovationen zu entwickeln, ohne eine teure Infrastruktur zu benötigen.

Wichtige Verbesserungen

Llama 3.1 enthält mehrere wichtige Verbesserungen:

• 128K Kontext Länge für alle Modelle: Dies ermöglicht eine bessere Verarbeitung längerer Eingaben, wodurch komplexere Aufgaben und längere Unterhaltungen möglich sind.
• Mehrsprachige Unterstützung für acht Sprachen: Dies erweitert die Verwendbarkeit des Modells in verschiedenen sprachlichen Kontexten und macht es vielseitiger und umfassender einsetzbar.
• Verbesserte Fähigkeiten zur Argumentation und zum Einsatz von Werkzeugen: Durch diese Anpassung ist das Modell besser in der Lage, logische Schlussfolgerungen zu ziehen und sogar externe Tools effektiv zu nutzen.
• Verbesserte Befolgung von Anweisungen und Chat-Leistung: Das Modell versteht jetzt Anweisungen besser und führt sie aus, was zu genaueren und kohärenten Antworten in Chat-Anwendungen führt.

Was dies für die Zukunft bedeutet

Die Veröffentlichung von Llama 3.1, insbesondere des 405B-Modells, stellt einen wichtigen Meilenstein in der Open-Source-KI dar. Sie verspricht, Innovationen zu beschleunigen, neue Anwendungen zu ermöglichen und die Grenzen dessen, was mit lokal betriebenen Modellen möglich ist, zu erweitern. Wenn sich dieser Trend fortsetzt, können wir davon ausgehen, dass in naher Zukunft noch leistungsfähigere und leichter zugängliche KI-Tools auf den Markt kommen werden.

Stay tuned, wenn die Community beginnt, diese bahnbrechenden Modelle zu erforschen und auszubauen!

Bereitstellung von Rechenressourcen

Um Ressourcen gut nutzen zu können, hat sich im letzten Jahrzehnt Container-Technologie als gewinnbringendes Konzept herausgestellt. Hierbei werden einzelne Prozesse durch Linux-Kernel-Features voneinander abgekapselt, was eine gemeinsame Nutzung von Rechenressourcen durch voneinander unabhängige Prozesse erleichtert. Wesentlich für die Nutzung von Container-Technologie ist, dass einzelne Container jederzeit (etwa auf einem anderen Rechner) neu gestartet werden können, da so eine orchestrierte hohe Auslastung der verfügbaren Rechenzeit erreicht wird. Der de-facto-Standard für die Orchestrierung von Containern ist das Open-Source-System Kubernetes, das bei guter Konfiguration eine Schnittstelle für Entwickler zum einfachen Deployment von Containern (und anderen Ressourcen) bereitstellt.

Da eine gute Konfiguration eines Kubernetes-Clusters eine relativ komplexe Aufgabe ist, sollte hierfür ein spezialisiertes Team etabliert werden, dass sich unter anderem mit der Netzwerkarchitektur, Kommunikation zwischen Containern, Secret Management und grundlegendem Logging und Monitoring in Zusammenhang mit Kubernetes beschäftigt.

Netzwerk-Konnektivität

Die innere Einfachheit von Microservices wird dadurch erkauft, dass viel Komplexität in die Kommunikation zwischen Services verlagert wird. Dafür ist es wichtig, dass Microservices eine Netzwerkverbindung zueinander und in Richtung Internet aufbauen können. Die Verbindung sollte automatisch durch mTLS abgesichert werden. Diese Automatisierung kann am besten auch durch ein zentrales Infrastruktur-Team gewährleistet werden.

Auch grundlegende Allow-Lists für den Zugriff auf Services sollten durch die Microservice-Teams einfach eingerichtet werden können, und gegebenenfalls sollten aus Compliance-Gründen manche Netzwerkregeln durch das Infrastruktur-Team verbindlich festgesetzt werden. Die Kommunikation zwischen Microservices ist erheblich leichter zu erreichen, wenn die Infrastruktur bei einem einzelnen Cloud-Provider gehostet wird.

Persistenz

Microservice-Container sollten jederzeit neu gestartet werden können, ohne Daten zu verlieren. Das impliziert, dass persistente Datenhaltung außerhalb der Microservices stattfinden muss, typischerweise in Datenbanken oder in persistenten Volumes. Neben allgemeinen Schwierigkeiten wie Authentifizierung und Autorisierung, sowie der Konnektivität zu den Datenhaltungssystemen bestehen hier spezialisierte Herausforderungen wie die Erstellung von Daten-Backups und Snapshots, um die Wiederherstellbarkeit persistenter Daten gewährleisten zu können.

Für verschiedene Bedürfnisse sollten verschiedene Typen von Datenbanken zur Verfügung gestellt werden, aus denen Microservice-Teams auswählen können: etwa eine SQL-Datenbank, eine Dokumentendatenbank und ein Cache-System. Das ist wichtig, um die Technologieoffenheit bei der Umsetzung von Microservices zu gewährleisten, sodass die Microservice-Teams die beste Technologie für ihren Anwendungsfall auswählen können.

Die Bereitstellung von Datenbanken oder Volumes sollte möglichst automatisiert erfolgen, wofür eine enge Zusammenarbeit mit dem Kubernetes-Team notwendig ist.

API-Design

Je nach Microservice können die Anforderungen an die APIs zur Kommunikation mit dem Microservice sehr unterschiedlich sein. Dennoch kann es sinnvoll sein, gemeinsame Anforderungen an die API-Struktur (beispielsweise HATEOAS oder gRPC) zu stellen, die nur in begründeten Ausnahmefällen nicht berücksichtigt werden. Für HTTP-APIs kann OpenAPI eine gute Lösung für die Dokumentation darstellen.

Gegebenenfalls kann man sich dafür entscheiden, die Bereitstellung von OpenAPI-Spezifikationen für Microservices verpflichtend zu gestalten, sodass sich die Entwickler von Clients auf die Existenz dieser Spezifikationen verlassen können. In jedem Fall sollte ein gemeinsames Schema für die Dokumentation von APIs (inklusive Fehlerfällen) geschaffen werden, damit es einfacher wird, relevante Dokumentation zu finden.

Messaging

Asynchrone Kommunikation über Messaging-Systeme kann wesentlich dabei helfen, das Gesamtsystem resilient zu gestalten. Die durch die Asynchronität entstehende temporäre Inkonsistenz bei der Datenhaltung wird bewusst in Kauf genommen („Eventual Consistency“), um schnellere Requests und eine Entkopplung verschiedener Microservices zu erreichen.

Damit Kommunikation über Messaging zwischen verschiedenen Microservices funktioniert, sollte das Messaging-System selbst von einem zentralen Team bereitgestellt und verwaltet werden. Das Format der Messages sollte wie bei den APIs mithilfe eines gemeinsamen Schemas dokumentiert werden.

Authentifizierung und Autorisierung

Authentifizierung und Autorisierung sind zentrale Aufgaben, die nicht von einzelnen Microservice-Teams erledigt werden können. Hierfür sollte eine zentrale Lösung, beispielsweise basierend auf OpenID, bereitgestellt werden.

Zusammenfassung

Eine Microservice-Architektur kann gerade für komplexe Systeme eine gute Lösung sein, um schnell Verbesserungen am System sowie neue Features zu implementieren. Dadurch entstehen allerdings Abhängigkeiten zwischen Microservices und somit auch zwischen den Microservice-Teams.

Die hier beschriebenen Querschnittskonzepte helfen dabei, Konsistenz, Sicherheit und Effizienz in einem Microservice-Umfeld sicherzustellen.

Microservices werden durch die folgenden Eigenschaften charakterisiert:

• Single Purpose: Wie bei den Unix-Prinzipien sollte ein Microservice genau eine Aufgabe gut erfüllen.

• Encapsulation: Microservices haben das alleinige Eigentum an ihren Daten. Sie interagieren mit der Außenwelt über wohldefinierte Schnittstellen.

• Ownership: Ein einzelnes Team (bestenfalls bestehend aus 5-9 Personen) ist verantwortlich für einen Microservice über seine gesamte Lebenszeit.

• Autonomy: Das für den Microservice zuständige Team darf ohne Absprache zu jeder Zeit den Microservice bauen und deployen. Das Team ist frei in Implementationsentscheidungen.

• Multiple Versions: Es ist möglich, dass zur gleichen Zeit verschiedene Versionen eines Microservices existieren.

• Choreography: Es gibt kein zentralisiertes System, das einen Workflow orchestriert. Stattdessen ist jeder Microservice in der Lage sich selbstständig mit den Informationen zu versorgen, die er für seine Funktionalität braucht.

• Eventual consistency: Eine kurzzeitige Inkonsistenz von Daten zwischen Microservices ist akzeptiert, solange die Daten schließlich wieder konsistent werden.

Herausforderungen von Microservices

Microservices sind durch ihre innere Einfachheit generell besser skalierbar und leichter und schneller zu ändern als Monolithen, in denen die gesamte Logik in einem einzelnen Programm enthalten ist. Durch die kleinen Teams fühlen sich (und sind) Microservice-Teams deutlich stärker für den Erfolg ihrer Microservices verantwortlich, was häufig zu besseren Ergebnissen und Entscheidungen führt.

Microservices erleichtern Omnichannel-Lösungen durch geteilte Backend-Funktionalität, die von verschiedenen Benutzerschnittstellen konsumiert werden können.

Erhöhte Komplexität

Auf der Ebene einzelner Microservices schaffen wir uns durch den begrenzten Aufgabenbereich und die Kapselung eine einfache und schöne Welt, doch TANSTAAFL!³ Die innere Einfachheit von Microservices wird erkauft durch die erhöhte Komplexität in Bezug auf die Kommunikation zwischen Microservices sowie eine gewisse Redundanz: Da die Microservice-Teams vollständig für ihre Services verantwortlich sind (Ownership) und sie auch selbstständig deployen können (Autonomy), müssen sie technisch dazu in der Lage sein, dieses Deployment tatsächlich durchzuführen. Das schließt sowohl Kompetenzen in Bezug auf Cloud-Infrastruktur ein als auch die Ressourcen, die für den Betrieb der Infrastruktur notwendig sind.

Konkreter können wir uns einen Mailing-Service vorstellen, der dafür zuständig ist, Informationsmails über ein Produkt an Kunden zu versenden. Der Service muss im Laufe der Entwicklung gebaut und dann auch ausgeführt werden. Die dafür verwendeten Computer müssen die notwendige Konnektivität haben, um diese Aufgaben durchzuführen. Sobald der Service läuft, müssen andere Services dazu in der Lage sein, den E-Mail-Prozess in Gang zu setzen. Mögliche Wege hierfür sind beispielsweise ein Event-System, aus dem der Mailing-Service selbstständig (im Sinne der Eigenschaft Choreography) die für ihn relevanten Events herausfiltert und zu E-Mails weiterverarbeitet.

So ein Event-System oder Messaging-System muss aber zum einen bereitgestellt werden und zum anderen von verschiedenen Teams mit ihren jeweiligen Microservices genutzt werden können. Ein anderes denkbares Szenario wäre die Ansprache des Mailing-Services via REST-Schnittstelle. In diesem Fall muss der Client dazu in der Lage sein, über ein Netzwerk mit unserem Mailing-Service zu kommunizieren, und diese Verbindung muss so abgesichert sein, dass nur autorisierte Services Zugriff auf die Schnittstelle bekommen.

Zusammenfassung

Die beschriebenen Herausforderungen zeigen, dass es einige Punkte gibt, an denen wir serviceübergreifend für Einheitlichkeit sorgen sollten. Manche dieser Punkte werden wir in diesem Artikel genauer unter die Lupe nehmen. Elemente der Softwarearchitektur, die (potenziell) für mehrere Bausteine der Architektur (in unserem konkreten Fall also Microservices) relevant sind, nennt man Querschnittskonzepte.

Um Redundanz zu vermeiden, sollten solche Querschnittskonzepte in der übergreifenden Architekturdokumentation behandelt werden, unabhängig von den einzelnen Komponenten. Es ist wichtig, Querschnittskonzepte frühzeitig festzulegen, da eine Migration zu einem späteren Zeit viel Kapazität über alle Teams hinweg in Anspruch nimmt.

Im Folgenden werfen wir einen Blick in die spannende Zukunft von MLOps. Wir betrachten aufkommende Trends, die die technische Landschaft umgestalten werden, und beleuchten die Herausforderungen, denen sich Unternehmen stellen müssen, um erfolgreiche Implementierungen von Maschinellem Lernen sicherzustellen.

Herausforderungen meistern: Aufbau eines soliden MLOps-Grundgerüsts

Auch wenn die Zukunft von MLOps sehr verheißungsvoll erscheint, müssen zahlreiche Herausforderungen bewältigt werden, um einen erfolgreichen Einsatz von ML zu gewährleisten. 

Hierbei sind einige wesentliche Schlüsselbereiche zu berücksichtigen:

• Standardisierung und Interoperabilität: Die fehlende Standardisierung von MLOps-Tools und -Frameworks kann zu Insellösungen führen und die Zusammenarbeit erschweren. Die Förderung der Interoperabilität zwischen Tools und die Einführung von Best Practices für MLOps-Workflows sind entscheidend für die Schaffung eines einheitlicheren und effizienteren Ökosystems. Ein erster Ansatz, um diesem Missstand zu begegnen, ist das Open Inference Protocol, eine industrieweite Anstrengung, die darauf abzielt ein standardisiertes Kommunikationsprotokoll zwischen sogenannten Inferenzservern (z.B. Seldon MLServer, NVIDIA Triton Inference Server) und orchestrating frameworks wie Seldon Core oder KServe zu etablieren.

• Nachwuchsmangel: Die Nachfrage nach qualifizierten MLOps-Fachkräften übersteigt das verfügbare Angebot. So stieg die Anzahl der offenen Stellen für IT-Fachkräfte in Unternehmen in Deutschland laut Statista im Jahr 2023 auf das Rekordhoch von 149.000, und Index Research berichtet, dass von Januar bis April 2023 Arbeitgeber fast 44.000 Stellen für KI-Experten ausschrieben. Um diese Lücke zu verkleinern und ein starkes MLOps-Team aufzubauen, müssen Unternehmen erheblich in Schulungsprogramme, Strategien zur Talentgewinnung und eine wettbewerbsfähige Mitarbeitervergütung investieren. Dieser Prozess umfasst das Erkennen der wesentlichen Fähigkeiten und Fachkenntnisse, die für eine erfolgreiche MLOps-Implementierung erforderlich sind, wie zum Beispiel Data Science, Software Engineering, Cloud Computing und DevOps. Ferner beinhaltet er die Zusammenstellung interdisziplinärer Teams, die diese verschiedenen Disziplinen abdecken.

• Monitoring und Beobachtbarkeit: Die effektive Überwachung der Leistung und des Zustands von ML-Modellen in der Produktion ist entscheidend, um Probleme frühzeitig zu erkennen und die Zuverlässigkeit des Modells zu gewährleisten. Die Entwicklung robuster Monitoring-Systeme und deren Integration in MLOps-Pipelines ist von entscheidender Bedeutung. Aporia, eine ML-Plattform, die sich die Beobachtbarkeit von ML-Modellen zum Ziel gesetzt hat, kann zu diesem Zweck eingesetzt werden.

• Modellverwaltung: Die Schaffung klarer Governance-Rahmen für die Verwaltung des Lebenszyklus von ML-Modellen ist unerlässlich. Dazu gehören die Festlegung von Rollen und Zuständigkeiten, die Sicherstellung der Modellversionierung und -kontrolle sowie die Festlegung von Richtlinien für die Bereitstellung und Stilllegung von Modellen. Beispiele für Lösungen bzw. Plattformen, die diese Eigenschaften zusammen mit vielen anderen des ML lifecycles ganzheitlich abbilden, sind die Enterprise Plattformen Domino Data Lab sowie Dataiku.

• Erklärbarkeit und Erkennung von Bias:  Wie bereits erwähnt, sind die Gewährleistung der Erklärbarkeit von Modellen und die Erkennung potenzieller Vorurteile entscheidende Aspekte einer verantwortungsbewussten KI. Unternehmen müssen in Tools und Techniken investieren, um zu verstehen, wie Modelle zu ihren Entscheidungen kommen, und um etwaige Fairnessprobleme zu identifizieren und zu entschärfen.