KServe : exposer des LLM sur Kubernetes

L'exposition de modèles d'intelligence artificielle sous forme d'API représente un défi technique majeur pour les équipes qui souhaitent passer du prototype à la production. Entre la gestion de la scalabilité, l'optimisation des ressources GPU, et l'orchestration de multiples versions de modèles, les problématiques d'infrastructure peuvent rapidement éclipser le travail sur les modèles eux-mêmes. C'est précisément ce que KServe vient résoudre.

KServe est une plateforme open source conçue pour déployer et servir des modèles de machine learning sur Kubernetes. Qu'il s'agisse d'un LLM de plusieurs dizaines de milliards de paramètres ou d'un modèle de classification plus classique, KServe fournit une abstraction unifiée qui simplifie considérablement le passage en production. Sa force réside dans sa capacité à gérer automatiquement l'autoscaling, le traffic splitting, et le monitoring, tout en s'intégrant nativement dans l'écosystème Kubernetes.

Dans cet article, nous allons explorer ce qu'est KServe, comprendre son architecture et son fonctionnement sur Kubernetes, et découvrir comment l'utiliser concrètement pour exposer vos modèles d'IA sous forme d'API robustes et scalables.

Qu'est-ce que KServe et pourquoi l'utiliser ?

KServe, anciennement connu sous le nom de KFServing, est un projet né au sein de la communauté Kubeflow avant de devenir un projet indépendant de la CNCF (Cloud Native Computing Foundation). Son objectif est de standardiser le déploiement de modèles de machine learning en proposant une interface déclarative simple tout en gérant la complexité sous-jacente.

Le problème que KServe résout est fondamental : servir des modèles d'IA en production nécessite bien plus que d'encapsuler une fonction de prédiction dans une API Flask. Il faut gérer la montée en charge lors des pics de trafic, optimiser l'utilisation des GPU coûteux, permettre des déploiements progressifs (canary releases), et assurer un monitoring fin des performances. Sans outillage adapté, ces préoccupations d'infrastructure consomment un temps considérable.

KServe répond à ces défis en s'appuyant sur les primitives de Kubernetes et en ajoutant une couche d'abstraction spécifiquement conçue pour le machine learning :

• Autoscaling intelligent : montée en charge automatique basée sur le nombre de requêtes, avec support du scale-to-zero pour optimiser les coûts
• Inférence serverless : les modèles ne consomment des ressources que lorsqu'ils sont sollicités
• Support multi-framework : compatible avec TensorFlow, PyTorch, scikit-learn, XGBoost, ONNX, et les runtimes LLM comme vLLM ou Hugging Face TGI
• Traffic management : routage du trafic entre versions, canary deployments, et A/B testing natifs
• Standardisation : API de prédiction conforme au protocole Open Inference Protocol (V2)

