Optimiser l'utilisation des ressources GKE pour les charges de travail mixtes d'entraînement et d'inférence d'IA/ML

Préparer l'environnement

Dans cette section, vous provisionnez les ressources dont vous avez besoin pour déployer TGI et le modèle pour vos charges de travail d'inférence et d'entraînement.

Accéder au modèle

Pour accéder aux modèles Gemma en vue du déploiement sur GKE, vous devez d'abord signer le contrat d'autorisation de licence, puis générer un jeton d'accès Hugging Face.

1. Signez le contrat de consentement de la licence. Accédez à la page d'autorisation du modèle, vérifiez l'autorisation à l'aide de votre compte Hugging Face et acceptez les conditions d'utilisation du modèle.

2. Générez un jeton d'accès. Pour accéder au modèle via Hugging Face, vous avez besoin d'un jeton Hugging Face. Pour générer un nouveau jeton si vous n'en possédez pas, procédez comme suit:

   1. Cliquez sur Your Profile > Settings > Access Tokens (Votre profil > Paramètres > Jetons d'accès).
   2. Sélectionnez New Token (Nouveau jeton).
   3. Spécifiez le nom de votre choix et un rôle d'au moins Read.
   4. Sélectionnez Générer un jeton.
   5. Copiez le jeton dans votre presse-papiers.

Lancer Cloud Shell

Dans ce tutoriel, vous utilisez Cloud Shell pour gérer les ressources hébergées surGoogle Cloud. Les logiciels dont vous avez besoin pour ce tutoriel sont préinstallés sur Cloud Shell, y compris kubectl, gcloud CLI et Terraform.

Pour configurer votre environnement avec Cloud Shell, procédez comme suit :

1. Dans la console Google Cloud , lancez une session Cloud Shell en cliquant sur Activer Cloud Shell dans la consoleGoogle Cloud . Une session s'ouvre dans le volet inférieur de la console Google Cloud .

2. Définissez les variables d'environnement par défaut :

   gcloud config set project PROJECT_ID export PROJECT_ID=$(gcloud config get project) 

   Remplacez PROJECT_ID par l'ID de votre projet : Google Cloud

3. Clonez l'exemple de code depuis GitHub. Dans Cloud Shell, exécutez les commandes suivantes :

   git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples/ cd kubernetes-engine-samples/ai-ml/mix-train-and-inference export EXAMPLE_HOME=$(pwd) 

Créer un cluster GKE

Vous pouvez utiliser un cluster Autopilot ou Standard pour vos charges de travail mixtes. Nous vous recommandons d'utiliser un cluster Autopilot pour une expérience Kubernetes entièrement gérée. Pour choisir le mode de fonctionnement GKE le mieux adapté à vos charges de travail, consultez la section Choisir un mode de fonctionnement GKE.

Créer un secret Kubernetes pour les identifiants Hugging Face

Pour créer un secret Kubernetes contenant le jeton Hugging Face, exécutez la commande suivante :

kubectl create secret generic hf-secret \     --from-literal=hf_api_token=$HF_TOKEN \     --dry-run=client -o yaml | kubectl apply --namespace=llm --filename=- 

Configurer Kueue

Dans ce tutoriel, Kueue est le gestionnaire de ressources central, qui permet de partager efficacement les GPU entre vos charges de travail d'entraînement et de diffusion. Pour ce faire, Kueue définit les exigences en termes de ressources ("saveurs"), hiérarchise les charges de travail à l'aide de files d'attente (en privilégiant les tâches de diffusion par rapport à l'entraînement) et alloue les ressources de manière dynamique en fonction de la demande et de la priorité. Ce tutoriel utilise le type de ressource Workload pour regrouper respectivement les charges de travail d'inférence et de réglage fin.

La fonctionnalité de préemption de Kueue garantit que les charges de travail de diffusion à haute priorité disposent toujours des ressources nécessaires en mettant en pause ou en expulsant les jobs d'entraînement à priorité inférieure lorsque les ressources sont rares.

