Sistema RAG Distribuido

💡 Para ingenieros de IA y CTOs evaluando si ejecutar LLMs localmente — y por qué la arquitectura distribuida es la respuesta a los cuellos de botella de VRAM.

🎯 TL;DR — Resumen Ejecutivo

• Problema: Ejecutar un LLM de 7B parámetros y generar embeddings en la misma máquina satura la VRAM instantáneamente
• Solución: Arquitectura distribuida que separa inferencia (servidor) de indexación (cliente local)
• Stack: Qdrant (motor vectorial) + vLLM (inferencia) + Ollama (embeddings) + Arize Phoenix (observabilidad)
• Resultado: Escalabilidad sin comprometer el entorno de desarrollo local

📋 Tabla de Contenidos

• El Problema de VRAM en RAG
• Arquitectura del Sistema: Dos Máquinas, Un Sistema
• Máquina Cliente (Local)
• Máquina Servidor (192.168.0.50)
• Beneficios del Enfoque Distribuido
• ¿Por Qué Esto Importa para Producción de IA?
• Conclusiones Clave
• Explora el Código
• Aprendizaje Continuo
• Contribuir
• Artículos Relacionados

� El Problema de VRAM en RAG

En el desarrollo de sistemas de Retrieval-Augmented Generation (RAG), uno de los mayores desafíos es gestionar los recursos computacionales de manera eficiente. Ejecutar grandes modelos de lenguaje (LLMs) localmente a menudo satura la VRAM, lo que penaliza la velocidad de indexación y recuperación de documentos.

flowchart TD
    subgraph Problem["Problema: Máquina Única — Competencia por VRAM"]
        direction TB
        A["GPU (8-24GB VRAM)"] --> B["LLM Local<br/>7B-13B parámetros"]
        A --> C["Modelo de Embeddings<br/>768 dimensiones"]
        A --> D["Base de Datos Vectorial<br/>Qdrant"]
        B --> E["⚠️ Competencia por memoria"]
        C --> E
        D --> E
        E --> F["Indexación lenta"]
        E --> G["Búsquedas inutilizables"]
    end

Los Números del Problema

💡 Arquitectura del Sistema: Dos Máquinas, Un Sistema

El sistema se divide en dos componentes principales: la Máquina Cliente (Local) y la Máquina Servidor, comunicadas a través de la red local.

flowchart LR
    subgraph Cliente["Máquina Cliente (Local)"]
        direction TB
        U["UI / MCP Bridge"] --> I["Indexer"]
        I --> O["Ollama<br/>Embeddings"]
        I --> Q["Qdrant<br/>Vector DB"]
        I --> P["Arize Phoenix<br/>Observabilidad"]
    end
    
    subgraph Servidor["Máquina Servidor (192.168.0.50)"]
        direction TB
        V["vLLM<br/>Inferencia LLM"]
    end
    
    Cliente -->|"HTTP API<br/>192.168.0.50:8000"| Servidor

Máquina Cliente (Local)

Esta máquina se encarga de la orquestación, indexación y la interfaz con el usuario.

• GPU 0 (Primaria): Compartida estratégicamente entre Ollama y Qdrant.
  • Ollama: Se utiliza exclusivamente para generar embeddings rápidos (modelos de 768 dimensiones), lo que permite un procesamiento ágil de los documentos.
  • Qdrant: Motor de base de datos vectorial que aprovecha la aceleración para la indexación HNSW.
• Arize Phoenix: Una herramienta fundamental para la observabilidad. Recolecta trazas de ejecución de los servicios locales, permitiendo auditar y depurar la recuperación de contexto (retrieval) en tiempo real.
• MCP Bridge & Indexer: El componente central de lógica de negocio. Se encarga de vigilar los archivos, orquestar los flujos de datos y servir la interfaz para las herramientas de IA.

GPU Sharing Strategy

Local Components

🖥️ Máquina Servidor (192.168.0.50)

