Wie ich einen KI-Chat auf meinem Portfolio selbst gehostet habe (und warum ich damit aufgehört habe)

Auf dieser Seite gibt es einen Chat namens Ask Tungi. Du kannst ihn nach meinen Projekten fragen, danach, wie ich arbeite, was ich über Produktprobleme denke. Darunter zieht eine Retrieval-Pipeline Projektkontext heran, und ein Sprachmodell antwortet in meiner Stimme.

Die meisten würden eine API aufrufen und wären fertig. Das habe ich am Ende auch getan. Vorher habe ich allerdings ein paar Wochen damit verbracht, ein eigenes Modell auf einer dedizierten GPU zu betreiben, und der Umweg hat mich mehr gelehrt als das Ziel.

Keine Abrechnung pro Token: Du bezahlst die Rechenzeit, die du bereitstellst, egal wie viel oder wenig sie produziert. Volle Kontrolle über das Modell. Offene Gewichte, also später auch Fine-Tuning möglich. Und die Daten bleiben auf der eigenen Infrastruktur. Nach Jahren, in denen ich unter DSGVO und KRITIS ausgeliefert habe, ist mir der letzte Punkt wichtig.

Ich habe eine GPU-Plattform gefunden, die dedizierte Maschinen hinter einer gewöhnlichen Chat-Completions-API kapselt. Modell wählen, Maschine wählen, deployen, Endpunkt bekommen. Innerhalb einer Stunde lief ein Chat und streamte Antworten.

Dann fingen die Probleme an.

Die Größe deines Modells entscheidet über die GPU. Ein Modell mit 7 Milliarden Parametern läuft problemlos auf einer A10G mit 24 GB VRAM. Wird es größer (13B, 70B), brauchst du A100s oder H100s, und die kosten pro Stunde richtig Geld.

Die Plattform bot serverlose GPUs an, die auf null skalieren, wenn niemand chattet. Klingt ideal für eine Portfolio-Seite. Nur muss das Modell nach einer Leerlaufphase erst wieder in den VRAM geladen werden, sobald die erste Nachricht eintrifft, und das dauert zehn bis dreißig Sekunden.

Meine Seite hat einstellige Besucherzahlen pro Tag, also trifft jede erste Nachricht auf eine kalte GPU. Bei diesem Traffic ist der Cold Start das ganze Erlebnis.

Eine dauerhaft laufende GPU löst das und kostet fünfzig bis zweihundert Dollar im Monat, was ich für ein Portfolio-Projekt nicht rechtfertigen konnte.

In diesem Setup bekommst du zwei von dreien.

Ein gutes Modell auf einer schnellen GPU gibt dir Qualität und Geschwindigkeit und kostet mehr als meine Domain und das Hosting zusammen. Ein gutes Modell auf einer serverlosen GPU gibt dir Qualität und niedrige Kosten, dazu fünfzehn Sekunden Cold Start; der Besucher starrt auf einen Spinner, und manche schließen den Tab. Ein kleines Modell auf einer serverlosen GPU ist schnell und günstig, und die Antworten werden schlechter: kürzer, generischer, schlecht darin, einem detaillierten System-Prompt zu folgen.

Eine Weile saß ich in der mittleren Variante, Qualität und günstig, und jede Session begann mit fünfzehn Sekunden Wartezeit. Ich hatte das Feature gebaut, um zu zeigen, wie ich über Produkte denke, und es machte dafür keine gute Figur.

Ein Grund fürs Selbsthosten war Fine-Tuning. Der Plan: ein Modell mit offenen Gewichten nehmen, es auf meinen Schreibstil trainieren und einen Chat bekommen, der nach mir klingt, ohne einen riesigen System-Prompt zu brauchen. Ich hatte angefangen, die Trainingsdaten zusammenzustellen. Frage-Antwort-Paare, Tonbeispiele, Leitplanken.

Dann habe ich die Wartungsrechnung aufgemacht.

Ein Modell von Grund auf zu trainieren, ist für eine einzelne Person nicht realistisch. Du brauchst Rechenleistung, Datenpipelines, Monate an Arbeit. Fine-Tuning ist zugänglicher, altert aber schlecht. Modelle werden alle sechs bis zwölf Monate ersetzt, und wenn die nächste Generation kommt, liegen deine feinjustierten Gewichte auf alter Architektur. In jedem Zyklus trainierst, evaluierst und deployst du erneut.

Ein guter System-Prompt funktioniert auf jedem Modell. Eine Retrieval-Pipeline, die den passenden Projektkontext heranzieht, interessiert sich nicht dafür, was die Antwort erzeugt hat. Und eine belastbare Eval-Suite sagt dir innerhalb von Minuten, ob ein neues Modell noch trägt; meine fährt über sechzig Tests für Stimme, Leitplanken und Injection-Resistenz.

