In der Proof-of-Concept-Phase benötigt ein AI-Startup in der Regel noch keine komplexe Infrastruktur. Die wichtigste Aufgabe besteht darin, eine Hypothese schnell zu überprüfen: Funktioniert das Modell, löst das Produkt das Problem des Nutzers und lohnt es sich, die Entwicklung fortzusetzen? Dafür reichen einige Cloud Instances, eine gemietete GPU oder sogar eine lokale Workstation aus. Je nach Projekt kann ein Startup in dieser Phase auch einen KI Server mieten, statt frühzeitig in eigene Hardware zu investieren.
Nach dem Übergang des Produkts in die Production ändern sich die Anforderungen. Es gibt reale Nutzer, SLAs, wachsende Datenmengen, parallele Anfragen und die Notwendigkeit, die Kosten zu kontrollieren. Eine Infrastruktur, die für Experimente praktisch war, kann bei dauerhafter Last zu teuer oder nicht zuverlässig genug sein.
Die Skalierung einer AI-Infrastruktur ist deshalb kein einmaliger Wechsel von einem kleinen auf einen großen Server. In jeder Phase muss ein Startup die Last, die Kosten der Rechenleistung, die Anforderungen an die Daten und das erforderliche Maß an Ausfallsicherheit neu bewerten.
Phase 1. PoC: Geschwindigkeit ist wichtiger als die optimale Infrastruktur
Für einen Proof of Concept ist es nicht sinnvoll, im Voraus ein System für Tausende Nutzer aufzubauen. In dieser Phase ist noch unbekannt, welches Modell letztlich im Produkt eingesetzt wird, wie viele GPUs benötigt werden und wie das tatsächliche Lastprofil aussehen wird.
Deshalb ist die Möglichkeit, Ressourcen schnell zu verändern, besonders wertvoll.
Mit Cloud GPUs lassen sich verschiedene Beschleuniger und Modelle testen, ohne Hardware kaufen zu müssen. Werden Rechenressourcen nur unregelmäßig benötigt, können sie zwischen den Experimenten abgeschaltet werden. Für kleinere Inference-Workloads kann je nach Modell und Anforderungen an die Latency eine einzelne GPU oder sogar eine CPU ausreichen.
In dieser Phase sollten Infrastrukturentscheidungen möglichst reversibel sein. Der Kauf eines teuren GPU-Servers für eine noch nicht bestätigte Hypothese birgt das Risiko, Hardware anzuschaffen, die bereits einige Monate später nicht mehr zu den Anforderungen des Produkts passt.
Die wichtigste Aufgabe des PoC besteht darin, erste technische Kennzahlen zu erfassen: den erforderlichen VRAM, die Geschwindigkeit von Inference oder Training, die Dauer einzelner Jobs und den ungefähren Verbrauch von Rechenressourcen.
Phase 2. MVP: Die reale Last wird messbar
Mit dem MVP trifft die Infrastruktur erstmals auf das Verhalten realer Nutzer.
Nun reicht es nicht mehr aus zu wissen, wie viele Tokens/s ein Modell in einem Benchmark generiert. Gemessen werden sollten:
- Anzahl der Anfragen und ihre zeitliche Verteilung;
- Concurrency;
- durchschnittliche und maximale Latency;
- TTFT bei LLMs;
- GPU- und CPU-Auslastung;
- VRAM- und RAM-Nutzung;
- Storage-Volumen und Network Traffic;
- Kosten pro Anfrage oder pro anderer Einheit produktiver Arbeit.
Diese Daten bilden die Grundlage für die weitere Skalierung.
Ein hoher Preis einer GPU Instance bedeutet beispielsweise nicht automatisch, dass sie ersetzt werden sollte. Wird die GPU nur wenige Stunden pro Tag genutzt, kann ein eigener Server aufgrund der Leerlaufzeiten wirtschaftlich weniger attraktiv sein.
Läuft dagegen dieselbe Cloud GPU rund um die Uhr mit hoher Auslastung, lohnt sich ein Kostenvergleich mit einem Dedicated GPU Server oder eigener Infrastruktur.
Eine nicht optimierte Modellarchitektur sollte nicht einfach skaliert werden
Einer der kostspieligsten Fehler besteht darin, steigende Last ausschließlich durch zusätzliche GPUs aufzufangen.
Bevor die Infrastruktur erweitert wird, sollte geprüft werden, ob sich die Kosten für die Ausführung des Workloads selbst reduzieren lassen. Bei Inference können dazu Quantisierung, Batching, Caching, der Einsatz eines kompakteren Modells oder die Optimierung der Inference Engine gehören.
Nicht jede Anfrage muss vom größten verfügbaren Modell verarbeitet werden. In manchen Produkten können unterschiedliche Aufgaben an Modelle verschiedener Größe weitergeleitet werden, während das teuerste Modell nur für Anfragen eingesetzt wird, bei denen seine Fähigkeiten tatsächlich erforderlich sind.
Beim Training spielen die Effizienz der Data Pipeline, die GPU-Auslastung und die Skalierung zwischen den Beschleunigern eine wichtige Rolle. Wenn GPUs einen erheblichen Teil der Zeit auf Daten warten, erhöht das Hinzufügen weiterer Beschleuniger lediglich die Kosten des Leerlaufs.
Durch Optimierung vor der Skalierung lässt sich bestimmen, wie viel Hardware das Produkt tatsächlich benötigt.
Phase 3. Die ersten dauerhaften Nutzer: Eine Grundlast entsteht
Mit zunehmendem Wachstum des Produkts wird ein Teil der Last vorhersehbar. Nun lässt sich bestimmen, welche Mindestmenge an Ressourcen nahezu permanent genutzt wird und welche Lastspitzen separat auftreten.
Dies ist ein wichtiger Zeitpunkt für die Wahl des Infrastrukturmodells.
Werden GPUs nur unregelmäßig benötigt, behält die Cloud aufgrund ihrer Elastizität ihren Vorteil. Arbeiten dagegen mehrere Beschleuniger rund um die Uhr mit hoher Auslastung, können die regelmäßigen stündlichen Kosten zu einem erheblichen Kostenfaktor werden.
In dieser Phase lohnt sich ein Vergleich zwischen:
- Cloud GPU – für variable Lasten und schnelle Skalierung;
- Miete eines Dedicated GPU Servers – für konstante Lasten ohne Investitionen in eigene Hardware;
- eigenen GPUs – für stabile langfristige Lasten, wenn das Unternehmen bereit ist, CAPEX und den Betrieb der Hardware zu übernehmen.
Es ist nicht notwendig, für das gesamte System dasselbe Modell zu wählen. Die permanente Last kann auf dedizierte Ressourcen verlagert werden, während die Cloud weiterhin für Lastspitzen genutzt wird.
Skalierung beginnt nicht mit der Anzahl der GPUs
Mit zunehmender Größe eines AI-Services kann jede Komponente der Infrastruktur zum Bottleneck werden.
Bei LLM Inference erhöht eine steigende Concurrency aufgrund des KV Cache die Anforderungen an den VRAM. Data-intensive Workloads hängen von Storage und der Geschwindigkeit der Datenzufuhr ab. Bei Multi-GPU-Berechnungen gewinnt der Interconnect an Bedeutung, während beim Übergang auf mehrere Server Network Bandwidth und Latency relevant werden.
Zusätzliche GPUs sollten daher erst nach der Identifizierung des Bottlenecks eingesetzt werden.
Liegt das Problem beim VRAM, kann ein Beschleuniger mit mehr Speicher erforderlich sein und nicht unbedingt mehr Rechenleistung. Bleiben GPUs aufgrund langsamen Preprocessings ungenutzt, müssen zunächst CPU oder Data Pipeline skaliert werden.
Die Infrastruktur sollte als Gesamtsystem wachsen: Compute, Memory, Storage und Network werden entsprechend der tatsächlichen Last skaliert und nicht unabhängig voneinander.
Phase 4. Production: Performance allein reicht nicht mehr aus
Während eines PoC können ein manueller Neustart des Services oder eine vorübergehend nicht verfügbare GPU akzeptabel sein. In Production wirkt sich ein Ausfall der Infrastruktur unmittelbar auf die Nutzer aus.
Zusammen mit der Rechenleistung muss deshalb auch die Zuverlässigkeit skaliert werden. Monitoring, Backup, Wiederherstellung nach Ausfällen und die Redundanz kritischer Komponenten müssen berücksichtigt werden.
Bei einem Inference-Service sollte geplant werden, was beim Ausfall einer GPU oder eines kompletten Servers geschieht. Läuft die gesamte Production auf einem einzigen Node, bedeutet dessen Ausfall gleichzeitig den Ausfall der AI-Funktionalität des Produkts.
Redundanz muss dabei nicht zwangsläufig bedeuten, dass die gesamte Infrastruktur vollständig dupliziert wird. Das erforderliche Maß an Ausfallsicherheit sollte der Kritikalität des Services und den Anforderungen an die Recovery Time entsprechen.
Capacity Planning statt ständig neue Server hinzuzufügen
Sobald historische Daten zur realen Last vorliegen, kann ein Startup von reaktiver Skalierung zu Capacity Planning übergehen.
Dafür sollten nicht nur Durchschnittswerte, sondern auch Lastspitzen überwacht werden: GPU Utilization, VRAM, Concurrency, Latency, Throughput, Storage und Network Traffic.
Anschließend lassen sich drei Ressourcenebenen unterscheiden:
- Grundlast, die nahezu permanent vorhanden ist;
- regelmäßige Lastspitzen, die sich prognostizieren lassen;
- seltene Maximalwerte, für die das Vorhalten eigener Infrastruktur wirtschaftlich möglicherweise nicht sinnvoll ist.
Diese Aufteilung hilft dabei, zwei Extreme zu vermeiden: dauerhaft zu wenig Capacity und den Kauf von Hardware, die den größten Teil der Zeit ungenutzt bleibt.
Unit Economics wird zur Infrastrukturmetrik
In einer frühen Phase betrachtet ein Startup häufig vor allem die gesamte Cloud Bill. Nach dem Übergang in Production ist es sinnvoller, die Infrastrukturkosten mit der tatsächlichen Arbeit des Produkts zu verknüpfen.
Je nach Service können beispielsweise folgende Kennzahlen berechnet werden:
- Kosten einer einzelnen Inference-Anfrage;
- Kosten von tausend Anfragen;
- Kosten für die Generierung einer bestimmten Anzahl von Tokens;
- Kosten für die Verarbeitung eines Dokuments oder Bildes;
- Kosten eines Training Jobs.
Mit solchen Kennzahlen lässt sich der Effekt eines Modellwechsels, einer Quantisierung, einer neuen GPU oder der Verlagerung einer permanenten Last von der Cloud auf einen Dedicated Server beurteilen.
Verdoppelt sich die Zahl der Nutzer, während sich die Infrastrukturkosten verdreifachen, liegt das Problem möglicherweise nicht beim Preis des Providers, sondern bei der Architektur oder der Effizienz des Workloads.
Wann das Infrastrukturmodell geändert werden sollte
Eine Migration ist nicht allein deshalb sinnvoll, weil das Startup wächst, sondern wenn sich der Charakter der Last verändert.
Die Infrastruktur sollte neu bewertet werden, wenn die dauerhafte GPU-Auslastung deutlich gestiegen ist, die Cloud Costs mit dem Wachstum des Produkts schlecht skalieren, der verfügbare VRAM nicht mehr ausreicht oder für das weitere Wachstum eine spezialisierte Multi-GPU-Konfiguration erforderlich wird.
Ein weiteres Signal sind Anforderungen, die während des PoC noch keine Rolle gespielt haben: vorhersehbare Latency, ein bestimmter Datenstandort, physische Isolation der Ressourcen oder ein höheres Maß an Kontrolle über die Hardware.
Dabei muss nicht die gesamte Infrastruktur gleichzeitig migriert werden. Die Migration einzelner stabiler Workloads ist häufig mit geringeren Risiken verbunden als ein vollständiger Wechsel von der bestehenden Plattform.
Hybride Infrastruktur als Wachstumsphase
Bei einem wachsenden AI-Produkt kann sich die Grenze zwischen Cloud und dedizierten Ressourcen dynamisch verändern.
Permanente Inference-Workloads können auf Dedicated GPU Servers betrieben werden, auf denen die Beschleuniger rund um die Uhr genutzt werden. Die Cloud kann weiterhin für starke Lastspitzen, Experimente und temporäre Training Jobs eingesetzt werden.
Eigene Hardware wird zu einer weiteren Option, sobald die Last stabil genug ist, um Utilization und Amortisationszeitraum zuverlässig abschätzen zu können.
Die Infrastruktur kann sich somit schrittweise entwickeln:
PoC → Cloud on Demand → permanente Grundlast → dedizierte Ressourcen → hybride oder eigene Infrastruktur
Diese Reihenfolge ist nicht für jedes Startup zwingend. Bleibt die Last stark variabel, kann die Cloud auch nach dem Übergang des Produkts in Production weiterhin Vorteile bieten.
Was bereits bei der Architektur berücksichtigt werden sollte
In der PoC-Phase lässt sich die spätere Production-Infrastruktur nicht exakt planen. Es ist jedoch möglich, Entscheidungen zu vermeiden, die eine spätere Skalierung erheblich erschweren.
Sinnvoll ist es, die Anwendung frühzeitig von einem bestimmten GPU Node zu entkoppeln, Daten unabhängig von den Compute Instances zu speichern, das Deployment zu automatisieren und Lastmetriken zu erfassen.
Ebenso wichtig ist die Möglichkeit, das Modell oder die Inference Engine auszutauschen, ohne das gesamte Produkt neu aufbauen zu müssen. Für ein AI-Startup ist dies besonders relevant: Das verwendete Modell und die Hardware-Anforderungen können sich schneller ändern als die übrige Architektur.
Das Ziel besteht nicht darin, eine Infrastruktur „für die nächsten zehn Jahre“ aufzubauen, sondern dafür zu sorgen, dass die nächste Wachstumsphase keine vollständige Neuentwicklung des Systems erfordert.
Vom PoC zur Production: Die Infrastruktur muss mit dem Produkt wachsen
In der PoC-Phase benötigt ein AI-Startup vor allem schnelle Experimente und die Möglichkeit, Ressourcen flexibel zu verändern. Sobald Nutzer hinzukommen, verschiebt sich der Schwerpunkt auf die Messung der realen Last und der Workload-Kosten. In Production kommen Anforderungen an Zuverlässigkeit, Capacity Planning und Kostenkontrolle hinzu.
Die Skalierung sollte deshalb schrittweise erfolgen: Hypothese prüfen → Last messen → Workload optimieren → Grund- und Spitzenlast bestimmen → geeignetes Infrastrukturmodell auswählen → erforderliche Ausfallsicherheit gewährleisten.
Mit diesem Ansatz lassen sich GPUs nicht nur vor unnötig frühen Anschaffungen bewahren, sondern auch Situationen vermeiden, in denen ein Produkt weiterhin auf einer PoC-Infrastruktur betrieben wird, obwohl diese längst nicht mehr zu seinem Umfang und seinen Anforderungen passt.
