Logs im eigenen Haus auswerten. Mit einem Modell, das dorthin passt.

/01On-Premise-KI für Logauswertung und Support: Begriff und Abgrenzung

Gemeint ist ein Sprachmodell — offen verfügbar, nicht hinter einer API eines Anbieters —, das auf eigener Hardware im Haus oder in einem deutschen Rechenzentrum läuft und zwei Aufgaben übernimmt: Logausschnitte zusammenfassen und wiederkehrende Support-Anfragen anhand einer internen Wissensbasis beantworten. Kein Agent, der selbst handelt, kein Modell, das neue Fakten „weiß" — ein Werkzeug, das Text liest und Text verdichtet, lokal genug betrieben, dass die Eingabedaten das Gebäude nicht verlassen.

Die Abgrenzung zur Cloud-API ist keine Glaubensfrage, sondern eine Rechnung aus Datenklasse und Nutzungsmenge: Enthalten Logs oder Ticketinhalte Kundendaten, interne Hostnamen oder Zugangsreste, ist ein lokal betriebenes Modell oft der kürzere Weg zur Freigabe als ein Auftragsverarbeitungsvertrag mit einem externen Anbieter. Was lokal nicht automatisch mitkommt: das größte verfügbare Modell. Dieser Artikel zeigt, mit welcher — kleineren — Größe sich die beiden genannten Aufgaben trotzdem zuverlässig lösen lassen, mit welcher Hardware das in der Praxis läuft und wo diese kleinere Größe tatsächlich an ihre Grenze stößt.

/02Welche Modellgröße für diese Aufgabe realistisch ist

Logzusammenfassung und Support-Antworten aus einer festen Wissensbasis sind Aufgaben mit geringer Kreativitätsanforderung und hohem Textvolumen — genau das Profil, für das kleine, offene Modelle gebaut werden. Drei Modellkarten geben dafür belastbare Anker:

Für die reine Logzusammenfassung — Häufung erkennen, Hosts benennen, Zeitfenster eingrenzen — reicht in unseren Tests die kleinste sinnvolle Stufe, Qwen3-8B oder gpt-oss-20b. Für Support-Antworten aus einer größeren Wissensbasis, bei der mehr Kontext gleichzeitig im Modell stehen muss, zahlt sich das größere Kontextfenster von Qwen3-8B aus: 32.768 Token fassen schon ein mehrstündiges Logfenster oder mehrere Wissensartikel gleichzeitig, 131.072 Token mit YaRN-Erweiterung reichen für die meisten Supportfälle eines Mittelständlers aus. gpt-oss-120b ist für diese beiden Aufgaben in der Regel überdimensioniert — es lohnt sich erst, wenn zusätzlich komplexere Schlussfolgerungen gefragt sind, etwa bei mehrstufiger Fehlerdiagnose.

Die Ollama-Modellbibliothek macht die Größenstufen innerhalb einer Familie greifbar, weil sie jede Quantisierungsstufe mit ihrer Dateigröße ausweist — ein brauchbarer erster Anker für den Speicherbedarf, auch wenn der tatsächliche Arbeitsspeicherbedarf zur Laufzeit etwas über der Dateigröße liegt:

Auffällig ist die 4b-Variante: Trotz kleinerer Parameterzahl als die 8b-Stufe trägt sie laut Bibliothek dasselbe große Kontextfenster von 256.000 Token wie die deutlich größere 30b-Variante. Für reine Logzusammenfassung, bei der ein langes Zeitfenster wichtiger ist als sprachliche Finesse, kann das die günstigere Wahl sein — ein Fall, in dem „kleiner, aber mit mehr Kontext" der größeren, aber kontextärmeren Variante vorzuziehen ist.

/03Hardware-Anker: CPU, GPU, RAM und Quantisierung

Drei Konfigurationen decken die meisten Mittelständler ab, von der kleinsten bis zur komfortabelsten:

