Desarrollador Busca Consejos de Arquitectura para Servir Modelos Embed, Rerank y Zero-Shot en 8GB de VRAM

Descripción General del Problema

Un desarrollador está construyendo un servicio unificado de Grafo de Conocimiento/RAG para un agente de codificación local que se ejecuta en un único contenedor Docker a través de FastAPI. El sistema inicialmente funcionaba bien en Windows (WSL), pero al migrar a Linux nativo se expusieron graves problemas de límite de memoria bajo pruebas de estrés.

Limitaciones de Hardware y Modelos

Hardware:

• 8GB de VRAM (GPU de portátil)
• ~16GB de RAM del sistema (los límites de Docker se alcanzan rápidamente, normalmente solo quedan ~6GB libres cuando los modelos están cargados)

Pila de Modelos:

• Embedding: nomic-ai/nomic-embed-text-v2-moe
• Reordenamiento: BAAI/bge-reranker-base
• Clasificación: MoritzLaurer/ModernBERT-large-zeroshot-v2.0 (utilizado para clasificar pares de texto en 4 relaciones: dependencia, expansión, contradicción, sin relación)

Desafíos Técnicos

El desarrollador no puede truncar el texto de forma agresiva porque está alimentando fragmentos de código y texto natural en estos modelos y necesita procesar secuencias largas y variables.

Problemas específicos encontrados:

• Latencia vs. OOM: Usar torch.cuda.empty_cache() para mantener limpia la GPU causa picos de latencia de 18-20 segundos por solicitud debido a sincronizaciones del controlador. Eliminarlo hace que la GPU se quede sin memoria (OOM) instantáneamente cuando llegan solicitudes concurrentes.
• Explosión de RAM del Sistema (Salida 137 en Linux): Usar la pipeline de Hugging Face ("zero-shot-classification") causó una enorme inflación de RAM de la CPU. Sin truncamiento, la pipeline genera matrices de combinación masivas en memoria antes de enviarlas a la GPU, haciendo que el kernel de Linux termine instantáneamente el contenedor.
• Picos de VRAM: cudnn.benchmark = True estaba almacenando en caché espacios de trabajo para cada longitud de secuencia única, agotando 3GB de VRAM libre en segundos durante las pruebas de estrés.

Implementación Actual

El desarrollador tiene una configuración pura de Python/FastAPI con los siguientes parches:

• Evitó la pipeline de HF y escribió un bucle de inferencia NLI manual para ModernBERT
• Usando asyncio.Lock() para forzar la ejecución en serie (solo un modelo toca la GPU a la vez)
• Usando desasignación determinista (del inputs + gc.collect()) a través de tareas en segundo plano de FastAPI

Este enfoque es mejor pero aún es inestable bajo una prueba de estrés de 3 minutos.

Preguntas para la Comunidad

El desarrollador está buscando consejo sobre:

• Alternativas de Modelos: Modelos más pequeños/rápidos que mantengan alta precisión para NLI de Cero Disparos y Reordenamiento que se ajusten mejor a un entorno de 8GB
• Arquitecturas Preconstruidas: Anteriormente consideró infinity_emb pero tuvo dificultades para integrar la lógica personalizada de clasificación NLI de 4 vías sin cargar modelos dos veces. Considerando TEI (Text Generation Inference), TensorRT u otras soluciones optimizadas para modelos Encoder
• Estrategia de Servicio: Patrones de diseño estándar para alojar 3 modelos transformadores en una única GPU de consumo sin que interfieran entre sí en la memoria