Arm64 et Hugging Face : la checklist en 7 points pour valider votre stack IA

Les architectures Arm64 — Apple Silicon en local, AWS Graviton en production — offrent un rapport performance/coût difficile à ignorer pour les workloads d'inférence LLM. Pourtant, migrer une stack basée sur Hugging Face vers Arm64 ne se résume pas à recompiler une image Docker. Cet article, inspiré de l'analyse publiée par Docker sur leur blog officiel, propose une checklist structurée en 7 points pour évaluer et préparer cette transition, que vous soyez développeur ou CTO.

Pourquoi Arm64 pour l'inférence IA ?

Avant d'entrer dans le vif du sujet, posons le contexte. Les puces Arm64 modernes (M1/M2/M3 chez Apple, Graviton 3/4 chez AWS) proposent :

• Une consommation énergétique nettement réduite à performance égale
• Un coût d'instance inférieur de 20 à 40 % sur AWS Graviton vs x86 équivalent
• Des performances d'inférence compétitives pour les modèles quantifiés (ONNX, GGUF)

Mais l'écosystème Python/ML a été historiquement centré sur x86_64. La maturité Arm64 progresse rapidement, mais elle nécessite une analyse méthodique avant tout déploiement en production.

La checklist en 7 points

✅ 1. Vérifier la disponibilité des wheels Python

C'est le premier filtre. Pour chaque dépendance critique (torch, transformers, tokenizers, scipy...), vérifiez qu'une wheel native linux/arm64 est disponible sur PyPI.

pip install --dry-run --platform linux_aarch64 \
  --only-binary=:all: torch transformers

Si pip répond qu'il doit compiler depuis les sources, anticipez un temps de build long et un risque d'incompatibilité. Les wheels PyTorch pour Arm64 sont disponibles depuis la version 2.0, mais certaines extensions restent fragiles.

✅ 2. Auditer les dépendances compilées (extensions C/C++/CUDA)

Les bibliothèques avec des extensions natives sont les plus risquées. Identifiez dans votre requirements.txt tout paquet contenant du code compilé :

pip show <paquet> | grep -i "location"
# Puis inspecter les fichiers .so dans le répertoire

Portez une attention particulière à bitsandbytes (quantization 8-bit), flash-attn et xformers, qui ont une compatibilité Arm64 partielle ou conditionnelle selon les versions.

✅ 3. Construire des images multi-arch avec Docker Buildx

Plutôt que de maintenir deux Dockerfiles séparés, adoptez le build multi-architecture natif :

docker buildx create --use --name multiarch-builder
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  --tag votre-registry/monapp:latest \
  --push .

Veillez à utiliser des images de base multi-arch (python:3.12-slim le supporte nativement). Si votre image de base ne propose pas de variante arm64, tout s'arrête là.

✅ 4. Utiliser QEMU pour tester sans matériel Arm64

Pas d'instance Graviton sous la main ? Docker Desktop avec QEMU permet d'exécuter et tester une image arm64 sur une machine x86 :

# Activer l'émulation QEMU
docker run --rm --privileged multiarch/qemu-user-static --reset -p yes

# Lancer un conteneur arm64 en émulation
docker run --platform linux/arm64 -it votre-image:latest bash

⚠️ L'émulation QEMU est lente (facteur 5 à 10x). Elle convient aux tests de compatibilité, pas aux benchmarks de performance.

✅ 5. Évaluer la quantization et les formats ONNX/GGUF

Les modèles Hugging Face en précision complète (FP32/BF16) sont souvent moins bien optimisés sur Arm64 que leurs équivalents quantifiés. Testez systématiquement :

• ONNX Runtime : propose un backend Arm64 optimisé avec onnxruntime (package séparé de la version CUDA)
• GGUF/llama.cpp : format de prédilection pour l'inférence Arm64, exploite les instructions NEON
• INT8/INT4 : la quantization réduit l'empreinte mémoire et améliore le débit sur Arm64

from optimum.onnxruntime import ORTModelForCausalLM
model = ORTModelForCausalLM.from_pretrained("model-id", export=True)

Docker Model Runner, l'outil local-first d'inférence de Docker, exploite justement ces formats pour offrir des performances optimales sur Apple Silicon.

✅ 6. Benchmarker ARM vs x86 sur vos cas d'usage réels

Ne vous fiez pas aux benchmarks génériques. Mesurez sur vos propres modèles et vos propres charges :

import time

start = time.perf_counter()
outputs = model.generate(**inputs, max_new_tokens=200)
elapsed = time.perf_counter() - start
print(f"Tokens/s : {200 / elapsed:.1f}")

Comparez tokens/s, latence P95 et consommation mémoire entre une instance x86 et une instance Graviton de coût équivalent. Le résultat peut surprendre, dans un sens comme dans l'autre selon le modèle.

✅ 7. Automatiser la validation en CI

Une compatibilité Arm64 qui n'est pas testée en continu sera cassée lors d'une prochaine mise à jour de dépendance. Ajoutez une étape dédiée dans votre pipeline :

# GitHub Actions
jobs:
  test-arm64:
    runs-on: ubuntu-latest
    steps:
      - uses: docker/setup-qemu-action@v3
      - uses: docker/setup-buildx-action@v3
      - name: Build and test arm64
        run: |
          docker buildx build --platform linux/arm64 \
            --load -t test-arm64 .
          docker run --platform linux/arm64 test-arm64 \
            python -c "import torch; print(torch.__version__)"

Des runners Arm64 natifs sont désormais disponibles sur GitHub Actions (béta) et GitLab CI, ce qui élimine l'overhead QEMU pour les tests réguliers.

POC minimal : par où commencer ?

Si vous démarrez l'évaluation, voici un plan en 3 étapes sur une semaine :

1. Jour 1-2 : Audit des dépendances (points 1 et 2). Identifiez les bloquants potentiels avant d'aller plus loin.
2. Jour 3-4 : Build multi-arch et tests QEMU (points 3 et 4). Validez que l'image se construit et démarre correctement.
3. Jour 5 : Benchmark sur instance Graviton spot (point 6) et décision go/no-go. Les instances t4g d'AWS sont économiques pour ce type de test.

Conclusion

L'écosystème Arm64 pour l'inférence IA est aujourd'hui suffisamment mature pour envisager des déploiements en production, à condition de valider méthodiquement chaque couche de la stack. Les 7 points de cette checklist permettent d'éviter les mauvaises surprises et de cadrer un POC réaliste.

Pour aller plus loin, la ressource originale de Docker (How to Analyze Hugging Face for Arm64 Readiness) détaille les outils Docker Model Runner et Docker Sandboxes dans ce contexte. Elle constitue une lecture complémentaire utile pour les équipes souhaitant intégrer ces pratiques dans un workflow containerisé complet.