Infrastruktur für KI-Workflows dimensionieren: Kapazität planen

Die KI-Automatisierung läuft, die Workflows sind gebaut, und plötzlich stehen Sie vor der Frage: Reicht der Server noch, wenn wir das auf die gesamte Vertriebsmannschaft ausrollen? Oder auf alle Eingangsrechnungen? Die meisten mittelständischen IT-Leiter kennen diesen Moment. Eine zu knappe Dimensionierung führt zu Timeouts, abgebrochenen Prozessen und Support-Anfragen. Eine deutlich überdimensionierte Infrastruktur bindet Budget, das an anderer Stelle fehlt. Dieser Artikel zeigt Ihnen, wie Sie die Kapazität für KI-Workflows planbar machen, welche Kennzahlen Sie brauchen und welche Fehler Sie vermeiden sollten.

Was Dimensionierung bei KI-Workflows bedeutet

Dimensionierung heißt: Sie bestimmen, wie viel Rechenleistung, Arbeitsspeicher, Speicherplatz und Netzwerkbandbreite Ihre Automatisierungen benötigen. Anders als bei klassischer Bürosoftware schwankt die Last bei KI-Workflows stark. Ein OCR-Lauf über 200 Eingangsrechnungen am Monatsanfang erzeugt eine andere Last als ein einzelnes Lead-Scoring am Dienstagnachmittag. Hinzu kommen Sprachanfragen an LLMs, RAG-Abfragen gegen Vektordatenbanken oder die Vorverarbeitung von Bildern und PDFs. Jeder dieser Schritte benötigt Ressourcen, und alle laufen oft gleichzeitig.

Sie müssen drei Ebenen betrachten: die Workflow-Plattform selbst (n8n, Make, Zapier), die angebundenen Dienste (Datenbanken, LLM-APIs, Objektspeicher) und die Netzwerkverbindungen zwischen allen Komponenten. Läuft die Plattform in der Cloud eines Drittanbieters, entfällt die Server-Dimensionierung; Netzwerk und API-Kontingente bleiben. Bei Self-Hosted-Betrieb ist jede Komponente Ihre Verantwortung.

Schritt eins: Anforderungen erfassen

Beginnen Sie mit einer Liste aller produktiven und geplanten Workflows. Notieren Sie für jeden:

• Durchsatz: wie viele Vorgänge pro Stunde oder Tag (zum Beispiel 50 Eingangsrechnungen pro Tag, 120 Lead-Scoring-Anfragen pro Stunde).
• Datenvolumen: Dateigröße bei Dokumenten, Anzahl Zeilen bei CSV-Importen, Textlänge bei LLM-Prompts.
• Externe Calls: wie viele API-Aufrufe (OpenAI, Claude, interne REST-Endpoints), welche Antwortzeiten Sie erwarten.
• Parallelität: ob Workflows sequenziell oder parallel laufen sollen, ob mehrere Nutzer gleichzeitig starten können.
• Spitzenlasten: ob es feste Zeitfenster gibt (Montagmorgen, Monatsende, Feierabend).

Fragen Sie die Fachabteilungen nach realistischen Mengen. Eine vage Aussage “so viele wie möglich” hilft nicht. Wenn die Buchhaltung sagt “wir bekommen im Schnitt 40 Rechnungen am Tag, an Monatsenden bis zu 180”, haben Sie eine belastbare Grundlage.

Schritt zwei: Ressourcenbedarf je Workflow abschätzen

Jeder Workflow verbraucht CPU, RAM und Netzwerk. Wie viel, hängt von den einzelnen Schritten ab:

• OCR und Bildverarbeitung: CPU-intensiv, bei großen PDFs oder Scans mehrere Sekunden pro Seite, typischerweise 1 bis 4 CPU-Kerne je parallelem Vorgang.
• LLM-Aufrufe: Netzwerk-intensiv, die eigentliche Inferenz läuft extern (OpenAI, Claude), lokal fallen nur Request und Response-Puffer an. Bei Self-Hosted-Modellen (Llama, Mistral) steigt der RAM-Bedarf je nach Modellgröße (ein 7B-Modell benötigt mindestens 8 GB RAM, 13B-Modelle 16 GB aufwärts).
• Vektordatenbanken (RAG): RAM-intensiv für Indizes, Disk-I/O bei großen Embedding-Tabellen.
• Datenbank-Operationen: abhängig von Indexierung und Transaktionslast, meist moderater RAM-Bedarf (4 bis 8 GB für PostgreSQL mit wenigen parallelen Anfragen).
• Datei-Uploads und -Downloads: Netzwerk und Speicher, wenig CPU.

