Server und Hardware

Intric liefert die Plattform auf Kubernetes aus, über versionierte Helm-Charts. Betreibst du noch kein Kubernetes (die Charts setzen 1.29 oder neuer voraus; nimm eine Version, die das Projekt noch unterstützt), installieren wir k3s, eine schlanke Kubernetes-Distribution, auf einer Linux-VM, die du bereitstellst. Was diese VM braucht, hängt davon ab, welche Teile der Plattform du in deiner eigenen Umgebung betreibst und welche du als Dienst von Intric nutzt.

Szenario wählen

Szenario	Läuft in deiner Umgebung	Als Dienst genutzt	Hardware
1. Plattform	Web-App, API, Datenbanken, Suchindex, Objektspeicher	Verarbeitung (PDF/OCR, Dokumentaufnahme, Transkription) und alle KI-Modelle	Eine VM, 4–8 Kerne
2. Plattform + Verarbeitung	Szenario 1, dazu die Verarbeitungs-Worker für PDF/OCR, Dokumentaufnahme und Audiotranskription, die auf der CPU laufen	KI-Modelle, die eine GPU brauchen: Sprachmodelle, Embeddings, Speech-to-Text, Bildmodell	Eine VM, ~20–72 Kerne
3. Vollständig lokal	Szenario 2, dazu alle KI-Modelle auf deinen eigenen GPU-Servern: Sprachmodelle, Embeddings, Speech-to-Text und Bildmodell	Nichts	Die VM aus Szenario 2, dazu ein oder mehrere GPU-Server

Wähle das Szenario, das deine Anforderungen an die Datenverarbeitung tatsächlich verlangen, nicht das größte.

So sind die Zahlen entstanden. CPU und Arbeitsspeicher sind die Reservierungen (Kubernetes Requests) aus unseren Helm-Charts, pro Szenario aufsummiert, plus Reserve. Es sind keine Ergebnisse aus Lasttests. GPU-Angaben sind als gemessen gekennzeichnet, wo wir die Konfiguration produktiv betreiben, und als geschätzt, wo wir sie berechnet haben. Starte auf der vorgeschlagenen Stufe, beobachte in den ersten Wochen die tatsächliche Auslastung und passe dann an (siehe Installation erweitern).

Anforderungen für alle Szenarien

	Anforderung
CPU-Architektur	x86-64 (amd64). Ein “Kern” auf dieser Seite bedeutet eine vCPU.
Betriebssystem	Ubuntu 22.04 oder neuer
Speicher	SSD. Lass /var auf der Systemfestplatte statt auf einer kleinen separaten Partition.
Topologie	Ein einzelner Node. Die Plattform hat keine eingebaute Hochverfügbarkeit; siehe Verfügbarkeit und Backup.

Szenario 1: Plattform

	Minimum	Empfohlen
CPU	4 Kerne	8 Kerne
RAM	16 GB	32 GB
Systemfestplatte	100 GB	100 GB
Datenfestplatte	250 GB	500 GB

Die Dienste der Plattform reservieren etwa 2 Kerne und 6 GB und können in Spitzen bis auf etwa 9 Kerne und 18 GB gehen. Der Rest entfällt auf Kubernetes selbst und auf die MCP-Server, die du auf derselben VM betreibst. Auf der Minimalstufe passt eine volle Spitze nicht in den Arbeitsspeicher. Der Arbeitsspeicher ist auch die erste Grenze, an die du stößt, wenn du MCP-Server hinzufügst. Wähle deshalb die empfohlene Stufe, wenn du mehrere betreiben willst.

Die Datenfestplatte enthält die Datenbank, den Suchindex und hochgeladene Dateien und wächst mit der Menge an Inhalten, die du hochlädst.

Übernimmt Intric die Verarbeitung, holen die Verarbeitungsdienste von Intric jede hochgeladene Datei aus deinem Objektspeicher und schicken das Ergebnis an deine Plattform zurück. Deine API und dein Objektspeicher müssen deshalb für den Verarbeitungsdienst von Intric über HTTPS mit einem gültigen Zertifikat erreichbar sein. Du kannst den Zugriff auf die Quell-IP-Adressen beschränken, die Intric dir nennt.

Szenario 2: Plattform + Verarbeitung

Lädst du eine Datei hoch, muss die Plattform sie erst in Text umwandeln, bevor Assistenten darin suchen können. Diese Arbeit übernehmen die Verarbeitungsdienste:

