KI-Infrastruktur für das MVP deines Startups wählen

Gründer, die ihrem MVP eine KI-Funktion hinzufügen, stellen meist die falsche erste Frage. Üblicherweise lautet sie „Welches Modell sollten wir nutzen”, während die Frage, die Kosten, Zeitplan und Risiko wirklich bestimmt, lautet: „Auf welcher Infrastruktur muss diese Funktion laufen.” Wird diese zweite Frage falsch beantwortet, kann man am Ende GPU-Server für eine Funktion bereitstellen, von der noch niemand bestätigt hat, dass sie überhaupt jemand will.

Dies ist ein praktischer Leitfaden für diese Infrastrukturentscheidung — nicht, welches KI-Modell am klügsten ist, sondern wie man das gewählte Modell betreibt, ohne zu überbauen, bevor das MVP bewiesen hat, dass sich die Investition in die Funktion lohnt.

Die eigentliche Entscheidung: gehostete API vs. selbst gehostetes Modell

Fast jede KI-Funktion in einem MVP läuft auf eine einzige Architekturentscheidung hinaus: eine gehostete LLM-API aufrufen oder ein Modell selbst betreiben.

Eine gehostete LLM-API bedeutet, dass du eine Anfrage an den Endpunkt eines Anbieters sendest und eine Antwort zurückbekommst. Du verwaltest keine Server, richtest keine Hardware ein und denkst nicht über Modellgewichte nach. Du zahlst pro Token oder pro Anfrage, und Skalierung ist das Problem des Anbieters, nicht deins.

Ein selbst gehostetes Modell bedeutet, dass du die Gewichte des Modells auf einer Infrastruktur betreibst, die du selbst kontrollierst — eigene Cloud-Instanzen, einen dedizierten GPU-Anbieter oder eigene Hardware vor Ort. Du bist verantwortlich für Verfügbarkeit, Skalierung, Updates und alles, was den Betrieb am Laufen hält.

Für ein MVP ist die gehostete API fast immer der richtige Ausgangspunkt. Es gibt keine Infrastruktur aufzubauen, sie ist am selben Tag live, an dem du einen API-Schlüssel erhältst, und sie skaliert, ohne dass du etwas tun musst. Der ganze Sinn der Infrastruktur in der MVP-Phase besteht darin, so wenig Entwicklungszeit wie möglich für Grundlagenarbeit aufzuwenden, während du herausfindest, ob die Funktion überhaupt wichtig ist — und eine gehostete API ist die Option ohne Grundlagenarbeit.

Self-Hosting ist kein Anfängerfehler, den man grundsätzlich vermeiden sollte; es ist eine Entscheidung, die später hingehört, sobald ein konkreter Grund dafür vorliegt. Der Fehler besteht darin, sie standardmäßig zu wählen oder weil sie „seriöser” wirkt oder mehr Kontrolle vermittelt, bevor Belege vorliegen, die den operativen Aufwand rechtfertigen.

Gehostete LLM-API vs. selbst gehostetes Modell

	Gehostete LLM-API	Selbst gehostetes offenes Modell
Einrichtungsaufwand	Minuten — API-Schlüssel und ein SDK-Aufruf	Tage bis Wochen — Bereitstellung, Deployment, Serving-Infrastruktur
Laufende Kosten	Nutzungsbasiert, skaliert mit dem Volumen, keine Leerlaufkosten	Feste Infrastrukturkosten (oft GPU-basiert), unabhängig von der Nutzung, plus Entwicklungszeit
Kontrolle	Beschränkt auf Modell, API und Ratenlimits des Anbieters	Volle Kontrolle über Modell, Gewichte, Fine-Tuning und Datenverarbeitung
Am besten für	MVP-Validierung, unvorhersehbares oder geringes Volumen, kleine Teams	Hohes, vorhersehbares Volumen; strikte Anforderungen an Datenresidenz; eng gefasste Aufgabe, die ein kleineres Modell gut bewältigt

Nutze diese Tabelle als Ausgangspunkt, nicht als Regel — aber beachte, dass jede Spalte unter „Am besten für” auf der Self-Hosting-Seite eine Bedingung beschreibt, die ein MVP am ersten Tag selten erfüllt.

Warum GPUs in deinem MVP-Stack fast nie etwas verloren haben

GPU-Infrastruktur wird im Diskurs über KI-Infrastruktur ständig erwähnt, und fast nichts davon ist für Teams in der MVP-Phase geschrieben. Wenn du eine gehostete API aufrufst, übernehmen die GPUs des Anbieters die Inferenz — du kommst nie mit einer GPU in Berührung, richtest keine ein und zahlst nicht direkt dafür.

GPU-Infrastruktur wird erst dann zu deinem Problem, wenn du ein Modell selbst hostest, und selbst dann ist der ehrliche erste Schritt für die meisten Teams nicht der Kauf oder die Miete roher GPU-Kapazität — sondern die Nutzung eines gehosteten Inferenz-Anbieters für Open-Weight-Modelle, der zwar immer noch auf den GPUs eines anderen läuft, aber die operative Last des eigenständigen Verwaltens von Treibern, Skalierung und Failover erspart. Eigene GPU-Infrastruktur aufzubauen ist ein Schritt für später, wenn Volumen und Kostenrechnung das tatsächlich rechtfertigen, keine Standard-Ausgangsposition für die erste KI-Funktion eines MVPs.

