Kurz gesagt

  • Tickets, Eingangsrechnungen und Firmenwissen verarbeitet bei uns KI, die im eigenen Netz läuft. Cloud-Modelle nutzen wir nur, wo die Daten es erlauben.
  • Ein Server mit zwei Grafikkarten betreibt ein großes Sprachmodell, ein Bildmodell und die Modelle für die Suche im Firmenwissen.
  • In den letzten 15 Monaten haben unsere Anwendungen darüber rund 4,9 Milliarden Tokens verarbeitet, im Schnitt 325 Millionen im Monat.
  • Die Hardware kostete rund 12.000 Euro zu Preisen von Anfang 2025. Strom kostet rund 60 Euro im Monat, knapp 20 Cent je Million Tokens.
  • Im Oktober 2026 haben wir das große Modell nach einem Vergleich an echten Tickets gewechselt: Gemma 4 ordnet deutlich besser ein als GPT-OSS, ist aber etwas langsamer.
  • Eine neuere Version von TensorRT-LLM, auf dem GPT-OSS lief, haben wir gemessen und nicht eingespielt: Sie war nicht spürbar schneller.

Warum eigene Hardware

Ein Ticket enthält Namen, Adressen, Bestellungen und manchmal Beschwerden. Eine Eingangsrechnung enthält Bankverbindungen. Für solche Daten wollten wir keine Abwägung je Anbieter, sondern eine einfache Antwort: Sie bleiben im eigenen Netz. Cloud-Modelle nutzen wir weiterhin, aber für Aufgaben, bei denen die Daten das erlauben. Welche Aufgabe wohin geht, legen wir einzeln fest.

Was lokal läuft

Diese Aufgaben laufen im Alltag vollständig auf dem eigenen Server:

  • Im Ticketsystem: Zusammenfassungen jedes Vorgangs, Übersetzungen, das Verbessern von Texten und Antwortentwürfe auf Basis des bisherigen Ticketverlaufs.
  • Anhänge: Das Bildmodell beschreibt Fotos und Screenshots, die Kunden mitschicken. So fließen sie in die Zusammenfassung ein, statt übersehen zu werden.
  • Eingangsrechnungen: PDF-Rechnungen, die keine E-Rechnung sind, werden in strukturierte Daten übertragen und für die Zahlung vorbereitet. Freigegeben wird von Menschen.
  • Im Team-Chat: die tägliche Agenda je Person und kurze Hinweise, wenn ein Ticket zu eskalieren droht.
  • Firmenwissen: Fragen werden aus Tickets, Notizen und Dokumenten beantwortet, mit Quellenangabe. Dafür machen zwei eigene Modelle die Texte durchsuchbar und sortieren die Treffer nach Relevanz, bevor das Sprachmodell antwortet.

Die Hardware

Der Server steht in unserem Netz und ist nur von dort und per VPN erreichbar. Er hat zwei Grafikkarten mit getrennten Aufgaben:

  • NVIDIA RTX PRO 6000 Blackwell mit 96 GB Grafikspeicher, auf 300 Watt begrenzt. Sie betreibt seit Oktober 2026 Gemma 4 31B, ein frei verfügbares Sprachmodell von Google. Drei Anfragen laufen gleichzeitig, jede mit Platz für rund 65.000 Tokens. Ein langer Ticketverlauf passt damit vollständig hinein.
  • AMD Radeon RX 7900 XTX mit 24 GB. Sie betreibt eine kleinere Variante von Gemma 4, die auch Bilder versteht, sowie die beiden kleinen Modelle für die Suche.

Bis Oktober 2026 lief auf der ersten Karte GPT-OSS 120B von OpenAI mit Platz für rund 120.000 Tokens je Anfrage. Es belegte die Karte fast vollständig: Von 96 GB blieben knapp 3 GB frei. Bevor wir das Fenster verkleinert haben, haben wir über eine Million protokollierte Anfragen ausgewertet: Im letzten Monat brauchten 99 von 100 Anfragen weniger als 30.000 Tokens, die größten knapp 60.000. Gemma 4 lässt im Betrieb rund 43 GB frei.