Messen Sie einen typischen Workflow im Testsystem: starten Sie einen einzelnen Durchlauf, notieren Sie CPU-Last, RAM-Nutzung (etwa über htop oder die Monitoring-Tools Ihrer Plattform) und Laufzeit. Wiederholen Sie das mit fünf parallelen Durchläufen, um zu sehen, wie sich die Last summiert.

Schritt drei: Lastspitzen und Parallelität einplanen

Die Summe aller Durchschnittswerte reicht nicht. Wenn morgens um neun Uhr 30 Vertriebsmitarbeiter zeitgleich Follow-Up-Sequenzen starten, kommt es zu einer Lastspitze. Wenn die Buchhaltung am Monatsende 180 Rechnungen auf einmal hochlädt, brauchen Sie entweder genug Kapazität für parallele Verarbeitung oder eine Queue, die die Last glättet.

Überlegen Sie, ob Sie Lastspitzen durch zeitliche Verteilung abfedern können (etwa OCR-Läufe nachts, gestaffelte Startzeitpunkte). Ist das nicht möglich, dimensionieren Sie auf die Spitzenlast. Eine Faustregel: planen Sie 20 bis 30 Prozent Reserve über der gemessenen Spitzenlast ein, um Puffer für Wachstum und unvorhergesehene Anfragen zu haben.

Rechenbeispiel: Server für n8n mit OCR und LLM

Angenommen, Sie betreiben n8n selbst gehostet und haben folgende Workflows:

• OCR-Pipeline für Eingangsrechnungen: 180 Rechnungen am Monatsende, je 4 Seiten, Verarbeitung 3 Sekunden pro Seite, Sie wollen die Last über 6 Stunden verteilen.
• Lead-Scoring mit OpenAI-API: 120 Anfragen pro Tag, verteilt über die Geschäftszeit.
• RAG-Abfragen gegen lokale Vektordatenbank (Chroma): 50 Anfragen pro Tag.

OCR: 180 Rechnungen mal 4 Seiten sind 720 Seiten. Bei 3 Sekunden pro Seite sind das 2.160 Sekunden (36 Minuten) reine Rechenzeit. Verteilt über 6 Stunden (21.600 Sekunden) könnten Sie sequenziell arbeiten. Wollen Sie die Zeit auf 2 Stunden verkürzen, brauchen Sie 3 parallele Worker (36 Minuten geteilt durch 2 Stunden). Ein OCR-Prozess nutzt typischerweise 2 CPU-Kerne, also 6 Kerne insgesamt. RAM-Bedarf pro Worker etwa 2 GB, zusammen 6 GB.

Lead-Scoring: 120 Anfragen pro Tag, verteilt über 8 Stunden, sind 15 pro Stunde. Die API-Calls laufen extern, lokal fällt vor allem n8n-Overhead an. Angenommen, jede Anfrage benötigt 0,5 GB RAM für Zwischenergebnisse und läuft 5 Sekunden, können Sie mit 1 GB RAM und 1 CPU-Kern rechnen.

RAG: 50 Anfragen pro Tag, Chroma im RAM. Index-Größe angenommen 4 GB, je Anfrage 0,5 GB Arbeitsspeicher, 1 CPU-Kern.

Zusätzlich brauchen Sie RAM für das Betriebssystem (2 GB) und n8n selbst (1 GB Basis, 1 GB pro aktivem Workflow). Summe: 6 (OCR) + 1 (Lead-Scoring) + 4 (Chroma-Index) + 0,5 (RAG-Anfrage) + 2 (OS) + 3 (n8n) = 16,5 GB RAM. CPU: 6 + 1 + 1 = 8 Kerne. Speicherplatz: Rechnungs-PDFs 180 mal 1 MB = 180 MB pro Monat, nach einem Jahr 2,2 GB; Chroma-Index 4 GB; Logs und Datenbank 5 GB. Zusammen mindestens 15 GB, besser 50 GB mit Reserve.

Eine passende Konfiguration wäre also: 8 CPU-Kerne, 20 GB RAM (mit Reserve), 50 GB SSD. Das entspricht in etwa einem Cloud-Server der Größe “Standard” bei Hetzner (CX41: 8 vCPU, 16 GB RAM, 240 GB Disk, Stand Produktdokumentation Hetzner Cloud) oder einem vergleichbaren Dedicated-Server. Ist die Spitzenlast höher, weil alle 180 Rechnungen gleichzeitig hochgeladen werden, multiplizieren Sie die Worker-Anzahl entsprechend.

Netzwerk und externe APIs einplanen

