KI-Server für das Security Operations Center: Alarm-Triage und Loganalyse auf eigenen GPUs

Was ein KI-Server im SOC leistet

Ein KI-Server für ein Security Operations Center betreibt ein lokales Sprachmodell (LLM) neben dem SIEM; Alarme, Logs und Notizen zu Vorfällen werden so auf Hardware eingeordnet und zusammengefasst, die das SOC kontrolliert, statt an ein Cloud-Modell zu gehen. Für das SOC eines Unternehmens trägt ein Server mit zwei Karten der NVIDIA RTX PRO 6000 Blackwell Server Edition die Triage-Warteschlange und die Fragen der Analysten; ein Managed Security Service Provider (MSSP) mit vielen Mandanten beginnt bei vier Karten.

Das Modell liest einen Alarm zusammen mit den Ereignissen um ihn herum, schreibt für einen Analysten ein Urteil mit Begründung, beantwortet Fragen zu einem Host oder Benutzer anhand der Logs, die das SIEM liefert, entwirft Erkennungsregeln und macht aus einer Untersuchung einen Vorfallsbericht. Die Werte unten sind veröffentlichte Bewertungen und Spezifikationen mit Quelle oder unsere Schätzungen und als solche gekennzeichnet. Wir schreiben für die SOC-Leitung oder die Geschäftsführung eines MSSP, die entscheidet, ob sich ein lokales Modell lohnt, und für das Plattformteam, das es an das SIEM anbindet. Unser Vergleich von EDR, XDR, SIEM und MDR erklärt die Werkzeugarten; diese Seite behandelt die GPUs hinter dem Sprachmodell.

Woher die Token kommen

Ein Modell im SOC liest weit mehr, als es schreibt. Das SIEM korreliert die Rohereignisse und löst einen Alarm aus; ein Anreicherungsschritt holt die zugehörigen Ereignisse, die Daten zu Asset und Benutzer und Threat Intelligence; das Modell erhält alles zusammen und liefert ein strukturiertes Urteil. Niemand schickt die Rohlogs eines Tages an ein Sprachmodell: Die Abfragen des SIEM bestimmen, was das Modell sieht.

Unsere Zusammenfassung; Tokenzahlen sind Beispielwerte, die durch die Durchschnitte Ihrer eigenen Alarme ersetzt werden.

Das Verhältnis setzt zwei Grenzen. Der Cache je Anfrage wird für den langen Prompt bemessen; ein Kontext von 32K ist für die Triage eine sinnvolle Obergrenze mit Platz für die Antwort. Und die Zeit je Alarm hängt ebenso vom Einlesen des Prompts (Prefill) ab wie vom Schreiben des Urteils; Prefill ist rechengebunden, und für dieses Modell auf diesen Karten gibt es keinen veröffentlichten Wert. Er wird in einem Pilotprojekt mit vllm bench throughput bei Ihren Ein- und Ausgabelängen gemessen, nach der Methode unseres Leitfadens zur LLM-Batch-Inferenz on-premise.

Ein Modell für Sicherheitsarbeit wählen

Sicherheitsanalyse ist eine enge Aufgabe, und allgemeine Ranglisten sagen wenig darüber. Elastic veröffentlicht eine LLM-Leistungsmatrix für die KI-Funktionen von Elastic Security ab 9.0; wir haben sie am 24. Oktober 2026 gelesen, und ihr Abschnitt zu Open-Source-Modellen ist als zuletzt im September 2026 gemessen gekennzeichnet. Sie bewertet jedes Modell je Aufgabe von 1 bis 10 und sieht Werte von 5 oder darunter als nicht empfohlen an.

Elastic, Large language model performance matrix, Elastic Security 9.0+, Open-Source-Modelle, zuletzt im September 2026 gemessen, gelesen am 24. Oktober 2026; Auszug aus vier Zeilen und drei der Aufgabenspalten des Agent Builder. Die Bewertungen stammen von Elastic, für dessen eigene Funktionen und Prompts.

