Déploiement d'une solution LLM/GPU en contexte éditeur : comment les orgs DevOps mutualisent-elles les ressources ?

Général
1

Bonjour,

Je travaille pour un éditeur de logiciels qui envisage de déployer une solution basée sur un LLM et potentiellement un GPU pour de l’OCR (bien qu’un LLM multimodal soit également envisagé selon les cas d’usage).

Notre usage du GPU sera ponctuel et non continu — or dédier un GPU à une seule application, c’est le payer 100% du temps pour un usage partiel. Je me pose donc la question de comment les équipes DevOps mettent concrètement les ressources GPU à disposition dans ce type de contexte.

Après quelques recherches, j’ai identifié deux approches qui semblent faire consensus :

  1. Kubernetes + node pools GPU : les workloads GPU sont schedulés sur des nœuds dédiés, mais en temps partagé via le mécanisme de scheduling de K8s (potentiellement avec du fractional GPU via MIG ou time-slicing).

  2. Mutualisation via une API LLM interne : déploiement d’un moteur d’inférence comme vLLM exposé comme une API REST compatible OpenAI, permettant de servir plusieurs applications simultanément et d’optimiser l’utilisation des GPU (batching, KV cache, etc.).

Mes questions concrètes :

  • Est-ce que cette lecture correspond à ce que vous observez sur le terrain ?
  • Y a-t-il d’autres patterns courants que j’aurais manqués ?
  • Pour une application éditeur à charge variable, quelle approche privilégiez-vous entre self-hosted vLLM et une API managée externe (OpenAI, Mistral, Bedrock…) ?
  • Des retours d’expérience sur les coûts réels et la complexité opérationnelle ?
  • Quel matériel GPU trouve-t-on concrètement dans ce type de déploiement ? H100, RTX (A6000, 4090…), cartes pro type L40S, ou autre chose ? Les H100 sont-ils réservés aux gros clouds ou accessibles chez des hébergeurs intermédiaires ?

Merci d’avance pour vos retours terrain.

2

Bonjour,

J’ai pas forcément réponse à tous les éléments, mais je peux te donner des éléments sur ce qu’on fait chez Waays pour faire du GPU à la demande sur Kubernetes typiquement.

Pour le contexte, nous avons une offre Kubernetes qui repose sur du cloud publique (OVHCloud, mixte barre metal et public cloud). Sur cette offre nous avons des clients qui dans le cadre de training ont des besoins ponctuel.

Pour le coup, on a fait simple, quand un workload a besoin d’une ressource CPU et qu’aucunes n’est disponible, on provisionne à la demande une VM avec une H100. Le scaling de 0 à many est géré par Keda. On a très peu de soucis au final c’est simple et efficace. On provisionne les VM par le trigger d’une pipeline Gitlab CI Terraform. Ce qui n’est pas le plus sexy, mais on travail à l’intégrer à Kapi pour gérer les ressources.

Tout ça n’est pas ultra complexe et la maintenance demandé n’est pas aussi élevé que ce qu’on craignait.