Marie tiene el cuaderno que “funciona en casa”. Thomas lo abre: el kernel falla: memoria insuficiente, versión diferente de pandas, ruta codificada /Users/marie/.... El CTO descubre la exportación de un cliente en un repositorio público de Git. Jupyter como equipo no envía un archivo .ipynb a través de Slack: es una plataforma con identidad, recursos y gobernanza.
Un portátil local con 32 GB de RAM no es una infraestructura de equipo. Tan pronto como tres personas comparten datos, GPU o entornos regulados, la autenticación debe centralizarse, los recursos aislados y el acceso rastreado. Si se implementa incorrectamente, JupyterHub se convierte en un VPS donde todos tienen los mismos derechos. Bien desplegado, es el puente entre los oleoductos de exploración y producción.
Arquitectura mínima viable
La configuración de un equipo se basa en algunos componentes no negociables:
| Componente | Rol |
|---|---|
| JupyterHub | Conexión SSO/LDAP, lanzamiento de un cuaderno por usuario |
| generador | Docker o Kubernetes: imagen reproducible |
| Almacenamiento persistente | Espacio por usuario o por proyecto, no solo disco efímero |
| Secretos | Variables de entorno seguras o inyectadas: nunca claves API en el cuaderno |
| Cuota de recursos | Máximo CPU, RAM, GPU por usuario o grupo |
El alojamiento varía según la carga: VPS sólido para exploración de CPU, máquina GPU para capacitación (consulte alquiler de GPU) o Kubernetes si el equipo ya domina la orquestación. Compare ofertas con acceso a GPU y regiones de la UE a través del directorio y la comparación.
Compartir sin fugas de datos
Versione los cuadernos en Git, pero elimine las salidas antes de cada confirmación (nbstripout o enlace previo a la confirmación). Una computadora portátil exportada con datos de clientes en texto plano en una celda es una fuga de GDPR a punto de ocurrir.
Limite el acceso a los datos: roles de solo lectura en bases de datos de producción, vistas anónimas, sin volcado completo "para pruebas". Deshabilite la descarga masiva si los datos son confidenciales; registrar exportaciones con marca de tiempo e identidad de usuario.
Elimine los núcleos inactivos ("idle culler") para liberar GPU y RAM: una computadora portátil olvidada y abierta desde el viernes no debería bloquear la cola del equipo.
Para los LLM internos, no mezcle mensajes confidenciales y cuadernos compartidos; consulte alojar un LLM.
Errores comunes que aceleran la TI en la sombra
En casi todas las autopsias se repiten cuatro patrones:
- Una única cuenta SSH compartida: el mismo problema que acceso del equipo SFTP: nadie es responsable, todos son root.
- Notebook = producción: un cron que ejecuta un
.ipynbno probado por la noche reemplaza una canalización no observable. - GPU encendida las 24 horas del día para exploración de pandas que solo usa la CPU.
- Sin copia de seguridad del directorio de usuarios en un único disco local.
Cada uno de estos errores se puede corregir sin prohibir Jupyter, aplicando los mismos requisitos que a una API: identidad, registros, límites.
GPU, cuotas y coste controlado
Rara vez se necesita una GPU por científico de datos. JupyterHub programa trabajos, aplica cuotas por grupo y libera el recurso después de la inactividad. Reserve costosas instancias de GPU para un entrenamiento intenso; La minería de datos (EDA) suele funcionar muy bien en la CPU.
Para entrenamiento intensivo, instancias puntuales o bajo demanda, complete el Hub sin inmovilizar el equipo las 24 horas del día. Documente quién puede iniciar un trabajo de GPU, durante cuánto tiempo y cómo alertar si la cola supera un umbral.
La cumbre: Jupyter compartido sin gobernanza = TI en la sombra acelerada
Esto es lo que el entusiasmo por los cuadernos olvida formalizar.
Compare hosts con acceso a GPU y alojamiento en la región de la UE en el directorio antes de comprar hardware "para Jupyter".
Decide y avanza sin puntos ciegos
Antes de comprar una GPU o implementar un Hub:
- Cuente cuántas notebooks deben ejecutarse simultáneamente, con qué datos y con qué trazabilidad.
- Elija JupyterHub + Docker tan pronto como tres usuarios de datos habituales compartan recursos o datos regulados.
- Corregir una imagen base bloqueada y una política de Git (resultados eliminados antes de la confirmación).
- Configurar cuotas de CPU/RAM/GPU y apagado automático de núcleos inactivos.
- Audite el acceso a los datos como con cualquier sistema confidencial: registros, roles, región de la UE.
- Pruebe la restauración del almacenamiento persistente del usuario antes de confirmar conjuntos de datos críticos.
Sin una respuesta clara a la primera pregunta, se está financiando el caos, no la ciencia.
Preguntas frecuentes
¿JupyterLab local o JupyterHub alojado?
Espacio para la exploración en solitario. Centro alojado tan pronto como varias personas comparten GPU, datos regulados o necesidad de trazabilidad; de lo contrario, todos copian los archivos CSV por correo electrónico y las versiones divergen en una semana.
¿Cómo evitar que un cuaderno sobrescriba la producción?
Entornos separados (datos provisionales), acceso a bases de datos de solo lectura de forma predeterminada, secretos que no son del portátil (variables de entorno seguras), revisión obligatoria antes de cualquier trabajo planificado en cron.
¿Necesita una GPU por científico de datos?
Casi nunca. Programación de concentradores, cuotas de GPU, instancias puntuales para entrenamiento intenso: la CPU es suficiente para la mayor parte de la extracción de datos. Consulte nuestra guía alquiler de GPU.
Notebooks y GDPR: ¿qué precauciones?
No hay datos personales claros en las celdas exportadas, registros de acceso, alojamiento en la región de la UE, eliminación de resultados cometidos por error en Git. Trate un cuaderno como un documento confidencial, no como un borrador desechable.
Antes de comprar una GPU “para Jupyter”, pregunte: ¿cuántas portátiles deben funcionar al mismo tiempo, con qué datos, con qué rastro? Sin una respuesta, estás financiando el caos, no la ciencia.