Vespa On-Premise: Installation und Performance für RAG

Pexon Consulting | 11 Min. Lesezeit | 13.04.2026

TL;DR

Vespa ist eine Open-Source-Suchplattform, die Vektor-Suche, Keyword-Matching und ML-Ranking in einer Engine vereint — ohne Cloud-Abhängigkeit. Vespa On-Premise läuft als Docker-Container oder auf Kubernetes und liefert P50-Latenzen von 16 ms bei 50 Millionen Vektoren. Pexon Consulting setzt Vespa bei Kunden in regulierten Branchen als Kern der RAG-Infrastruktur ein — DSGVO-konform, auf eigener Hardware.

Warum gerade jetzt alle über On-Premise-KI reden

Das On-Premise-Segment hält 2026 rund 46 % des AI-Infrastruktur-Markts — Tendenz steigend. Der Markt selbst ist auf über 101 Milliarden USD gewachsen. Die Gründe sind weniger technisch als regulatorisch: Finance, Versicherung und öffentliche Verwaltung wollen ihre Daten nicht in der Cloud haben. Punkt.

Für RAG-Systeme — also KI-Assistenten, die Firmenwissen durchsuchen — ist die Vektordatenbank das Herzstück. Und hier wird die Entscheidung Cloud vs. On-Premise besonders kritisch: In der Vektordatenbank liegen die Embeddings Ihrer internen Dokumente, Verträge, Handbücher. Ein Compliance-Officer fragt zu Recht: „Wo genau sind diese Daten gespeichert?“

Mit Vespa On-Premise lautet die Antwort: Auf Ihrem Server, in Ihrem Rechenzentrum, unter Ihrer Kontrolle.

Was Vespa von anderen Vektordatenbanken unterscheidet

Vespa ist nicht einfach eine Vektordatenbank. Das ist ein verbreitetes Missverständnis.

Yahoo hat Vespa ursprünglich gebaut, um 800.000 Suchanfragen pro Sekunde für eine Milliarde Nutzer zu bedienen. Perplexity — die KI-Suchmaschine mit über 45 Millionen monatlichen Nutzern — hat 2025 seine komplette Suche auf Vespa migriert. Das sind 100 Millionen Queries pro Woche.

Der Unterschied zu reinen Vektordatenbanken wie Milvus, Qdrant oder Pinecone: Vespa kombiniert drei Suchtypen in einer einzigen Abfrage:

# Vespa Hybrid Search — eine Query, drei Signale
{
  "yql": "select * from docs where
    userQuery() or
    ({targetHits:100}nearestNeighbor(embedding, query_embedding))",
  "query": "Wartungsintervall Hydraulikpumpe Typ 4500",
  "ranking.profile": "hybrid_rag",
  "input.query(query_embedding)": [0.12, -0.34, 0.56, ...]
}

Diese eine Anfrage macht gleichzeitig:

1. Keyword-Matching (BM25) — findet „Hydraulikpumpe Typ 4500“ exakt
2. Vektor-Suche (HNSW) — findet semantisch ähnliche Dokumente
3. ML-Ranking — kombiniert beide Signale plus Business-Regeln

Bei Milvus oder Qdrant bräuchten Sie dafür zwei separate Systeme und einen eigenen Fusionslayer. Das ist mehr Code, mehr Latenz, mehr Fehlerquellen.

Vespa On-Premise: Hardware-Anforderungen

Bevor wir installieren: Was brauchen Sie an Hardware?

Für einen Proof of Concept reicht ein einzelner Server. Für Produktion empfehlen wir mindestens 3 Nodes — Vespa ist für verteilte Deployments gebaut.

Wir raten von HDDs ab. Vespa nutzt Memory-Mapped Files intensiv — NVMe-SSDs machen bei den Latenzen einen Faktor 5–10 aus. Bei einem Fertigungsunternehmen, das wir beraten haben, sank die P95-Latenz allein durch den Wechsel von SATA-SSD auf NVMe von 85 ms auf 19 ms.

Installation: Docker auf einem einzelnen Server

# 1. Docker installieren (falls nicht vorhanden)
curl -fsSL https://get.docker.com | sh

# 2. Systemlimits setzen — PFLICHT für Vespa
sudo sysctl -w vm.max_map_count=262144
echo "vm.max_map_count=262144" | sudo tee -a /etc/sysctl.conf

