Wie ein ML-Startup seine AWS-Rechnung von 22.000 US-Dollar durch die Optimierung der Planung reduzierte

Ein Machine-Learning-Startup mit acht Ingenieuren hat kürzlich seine monatliche Rechnung für Cloud-Infrastruktur um fast fünftausend Dollar gesenkt. Das Team erzielte diese Einsparungen nicht durch das Umschreiben ihrer Inferenzmodelle oder das Ändern der Instanztypen, sondern durch die Anpassung des GPU-Nutzungsplans an die tatsächlichen Muster der Nutzernachfrage. Der Fall verdeutlicht, wie operative Zeitplanung, und nicht nur architektonische Effizienz, zu erheblichen Kostenunterschieden in Cloud-Umgebungen führt.

Was passiert ist

Das Startup betrieb eine Produktions-Inferenz-API, die echten Traffic bediente, was zu einer AWS-Rechnung von 22.000 US-Dollar pro Monat führte. Der Großteil dieser Kosten entfiel auf GPU-Compute-Ressourcen für die Modellinferenz. Als ein Berater das Konto überprüfte, erwartete er, überdimensionierte Hardware oder ineffizienten Code vorzufinden. Stattdessen stellte er fest, dass die Instanztypen gut zur Workload passten und die Auslastungsraten während der aktiven Stunden angemessen waren. Es gab keine offensichtlichen technischen Verschwendungen in der Architektur selbst.

Die Ursache der hohen Kosten war zeitlicher, nicht technischer Natur. Die Analyse der Traffic-Logs ergab, dass neunzig Prozent aller Nutzeranfragen zwischen 9:00 Uhr und 23:00 Uhr US Eastern Time stattfanden. Die Nachtzeit war nahezu still, bestehend nur aus automatisierten Health Checks und kleinen Hintergrund-Jobs. Trotz dieses Mangels an Nachfrage liefen die GPU-Instanzen rund um die Uhr bei voller Kapazität und zum vollen Preis. Das Team hatte den Cluster nachts auf maximaler Größe belassen, weil es sich sicherer anfühlte, was zu acht Stunden nahezu null Auslastung jede einzelne Nacht führte.

Um dies anzugehen, implementierte das Team einen Skalierungsplan. Um 23:00 Uhr Eastern Time skaliert der Inferenz-Cluster auf einen minimalen Warmzustand herunter. Dieser Zustand reicht aus, um Hintergrund-Tasks zu bearbeiten und auf Health Checks zu reagieren, verbraucht aber deutlich weniger Ressourcen. Um 8:00 Uhr Eastern Time, vor dem morgendlichen Traffic-Anstieg, skaliert der Cluster wieder auf volle Kapazität hoch. Die gesamte Änderung dauerte nur zwei Tage bis zur sicheren Implementierung und Testphase.

Wichtige Details

• Die monatliche AWS-Rechnung des Startups betrug 22.000 US-Dollar, hauptsächlich getrieben durch GPU-Compute-Kosten für Inferenz.
• Die Traffic-Analyse zeigte, dass 90 % der Anfragen zwischen 9:00 Uhr und 23:00 Uhr US Eastern Time stattfanden.
• GPU-Instanzen liefen 24/7 bei voller Kapazität, trotz acht Stunden nahezu null Nutzer-Traffic pro Nacht.
• Die Lösung bestand darin, um 23:00 Uhr auf einen minimalen Warmzustand herunterzuskalieren und um 8:00 Uhr Eastern Time wieder hochzuskalieren.
• Die Implementierung dauerte zwei Tage zum Testen und Bereitstellen, ohne die zugrunde liegende Architektur oder Modelle zu ändern.
• Die Anpassung führte zu monatlichen Einsparungen von 4.800 US-Dollar durch die Abstimmung der Ressourcenzuweisung auf die tatsächliche Nachfrage.

Hintergrund

