Desenvolvedor Busca Conselhos de Arquitetura para Servir Modelos de Embed, Rerank e Zero-Shot em 8GB de VRAM

Visão Geral do Problema

Um desenvolvedor está construindo um serviço unificado de Grafo de Conhecimento/RAG para um agente de codificação local que roda em um único contêiner Docker via FastAPI. O sistema inicialmente funcionava bem no Windows (WSL), mas a migração para Linux nativo expôs problemas severos de limite de memória sob testes de estresse.

Restrições de Hardware e Modelos

Hardware:

• 8GB de VRAM (GPU de laptop)
• ~16GB de RAM do sistema (os limites do Docker são atingidos rapidamente, geralmente apenas ~6GB livres quando os modelos estão carregados)

Pilha de Modelos:

• Embedding: nomic-ai/nomic-embed-text-v2-moe
• Reclassificação (Reranking): BAAI/bge-reranker-base
• Classificação: MoritzLaurer/ModernBERT-large-zeroshot-v2.0 (usado para classificar pares de texto em 4 relações: dependência, expansão, contradição, não relacionado)

Desafios Técnicos

O desenvolvedor não pode truncar textos de forma agressiva porque está alimentando trechos de código e texto natural nesses modelos e precisa processar sequências longas e variáveis.

Problemas específicos encontrados:

• Latência vs. OOM: Usar torch.cuda.empty_cache() para manter a GPU limpa causa picos de latência de 18-20 segundos por requisição devido a sincronizações do driver. Remover isso faz com que a GPU instantaneamente atinja OOM quando requisições concorrentes chegam.
• Explosão de RAM do Sistema (Linux Exit 137): Usar o pipeline da Hugging Face ("zero-shot-classification") causou um inchaço massivo da RAM da CPU. Sem truncamento, o pipeline gera matrizes de combinação massivas na memória antes de enviá-las para a GPU, fazendo com que o kernel do Linux mate instantaneamente o contêiner.
• Picos de VRAM: cudnn.benchmark = True estava armazenando em cache espaços de trabalho para cada comprimento de sequência único, drenando 3GB de VRAM livre em segundos durante testes de estresse.

Implementação Atual

O desenvolvedor tem uma configuração pura em Python/FastAPI com as seguintes soluções alternativas:

• Contornou o pipeline da HF e escreveu um loop de inferência NLI manual para o ModernBERT
• Usando asyncio.Lock() para forçar execução serial (apenas um modelo toca na GPU por vez)
• Usando desalocação determinística (del inputs + gc.collect()) via tarefas em segundo plano do FastAPI

Essa abordagem é melhor, mas ainda instável sob um teste de estresse de 3 minutos.

Perguntas para a Comunidade

O desenvolvedor está buscando conselhos sobre:

• Alternativas de Modelos: Modelos menores/mais rápidos que mantêm alta precisão para Zero-Shot NLI e Reclassificação (Reranking) que se encaixem melhor em um envelope de 8GB
• Arquiteturas Pré-construídas: Anteriormente olhou para infinity_emb, mas teve dificuldades para integrar a lógica personalizada de classificação NLI de 4 vias sem carregar modelos em dobro. Considerando TEI (Text Generation Inference), TensorRT ou outras soluções otimizadas para modelos Encoder
• Estratégia de Serviço: Padrões de design padrão para hospedar 3 modelos de transformadores em uma única GPU de consumidor sem que eles interfiram na memória um do outro