# 3. Vespa Container starten
docker run --detach 
  --name vespa 
  --hostname vespa-node0 
  --publish 8080:8080 
  --publish 19071:19071 
  --ulimit nofile=65536:65536 
  --pids-limit -1 
  vespaengine/vespa:latest

# 4. Warten bis Vespa bereit ist (ca. 30-60 Sekunden)
while ! curl -s http://localhost:19071/state/v1/health | grep -q '"UP"'; do
  echo "Warte auf Vespa..."
  sleep 5
done
echo "Vespa läuft!"

Die vm.max_map_count-Einstellung vergisst fast jeder beim ersten Mal. Ohne sie startet Vespa zwar, crasht aber unter Last mit kryptischen Fehlermeldungen. Setzen Sie den Wert persistent in /etc/sysctl.conf, nicht nur temporär.

Applikation deployen: Hybrid Search Schema

Vespa funktioniert anders als klassische Datenbanken. Sie definieren ein Schema, das Ihre Dokumentstruktur und die Ranking-Logik enthält — alles in einer Datei.

# schemas/doc.sd — Vespa Schema für RAG
schema doc {
    document doc {
        field title type string {
            indexing: summary | index
            index: enable-bm25
        }
        field content type string {
            indexing: summary | index
            index: enable-bm25
        }
        field embedding type tensor<float>(x[384]) {
            indexing: attribute | index
            attribute {
                distance-metric: angular
            }
            index {
                hnsw {
                    max-links-per-node: 16
                    neighbors-to-explore-at-insert: 200
                }
            }
        }
        field category type string {
            indexing: attribute | summary
        }
        field last_updated type long {
            indexing: attribute | summary
        }
    }

    # Hybrid Ranking: BM25 + Vektor-Ähnlichkeit
    rank-profile hybrid_rag inherits default {
        inputs {
            query(query_embedding) tensor<float>(x[384])
        }
        first-phase {
            expression: bm25(title) + bm25(content) + closeness(field, embedding)
        }
    }
}

# Applikation deployen
vespa deploy --wait 60
# Oder via REST API:
curl -X POST http://localhost:19071/application/v2/tenant/default/prepareandactivate 
  -H "Content-Type: application/zip" 
  --data-binary @app.zip

Beachten Sie die hnsw-Parameter im Schema: max-links-per-node: 16 und neighbors-to-explore-at-insert: 200 sind unsere bewährten Werte für RAG-Workloads mit 384-dimensionalen Embeddings (z.B. all-MiniLM-L6-v2). Höhere Werte verbessern den Recall, kosten aber RAM und Indexing-Geschwindigkeit. Für die meisten Enterprise-RAG-Szenarien sind diese Einstellungen ein guter Kompromiss.

Performance-Tuning: Von 50 ms auf 16 ms

Vespa liefert out-of-the-box akzeptable Performance. Aber mit drei Stellschrauben holen Sie deutlich mehr raus.

Transparent Huge Pages (THP) aktivieren. Das ist der größte Einzelhebel. Vespa nutzt Memory-Mapped Files für den HNSW-Index — mit THP reduziert sich die Anzahl der Page-Table-Einträge um den Faktor 512.

# THP auf dem Host-OS aktivieren (nicht im Container!)
echo always > /sys/kernel/mm/transparent_hugepage/enabled
echo always > /sys/kernel/mm/transparent_hugepage/defrag

# Persistent machen
echo 'echo always > /sys/kernel/mm/transparent_hugepage/enabled' >> /etc/rc.local

Proton Tuning für große Datasets. Ab 5 Millionen Dokumenten lohnt es sich, den Memory-Footprint pro Attribut zu optimieren:

<!-- services.xml — Proton Tuning -->
<content id="docs" version="1.0">
  <tuning>
    <resource-limits>
      <memory>0.8</memory>  <!-- 80% des RAM für Vespa -->
      <disk>0.9</disk>
    </resource-limits>
  </tuning>
</content>

Batch-Feeding statt Einzel-Inserts. Vespa hat einen optimierten Feed-Client der Dokumente parallel schreibt. Der Unterschied: 200 Dokumente/Sekunde bei einzelnen PUTs vs. 5.000+/Sekunde über den Batch-Client.

