Arquitectura de Runtime On-Premise para Preparación de Datos de IA Empresarial

La mayoría de los proyectos empresariales de IA dedican entre el 60 y el 80% de su cronograma a la preparación de datos. Ingesta, limpieza, etiquetado, augmentación, exportación: estos pasos ocurren antes de que comience una sola ejecución de entrenamiento. Para las organizaciones en industrias reguladas, este trabajo debe realizarse en infraestructura que ellas controlan.

La arquitectura que elijas para la preparación de datos on-premise determina tu rendimiento, tu complejidad operativa y si los expertos de dominio pueden realmente usar las herramientas sin la asistencia de un ingeniero de ML. Esta guía cubre los modelos de despliegue, los requisitos de cómputo y los patrones de infraestructura que funcionan en la práctica.

Modelo de Despliegue: La Primera Decisión

Tres enfoques de despliegue dominan las herramientas de preparación de datos on-premise:

Aplicaciones de Escritorio Nativas

La aplicación se instala como cualquier otro programa. Se ejecuta como un proceso local con acceso directo a CPU, GPU y sistema de archivos. Sin contenedores, sin capa de orquestación, sin servidor web. La instalación toma minutos. Las actualizaciones son a nivel de aplicación: descargar e instalar.

Ventajas: Cero overhead de DevOps. Los expertos de dominio pueden instalar y ejecutar la herramienta por sí mismos. La operación air-gapped viene integrada: la aplicación funciona completamente offline después de la instalación. El acceso directo al hardware significa que la inferencia GPU no pasa por una capa de virtualización.

Limitaciones: Alcance de una sola máquina. Escalar a un equipo requiere almacenamiento compartido o coordinación fuera de la herramienta.

Contenedores Docker

La herramienta se distribuye como una o más imágenes de contenedor. El despliegue requiere Docker (o Podman), y las herramientas complejas a menudo necesitan Docker Compose u orquestación similar. El acceso a GPU requiere NVIDIA Container Toolkit y configuración adecuada de controladores.

Ventajas: Entornos reproducibles. Comportamiento consistente en diferentes sistemas operativos host. Modelo de despliegue familiar para equipos de DevOps.

Limitaciones: El passthrough de GPU agrega complejidad de configuración. Docker en sí es una superficie de seguridad. El despliegue air-gapped requiere pre-descargar imágenes y todas las dependencias, un proceso que a menudo falla por capas faltantes o dependencias de runtime. Los expertos de dominio no pueden autoservirse; necesitan soporte de ingeniería para despliegue y resolución de problemas.

Aplicaciones Web Auto-Alojadas (con o sin Kubernetes)

La herramienta se ejecuta como un servicio web, típicamente detrás de Nginx o Traefik. Los despliegues con Kubernetes agregan descubrimiento de servicios, escalado y monitoreo de salud.

Ventajas: Acceso multiusuario a través de un navegador. Recursos de cómputo centralizados. Kubernetes permite autoescalado para cargas de trabajo por lotes.

Limitaciones: Mayor complejidad operativa. Requiere networking, configuración de TLS, autenticación y gestión continua del clúster. La programación de GPU en Kubernetes requiere el plugin de dispositivo NVIDIA y cuotas de recursos cuidadosas. Los despliegues air-gapped de Kubernetes son notoriamente difíciles.

Requisitos de Cómputo por Etapa del Pipeline

La preparación de datos no es una carga de trabajo única. Cada etapa tiene características de cómputo diferentes:

Ingesta

Principalmente limitada por I/O. El cuello de botella es leer documentos del disco o almacenamiento en red: parseo de PDF, decodificación de imágenes, extracción de texto. El almacenamiento SSD importa más que la velocidad de CPU aquí. Un disco NVMe moderno puede leer a 3-7 GB/s, mientras que un disco mecánico alcanza un máximo de 100-200 MB/s. Para archivos de documentos grandes, esta diferencia se mide en horas.

El uso de CPU durante la ingesta es moderado. La mayoría de los formatos (PDF, DOCX, HTML) usan bibliotecas de parseo de un solo hilo, así que más núcleos solo ayudan al procesar muchos archivos en paralelo.