Pour contrôler le déploiement du serveur d'inférence avec Kueue, activez l'intégration pod et configurez managedJobsNamespaceSelector pour exclure les espaces de noms kube-system et kueue-system.

1. Dans le répertoire /kueue, consultez le code dans kustomization.yaml. Ce fichier manifeste installe le gestionnaire de ressources Kueue avec des configurations personnalisées.

   apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - https://github.com/kubernetes-sigs/kueue/releases/download/v0.12.3/manifests.yaml patches: - path: patch.yaml   target:     version: v1     kind: ConfigMap     name: kueue-manager-config 

2. Dans le répertoire /kueue, consultez le code dans patch.yaml. Cette ConfigMap personnalise Kueue pour exclure la gestion des pods dans les espaces de noms kube-system et kueue-system.

   apiVersion: v1 kind: ConfigMap metadata:   name: kueue-manager-config data:   controller_manager_config.yaml: |     apiVersion: config.kueue.x-k8s.io/v1beta1     kind: Configuration     health:       healthProbeBindAddress: :8081     metrics:       bindAddress: :8080     # enableClusterQueueResources: true     webhook:       port: 9443     leaderElection:       leaderElect: true       resourceName: c1f6bfd2.kueue.x-k8s.io     controller:       groupKindConcurrency:         Job.batch: 5         Pod: 5         Workload.kueue.x-k8s.io: 5         LocalQueue.kueue.x-k8s.io: 1         ClusterQueue.kueue.x-k8s.io: 1         ResourceFlavor.kueue.x-k8s.io: 1     clientConnection:       qps: 50       burst: 100     #pprofBindAddress: :8083     #waitForPodsReady:     #  enable: false     #  timeout: 5m     #  blockAdmission: false     #  requeuingStrategy:     #    timestamp: Eviction     #    backoffLimitCount: null # null indicates infinite requeuing     #    backoffBaseSeconds: 60     #    backoffMaxSeconds: 3600     #manageJobsWithoutQueueName: true     managedJobsNamespaceSelector:       matchExpressions:         - key: kubernetes.io/metadata.name           operator: NotIn           values: [ kube-system, kueue-system ]     #internalCertManagement:     #  enable: false     #  webhookServiceName: ""     #  webhookSecretName: ""     integrations:       frameworks:       - "batch/job"       - "kubeflow.org/mpijob"       - "ray.io/rayjob"       - "ray.io/raycluster"       - "jobset.x-k8s.io/jobset"       - "kubeflow.org/paddlejob"       - "kubeflow.org/pytorchjob"       - "kubeflow.org/tfjob"       - "kubeflow.org/xgboostjob"       - "kubeflow.org/jaxjob"       - "workload.codeflare.dev/appwrapper"       - "pod"     #  - "deployment" # requires enabling pod integration     #  - "statefulset" # requires enabling pod integration     #  - "leaderworkerset.x-k8s.io/leaderworkerset" # requires enabling pod integration     #  externalFrameworks:     #  - "Foo.v1.example.com"     #fairSharing:     #  enable: true     #  preemptionStrategies: [LessThanOrEqualToFinalShare, LessThanInitialShare]     #admissionFairSharing:     #  usageHalfLifeTime: "168h" # 7 days     #  usageSamplingInterval: "5m"     #  resourceWeights: # optional, defaults to 1 for all resources if not specified     #    cpu: 0    # if you want to completely ignore cpu usage     #    memory: 0 # ignore completely memory usage     #    example.com/gpu: 100 # and you care only about GPUs usage     #resources:     #  excludeResourcePrefixes: []     #  transformations:     #  - input: nvidia.com/mig-4g.5gb     #    strategy: Replace | Retain     #    outputs:     #      example.com/accelerator-memory: 5Gi     #      example.com/accelerator-gpc: 4     #objectRetentionPolicies:     #  workloads:     #    afterFinished: null # null indicates infinite retention, 0s means no retention at all     #    afterDeactivatedByKueue: null # null indicates infinite retention, 0s means no retention at all 