Im Cloud-Computing, insbesondere bei spezialisierter Hardware wie GPUs, sind die Kosten oft an die Verfügbarkeit (Uptime) gebunden und nicht nur an die aktive Verarbeitung. Viele Teams belassen Cluster standardmäßig auf maximaler Kapazität, um niedrige Latenz und hohe Verfügbarkeit zu gewährleisten, aus Angst, dass ein Herunterskalieren Risiken oder Verzögerungen einführen könnte. Dieser Ansatz, oft als "Over-Provisioning for Safety" bezeichnet, kann zu erheblicher Verschwendung während vorhersehbarer Traffic-Pausen führen.

FinOps, oder Financial Operations, ist die Praxis des Managements von Cloud-Kosten durch Zusammenarbeit zwischen Engineering- und Finanzteams. Ein Kernprinzip von FinOps ist die Übereinstimmung von Ausgaben mit dem Geschäftswert. In diesem Kontext bedeutet es, dass teure Ressourcen nur laufen, wenn sie aktiv Nutzer bedienen. Automatische Skalierungsrichtlinien ermöglichen es Teams, Ressourcen dynamisch basierend auf Zeit oder Last anzupassen und so die Lücke zwischen technischer Zuverlässigkeit und finanzieller Effizienz zu schließen.

Warum es wichtig ist

Für Teams, die ihre eigene Software-Infrastruktur verwalten, illustriert dieser Fall, dass Kostenoptimierung nicht immer komplexes Refactoring erfordert. Ingenieure konzentrieren sich oft auf Code-Effizienz oder Datenbank-Indizierung, um Kosten zu senken, und übersehen dabei operative Zeitpläne. Wenn Traffic-Muster vorhersehbar sind, wie bei B2B-Anwendungen mit klaren Geschäftszeiten, können statische Skalierungsrichtlinien Geld liegen lassen. Die Erkenntnis, dass "Sicherheit" durch konstante Spitzenkapazität eine direkte finanzielle Strafe hat, ist ein entscheidender Wandel im Denken für DevOps-Leads.

Darüber hinaus unterstreicht diese Geschichte die Bedeutung datengesteuerter Entscheidungen im Infrastrukturmanagement. Ohne die Analyse der Zeitstempelverteilung der Anfragen ging das Team davon aus, dass ihre hohe Rechnung durch konstante Nachfrage gerechtfertigt sei. Durch die einfache Beobachtung, wann Nutzer tatsächlich aktiv waren, identifizierten sie eine klare Möglichkeit zur Einsparung. Dieser Ansatz ist auf viele Self-Hosted-Services anwendbar, bei denen die Last vorhersehbar schwankt, von internen Tools bis hin zu kundenseitigen APIs.

Was Sie tun können

• Analysieren Sie Ihre Service-Logs, um Spitzen- und Nebenzeiten des Traffics zu identifizieren und nach vorhersehbaren täglichen oder wöchentlichen Mustern zu suchen.
• Überprüfen Sie Ihre aktuellen Auto-Scaling-Richtlinien, um zu sehen, ob sie tiefgreifende Herunterskalierungen während bekannter verkehrsarmer Perioden zulassen.
• Implementieren Sie eine "Warm State"-Konfiguration, die wesentliche Health Checks und Hintergrund-Worker am Laufen hält, während teure Compute-Knoten reduziert werden.
• Testen Sie Skalierungsereignisse in einer Staging-Umgebung, um sicherzustellen, dass Hochfahrzeiten die Nutzererfahrung während Traffic-Anstiegen nicht beeinträchtigen.
• Richten Sie Warnmeldungen für ungewöhnliche Traffic-Spitzen außerhalb der erwarteten Fenster ein, um Anomalien zu erkennen, ohne Ressourcen dauerhaft hochzuhalten.
• Überarbeiten Sie regelmäßig Ihren Skalierungsplan, wenn sich das Nutzerverhalten ändert, um sicherzustellen, dass Ihre Kostenstruktur weiterhin mit der tatsächlichen Nachfrage übereinstimmt.