Compatibilité ascendante avec LFS

Les téléversements effectués depuis des clients legacy ou non compatibles avec Xet suivent toujours le chemin standard de Git LFS, même si le dépôt est déjà basé sur Xet. Une fois le fichier téléversé dans LFS, un processus en arrière-plan migre automatiquement le fichier vers le stockage Xet. L’architecture Xet offre une compatibilité ascendante pour les clients legacy qui téléchargent des fichiers depuis des dépôts basés sur Xet, en fournissant un pont Git LFS. Alors qu’un client compatible avec Xet reçoit des informations de reconstruction de fichier depuis le CAS pour télécharger le fichier basé sur Xet, un client legacy reçoit une URL unique du pont, qui s’occupe de reconstruire le fichier demandé et de renvoyer l’URL vers la ressource. Cela permet de télécharger des fichiers via une URL, afin que vous puissiez continuer à utiliser l’interface web du Hub ou curl. En automatisant la migration des téléversements de fichiers LFS et en permettant aux clients plus anciens de continuer à télécharger des fichiers depuis des dépôts basés sur Xet, les mainteneurs et le reste du Hub peuvent mettre à jour leurs pipelines à leur propre rythme.

Le stockage Xet offre une transition transparente pour les dépôts Hub existants. Il n’est pas nécessaire de savoir si le backend Xet est impliqué. Les dépôts gérés par Xet continuent d’utiliser le format de fichier pointeur Git LFS ; l’ajout du Xet backed hash n’est ajouté à l’interface web que par commodité. Concrètement, cela signifie que les dépôts existants et les dépôts nouvellement créés n’auront pas l’air différents si vous effectuez un bare clone de ceux-ci. Chacun des fichiers volumineux (ou binaires) continuera d’avoir un fichier pointeur conforme à la spécification du fichier pointeur Git LFS.

Cette symétrie permet aux clients non compatibles avec Xet (par exemple, les anciennes versions de huggingface_hub) d’interagir avec les dépôts adossés à Xet sans souci. En effet, au sein d’un dépôt, un mélange de fichiers adossés à Git LFS et à Xet est pris en charge. L’arrière-plan Xet indique si un fichier est stocké dans Git LFS ou dans le stockage Xet, permettant ainsi aux services en aval de demander les URL appropriées depuis S3, quel que soit le système de stockage qui contient le contenu.

Stockage hérité : Git LFS

Le système de stockage legacy sur le Hub, Git LFS, utilise de nombreuses conventions similaires à celles des dépôts adossés à Xet. L’infrastructure Git LFS du Hub est Amazon Simple Storage Service (S3). Lorsque Git LFS est invoqué, il stocke le contenu des fichiers dans S3 en utilisant l’empreinte SHA256 pour nommer le fichier afin d’y accéder ultérieurement. Cette architecture de stockage est relativement simple et a permis au Hub de stocker les fichiers de millions de dépôts de modèles, de jeux de données et d’espaces.

La principale limitation de Git LFS est son approche centrée sur les fichiers pour la déduplication. Toute modification d'un fichier, quelle que soit son ampleur, entraîne la versionnage de l'intégralité du fichier, ce qui engendre des surcoûts importants lors des transferts de fichiers, l'ensemble du fichier étant téléversé (en cas d'engagement vers un dépôt) ou téléchargé (en cas de récupération de la dernière version sur votre machine).

Cela entraîne une expérience développeur dégradée ainsi qu'une prolifération du stockage supplémentaire.

Update on GitHub