Freitag, 17:47 Uhr. Mein Handy klingelt. Am anderen Ende: Markus, IT-Leiter bei einem Sondermaschinenbauer aus der Nähe von Ingolstadt. 45 Mitarbeiter, Familienunternehmen, und seit ein paar Wochen läuft dort Llama 3 im eigenen Serverraum. Seine Botschaft war kurz: „Der Angebotsassistent ist down. Beide Leute aus dem Vertrieb haben ihn gleichzeitig benutzt.“ Was dann kam, war ein Abend mit nvidia-smi, zu viel Kaffee und einer Lektion über KV-Caches, die ich nicht mehr vergesse.
Dieser Bericht ist ehrlich gemeint: Was es wirklich kostet hat, Llama 3 im eigenen Rechenzentrum zu betreiben, wo wir uns vertan haben, und warum der Betrieb nach drei Monaten auf ein Hybrid-Modell umgestellt wurde. Falls du gerade erst mit KI im Mittelstand anfängst: Fang nicht hier an. Unser No-Hype-Playbook für KI-Automatisierung im Mittelstand ist der bessere Einstieg, On-Prem ist Lektion 401.
Die Ausgangslage: Warum Public Cloud keine Option war
Der Geschäftsführer ist kein Techniker, aber eine Sache stand vom ersten Gespräch an fest: „Unsere Kundendaten verlassen das Haus nicht.“ Konkret heißt das: Anfragen mit technischen Zeichnungen, Angebotsdaten, Materiallisten aus SAP. Ein großer Teil der Kunden sind Automobilzulieferer mit entsprechend strengen Vertraulichkeitsklauseln. Dazu kommt die DSGVO, und im Hintergrund das Schrems-II-Urteil, das Auftragsverarbeitungsverträge mit US-Anbietern wackelig macht.
Ich hab anfangs dagegen gehalten. Azure OpenAI in einer EU-Region, Zero-Retention-Zusage, sauberer AVV, das ganze Programm. Mein Argument: Für 99 Prozent der Mittelständler reicht das völlig. Sein Gegenargument war kürzer: „Amerikanischer Anbieter bleibt amerikanischer Anbieter.“ Nach Schrems II kann man diese Haltung nicht mal als paranoid abtun, und vertraglich war das Kind ohnehin geschieden. Die Kundenverträge saßen tiefer als jede Cloud-Empfehlung von mir.
Der Anwendungsfall war klar: ein Angebotsassistent, der aus Anfrage-Mails erste Angebotsskizzen baut, plus ein Wissensassistent für Handbücher und Wartungsdoku. Beides berührt Kundendaten in fast jedem Schritt. Also stand es im Projektplan: Llama 3, selbst gehostet, im eigenen RZ.
Das Hardware-Setup: 38.500 Euro und ein Serverraum neben der Kaffeeküche
Zuerst die Modellfrage. Llama 3 kommt in mehreren Größen, für uns relevant waren 8B und 70B Parameter. Der 70B sollte der Hauptakteur werden, quantisiert in 4 Bit (AWQ), das belegt rund 40 GB VRAM. Vier RTX 4090 mit je 24 GB ergeben 96 GB, genug für Modell plus KV-Cache. Über A100 oder H100 haben wir kaum nachgedacht: Eine gebrauchte A100 mit 80 GB kostete über 10.000 Euro pro Stück. Für dieses Geld bekamen wir vier 4090er und hatten noch Budget für den Rest.
Die Anschaffung im Überblick:
- GPU-Server (4x RTX 4090, Dual-CPU, 512 GB RAM): rund 25.000 Euro
- Workstation für den 8B und für Tests (1x RTX 4090): rund 6.500 Euro
- USV, Rack, 10-Gbit-Switch, Verkabelung: rund 4.300 Euro
- Serverraum-Umbau (Klima, Tür, Brandmeldeanbindung): rund 2.700 Euro
Macht 38.500 Euro Anschaffung. Der Serverraum selbst ist ein umgebauter Abstellraum direkt neben der Kaffeeküche, und vier 4090er unter Volllast klingen wie ein Startmotor. Das erste Team-Meeting dort drüben haben wir nach fünf Minuten nach oben verlegt.
Was ich unterschätzt habe, war der Wartungsaufwand. Ich hatte zwei Stunden pro Woche kalkuliert, im ersten Monat waren es real 12 bis 15. CUDA-Treiber, vLLM-Updates, Monitoring, Thermik, dazu der Sprung von Llama 3 auf 3.1, der zum Glück nur einen Nachmittag gekostet hat. Und Strom: Der große Server zieht unter Last rund 1,8 kW. Über drei Monate kamen wir auf etwa 2.900 kWh, bei 0,34 Euro pro kWh sind das knapp 1.000 Euro. Nicht ruinös, aber ein Posten, den vorher niemand auf dem Schirm hatte.
Drei Hürden, die uns richtig Zeit gekostet haben
Drei Dinge haben uns mehr Zeit gekostet als alles andere. Keine davon stand in irgendeinem Beratungsslider.
1. Durchsatz: Physik lässt sich nicht patchen
Ein 70B auf vier 4090ern liefert pro Anfrage grob 12 bis 18 Tokens pro Sekunde. Für Chat völlig okay. Aber der Angebotsassistent sollte Dokumente von 20, 30 Seiten verdauen, und wenn zwei Vertriebskollegen das gleichzeitig tun, wird der Speicher eng. Zurück zum Freitagsabend: vLLM lief mit Standardeinstellungen und reservierte 90 Prozent des VRAM für Modell und KV-Cache. Zwei parallele Requests mit langem Kontext, und der war durch. Out of Memory, Assistent tot, beide Kollegen sahen einen 500er.
Die Lösung war banal und hat trotzdem drei Stunden gedauert: maximale Kontextlänge pro Request runter, Parallelität begrenzt, eine Warteschlange davor. Seither läuft das stabil. Aber Ausfälle dieser Art kosten dich irgendwann das Vertrauen deiner Nutzer, und das ist teurer als jede GPU. Wir haben danach ein Healthcheck-Monitoring aufgesetzt und die Kette wie jede andere produktive Integration behandelt. Wie man Ausfälle sauber abfängt, haben wir in unserem Artikel zu Workflow Reliability aufgeschrieben.
2. Halluzinierte Materialnummern und mein LoRA-Debakel
Die Qualitätsfrage war die härtere Nuss. Llama 3 70B kann gut schreiben und zusammenfassen, das stimmt. Aber bei SAP-Materialnummern und Teilelisten hat das Modell furchtbar selbstbewusst Nummern erfunden, die plausibel aussahen und nicht existierten. Zwei Wochen lang haben wir Prompts gedreht, Beispiele eingebaut, Ausgabeformate vorgegeben. Hat fast nichts gebracht. Irgendwann mussten wir einsehen, was wir eigentlich längst wussten: Prompting strukturiert Wissen, aber es schafft keins. Dazu passt unser Beitrag darüber, warum Prompt-Engineering deine KI-Fehler nicht repariert.
Dann mein Fehler. Ich war fest davon überzeugt, ein LoRA-Finetuning mit den historischen Angeboten würde die Nummern in den Griff kriegen. 320 Beispiele aufbereitet, ein Wochenende Trainingszeit verbrannt. Sonntagabend saß ich vor der Auswertung: Das finetunete Modell war bei Standardtexten messbar schlechter und hatte die Halluzinationen trotzdem noch. 320 Beispiele sind schlicht zu wenig für ein Finetuning, das hätte ich vorher wissen können. Ich wusste erstmal nicht weiter, und diese Einsicht hat mich beim Kunden einen Tag Überzeugungsarbeit gekostet. Sowas nagt an dir.
Geholfen hat am Ende etwas Langweiliges: Retrieval. Eine Postgres mit pgvector, gefüllt mit Materialnummern und Positionen aus alten Angeboten, plus der kleine 8B, der nichts weiter tut, als daraus die passenden Positionen zu ziehen. Weniger Modell, mehr Datenbank. Klingt nach Rückschritt, war aber der Durchbruch.
3. Markus als Single Point of Failure
45 Mitarbeiter, davon genau eine Person, die vLLM, CUDA und das Monitoring versteht: Markus. Als er zwei Wochen Urlaub hatte, ist der Dienst nach einem kurzen Stromausfall nicht wieder hochgekommen. Die USV hielt durch, aber der Autostart war falsch konfiguriert. Zwei Stunden Ausfall. Kein Drama, aber es zeigte das eigentliche Risiko von On-Prem: Ausfälle, Updates und Patches sind dein Problem. Auch nachts um zwei. Ein 45-Personen-Betrieb hat kein On-Call-Team, das gibt es in dieser Größe schlicht nicht.
Wir haben danach Runbooks geschrieben und eine zweite Person eingearbeitet. Weg ist das Risiko trotzdem nicht. Das ist Realität im Mittelstand, und wer dir etwas anderes erzählt, hat noch nie einen Serverraum neben einer Kaffeeküche betreut.
Die Kehrtwende: Wie das Hybrid-Modell heute aussieht
Nach zehn Wochen haben wir Bilanz gezogen, mit dem Geschäftsführer und Markus am Tisch. Das Ergebnis war ernüchternd und befreiend zugleich: Rund 70 Prozent der tatsächlichen Nutzung kamen gar nicht mit Kundendaten in Kontakt. Übersetzungen, Marketingentwürfe, allgemeine Recherche, Code-Hilfe für die Maschinensteuerung. Dafür das eigene RZ zu nutzen war schlicht Verschwendung.
Die Architektur heute:
- Alles mit Kundendatenbezug (Angebotsassistent, E-Mail-Triage, Wissensassistent) läuft auf dem selbst gehosteten Llama 3 8B mit Retrieval aus der Postgres. Auf einer einzigen 4090 fliegt der mit 60 bis 80 Tokens pro Sekunde.
- Der große 70B-Server arbeitet nur noch nachts: Batch-Jobs für Ausschreibungsanalysen und große Dokumentenpakete. Tagsüber ist er aus.
- Der Rest geht über einen EU-gehostierten API-Dienst mit sauberem AVV. Eine Datenkategorie-Klassifizierung steuert das Routing davor.
Vorgeschaltet ist eine einfache Routing-Logik in n8n. Welche Automatisierungsplattform für so etwas taugt, haben wir in unserem Vergleich von Zapier, Make und n8n aufgedröselt. Und weil der Angebotsassistent intern nicht als Chatfenster, sondern als Agent mit Werkzeugen arbeitet, lohnt an der Stelle auch unser Artikel darüber, wie Agenten-Systeme im Alltag wirklich funktionieren.
Ehrlich gesagt klang „Hybrid“ für mich anfangs nach Rückzieher. Ist es nicht. Ich bin mir bis heute nicht sicher, ob wir nicht schon in Woche eins darauf hätten kommen müssen.
Echte Zahlen: Was drei Monate Betrieb gekostet haben
Jetzt der Teil, für den du vermutlich hier bist. Alle Posten, ohne Schönfärberei:
- Hardware gesamt: 38.500 Euro
- Strom: rund 980 Euro (2.900 kWh à 0,34 Euro)
- Interne Arbeitszeit (120 Stunden, intern mit 45 Euro kalkuliert): 5.400 Euro
- Unsere Projektbegleitung (Konzeption, Setup, Schulung): rund 12.000 Euro
Summe über drei Monate: knapp 57.000 Euro.
Und jetzt der Vergleich, der wehtut. Das Token-Volumen des Kunden lag bei rund 10 Millionen Tokens im Monat. Über einen EU-gehostierten API-Dienst mit vergleichbarer Modellqualität wären das je nach Modell grob 100 bis 250 Euro im Monat gewesen, also vielleicht 500 Euro für den ganzen Zeitraum. Ja, du liest richtig.
Fairerweise: Die 12.000 Euro Projektbegleitung und ein Großteil der 120 Stunden hätte man mit einer API genauso gebraucht, das liegt nicht am Self-Hosting. Aber selbst wenn man nur die laufenden Kosten betrachtet (Abschreibung über fünf Jahre, Strom, die inzwischen auf etwa vier Stunden pro Woche gesunkene Wartung), landen wir bei rund 2.000 Euro im Monat. Gegenüber grob 150 Euro Token-Kosten. Datensouveränität kostet hier schlicht etwa das Zehnfache.
War es das wert? Rein wirtschaftlich: nein. Ohne die vertraglichen Anforderungen der Automobilkunden hätte ich von dem Projekt abgeraten, so klar kann und will ich das sagen. Aber Wirtschaftlichkeit war nie der Maßstab des Geschäftsführers. Kein einziges Kundendokument hat das Haus verlassen, und das war ihm den Preis wert. Nach drei Monaten kann ich beide Positionen nachvollziehen.
Wo das Projekt heute steht
Der Angebotsassistent bearbeitet inzwischen rund 200 Anfragen im Monat, die Durchlaufzeit für eine erste Angebotsskizze ist von zwei Tagen auf unter zwei Stunden gesunken. Der kleine 8B mit Retrieval schlägt sich übrigens besser als der 70B es je getan hat. Das nagt ein bisschen an mir, wenn ich an die 25.000-Euro-Maschine denke, die jetzt Nachtschichten schiebt.
Was ich mitnehme: Llama 3 im eigenen Rechenzentrum funktioniert, wenn du drei Dinge mitbringst. Einen echten Grund. Eine Person mit Zeit. Und ein Budget für das Doppelte deiner Erstschätzung. Fehlt einer davon, schau dir zuerst EU-APIs mit sauberen AVVs an. Das ist kein Versagen, das ist Ingenieursökonomie.
Wenn du selbst so ein Projekt am Start hast und deine Zahlen gegen unsere halten willst: Schreib mir, ich teile gern das Rechenblatt. Wer hier überhaupt schreibt, kannst du hier nachlesen. Bis zum nächsten Projektbericht, dein Damian.
