Treiben KI-Workloads Ihre Cloud-Rechnung in die Höhe?

Auf Geschwindigkeit ausgelegt: ~ 10 ms Latenz, auch unter Last
Unglaublich schnelle Methode zum Erstellen, Verfolgen und Bereitstellen Ihrer Modelle!
- Verarbeitet mehr als 350 RPS auf nur 1 vCPU — kein Tuning erforderlich
- Produktionsbereit mit vollem Unternehmenssupport
Wir sind fest davon überzeugt, dass jedes Unternehmen in den kommenden Jahren zu einem Machine-Learning-Unternehmen (ML) werden wird. Während Unternehmen ML zunehmend integrieren, stellt die Verwaltung der damit verbundenen Cloud-Kosten eine der größten Herausforderungen dar. Der Betrieb von KI/ML-Workloads in der Cloud kann schnell teuer werden, doch mit sorgfältiger Planung und Optimierung lassen sich diese Kosten erheblich senken.
In diesem Blogbeitrag untersuchen wir verschiedene Strategien, mit denen Sie Ihre KI-Infrastruktur optimieren und letztlich Ihre Cloud-Ausgaben senken können, ohne dabei Kompromisse bei Leistung oder Skalierbarkeit einzugehen. Nachfolgend finden Sie die wichtigsten Kategorien, die es zu berücksichtigen gilt:
- Messen und zuordnen
- Senkung der Rechenkosten durch Nutzung von Spot- oder Reserved-Instanzen
- Wahl der richtigen Bereitstellungsarchitektur
- Implementierung von Autoscaling
- Colocation von Rechenleistung und Daten
- Umstieg auf gehostete Notebooks mit automatischer Abschaltung anstelle dedizierter VMs für jeden Entwickler
- Verwendung von Checkpointing bei lang laufenden Trainingsjobs, um diese bei Bedarf fortsetzen zu können.
- Effiziente GPU-Auslastung
Messen und zuordnen
Nach der Zusammenarbeit mit zahlreichen Unternehmen und basierend auf unserer eigenen Erfahrung wissen wir, dass ein Großteil der Kosten auf menschliche Fehler zurückzuführen ist – etwa das Vergessen des Abschaltens von VMs oder Diensten sowie fehlerhafte Architekturdesigns, die unnötige Kosten verursachen. Eine vollständige Transparenz darüber, wer für was verantwortlich ist und welche Kosten pro Team oder Projekt anfallen, hilft dabei, Kostenfallen schneller zu identifizieren und sorgt dafür, dass jeder die Verantwortung für seine eigenen Projekte übernimmt.
Was man nicht messen kann, kann man nicht verbessern

Der erste Schritt zur Optimierung von ML-Workloads besteht darin, mit der Messung und der verursachergerechten Zuordnung zu beginnen. Hier sind einige Initiativen, die Sie ergreifen können:
- Kosten auf Ebene einzelner Microservices, Projekte oder Teams nachverfolgenhandelt.
- Kostentransparenz für alle Entwickler schaffen und sicherstellen, dass sie in die Lage versetzt werden, Kosten zu verstehen und zu senken.
- Cloud-Kosten-Benachrichtigungen einrichten.
- Tools wie Infracost.io verwenden, um die Kosten der Infrastruktur vor der Bereitstellung zu ermitteln, falls Sie Terraform einsetzen.
Rechenkosten senken
ML-Workloads verursachen enorme Rechenkosten, vor allem weil sie hohe Rechenressourcen erfordern – entweder hohe CPU-Anforderungen oder GPUs, die beide sehr teuer sind. Im Folgenden finden Sie einige Schritte, mit denen Sie Ihre Rechenkosten senken können:
- Modell-Destillation und -Pruning um den Ressourcenbedarf Ihres Modells zu reduzieren
- Verwendung von Reserved- und Spot-Instanzen um Kosten zu sparen. Laut Amazon können Sie mit EC2 Spot-Instanzen im Vergleich zu On-Demand-Instanzen potenziell bis zu 90 % der Kosten einsparen.
- Wählen Sie die richtige Ressourcenkonfiguration: Wir haben häufig festgestellt, dass ML-Teams die Ressourcen für ML-Dienste und Trainingsaufträge überdimensionieren. Dies kann bedeuten, dass bei der Arbeit mit VMs der falsche Instanztyp gewählt wird oder die Anforderungen an CPU und Arbeitsspeicher falsch eingeschätzt werden. Es ist wichtig, einen Überblick über die angeforderte und tatsächlich genutzte CPU/Speicherkapazität zu erhalten, um die Werte für optimale Kosten anpassen zu können.