Wenn du dich dabei ertappst, GPU-Instanzen zu kalkulieren, bevor die Funktion einem einzigen echten Nutzer ausgeliefert wurde, ist das meist ein Zeichen dafür, dass die Infrastrukturentscheidung der Validierung vorausgeeilt ist, der sie eigentlich folgen sollte.

Ein kurzes Wort zu Infrastructure as Code

Infrastructure as Code (IaC) — Server, Datenbanken und Cloud-Ressourcen in versionierter Konfiguration statt durch Klicken in einer Konsole zu definieren — ist eine wirklich gute Angewohnheit, und Tools wie Terraform und Pulumi lohnt es sich zu kennen. Aber es ist in der MVP-Phase keine Priorität, stark in eine Funktion zu investieren, die noch nicht validiert wurde.

Ein vernünftiger Mittelweg: Halte deine Kerninfrastruktur (Datenbank, Hosting, Auth) reproduzierbar, wenn dein Team bereits IaC für den Rest des Stacks nutzt, baue aber keine aufwendige Deployment-Pipeline um eine KI-Funktion herum, bevor du weißt, dass sie bleibt. Wird die Funktion nach einem Validierungs-Sprint gestrichen, war jede Stunde, die in die Absicherung ihrer Infrastruktur floss, eine Stunde, die noch nicht hätte investiert werden müssen.

Wie man Überbauen vermeidet, bevor die Funktion validiert ist

Das Muster, das die meiste Zeit und das meiste Geld verschwendet, ist nicht die Wahl des falschen Modells — es ist der Aufbau von Infrastruktur für ein Skalierungs- und Zuverlässigkeitsniveau, das sich die Funktion noch nicht verdient hat. Ein paar Leitplanken:

• Live gehen hinter der einfachsten Infrastruktur, die echte Nutzer unterstützen kann. Für die meisten KI-Funktionen in einem MVP ist das ein Aufruf einer gehosteten API innerhalb des bestehenden Backends, kein neuer Service, kein dediziertes Deployment.
• Nutzung soll die nächste Ebene rechtfertigen, nicht umgekehrt. Caching, Ratenbegrenzung, Fallback-Modelle oder Self-Hosting erst hinzufügen, wenn echte Nutzungsdaten zeigen, dass sie gebraucht werden — nicht weil ein Blogbeitrag behauptet, eine „produktionsreife” KI-Funktion brauche das von Tag eins an.
• Die KI-Funktion wie jede andere MVP-Funktion behandeln: davon ausgehen, dass sie gestrichen werden könnte. Würde ein Gründer für eine nicht validierte Nicht-KI-Funktion keinen vollständigen Microservice bauen, sollte hier dieselbe Disziplin gelten. Unser Leitfaden dazu, warum die meisten Startups Microservices in der MVP-Phase vermeiden sollten, behandelt denselben Instinkt für Architektur im Allgemeinen, und er gilt direkt auch für KI-Infrastruktur.
• „Funktioniert diese Funktion” von „skaliert diese Funktion” trennen. Die erste Frage erfordert kaum Infrastrukturinvestitionen zur Beantwortung. Die zweite Frage lohnt sich erst dann erneut zu betrachten, wenn die erste eine echte Antwort hat.

Wenn du unsicher bist, ob eine KI-Funktion überhaupt ins MVP gehört — im Gegensatz zur Frage, wie man sie hostet —, ist das eine etwas frühere Entscheidung, als dieser Beitrag behandelt. Unser Leitfaden zu KI-Automatisierung für Startups zeigt, wo KI kleinen Teams wirklich Zeit spart im Vergleich zu wo sie Risiko hinzufügt — es lohnt sich, das zu klären, bevor die Infrastrukturfrage aufkommt.

Budgetierung für die tatsächlich gewählte Infrastruktur

Egal für welchen Weg du dich entscheidest, die laufenden Kosten einer KI-Funktion verdienen eine eigene Zeile in deinem Budget, keine Schätzung. Hast du dich für eine gehostete API entschieden und möchtest Anbieter vor der Festlegung vergleichen, zeigt unser Leitfaden zum Vergleich von KI- und API-Preisen, wie man Preismodelle gegeneinander bewertet. Sobald klar ist, welchen Anbieter du nutzt, zeigt unser Leitfaden zur Schätzung von Cloud- und API-Infrastrukturkosten, wie man diese Wahl in eine tatsächliche Kostenprognose vor dem Launch umwandelt — das sind aufeinanderfolgende Schritte, nicht dieselbe Aufgabe, und beide kommen nach der Architekturentscheidung, die dieser Beitrag behandelt.

Wann man die Entscheidung überdenken sollte