Requisito típico: 4+ núcleos de CPU, 16 GB de RAM, SSD NVMe.

OCR (Reconocimiento Óptico de Caracteres)

Intensivo en CPU o acelerado por GPU según el motor. Tesseract se ejecuta en CPU y procesa aproximadamente 1-3 páginas por segundo. Los motores de OCR acelerados por GPU (PaddleOCR, EasyOCR) pueden alcanzar 10-30 páginas por segundo en una GPU de gama media.

Para archivos de documentos escaneados, el OCR suele ser la etapa más lenta del pipeline. Un archivo de 100,000 páginas a 2 páginas/segundo toma aproximadamente 14 horas con OCR solo en CPU.

Requisito típico: GPU recomendada (8+ GB de VRAM), 32 GB de RAM para procesamiento por lotes.

Limpieza y Deduplicación

Limitada por CPU y memoria. La deduplicación en datasets grandes requiere mantener hashes de similitud en memoria. La deduplicación exacta en 1 millón de documentos es sencilla; la deduplicación difusa (MinHash, SimHash) a escala requiere RAM significativa.

La detección y redacción de PII agrega carga de CPU. La detección de PII basada en regex es rápida; la detección basada en NER (usando un modelo de lenguaje pequeño) es más lenta pero más precisa.

Requisito típico: 8+ núcleos de CPU, 32-64 GB de RAM según el tamaño del dataset.

Etiquetado con LLM Local

Intensivo en GPU cuando se usa etiquetado asistido por IA. Un modelo de 7B parámetros en cuantización Q4 requiere aproximadamente 4-5 GB de VRAM y puede procesar 20-50 documentos por minuto para tareas de clasificación. Un modelo de 14B en Q4 necesita 8-10 GB de VRAM y funciona a aproximadamente la mitad de velocidad.

El etiquetado manual tiene demanda de CPU trivial: el cuello de botella es la velocidad humana, no el cómputo.

Requisito típico: GPU con 8+ GB de VRAM (16 GB preferible), 32 GB de RAM del sistema.

Augmentación y Generación Sintética

Similar al etiquetado: limitada por GPU cuando se usan LLMs locales para generación de datos sintéticos. Las salidas más largas (generar documentos sintéticos vs. generar etiquetas) aumentan el tiempo de GPU por elemento. La generación de documentos sintéticos de 500 palabras en 7B Q4 produce aproximadamente 5-15 documentos por minuto según el hardware.

Requisito típico: GPU con 8-16 GB de VRAM, 32 GB de RAM del sistema.

Exportación

Limitada por I/O. Convertir datos procesados a formatos de entrenamiento (JSONL, Parquet, datasets de HuggingFace) está limitado por la velocidad de escritura. La compresión agrega carga de CPU. La exportación de 100 GB de datos procesados toma 10-30 minutos en NVMe, más en HDD.

Requisito típico: SSD NVMe, 16 GB de RAM, CPU moderada.

Tres Niveles de Hardware

No todos los proyectos de preparación de datos necesitan la misma infraestructura. Esto es lo que funciona en cada escala:

Nivel 1: Ligero (Solo CPU, Menos de 100 GB de Datos)

Hardware: Estación de trabajo moderna o laptop. 8+ núcleos, 32 GB de RAM, 1 TB SSD NVMe.
Costo: $1,500-$3,000
Caso de uso: Conjuntos de documentos pequeños, datos con mucho texto, flujos de etiquetado manual
Inferencia LLM: Solo CPU vía llama.cpp. Más lento (2-5 tokens/segundo para modelos 7B) pero funcional para pre-anotación de lotes pequeños.
OCR: Solo CPU con Tesseract. Adecuado para menos de 10,000 páginas.

Este nivel maneja proyectos de prueba de concepto y preparación de datos de producción a pequeña escala. Muchos compromisos empresariales comienzan aquí.

Nivel 2: Gama Media (Acelerado por GPU, 100 GB-1 TB)