• PDF-Verarbeitung liest Layout, Tabellen und Text von PDF-Dateien und erkennt Text auf gescannten Seiten (OCR).
• Dokumentaufnahme teilt den Text in Abschnitte, und ein Embedding-Modell wandelt jeden davon in einen Vektor um, den die Suche finden kann. Hast du ein Bildmodell konfiguriert, schickt die Dokumentaufnahme außerdem Bilder und Diagramme aus den Dokumenten zur Beschreibung an dieses Modell.
• Audiotranskription bereitet Aufnahmen vor und schickt sie an ein Speech-to-Text-Modell, das den Text zurückgibt.

Die Worker selbst laufen auf der CPU. Die Modelle, die sie aufrufen (Embeddings, Speech-to-Text und das Bildmodell), brauchen eine GPU und laufen nicht auf der VM: In den Szenarien 1 und 2 rufen die Worker von Intric gehostete Modelle über das Netzwerk auf, in Szenario 3 Modelle auf deinen eigenen GPU-Servern. Szenario 2 braucht deshalb keine GPU.

Eine Message Queue übergibt jeden Job an den passenden Worker. In Szenario 1 betreibt Intric diese Dienste für dich; in Szenario 2 betreibst du sie auf deiner eigenen VM. Die Anzahl der Worker folgt automatisch der Anzahl wartender Jobs, und die Worker brauchen nur CPU, während sie Dokumente oder Aufnahmen verarbeiten. Die PDF-Verarbeitung macht den größten Teil aus: Jeder PDF-Worker reserviert 6 Kerne und 5 GB, weil die OCR auf gescannten Seiten KI-Modelle auf der CPU ausführt. Jedes Dokument bearbeitet genau ein Worker. Mehr Worker bedeuten also, dass die Plattform mehr Dokumente gleichzeitig verarbeiten kann.

Stufe	PDF-Worker	Worker für Dokumentaufnahme	Worker für Transkription	CPU	RAM
Einstieg	1	2	1	~20 Kerne	~40 GB
Standard	4	4	3	~40 Kerne	~60 GB
Hoher Durchsatz	9	9	5	~72 Kerne	~88 GB

Jede Summe besteht aus dem Minimum von Szenario 1 (4 Kerne / 16 GB), den Reservierungen der Verarbeitungsdienste und 8 Kernen / 16 GB Reserve für Spitzen. Ein Beispiel für Standard: 4 PDF-Worker (24 Kerne / 20 GB), 4 Worker für Dokumentaufnahme (1,2 Kerne / 2 GB), 3 Worker für Transkription (0,6 Kerne / 2,3 GB) sowie Message Queue, Job-Koordination, Code-Sandbox und Export-Dienst, die immer laufen (1,4 Kerne / 1,9 GB), ergeben zusammen etwa 27 Kerne / 26 GB. Mit Plattform und Reserve sind es etwa 40 Kerne / 60 GB.

Einstieg funktioniert, aber große Uploads landen in der Warteschlange, und ein großes gescanntes Dokument dauert spürbar länger. Standard ist für die meisten Organisationen ein guter Ausgangspunkt.

Unter Last kann ein PDF-Worker bis zum Doppelten seiner CPU-Reservierung und bis zu 8 GB Arbeitsspeicher nutzen. Erreichen alle PDF-Worker der Stufe Hoher Durchsatz gleichzeitig ihre Spitze, kann der Speicherbedarf über der Summe oben liegen; erweitere den RAM, wenn du Speicherengpässe siehst. Die Verarbeitung steht die meiste Zeit still, deshalb bleibt die ungenutzte CPU unter VMware und ähnlichen Plattformen für andere VMs verfügbar. Reserviere für die VM daher Arbeitsspeicher, nicht CPU.

Festplatte: Plane etwa 50 GB zusätzlich für Container-Images ein (allein das Image der PDF-Verarbeitung hat etwa 9 GB). Jeder Transkriptions-Worker schreibt während der Arbeit bis zu 2 GB temporäre Dateien, die Code-Sandbox bis zu 1 GB, und zwar auf das Dateisystem, das /var/lib/kubelet enthält. Läuft /var voll, beginnt Kubernetes, Workloads auf der gesamten VM zu verdrängen (evict).