Was er leistet

Ein Token ist ein Wortteil, ein deutsches Wort hat meist ein bis drei davon. Mitgezählt sind auch die Tokens, mit denen das Modell überlegt, bevor es antwortet.

  • Gemma 4 im Betrieb: In den ersten 345 Anfragen nach der Umstellung schrieb das Modell im Median 97 Tokens pro Sekunde. Eine Anfrage dauerte im Median zehn Sekunden, eine vollständige Ticketanalyse im Test gut 20 Sekunden.
  • Multi-Token Prediction: Ein kleines Zusatzmodell schlägt jeweils mehrere Tokens im Voraus vor, das große Modell prüft sie in einem Schritt, statt jedes Token einzeln zu erzeugen. Mit einer älteren Version von llama.cpp und ohne dieses Verfahren schaffte Gemma rund 35 Tokens pro Sekunde, für den Alltag zu langsam. Von vier Einstellungen, alle an denselben acht Tickets gemessen (75 bis 80 Tokens pro Sekunde), haben wir die mit der kürzesten Bearbeitungszeit behalten.
  • Zum Vergleich GPT-OSS 120B: Gemessen haben wir mit NVIDIAs eigenem Testprogramm und immer denselben Eingaben, ohne dass frühere Anfragen etwas zwischengespeichert hatten. So lassen sich die Werte später wiederholen. Eine Anfrage allein: rund 134 Tokens pro Sekunde. Acht Anfragen gleichzeitig: zusammen rund 394, jede einzelne etwa 52.

Für unsere Arbeit reicht das deutlich. Zusammenfassungen und Entwürfe entstehen im Hintergrund, während jemand das Ticket öffnet. Die Grenze liegt bei vielen gleichzeitigen Anfragen: Der Server wächst nicht mit, wie es ein Cloud-Dienst tut. Anwendungen, die ihn nutzen, regeln deshalb selbst, wie viele Anfragen sie gleichzeitig stellen.

Was er kostet

Die Hardware kostete im Januar 2025 rund 12.000 Euro. Die Preise für solche Hardware sind seitdem gestiegen; heute läge der Betrag höher.

Der Server braucht an Werktagen etwa 7 kWh, am Wochenende etwa 6 kWh. Das sind rund 2.450 kWh im Jahr, im Schnitt knapp 300 Watt. Bei 30 Cent je Kilowattstunde sind das gut 700 Euro Strom im Jahr, rund 60 Euro im Monat.

Dem steht die Menge gegenüber. In den letzten 15 Monaten haben unsere Anwendungen über die Sprachmodelle 4,87 Milliarden Tokens verarbeitet: 4,50 Milliarden Tokens Eingabe und 371 Millionen Tokens Ausgabe, Wiederholungen eingeschlossen. Das sind im Schnitt rund 325 Millionen Tokens im Monat oder knapp 11 Millionen am Tag. Gut 92 % davon sind Eingabe: Die KI liest vor allem Ticketverläufe, Rechnungen und Dokumente und schreibt vergleichsweise wenig.

  • Nur Strom: knapp 20 Cent je Million Tokens.
  • Strom und Hardware, die Hardware auf fünf Jahre Nutzung verteilt: rund 80 Cent je Million Tokens.

Gebühren je Anfrage fallen nicht an: Ob das Team zehn oder tausend Zusammenfassungen am Tag erzeugt, ändert an den Kosten kaum etwas. Bei einem Cloud-Dienst wird jeder dieser Tokens abgerechnet; wer über lokale KI nachdenkt, sollte seine eigene Menge mit den aktuellen Preislisten vergleichen.

Nicht in dieser Rechnung steht die eigene Arbeit: Updates, Überwachung und Fehlersuche übernimmt kein Anbieter.

Kein Update ohne Messung

