Escritorio nativo vs Docker vs Kubernetes para pipelines de datos ML on-premise

Cuando un proveedor de servicios gana un engagement de preparación de datos empresarial, la primera decisión técnica no es qué modelo usar ni cómo estructurar el esquema de etiquetado. Es cómo se despliegan las herramientas en la infraestructura del cliente.

Esta decisión tiene efectos en cascada: en la línea de tiempo (días vs. semanas de configuración), en quién puede operar las herramientas (solo ingenieros de ML vs. también expertos de dominio), en la postura de seguridad (superficie de ataque) y en si el equipo de TI del cliente aprobará el despliegue.

Tres modelos de despliegue dominan el panorama de preparación de datos on-premise. Cada uno hace diferentes concesiones.

---

Aplicaciones de escritorio nativas

Una aplicación de escritorio nativa se instala como cualquier otro programa en la máquina objetivo. En macOS, es un .dmg o .app. En Windows, un instalador .msi o .exe. En Linux, un .deb, .rpm o AppImage.

Complejidad de instalación

Mínima. Descarga el instalador, ejecútalo, lanza la aplicación. Todo el proceso toma 2-10 minutos. No se requiere software previo más allá del sistema operativo (y drivers de GPU, si se necesita inferencia por GPU).

Carga operativa

Cercana a cero. La aplicación gestiona su propio directorio de datos, configuración y ciclo de vida del proceso. Las actualizaciones son a nivel de aplicación: descarga la nueva versión e instálala sobre la existente. No hay daemon que monitorear, no hay registro de contenedores que mantener, no hay clúster que mantener saludable.

Superficie de seguridad

Pequeña. La aplicación se ejecuta como un solo proceso en espacio de usuario. No escucha en puertos de red (a menos que la inferencia LLM local use localhost). No hay servidor web, no hay capa de autenticación, no hay API expuesta a la red. La superficie de ataque es el binario de la aplicación y su directorio de datos.

Compatibilidad con redes aisladas

Nativa. Después de la instalación, la aplicación no requiere conectividad de red. Los pesos de modelos para inferencia LLM local pueden transferirse vía USB o medios aprobados. La aplicación no tiene requisito de "phone home".

Accesibilidad para expertos de dominio

Alta. Un oficial de cumplimiento, revisor legal o codificador médico puede instalar y usar una aplicación de escritorio nativa sin soporte DevOps. Esto importa porque la calidad de la preparación de datos depende de la experiencia de dominio, no de la experiencia en ML.

Acceso a hardware

Directo. La aplicación accede a CPU, GPU y NPU a través de las APIs nativas del sistema operativo. Sin capa de virtualización, sin configuración de passthrough. La memoria GPU está completamente disponible para la aplicación.

Gestión de actualizaciones

Actualizaciones estándar de aplicación. En entornos de red aislada, las actualizaciones se entregan vía medios físicos o sistemas internos de distribución de software.

---

Contenedores Docker

Las herramientas basadas en Docker se distribuyen como una o más imágenes de contenedor, típicamente orquestadas con Docker Compose. Label Studio, por ejemplo, se distribuye como una imagen Docker con un contenedor PostgreSQL separado para metadatos.

Complejidad de instalación

Moderada. Los prerrequisitos incluyen Docker Engine (o Docker Desktop), Docker Compose y, para cargas de trabajo con GPU, el NVIDIA Container Toolkit con drivers compatibles. En sistemas Linux empresariales, esto a menudo significa coordinar con el equipo de TI para la instalación de paquetes y configuración del daemon Docker.

Tiempo total de configuración: 1-4 horas para un despliegue directo, más cuando la configuración de proxy corporativo, mirrors de registro o problemas de drivers complican las cosas.

Carga operativa

Media. Los contenedores Docker necesitan monitoreo — ¿están corriendo? ¿Han consumido demasiada memoria? ¿El montaje de volumen está configurado correctamente? Los reinicios de Docker Compose manejan la recuperación básica, pero la gestión de estado persistente (volúmenes, bind mounts) requiere atención.

Las actualizaciones del daemon Docker a veces rompen la compatibilidad de contenedores. Las actualizaciones del NVIDIA Container Toolkit a veces rompen el acceso a GPU. Estos no son problemas diarios, pero aparecen en los peores momentos.

Superficie de seguridad

Mayor que escritorio nativo. Docker introduce varios componentes: el daemon Docker (ejecutándose como root), networking de contenedores, puertos expuestos y montajes de volumen. Cada uno es un vector de ataque potencial. Las vulnerabilidades de escape de contenedor, aunque raras, son una preocupación real para organizaciones conscientes de la seguridad.