Also habe ich die Eval-Suite gebaut statt des Fine-Tunings. Wenn ich das Modell wechseln muss, ändere ich eine Umgebungsvariable, lasse die Tests laufen und liefere aus. Da investiere ich lieber hinein als in Gewichte, die ich in einem Jahr wegwerfe.

Es gibt Fälle, in denen Fine-Tuning richtig ist. Spezialisiertes Reasoning, ungewöhnliche Ausgabeformate, Randfälle, die kein Prompt abdeckt. Für einen dialogischen Chat mit klarem Charakter haben Prompting und Retrieval gereicht, ohne den Overhead.

Als ich von der GPU wegging, kam jede Sicherheitsschicht unverändert mit. Erkennung von Prompt Injection für Jailbreak-Versuche. Rate Limiting über Redis, zwanzig Anfragen pro Stunde und IP. CSRF-Origin-Prüfungen. Eingabebereinigung mit Längenbegrenzung. Eine zustandslose Edge Function: Das Rate Limiting kennt die IP, im Request-Log steht eine gekürzte Fassung davon, auf dem Server liegt kein Nachrichtentext, und das Gespräch selbst liegt in deinem Browser-Tab, bis du ihn schließt.

Das alles sitzt vor dem Modellaufruf. Es funktioniert gleich, ob das Modell auf einer gemieteten GPU liegt oder hinter einer fremden API, denn die Sicherheitsgrenze gehört zur Anwendung, und der Anbieter ist ein Detail dahinter.

Ich bin auf eine gehostete API mit einem kleinen, schnellen Modell umgezogen: Zeit bis zum ersten Token unter einer Sekunde, keine Cold Starts und bessere Fehler. Ich konnte jetzt einen falschen Key, ein Rate Limit, einen Ausfall upstream und einen Timeout auseinanderhalten, wo ich vorher für alles eine generische "schläft gerade"-Meldung bekam.

Bei meinem Traffic, unter hundert Nachrichten im Monat, liegen die API-Kosten unter einem Dollar. Das GPU-Setup war im Leerlauf kostenlos, lief aber auf fünfzehn bis zwanzig Dollar, sobald es jemand benutzte. Plus Cold Start in jeder Session.

Hätte ich Tausende Gespräche am Tag oder bräuchte ich strikte Datenresidenz, ginge die Rechnung andersherum auf. Selbsthosten gewinnt, wenn sich Token-Kosten auftürmen und du Kontrolle brauchst, die die API nicht hergibt. In dieser Lage war ich nicht.

Sobald die Infrastrukturentscheidung stand, begann die interessante Arbeit.

Aus der Retrieval-Pipeline ist der Teil geworden, auf den ich am stolzesten bin. Ich bin von einfachem Keyword-Matching zu TF-IDF-Vektoren mit Kosinus-Ähnlichkeit gewechselt: Jeder Projekt- und Fallstudienabschnitt wird zur Build-Zeit vektorisiert, eingehende Anfragen werden dagegen abgeglichen. Dazu kam Query Expansion, damit Synonyme und verwandte Begriffe die passenden Abschnitte nicht verfehlen. Der Ähnlichkeitsschwellwert hat mehrere Runden Justieren gebraucht: zu streng, und Einstiegsfragen wie "Was war dein schwierigstes Projekt?" lieferten gar nichts; zu locker, und sachfremde Abschnitte verunreinigten den Kontext.

Die Arbeit an der Stimme war schwieriger. Ich habe den System-Prompt mehrfach neu geschrieben, bis der Ton saß: selbstbewusst, ohne anzugeben, konkret zu meinen eigenen Projekten, und fähig, über ein langes Gespräch in der Rolle zu bleiben, ohne in generisches Beratersprech zu rutschen. Die Eval-Suite hat jede Regression abgefangen, wenn ich am Prompt etwas geändert habe.

Das Feature, über das ich mich am meisten freue, ist der Dokumenten-Upload. Du kannst eine Stellenausschreibung oder ein Projektbriefing hineinlegen, und der Chat gleicht meine Erfahrung dagegen ab: konkrete Projekte, relevante Fähigkeiten, bei einer Stellenausschreibung ein Match-Score. Das funktioniert nur, weil das Retrieval in den Fallstudien selbst verankert ist, und der Vektorindex ist das, was es konkret macht.

Fang mit der API an und liefere das Feature aus. Die schwierigen Probleme eines KI-Chats liegen woanders: das Retrieval gut genug zu machen, damit die Antworten geerdet sind, einen Prompt zu schreiben, der eine gleichbleibende Stimme hält, Tests zu bauen, die einen Qualitätsabfall bemerken, und die Sicherheitsgrenze zwischen Nutzereingabe und Modellausgabe dicht zu halten.

Hoste selbst, wenn du einen konkreten Grund hast: eine Token-Rechnung, die wehtut, eine Anforderung an Datenresidenz, ein Modell, das die APIs nicht anbieten.

Die GPU war gemietet. Die Retrieval-Pipeline, der System-Prompt und die Eval-Suite sind das, was ich weiter benutze, und sie laufen auf jedem Backend.