3. Dans Cloud Shell, exécutez la commande suivante pour installer Kueue :

   cd ${EXAMPLE_HOME} kubectl kustomize kueue |kubectl apply --server-side --filename=- 

   Attendez que les pods Kueue soient prêts :

   watch kubectl --namespace=kueue-system get pods 

   Le résultat doit ressembler à ce qui suit :

   NAME                                        READY   STATUS    RESTARTS   AGE kueue-controller-manager-bdc956fc4-vhcmx    1/1     Running   0          3m15s 

4. Dans le répertoire /workloads, affichez les fichiers flavors.yaml, cluster-queue.yaml et local-queue.yaml. Ces fichiers manifestes spécifient comment Kueue gère les quotas de ressources :

   ResourceFlavor

   Ce fichier manifeste définit une ResourceFlavor par défaut dans Kueue pour la gestion des ressources.

   apiVersion: kueue.x-k8s.io/v1beta1 kind: ResourceFlavor metadata:   name: default-flavor 

   ClusterQueue

   Ce fichier manifeste configure une ClusterQueue Kueue avec des limites de ressources pour le processeur, la mémoire et le GPU.

   Ce tutoriel utilise des nœuds auxquels sont associés deux GPU Nvidia L4, avec le type de nœud correspondant g2-standard-24, qui offre 24 vCPU et 96 Go de RAM. L'exemple de code montre comment limiter l'utilisation des ressources de votre charge de travail à un maximum de six GPU.

   Le champ preemption de la configuration ClusterQueue fait référence aux PriorityClasses pour déterminer quels pods peuvent être préemptés lorsque les ressources sont rares.

   apiVersion: kueue.x-k8s.io/v1beta1 kind: ClusterQueue metadata:   name: "cluster-queue" spec:   namespaceSelector: {} # match all.   preemption:     reclaimWithinCohort: LowerPriority     withinClusterQueue: LowerPriority   resourceGroups:   - coveredResources: [ "cpu", "memory", "nvidia.com/gpu", "ephemeral-storage" ]     flavors:     - name: default-flavor       resources:       - name: "cpu"         nominalQuota: 72       - name: "memory"         nominalQuota: 288Gi       - name: "nvidia.com/gpu"         nominalQuota: 6       - name: "ephemeral-storage"         nominalQuota: 200Gi 

   LocalQueue

   Ce fichier manifeste crée une LocalQueue Kueue nommée lq dans l'espace de noms llm.

   apiVersion: kueue.x-k8s.io/v1beta1 kind: LocalQueue metadata:   namespace: llm # LocalQueue under llm namespace    name: lq spec:   clusterQueue: cluster-queue # Point to the ClusterQueue 

5. Affichez les fichiers default-priorityclass.yaml, low-priorityclass.yaml et high-priorityclass.yaml. Ces fichiers manifestes définissent les objets PriorityClass pour la planification Kubernetes.

   Priorité par défaut

   apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata:   name: default-priority-nonpreempting value: 10 preemptionPolicy: Never globalDefault: true description: "This priority class will not cause other pods to be preempted." 

   Priorité faible

   apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata:   name: low-priority-preempting value: 20 preemptionPolicy: PreemptLowerPriority globalDefault: false description: "This priority class will cause pods with lower priority to be preempted." 

   Priorité élevée

   apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata:   name: high-priority-preempting value: 30 preemptionPolicy: PreemptLowerPriority globalDefault: false description: "This high priority class will cause other pods to be preempted." 

6. Créez les objets Kueue et Kubernetes en exécutant ces commandes pour appliquer les fichiers manifestes correspondants.

   cd ${EXAMPLE_HOME}/workloads kubectl apply --filename=flavors.yaml kubectl apply --filename=default-priorityclass.yaml kubectl apply --filename=high-priorityclass.yaml kubectl apply --filename=low-priorityclass.yaml kubectl apply --filename=cluster-queue.yaml kubectl apply --filename=local-queue.yaml --namespace=llm 

Déployer le serveur d'inférence TGI

Dans cette section, vous allez déployer le conteneur TGI pour diffuser le modèle Gemma 2.

