IA ouverte et locale

Vérifiez si votre modèle Hugging Face fonctionne sur AWS Trainium

Un nouvel espace Hugging Face répertorie les modèles populaires qui fonctionnent sans modification sur AWS Trainium2, fournissant aux développeurs des scripts et des données de compatibilité.

Matériel de serveur connecté à un écran de liste de contrôle de compatibilité
Illustration générée pour cet article

Traduit automatiquement depuis l'original anglais.

Hugging Face a lancé un nouvel outil interactif pour aider les développeurs à déterminer si leurs modèles open source préférés sont compatibles avec le matériel AWS Trainium. Publié fin octobre 2026, cette ressource répond au besoin croissant de clarté concernant l'accélération matérielle pour les grands modèles de langage sur les puces personnalisées d'Amazon.

L'outil offre une visibilité immédiate sur les modèles du Hub Hugging Face pouvant s'exécuter sans modification de code sur les instances Trainium. Il sert de pont pratique entre la promesse abstraite de l'accélération matérielle et la réalité concrète de l'ingénierie de déploiement.

Ce qui s'est passé

Hugging Face a introduit un espace dédié nommé torch-neuronx model support pour cataloguer la compatibilité entre les modèles Transformer populaires et AWS Trainium. Cette initiative s'appuie sur la sortie antérieure de TorchNeuron, un backend PyTorch natif qui permet à la bibliothèque Transformers d'exécuter son code de modélisation standard directement sur les périphériques Trainium via le package torch-neuronx.

L'espace agrège les résultats de tests pour les modèles les plus téléchargés et les plus tendance du Hub. Il ne se contente pas de lister un support théorique, mais fournit des preuves empiriques de l'exécution. Pour chaque modèle testé, l'interface affiche s'il a réussi la validation, le nombre de cœurs Trainium requis pour le sharding, le temps total écoulé incluant la compilation, et l'utilisation maximale de la mémoire du périphérique.

Les utilisateurs peuvent naviguer dans les données via trois vues principales. La vue Selected présente une liste sélectionnée des meilleurs modèles choisis selon leur nombre de téléchargements et leurs scores de tendance. Les vues Trending et Downloads permettent aux utilisateurs de rechercher des modèles spécifiques par nom, en suivant les propres systèmes de classement du Hub. Si un modèle n'a pas été testé, l'interface explique pourquoi, citant des raisons telles qu'une faible priorité ou une incompatibilité réelle. L'outil permet également aux utilisateurs de filtrer les résultats par versions spécifiques du compilateur Neuron (neuronx-cc) et de la bibliothèque Transformers.

Comment cela fonctionne

Le mécanisme sous-jacent repose sur des pipelines de test automatisés qui chargent les modèles sur des instances trn2. Le système répartit les modèles sur le nombre minimum de cœurs Trainium nécessaire pour contenir les poids, utilisant généralement le parallélisme tensoriel. Pour les architectures mixture-of-experts qui ne disposent pas d'un plan de parallélisme tensoriel, le système emploie plutôt le parallélisme d'experts. Actuellement, les tests sont limités aux modèles tenant dans quatre périphériques Trainium2, soit un maximum de 16 cœurs.

La validation implique la génération de 32 jetons par le modèle. Sur les configurations mono-cœur, les jetons de sortie sont comparés directement à une exécution de référence sur CPU. Pour les modèles shardés, un petit modèle juge évalue la sortie pour garantir qu'elle constitue un anglais fluide. Un statut "PASS" confirme la correction fonctionnelle mais ne garantit pas des métriques de débit spécifiques ni des performances sur des séquences de génération plus longues.

Pour les développeurs prêts à déployer, l'espace fournit la pile logicielle exacte utilisée lors des tests. Il liste les packages requis et fournit un script run.py qui reproduit la recette officielle TorchNeuron. Ce script charge le modèle en utilisant from_pretrained, applique le sharding si nécessaire, et génère du texte en utilisant un cache statique avec torch.compile(backend="neuron"). Le script gère les rangs distribués en interne, supprimant le besoin de lanceurs externes comme torchrun.

Pour réduire la latence de démarrage, les développeurs peuvent contourner l'étape initiale de compilation du graphe. L'espace fournit des commandes pour synchroniser les graphes pré-compilés depuis un bucket de cache NEFF public hébergé sur Hugging Face. En faisant correspondre la version du compilateur, les utilisateurs peuvent charger ces artefacts mis en cache directement dans leur environnement local.

Détails clés

  • L'outil ne prend actuellement en charge que les tâches text-generation et image-text-to-text, avec des plans pour étendre le support aux diffusers et aux sentence transformers.
  • Les tests sont effectués sur des instances AWS Trainium2 (trn2), avec une limite maximale de 16 cœurs par modèle.
  • Chaque résultat de test inclut les versions spécifiques de neuronx-cc et de la bibliothèque Transformers utilisées, garantissant la reproductibilité.
  • Les données sous-jacentes sont disponibles sous forme de jeu de données public nommé aws-neuron/torch-neuronx-model-support, stocké au format Parquet.
  • Les graphes de compilation peuvent être récupérés depuis le bucket public hf://buckets/aws-neuron/torch-neuronx-neff-cache/ pour éviter les temps de compilation initiaux.
  • Un test réussi vérifie la correction de la sortie fonctionnelle mais ne mesure pas la vitesse d'inférence ni la stabilité sur contexte long.

Pourquoi c'est important

Pour les équipes d'ingénierie évaluant les coûts d'infrastructure cloud, la spécificité matérielle est un facteur de risque majeur. AWS Trainium offre des avantages potentiels en termes de coûts pour l'entraînement et l'inférence, mais seulement si la pile logicielle s'aligne parfaitement avec le matériel. Auparavant, déterminer cet alignement nécessitait des essais et erreurs manuels, impliquant souvent des débogages complexes d'erreurs de compilation ou de problèmes de dépassement de mémoire. Cet outil élimine cette incertitude en fournissant une liste vérifiée de modèles compatibles.

La disponibilité de graphes pré-compilés et de scripts de reproduction exacts abaisse considérablement la barrière à l'entrée. Les développeurs n'ont plus besoin de faire de l'ingénierie inverse pour trouver la configuration optimale pour chaque modèle. Au lieu de cela, ils peuvent reproduire précisément l'environnement testé, réduisant le temps entre la sélection et le déploiement. Cette normalisation est cruciale pour les équipes visant à opérationnaliser des modèles open source à grande échelle sans maintenir de vastes bases de code forkées personnalisées.

Ce que vous pouvez faire

  • Visitez l'espace torch-neuronx model support sur Hugging Face pour vérifier si votre modèle cible est répertorié.
  • Utilisez la fonction de recherche dans les vues Trending ou Downloads pour trouver des modèles spécifiques par nom.
  • Notez les versions spécifiques de neuronx-cc et de Transformers associées à tout modèle ayant réussi que vous avez l'intention d'utiliser.
  • Copiez le script run.py fourni et la liste des packages pour configurer votre environnement de développement local.
  • Synchronisez les graphes NEFF pré-compilés depuis le bucket public Hugging Face pour éviter les retards de compilation initiaux.
  • Interrogez directement le jeu de données public aws-neuron/torch-neuronx-model-support si vous devez analyser les tendances de compatibilité par programmation.
  • #aws trainium
  • #hugging face
  • #pytorch
  • #llm deployment
  • #machine learning ops

Outils de la Boutique Bytechap

$89

DocBento

Gestion documentaire auto-hébergée qui analyse chaque scan et répond avec des citations de pages.

Démo en ligne

Continuer la lecture

Tous les articles