• Reiner CPU-Betrieb. Ein llama.cpp-Server auf einem gewöhnlichen Zweisockel-Server mit AVX2- oder AVX512-fähigen Prozessoren verarbeitet ein quantisiertes 8B-Modell im GGUF-Format mit brauchbarer Geschwindigkeit für Stapelverarbeitung — also für Logauswertung, die nicht in Echtzeit beantwortet werden muss. Keine Grafikkarte nötig, dafür längere Wartezeit je Anfrage.
• Eine Konsumer- oder Workstation-GPU. Eine Karte mit 16 bis 24 GB Grafikspeicher — wie sie gpt-oss-20b laut Modellkarte braucht — bedient mehrere gleichzeitige Support-Anfragen in Sekunden statt Minuten. Das ist die Konfiguration, die sich für den laufenden Support-Chat lohnt, nicht nur für nächtliche Logauswertung. Ein zweiter Server oder eine zweite Karte als Rückfall kostet zusätzlich, lohnt sich aber, sobald der Support-Chat während der Geschäftszeiten zur Pflicht wird und nicht mehr ausfallen darf, ohne dass ein Techniker es sofort bemerkt.
• Eine Enterprise-Karte mit 80 GB. Für gpt-oss-120b oder mehrere gleichzeitig geladene kleinere Modelle. In den meisten Mittelstandsprojekten, die wir begleiten, ist das für Logauswertung und Support überdimensioniert — die Stufe lohnt sich erst, wenn dieselbe Hardware weitere KI-Arbeitslasten übernimmt.

Die Quantisierung ist der Hebel, der zwischen diesen Stufen vermittelt: llama.cpp reduziert ein Modell im GGUF-Format auf 1,5 bis 8 Bit je Parameter, je nach gewünschtem Verhältnis aus Geschwindigkeit und Qualität. Die Ollama-Bibliothek liefert dafür vorquantisierte Varianten: Die 8B-Version von Qwen3 wiegt in einer gängigen Quantisierung rund 5,2 GB auf der Festplatte, die 14B-Version 9,3 GB, eine 30B-MoE-Variante mit 256.000 Token Kontext rund 19 GB. Wer unsicher ist, ob die eigene Hardware reicht, beginnt mit der kleinsten Stufe und testet nach oben — nicht umgekehrt.

# Quantisierte Varianten vergleichen und lokal starten
ollama pull qwen3:8b
ollama run qwen3:8b "Fasse die Fehlermuster der letzten Stunde zusammen, \
  nenne betroffene Hosts und Haeufigkeit, keine Ursachendiagnose."

# Reiner CPU-Betrieb mit llama.cpp und GGUF-Quantisierung
./llama-server -m qwen3-8b-q4_k_m.gguf --ctx-size 32768 --threads 16

Die Thread-Zahl im letzten Befehl ist kein Zufallswert: llama.cpp nutzt laut Projektdokumentation AVX-, AVX2- oder AVX512-Erweiterungen je nach Prozessor und skaliert mit der Zahl der physischen Kerne — bei einem Server mit sechzehn Kernen ist --threads 16 der naheliegende Startwert, nicht zwangsläufig der schnellste; in der Praxis lohnt sich ein kurzer Test mit acht, sechzehn und der vollen Kernzahl, weil Speicherbandbreite häufiger der Engpass ist als Rechenleistung. Auf Apple- Silicon-Hardware entfällt diese Abwägung weitgehend, weil llama.cpp dort laut Projektdokumentation ARM NEON, Accelerate und Metal als bevorzugte Backends nutzt.

Welche Kombination aus Modellgröße und Hardware zu welcher Aufgabe passt, lässt sich als Faustregel zusammenfassen — eine Einordnung aus eigenen Projekten, kein Benchmarkergebnis:

/04Einbindung: vom Logstream zum Assistenten