Muchos equipos de seguridad empresarial requieren una revisión de las imágenes Docker, sus capas base y cualquier exposición de red antes de aprobar el despliegue.

Compatibilidad con redes aisladas

Posible pero difícil. El despliegue Docker en redes aisladas requiere:

1. Pre-descargar todas las imágenes de contenedor en una máquina con internet
2. Guardar imágenes como tarballs (docker save)
3. Transferir tarballs a la máquina objetivo vía medios aprobados
4. Cargar imágenes (docker load)
5. Asegurar que todas las dependencias de runtime (pesos de modelo, configuración) estén incluidas

Este proceso frecuentemente falla debido a capas de imagen faltantes, dependencias de runtime faltantes (como archivos de modelo que se descargan al inicio del contenedor) o incompatibilidades entre versiones de Docker Engine.

Accesibilidad para expertos de dominio

Baja. Los usuarios no técnicos no pueden auto-servirse con despliegues Docker. Incluso ejecutar la herramienta requiere entendimiento de comandos Docker o un script wrapper. La solución de problemas (crashes de contenedor, problemas de volumen, conflictos de puertos) requiere experiencia en Docker.

Acceso a hardware

Indirecto. El acceso a GPU requiere el NVIDIA Container Toolkit y configuración adecuada de passthrough de dispositivo. La memoria GPU disponible dentro del contenedor puede ser menor que la capacidad total del host dependiendo de la configuración. El acceso a NPU desde dentro de contenedores tiene soporte deficiente en 2026.

Gestión de actualizaciones

Descargar nuevas imágenes, reiniciar contenedores. En entornos de red aislada, esto repite todo el proceso de transferencia de imágenes.

---

Orquestación Kubernetes

Los despliegues en Kubernetes se usan típicamente cuando múltiples equipos necesitan acceso concurrente a herramientas de preparación de datos, o cuando la herramienta es parte de una plataforma ML más grande.

Complejidad de instalación

Alta. Un clúster Kubernetes requiere ya sea un servicio gestionado (que es nube, no on-premise) o un despliegue autogestionado usando kubeadm, k3s o una distribución comercial. Kubernetes on-premise también necesita un aprovisionador de almacenamiento (Rook-Ceph, Longhorn o NFS), un balanceador de carga (MetalLB para bare metal) y un controlador de ingress.

La programación de GPU requiere el NVIDIA GPU Operator o configuración manual del plugin de dispositivo. Configurar time-slicing de GPU o MIG (Multi-Instance GPU) agrega más complejidad.

Tiempo total de configuración: días a semanas, dependiendo de la experiencia del equipo con Kubernetes y el proceso de gestión de cambios de la organización.

Carga operativa

Alta. Los clústeres Kubernetes requieren mantenimiento continuo: actualizaciones de nodos, rotación de certificados, gestión de almacenamiento, monitoreo (stack Prometheus/Grafana), agregación de logs y respaldo. Un equipo dedicado de ingeniería de plataforma es la norma, no la excepción.

Superficie de seguridad

Grande. Kubernetes introduce servidores API, etcd, kubelet, runtime de contenedor, networking de pods, service mesh (si se usa), ingress y configuración RBAC. Cada componente es una vulnerabilidad potencial. El endurecimiento de seguridad de Kubernetes es una disciplina en sí misma.

Compatibilidad con redes aisladas

Muy difícil. Kubernetes en redes aisladas requiere:

1. Todas las imágenes de contenedor pre-cargadas en un registro local
2. Un registro local ejecutándose en la red aislada
3. Charts Helm o manifiestos modificados para apuntar al registro local
4. Todas las imágenes de operadores y dependencias pre-cargadas
5. Gestión de certificados sin acceso a CA externa

Las organizaciones que ejecutan exitosamente Kubernetes en redes aisladas típicamente tienen equipos de plataforma dedicados con experiencia profunda en Kubernetes.

Accesibilidad para expertos de dominio

Muy baja. Los usuarios finales acceden a la herramienta a través de un navegador, lo cual está bien. Pero el despliegue, mantenimiento y solución de problemas son enteramente dominio de ingenieros de plataforma.

Acceso a hardware

Gestionado por el clúster. El acceso a GPU requiere el plugin de dispositivo NVIDIA, con solicitudes/límites de recursos especificados por pod. Configuraciones multi-GPU necesitan programación cuidadosa para evitar contención de recursos. La memoria GPU se gestiona a nivel de pod.

