Wer allein KI-Funktionen entwickelt, kann sich vor allem eine Art Skalierung nicht leisten: die der eigenen Infrastrukturarbeit. Trotzdem beginnen viele Projekte mit GPU-Instanzen, Container-Stacks und Durchsatzschätzungen, bevor eine wiederholbare Nutzeranfrage existiert. Meine Position: Für Freelancer ist frühe Skalierbarkeit meist ein Kostenfehler. Nicht die größte Last entscheidet zuerst, sondern die Frage, wie billig sich eine falsche Annahme korrigieren lässt.
Wer vor der ersten Rechnung Kapazität plant, bezahlt für Vermutungen
Der erste Fehler ist, „später skalierbar“ mit „heute dauerhaft betriebsbereit“ gleichzusetzen. Ein Kunde fragt, ob eine KI-Funktion zehnmal so viele Anfragen bewältigen könnte; daraus wird ein Plan für ständig verfügbare GPU-Kapazität. Dabei fehlen oft drei Angaben: Wie viele Anfragen treten tatsächlich auf, wie lang sind die Eingaben, und wie viele Ergebnisse sind für den Kunden brauchbar? Ohne diese Angaben beschreibt eine Kapazitätszahl eher die Sorge des Entwicklers als die Last der Anwendung.
Ich lese KI-Infrastruktur fuer skalierbare Softwareentwicklung mit Vorbehalt: Als nächster Arbeitsschritt ist Infrastruktur erst sinnvoll, wenn eine konkrete Anfrage, ihre Antwort und ihr Nutzen feststehen. Davor würde ich einen kleinen Satz echter Aufgaben sammeln und mit einer einfachen Ausführung testen. Für einen Solo-Freelancer sind schon 20 freigegebene Beispielanfragen wertvoller als ein Architekturdiagramm, weil sie sichtbar machen, ob das Problem überhaupt an Rechenkapazität liegt. Die Zahl 20 ist hier ein Startwert für den eigenen Test, keine statistische Garantie.
Ein typischer Fehlschluss entsteht bei langsamen Demos. Dauert eine Antwort zu lange, wird reflexartig ein schnellerer Server gesucht. Vielleicht enthält der Prompt aber unnötig lange Dokumente, vielleicht erzeugt das Modell Text, den anschließend niemand verwendet. Eine gekürzte Eingabe mit demselben brauchbaren Ergebnis spart Rechenzeit unabhängig davon, auf welcher Maschine sie läuft. Diese Prüfung kostet hauptsächlich Aufmerksamkeit; eine GPU-Miete kostet auch dann Geld, wenn die Ursache unverändert bleibt.
Ich würde keinen Kubernetes-Cluster für einen ersten bezahlten KI-Prototypen aufsetzen, weil dessen Installation, Updates und Fehlersuche die knappe Arbeitszeit verbrauchen, bevor ein Lastproblem belegt ist. Ein einzelner Prozess mit einer dokumentierten Startanweisung reicht für einen Test oft aus, weil sich damit Fehler und Laufzeiten bereits reproduzieren lassen. Docker kann dafür hilfreich sein, wenn die lokale Umgebung sonst vom Zielsystem abweicht; ein Container ist aber noch keine Begründung für einen Orchestrator.
Der Preis der verfrühten Planung ist nicht nur die Serverrechnung. Jede Stunde, in der der Freelancer Skalierung für hypothetische Nutzer absichert, fehlt bei der Prüfung eines realen Ergebnisses. Besonders teuer wird das bei Festpreisaufträgen: Zusätzliche Betriebsarbeit lässt sich dann häufig nicht nachträglich abrechnen, weil sie im Angebot gar nicht als eigener Posten stand. Vor dem ersten Infrastrukturvertrag sollte deshalb ein Satz ins Angebot: Welche Last wird getestet, und wer bezahlt einen späteren Ausbau?
Eine gemietete GPU ist nur während brauchbarer Auslastung günstig
Der zweite Fehler ist, den Stundenpreis einer GPU mit den Kosten einer Antwort zu verwechseln. Eine Instanz kann pro Stunde preiswert wirken und pro erledigter Kundenaufgabe teuer sein, wenn sie auf Eingaben wartet, Modelle lädt oder nach dem Test weiterläuft. Umgekehrt kann ein langsamer lokaler Lauf teuer werden, wenn der Freelancer wegen jeder Iteration auf Ergebnisse wartet. Verglichen werden muss deshalb die vollständige Testserie, nicht nur die Hardwarebezeichnung.
Hier gewinnen zwei ausdrücklich verschiedene Optionen. CPU mit llama.cpp gewinnt bei kleinen Modellen, kurzen Eingaben und unregelmäßigen Tests, weil keine laufende GPU-Miete anfällt; sie kostet dafür Wartezeit und kann bei größeren Modellen an Arbeitsspeicher oder Tempo scheitern. Stundenweise GPU mit vLLM gewinnt bei vielen ähnlichen Anfragen in einem festen Zeitfenster, weil parallele Ausführung und das Zusammenfassen von Anfragen die bezahlte Laufzeit besser nutzen können; sie kostet Miete, Vorbereitung und konsequentes Abschalten. Keiner der beiden Wege gewinnt allein deshalb, weil er auf einem Screenshot schneller aussieht.
Ich lese KI und ML: GPU Server mieten fuer skalierbare Infrastruktur ebenfalls mit Vorbehalt: Eine Mietoption beantwortet noch nicht, wie viele Stunden pro Woche sie tatsächlich Arbeit übernimmt. Als reine Rechenannahme ergeben 0,80 Euro pro Stunde bei 20 eingeschalteten Stunden 16 Euro; diese Beispielrechnung enthält weder Speicher noch die Zeit für Einrichtung und Kontrolle. Sie ist keine Preisangabe eines Anbieters. Der nützliche Wert für ein Angebot ist vielmehr: Kosten der kompletten, wiederholbaren Testserie geteilt durch die Zahl brauchbarer Ergebnisse.
Auch Grafikspeicher wird leicht falsch gelesen. NVIDIA nennt für die GeForce RTX 4090 24 GB Grafikspeicher; das ist eine Herstellerangabe zur Karte, keine Zusage, dass ein bestimmtes Modell samt Kontext, Zwischenspeicher und parallelen Anfragen hineinpasst. Vor einer Miete würde ich Modellgröße, gewünschte Präzision und maximale Eingabelänge festhalten. PyTorch kann für Experimente geeignet sein, während ONNX Runtime oder llama.cpp für eine konkrete Ausführung weniger Verwaltungsaufwand verursachen können; entscheiden sollte ein Test mit denselben Eingaben, weil sonst unterschiedliche Aufgaben verglichen werden.
Der teure Irrtum ist schließlich der vergessene Ausschalter. Eine Testinstanz, die über Nacht weiterläuft, erzeugt Kosten ohne zusätzliche Erkenntnis. Deshalb gehört zur Startanweisung auch eine Stoppanweisung, und nach jeder Sitzung gehört die Instanz auf „aus“ geprüft. Wer diese Handlung nicht zuverlässig in seinen Arbeitsablauf bekommt, sollte keine dauerhafte GPU als vermeintlich günstigen Standard kalkulieren.
Durchsatz ohne Nutzwertmessung optimiert den falschen Engpass
Der dritte Fehler lautet: mehr Anfragen pro Sekunde messen und daraus Kundennutzen ableiten. Ein Modell kann schneller werden, indem es kürzere oder schlechtere Antworten liefert. Eine Anfrage kann außerdem technisch erfolgreich sein, obwohl ihr Ergebnis die Aufgabe verfehlt. Für einen Freelancer ist das gefährlich, weil ein überzeugendes Performancediagramm leicht eine Zusage erzeugt, die spätere Nacharbeit nicht berücksichtigt.
Ich würde zwei getrennte Protokolle führen. Im ersten stehen Eingabelänge, Ausgabelänge, Laufzeit, Fehlermeldung und verwendete Modellversion. Im zweiten bewertet der Auftraggeber anhand derselben Beispiele, ob die Antwort verwendbar ist und welche Korrektur nötig wäre. So bleibt sichtbar, ob eine Beschleunigung tatsächlich Zeit spart oder nur Arbeit vom Server zum Menschen verschiebt. Ein Ziel von beispielsweise 5 Sekunden pro Antwort ist ein veränderbarer Grenzwert für einen bestimmten Ablauf, keine allgemeine Norm für KI-Anwendungen.
Für einen lokalen, OpenAI-kompatiblen Endpunkt lässt sich ein einzelner Antworttest ohne zusätzliche Python-Bibliothek ausführen. Die Umgebungsvariable MODEL muss dabei dem Modellnamen des laufenden Servers entsprechen; INFER_URL kann dessen Adresse überschreiben. Das Skript misst die gesamte Antwortzeit, ausdrücklich nicht die Zeit bis zum ersten Token:
python3 - <<'PY'
import json, os, time, urllib.request
url = os.getenv("INFER_URL", "http://127.0.0.1:8000/v1/chat/completions")
data = json.dumps({"model": os.getenv("MODEL", "local-model"), "messages": [{"role": "user", "content": "Antworte mit OK."}], "max_tokens": 16}).encode()
req = urllib.request.Request(url, data=data, headers={"Content-Type": "application/json"})
start = time.perf_counter()
try:
with urllib.request.urlopen(req, timeout=20) as res:
body = json.load(res)
print(res.status, round(time.perf_counter() - start, 2), body.get("usage", {}))
except Exception as exc:
print(type(exc).__name__, exc)
PY
Ein einzelner Lauf ist noch kein Belastungstest, weil Modellstart, Netz und gleichzeitig eintreffende Anfragen das Ergebnis verändern. Erst danach würde ich mit k6 eine kleine, feste Folge derselben Aufgaben wiederholen und mindestens Fehlerrate sowie das 95. Perzentil der Antwortzeit notieren. Das Perzentil ist nützlich, weil ein guter Durchschnitt einzelne sehr langsame Antworten verdecken kann. OpenTelemetry kann später die Zeitanteile zwischen Anwendung und Modellserver trennen; es zuerst einzubauen kostet jedoch mehr, als eine noch unbekannte Verzögerung wert sein muss.
Auch HTTP-Fehler verdienen eine nüchterne Deutung. HTTP 429 bezeichnet laut RFC 6585 eine Begrenzung von Anfragen; blindes sofortiges Wiederholen kann diese Begrenzung verschärfen, weil es neue Last erzeugt. Ein Wiederholungsversuch mit Pause mag bei vorübergehender Überlast helfen, sollte aber nur für Anfragen erfolgen, deren erneute Ausführung keine unerwünschte Doppelarbeit auslöst. Der wirtschaftliche Maßstab bleibt die Zahl verwendbarer Antworten pro bezahlter Arbeits- und Rechenstunde.
Fehlende Abbruchregeln machen kleine KI-Projekte dauerhaft teuer
Der vierte Fehler ist organisatorisch: Ein Experiment erhält einen Starttermin, aber keine Bedingung, unter der es beendet oder zurückgebaut wird. Das klingt nach Projektverwaltung, hat jedoch direkte technische Kosten. Ohne Grenze bleiben Testdateien liegen, Instanzen werden erneut hochgefahren, und jede kleine Änderung muss gegen einen unklaren Zustand geprüft werden. Wer keine Infrastrukturabteilung hat, übernimmt diese Pflege selbst.
Vor dem ersten bezahlten Lauf würde ich drei Grenzen schriftlich festlegen: einen maximalen Geldbetrag für Rechenzeit, ein Enddatum für den Versuch und ein Kriterium für ein brauchbares Ergebnis. Die konkreten Werte müssen zum Auftrag passen; entscheidend ist, dass ein Abbruch ohne neue Grundsatzdiskussion möglich wird. Wird das Kriterium verfehlt, folgt nicht automatisch mehr Hardware. Zuerst ist zu prüfen, ob die Eingabedaten, der Prompt oder die Aufgabe selbst geändert werden müssen, weil zusätzliche Rechenleistung keines dieser Probleme behebt.
Ebenso wird die Wiederaufnahme oft vergessen. Liegen Testeingaben, Modellkennung und Einstellungen nur in einer interaktiven Sitzung, kostet der nächste Versuch erneut Sucharbeit. Eine kleine Textdatei mit Startbefehl, Modellname, max_tokens, Eingabebeispielen und Abschaltbefehl kann mehr sparen als ein zusätzliches Dashboard, weil sie den Test für denselben Freelancer eine Woche später wiederholbar macht. SQLite reicht für ein kleines lokales Ergebnisprotokoll häufig aus, weil es ohne separaten Datenbankdienst auskommt. Erst wenn mehrere Prozesse gleichzeitig schreiben oder andere Personen Zugriff brauchen, ist dieser einfache Standard erneut zu prüfen.
Bei wachsendem Aufwand würde ich nicht jede Beobachtungsmöglichkeit auf einmal installieren. Prometheus und Grafana lohnen sich, wenn wiederkehrende Last über längere Zeit sichtbar gemacht werden muss; für einen kurzen Versuch kosten Installation und Pflege sonst womöglich mehr als das manuelle Protokoll. Dasselbe gilt für Sicherungskopien: Ein gezielt gespeicherter Satz freigegebener Testfälle ist nützlich, weil Ergebnisse damit vergleichbar bleiben, während das wahllose Aufheben aller Zwischenstände Speicher und Aufräumarbeit erzeugt.
Der härteste Posten ist oft eine stillschweigende Zusage. Steht im Angebot nur „KI-Funktion“, kann der Kunde erwarten, dass Verfügbarkeit, Modellwechsel und spätere Lastspitzen im selben Preis enthalten sind. Ich würde deshalb Entwicklung, zeitlich begrenzten Testbetrieb und laufenden Betrieb getrennt benennen, weil jede Phase andere Kosten auslöst. Das ist keine Ausrede gegen Skalierung; es verhindert, dass ein Einzelner unbezahlte Bereitschaft mit technischer Professionalität verwechselt.
Der erste Schritt ist eine Rechnung, kein neuer Server
Nimm die letzte konkrete KI-Anfrage aus deinem Projekt und notiere Eingabe, gewünschtes Ergebnis, tatsächliche Laufzeit und erforderliche Korrektur. Wiederhole sie mit einem zweiten Beispiel, bevor du Hardware auswählst. Falls du keine solche Anfrage hast, vereinbare sie zuerst mit dem Kunden. Erst aus diesen Fällen lässt sich ein Testbudget ableiten, das du auch dann verantworten kannst, wenn die Idee scheitert.