👉
Spot-Instanz: Eine Spot-Instanz ermöglicht es Ihnen, auf ungenutzte EC2-Kapazitäten zu einem stark reduzierten Preis zuzugreifen und diese zu nutzen.
Wenn Sie eine Spot-Instanz starten, legen Sie einen Höchstpreis fest, den Sie pro Stunde zu zahlen bereit sind. Wenn der Spot-Preis für den von Ihnen angeforderten Instanztyp und die Availability Zone unter Ihrem Höchstpreis liegt, wird Ihre Instanz gestartet. Sollte der Spot-Preis für diesen Instanztyp und diese Availability Zone jedoch über Ihren Höchstpreis steigen, kann Ihre Instanz mit einer Vorankündigung von zwei Minuten beendet werden.
👉
Reserved-Instanz: Hierbei verpflichten Sie sich, eine bestimmte Menge an EC2-Kapazität für einen festgelegten Zeitraum zu nutzen. Im Gegenzug erhalten Sie einen erheblichen Rabatt auf den On-Demand-Preis dieser Kapazität.
Wir haben eine Vergleichsstudie für die Region US East (N. Virginia) durchgeführt und Folgendes festgestellt:
- Spot-Instanzen waren zu einem 44 % bis 62 % günstigeren Preis verfügbar.
- 1-jährige Reserved-Instanzen sind zu einem 14 % bis 37 % günstigeren Preis verfügbar.