1. Dans le répertoire /workloads, affichez le fichier tgi-gemma-2-9b-it-hp.yaml. Ce fichier manifeste définit un déploiement Kubernetes pour déployer le runtime de diffusion TGI et le modèle gemma-2-9B-it. Un déploiement est un objet de l'API Kubernetes qui vous permet d'exécuter plusieurs instances dupliquées de pods répartis entre les nœuds d'un cluster.

   Le déploiement donne la priorité aux tâches d'inférence et utilise deux GPU pour le modèle. Il utilise le parallélisme de tenseur en définissant la variable d'environnement NUM_SHARD pour ajuster le modèle à la mémoire du GPU.

   apiVersion: apps/v1 kind: Deployment metadata:   name: tgi-gemma-deployment   labels:     app: gemma-server spec:   replicas: 1   selector:     matchLabels:       app: gemma-server   template:     metadata:       labels:         app: gemma-server         ai.gke.io/model: gemma-2-9b-it         ai.gke.io/inference-server: text-generation-inference         examples.ai.gke.io/source: user-guide         kueue.x-k8s.io/queue-name: lq     spec:       priorityClassName: high-priority-preempting       containers:       - name: inference-server         image: us-docker.pkg.dev/deeplearning-platform-release/gcr.io/huggingface-text-generation-inference-cu121.2-1.ubuntu2204.py310         resources:           requests:             cpu: "4"             memory: "30Gi"             ephemeral-storage: "30Gi"             nvidia.com/gpu: "2"           limits:             cpu: "4"             memory: "30Gi"             ephemeral-storage: "30Gi"             nvidia.com/gpu: "2"         env:         - name: AIP_HTTP_PORT           value: '8000'         - name: NUM_SHARD           value: '2'         - name: MODEL_ID           value: google/gemma-2-9b-it         - name: HUGGING_FACE_HUB_TOKEN           valueFrom:             secretKeyRef:               name: hf-secret               key: hf_api_token         volumeMounts:         - mountPath: /dev/shm           name: dshm       volumes:       - name: dshm         emptyDir:           medium: Memory       nodeSelector:         cloud.google.com/gke-accelerator: "nvidia-l4" --- apiVersion: v1 kind: Service metadata:   name: llm-service spec:   selector:     app: gemma-server   type: ClusterIP   ports:   - protocol: TCP     port: 8000     targetPort: 8000 

2. Appliquez le fichier manifeste en exécutant la commande suivante :

   kubectl apply --filename=tgi-gemma-2-9b-it-hp.yaml --namespace=llm 

   L'opération de déploiement prendra quelques minutes.

3. Pour vérifier si GKE a bien créé le déploiement, exécutez la commande suivante :

   kubectl --namespace=llm get deployment 

   Le résultat doit ressembler à ce qui suit :

   NAME                   READY   UP-TO-DATE   AVAILABLE   AGE tgi-gemma-deployment   1/1     1            1           5m13s 

Vérifier la gestion des quotas Kueue

Dans cette section, vous vérifiez que Kueue applique correctement le quota de GPU pour votre déploiement.

1. Pour vérifier si Kueue connaît votre déploiement, exécutez cette commande pour récupérer l'état des objets Workload :

   kubectl --namespace=llm get workloads 

   Le résultat doit ressembler à ce qui suit :

   NAME                                              QUEUE   RESERVED IN     ADMITTED   FINISHED   AGE pod-tgi-gemma-deployment-6bf9ffdc9b-zcfrh-84f19   lq      cluster-queue   True                  8m23s 

2. Pour tester le remplacement des limites de quota, mettez à l'échelle le déploiement à quatre répliques :

   kubectl scale --replicas=4 deployment/tgi-gemma-deployment --namespace=llm 

