Compatibilidad inversa con LFS

Las cargas realizadas desde clientes heredados o no compatibles con Xet siguen el camino estándar de Git LFS, incluso si el repositorio ya está respaldado por Xet. Una vez que el archivo se carga en LFS, un proceso en segundo plano migra automáticamente el archivo para que utilice el almacenamiento de Xet. La arquitectura de Xet ofrece compatibilidad hacia atrás para los clientes heredados que descargan archivos de repositorios respaldados por Xet mediante un puente de Git LFS. Mientras que un cliente compatible con Xet recibirá información de reconstrucción de archivos desde CAS para descargar el archivo respaldado por Xet, un cliente heredado obtendrá una única URL del puente que realiza el trabajo de reconstruir el archivo solicitado y devolver la URL del recurso. Esto permite descargar archivos a través de una URL, de modo que puedas seguir utilizando la interfaz web de Hub o curl. Al migrar automáticamente las cargas de archivos de LFS y permitir que los clientes más antiguos sigan descargando archivos de repositorios respaldados por Xet, los mantenedores y el resto de Hub pueden actualizar sus pipelines a su propio ritmo.

El almacenamiento Xet ofrece una transición sin problemas para los repositorios existentes del Hub. No es necesario saber si el backend de Xet está involucrado. Los repositorios respaldados por Xet continúan utilizando el formato de archivo de puntero de Git LFS; la adición del Xet backed hash solo se muestra en la interfaz web como una comodidad. En la práctica, esto significa que los repositorios existentes y los recién creados no se verán de manera diferente si se realiza un bare clone de ellos. Cada uno de los archivos grandes (o binarios) continuará teniendo un archivo de puntero que cumple con la especificación de archivo de puntero de Git LFS.

Esta simetría permite que los clientes no compatibles con Xet (por ejemplo, versiones anteriores de huggingface_hub) interactúen con repositorios respaldados por Xet sin preocupaciones. De hecho, dentro de un repositorio se admite una mezcla de archivos respaldados por Git LFS y Xet. El backend de Xet indica si un archivo está en el almacenamiento de Git LFS o de Xet, lo que permite a los servicios downstream solicitar las URL(s) adecuadas desde S3, independientemente de qué sistema de almacenamiento contenga el contenido.

Almacenamiento heredado: Git LFS

El sistema de almacenamiento heredado en el Hub, Git LFS, utiliza muchas de las mismas convenciones que los repositorios respaldados por Xet. El backend de Git LFS del Hub es Amazon Simple Storage Service (S3). Cuando se invoca Git LFS, almacena el contenido de los archivos en S3 utilizando el hash SHA256 para nombrar el archivo y permitir su acceso futuro. Esta arquitectura de almacenamiento es relativamente simple y ha permitido que el Hub almacene los archivos de millones de repositorios de modelos, conjuntos de datos y espacios.

La principal limitación de Git LFS es su enfoque centrado en archivos para la deduplicación. Cualquier cambio en un archivo, sin importar si es grande o pequeño, implica que se versiona el archivo completo, lo que genera un sobrecoste significativo en las transferencias de archivos, ya que se sube el archivo entero (si se realiza un commit en un repositorio) o se descarga (si se obtiene la última versión en tu máquina).

Esto conduce a una peor experiencia de desarrollo junto con una proliferación de almacenamiento adicional.

Update on GitHub