Wählen Sie die optimale Bereitstellungsarchitektur
Unterschiedliche ML-Anwendungsfälle erfordern unterschiedliche Architekturen, und die Wahl des falschen Designs kann hier zu massiven Kostenunterschieden führen. Einige der häufigsten Anwendungsfälle und Fehler, die wir beobachtet haben, sind:
- Echtzeit-Inferenz: In diesem Fall liegt die Latenz der Modell-Inferenz unter 1-2 Sekunden (oft im Millisekundenbereich) und das Verkehrsaufkommen ist hoch. Das Modell sollte bereitgestellt werden als Echtzeit-Autoscaling-API und wir haben meist festgestellt, dass Anfragen pro Sekunde eine bessere Metrik für das Autoscaling sind als CPU oder Arbeitsspeicher in vielen ML-Anwendungsfällen. Wenn das Verkehrsaufkommen sprunghaft ist (z. B. 2-3 Stunden am Tag) und das Modell klein ist, erweist sich eine serverlose Bereitstellung (AWS Lambda) als kostengünstigere Bereitstellungsart.
- Asynchrone Inferenz: In diesem Fall kann die Verarbeitungslogik einige Sekunden in Anspruch nehmen und es muss eine Warteschlange für eine bessere Zuverlässigkeit bereitgestellt werden – andernfalls führt dies zu Fehlern und geschäftlichen Einbußen. Für Autoscaling ist die Warteschlangenlänge eine gute Metrik in diesen Anwendungsfällen.
- Mehrere kleine Modelle mit sprunghaftem Verkehrsaufkommen: Dies ist ein häufiger Anwendungsfall in vielen Unternehmen, in denen Modelle kundenspezifisch sind. In diesem Fall gibt es eine große Anzahl von Modellen, von denen jedes ein geringes Verkehrsaufkommen erhält und die Latenzerwartungen recht niedrig sind. Hierbei hostet ein Container mehrere Modelle, und die Modelle werden je nach Bedarf dynamisch in den Arbeitsspeicher geladen und wieder entladen. Es gibt hier Herausforderungen in Bezug darauf, welche Modelle bereits in welchen Pods geladen sind und die Anfragen müssen entsprechend weitergeleitet werden.
- Ressourcenintensive, seltene Verarbeitung/Cron-Jobs: Dies kann der Anwendungsfall sein, wenn Modelle dynamisch basierend auf bestimmten Benutzeraktionen trainiert werden. In diesem Fall funktioniert die asynchrone Inferenz möglicherweise nicht, da der Verarbeitungsprozess Minuten dauern kann. Hier sollte die Verarbeitung als Job an einen Workflow-Orchestrator übermittelt werden und die Echtzeit-Updates des Jobs sollten an eine Benachrichtigungswarteschlange gemeldet werden.
Oftmals kann die Abbildung eines dieser Anwendungsfälle in einer anderen Architektur zu einem Verlust an Zuverlässigkeit, zusätzlicher Latenz oder hohen Cloud-Rechnungen führen.
Autoscaling implementieren
Viele gehen davon aus, dass Autoscaling nur dann nützlich ist, wenn ein hohes Verkehrsaufkommen herrscht und Maschinen basierend auf dem eingehenden Datenverkehr hoch- oder runtergefahren werden müssen. Wir möchten das Konzept des Autoscaling jedoch auch auf Entwicklungsumgebungen ausweiten, um Kosten zu sparen. Einige Bereiche, in denen Autoscaling helfen kann, die Kosten drastisch zu senken, sind:
- Skalieren Sie Ihren Rechenbedarf automatisch basierend auf der Nachfrage: Nutzen Sie die Autoscaling-Funktionen, um die Größe Ihrer Infrastruktur dynamisch an die Arbeitslast anzupassen. Durch automatisches Hoch- oder Herunterskalieren können Sie die Ressourcennutzung optimieren und Kosten in Zeiten geringer Aktivität senken. Identifizieren Sie geeignete Skalierungsschwellenwerte und Trigger basierend auf Ihren Arbeitslastmustern, um eine optimale Ressourcenzuweisung sicherzustellen.
- Skalieren Sie die Infrastruktur bei Nichtgebrauch auf Null herunter (z. B. Entwicklungsinstanzen in der Nacht): Ein Teil der Infrastruktur in einem Unternehmen wird nicht benötigt, wenn keine Benutzer aktiv sind. Die Implementierung eines Systems, das die Recheninfrastruktur bei Nichtgebrauch auf Null skaliert, kann für ein Unternehmen erhebliche Einsparungen bedeuten.
- Instanzreservierungen bei Ihrem Cloud-Anbieter beantragen: Die Beantragung von reservierten Instanzen bei Ihrem Cloud-Anbieter kann Ihnen bei vorhersehbarem Rechenbedarf attraktive Rabatte verschaffen.
- Nutzung von Spot-Instanzen für zustandslose Workloads erzwingen: Nutzen Sie Spot-Instanzen (AWS) oder preemptible VMs (Google Cloud) für fehlertolerante ML-Workloads. Diese Instanzen sind deutlich günstiger als On-Demand-Instanzen, da Sie auf ungenutzte Kapazitäten bieten können, um Kosten zu sparen. Achten Sie jedoch auf die Möglichkeit einer Instanzbeendigung und gestalten Sie Ihre Infrastruktur so, dass sie Unterbrechungen problemlos abfängt. Um den Preisunterschied zwischen On-Demand- und Spot-Instanzen zu verdeutlichen, vergleichen wir die monatlichen Kosten einer T4-GPU bei AWS und Azure.
g4dn.xlarge : 383 $ (On-Demand) vs. 115 $ (Spot)
NC4as T4 v3: 383 $ (On-Demand) vs. 49 $ (Spot)
Colocation von Rechenleistung und Daten
Es ist wichtig, Daten und Rechenleistung am selben Ort zu halten, um hohe Ingress-/Egress-Kosten zu vermeiden. Trainingsprozesse beinhalten in der Regel das Herunterladen von Daten auf die Maschinen, auf denen das Modell trainiert wird. Um unerwartete Kosten zu vermeiden, sollten Sie auf Folgendes achten:
- Daten für mehrere Data Scientists freigeben: Es ist wichtig, nur eine einzige Kopie der Trainingsdaten vorzuhalten, die von verschiedenen Data Scientists genutzt werden kann, anstatt für jeden eine eigene Kopie zu erstellen. Dies lässt sich erreichen, indem ein schreibgeschütztes Volume mit den Daten auf allen Trainingsmaschinen eingebunden wird.
- Nicht genutzte Volumes löschen: Oft vergisst man, erstellte Volumes wieder zu löschen, was dazu führt, dass verwaiste Volumes unnötige Kosten verursachen.
Automatisches Herunterfahren von Notebooks bei Inaktivität
Data Scientists starten häufig eine VM, richten dort ein Jupyter Notebook ein oder nutzen sie per SSH in VSCode. Dieser Ansatz funktioniert zwar, führt aber oft dazu, dass Entwickler vergessen, die VMs nach getaner Arbeit herunterzufahren. Dies führt zu erheblichen Kosten. Sobald das DS-Team auf mehr als 5 Mitglieder anwächst, lohnt sich die Investition in gehostete Notebooks mit automatischer Abschaltfunktion.
Effiziente GPU-Auslastung
GPUs werden im ML-Bereich intensiv genutzt, jedoch nur in den seltensten Fällen effizient. Dieser Artikel beleuchtet hervorragend, wie GPUs heute meist eingesetzt werden und wo die Ineffizienzen liegen. Die gemeinsame Nutzung von GPUs durch verschiedene Workloads sowie effiziente Batching-Techniken sind entscheidend für eine optimale GPU-Auslastung.
Wie kann TrueFoundry bei der Kostensenkung helfen?
TrueFoundry hat allen Kunden geholfen, die Infrastrukturkosten um mindestens 40 % zu senken.
Wir nutzen Kubernetes
Kubernetes hilft dabei, Kosten zu senken, indem Workloads effizient auf die Knoten verteilt werden und eine effektive Auslastung des Clusters sichergestellt wird. Dieser Artikel beleuchtet ausführlich, wie Kubernetes zur Kosteneinsparung beiträgt.
Entwicklungskosten um 60 % senken mit zeitbasiertem Autoscaling
TrueFoundry macht es durch die Funktion für zeitbasiertes Autoscaling sehr einfach, Ihre Entwicklungsumgebungen herunterzufahren. Entwickler arbeiten meist etwa 40 Stunden pro Woche, während die Maschinen fast 128 Stunden pro Woche laufen. Wenn wir die Maschinen effektiv herunterfahren würden, könnten wir etwa 60 % der Kosten einsparen.