GPT-OSS lief bei uns auf TensorRT-LLM, der Software von NVIDIA, die das Modell auf der Grafikkarte ausführt. Dafür erscheinen fast wöchentlich Vorabversionen. Im August 2026, als wir noch GPT-OSS einsetzten, haben wir die aktuelle stabile Version geprüft, bevor wir sie einspielen. Gemma 4 läuft heute auf llama.cpp; dort gilt dasselbe Vorgehen:

  1. Vorher festlegen, was zählt: Umgestellt wird nur, wenn eine einzelne Anfrage mindestens 10 % schneller wird oder der Gesamtdurchsatz mindestens 15 %, ohne dass Funktionen verloren gehen.
  2. Getrennt aufbauen: Die neue Version kam in eine eigene, frische Umgebung. Die laufende blieb unverändert als Rückweg.
  3. Die Karte exklusiv übergeben: Da das Modell die Karte fast füllte, passten nicht zwei Versionen gleichzeitig darauf. Für den Test pausierte der Produktivbetrieb in einem abgestimmten Zeitfenster.
  4. Gleich messen: dieselben fünf Lastfälle mit festen Eingaben wie bei der laufenden Version, dazu Funktionstests für Chat, Streaming und Werkzeugaufrufe.

Das Ergebnis: Die Funktionstests verhielten sich wie bei der laufenden Version, die Geschwindigkeit änderte sich je nach Lastfall um −1,7 % bis +3,5 %. Keine Schwelle war erreicht. Wir haben die bewährte Version zu diesem Zeitpunkt beibehalten, bis wir im Oktober einen Modellwechsel getestet haben.

Modellwechsel: erst messen, dann tauschen

Neue Modelle erscheinen fast jeden Monat, und jedes verspricht bessere Werte in allgemeinen Tests. Ob es unsere Tickets besser einordnet, sagt keiner davon. GPT-OSS 120B haben wir deshalb erst ersetzt, nachdem wir Kandidaten an genau dieser Aufgabe gemessen hatten:

  1. Echte Fälle einfrieren: acht ausgewählte Tickets mit bekannten Fallstricken, etwa eine fehlende Palette, die sofort eskaliert werden muss, eine Rechnungsrückfrage, die wie ein Zahlungsproblem aussieht, und eine Kennzahl, die sich als künstlich aufgebläht herausstellte. Eingaben, Anweisungen und Ausgabeformat waren für alle Modelle identisch.
  2. Mehrfach fragen: Jedes Modell bewertete jedes Ticket dreimal, damit Zufallsschwankungen sichtbar werden.
  3. Gegen die Quellen prüfen: Jede Antwort wurde nach einem vorab festgelegten Raster gegen den Ticketinhalt bewertet: Einordnung, Fakten und vorgeschlagener nächster Schritt, zusammen höchstens 10 Punkte.
  4. Vorauswahl: Infrage kamen nur frei verfügbare Modelle, die wir auch auf eigener Hardware betreiben können. Sechs davon haben wir für den Vergleich bei einem Anbieter gemietet, der sie bereits betreibt, statt jedes herunterzuladen, einzurichten und abzustimmen, nur um es zu testen. Dazu kam GPT-OSS auf unserem Server in zwei Einstellungen. Diesen einmaligen Test mit echten Tickets haben wir bewusst freigegeben; im Alltag verlassen diese Daten das Haus nicht.
  5. Lokal nachmessen: Erst den Favoriten haben wir auf unserer eigenen Karte eingerichtet und erneut getestet, in der Fassung, die tatsächlich darauf passt, mit denselben 24 Analysen.

Die Rangfolge im Vorvergleich, je 24 Analysen, Punkte von 10:

  1. Gemma 4 31B (Google): 8,3
  2. Qwen3.8 Flash (Alibaba): 8,1
  3. Qwen3.8 27B (Alibaba): 7,9
  4. GLM-5.3 Flash (Z.ai): 7,9
  5. Nemotron 3 Super 120B (NVIDIA): 6,9
  6. GPT-OSS 120B (OpenAI), bisher bei uns im Einsatz: 6,3 mit hoher und 6,1 mit mittlerer Denktiefe
  7. Mistral Small 4 (Mistral AI): 6,0