Jede LLM-Anfrage überträgt Prompt und Antwort. Angenommen, ein Prompt hat 2.000 Zeichen (ca. 2 KB), die Antwort 1.000 Zeichen (1 KB), sind das 3 KB pro Request. Bei 120 Anfragen pro Tag sind das 360 KB, vernachlässigbar. Bei 10.000 Anfragen pro Tag (etwa im Customer-Service-Einsatz) kommen Sie auf 30 MB, immer noch unkritisch. Achten Sie aber auf API-Kontingente: OpenAI und Anthropic begrenzen Requests pro Minute (RPM) und Tokens pro Minute (TPM). Überschreiten Sie das Limit, laufen Ihre Workflows in Timeouts. Prüfen Sie die Limits in Ihrem API-Plan und bauen Sie Retry-Logik mit exponenziellem Backoff ein.

Bei Self-Hosted-Modellen fällt die externe Bandbreite weg, dafür steigt die lokale Last erheblich. Ein 13B-Modell benötigt 16 bis 32 GB RAM und mehrere CPU-Kerne (oder eine GPU), je nach Quantisierung und Inferenz-Framework.

Was häufig schiefgeht

1. Unterschätzte Spitzenlasten: Sie planen auf den Durchschnitt, aber an Monatsenden oder Feierabend häufen sich die Anfragen. Ergebnis: Timeouts, abgebrochene Workflows.
2. Fehlender Speicher für Logs und Daten: Logs wachsen schnell, vor allem bei Debug-Modus. Planen Sie Logrotation ein und überwachen Sie den freien Speicherplatz.
3. Zu wenig RAM für Vektordatenbanken: RAG-Indizes liegen idealerweise im RAM. Lädt die Datenbank ständig von Disk nach, wird jede Abfrage langsam.
4. Keine Queue bei parallelen Starts: Wenn viele Nutzer gleichzeitig auslösen, kämpfen die Workflows um Ressourcen. Eine Message-Queue (RabbitMQ, Redis) glättet die Last.
5. Vergessene Abhängigkeiten: PostgreSQL, Redis, Chroma laufen oft auf demselben Server wie n8n. Jeder Dienst braucht eigenen RAM und CPU. Addieren Sie alle Komponenten.
6. Zu knappe Netzwerkanbindung: Wenn Sie große Dateien (Videos, hochauflösende Scans) verarbeiten, prüfen Sie die Uplink-Geschwindigkeit Ihres Servers. 100 Mbit/s Shared-Anbindung kann bei mehreren parallelen Uploads zum Flaschenhals werden.

Monitoring und Anpassung

Dimensionierung ist keine einmalige Aufgabe. Richten Sie Monitoring ein: CPU-Last, RAM-Nutzung, freier Speicherplatz, Netzwerk-Durchsatz, API-Latenz. Tools wie Prometheus, Grafana oder einfache Skripte, die per Cron laufen und Schwellwerte prüfen, reichen für den Anfang. Definieren Sie Schwellwerte: etwa “wenn RAM-Nutzung über 80 Prozent bleibt, wird skaliert” oder “wenn CPU-Last über 15 Minuten über 90 Prozent liegt, Alarm”.

Protokollieren Sie, wie sich die Last über Wochen entwickelt. Steigt die Zahl der Workflows, wächst die Infrastruktur mit. Virtualisierung (Proxmox, VMware) oder Container (Docker, Kubernetes) erleichtern das Hochskalieren: Sie fügen RAM oder CPU hinzu, ohne neu aufzusetzen.

Fazit und nächster Schritt

Richtig dimensionierte Infrastruktur verhindert Ausfälle, spart Kosten und gibt Planungssicherheit. Erfassen Sie Ihre Workflows, messen Sie den Ressourcenbedarf im Testsystem, rechnen Sie Spitzenlasten und Reserve ein. Monitoring zeigt Ihnen, ob die Planung aufgeht oder ob Sie nachsteuern müssen. Vermeiden Sie die häufigsten Fehler: unterschätzte Parallelität, vergessene Abhängigkeiten, fehlende Logrotation.

Wenn Sie unsicher sind, wie viel Kapazität Ihre geplanten KI-Workflows wirklich brauchen, oder wenn Sie Self-Hosted-Betrieb mit DSGVO-konformer EU-Infrastruktur aufbauen möchten, sprechen Sie mit uns.

Sprechen Sie mit uns

Sie möchten das in Ihrem Betrieb umsetzen? Wir bauen die passende Maschine mit Ihnen.

Telefon: 040 468 967 680
E-Mail: info@whitefox-automations.com
Oder über unser Kontaktformular.