GPU prêts pour la production et compatibles CI/CD : le chaînon manquant du DevOps

Parité DevOps + GPU

Le coût caché des tests CPU

Il existe un fossé dans les pipelines DevOps modernes : l'écart entre l'environnement de test/dev et l'environnement de production.

Les apps de production s'appuient de plus en plus sur des GPU (inférence IA, transcodage vidéo accéléré, rendu WebGL), mais les pipelines CI tournent sur des runners 100 % CPU (runners partagés GitHub/GitLab).

Ce décalage matériel entraîne plusieurs problèmes :

1. Bugs « marche chez moi » : le code passe les tests unitaires CPU mais échoue en prod à cause d'incompatibilités CUDA, de fuites VRAM ou de drivers.
2. Mocks trompeurs : on « mock » les appels GPU pour faire passer les tests sur CPU : les kernels ne sont jamais réellement testés avant le déploiement.
3. Régressions de perf : sans GPU dans la boucle CI, impossible de détecter automatiquement une latence d'inférence ou un pic de VRAM.

Mettez de vrais GPU dans la CI pour attraper CUDA, VRAM et latence avant la production.

Intégration GitLab et GitHub Actions

Les instances Shadow GPU se configurent facilement en runners self-hosted pour les principales plateformes CI, comblant l'écart test/prod.

Configuration GitLab Runner

Les « SaaS Runners » GPU de GitLab existent mais sont coûteux et souvent soumis à la queue ou à des quotas. Configurer une instance Shadow comme Runner privé offre une alternative dédiée et autoscalable.

Étape 1 : installer le Runner

Suivez l'installation Linux standard de GitLab Runner sur l'instance Shadow.

Étape 2 : configurer config.toml

La clé se situe dans la section [runners.docker] : il faut passer le device GPU au conteneur.

[[runners]]
  name = "shadow-gpu-runner-01"
  url = "https://gitlab.com/"
  token = "PROJECT_TOKEN"
  executor = "docker"
  [runners.docker]
    image = "nvidia/cuda:12.1.0-base-ubuntu22.04"
    privileged = false
    disable_cache = false
    volumes = ["/cache"]
    gpus = "all"  # Flag indispensable pour exposer le GPU

Étape 3 : définir le pipeline (.gitlab-ci.yml)

Le pipeline peut alors exécuter des commandes GPU réelles.

test_inference:
  stage: test
  tags:
    - shadow-gpu  # Correspond au tag du runner
  image: pytorch/pytorch:2.1.0-cuda12.1-cudnn8-runtime
  script:
    - nvidia-smi  # Vérifier la visibilité GPU
    - python tests/benchmark_inference.py  # Lancer un vrai test d'inférence

Runners self-hosted GitHub Actions

Côté GitHub, les « Larger Runners » GPU sont onéreux. Une instance Shadow peut héberger l'application GitHub Actions Runner.

• Runners éphémères : par sécurité, mieux vaut des runners qui se réinitialisent après chaque job pour éviter les effets de bord (disque plein, process résiduels). L'API OpenStack Shadow peut être appelée par webhook (via un autoscaler custom) pour lancer une VM fraîche à chaque workflow et la détruire juste après : les JIT runners assurent un environnement propre.

Automatiser les régressions de performance

Au-delà du simple pass/fail, la CI GPU permet de faire du benchmark comme garde-fou.

• Scénario : une équipe IA optimise le code d'inférence d'un modèle.
• Logique de pipeline :

1. Le runner CI tire la nouvelle branche.
2. Il exécute un dataset d'inférence standard sur le GPU Shadow.
3. Il enregistre les métriques : latence (ms/token), débit (tokens/s), pic VRAM.
4. Il compare ces métriques au baseline (branche main).
5. Condition d'échec : si la perf se dégrade de >5 % ou si la VRAM grimpe, la MR est bloquée.

Cette « Performance CI » empêche un code gonflé ou inefficace d'atteindre la production et maintient l'efficacité tout au long du cycle logiciel.

Optimisation des coûts avec le Spot

Pour les workloads CI/CD, la fiabilité est moins critique que le coût, tant que le système peut relancer.

• Stratégie : configurer l'autoscaler CI pour demander d'abord des instances Spot. Si elles sont préemptées, le job retourne en file. Les jobs CI étant batch (tests, builds), ils sont parfaits pour le pricing Spot Shadow (~€0.29/h).
• Cette approche peut réduire la facture CI de ~30–50 % par rapport aux instances on-demand.

Annexe technique : spécifications de référence