Autopilot: Automatisierung des Infrastrukturmanagements für GenAI

Was ist Autopilot

Machine-Learning-Operationen (MLOps) beinhalten oft komplexe, manuelle Prozesse, die Zeit und Ressourcen verbrauchen. Der Autopilot von Truefoundry zielt darauf ab, diese betrieblichen Belastungen zu beseitigen, sodass sich Entwickler ausschließlich auf das Schreiben von Code konzentrieren können und Datenwissenschaftler ihre Modelle verfeinern können. Autopilot kümmert sich automatisch um Ressourcenoptimierung und Zuverlässigkeitskorrekturen und sorgt für einen reibungslosen Arbeitsablauf mit minimalem menschlichem Eingreifen.

Warum brauchen wir das

Die betrieblichen Belange eines jeden Softwareentwicklungszyklus lassen sich in drei verschiedene Phasen unterteilen —

1. Tag 0 — Design und Planung: Definieren Sie vor der Bereitstellung Architektur, Bereitstellungsstrategien, Sicherheitsrichtlinien und Skalierungsframeworks.
2. Tag 1 — Bereitstellung und Implementierung: Richten Sie die Infrastruktur ein, stellen Sie Anwendungen bereit, konfigurieren Sie Observability und richten Sie CI/CD-Pipelines ein.
3. Tag 2 — Betrieb und Wartung: Überwachen Sie kontinuierlich Ressourcen, skalieren Sie sie automatisch, wenden Sie Sicherheitspatches an und kümmern Sie sich um das Vorfallmanagement.

Diese Prozesse wurden in drei verschiedenen Phasen implementiert, die von fragmentierten Verantwortlichkeiten bis hin zu automatisierter Effizienz führten.

Phase 1: Dev und Ops trennen

Dies ist die Phase, in der ein Team normalerweise beginnt. Die drei Betriebsphasen umfassen in dieser Phase in der Regel Folgendes.

• Tag 0: Die Entwickler konzentrieren sich auf das Anwendungsdesign, während sich die Betriebsteams um Infrastruktur und Sicherheit kümmern.
• Tag 1: Entwickler verpacken und bereiten die Anwendungen für die Bereitstellung vor, während sich das Betriebsteam auf die Bereitstellung von Ressourcen und deren Konfiguration konzentriert.
• Tag 2: Operations kümmert sich um Skalierung, Überwachung und Sicherheitspatches, während die Entwickler weiterhin Probleme beheben.

Diese Trennung der Verantwortlichkeiten führt zu unnötigen Reibungen zwischen den Entwicklungs- und Betriebsteams. Das Problem wird noch dadurch verschärft, dass die gemeinsame Nutzung von Kontexten aufgrund des begrenzten gemeinsamen Wortschatzes in einigen Fällen erschwert wird.

Für eine einzelne Anwendung kann dies zu einer anfänglichen Veröffentlichungszeit von mehreren Wochen führen, wobei jeder weitere Betrieb am zweiten Tag einige Tage in Anspruch nimmt, was zu unvermeidlichen Abstimmungsproblemen zwischen den Betriebs- und Entwicklungsteams führt.

Criteria	What should you evaluate ?	Priority	TrueFoundry
Latency	Adds <10ms p95 overhead for time-to-first-token?	Must Have	✅ Supported
Data Residency	Keeps logs within your region (EU/US)?	Depends on use case	✅ Supported
Latency-Based Routing	Automatically reroutes based on real-time latency/failures?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported

AI Gateway Evaluation Checklist

A practical guide used by platform & infra teams

Phase 2: Erstellung interner Plattformen

In Phase 2 verwendet eine Organisation eine interne Plattform, die es dem Entwicklungsteam ermöglicht, die meisten operativen Hebel nach eigenem Ermessen zu konfigurieren und zu steuern. Das Betriebsteam nimmt eine eher durchsetzende und standardisierende Rolle ein und nutzt dabei die Plattform als Orchestrierungsebene.

Diese Phase hat einige Nachteile -

• Für Entwickler bedeutet diese Phase, in der Anfangsphase viele Entscheidungen mit begrenztem Kontext oder relevantem Fachwissen zu treffen. Dies führt zu einer Erhöhung der kognitiven Belastung und einer suboptimalen Ressourcenplanung.
• Dieser Ansatz äußert sich in einer explosionsartigen Zunahme des Einsatzraums für das Einsatzteam. Ein typisches Team kann aufgrund einer Reihe suboptimaler Entscheidungen mit einem vielfachen Anstieg der Anzahl der Dienste und der Infrastrukturkosten konfrontiert werden.

