Kapazitätsplanung

Architekturübersicht

Reva besteht aus sechs Komponenten, die sich Host-Ressourcen teilen:

                     +-----------+
Microsoft Teams ---->| Reva App  |----> Ollama (GPU)
                     |  FastAPI  |       - Router: llama3.2:3b
                     |  Python   |       - Agent:  qwen3:14b
                     +-----+-----+
                           |
                +----------+----------+
                |          |          |
          +-----+--+ +----+---+ +----+---+
          |PostgreSQL| | Redis  | |  MCP   |
          | pgvector | |  cache | | servers|
          +----------+ +--------+ +--------+
                                    (Release, Jira)

Ressourcenverbrauchsprofil:

• GPU (Ollama): Der dominierende Engpass. Alle LLM-Inferenzen werden serialisiert über die GPU ausgeführt. Jede Benutzeranfrage erfordert 2–4 LLM-Aufrufe (1 Router-Klassifikation + 1–3 Agent-Schritte).
• CPU/RAM (Reva App): Leichtgewichtiger asynchroner Python-Prozess. Verbringt die meiste Zeit mit dem Warten auf GPU- und MCP-Antworten.
• CPU/RAM (MCP-Server): Zwei Sidecar-Container für API-Aufrufe an Digital.ai Release und Jira. Median-Latenz 63ms.
• CPU/RAM (PostgreSQL): Gesprächsverlauf und pgvector-Embeddings. Sub-Millisekunden-Abfragezeiten. War in Tests nie ein Engpass.
• CPU/RAM (Redis): Sitzungscache. Sub-Millisekunden-Latenz. Vernachlässigbarer Ressourcenverbrauch.

Komponentenanforderungen

Mindestressourcen pro Komponente für ein Single-Instance-Deployment:

GPU-Dimensionierung

Die GPU ist die wichtigste Kapazitätsentscheidung. Alle anderen Komponenten sind im Vergleich zur GPU günstig.

Wichtigste Ergebnisse aus Tests (RTX 5070 Ti 16GB)

• Einzelbenutzer: 22s Median End-to-End (4 Agent-Schritte, 1 Tool-Aufruf).
• Durchsatz-Obergrenze: 0,05 QPS (konstant unabhängig von Parallelität) = ~3 Anfragen/Min.
• Lineare Degradation: Jeder zusätzliche gleichzeitige Benutzer fügt ~20s Wartezeit hinzu, bedingt durch GPU-Queue-Serialisierung.
• 5 gleichzeitige Benutzer: 40% der Anfragen liefen beim 120s-Client-Timeout ab.
• NUM_PARALLEL=2 bei 16GB: 5x langsamer (110s vs. 22s). Das qwen3:14b-Modell belegt ~9 GB für Gewichte, sodass nur ~7 GB für KV-Cache verbleiben. Zwei parallele Sequenzen lösen CPU-Offloading aus.

Wann welche GPU-Stufe verwenden

• 8 GB: Proof of Concept oder persönliche Nutzung. Ein kleineres Modell (qwen3:8b) ist erforderlich. Reduzierte Tool-Calling-Genauigkeit zu erwarten.
• 16 GB: Kleines Team (< 20 Benutzer), leichte Nutzung. Akzeptabel, wenn die meisten Benutzer nur 1–2 Anfragen pro Tag senden.
• 24 GB: Mittleres Team (20–100 Benutzer), moderate Nutzung. Ermöglicht NUM_PARALLEL=2 ohne KV-Cache-Überlauf. Erste Stufe, auf der vLLM sinnvoll wird.
• 48 GB: Großes Deployment oder intensive Nutzung. vLLM-Continuous-Batching bietet nahezu lineares Durchsatz-Scaling bis 10+ gleichzeitige Benutzer.

Benutzer pro Instanz

„Gleichzeitige Benutzer“ unterscheidet sich von „Gesamtbenutzer.“ Die meisten Unternehmensbenutzer interagieren nur wenige Male täglich mit Reva. Die folgende Tabelle ordnet Gesamt-Teams-Benutzer der benötigten Infrastruktur zu, basierend auf einem gemessenen Durchsatz von ~3 Anfragen/Min. auf einer 16GB-GPU.

So schätzen Sie Ihr Nutzungsmuster

1. Zählen Sie Ihre Reva-berechtigten Benutzer (Release-Manager, Ops-Ingenieure usw.).
2. Schätzen Sie die Spitzenstundenlast: Typischerweise sind 10–20% der Benutzer in der stärksten Stunde aktiv.
3. Multiplizieren Sie aktive Benutzer mit durchschnittlichen Anfragen pro Stunde.
4. Wenn die Spitzenanfragen/Minute 3 (16GB) oder 6 (24GB) übersteigt, benötigen Sie eine größere GPU oder mehrere Instanzen.

Skalierungsentscheidungsbaum

Verwenden Sie diesen Baum, wenn Antwortzeiten oder Timeouts auf Skalierungsbedarf hinweisen:

Skalierungsoptionen in Prioritätsreihenfolge

K8s-Ressourcenbeispiele

Produktionsgetestete Ressourcenspezifikationen aus den Kubernetes-Manifesten des Projekts.

Reva-Anwendungs-Pod (inkl. MCP-Sidecars)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: reva
  namespace: reva