Die Matrix bewertet Modelle innerhalb der Funktionen eines Herstellers; sie ist ein Ausgangspunkt, kein Urteil für Ihr SIEM. Sie zeigt, dass ein Modell, das als allgemeiner Assistent gut dient, wie gpt-oss-120b, bei der Alarmanalyse in einem Sicherheitswerkzeug scheitern kann und dass mittelgroße dichte Modelle besser abschneiden können. Dieselbe Matrix gibt Gemma 4 31B IT für Elastics Attack Discovery 4,3, unter der eigenen Schwelle. Bauen Sie aus einigen Hundert eigener abgeschlossener Alarme mit den Urteilen der Analysten einen Testdatensatz und bewerten Sie jeden Kandidaten daran, bevor Sie den Server dimensionieren.

Unser Private-AI/ML-Service richtet Kandidatenmodelle auf einem Pilotserver ein und bewertet sie an Ihren abgeschlossenen Alarmen; beschreiben Sie Ihr SIEM und den Weg der Alarme zu Ihren Analysten, und wir schlagen das Pilotprojekt und die Hardware dafür vor.

Googles Modellkarte zu gemma-4-31B-it, gelesen am 24. Oktober 2026, nennt 30,7B Parameter, einen Kontext von 256K Token, native Unterstützung für strukturierte Tool-Nutzung und die Lizenz Apache 2.0. Die Dateiseite listet zwei Safetensors-Dateien mit 49,8 GB und 12,8 GB, zusammen 62,6 GB in BF16. Unser Leitfaden zu den Hardware-Anforderungen von Gemma behandelt die anderen Größen.

Elastic dokumentiert zwei Wege, seinen AI Assistant über den OpenAI-Connector mit der Einstellung „Other (OpenAI Compatible Service)“ an ein selbst betriebenes Modell anzubinden: einen mit LM Studio und einen mit vLLM für Umgebungen ohne Internetverbindung, der laut Elastic keinen ausgehenden Netzwerkzugriff braucht. Dieselben Seiten weisen darauf hin, dass dieser Connector veraltet ist und schrittweise aus der Oberfläche zum Anlegen von Connectors entfernt wird, zugunsten von Inference-Endpunkten in Elasticsearch; prüfen Sie daher den Integrationsweg für Ihre Version. Elastics vLLM-Leitfaden lief auf einem Cloud-Server mit zwei A100 80GB und dem Image von vLLM 0.9.1; auf Karten der RTX PRO Blackwell setzen Sie eine aktuelle vLLM-Version ein.

Dimensionierung nach Alarmen pro Tag

Nach unserer Regel für Nutzer je Karte, die 90 Prozent der 95,6 GiB nimmt, die der Treiber meldet, abzüglich 3 GiB je Karte und der Gewichte, lässt Gemma 4 31B in BF16 (58,3 GiB) auf einer Karte 24,7 GiB für den Cache. Seine zehn Schichten mit voller Attention haben vier KV-Köpfe der Dimension 512, und seine fünfzig Schichten mit Sliding Window betrachten 1.024 Token; eine Anfrage mit 32K belegt damit bis zu etwa 3,3 GiB 16-Bit-Cache, wie unser Gemma-Leitfaden rechnet. Eine Karte hält 7 Anfragen mit 32K, ein Tensor-Parallel-Paar mit 107,8 GiB Cache 32. Das vLLM-Rezept für das 31B nennt für einen FP8-Cache etwa 50 Prozent weniger KV-Speicher, was diese Zahlen ungefähr verdoppelt.

Die Schreibgeschwindigkeit hat eine Obergrenze, die die Speicherbandbreite setzt: Jeder Schritt liest die Gewichte und den Cache jeder laufenden Anfrage. Mit 1.597 GB/s je Karte und sieben vollen 32K-Anfragen liest eine Karte je Schritt etwa 81 GiB, schafft also etwa 18 Schritte pro Sekunde und damit für die sieben zusammen höchstens etwa 128 Ausgabe-Token pro Sekunde. Ein Paar teilt die Gewichte und hält 32 Anfragen, für höchstens etwa 580 pro Sekunde. Das sind nach unserer Schätzung Obergrenzen: Prefill und der Austausch zwischen zwei Karten über PCIe fehlen darin. Wir planen mit der Hälfte, etwa 64 und etwa 290 Token pro Sekunde.

Unsere Schätzungen für Gemma 4 31B in BF16 mit 16-Bit-Cache bei 32K und 500 Ausgabe-Token je Alarm; Obergrenzen aus 1.597 GB/s je RTX PRO 6000 Server Edition (NVIDIA), Gewichte aus der Dateiseite auf Hugging Face und Cache aus config.json wie in unserem Gemma-Leitfaden gezählt; Alarmmengen sind Beispielwerte. Das Prefill der Prompts mit 12.000 Token ist nicht enthalten und wird in einem Pilotprojekt gemessen.

Ein einzelnes SOC mit 2.000 Alarmen am Tag, die das Modell erreichen, passt auf eine Karte mit Reserve für die Fragen der Analysten; ein Alarmsturm staut sich auf einer Karte aber etwa eine Stunde lang und ist auf einem Paar in etwa einer Viertelstunde abgearbeitet. Planen Sie für den Sturm: Er entscheidet, ob das Modell eine Karte oder ein Paar erhält. Das MSSP-Beispiel braucht vor dem Prefill etwa 14 Stunden auf einem Paar, 7 Stunden auf zwei Paaren und 3,6 auf vier; ein MSSP plant seine Karten deshalb als Tensor-Parallel-Paare.

Konfigurationen nach Kartenzahl

Die Optionen folgen den Referenz­konfigurationen auf unserer Seite zu KI-Servern und NVIDIAs Leitfaden für zertifizierte Systeme: zwei Prozessoren, mindestens sechs Kerne je GPU und Arbeitsspeicher in doppelter Größe des GPU-Speichers.

Referenz­konfigurationen auf unserer Seite zu KI-Servern; Anfragen und Token pro Sekunde nach unserer Schätzung für Gemma 4 31B in BF16, 32K, halbe Bandbreitengrenze; Strom nach unserer Schätzung mit Karten bei 600 W, Prozessoren und 15 Prozent für den Rest des Servers.

Zwei Karten. Der Einstiegsserver hat zwei RTX PRO 6000 Server Edition, zwei AMD-EPYC-Prozessoren, 384 GB DDR5-ECC und zwei NVMe-Laufwerke. Betreiben Sie das Modell als eine Kopie über beide Karten: Das Paar hält nach unserer Schätzung mehr als viermal so viele Anfragen wie eine Karte und arbeitet einen Alarmsturm mehr als viermal so schnell ab. Alternativ betreibt Karte 1 das Modell für die Triage, und Karte 2 wird per MIG in vier Instanzen mit 24 GB geteilt, für ein Embedding-Modell über frühere Vorfälle und Playbooks, einen Reranker und eine Testinstanz; das passt zu einem SOC mit gleichmäßig niedriger Alarmmenge.

Vier Karten. Der Inferenzknoten mit 768 GB und vier NVMe-Laufwerken betreibt zwei Paare. Ein SOC gibt ein Paar der Triage-Warteschlange und eines den Analysten, sodass ein Sturm während eines Vorfalls nie eine Frage blockiert. Ein MSSP gibt die Paare verschiedenen Mandantenpools oder stellt beide hinter eine Warteschlange. Diese Konfiguration würden wir für einen MSSP zuerst dimensionieren.

Zwei Server mit je vier Karten oder acht Karten. Eine Triage im Dauerbetrieb braucht einen zweiten Server, damit einer ausfallen oder gepatcht werden kann, während der andere die Warteschlange abarbeitet, wie unser Leitfaden zur Hochverfügbarkeit mit zwei GPU-Knoten beschreibt. Acht Karten in einem Server bringen vier Paare, nach unserer Schätzung mit etwa 6,3 kW und ohne Ausfallsicherheit.