Obwohl wir zunächst an Geschwindigkeit gewinnen, wird dies durch die explosionsartige Zunahme der Komplexität der Arbeit eines Entwicklungsteams ausgeglichen, worauf unweigerlich ein Konflikt der Bedenken zwischen den beiden Teams folgt.

Phase 3: Automatisierung der Plattform

In der dritten Phase beginnt die Plattform selbst, alle betrieblichen Belange zu automatisieren. Dadurch müssen nicht viele Entscheidungen in den drei Betriebsphasen getroffen werden.

Das bedeutet, dass die 3 Betriebsphasen am Tag 0 selbst erreicht werden können, ohne dass das Entwicklungs- oder das Betriebsteam operative Entscheidungen treffen muss. Genau das versucht der Autopilot zu tun.

Warum jetzt

Obwohl der Bedarf an mehr Automatisierung schon seit geraumer Zeit offensichtlich ist, wird ein System wie der Autopilot im aktuellen Szenario noch wichtiger, da die folgenden neuen Paradigmen ins Spiel kommen

Mikrodienste

Mit der breiten Einführung der Microservices-Architektur ist die Anzahl der Dienste in einer Organisation explosionsartig angestiegen. Diese Bequemlichkeit, Änderungen oder neue Dienste in die Produktion zu integrieren, hat die Kehrseite einer schwierigeren Überwachung. Der Autopilot ist ein System, das diese Dienste zuverlässig optimieren kann.

Agentische Systeme

Agentische Systeme sind Systeme, die autonom Aufgaben ausführen. Sie benötigen eine robuste, autarke Bereitstellungsstrategie mit einer unterstützenden Infrastruktur, die flexibel genug ist, um bei Bedarf dynamisch hoch- und herunterskaliert werden zu können. KI-Agenten auf dem neuesten Stand der Technik sind auf eine anpassungsfähige, effiziente Infrastruktur angewiesen, um optimal zu funktionieren. Dies sind dynamische Systeme, die ein unterschiedliches Maß an menschlicher Beteiligung erfordern. Die breite Einführung solcher Systeme kann nur mit einem System möglich sein, bei dem alle betrieblichen Aspekte automatisiert sind, und genau hier kommt der Autopilot ins Spiel

Fallstudie

Für einen der Nutzer der Truefoundry-Plattform waren die Kosten für Entwicklungscluster ein großes Problem. Bei rund 200 bereitgestellten Diensten war dies ein typischer Fall, bei dem sich mehrere Dienste ansammelten, wobei sich kleine Ineffizienzen anhäuften und zu einem massiven Gesamtkostenanstieg führten. Jeder Versuch einer Kostenoptimierung müsste auf der Ebene der einzelnen Dienste erfolgen. Diese extreme Arbeitsanforderung führte dazu, dass sich die Kostenüberschreitung verschlimmerte und nie zu einer Priorität wurde.

Nach der Aktivierung des Autopiloten konnte dieser Kunde in nur 2 Clustern Kosteneinsparungen von 1500$ erzielen. Darüber hinaus wurden über 50 Fehlerbehebungen im Zusammenhang mit der Zuverlässigkeit vorgenommen, wenn die Workloads entweder zu wenig CPU-fähig waren oder Probleme im Zusammenhang mit Speicherproblemen auftraten

‍

Was kann Autopilot derzeit

‍

CPU-, Speicher- und Speicheroptimierung

Der Autopilot automatisiert die CPU- und Speicherkonfiguration für eine Anwendung. Der Autopilot macht das, indem er sich zwei Eingangsquellen anschaut -

• Historische Nutzung: Der Autopilot untersucht die historische Nutzung einer Anwendung, um in Zukunft mit einer optimalen Konfiguration zurückzukehren
• Anpassungen in Echtzeit: Der Autopilot reagiert auch auf Warnungen und andere Quellen von Ereignissen, um in Echtzeit Abhilfe zu schaffen und ein Problem im Keim zu ersticken. Dies führt zu einer Verbesserung der MTTR und verhindert proaktiv viele Probleme, die sonst viel größer werden würden.

Cluster-Gesundheit