Esta máquina está dedicada al trabajo pesado de la inferencia del modelo.

• vLLM: Ejecuta el Modelo de Lenguaje de Gran Tamaño (LLM). Al mantener este proceso en un servidor separado mediante un motor de inferencia altamente optimizado como vLLM o TensorRT-LLM, evitamos saturar la VRAM de la máquina de trabajo principal. Esto garantiza que las inferencias pesadas no afecten el rendimiento del indexador local ni de las herramientas de desarrollo.

¿Por qué vLLM?

📈 Beneficios del Enfoque Distribuido

1. Eficiencia de VRAM: Al aislar el LLM grande en el servidor, la GPU local puede dedicarse completamente a generar embeddings y realizar búsquedas vectoriales veloces, sin competir por memoria.
2. Escalabilidad: Se puede actualizar o cambiar el LLM en el servidor (ej. de un modelo de 8B a uno de 70B) sin alterar la lógica de indexación local.
3. Observabilidad: La integración de Arize Phoenix en el nodo local asegura que cada "Retrieval" pueda ser traceado y evaluado para mitigar alucinaciones.

🤔 ¿Por Qué Esto Importa para Producción de IA?

Este patrón distribuido se extiende más allá de los sistemas RAG:

✅ Conclusiones Clave

1. VRAM es el cuello de botella — ejecutar LLM + embeddings + base de datos vectorial en una GPU causa competencia
2. La arquitectura distribuida resuelve esto — separar inferencia (servidor) de indexación (local)
3. vLLM permite inferencia flexible — paged attention, continuous batching, cambio de modelos
4. Arize Phoenix proporciona observabilidad — rastrear cada recuperación para mitigar alucinaciones
5. Escalabilidad modular — actualizar el servidor independientemente del entorno de desarrollo local

🔗 Explora el Código

¿¿Quieres ver la implementación completa? Consulta el repositorio: 87maxi/rag_distributed_system en GitHub:

• docker-compose.yml — Configuración de despliegue para ambas máquinas
• client/ — Orquestación local, MCP Bridge e Indexer
• server/ — Configuración del servidor de inferencia vLLM
• observability/ — Configuración de tracing con Arize Phoenix

💬 ¿Quieres Contribuir?

Esta arquitectura es open-source y dirigida por la comunidad. Ya sea que quieras:

• Agregar soporte para bases de datos vectoriales adicionales (Pinecone, Weaviate, Milvus)
• Implementar balanceo de carga multi-servidor con vLLM
• Crear una configuración de despliegue en Kubernetes
• Mejorar los dashboards de Arize Phoenix

Haz fork del repositorio y envía un Pull Request: 87maxi/rag_distributed_system en GitHub

🔗 Aprendizaje Continuo

Mantente actualizado con lo último en arquitectura RAG y sistemas de IA distribuidos:

Recurso	Descripción	Enlace
Documentación vLLM	Docs oficiales para paged attention y continuous batching	vllm.ai
Guías de Qdrant	Mejores prácticas de búsqueda vectorial	qdrant.tech
Arize Phoenix	Frameworks de observabilidad y evaluación LLM	arize.com
Modelos Ollama	Biblioteca de modelos de embeddings optimizados	ollama.com
Docker Compose	Patrones de orquestación multi-contenedor	docs.docker.com

🔗 Artículos Relacionados

Explora más contenido técnico profundo de este blog:

Artículo	Categoría	Descripción
Aprendizaje Asistido por IA: eBPF y Blockchain	Deep Tech	Cómo aprendí programación a nivel de kernel con IA
API REST con Rust y Rocket	Programación de Sistemas	API full-stack con framework Rocket y SQLx
Interrupciones de Hardware y XDP	Internos de Linux	Entendiendo tormentas de interrupciones
Blindando Validadores con XDP	Seguridad Blockchain	Mitigación de DoS a nivel de kernel con Rust