Die RTX PRO 6000 Max-Q ist die Workstation-Karte, eine Radiallüfter-Karte mit 300 W; ins Rack gehört sie nur in ein Gehäuse, für das der Hersteller sie listet, und für den Dauerbetrieb empfehlen wir die Server Edition. Wir bauen diese Server und richten über unseren Private-AI/ML-Service das Modell und die Anbindung an Ihr SIEM ein; schicken Sie uns Ihre Alarme pro Tag, Ihre Spitzenstunde und das SIEM, das Sie betreiben, und unser Team antwortet mit einer Konfiguration.

Logs sind nicht vertrauenswürdige Eingabe

Vieles von dem, was ein Modell im SOC liest, hat der Angreifer geschrieben: einen User-Agent-String, einen URL-Pfad, einen Dateinamen, einen E-Mail-Betreff, eine Kommandozeile. Jedes dieser Felder kann Text enthalten, der sich an das Modell richtet, etwa die Anweisung, den Alarm als harmlos einzustufen. OWASP führt Prompt Injection als LLM01 an erster Stelle seiner Top 10 for LLM Applications 2026, und unser Leitfaden zu Prompt Injection und LLM-Sicherheit erklärt, warum kein Filter sie zuverlässig entfernt. Das Design begrenzt deshalb, was eine eingeschleuste Anweisung bewirken kann.

1. Das Modell berät, Menschen handeln. Es schreibt Urteile und Entwürfe; einen Alarm schließen, einen Host isolieren oder ein Konto sperren bleibt bei einem Analysten oder bei einem Playbook, dessen Regeln außerhalb des Modells liegen.
2. Nur lesende Tools. Darf das Modell das SIEM abfragen, geben Sie ihm ein Konto mit reinen Leserechten, begrenzt auf den Mandanten und das Zeitfenster des Alarms.
3. Beweismaterial kennzeichnen. Legen Sie Loginhalte in einen abgegrenzten Block des Prompts, kürzen Sie überlange Felder und zeigen Sie dem Analysten in der Ausgabe, welche Felder aus dem Ereignis stammen.
4. Fehlurteile messen. Nehmen Sie Alarme mit eingeschleustem Text in den Testdatensatz auf und prüfen Sie, dass das Urteil ihnen nicht folgt.

Mandantentrennung beim MSSP

Ein MSSP verarbeitet die Logs jedes Kunden in dessen Auftrag; Artikel 28 DSGVO verlangt daher einen Vertrag mit jedem Kunden, und Kunden fragen oft, wohin ihre Logs gehen und wer die Hardware noch nutzt. Es gibt drei Stufen der Trennung.

• Eine Karte oder ein Paar je Mandant. Physische Trennung für die größten Kunden oder die strengsten Verträge. Gemma 4 31B braucht eine ganze Karte.
• Eine MIG-Instanz je Mandant. MIG teilt eine RTX PRO 6000 in bis zu vier Instanzen mit 24 GB, jede mit eigenem Speicher und eigener Fehlerisolation. Eine Instanz hält ein Embedding-Modell oder ein Modell mit etwa 8B Parametern in BF16, nach unserer Rechnung etwa 16 GB Gewichte bei 2 Byte je Parameter, nicht das 31B; Elastics Matrix bewertet die kleinen Modelle, die sie listet, bei der Alarmanalyse niedrig, testen Sie also, bevor Sie es anbieten.
• Ein gemeinsames Modell mit logischer Trennung. Ein Modell bedient alle Mandanten; das Gateway gibt jedem Mandanten eigene Schlüssel, einen eigenen Index, einen eigenen Protokollstrom und eine eigene Aufbewahrung. Der Prefix-Cache von vLLM verwendet berechnete Blöcke zwischen Anfragen mit gleichem Präfix wieder, und die Design-Dokumentation zu Version 0.32.0 beschreibt ein Salting je Anfrage, das zeitbasierte Angriffe verhindert, bei denen ein Gegner aus Latenzunterschieden auf zwischengespeicherte Inhalte schließt: Mit einem cache_salt je Mandant können nur Anfragen mit demselben Salt zwischengespeicherte KV-Blöcke wiederverwenden. Setzen Sie ihn im Gateway, nicht im Client.

Unser Leitfaden zu selbst betriebenen LLMs für SaaS-Produkte behandelt mandantenfähiges Serving ausführlicher.