Die Mechanik ist in den meisten Umgebungen gleich: Ein Sammeldienst — etwa Loki oder ein klassisches Syslog-Ziel — hält die Logs vor, ein einfacher Dienst zieht in festen Abständen einen Ausschnitt, reicht ihn an das lokal laufende Modell über vLLM oder llama.cpp weiter und schreibt die Zusammenfassung in ein Dashboard oder ein Ticket. Für Support-Antworten kommt eine Wissensbasis dazu: Eine Vektordatenbank hält Auszüge aus Dokumentation und früheren Tickets vor, das Modell bekommt bei jeder Anfrage die passenden Ausschnitte mitgeliefert, statt sich auf sein eigenes, begrenztes Wissen zu verlassen.

Diese Architektur hat einen Vorteil, den Cloud-Lösungen so nicht bieten: Jeder Schritt — welche Logzeilen gelesen wurden, welche Wissensartikel ins Modell geflossen sind, was es geantwortet hat — bleibt im eigenen Netz protokollierbar. Für ein Haus mit ISMS ist das die Grundlage für den Nachweis, dass der Assistent nur mit den Datenklassen arbeitet, die freigegeben sind.

Als wiederkehrender Dienst läuft das Modell am robustesten unter einer eigenen Prozessverwaltung statt in einem manuell gestarteten Terminalfenster:

# /etc/systemd/system/ki-logauswertung.service
[Unit]
Description=Lokaler Qwen3-8B-Dienst fuer Logauswertung
After=network.target

[Service]
ExecStart=/opt/llama.cpp/llama-server -m /opt/modelle/qwen3-8b-q4_k_m.gguf \
  --ctx-size 32768 --threads 16 --host 127.0.0.1 --port 8081
Restart=on-failure
RestartSec=10
User=ki-dienst

[Install]
WantedBy=multi-user.target

So sieht ein Tag mit diesem Aufbau aus: Um 6 Uhr zieht ein Cron-Job die Logs der Nacht, der Dienst fasst sie zusammen, ein Techniker findet beim Einloggen eine Zusammenfassung statt eines ungefilterten Logbergs vor — „vierzehn Zeitüberschreitungen auf host-db02 zwischen 2 und 4 Uhr, keine Fehler auf den übrigen Hosts" statt tausender Einzelzeilen. Tagsüber bedient derselbe Dienst über Port 8081 die Support-Oberfläche: Eine Anfrage kommt herein, die Wissensbasis liefert die passenden Ausschnitte, das Modell formuliert den Entwurf, ein Mitarbeiter liest und verschickt. Abends prüft der in Abschnitt 6 beschriebene Alarm, ob der Dienst den Tag über durchgehend geantwortet hat — bleibt diese Meldung aus, hat niemand etwas zu tun; genau das ist der Zweck der Automatisierung.

/05Qualität kleiner Modelle: was sie leisten, was nicht

Ein 8-Milliarden-Parameter-Modell ist kein Ersatz für ein Frontier-Modell mit hundertfacher Größe — das sollte niemand erwarten, der diesen Artikel liest. Was es gut kann: Text zusammenfassen, Muster in wiederkehrenden Formulierungen erkennen, aus vorgegebenem Kontext eine Antwort formulieren. Was es schlechter kann als ein großes Modell: mehrstufig schlussfolgern, seltene Fehlerbilder korrekt einordnen, ohne Kontext aus eigenem Wissen antworten — und genau beim letzten Punkt entstehen die unangenehmsten Fehler, weil ein kleines Modell dieselbe selbstsichere Sprache verwendet wie ein großes, auch wenn es daneben liegt.

Die Gegenmaßnahme ist nicht ein größeres Modell, sondern eine engere Aufgabe: Ein Assistent, der nur zusammenfasst, was im Logausschnitt steht, oder nur aus der vorgelegten Wissensbasis zitiert, hat deutlich weniger Spielraum zu erfinden als einer, der „frei" antworten darf. Diese Beschränkung gehört in den Prompt, nicht nur in die Hoffnung, dass das Modell sie von selbst einhält. Ein Satz wie „Wenn die Information nicht im mitgelieferten Text steht, antworte mit 'nicht im Logausschnitt enthalten'" kostet im Prompt zwei Zeilen und verhindert einen erheblichen Teil der Fälle, in denen ein kleines Modell sonst eine plausible, aber erfundene Lücke füllt.

