Ein praktischer Leitfaden zum Deployment von Search Foundation Models in der Produktion

Bei Jina AI ist es unsere Mission, Unternehmensanwendern hochwertige Suchlösungen bereitzustellen. Um dies zu erreichen, machen wir unsere Modelle über verschiedene Kanäle zugänglich. Die Wahl des richtigen Kanals für Ihren spezifischen Anwendungsfall kann jedoch knifflig sein. In diesem Beitrag führen wir Sie durch den Entscheidungsprozess, erläutern die Vor- und Nachteile und geben Ihnen praktische Hinweise, wie Sie basierend auf Ihrem Nutzerprofil und Ihren Anforderungen am besten auf unsere Search Foundation Models zugreifen können.

tagJina Search Foundation Models

Our Search Foundation Models

We've been moving the needle in search models since day one. Take a look at our model evolution below—hover or click to discover each milestone.

Jina AI

Unsere Search Foundation Models umfassen:

• Embeddings: Diese wandeln Informationen über digitale Objekte in Embedding-Vektoren um und erfassen dabei deren wesentliche Eigenschaften.
• Rerankers: Diese führen eine eingehende semantische Analyse von Query-Dokument-Sets durch, um die Suchrelevanz zu verbessern.
• Small Language Models: Diese umfassen spezialisierte SLM wie ReaderLM-v2 für Nischenaufgaben wie HTML2Markdown oder Informationsextraktion.

In diesem Beitrag untersuchen wir verschiedene Bereitstellungsoptionen für jina-embeddings-v3 und vergleichen drei zentrale Ansätze:

• Nutzung der Jina API
• Bereitstellung über CSP wie AWS SageMaker
• Self-Hosting auf einem Kubernetes-Cluster unter einer kommerziellen Lizenz

Der Vergleich wird die Kostenauswirkungen und Vorteile jedes Ansatzes bewerten, um Ihnen bei der Bestimmung der für Sie am besten geeigneten Option zu helfen.

tagWichtige Leistungsmetriken

Wir haben fünf wichtige Leistungsmetriken in verschiedenen Nutzungsszenarien ausgewertet:

• Request Success Rate: Der Prozentsatz erfolgreicher Anfragen an den Embedding-Server
• Request Latency: Die Zeit, die der Embedding-Server für die Verarbeitung und Rückgabe einer Anfrage benötigt
• Token Throughput: Die Anzahl der Token, die der Embedding-Server pro Sekunde verarbeiten kann
• Cost per Token: Die gesamten Verarbeitungskosten pro Texteinheit

Für selbst gehostete Jina Embeddings auf Kubernetes-Clustern haben wir auch die Auswirkungen von Dynamic Batching untersucht. Diese Funktion reiht Anfragen in eine Warteschlange ein, bis die maximale Batch-Größe (8.192 für jina-embeddings-v3) erreicht ist, bevor Embeddings generiert werden.

Wir haben bewusst zwei wichtige Leistungsfaktoren von unserer Analyse ausgeschlossen:

• Auto-scaling: Während dies für Cloud-Bereitstellungen mit variablen Workloads entscheidend ist, hängt seine Effektivität von zahlreichen Variablen ab – Hardware-Effizienz, Netzwerkarchitektur, Latenz und Implementierungsentscheidungen. Diese Komplexitäten gehen über unseren aktuellen Rahmen hinaus. Beachten Sie, dass Jina API automatische Skalierung beinhaltet und unsere Ergebnisse dies widerspiegeln.
• Quantisierung: Während diese Technik kleinere Embedding-Vektoren erzeugt und den Datentransfer reduziert, kommen die hauptsächlichen Vorteile von anderen Systemkomponenten (Datenspeicherung und Vektor-Distanzberechnungen) anstatt von reduziertem Datentransfer. Da wir uns auf direkte Modellnutzungskosten konzentrieren, haben wir die Quantisierung aus dieser Analyse ausgelassen.

Schließlich werden wir die finanziellen Auswirkungen jedes Ansatzes untersuchen, wobei sowohl die Gesamtbetriebskosten als auch die Kosten pro Token/Anfrage berücksichtigt werden.