3. Exécutez la commande suivante pour afficher le nombre de répliques déployées par GKE :

   kubectl get workloads --namespace=llm 

   Le résultat doit ressembler à ce qui suit :

   NAME                                              QUEUE   RESERVED IN     ADMITTED   FINISHED   AGE pod-tgi-gemma-deployment-6cb95cc7f5-5thgr-3f7d4   lq      cluster-queue   True                  14s pod-tgi-gemma-deployment-6cb95cc7f5-cbxg2-d9fe7   lq      cluster-queue   True                  5m41s pod-tgi-gemma-deployment-6cb95cc7f5-tznkl-80f6b   lq                                            13s pod-tgi-gemma-deployment-6cb95cc7f5-wd4q9-e4302   lq      cluster-queue   True                  13s 

   Le résultat indique que seuls trois pods sont admis en raison du quota de ressources appliqué par Kueue.

4. Exécutez la commande suivante pour afficher les pods dans l'espace de noms llm :

   kubectl get pod --namespace=llm 

   Le résultat doit ressembler à ce qui suit :

   NAME                                    READY   STATUS            RESTARTS   AGE tgi-gemma-deployment-7649884d64-6j256   1/1     Running           0          4m45s tgi-gemma-deployment-7649884d64-drpvc   0/1     SchedulingGated   0          7s tgi-gemma-deployment-7649884d64-thdkq   0/1     Pending           0          7s tgi-gemma-deployment-7649884d64-znvpb   0/1     Pending           0          7s 

5. Maintenant, réduisez le déploiement à 1. Cette étape est obligatoire avant de déployer le job de réglage précis. Sinon, il ne sera pas accepté, car le job d'inférence est prioritaire.

   kubectl scale --replicas=1 deployment/tgi-gemma-deployment --namespace=llm 

Explication du comportement

L'exemple de scaling ne génère que trois répliques (malgré le scaling à quatre) en raison de la limite de quota de GPU que vous avez définie dans la configuration ClusterQueue. La section spec.resourceGroups de ClusterQueue définit un nominalQuota de "6" pour nvidia.com/gpu. Le déploiement spécifie que chaque pod nécessite deux GPU. Par conséquent, ClusterQueue ne peut accepter qu'un maximum de trois répliques du déploiement à la fois (car 3 répliques * 2 GPU par réplique = 6 GPU, ce qui correspond au quota total).

Lorsque vous essayez de passer à quatre répliques, Kueue reconnaît que cette action dépasserait le quota de GPU et empêche la quatrième réplique d'être planifiée. Cela est indiqué par l'état SchedulingGated du quatrième pod. Ce comportement illustre l'application des quotas de ressources de Kueue.

Déployer le Job d'entraînement

Dans cette section, vous allez déployer un job d'affinage de priorité inférieure pour un modèle Gemma 2 qui nécessite quatre GPU répartis sur deux pods. Dans Kubernetes, un contrôleur Job crée un ou plusieurs pods et s'assure qu'ils exécutent correctement une tâche spécifique.

Ce job utilisera le quota de GPU restant dans la ClusterQueue. Le job utilise une image prédéfinie et enregistre des points de contrôle pour permettre le redémarrage à partir de résultats intermédiaires.

Le job d'optimisation utilise l'ensemble de données b-mc2/sql-create-context. La source du job d'affinage se trouve dans le dépôt.