Das Helm-Chart setzt die Obergrenzen für Worker anfangs vorsichtig: consumers.pdfPreProcessing.scaling.maxReplicas steht standardmäßig auf 2, für Dokumentaufnahme und Audiotranskription auf 5. Hebe jede Obergrenze mindestens auf die Anzahl deiner Stufe an, sonst skalieren die Worker nicht in die Kapazität hinein, die du bereitgestellt hast.

Szenario 3: Vollständig lokal

Alle KI-Modelle laufen auf separaten GPU-Servern, die die VM über das Netzwerk erreicht: das Sprachmodell und die unterstützenden Modelle, die die Verarbeitungs-Worker aufrufen (Embeddings, Speech-to-Text und das Bildmodell). Dimensioniere die VM wie in Szenario 2.

Sprachmodell. Die Kapazität hängt viel stärker davon ab, wie viele Anfragen gleichzeitig laufen und wie lang die angehängten Dokumente sind, als von der Anzahl der Nutzer. Bei einem unserer größeren kommunalen Kunden liegt die Spitze im Produktivbetrieb bei etwa 10 gleichzeitigen Anfragen.

Diese Empfehlungen ändern sich laufend. Modelle und GPU-Generationen entwickeln sich schnell, und was wir heute empfehlen, kann in wenigen Monaten überholt sein. Die Konfigurationen unten geben unsere Einschätzung vom Oktober 2026 wieder. Wir überarbeiten sie, sobald wir neue Modelle und neue Hardware messen, und wir stimmen die Dimensionierung mit dir ab, bevor du etwas bestellst.

Konfiguration	Modell	Geeignet für	Status
1× H200 (141 GB)	Gemma 4 31B	Chat und Fragen zu Dokumenten	Gemessen im Produktivbetrieb
2× B200	Inkling Small (276B Parameter, 12B aktiv)	Schnellere Antworten, lange Dokumente, komplexere Aufgaben in mehreren Schritten	Geschätzt
8× B200 (ein Node)	Inkling (etwa 950B Parameter, 40B aktiv)	Viele gleichzeitige Nutzer und die anspruchsvollsten Aufgaben	Geschätzt

1× H200 ist die Konfiguration, die wir heute produktiv betreiben. Gemessen mit Gemma 4 31B (4-Bit-Gewichte, vLLM): ~100 tokens/s pro Antwort bei einer einzelnen Anfrage und Platz im GPU-Speicher für etwa 900.000 Tokens Gesprächskontext. Das reicht für etwa 9 gleichzeitige Gespräche mit vollem Kontext von 100.000 Tokens, bei üblichen Prompt-Größen für deutlich mehr. Nach unserer Schätzung bringt eine weitere Karte mit einer eigenen Kopie des Modells noch einmal dieselbe Kapazität und dazu Redundanz. Die H200 gehört zur Hopper-Generation von NVIDIA (H100/H200), die Blackwell (B200 und neuer) gerade ablöst. NVIDIA verkauft und unterstützt Hopper-Karten weiterhin, hat für Teile der Generation aber bereits das End-of-Life angekündigt. Bei einer Neuanschaffung empfehlen wir deshalb, die Verfügbarkeit zu prüfen und Blackwell in Betracht zu ziehen. Gemma 4 sollte auch auf eine einzelne B200 passen, die mehr Speicher und Bandbreite als die H200 hat. Getestet haben wir das aber noch nicht.

Für 2× B200 mit Inkling Small schätzen wir ~150 tokens/s pro Antwort und Platz für 17–53 gleichzeitige Gespräche mit vollem Kontext von 100.000 Tokens. Das vollständige Inkling-Modell passt nur auf einen ganzen Node; für 8× B200 schätzen wir damit ~110 tokens/s pro Antwort und Platz für 44–142 solcher Gespräche. Diese Konfiguration bringt Kapazität und Modellgröße, keine schnelleren Antworten pro Nutzer. Die Inkling-Modelle setzen Blackwell-GPUs voraus und laufen nicht auf H100/H200. Die B200-Zahlen haben wir aus unseren Messungen auf der H200 und den Hardware-Spezifikationen berechnet; unter realer Last haben wir sie noch nicht betrieben.

