Automatizar la entrega de modelos HuggingFace a EFS en EKS
Un equipo busca una forma de cargar modelos de HuggingFace directamente a EFS sin intervención manual, ya que los servicios corren en EKS con volúmenes compartidos.
Problema
En un entorno con tres clústeres EKS y cuatro workloads, un equipo mantiene un único sistema de archivos EFS de ~3 GB que contiene snapshots de modelos de HuggingFace (bge‑small‑en‑v1.5, distiluse‑base‑multilingual‑cased‑v2, bge‑m3). Los pods se ejecutan con TRANSFORMERS_OFFLINE=1 y HF_DATASETS_OFFLINE=1, por lo que dependen exclusivamente de los archivos locales. La ausencia de una copia de respaldo y el hecho de que los servicios de inferencia montan el EFS con acceso de escritura, aunque solo leen, generan riesgo de fallos.
El flujo anterior consistía en:
- Subir la carpeta del modelo a S3.
- Conectarse a una instancia EC2 con EFS montado y copiar desde S3 al volumen.
- Migrar los servicios a EKS.
Con la desaparición de las instancias EC2, los pasos 2 y 3 ya no son posibles. El único camino disponible es que un científico de datos suba el modelo a S3 y un ingeniero de operaciones lo copie manualmente, proceso que puede tardar una semana.
Posibles soluciones exploradas
- AWS DataSync – Servicio sin código que sincroniza S3 a EFS con verificación de integridad. No se ha probado aún.
- CronJob de Kubernetes – Se usa con éxito para un volumen EFS distinto donde se escriben datos de referencia cada hora. La idea sería replicar la misma arquitectura para los modelos.
- Lambda con EFS – Eliminado por límite de 15 min, insuficiente para transferir un archivo de 2.1 GB.
- S3 CSI driver – Se descartó al no querer abandonar EFS.
- Mecanismo de directorios versionados y enlaces simbólicos atómicos – Escribir en una ruta temporal y cambiar el symlink con mv -T, similar a la forma en que Kubernetes monta ConfigMaps.
Próximos pasos
La propuesta actual es investigar la viabilidad de DataSync, ya que permite escribir en un directorio que no esté siendo leído y ofrece integridad de datos. Si se confirma, se podrá automatizar la transferencia de modelos sin intervención humana. En paralelo, se podría implementar el esquema de CronJob para la copia de modelos, con la ventaja de no requerir un pod adicional que mantenga el EFS en modo RW.
La solución elegida tendrá que equilibrar la velocidad de despliegue, la confiabilidad y el coste de operación. Una vez validada, se podrá integrar en la pipeline CI/CD para que cualquier nuevo snapshot de modelo sea copiado automáticamente al EFS y los pods lo consuman sin necesidad de reinicio ni intervención manual.