Autopilot kümmert sich auch um den Zustand und die Kosten der einzelnen Komponenten, die in einem Cluster installiert sind, wie Istio, ArgoCD, Carpenter usw. Der Ausfall einer dieser Komponenten kann katastrophale Folgen für die auf diesem Cluster ausgeführten Workloads haben. Autopilot stellt sicher, dass diese Komponenten kostenoptimal laufen und gleichzeitig weiterhin funktionieren, indem proaktiv nach Ressourcenspitzen gesucht und diese berücksichtigt werden.

Knotenkapazität

Autopilot geht über die Dienste hinaus und optimiert auch die Infrastruktur, die den laufenden Diensten zugrunde liegt. Das bedeutet, die Knotenkapazität zu empfehlen, die für eine Anwendung ideal ist. Dabei werden die Anwendungsmetriken, die Umgebung und andere Faktoren berücksichtigt.

Automatische Skalierung

Viele Entwicklungsteams entscheiden sich dafür, ihre Anwendungen für die maximale Belastung zu skalieren, der eine Anwendung voraussichtlich ausgesetzt sein wird. Dies führt zu hohen zusätzlichen Kosten, wenn diese zusätzlichen Replikate nicht verwendet werden. Eine naheliegende Lösung ist die Implementierung von Autoscaling, aber selbst das ist nicht anwendbar, wenn die Verkehrsmuster unvorhersehbar sind. Der Autopilot durchläuft die historischen Kennzahlen für jeden Dienst und generiert eine Empfehlung für die Aktivierung oder Deaktivierung der automatischen Skalierung, die auf dem historischen Charakter der Anwendung basiert.

‍

Was kommt als Nächstes

Obwohl wir bei der Verwendung des Autopiloten in der Produktion bereits viele Vorteile in Bezug auf Kosten und Zuverlässigkeit sehen, muss noch viel mehr getan werden, um die zuvor festgelegte vollständige Automatisierungsvision zu verwirklichen. Einige betriebliche Aspekte, die es wert sind, als Nächstes automatisiert zu werden, sind:

• Periodische Autoskalierung — Durch die Vorhersage und Implementierung von periodischem Autoscaling unter Berücksichtigung des historischen Datenverkehrs können wir Autoscaling auch für hohe Workloads aktivieren.
• Empfehlung zur automatischen Abschaltung — Das Herausfiltern und Herunterfahren von Diensten oder Workloads, die nicht genutzt werden, kann zu massiven Kosteneinsparungen führen
• Automatisches Benchmarking — Eine Schätzung der Ressourcen eines Dienstes ist zwar bereits möglich, eine bessere Schätzung kann jedoch vorgenommen werden, indem die Benchmarks mit Live- oder simuliertem Traffic ausgeführt und die betroffenen Geschäftskennzahlen beobachtet werden. Autopilot versucht, diesen Prozess zu automatisieren, was für die meisten Entwicklungsteams sehr zeitaufwändig sein kann.
• Cluster-Infrastrukturoptimierung — Die Cluster-CPU-Auslastung liegt branchenweit im Durchschnitt bei 10% Verknüpfung . Die Fehlkonfiguration von CPU-Anwendungen macht zwar einen erheblichen Teil davon aus, aber ein großer Teil ist auch auf die Ineffizienzen bei der Lastverteilung auf der zugrunde liegenden Infrastruktur zurückzuführen. Dies kann in Form von vielen nicht ausgelasteten Knoten geschehen, zu viele kleine Knoten, die Speicherplatz für Daemonsets usw. verschwenden. Die Korrektur der Infrastruktur-Bereitstellungskonfigurationen und die Nutzung von Tools wie Karpenter auf Cloud-Ebene können viel dazu beitragen, diesen Aspekt zu verbessern.

Fazit

Der Autopilot von Truefoundry ist ein transformatives Tool in der Entwicklung von MLOps, das kritische betriebliche Herausforderungen im gesamten Softwareentwicklungszyklus bewältigt. Autopilot ermöglicht es Teams, sich auf Innovationen statt auf den operativen Aufwand zu konzentrieren, indem die Ressourcenoptimierung, das Cluster-Integritätsmanagement und die automatische Skalierung automatisiert werden. Da die Einführung von Microservices und Agentensystemen weiter zunimmt, wird eine solche Automatisierung immer dringender. Mit seinen aktuellen Funktionen und seiner ehrgeizigen Roadmap ist Autopilot bereit, die Art und Weise, wie Unternehmen an betriebliche Effizienz, Zuverlässigkeit und Kostenoptimierung herangehen, zu revolutionieren.

‍