Die Entscheidung zwischen gehostet und selbst gehostet ist nicht dauerhaft — sie ist die richtige Standardwahl, bis eine konkrete, messbare Bedingung sie ändert. Überdenke sie, wenn:

• Dein Token-Volumen hoch und konstant genug ist, dass die festen Infrastrukturkosten eines selbst gehosteten Modells die laufenden API-Ausgaben übersteigen würden — mit echten Zahlen hinter diesem Vergleich, keiner Schätzung.
• Eine Kunden- oder Compliance-Anforderung bedeutet, dass Daten die eigene Infrastruktur wirklich nie verlassen dürfen.
• Die Latenzanforderungen so streng sind, dass die Antwortzeit einer gehosteten API der Flaschenhals ist, und du bestätigt hast, dass ein selbst gehosteter Aufbau tatsächlich schneller wäre.
• Ein enger gefasstes, feinabgestimmtes offenes Modell deine spezifische Aufgabe besser und günstiger bewältigen kann als eine allgemeine gehostete API — und du das getestet hast, statt es anzunehmen.

Außerhalb dieser Bedingungen ist das Verbleiben bei einer gehosteten API kein Kompromiss — es ist die richtige Infrastrukturwahl für ein Produkt, das sich noch beweisen muss.

Das Fazit

Die meisten MVPs mit einer KI-Funktion brauchen keine GPUs, kein selbst gehostetes Modell und keine aufwendige Deployment-Pipeline — sie brauchen einen Aufruf einer gehosteten LLM-API und die Disziplin, es dabei zu belassen, bis echte Nutzungsdaten etwas anderes sagen. Die wichtigste Infrastrukturentscheidung in dieser Phase ist nicht, welches Modell das beste ist; es ist, dem Drang zu widerstehen, für ein Skalierungs- und Kontrollniveau zu bauen, das man sich noch nicht verdient hat.

Häufig gestellte Fragen

Brauche ich eine GPU, um meinem MVP eine KI-Funktion hinzuzufügen?

In der MVP-Phase fast nie. Wenn du eine gehostete LLM-API aufrufst — was für die große Mehrheit der KI-Funktionen in einem MVP gilt, etwa Chat, Zusammenfassung und Klassifikation —, betreibt der Anbieter die GPUs, nicht du. GPU-Infrastruktur wird erst dann wirklich relevant, wenn du ein Open-Weight-Modell selbst hostest, und selbst dann greifen viele Teams zunächst auf GPU-basierte gehostete Inferenz zurück, bevor sie eigene GPU-Kapazität kaufen oder mieten.

Sollte mein MVP eine gehostete LLM-API oder ein selbst gehostetes Modell nutzen?

Für ein MVP standardmäßig eine gehostete API wählen. Es gibt keine Infrastruktur zu verwalten, sie skaliert automatisch und du kannst in Tagen statt Wochen live gehen. Self-Hosting ist erst sinnvoll, sobald ein konkreter, validierter Grund vorliegt — Anforderungen an Datenresidenz, Kosten pro Anfrage bei echtem Volumen oder Latenzanforderungen, die eine gehostete API nicht erfüllen kann — sowie die Entwicklungszeit, um es zu betreiben.

Was ist Infrastructure as Code, und braucht mein MVP das?

Infrastructure as Code (IaC) bedeutet, Server, Datenbanken und Cloud-Ressourcen in versionierten Konfigurationsdateien zu definieren, statt sich durch eine Cloud-Konsole zu klicken. Das ist auch in der MVP-Phase eine gute Angewohnheit für Reproduzierbarkeit, aber nichts, worin man stark investieren sollte, bevor klar ist, dass sich die KI-Funktion lohnt — ein paar manuell konfigurierte Ressourcen reichen für eine erste Version.

Wie vermeide ich Überbauen der KI-Infrastruktur, bevor ich weiß, ob die Funktion funktioniert?

Bringe die KI-Funktion hinter der einfachsten Infrastruktur live, die echte Nutzer unterstützen kann — meist ein Aufruf einer gehosteten API aus deinem bestehenden Backend —, bevor du in selbst gehostete Modelle, GPU-Kapazität oder aufwendige Deployment-Pipelines investierst. Lass Nutzungsdaten und Nutzerfeedback jede zusätzliche Infrastrukturebene rechtfertigen, statt für eine Skalierung zu bauen, die du dir noch nicht verdient hast.

Wann ist es sinnvoll, ein KI-Modell selbst zu hosten statt eine API zu nutzen?

In der Regel erst nach Product-Market-Fit, wenn du ein konstantes, hohes Volumen hast, das Pay-per-Token-Preise teurer macht als der Betrieb eigener Inferenz, eine Compliance-Anforderung besteht, dass Daten die eigene Infrastruktur nie verlassen dürfen, oder eine eng gefasste Aufgabe vorliegt, bei der ein kleineres, feinabgestimmtes offenes Modell eine allgemeine API bei geringeren Kosten übertrifft. Nur sehr wenige MVPs erfüllen diese Bedingungen vor dem Launch.