Hardware: Estación de trabajo con GPU dedicada. 16+ núcleos, 64 GB de RAM, 2 TB NVMe, NVIDIA RTX 4070/4080 (12-16 GB de VRAM) o equivalente.
Costo: $5,000-$10,000
Caso de uso: Preparación de datos de producción, etiquetado asistido por IA, augmentación sintética
Inferencia LLM: Acelerada por GPU vía Ollama o llama.cpp. 30-80 tokens/segundo para 7B Q4. Suficientemente rápido para flujos de etiquetado interactivo.
OCR: Acelerado por GPU. 10-30 páginas/segundo.

Este es el nivel de trabajo pesado. Una sola estación de trabajo en este nivel maneja las necesidades de preparación de datos de la mayoría de los proyectos empresariales de IA, incluyendo los que los clientes asumen que necesitan un clúster de GPUs.

Nivel 3: Pesado (Multi-GPU, 1 TB+)

Hardware: Servidor o estación de trabajo de gama alta con 2-4 GPUs. 32+ núcleos, 128-256 GB de RAM, 4+ TB NVMe (o NVMe RAID), NVIDIA RTX 4090 o A6000 (24-48 GB de VRAM por GPU).
Costo: $20,000-$50,000
Caso de uso: Preparación de datos empresarial a gran escala, etapas de pipeline concurrentes, inferencia de modelos 14B+
Inferencia LLM: Multi-GPU permite modelos más grandes (30B+) o inferencia paralela en múltiples datasets.
OCR: Optimizado por lotes con aceleración GPU. Procesa archivos de más de 100,000 páginas durante la noche.

La mayoría de las organizaciones descubren que no necesitan este nivel para preparación de datos. El error común: "Tenemos 2 TB de documentos, así que necesitamos un clúster masivo de GPUs." En la práctica, la preparación de datos procesa documentos secuencialmente o en lotes pequeños. Los 2 TB pasan por una estación de trabajo de gama media en días, no minutos, y ese cronograma generalmente está bien porque la preparación de datos es una tarea puntual o periódica, no un servicio en tiempo real.

Arquitectura de Inferencia LLM Local

La inferencia LLM local es el componente que más cambia el flujo de trabajo de preparación de datos. En lugar de enviar documentos a una API en la nube, el modelo se ejecuta en la misma máquina (o una máquina en la misma red) que la herramienta de preparación de datos.

Los dos backends de inferencia principales:

Ollama: Gestiona descargas de modelos, variantes de cuantización y asignación de GPU. Proporciona una API compatible con OpenAI en localhost. Fácil de configurar; buena biblioteca de modelos. El overhead es mínimo: Ollama agrega una capa HTTP delgada sobre llama.cpp.

llama.cpp: Inferencia directa sin la capa HTTP. Ligeramente más complejo de configurar pero ofrece control más fino sobre asignación de memoria, tamaño de lote y threading. Preferido en entornos air-gapped donde el registro de modelos de Ollama es inalcanzable.

Ambos soportan formatos de modelo GGUF. Para tareas de preparación de datos (clasificación, extracción de entidades, pre-anotación) los modelos de seguimiento de instrucciones en el rango de 7B-14B proporcionan el mejor equilibrio de velocidad y precisión. Los modelos más grandes (30B+) raramente mejoran la calidad del etiquetado lo suficiente como para justificar la reducción de rendimiento.

Arquitectura de Almacenamiento

La preparación de datos implica leer grandes volúmenes de datos fuente, escribir resultados intermedios y producir salidas finales. El I/O de almacenamiento es un cuello de botella en cada etapa.

Datos fuente: Almacenar en el medio más rápido disponible. SSD NVMe es preferible. Si los datos fuente residen en almacenamiento en red (NFS, SMB), copiarlos a SSD local antes de procesar. La latencia de I/O de red se acumula a través de millones de lecturas de archivos.

Datos intermedios: Resultados de OCR, texto extraído, embeddings y salidas de procesamiento parcial. Estos pueden ser 2-5x el tamaño de los datos fuente. Asegurar suficiente capacidad de SSD local para el dataset intermedio completo.

