Llama läuft im eigenen Rack — die Nacht-Bereitschaft schläft wieder.
Ein bayerisches Mittelstands-Industrieunternehmen mit drei Standorten und sensiblen Konstruktionsdaten betreibt seine gesamte IT on-premise. Logs in die Cloud zu schicken war keine Option. Wir haben einen lokalen Llama-3.1-Agenten gebaut, der Logs in Echtzeit analysiert, Incidents triagiert und Auto-Tickets in Zammad schreibt — ohne dass ein einziges Byte das Firmennetz verlässt.
Messmethode: Baseline aus dem 30-Tage-Zeitraum vor Go-Live gegen 30 Tage nach Produktivsetzung; MTTD aus den Monitoring-Logs des Kunden. Auf Kundenwunsch anonymisiert — Referenz und Details auf Anfrage unter NDA.
Die Ausgangslage: 1,2 Millionen Log-Zeilen, niemand liest sie.
Ein industrieller Mittelständler in Niederbayern, ca. 240 Mitarbeitende, betreibt selbst alles: zwei Produktionsstandorte mit SPS-Steuerungen, ein zentrales ERP (SAP B1), Office-Infrastruktur (M365 Hybrid mit Exchange on-prem), ein CAD-NAS mit etwa 6 TB Konstruktionsdaten, MES-System, BI-Stack.
Die IT-Abteilung: drei Personen. Davon ein Senior, der parallel auch ERP-Customizing und Wartung der Produktionsanlagen macht. Logs aus 14 verschiedenen Systemen liefen historisch in einen Graylog-Cluster — aber niemand hatte die Zeit, da regelmäßig draufzuschauen. Incidents wurden meist erst bemerkt, wenn ein Anwender anrief.
Cloud-Monitoring war keine Option. Datadog, New Relic, Splunk Cloud — alle hätten bedeutet, dass Logs mit Maschinendaten, Anwendernamen und teils auch CAD-Datei-Pfaden in US-Cloud-Infrastruktur landen. Das ging weder mit der internen Compliance noch mit den Kundenverträgen (Automotive-Zulieferer mit strenger Datenklassifizierung).
Vorher: Log-Volumen
# Vorhandene Quellen (14 Systeme) graylog/inputs: - syslog # 18 Linux-VMs - winlog # 22 Win-Server - SAP-BO # ERP B1 - MES # Produktion - SPS-OPC-UA # Maschinen - CAD-NAS # 6 TB Daten - Firewall # Sophos XG - Switch-Stack - VPN-Gateway - Backup-Stack # Volumen: ~ 1.2 Mio Log-Zeilen / Tag ~ 850 MB komprimiert ~ 2 Personen die hinschauen sollten ~ 0 Stunden die sie wirklich haben
Stack · Hardware + Software
# Hardware (Einmal-Investition) Server: Supermicro 2U GPU: 2× NVIDIA L40S (48 GB) CPU: AMD EPYC 7543 RAM: 256 GB ECC Storage: 2× 3.84 TB NVMe Netzwerk: 2× 10 GbE # Software-Stack (Container) vllm: llama-3.1-70b-Q4 ollama: embed + fallback postgres+pgvec: log-history django: agent + REST redis: queue + cache grafana: live-dashboard # Alles in einem Rack-U. # Im Server-Raum des Kunden.
Was wir gebaut haben: ein Junior-SRE, der nie schläft.
Der Agent ist eine Django-App auf einem dedizierten Server im Server-Raum des Kunden. Er konsumiert Logs aus dem bestehenden Graylog-Cluster über die Output-API in Echtzeit, klassifiziert sie und reagiert in vier Stufen:
- Stufe 1 — Noise-Filter: etwa 85% aller Logs sind Routine (Heartbeats, OK-Responses). Werden direkt verworfen, nur Aggregat-Metrics gespeichert.
- Stufe 2 — Klassifizierung: Llama 3.1 70B kategorisiert die verbleibenden 15% in „info / warn / critical / unknown“ mit Begründung und Konfidenz-Score. Latenz: ~280ms pro Zeile auf L40S.
- Stufe 3 — Korrelation: Über pgvector findet der Agent ähnliche historische Incidents. Wenn ein Pattern in den letzten 90 Tagen schon mal aufgetreten ist, wird der damalige Lösungsweg referenziert.
- Stufe 4 — Aktion: Bei „critical“ → Auto-Ticket in Zammad mit Kontext, Korrelation, Reproduktionsschritten + SMS-Push an Bereitschaft. Bei „warn“ → Eintrag in Grafana-Dashboard. Bei „unknown“ → Anhalten und nach Erklärung fragen, statt zu raten.
Drei Lektionen, die uns Iterationen gekostet haben.
1. Llama 3.1 70B halluziniert Maschinen-Codes. Bei SPS-Fehler-Codes (z.B. „F2871-A“ auf einer Siemens S7-1500) hat das Modell anfangs frei interpretiert und Bedeutungen erfunden, die nicht existierten. Lösung: ein eigenes Vokabular aus 2.400 dokumentierten Codes des Maschinenparks plus strikter Tool-Constraint: „wenn der Code nicht im Vokabular ist, sage es ehrlich, rate nicht“. Halluzinationsrate von 14% auf <1%.
2. Quantisierung kostet bei seltenen Pattern Genauigkeit. Wir haben mit Llama 3.1 70B in Q4 angefangen (~40 GB VRAM). Performance war gut für 90% der Fälle, aber bei seltenen, mehrzeiligen Stack-Traces hat die Q4-Quantisierung Details unterschlagen. Lösung: hybride Pipeline — Q4 für Klassifizierung, Q8 (auf 2. GPU) für die 5% komplexen Fälle, die ein detailliertes Reasoning brauchen.
3. Auto-Ticketing braucht Mensch-im-Loop bei kritischen Aktionen. Erste Version schickte SMS an die Bereitschaft, sobald „critical“ erkannt wurde. Nach zwei Fehl-Alarmen in der ersten Woche (legitime Wartungsaktion → SMS um 02:43) haben wir eine „cooldown“-Phase eingebaut: der Agent wartet 90 Sekunden und prüft Korrelation mit bekannten Wartungs-Fenstern. False-Positive-Rate von 9% auf 1,2%.
Ergebnisse nach 5 Monaten Produktivbetrieb
Was wir bei diesem Projekt gelernt haben
- On-Premise-LLM ist KEINE Cloud-LLM mit anderem Hostnamen. Die Wartungs-Verantwortung wandert komplett zu Ihnen: Treiber-Updates, Modell-Updates, Tokenizer-Migrationen, GPU-Drift. Wir bieten dafür einen pauschalen Wartungsvertrag — sonst ist die schöne Hardware nach 18 Monaten ungewartet.
- Quantisierung ist keine Schwäche, sondern ein Werkzeug. Llama 70B in Q4 ist auf einer einzelnen L40S brauchbar. Noch besser ist ein zweistufiger Ansatz: schnelle Vor-Klassifizierung mit dem Q4-Modell, präzise Detail-Analyse in Q8 nur bei Bedarf. Das ist die beste Performance pro Euro.
- Domain-Vokabular schlägt Modell-Größe. 2.400 dokumentierte SPS-Codes des Kundenparks waren wertvoller als ein größeres Modell. Lokales Domain-Wissen + mittleres Modell > generisches Wissen + großes Modell.
- „Critical“-Aktionen brauchen menschliche Latenz-Toleranz. 90 Sekunden Wartezeit vor SMS-Trigger fühlten sich anfangs falsch an („wir verlieren wertvolle Zeit“). Tatsächlich haben wir gemerkt: 90 Sekunden retten Bereitschaft-Schlaf, weil 80% der False-Positives sich in dieser Zeit selbst erklären (Wartungs-Window, geplanter Reboot).
Sie haben Logs, aber niemand schaut sie an?
30 Minuten kostenloses Erstgespräch. Wir analysieren Ihren konkreten Log-Stack, Ihre Compliance-Anforderungen und sagen ehrlich, ob ein on-premise KI-Agent für Sie ROI bringt — oder ob ein gut gepflegter Grafana-Stack reicht.