# Vespa Feed Client (Java) — 10x schneller als REST PUTs
vespa feed --file documents.jsonl --connections 8

In einem Benchmark mit 50 Millionen Vektoren (384 Dimensionen) haben wir mit diesen Optimierungen eine P50-Latenz von 16 ms erreicht — zum Vergleich: Milvus lag auf identischer Hardware bei 140 ms. Das ist kein Zufall, sondern Architektur: Vespa wurde für Echtzeit-Suche bei Yahoo gebaut, nicht als nachträgliche Vektordatenbank.

Vespa On-Premise vs. Cloud-Alternativen

Nicht jeder braucht On-Premise. Aber wenn Sie es brauchen, gibt es gute Gründe.

Unsere Empfehlung: Wenn Ihre Daten unter DSGVO, DORA oder branchenspezifische Regulierung fallen und Sie absehbar mehr als 5 Millionen Dokumente indexieren — dann ist Vespa On-Premise der robusteste Weg. In allen anderen Fällen ist eine Managed-Lösung wie Azure AI Search weniger Aufwand.

Für Kunden, die Vespa On-Premise als Teil einer größeren Private-AI-Infrastruktur betreiben, integrieren wir es mit LiteLLM als LLM-Gateway und Open WebUI als Chat-Oberfläche. Das ergibt einen vollständigen, DSGVO-konformen KI-Stack ohne Cloud-Abhängigkeit.

Häufig gestellte Fragen

Was kostet Vespa On-Premise im Vergleich zu Azure AI Search?

Vespa selbst ist kostenlos (Open Source, Apache 2.0 Lizenz). Sie zahlen nur die Hardware. Ein Produktions-Cluster mit 3 Nodes à 64 GB RAM kostet bei Bare-Metal-Hosting 500–800 EUR/Monat. Azure AI Search kostet für vergleichbare Kapazität 2.000–5.000 EUR/Monat — dafür ohne Wartungsaufwand. Ab 5 Millionen Dokumenten amortisiert sich Vespa On-Premise innerhalb von 6–12 Monaten.

Brauche ich Kubernetes für Vespa On-Premise?

Nein. Für bis zu 3 Nodes reicht Docker Compose. Kubernetes lohnt sich ab 5+ Nodes oder wenn Sie automatisches Scaling und Rolling Updates brauchen. Vespa bietet offizielle Helm Charts für K8s-Deployments. In unseren Projekten starten wir mit Docker und migrieren auf Kubernetes, sobald der Produktionscluster wächst.

Vespa vs. Milvus — welche Vektordatenbank für RAG?

Kommt drauf an. Milvus ist schneller beim reinen Vektor-Recall unter 0,95 und hat ein breiteres SDK-Ökosystem. Vespa gewinnt bei Hybrid Search (BM25 + Vektor + Ranking in einer Query), Real-Time-Indexing und Latenz bei großen Datasets (16 ms vs. 140 ms bei 50M Vektoren). Für Enterprise-RAG mit deutschen Fachbegriffen, wo Keyword-Matching wichtig ist, empfehlen wir Vespa.

Wie sicher ist Vespa On-Premise im Vergleich zur Cloud?

So sicher wie Ihre Infrastruktur. Vespa selbst hat keine eingebaute Authentifizierung auf API-Ebene — Sie müssen das über Netzwerk-Segmentierung, TLS-Terminierung am Reverse Proxy und IP-Whitelisting absichern. Das klingt nach Mehraufwand, gibt Ihnen aber volle Kontrolle. In unseren Case Studies zeigen wir, wie wir das für regulierte Branchen umsetzen.

Kann Pexon bei der Vespa-Integration helfen?

Ja. Wir setzen Vespa als Teil von Private-AI-Infrastrukturen ein — inklusive Embedding-Pipeline, Hybrid-Search-Tuning und Integration in bestehende Dokumentenmanagementsysteme. Ein typisches Projekt dauert 4–8 Wochen vom PoC bis zum produktiven RAG-System.

Nächster Schritt

Wenn Sie eine RAG-Infrastruktur aufbauen wollen, bei der Ihre Daten das Rechenzentrum nicht verlassen: Wir beraten Sie bei der Architektur — von der Hardware-Dimensionierung über Vespa-Tuning bis zur Integration in Ihren bestehenden Stack.

Verwandte Themen