Unterstützende Modelle. Embeddings (Suche), Speech-to-Text und das Bildmodell, das Bilder und Diagramme in Dokumenten interpretiert, sind kleiner. In unserer größten lokalen Installation teilen sie sich eine GPU mit 94 GB und belegen etwa 50 GB davon. Plane deshalb eine Karte mit mindestens 80 GB ein, wenn sie zusammen laufen sollen (zum Beispiel eine NVIDIA RTX PRO 6000 Blackwell Server Edition, 96 GB).

GPU-Server brauchen Rechenzentrums-GPUs (passiv gekühlt) in einem Server, der für sie zertifiziert ist, mit ausreichender Kühlung und Stromversorgung.

Installation erweitern

• Dokumente brauchen lange, bis sie durchsuchbar sind: Prüfe die Verarbeitungs-Queues. Stehen die Worker an ihrer Obergrenze, erhöhe maxReplicas und gib der VM mehr CPU und RAM.
• Speicherengpässe oder verdrängte Pods: Erweitere zuerst den RAM. Er ist die häufigste Grenze auf der Plattform-VM.
• Antworten beginnen unter Last verzögert (Szenario 3): Füge eine GPU für das Sprachmodell hinzu.

Verfügbarkeit und Backup

Alle Szenarien laufen auf einer einzelnen VM. Startet deine Virtualisierungsplattform eine VM nach einem Hardwareausfall auf einem anderen Host neu (zum Beispiel vSphere HA), deckt das die meisten Verfügbarkeitsanforderungen ab, auf Kosten weniger Minuten Ausfallzeit. VM-Snapshots sind kein konsistentes Datenbank-Backup. Wir richten regelmäßige Datenbank-Dumps ein, die du außerhalb der VM speichern solltest.

Netzwerk und Firewall

Eingehender Verkehr (Ports)

• Port 443: Weboberfläche (HTTPS), aus den Netzwerken deiner Nutzer.
• Port 80: Automatische Weiterleitung auf HTTPS.
• Port 22: SSH, für Installation und Betrieb. Beschränke den Port auf den Zugangsweg von Intric (zum Beispiel dein VPN); er sollte nicht aus dem Internet erreichbar sein.

Ausgehender Verkehr (Whitelist - Infrastruktur)

Zusätzlich zu den Sprachmodellen (siehe Abschnitt unten) braucht der Server HTTPS-Zugriff auf:

• get.k3s.io, github.com, objects.githubusercontent.com (Installation von k3s)
• ghcr.io, pkg-containers.githubusercontent.com (Container-Images und Helm-Charts von Intric)
• registry-1.docker.io, auth.docker.io, production.cloudflare.docker.com (Container-Images von Drittanbietern)
• login.intric.ai (Intric nutzt seinen eigenen IdP für die Authentifizierung)

Prüft dein Proxy oder deine Firewall TLS, nimm diese Hosts davon aus. Installationen ohne ausgehenden Zugriff sind möglich, wenn du alle Images in eine private Registry spiegelst.

Sprachmodelle für On-Premises-Betrieb

In den Szenarien 1 und 2 rufen die Plattform und die Verarbeitungs-Worker Sprachmodelle, Embeddings und Speech-to-Text über das Netzwerk auf. Erlaube ausgehenden Verkehr zu:

Intric gehostete Modelle (EU):

• gpu6.intric.ai (von Intric gehostetes Sprachmodell)
• embedding-model.intric.ai (von Intric gehostete Embeddings)
• Speech-to-Text: Die Adresse hängt vom Transkriptionsanbieter ab, den deine Installation nutzt; du bekommst sie von uns
• mcp.intric.ai/* (von Intric gehostete MCP-Server)
• mcp-servers.intric.ai/* (von Intric gehostete MCP-Server)

Die aktuelle Modellauswahl findest du im Admin-Bereich unter Modelle.

Externe öffentliche Modelle (APIs):

• api.openai.com/v1
• api.anthropic.com
• api.berget.ai/v1
• api.mistral.ai/v1

Domain und Zertifikat

1. DNS: Lass die gewählte Domain (z. B. app.company.com) per A- oder AAAA-Eintrag auf die IP-Adresse des Servers zeigen.

2. SSL/TLS-Zertifikat: Du musst gültige Zertifikate bereitstellen:

   • Zertifikatsdatei (.crt): Vollständige Kette im PEM-Format.
   • Privater Schlüssel (.key): Privater Schlüssel im PEM-Format.
   • Hinweis: Der Kunde ist für die Erneuerung des Zertifikats verantwortlich.