Entwickler sucht Architekturberatung für das Bereitstellen von Embed-, Rerank- und Zero-Shot-Modellen auf 8 GB VRAM

Problemübersicht

Ein Entwickler baut einen einheitlichen Wissensgraphen/RAG-Dienst für einen lokalen Coding-Agenten, der in einem einzelnen Docker-Container über FastAPI läuft. Das System lief anfangs unter Windows (WSL) in Ordnung, aber der Wechsel zu nativem Linux offenbarte unter Stresstests schwerwiegende Speicherlimit-Probleme.

Hardware- und Modellbeschränkungen

Hardware:

• 8 GB VRAM (Laptop-GPU)
• ~16 GB System-RAM (Docker-Limits werden schnell erreicht, normalerweise nur ~6 GB frei, wenn Modelle geladen sind)

Modell-Stack:

• Embedding: nomic-ai/nomic-embed-text-v2-moe
• Reranking: BAAI/bge-reranker-base
• Klassifikation: MoritzLaurer/ModernBERT-large-zeroshot-v2.0 (wird verwendet, um Textpaare in 4 Relationen zu klassifizieren: Abhängigkeit, Erweiterung, Widerspruch, unabhängig)

Technische Herausforderungen

Der Entwickler kann Text nicht aggressiv kürzen, da Code-Abschnitte und natürlicher Text in diese Modelle eingespeist werden und variable, lange Sequenzen verarbeitet werden müssen.

Spezifische auftretende Probleme:

• Latenz vs. OOM: Die Verwendung von torch.cuda.empty_cache(), um die GPU sauber zu halten, verursacht Latenzspitzen von 18-20 Sekunden pro Anfrage aufgrund von Treiber-Synchronisationen. Das Weglassen führt dazu, dass die GPU bei gleichzeitigen Anfragen sofort OOM-Fehler verursacht.
• System-RAM-Explosion (Linux Exit 137): Die Verwendung der Hugging Face Pipeline ("zero-shot-classification") verursachte massive CPU-RAM-Aufblähung. Ohne Kürzung erzeugt die Pipeline riesige Kombinationsmatrizen im Speicher, bevor sie an die GPU gesendet werden, was dazu führt, dass der Linux-Kernel den Container sofort beendet.
• VRAM-Spitzen: cudnn.benchmark = True speicherte Arbeitsbereiche für jede eindeutige Sequenzlänge zwischen und entleerte so innerhalb von Sekunden 3 GB freien VRAM während Stresstests.

Aktuelle Implementierung

Der Entwickler hat einen reinen Python/FastAPI-Aufbau mit folgenden Workarounds:

• Umging die HF-Pipeline und schrieb eine manuelle NLI-Inferenzschleife für ModernBERT
• Verwendet asyncio.Lock(), um serielle Ausführung zu erzwingen (nur ein Modell greift gleichzeitig auf die GPU zu)
• Verwendet deterministische Freigabe (del inputs + gc.collect()) über FastAPI-Hintergrundaufgaben

Dieser Ansatz ist besser, aber unter einem 3-minütigen Stresstest immer noch instabil.

Fragen an die Community

Der Entwickler sucht Rat zu:

• Modellalternativen: Kleinere/schnellere Modelle, die eine hohe Genauigkeit für Zero-Shot NLI und Reranking beibehalten und besser in einen 8-GB-Rahmen passen
• Vorgefertigte Architekturen: Hatte sich zuvor infinity_emb angesehen, hatte aber Schwierigkeiten, benutzerdefinierte 4-Wege-NLI-Klassifikationslogik zu integrieren, ohne Modelle doppelt zu laden. Erwägt TEI (Text Generation Inference), TensorRT oder andere für Encoder-Modelle optimierte Lösungen
• Bereitstellungsstrategie: Standard-Designmuster für das Hosten von 3 Transformer-Modellen auf einer einzelnen Consumer-GPU, ohne dass sie sich gegenseitig in den Speicher greifen