/06Pflegeaufwand: Updates, Modellwechsel, Betrieb

Ein lokal betriebenes Modell entfällt nicht der Pflege, es verschiebt sie nur ins eigene Haus. Drei wiederkehrende Aufgaben: Erstens, Modellversionen aktualisieren — Hersteller wie OpenAI oder Alibaba veröffentlichen neue Varianten in unregelmäßigen Abständen, und wer eine veraltete Version dauerhaft betreibt, verzichtet auf Qualitätsverbesserungen, die ein Cloud-Anbieter automatisch mitliefert. Zweitens, die Anbindung an Logquelle und Wissensbasis pflegen, wenn sich deren Format ändert. Drittens, den Dienst selbst überwachen: Läuft der Assistent noch, antwortet er in akzeptabler Zeit, wächst der Zwischenspeicher über die geplante Grenze hinaus?

In einer IT mit zwei bis fünf Köpfen ist das selten eine Vollzeitaufgabe, aber eine, die niemand „nebenbei" erledigt, wenn sie nicht explizit jemandem zugeordnet ist. Wer den Aufwand nicht selbst tragen will, bezieht den Betrieb als Dienstleistung — mit Monitoring, Versionspflege und Ansprechpartner.

Ein Muster, das in Projekten immer wieder auftaucht: Der Assistent läuft in den ersten Wochen hervorragend, weil jemand aus Neugier regelmäßig nachschaut. Sobald diese Person im Urlaub ist oder das Projekt wechselt, merkt oft wochenlang niemand, dass ein Logmuster längst nicht mehr erkannt wird, weil eine Formatänderung in der Logquelle den Assistenten leise ins Leere laufen lässt. Die Gegenmaßnahme ist banal, aber wirksam: ein einfacher Alarm, der meldet, wenn der Dienst seit einer bestimmten Zeit keine Zusammenfassung mehr erzeugt hat — eine Zeile Prometheus-Regel reicht dafür meist aus, keine eigene Überwachungssoftware.

/07Datenschutz: warum die Daten im Haus bleiben

Der eigentliche Grund, warum sich der Aufwand für die meisten Betriebe lohnt, ist nicht die Modellqualität, sondern die Datenlage. Logs enthalten regelmäßig interne Hostnamen, IP-Adressen, manchmal Nutzernamen oder Fragmente von Zugangsdaten; Supportanfragen enthalten Kundendaten. Läuft das Modell lokal, verlassen diese Daten das Gebäude nicht — es gibt keinen Cloud-Anbieter, mit dem ein Auftragsverarbeitungsvertrag geschlossen werden müsste, und keine Frage nach dem Drittlandbezug.

Das ersetzt nicht die DSGVO-Grundlagen: Ein Verarbeitungsverzeichnis, eine Zugriffskontrolle auf den Assistenten selbst und eine Entscheidung, wer die Protokolle einsehen darf, braucht ein lokal betriebenes System genauso wie ein Cloud-Dienst. Was On-Premise ändert, ist die Zahl der Beteiligten: ein Verantwortlicher im eigenen Haus statt einer Verarbeitungskette über mehrere Unternehmen.

/08Wo es hakt: Grenzen und Fallstricke

Die Hardware ist schneller angeschafft als betrieben. Eine GPU ist in wenigen Tagen bestellt; ein stabiler Dienst mit Monitoring, Neustart bei Absturz und Versionspflege braucht Wochen, bis er wirklich läuft, ohne dass jemand händisch eingreift.