tagDeployment-Setup

Wir haben drei Bereitstellungs- und Nutzungsszenarien mit jina-embeddings-v3 evaluiert:

tagNutzung der Jina API

Alle Jina AI Embedding-Modelle sind über die Jina API zugänglich. Der Zugriff funktioniert über ein Prepaid-Token-System, wobei eine Million Token kostenlos zum Testen zur Verfügung stehen. Wir haben die Leistung durch API-Aufrufe über das Internet von unseren deutschen Büros aus evaluiert.

tagNutzung von AWS SageMaker

Jina Embeddings v3 ist für AWS-Benutzer über SageMaker verfügbar. Die Nutzung erfordert ein AWS-Abonnement für dieses Modell. Für Beispielcode haben wir ein Notebook bereitgestellt, das zeigt, wie man Jina AI-Modelle mit einem AWS-Konto abonniert und nutzt.

Während die Modelle auch auf Microsoft Azure und Google Cloud Platform verfügbar sind, haben wir uns bei unseren Tests auf AWS konzentriert. Wir erwarten ähnliche Leistung auf anderen Plattformen. Alle Tests liefen auf einer ml.g5.xlarge Instanz in der Region us-east-1.

tagSelf-Hosting auf Kubernetes

Wir haben eine FastAPI-Anwendung in Python entwickelt, die jina-embeddings-v3 von HuggingFace unter Verwendung der SentenceTransformer Bibliothek lädt. Die App enthält zwei Endpunkte:

• /embed: Nimmt Textpassagen als Input und gibt deren Embeddings zurück
• /health: Bietet grundlegendes Gesundheitsmonitoring

Wir haben dies als Kubernetes-Service auf Amazon's Elastic Kubernetes Service bereitgestellt, unter Verwendung einer g5.xlarge Instanz in us-east-1.

Mit und ohne Dynamic Batching

Wir haben die Leistung in einem Kubernetes-Cluster in zwei Konfigurationen getestet: Eine, bei der jede Anfrage sofort nach Erhalt verarbeitet wurde, und eine mit Dynamic Batching. Beim Dynamic Batching wartet der Service, bis MAX_TOKENS (8192) in einer Warteschlange gesammelt sind oder ein vordefiniertes Timeout von 2 Sekunden erreicht ist, bevor das Modell aufgerufen und die Embeddings berechnet werden. Dieser Ansatz erhöht die GPU-Auslastung und reduziert die Fragmentierung des GPU-Speichers.

Für jedes Bereitstellungsszenario führten wir Tests mit drei Schlüsselparametern durch:

• Batch-Größe: Jede Anfrage enthielt entweder 1, 32 oder 128 Textpassagen für Embedding
• Passagenlänge: Wir verwendeten Textpassagen mit 128, 512 oder 1.024 Token
• Gleichzeitige Anfragen: Wir sendeten 1, 5 oder 10 Anfragen gleichzeitig

tagBenchmark-Ergebnisse

Die folgende Tabelle ist eine Zusammenfassung der Ergebnisse für jedes Nutzungsszenario, gemittelt über alle Einstellungen der drei Variablen oben.

tagRequest Success Rate

Die Erfolgsraten in unserem Test reichen von SageMakers nahezu perfekten 99,9% bis zu den bescheidenen 56-58% der Self-Hosted-Lösungen, was zeigt, warum 100% Zuverlässigkeit in Produktionssystemen weiterhin schwer erreichbar bleibt. Drei Hauptfaktoren tragen dazu bei:

• Netzwerkinstabilität verursacht unvermeidbare Ausfälle selbst in Cloud-Umgebungen
• Ressourcenkonflikte, insbesondere beim GPU-Speicher, führen zu Anfrage-Fehlern unter Last
• Notwendige Timeout-Limits bedeuten, dass einige Anfragen fehlschlagen müssen, um die Systemgesundheit zu erhalten

tagErfolgsrate nach Batch-Größe