Die ersten vier liegen so dicht beieinander, dass acht Tickets keine sichere Reihenfolge ergeben. Für Gemma sprach neben dem höchsten Wert, dass es bei wiederholten Fragen am beständigsten antwortete und die wenigsten Sachfehler machte. Alle vier lagen klar vor GPT-OSS.

  • Gemma 4 31B auf unserem Server: 8,2 von 10, fast gleichauf mit der gemieteten Fassung in voller Genauigkeit. Alle 24 Antworten kamen beim ersten Versuch im verlangten Format. Bei GPT-OSS brauchte im Betrieb rund jeder sechste Lauf mehr als einen Modellaufruf, etwa für Formatkorrekturen.
  • Schneller als gemietet: Beim Anbieter schrieben die fünf besten Modelle im Test 23 bis 58 Tokens pro Sekunde, Gemma 4 rund 23. Auf unserem Server liefert dasselbe Modell 80 bis 100, drei- bis viermal so schnell. Die gemieteten Werte hängen von der Auslastung des Anbieters ab und sind keine Bestwerte.
  • Der Preis: Gemma schreibt rund 80 bis 100 statt 134 Tokens pro Sekunde, die wir vorher mit GPT-OSS 120B erreicht haben. Für Analysen im Hintergrund ist uns die bessere Einordnung wichtiger als ein paar Sekunden.

Acht Tickets sind eine Stichprobe, kein Beweis für jeden Fall, und die lokale Fassung haben wir nachträglich nach demselben Raster bewertet. Auch das bessere Modell erkennt nicht jeden Zusammenhang und macht Fehler. Das ist die Grenze lokaler Modelle in dieser Größe, und der Grund, warum die KI bei uns vorbereitet und ein Mensch entscheidet. Nach der ersten Woche im Betrieb prüfen wir echte Ergebnisse nach demselben Raster. Die alte Umgebung bleibt bis dahin als Rückweg erhalten.

Was „kompatibel“ in der Praxis heißt

Die Modellserver sprechen dieselbe Schnittstelle wie bekannte Cloud-Dienste. Trotzdem lief nicht alles ohne Anpassung:

  • Denkende Modelle brauchen Platz: GPT-OSS und Gemma 4 überlegen, bevor sie antworten. Ist die erlaubte Antwortlänge zu knapp, bleibt die eigentliche Antwort leer. Jede Anwendung setzt deshalb ein ausreichendes Budget und behandelt eine leere Antwort als Fehler.
  • Nicht jede Funktion verhält sich gleich: Eine erzwungene Werkzeugwahl, wie Cloud-Dienste sie anbieten, unterstützte TensorRT-LLM für GPT-OSS nicht. Gemma lieferte strukturierte Antworten erst zuverlässig, nachdem wir eine Korrektur aus der Entwicklung von llama.cpp übernommen hatten und die Formatbeschreibung ohne verschachtelte Verweise übergaben. Unsere Zwischenschicht gleicht solche Unterschiede aus, die Anwendungen merken davon nichts.

Was der eigene Server nicht löst

Ein Server ist ein Server: Fällt er aus, fehlen Zusammenfassungen und Entwürfe, bis er wieder läuft. Die Tickets selbst bearbeitet das Team dann ohne diese Hilfe weiter, weil die KI vorbereitet und nicht entscheidet. Und die größten Cloud-Modelle sind bei manchen Aufgaben weiterhin stärker. Deshalb nutzen wir beide Wege, je nach Aufgabe und Daten.

Was Sie prüfen sollten

  • Welche Daten würde die KI sehen, und dürfen sie zu einem Cloud-Anbieter?
  • Wie viele Anfragen fallen am Tag an, und wie viele gleichzeitig?
  • Wer spielt Updates ein, und woran misst er, ob eine neue Version oder ein neues Modell besser ist?
  • Ist der Server nur intern erreichbar?
  • Läuft Ihr Ablauf weiter, wenn die KI einmal ausfällt?

Wenn Sie lokale KI für eine konkrete Aufgabe prüfen möchten, rechnen wir es mit Ihnen durch. KI in der Praxis ›