Hinweise für das IT-Team

1. Anbindung. vLLM stellt eine OpenAI-kompatible API bereit, die der Connector des SIEM oder das SOAR-Playbook aufruft. Setzen Sie ein LLM-Gateway mit Schlüsseln und Abfrage-Log davor und protokollieren Sie Mandant, Alarm-ID, Modellversion und Ausgabe.
2. Strukturierte Urteile. Mit den Structured Outputs von vLLM folgt die Antwort einem JSON-Schema mit Feldern wie Urteil, Konfidenz und zitierten Ereignis-IDs, sodass die SOAR-Plattform sie weiterleiten kann.
3. Netzwerk. --api-key schützt in vLLM nur Pfade unter /v1, /v2, /inference und /cohere; Routen wie /invocations und /metrics antworten auch ohne Schlüssel (Sicherheitsleitfaden von vLLM 0.32.0). Halten Sie die Engines deshalb in einem internen Verwaltungsnetz hinter dem Gateway. Betreiben Sie vLLM 0.31.0 oder neuer, das NVIDIA Container Toolkit ab 1.17.8 und einen Treiber, den NVIDIA in seinem Bulletin vom 30. September 2026 als behoben nennt. Unser Leitfaden zur Absicherung eines GPU-Servers behandelt den Host.
4. Daten. Logs enthalten Benutzernamen, IP-Adressen und E-Mail-Adressen, also personenbezogene Daten; legen Sie die Aufbewahrung von Prompts und Ausgaben passend zu der des SIEM fest. Für Einrichtungen unter NIS2 behandelt unser Artikel zu den Anforderungen an Protokollierung und Überwachung nach NIS2, was die Regeln von Logs verlangen.
5. Modell-Updates. Legen Sie das Modell fest und lassen Sie jede neue Version über Ihren Alarm-Testdatensatz laufen, bevor sie die alte ersetzt, wie unser Leitfaden zur LLM-Evaluierung vor Modell-Upgrades beschreibt.

Stromversorgung und Aufstellung

Nach unserer Schätzung nimmt der Server mit zwei Karten und zwei EPYC 9135 etwa 1,8 kW am Netz auf und passt an einen 16-A-Anschluss mit 230 V, der bei 80 Prozent Auslastung 2,94 kW trägt. Der Server mit vier Karten zieht mit Karten bei 600 W etwa 3,4 kW und braucht 32 A oder Drehstrom, mit auf 450 W begrenzten Karten etwa 2,7 kW. Acht Karten ziehen nach unserer Schätzung etwa 6,3 kW; Dells Datenblatt nennt etwa 8 kW je Knoten mit acht Karten als Richtwert, und die Zuleitungen sollten nach dem Wert des Herstellers geplant werden. Eine Messung am gelieferten System bestätigt die Leistungsaufnahme. Unser Leitfaden zum Stromanschluss von GPU-Servern mit 16 A, 32 A und Drehstrom rechnet die Anschlüsse durch. Ohne eigenen Serverraum betreibt unser Private-AI/ML-Service die Plattform auf dedizierter Hardware in einem Tier-3-Rechenzentrum in Litauen, innerhalb der EU.

Was wir liefern

Sie können dieses System bei uns kaufen: Unser Team dimensioniert die Konfiguration nach Ihrer Last und Ihrem Budget und antwortet innerhalb eines Werktages. Wir bauen die Server auf Bestellung mit zwei, vier oder acht Karten der RTX PRO 6000 Server Edition, vor der Lieferung montiert und getestet, geliefert in die gesamte EU mit einem EU-Vertrag und einer Rechnung, mit Herstellergarantie auf jede Komponente, abgewickelt über uns; Stückzahlen und Lieferzeit werden mit dem Angebot schriftlich bestätigt. Unser Service Private AI/ML mit Engineering durch unseren Partner Vixen.UNO richtet das Modell, das Gateway mit Schlüsseln und Protokollen je Mandant und die Anbindung an Ihr SIEM ein. Unsere Seite zum Kauf eines GPU-Servers für LLMs listet alle Konfigurationen.

FAQ