Datos de salida: Datasets finales etiquetados, augmentados y exportados. Típicamente más pequeños que los datos intermedios pero aún significativos. Exportar directamente al destino (servidor de entrenamiento, almacenamiento compartido) cuando sea posible.

Regla general: Aprovisionar 3-5x el tamaño de tus datos fuente en capacidad NVMe local para una ejecución completa del pipeline.

Networking, o la Ausencia de Él

En entornos air-gapped, no hay red que configurar. La herramienta de preparación de datos, el LLM local y los datos residen todos en la misma máquina o en un segmento de red físicamente aislado. Esta es la arquitectura de red más simple posible, y para muchos entornos regulados, es un requisito.

Para despliegues on-premise conectados, las consideraciones de red son mínimas para preparación de datos de un solo usuario. Si varios miembros del equipo necesitan acceder a resultados, un montaje NFS/SMB compartido o un mecanismo simple de sincronización de archivos es suficiente. Las herramientas de preparación de datos no necesitan mallas de servicios complejas, balanceadores de carga ni controladores de ingreso.

Arquitectura de Escritorio Nativa en la Práctica

Ertas Data Suite adopta el enfoque de escritorio nativo para este problema. Construido con Tauri 2.0 (backend Rust, frontend React), se instala como una aplicación de escritorio estándar y se ejecuta completamente en la máquina local. Los cinco módulos del pipeline (Ingest, Clean, Label, Augment, Export) comparten un almacén de datos local común y acceden al hardware de CPU, GPU y NPU directamente a través del sistema operativo.

La inferencia LLM local se integra a través de Ollama o llama.cpp, ejecutándose en la misma máquina. No hay salto de red entre la interfaz de etiquetado y el modelo: la aplicación se comunica con el backend de inferencia a través de localhost.

Esta arquitectura elimina la complejidad de despliegue que hace que herramientas como Label Studio (Docker/Docker Compose) e IBM Data Prep Kit (entorno Python + Docker) sean inaccesibles para expertos de dominio. Un oficial de cumplimiento o experto en la materia puede instalar la aplicación, abrir un dataset y comenzar a etiquetar sin esperar a que un ingeniero de ML configure la infraestructura.

Elegir Tu Arquitectura

La matriz de decisión es más simple de lo que los proveedores hacen parecer:

Factor	Escritorio Nativo	Docker	Kubernetes
Usuarios	1-3	3-10	10+
Tiempo de configuración	Minutos	Horas	Días
Overhead operativo	Ninguno	Bajo-Medio	Alto
Compatible con air-gap	Sí	Posible	Difícil
Acceso de expertos de dominio	Directo	Necesita soporte	Necesita soporte
Acceso a GPU	Directo	Passthrough	Plugin de dispositivo

Para la mayoría de los proveedores de servicios que entregan soluciones de IA a clientes empresariales, la fase de preparación de datos involucra 1-3 personas trabajando en un dataset definido. El modelo de escritorio nativo maneja esto. Kubernetes se vuelve relevante cuando ejecutas una plataforma compartida de preparación de datos para múltiples proyectos concurrentes, lo cual es un problema diferente a preparar datos para un compromiso específico.

Guías Relacionadas

Este artículo es el eje del Pilar 4: Runtime On-Premise e Infraestructura para Preparación de Datos. Para una cobertura más profunda de temas específicos:

Modelos de despliegue: Native Desktop vs Docker vs Kubernetes for On-Premise ML Data Pipelines
Selección de hardware: Hardware Sizing for On-Premise Data Preparation
Ajuste de LLM local: Optimizing Local LLM Inference for Data Labeling and Augmentation
Procesamiento por lotes: Batch Processing Large Document Archives On-Premise
Ollama air-gapped: Running Ollama in Air-Gapped Enterprise Environments
Benchmarks de rendimiento: On-Premise Data Prep Pipeline Throughput Benchmarks

La arquitectura de runtime que selecciones afecta cada decisión posterior: adquisición de hardware, flujo de trabajo del equipo, cronogramas de entrega al cliente y costo operativo continuo. Define primero el modelo de despliegue correcto, luego optimiza dentro de él.