Große Batch-Größen verursachen häufig Out-of-Memory-Fehler in der selbst gehosteten Kubernetes-Konfiguration. Ohne Dynamic Batching schlugen alle Anfragen mit 32 oder 128 Items pro Batch aus diesem Grund fehl. Selbst mit implementiertem Dynamic Batching blieb die Fehlerrate für große Batches signifikant hoch.

Obwohl dieses Problem durch Auto-Scaling leicht behoben werden könnte, haben wir uns entschieden, diese Option hier nicht zu untersuchen. Auto-Scaling würde zu unvorhersehbaren Kostensteigerungen führen, und es wäre schwierig, angesichts der großen Anzahl verfügbarer Auto-Scaling-Konfigurationsoptionen praktische Erkenntnisse zu liefern.

tagErfolgsrate nach Parallelitätsgrad

Parallelität – die Fähigkeit, mehrere Anfragen gleichzeitig zu verarbeiten – hatte weder einen starken noch einen konsistenten Einfluss auf die Erfolgsraten der Anfragen in den selbst gehosteten Kubernetes-Konfigurationen und nur minimale Auswirkungen auf AWS SageMaker, zumindest bis zu einem Parallelitätsgrad von 10.

tagErfolgsrate nach Token-Länge

Lange Passagen mit hoher Token-Anzahl beeinflussen sowohl die Jina Embedding API als auch Kubernetes mit dynamischem Batching ähnlich wie große Batches: Mit zunehmender Größe steigt die Fehlerrate erheblich. Während selbst gehostete Lösungen ohne dynamisches Batching bei großen Batches fast immer fehlschlagen, funktionieren sie bei einzelnen langen Passagen besser. Bei SageMaker hatten lange Passagenlängen – wie Parallelität und Batch-Größe – keinen nennenswerten Einfluss auf die Erfolgsraten der Anfragen.

tagAnfrage-Latenz

Alle Latenztests wurden fünfmal bei Parallelitätsgraden von 1, 5 und 10 wiederholt. Die Antwortzeit ist der Durchschnitt über fünf Versuche. Der Anfragedurchsatz ist der Kehrwert der Antwortzeit in Sekunden, multipliziert mit der Parallelität.

tagJina API

Die Antwortzeiten in der Jina API werden hauptsächlich von der Batch-Größe beeinflusst, unabhängig vom Parallelitätsgrad. Während die Passagenlänge auch die Leistung beeinflusst, ist ihre Auswirkung nicht geradlinig. Als allgemeines Prinzip gilt: Anfragen mit mehr Daten – sei es durch größere Batch-Größen oder längere Passagen – benötigen mehr Verarbeitungszeit.

Parallelität 1:

Parallelität 5:

Parallelität 10:

Für einzelne Anfragen (Batch Size 1):

• Die Antwortzeiten bleiben relativ stabil bei etwa 600-800 ms, unabhängig von der Passagenlänge
• Höhere Parallelität (5 oder 10 gleichzeitige Anfragen) beeinträchtigt die Leistung pro Anfrage nicht wesentlich

Für größere Batches (32 und 128 Elemente):

• Die Antwortzeiten steigen erheblich an, wobei Batch Size 128 etwa 4-6 mal länger dauert als einzelne Anfragen
• Der Einfluss der Passagenlänge wird bei größeren Batches deutlicher
• Bei hoher Parallelität (10) und großen Batches (128) führt die Kombination zu deutlich längeren Antwortzeiten, die bei den längsten Passagen fast 18 Sekunden erreichen

Für den Durchsatz:

• Kleinere Batches erzielen im Allgemeinen einen besseren Durchsatz bei parallel laufenden Anfragen
• Bei Parallelität 10 mit Batch Size 1 erreicht das System seinen höchsten Durchsatz von etwa 15 Anfragen pro Sekunde
• Größere Batches zeigen durchgehend niedrigeren Durchsatz, der in mehreren Szenarien auf weniger als 1 Anfrage pro Sekunde sinkt

tagAWS SageMaker

AWS SageMaker Tests wurden mit einer ml.g5.xlarge Instanz durchgeführt.

Parallelität 1:

Parallelität 5:

Parallelität 10:

Wesentliche Unterschiede zur Jina API:

• Basis-Performance: SageMaker ist deutlich schneller bei kleinen Anfragen (einzelne Elemente, kurze Passagen) - etwa 200 ms gegenüber 700-800 ms bei Jina.
• Skalierungsverhalten:
  • Beide Dienste werden mit größeren Batches und längeren Passagen langsamer
  • SageMaker zeigt eine drastischere Verlangsamung bei großen Batches (128) und langen Passagen (1024 Tokens)
  • Bei hoher Parallelität (10) mit maximaler Last (Batch 128, 1024 Tokens) benötigt SageMaker ~26s gegenüber Jinas ~18s
• Auswirkungen der Parallelität:
  • Beide Dienste profitieren von erhöhter Parallelität beim Durchsatz
  • Beide behalten ähnliche Durchsatzmuster über verschiedene Parallelitätsstufen hinweg bei
  • SageMaker erreicht bei Parallelität 10 einen etwas höheren Spitzendurchsatz (17 Anfr./s vs. 15 Anfr./s)

tagSelf-Hosted Kubernetes Cluster

Die Self-Hosting-Tests wurden auf Amazon's Elastic Kubernetes Service mit einer g5.xlarge Instanz durchgeführt.

Parallelität 1:

Parallelität 5:

Parallelität 10:

Bei Anfragen mit mehr als 16.384 Token scheiterte unser Self-Hosting-Setup mit Serverfehlern, typischerweise Out-of-Memory-Fehlern. Dies galt unabhängig von der Parallelität. Daher werden keine Tests mit mehr Daten als diese angezeigt.

Hohe Parallelität erhöhte die Antwortzeiten weitgehend linear: Parallelitätsstufen von 5 brauchten ungefähr fünfmal so lange zum Antworten wie 1. Stufen von 10 brauchten zehnmal so lange.

Dynamisches Batching verlangsamt die Antwortzeiten bei kleinen Batches um etwa zwei Sekunden. Dies ist zu erwarten, da die Batching-Warteschlange 2 Sekunden wartet, bevor sie einen nicht vollen Batch verarbeitet. Bei größeren Batch-Größen bringt es jedoch moderate Verbesserungen in der Antwortzeit.

tagToken-Durchsatz

Der Token-Durchsatz steigt mit größeren Batch-Größen, längeren Passagenlängen und höherer Parallelität über alle Plattformen hinweg. Daher präsentieren wir nur Ergebnisse bei hoher Auslastung, da niedrigere Levels keine aussagekräftige Indikation der realen Performance liefern würden.

Alle Tests wurden bei einer Parallelität von 10 mit 16.384 Token pro Anfrage durchgeführt, gemittelt über fünf Anfragen. Wir testeten zwei Konfigurationen: Batch-Größe 32 mit 512-Token-Passagen und Batch-Größe 128 mit 128-Token-Passagen. Die Gesamtzahl der Token bleibt über beide Konfigurationen konstant.

Token-Durchsatz (Token pro Sekunde):

Unter hoher Last übertrifft die Jina API die Alternativen deutlich, während die hier getesteten Self-Hosted-Lösungen eine wesentlich niedrigere Leistung zeigen.

tagKosten pro Million Token

Die Kosten sind wohl der wichtigste Faktor bei der Wahl einer Embedding-Lösung. Während die Berechnung von KI-Modellkosten komplex sein kann, hier eine vergleichende Analyse verschiedener Optionen:

tagJina API

Der Service folgt einem tokenbasierten Preismodell mit zwei vorausbezahlten Stufen:

• $20 für 1 Milliarde Token ($0,02 pro Million) - Ein Einstiegstarif, ideal für Prototyping und Entwicklung
• $200 für 11 Milliarden Token ($0,018 pro Million) - Ein wirtschaftlicherer Tarif für größere Volumen

Es ist erwähnenswert, dass diese Token für Jinas gesamte Produktpalette verwendet werden können, einschließlich Reader, Reranker und Zero-Shot-Klassifikatoren.

tagAWS SageMaker

Die SageMaker-Preisgestaltung kombiniert stündliche Instanzkosten mit Modell-Lizenzgebühren. Bei Verwendung einer ml.g5.xlarge Instanz:

• Instanzkosten: $1,408/Stunde (US East) oder$1,761/Stunde (EU Frankfurt)
• jina-embeddings-v3 Lizenz: $2,50/Stunde
• Gesamtstündliche Kosten: $3,908-$4,261 je nach Region

Mit einem durchschnittlichen Durchsatz von 15.044 Token/Sekunde (54,16M Token/Stunde) liegen die Kosten pro Million Token zwischen $0,0723 und$0,0788.

tagSelf-Hosting mit Kubernetes

Die Kosten für Self-Hosting variieren erheblich je nach Infrastrukturwahl. Mit einer AWS EC2 g5.xlarge Instanz als Referenz:

• Instanzkosten: $1,006/Stunde (US East) oder$1,258/Stunde (EU Frankfurt)
• jina-embeddings-v3 Lizenz: $5000/Quartal ($2,282/Stunde)
• Gesamtstündliche Kosten: $3,288-$3,540 je nach Region

Bei 2.588 Token/Sekunde (9,32M Token/Stunde) betragen die Kosten pro Million Token $0,352-$0,379. Während der Stundensatz niedriger ist als bei SageMaker, führt der reduzierte Durchsatz zu höheren Kosten pro Token.

Wichtige Überlegungen für Self-Hosting:

• Fixkosten (Lizenzierung, Infrastruktur) fallen unabhängig von der Nutzung an
• On-Premises-Hosting erfordert weiterhin Lizenzgebühren und Personalkosten
• Variable Arbeitslasten können die Kosteneffizienz erheblich beeinflussen

tagWichtige Erkenntnisse

Die Jina API erweist sich als die kostengünstigste Lösung, selbst ohne Berücksichtigung von Kaltstartzeiten und unter Annahme optimalen Durchsatzes für Alternativen.

Self-Hosting könnte für Organisationen mit bestehender robuster Infrastruktur sinnvoll sein, bei denen die marginalen Serverkosten minimal sind. Zusätzlich könnte die Erkundung von Cloud-Anbietern jenseits von AWS bessere Preise ergeben.

Für die meisten Unternehmen, insbesondere KMUs, die schlüsselfertige Lösungen suchen, bietet die Jina API jedoch unübertroffene Kosteneffizienz.

tagSicherheits- und Datenschutzaspekte

Bei der Wahl einer Deploymentstrategie für Embedding-Modelle können Sicherheits- und Datenschutzanforderungen neben Performance und Kostenüberlegungen eine entscheidende Rolle spielen. Wir bieten flexible Deployment-Optionen für verschiedene Sicherheitsanforderungen:

tagCloud Service Provider

Für Unternehmen, die bereits mit großen Cloud-Anbietern arbeiten, bieten unsere Cloud-Marketplace-Angebote (wie AWS Marketplace, Azure und GCP) eine natürliche Lösung für das Deployment innerhalb bestehender Sicherheitsframeworks. Diese Deployments profitieren von:

• Vererbten Sicherheitskontrollen und Compliance aus Ihrer CSP-Beziehung
• Einfacher Integration mit bestehenden Sicherheitsrichtlinien und Datenverwaltungsregeln
• Erfordern wenig oder keine Änderungen an bestehenden Datenverarbeitungsvereinbarungen
• Abstimmung mit bestehenden Datensouveränitätsaspekten

tagSelf-Hosting und lokales Deployment

Organisationen mit strengen Sicherheitsanforderungen oder spezifischen regulatorischen Verpflichtungen bevorzugen oft vollständige physische Kontrolle über ihre Infrastruktur. Unsere Self-Hosted-Option ermöglicht:

• Volle Kontrolle über die Deployment-Umgebung
• Datenverarbeitung vollständig innerhalb Ihres Sicherheitsperimeters
• Integration mit bestehender Sicherheitsüberwachung und -kontrollen

Um eine kommerzielle Lizenz für unsere CC-BY-NC-Modelle zu erhalten, müssen Sie zunächst eine Lizenz von uns erwerben. Bitte kontaktieren Sie unser Vertriebsteam.

tagJina API Service

Für Startups und KMUs, die Sicherheit und Komfort gegen Kosten abwägen müssen, bietet unser API-Service Sicherheit auf Unternehmensebene ohne zusätzlichen operativen Aufwand:

• SOC2-Zertifizierung für robuste Sicherheitskontrollen
• Volle DSGVO-Konformität für die Datenverarbeitung
• Null-Daten-Aufbewahrungsrichtlinie - wir speichern oder protokollieren Ihre Anfragen nicht
• Verschlüsselte Datenübertragung und sichere Infrastruktur

Die Modellangebote von Jina AI ermöglichen es Organisationen, die Deploymentstrategie zu wählen, die am besten mit ihren Sicherheitsanforderungen übereinstimmt und dabei die betriebliche Effizienz aufrechterhält.

tagAuswahl Ihrer Lösung

Das folgende Flussdiagramm fasst die Ergebnisse aller empirischen Tests und Tabellen zusammen, die Sie gesehen haben:

Berücksichtigen Sie zunächst Ihre Sicherheitsanforderungen und wie viel Flexibilität Sie opfern können, um diese zu erfüllen.

Überlegen Sie dann, wie Sie KI in Ihrem Unternehmen einsetzen möchten:

1. Offline-Indexierung und nicht zeitsensitive Anwendungsfälle, die Batch-Verarbeitung optimal nutzen können.
2. Zuverlässigkeits- und skalierbarkeitssensitive Verwendungen wie Retrieval-Augmented Generation und LLM-Integration.
3. Zeitsensitive Nutzungen wie Online-Suche und -Abruf.

Berücksichtigen Sie auch Ihr internes Fachwissen und bestehende Infrastruktur:

1. Ist Ihr Technologie-Stack bereits stark Cloud-abhängig?
2. Verfügen Sie über einen großen internen IT-Betrieb, der Self-Hosting durchführen kann?

Berücksichtigen Sie schließlich Ihr erwartetes Datenvolumen. Sind Sie ein Großnutzer, der täglich Millionen von Operationen mit KI-Modellen durchführen möchte?

tagFazit

Die Integration von KI in operative Entscheidungen bleibt für viele IT-Abteilungen Neuland, da der Markt keine etablierten schlüsselfertigen Lösungen bietet. Diese Unsicherheit kann die strategische Planung erschweren. Unsere quantitative Analyse zielt darauf ab, konkrete Orientierung für die Integration unserer Such-Foundation-Models in Ihre spezifischen Workflows und Anwendungen zu geben.

Was die Kosten pro Einheit betrifft, sticht die Jina API als eine der wirtschaftlichsten Optionen für Unternehmen hervor. Nur wenige Alternativen können unseren Preis bei vergleichbarer Funktionalität erreichen.

Wir sind bestrebt, Suchfunktionen zu liefern, die nicht nur leistungsstark und benutzerfreundlich, sondern auch kosteneffektiv für Organisationen aller Größen sind. Ob über große Cloud-Anbieter oder Self-Hosted-Deployments, unsere Lösungen erfüllen selbst die komplexesten Unternehmensanforderungen, die über reine Kostenüberlegungen hinausgehen. Diese Analyse schlüsselt die verschiedenen Kostenfaktoren auf, um Ihre Entscheidungsfindung zu unterstützen.

Da jede Organisation ihre eigenen einzigartigen Anforderungen hat, sind wir uns bewusst, dass ein einzelner Artikel nicht jedes Szenario abdecken kann. Wenn Sie spezifische Bedürfnisse haben, die hier nicht behandelt wurden, kontaktieren Sie uns bitte, um zu besprechen, wie wir Ihre Implementierung am besten unterstützen können.