L'un des atouts majeurs de KServe est sa capacité à servir aussi bien des modèles d'IA générative (LLM, modèles de diffusion) que des modèles de machine learning classique (classification, régression, détection d'anomalies). Cette polyvalence permet aux équipes d'unifier leur infrastructure de serving autour d'un outil unique.

Architecture et intégration avec Kubernetes

KServe s'intègre profondément dans l'écosystème Kubernetes en étendant ses capacités via des Custom Resource Definitions (CRDs). Cette approche permet de déployer des modèles en décrivant simplement l'état souhaité dans un fichier YAML, Kubernetes se chargeant de la réconciliation.

L'architecture de KServe repose sur plusieurs composants qui collaborent pour servir les modèles de manière fiable :

Le Control Plane gère le cycle de vie des InferenceServices (la ressource principale de KServe). Il orchestre la création des pods, configure le routage réseau, et gère les révisions lors des mises à jour de modèles.

Le Data Plane traite les requêtes d'inférence. Il peut fonctionner en deux modes :

• Serverless mode : s'appuie sur Knative pour l'autoscaling et le scale-to-zero
• RawDeployment mode : utilise des Deployments Kubernetes standards pour les cas nécessitant un contrôle plus fin

L'Ingress (généralement Istio ou Kourier) gère le routage du trafic externe vers les services d'inférence, permettant le traffic splitting entre différentes versions.

KServe introduit également le concept de composants modulaires dans un InferenceService :

• Predictor : le composant principal qui exécute l'inférence
• Transformer : optionnel, pour le pré-traitement et post-traitement des données
• Explainer : optionnel, pour fournir des explications sur les prédictions (SHAP, LIME)

Cette modularité permet de séparer les responsabilités et de scaler indépendamment chaque composant selon les besoins.

À découvrir : notre formation LLM Engineering

Déployer des modèles avec KServe

La mise en pratique de KServe commence par l'installation sur un cluster Kubernetes, puis par la création d'InferenceServices décrivant les modèles à exposer.

Installation de KServe

KServe peut être installé de plusieurs manières. Pour un environnement de développement ou de test, l'installation rapide avec le script officiel est la plus simple :

# Installation des dépendances (Istio, Cert-Manager, Knative)
kubectl apply -f https://github.com/kserve/kserve/releases/download/v0.12.0/kserve.yaml

# Vérification de l'installation
kubectl get pods -n kserve

Pour la production, une installation via Helm avec configuration personnalisée est recommandée, permettant d'ajuster les ressources, la haute disponibilité, et les intégrations avec votre infrastructure existante.

Exposer un modèle classique

Commençons par un exemple simple : déployer un modèle scikit-learn stocké sur un bucket S3. KServe fournit des runtimes pré-construits pour les frameworks les plus courants :

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: sklearn-iris
spec:
  predictor:
    model:
      modelFormat:
        name: sklearn
      storageUri: "s3://mon-bucket/models/iris-model"
      resources:
        requests:
          cpu: "100m"
          memory: "256Mi"
        limits:
          cpu: "1"
          memory: "1Gi"

Une fois appliqué avec kubectl apply -f iris-service.yaml, KServe télécharge le modèle, crée le pod de serving, et expose une API REST :

# Récupérer l'URL du service
kubectl get inferenceservice sklearn-iris

# Tester l'inférence
curl -X POST http://<service-url>/v1/models/sklearn-iris:predict \
  -H "Content-Type: application/json" \
  -d '{"instances": [[5.1, 3.5, 1.4, 0.2]]}'

Servir des LLM avec vLLM

Pour les modèles de langage, KServe s'intègre avec des runtimes optimisés comme vLLM ou Hugging Face TGI. Voici comment déployer un LLM avec vLLM :

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: llama-service
spec:
  predictor:
    model:
      modelFormat:
        name: vllm
      storageUri: "pvc://models-pvc/llama-3-8b"
      args:
        - --model=/mnt/models
        - --tensor-parallel-size=1
      resources:
        limits:
          nvidia.com/gpu: "1"
        requests:
          cpu: "4"
          memory: "32Gi"

Cette configuration déploie un modèle Llama 3 8B avec vLLM, bénéficiant automatiquement des optimisations de continuous batching et paged attention. L'API exposée est compatible avec le format OpenAI, facilitant l'intégration avec des applications existantes.

Configuration de l'autoscaling

L'autoscaling est l'une des fonctionnalités les plus précieuses de KServe pour optimiser les coûts. La configuration permet de définir des seuils de scale-up et le comportement de scale-to-zero :

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: mon-modele
  annotations:
    autoscaling.knative.dev/target: "10"      # Requêtes par pod
    autoscaling.knative.dev/minScale: "0"     # Scale to zero activé
    autoscaling.knative.dev/maxScale: "5"     # Maximum 5 replicas
spec:
  predictor:
    model:
      modelFormat:
        name: pytorch
      storageUri: "gs://bucket/model"

Avec cette configuration, le service démarre à zéro pods en l'absence de trafic, scale automatiquement pour maintenir environ 10 requêtes par pod, et ne dépasse jamais 5 replicas.

À lire : découvrez notre formation LLM Engineering

Bonnes pratiques et cas d'usage avancés

L'utilisation de KServe en production nécessite d'aller au-delà des configurations de base pour tirer pleinement parti de ses capacités.

Le traffic splitting permet de déployer de nouvelles versions de modèles progressivement. En spécifiant des pourcentages de trafic entre versions, vous pouvez valider les performances d'un nouveau modèle sur une fraction du trafic réel avant un déploiement complet :

spec:
  predictor:
    canaryTrafficPercent: 20  # 20% vers la nouvelle version
    model:
      modelFormat:
        name: sklearn
      storageUri: "s3://bucket/model-v2"

Le multi-model serving optimise l'utilisation des ressources en permettant à plusieurs modèles de partager le même pod. Cette approche est particulièrement intéressante lorsque vous avez de nombreux petits modèles :

apiVersion: serving.kserve.io/v1alpha1
kind: ClusterServingRuntime
metadata:
  name: triton-multi-model
spec:
  supportedModelFormats:
    - name: onnx
      autoSelect: true
  multiModel: true
  containers:
    - name: triton
      image: nvcr.io/nvidia/tritonserver:23.10-py3

Pour le monitoring, KServe expose nativement des métriques Prometheus couvrant la latence, le throughput, et les erreurs. L'intégration avec Grafana permet de construire des dashboards de supervision complets. Les métriques clés à surveiller incluent :

• Latence P50, P95 et P99 des inférences
• Nombre de requêtes par seconde
• Taux d'erreur et types d'erreurs
• Utilisation GPU et mémoire
• Temps de cold start (en mode serverless)

Conclusion

KServe s'impose comme une solution de référence pour l'exposition de modèles d'IA en production sur Kubernetes. En abstrayant la complexité de l'infrastructure de serving, il permet aux équipes de se concentrer sur ce qui compte vraiment : la qualité des modèles et la valeur métier qu'ils apportent.

La polyvalence de KServe constitue l'un de ses atouts majeurs. Que vous déployiez un modèle de classification entraîné avec scikit-learn, un réseau de neurones PyTorch, ou un LLM de plusieurs milliards de paramètres via vLLM, la même interface déclarative s'applique. Cette unification simplifie considérablement la gestion opérationnelle et réduit la charge cognitive des équipes.

Pour les organisations qui exploitent déjà Kubernetes, l'adoption de KServe s'inscrit naturellement dans les pratiques existantes. Les équipes DevOps retrouvent les concepts familiers de Deployments, Services et Ingress, enrichis de fonctionnalités spécifiquement conçues pour le machine learning. L'autoscaling intelligent et le scale-to-zero permettent d'optimiser les coûts, particulièrement importants lorsque des GPU sont impliqués.

L'écosystème des outils de MLOps continue d'évoluer rapidement, mais KServe a su s'établir comme un standard de facto pour le model serving sur Kubernetes. Maîtriser cet outil représente un investissement pertinent pour quiconque construit des systèmes d'IA destinés à servir des utilisateurs en production, qu'il s'agisse d'applications d'IA générative ou de pipelines de machine learning plus traditionnels.