Quantisierung kostet Qualität, nicht nur Speicher. Eine sehr aggressive Quantisierung — etwa auf 2 oder 3 Bit — spart Speicher, verschlechtert aber messbar die Antwortqualität. Für Logauswertung und Support ist eine mittlere Stufe wie 4-Bit-Quantisierung in der Praxis meist der bessere Kompromiss als die kleinstmögliche Dateigröße. Wer unsicher ist, testet beide Stufen an denselben zehn bis zwanzig echten Logfällen und vergleicht die Zusammenfassungen nebeneinander — der Unterschied ist meist deutlicher sichtbar als in einer abstrakten Benchmarkzahl.

Kontextfenster ist nicht gleich Gedächtnis. Auch 131.072 Token Kontext bei Qwen3-8B mit YaRN bedeuten nicht, dass das Modell sich an Vorgänge aus der letzten Woche „erinnert" — jede Anfrage beginnt neu, nur was explizit mitgeschickt wird, ist dem Modell bekannt. Eine Wissensbasis muss deshalb aktiv gepflegt werden, nicht nur einmal befüllt.

Ein einzelner Server ist ein Ausfallpunkt. Wer Logauswertung und Support produktiv auf eine einzelne Maschine legt, hat keinen Ausweichpfad, wenn sie ausfällt. Für eine Aufgabe, die nicht sicherheitskritisch ist, ist das oft akzeptabel — wer mehr Verlässlichkeit braucht, plant von Anfang an eine zweite, kleinere Instanz als Rückfall ein. Ein einfacher Fallback genügt dafür meist: Fällt der dedizierte Server aus, übernimmt vorübergehend eine CPU-only-Instanz mit demselben quantisierten Modell — langsamer, aber verfügbar, bis die Hauptmaschine wieder läuft.

Die Kostenrechnung hängt an der Nutzung, nicht an der Hardware allein. Eine genaue Gegenüberstellung aus eigener Karte und API-Tokens — inklusive der Frage, ab welcher Nutzungsmenge sich welche Form lohnt — haben wir in GPU-Preise 2026: Eigene KI-Hardware oder API-Tokens rechnen mit Beispielwerten durchgerechnet; belastbar wird die Zahl erst mit den eigenen Nutzungsdaten aus einem Pilotbetrieb.

Ein neues Modell ist kein Drop-in-Ersatz. Zwischen zwei Versionen derselben Modellfamilie können sich Antwortformat, Tonfall oder die Neigung zu ausführlichen Erklärungen spürbar verschieben. Ein Wechsel, der ungetestet in die Produktivumgebung geht, kann eine bisher zuverlässige Logzusammenfassung plötzlich mit unnötigen Erklärsätzen aufblähen. Der sichere Weg: neue Version parallel auf denselben Testfällen laufen lassen, erst nach einem Vergleich umschalten — der alte Dienst bleibt so lange als Fallback aktiv.

/09Die Entscheidung: wann sich eigene Hardware lohnt — und wann nicht

Eigene Hardware lohnt sich, wenn Logs oder Supportdaten vertrauliche Inhalte enthalten, die Nutzungsmenge regelmäßig genug ist, um die Anschaffung zu tragen, und jemand im Haus — oder ein Betriebspartner — die Pflege übernimmt. Ein CPU-only-Server mit einem quantisierten 8B-Modell ist dabei oft der richtige Einstieg, nicht die teuerste Karte — die Entscheidungstabelle aus Abschnitt 3 gibt für den Einstieg eine erste Orientierung, die eigene Testreihe ersetzt sie nicht.

Eine API mit Auftragsverarbeitungsvertrag ist die bessere Wahl, wenn die Datenklasse das zulässt und die Nutzungsmenge gering ist — dann rechnet sich eine eigene Karte selten. Nichts davon lohnt sich, solange niemand die Logquelle und Wissensbasis sauber anbindet: Ein starkes Modell auf unsortierten Daten liefert unsortierte Antworten, egal wie viel GPU-Speicher dahintersteht.

/10Häufige Fragen