Automatisches Herunterfahren von Notebooks bei Inaktivität
TrueFoundry ermöglicht es Data Scientists, für jedes Notebook einen Inaktivitäts-Timeout zu konfigurieren, nach dessen Ablauf das Notebook automatisch abgeschaltet wird.

Dies hilft dabei, erhebliche Kosten zu sparen, insbesondere wenn Notebooks auf GPUs ausgeführt werden.
Einfache Nutzung von Spot-Instanzen
Truefoundry macht die Verwendung von Spot- und On-Demand-Instanzen für Entwickler besonders einfach. Da Entwickler und Data Scientists ihre Anwendungen am besten kennen, überlassen wir ihnen die Entscheidung, welche Option für ihre Projekte am besten geeignet ist.

Zudem werden Ihnen die Kostenunterschiede zwischen Spot- und On-Demand-Instanzen aufgezeigt, damit Sie die richtige Wahl für Ihren Anwendungsfall treffen können.

Ressourcenkontingente für Teams und Entwickler
Mit Truefoundry können Sie CPU-, Arbeitsspeicher- und GPU-Kontingente für verschiedene Teams und Entwickler festlegen. Dies ermöglicht Führungskräften einen Überblick über die Kostenverteilung innerhalb der Teams und schützt vor Fehlern, indem Entwickler daran gehindert werden, die zugewiesenen Limits zu überschreiten.

Einblicke zur Kostenoptimierung
Truefoundry analysiert den Ressourcenverbrauch Ihres Dienstes über die letzten Tage und schlägt automatisch die optimalen CPU- und Arbeitsspeicherwerte vor. Aktuell erhalten Sie Empfehlungen für CPU- und Speicheranforderungen sowie entsprechende Limits. Zukünftig planen wir, auch Empfehlungen für Autoscaling-Strategien und die ideale Architektur zu integrieren.

Bewertung durchführen
Möchten Sie wissen, wie Sie die Kosten für Ihre KI-Workloads optimieren können? Wir haben eine kurze, 5-minütige Bewertung für Sie erstellt.
Wir garantieren Ihnen die Zusendung eines personalisierten Berichts.
TrueFoundry AI Gateway bietet eine Latenz von ~3—4 ms, verarbeitet mehr als 350 RPS auf einer vCPU, skaliert problemlos horizontal und ist produktionsbereit, während LiteLM unter einer hohen Latenz leidet, mit moderaten RPS zu kämpfen hat, keine integrierte Skalierung hat und sich am besten für leichte Workloads oder Prototyp-Workloads eignet.

















%20(28).webp)



.webp)
.webp)
.png)

.png)
.png)
.png)
.png)
.png)
.webp)
.webp)