spec:
  replicas: 1
  template:
    spec:
      containers:
        - name: reva
          image: reva:latest
          resources:
            requests:
              cpu: 100m
              memory: 256Mi
            limits:
              memory: 1Gi

        - name: release-mcp
          image: xebialabsearlyaccess/dai-release-mcp:25.3.0-beta.926
          resources:
            requests:
              cpu: 50m
              memory: 128Mi
            limits:
              memory: 256Mi

        - name: jira-mcp
          image: ghcr.io/sooperset/mcp-atlassian:0.21.0
          resources:
            requests:
              cpu: 50m
              memory: 128Mi
            limits:
              memory: 256Mi

PostgreSQL StatefulSet

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
  namespace: reva
spec:
  template:
    spec:
      containers:
        - name: postgres
          image: pgvector/pgvector:pg16
          resources:
            requests:
              cpu: 100m
              memory: 256Mi
            limits:
              memory: 512Mi
  volumeClaimTemplates:
    - metadata:
        name: pgdata
      spec:
        resources:
          requests:
            storage: 10Gi

Redis

apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis
  namespace: reva
spec:
  template:
    spec:
      containers:
        - name: redis
          image: redis:7-alpine
          resources:
            requests:
              cpu: 50m
              memory: 64Mi
            limits:
              memory: 128Mi

Gesamtes Pod-Ressourcenbudget

Cloud-LLM-Vergleich

Wenn die lokale GPU-Kapazität nicht ausreicht, bieten Cloud-LLM-APIs unbegrenzte Skalierung zu Pro-Token-Kosten. Dieser Vergleich geht davon aus, dass das Ollama-Router-Modell (llama3.2:3b) weiterhin lokal läuft.

Kosten pro Anfrage (Schätzung)

Eine typische Reva-Anfrage umfasst ~4 LLM-Aufrufe mit insgesamt ca. 4.000 Eingabe-Tokens und 800 Ausgabe-Tokens.

Break-Even-Analyse

GPU-Amortisationskosten über 3 Jahre (typischer Enterprise-Hardware-Lebenszyklus):

Wann Cloud sinnvoll ist

• Weniger als 100 Anfragen/Tag und Sie möchten keine GPU beschaffen
• Burst-Kapazität benötigt, die über die lokale GPU hinausgeht
• Proof of Concept oder Testinstallationen

Wann lokale GPU sinnvoll ist

• Mehr als 100 Anfragen/Tag im Dauerbetrieb
• Anforderungen an Datensouveränität (keine Daten verlassen das Netzwerk)
• Planbare, feste monatliche Kosten gegenüber variablen Pro-Token-Abrechnungen bevorzugt

Monitoring für Kapazität

Reva stellt Metriken über GET /api/stats (JSON) und GET /api/metrics (Prometheus) bereit. Dies sind die kapazitätsrelevanten Metriken:

Prometheus-Alerting-Regeln (Beispiel)

groups:
  - name: reva-capacity
    rules:
      - alert: RevaHighLatency
        expr: reva_request_duration_seconds{quantile="0.95"} > 30
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Reva p95-Antwortzeit überschreitet 30s"

      - alert: RevaVeryHighLatency
        expr: reva_request_duration_seconds{quantile="0.95"} > 60
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Reva p95-Antwortzeit überschreitet 60s"

      - alert: RevaHighErrorRate
        expr: rate(reva_requests_total{status="error"}[5m]) / rate(reva_requests_total[5m]) > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Reva-Fehlerrate überschreitet 5%"

      - alert: RevaDBPoolExhaustion
        expr: reva_db_pool_checked_out / reva_db_pool_size > 0.9
        for: 1m
        labels:
          severity: warning
        annotations:
          summary: "Datenbank-Connection-Pool > 90% ausgelastet"

Manueller Kapazitätscheck

Führen Sie dies regelmäßig oder nach Skalierungsänderungen aus:

# Schneller Kapazitäts-Snapshot
curl -s http://localhost:3978/api/stats | jq '{
  response_p50: .request_performance.response_time_p50_s,
  response_p95: .request_performance.response_time_p95_s,
  rpm: .request_performance.requests_per_minute,
  active_sessions: .conversations.active_sessions,
  llm_p50: .llm.response_time_p50_s,
  db_pool_used: .infrastructure.db_pool_checked_out,
  db_pool_max: (.infrastructure.db_pool_size + 20),
  process_rss_mb: (.infrastructure.process_rss_bytes / 1048576 | floor)
}'

Speicherplanung

PostgreSQL-Wachstum

PostgreSQL speichert Gesprächsverlauf, pgvector-Embeddings und Metadaten. Das Wachstum hängt vom Nutzungsvolumen ab.

Geschätztes monatliches Wachstum

Die Standard-PVC-Größe von 10 Gi reicht für alle außer den intensivsten Deployments über mehrere Jahre. Berücksichtigen Sie täglich komprimierte Backups (~5–10% der DB-Größe pro Backup, 30-Tage-Aufbewahrung):

Ollama-Modellspeicher

Modelldateien werden auf dem Ollama-Host gespeichert (nicht im K8s-Cluster).

Docker-Log-Speicher

Log-Rotation ist in docker-compose.yml konfiguriert: