Infinity: ein Serving-Engine für Embeddings, Reranker und multimodale Modelle

Welches Problem Infinity adressiert

Embedding-Modelle sind klein genug, um sie in einem Prozess zu laden, und zahlreich genug, dass ein einzelner Prozess schnell zum Engpass wird. Wer semantische Suche, Reranking oder multimodale Vektoren in einer Anwendung braucht, steht vor derselben Aufgabe: Modellgewichte laden, Tokenisierung und Vorverarbeitung beschleunigen, Anfragen bündeln, eine HTTP-Schnittstelle bereitstellen und all das auf dem vorhandenen Beschleuniger betreiben. Infinity nimmt diese Aufgabe als fertigen Dienst ab. Die Zielgruppe sind laut Repository Entwickler und Plattformteams, die Modelle selbst hosten, statt eine gehostete Embedding-API zu mieten: also alle, die Datenhoheit, feste Kosten oder eigene Hardware brauchen. Die Liste der Integrationen im README (Baseten, Runpod, TrueFoundry, Vast, SAP, BentoML und weitere) deutet darauf hin, dass der typische Einsatz nicht der einzelne Laptop ist, sondern eine Container-Umgebung mit GPU.

Ein Prozess, mehrere Modelle, ein HTTP-Endpunkt

Das zentrale Architekturmerkmal ist die Trennung zwischen API-Schicht und Inferenz-Workern. Der Server basiert auf FastAPI, die Modellausführung läuft in Worker-Threads, in denen Tokenisierung und Batching stattfinden. Das README nennt das ausdrücklich: Infinity nutze dynamisches Batching und Tokenisierung in dedizierten Worker-Threads. Für den Aufrufer bedeutet das, dass er einzelne Texte schicken kann, während der Server sie intern zu größeren Batches zusammenfasst. Das ist der übliche Weg, um Durchsatz auf GPUs zu erhöhen, ohne die Latenz einer einzelnen Anfrage zu stark zu verschlechtern. Unter den Workern liegt eine austauschbare Inferenzschicht. Das Repository nennt PyTorch, Optimum mit ONNX- und TensorRT-Export sowie CTranslate2 als Backends und FlashAttention zur Beschleunigung. Der zweite Architekturpunkt ist die Mehrfachmodell-Fähigkeit: Die v2-CLI kann laut README mehrere Modelle starten, und Infinity orchestriert sie. Ein Prozess kann also ein Text-Embedding-Modell, einen Reranker und ein CLIP-Modell gleichzeitig bedienen. Wie die Zuordnung von Anfrage zu Modell genau aussieht, geht aus dem vorliegenden Material nicht hervor; das wäre in der Online-Dokumentation zu prüfen.

Installation und Start über die v2-CLI

Der schnellste Weg führt über pip. Das README gibt den Befehl pip install infinity-emb[all] an, gefolgt vom Start des Servers mit infinity_emb v2 --model-id BAAI/bge-small-en-v1.5. Die Hilfe zu allen Parametern liefert infinity_emb v2 --help. Bemerkenswert ist, dass die CLI laut README alle Argumente auch über Umgebungsvariablen akzeptiert, was den Betrieb in Container-Orchestrierung vereinfacht, weil dann kein angepasstes Startkommando nötig ist. Für den Produktivbetrieb empfiehlt das README ausdrücklich das vorgebaute Docker-Image michaelf34/infinity. Dabei muss der Beschleuniger in den Container durchgereicht werden, im README ist von nvidia-docker die Rede. Wer den Dienst gegen unbefugten Zugriff absichern will, kann laut den Release-Hinweisen seit Mai 2024 einen API-Schlüssel über die v2-CLI setzen, das entsprechende Argument heißt --api-key. Ein Python-Client existiert separat als pip install infinity_client, seit Oktober 2024.

Beschleuniger, Backends und Quantisierung

Die Bandbreite der unterstützten Hardware ist ungewöhnlich groß für ein Projekt dieser Größe. Das README nennt NVIDIA CUDA, AMD ROCm, CPU, AWS Inferentia 2 und Apple MPS. Die Release-Hinweise ergänzen: November 2024 brachte AMD-, CPU- und ONNX-Docker-Images, Juli 2025 Unterstützung für Blackwell. Für Quantisierung nennt das README experimentellen int8-Support auf CPU und CUDA sowie fp8 auf H100 und MI300, eingeführt im März 2024. Das Wort experimentell steht dort wörtlich. Wer Quantisierung einsetzt, sollte also mit abweichenden Ergebnissen gegenüber dem Vollmodell rechnen und das selbst nachmessen; das Repository liefert dafür keine Garantie. Die Backend-Vielfalt ist ein Vorteil und eine Fehlerquelle zugleich: PyTorch, ONNX, TensorRT und CTranslate2 verhalten sich nicht identisch, und nicht jedes Modell lässt sich auf jedes Backend exportieren. Die Dokumentation verweist für Optimierungen auf Optimum, was bedeutet, dass die Exportpfade von einem separaten Projekt gepflegt werden.

Wo Infinity die falsche Wahl ist

Infinity ist ein Server, kein Bibliotheks-Wrapper. Wer in einem einzelnen Python-Skript einmalig ein paar tausend Texte einbetten will, zahlt mit Infinity den Preis eines laufenden Dienstes für einen Batch-Job. In diesem Fall ist ein direkter Aufruf über sentence-transformers oder ein Skript mit dem HuggingFace-Transformer kürzer und schneller zum Ziel. Auch für sehr kleine Latenzanforderungen bei genau einem Modell ist die zusätzliche Schicht nicht kostenlos: FastAPI, Worker-Threads und Batching-Logik bringen Overhead und Konfigurationsfläche mit. Ein weiterer Grenzfall sind Umgebungen, in denen die Modellgewichte nicht aus dem Netz geladen werden dürfen. Das README beschreibt den Bezug der Modelle von HuggingFace als Kernfunktion; ob und wie ein vollständig offline betriebener Modell-Cache konfiguriert wird, ist dem vorliegenden Material nicht zu entnehmen und muss vorab geklärt werden. Und schließlich: Wer eine verwaltete API ohne eigenen Betrieb sucht, ist hier falsch, denn Infinity wird selbst gehostet.

Der Unterschied zu Text Embeddings Inference

Der naheliegende Vergleich ist HuggingFace Text Embeddings Inference (TEI), das ein ähnliches Problem adressiert und dessen Modell-Tag text-embeddings-inference im README von Infinity sogar als Filter für die Modellauswahl auftaucht. Der Unterschied liegt im Umfang der Backends und Modalitäten. TEI ist auf Text-Embeddings und Reranking ausgerichtet und wird von HuggingFace selbst gepflegt, was die Anbindung an das Ökosystem und den Support-Pfad vereinfacht. Infinity geht breiter: Das Projekt nennt zusätzlich CLIP, CLAP und Colpali, also Bild-, Audio- und Dokumenten-Retrieval, und erlaubt mehrere Modelle in einem Prozess. Wer nur Text-Embeddings mit einem Modell braucht, bekommt bei TEI einen kleineren, enger geführten Funktionsumfang. Wer dagegen Text-, Bild- und Audiovektoren über eine gemeinsame Schnittstelle ausliefern will, muss bei TEI mehrere Dienste nebeneinander betreiben. Die Wahl hängt also weniger von der Leistung ab, die das Material ohnehin nicht vergleichend belegt, als davon, ob ein Dienst oder mehrere gebraucht werden.

Wartung, Versionierung und Lizenz

Die Versionsnummern stehen noch auf 0.0.x, zuletzt 0.0.77 vom August 2025, davor 0.0.76 im März 2025 und 0.0.75 im Januar 2025. Der Abstand zwischen den Releases ist unregelmäßig, das letzte Repository-Update liegt laut Metadaten im März 2026. Für Betreiber heißt das: Upgrade-Pfade sollten getestet werden, und Breaking Changes sind bei einer Null-Komponente nicht ausgeschlossen. Ein Upgrade betrifft nicht nur das Python-Paket, sondern auch die Backend-Abhängigkeiten. Wer TensorRT oder ONNX nutzt, muss zusätzlich die Exportpfade von Optimum im Blick behalten, weil sich Änderungen dort auf die geladenen Modelle auswirken können. Das Docker-Image michaelf34/infinity entkoppelt das teilweise, bindet aber an das Image-Tag. Lizenziert ist Infinity unter MIT, was kommerzielle Nutzung und Modifikation erlaubt, solange Lizenz- und Copyright-Hinweis erhalten bleiben. Diese Aussage bezieht sich nur auf den Code von Infinity selbst. Die heruntergeladenen Modellgewichte stehen unter eigenen Lizenzen, die je nach Modell kommerzielle Nutzung einschränken können. Das ist vor dem Produktiveinsatz pro Modell zu prüfen, nicht pauschal für das Projekt.

Redaktionelles Fazit

Wer mehrere Embedding- oder Reranking-Modelle hinter einer einzigen, OpenAI-kompatiblen HTTP-Schnittstelle betreiben will, findet in Infinity eine passende Grundlage. Wer nur ein einzelnes Modell mit minimalem Betriebsaufwand braucht, fährt mit einem schlankeren Server oder einem gehosteten Dienst oft günstiger, weil er dann keine Accelerator-Treiber, kein Docker-Image und keine Modellverwaltung selbst tragen muss. Vor dem Einsatz ist zu prüfen, ob das gewählte Backend zum eigenen Beschleuniger passt (die Dokumentation nennt CUDA, ROCm, CPU, AWS INF2 und Apple MPS, dazu ONNX und CTranslate2), ob die installierte Version die benötigte Modellarchitektur unterstützt und ob die eigene Infrastruktur das offizielle Image michaelf34/infinity mit durchgereichtem Accelerator starten kann.

Offizielle Quellen

1. License: MIT
2. michaelfeil/infinity on GitHub
3. Project website
4. README
5. Releases