1. Affichez le fichier fine-tune-l4.yaml. Ce fichier manifeste définit le job d'affinage.

   apiVersion: v1 kind: Service metadata:   name: headless-svc-l4 spec:   clusterIP: None # clusterIP must be None to create a headless service   selector:     job-name: finetune-gemma-l4 # must match Job name --- apiVersion: batch/v1 kind: Job metadata:   name: finetune-gemma-l4   labels:     kueue.x-k8s.io/queue-name: lq spec:   backoffLimit: 4   completions: 2   parallelism: 2   completionMode: Indexed   suspend: true # Set to true to allow Kueue to control the Job when it starts   template:     metadata:       labels:         app: finetune-job       annotations:         gke-gcsfuse/volumes: "true"         gke-gcsfuse/memory-limit: "35Gi"     spec:       priorityClassName: low-priority-preempting       containers:       - name: gpu-job         imagePullPolicy: Always         image: us-docker.pkg.dev/google-samples/containers/gke/gemma-fine-tuning:v1.0.0         ports:         - containerPort: 29500         resources:           requests:             nvidia.com/gpu: "2"           limits:             nvidia.com/gpu: "2"         command:         - bash         - -c         - |           accelerate launch \           --config_file fsdp_config.yaml \           --debug \           --main_process_ip finetune-gemma-l4-0.headless-svc-l4 \           --main_process_port 29500 \           --machine_rank ${JOB_COMPLETION_INDEX} \           --num_processes 4 \           --num_machines 2 \           fine_tune.py         env:         - name: "EXPERIMENT"           value: "finetune-experiment"         - name: MODEL_NAME           value: "google/gemma-2-2b"         - name: NEW_MODEL           value: "gemma-ft"         - name: MODEL_PATH           value: "/model-data/model-gemma2/experiment"         - name: DATASET_NAME           value: "b-mc2/sql-create-context"         - name: DATASET_LIMIT           value: "5000"         - name: EPOCHS           value: "1"         - name: GRADIENT_ACCUMULATION_STEPS           value: "2"         - name: CHECKPOINT_SAVE_STEPS           value: "10"         - name: HF_TOKEN           valueFrom:             secretKeyRef:               name: hf-secret               key: hf_api_token         volumeMounts:         - mountPath: /dev/shm           name: dshm         - name: gcs-fuse-csi-ephemeral           mountPath: /model-data           readOnly: false       nodeSelector:         cloud.google.com/gke-accelerator: nvidia-l4       restartPolicy: OnFailure       serviceAccountName: default       subdomain: headless-svc-l4       terminationGracePeriodSeconds: 60       volumes:       - name: dshm         emptyDir:           medium: Memory       - name: gcs-fuse-csi-ephemeral         csi:           driver: gcsfuse.csi.storage.gke.io           volumeAttributes:             bucketName: <MODEL_BUCKET>             mountOptions: "implicit-dirs"             gcsfuseLoggingSeverity: warning 

2. Appliquez le fichier manifeste pour créer le job d'affinage :

   cd ${EXAMPLE_HOME}/workloads  sed -e "s/<MODEL_BUCKET>/$MODEL_BUCKET/g" \     -e "s/<PROJECT_ID>/$PROJECT_ID/g" \     -e "s/<REGION>/$REGION/g" \     fine-tune-l4.yaml |kubectl apply --filename=- --namespace=llm 

3. Vérifiez que vos déploiements sont en cours d'exécution. Pour vérifier l'état des objets Workload, exécutez la commande suivante :

   kubectl get workloads --namespace=llm 

   Le résultat doit ressembler à ce qui suit :

   NAME                                              QUEUE   RESERVED IN     ADMITTED   FINISHED   AGE job-finetune-gemma-l4-3316f                       lq      cluster-queue   True                  29m pod-tgi-gemma-deployment-6cb95cc7f5-cbxg2-d9fe7   lq      cluster-queue   True                  68m 

   Ensuite, affichez les pods dans l'espace de noms llm en exécutant la commande suivante :

   kubectl get pod --namespace=llm 

   Le résultat doit ressembler à ce qui suit :

   NAME                                    READY   STATUS    RESTARTS   AGE finetune-gemma-l4-0-vcxpz               2/2     Running   0          31m finetune-gemma-l4-1-9ppt9               2/2     Running   0          31m tgi-gemma-deployment-6cb95cc7f5-cbxg2   1/1     Running   0          70m 

   Le résultat indique que Kueue autorise l'exécution de votre job de réglage fin et de vos pods de serveur d'inférence, en réservant les ressources appropriées en fonction des limites de quota que vous avez spécifiées.