Gestión de actualizaciones

Actualizaciones de charts Helm o redespliegue de manifiestos. En entornos de red aislada, esto significa actualizar el registro local con nuevas imágenes antes de actualizar.

---

Resumen comparativo

---

Quién necesita qué

Preparación de datos de un solo usuario (la mayoría de los engagements empresariales)

La realidad de la preparación de datos empresarial: la mayoría de los proyectos involucran 1-3 personas preparando datos para un caso de uso específico. Un proveedor de servicios envía un ingeniero de ML y un experto de dominio (o capacita al experto de dominio del cliente) para etiquetar, limpiar y aumentar datos para un proyecto de fine-tuning.

Para este escenario, escritorio nativo es el modelo de despliegue correcto. La configuración es instantánea. El experto de dominio puede trabajar independientemente. La operación en red aislada viene integrada. No hay infraestructura que mantener después de que el engagement termina.

Colaboración de equipo pequeño (3-10 personas)

Cuando múltiples personas necesitan trabajar en el mismo dataset concurrentemente — por ejemplo, un equipo de anotadores etiquetando diferentes subconjuntos — las opciones son:

• Escritorio nativo con almacenamiento compartido: Cada usuario ejecuta la aplicación localmente, leyendo y escribiendo en un montaje NFS o SMB compartido. Simple pero requiere coordinación de bloqueo de archivos y asignación de tareas.
• Despliegue Docker: Una instancia centralizada a la que los miembros del equipo acceden vía navegador. Funciona bien cuando la organización ya tiene infraestructura Docker. Agrega carga de despliegue pero proporciona estado centralizado.

Escala empresarial multiequipo (más de 10 usuarios concurrentes)

Cuando una organización ejecuta múltiples proyectos de preparación de datos simultáneamente, con equipos dedicados para cada uno, Kubernetes se vuelve relevante. El equipo de plataforma aprovisiona namespaces por proyecto, gestiona la programación de GPU entre equipos y proporciona monitoreo centralizado.

Este es el caso de uso para el que Kubernetes fue diseñado. Pero también es el escenario más raro en preparación de datos. La mayoría de las organizaciones no ejecutan 10 proyectos concurrentes de preparación de datos.

---

Las herramientas en la práctica

Varias herramientas populares de preparación de datos ilustran estas concesiones de modelo de despliegue:

Label Studio: Se distribuye como imagen Docker. Requiere Docker Compose para el stack completo (aplicación + PostgreSQL). El despliegue en red aislada requiere pre-descargar imágenes y asegurar que la base de datos se inicialice correctamente sin acceso de red. Los usuarios no técnicos no pueden desplegarlo independientemente.

IBM Data Prep Kit: Toolkit basado en Python. Requiere un entorno Python (o Docker) y a menudo dependencias adicionales para componentes específicos del pipeline. No es una aplicación independiente; es una biblioteca que los ingenieros integran en pipelines personalizados.

Prodigy: Basado en Python pero se ejecuta como un servidor web local en la máquina del usuario. Más cercano al modelo de escritorio nativo en la práctica, aunque la instalación aún requiere gestión del entorno Python.

Ertas Data Suite: Aplicación de escritorio nativa construida con Tauri 2.0. Se instala como una aplicación estándar sin prerrequisitos más allá de los drivers de GPU para inferencia acelerada. Los cinco módulos del pipeline (Ingest, Clean, Label, Augment, Export) se ejecutan enteramente en la máquina local con integración opcional de Ollama/llama.cpp para etiquetado asistido por IA.

---

Tomando la decisión

Empieza con el modelo de despliegue más simple que cumpla tus requisitos reales — no los requisitos que podrías tener en el futuro. Para la mayoría de los engagements de preparación de datos empresarial, una aplicación de escritorio nativa en una estación de trabajo con una GPU decente es la respuesta correcta. Se despliega en minutos, opera en entornos de red aislada sin modificación y da a los expertos de dominio acceso directo a las herramientas que necesitan.

Docker se vuelve relevante cuando necesitas acceso centralizado para un equipo pequeño. Kubernetes se vuelve relevante cuando estás operando a escala de plataforma. La mayoría de los proyectos de preparación de datos nunca alcanzan ninguno de esos umbrales.

La ruta más rápida a datos preparados es la que tiene menos obstáculos de despliegue entre tu equipo y el trabajo real.