4. Affichez les journaux de sortie pour vérifier que votre tâche d'affinage enregistre les points de contrôle dans le bucket Cloud Storage. Le job de réglage fin prend environ 10 minutes avant de commencer à enregistrer le premier point de contrôle.

   kubectl logs --namespace=llm --follow --selector=app=finetune-job 

   La sortie du premier point de contrôle enregistré ressemble à ce qui suit :

   {"name": "finetune", "thread": 133763559483200, "threadName": "MainThread", "processName": "MainProcess", "process": 33, "message": "Fine tuning started", "timestamp": 1731002351.0016131, "level": "INFO", "runtime": 451579.89835739136} … {"name": "accelerate.utils.fsdp_utils", "thread": 136658669348672, "threadName": "MainThread", "processName": "MainProcess", "process": 32, "message": "Saving model to /model-data/model-gemma2/experiment/checkpoint-10/pytorch_model_fsdp_0", "timestamp": 1731002386.1763802, "level": "INFO", "runtime": 486753.8924217224} 

Tester la préemption et l'allocation dynamique de Kueue sur votre charge de travail mixte

Dans cette section, vous allez simuler un scénario dans lequel la charge du serveur d'inférence augmente, ce qui nécessite une mise à l'échelle. Ce scénario montre comment Kueue donne la priorité au serveur d'inférence à priorité élevée en suspendant et en préemptant le job d'affinage à priorité inférieure lorsque les ressources sont limitées.

1. Exécutez la commande suivante pour faire passer le nombre d'instances dupliquées du serveur d'inférence à deux :

   kubectl scale --replicas=2 deployment/tgi-gemma-deployment --namespace=llm 

2. Vérifiez l'état des objets Workload :

   kubectl get workloads --namespace=llm 

   La sortie ressemble à ceci :

   NAME                                              QUEUE   RESERVED IN     ADMITTED   FINISHED   AGE job-finetune-gemma-l4-3316f                       lq                      False                 32m pod-tgi-gemma-deployment-6cb95cc7f5-cbxg2-d9fe7   lq      cluster-queue   True                  70m pod-tgi-gemma-deployment-6cb95cc7f5-p49sh-167de   lq      cluster-queue   True                  14s 

   La sortie indique que le job de réglage fin n'est plus accepté, car les répliques de serveur d'inférence supplémentaires utilisent le quota de GPU disponible.

3. Vérifiez l'état du job de réglage fin :

   kubectl get job --namespace=llm 

   Le résultat ressemble à ce qui suit, indiquant que l'état du job d'affinage est désormais "Suspendu" :

   NAME                STATUS      COMPLETIONS   DURATION   AGE finetune-gemma-l4   Suspended   0/2                      33m 

4. Exécutez la commande suivante pour inspecter vos pods :

   kubectl get pod --namespace=llm 

   Le résultat ressemble à ce qui suit, indiquant que Kueue a mis fin aux pods de job d'affinage pour libérer des ressources pour le déploiement du serveur d'inférence de priorité supérieure.

   NAME                                    READY   STATUS              RESTARTS   AGE tgi-gemma-deployment-6cb95cc7f5-cbxg2   1/1     Running             0          72m tgi-gemma-deployment-6cb95cc7f5-p49sh   0/1     ContainerCreating   0          91s 

5. Ensuite, testez le scénario dans lequel la charge du serveur d'inférence diminue et ses pods sont mis à l'échelle à la baisse. Exécutez la commande suivante :

   kubectl scale --replicas=1 deployment/tgi-gemma-deployment --namespace=llm 

   Exécutez la commande suivante pour afficher les objets Workload :

   kubectl get workloads --namespace=llm 

   Le résultat ressemble à ce qui suit, indiquant qu'un des déploiements du serveur d'inférence est terminé et que le job de réglage fin est réadmis.

   NAME                                              QUEUE   RESERVED IN     ADMITTED   FINISHED   AGE job-finetune-gemma-l4-3316f                       lq      cluster-queue   True                  37m pod-tgi-gemma-deployment-6cb95cc7f5-cbxg2-d9fe7   lq      cluster-queue   True                  75m 

6. Exécutez la commande suivante pour afficher les jobs :

   kubectl get job --namespace=llm 

   Le résultat ressemble à ce qui suit, indiquant que le job d'affinage est à nouveau en cours d'exécution, en reprenant à partir du dernier point de contrôle disponible.

   NAME                STATUS    COMPLETIONS   DURATION   AGE finetune-gemma-l4   Running   0/2           2m11s      38m