Valider une architecture

Si vous souhaitez déployer une architecture similaire à celle illustrée dans cette solution, vous devez la valider en fonction des critères indiqués dans les rubriques suivantes. Tenez compte de la sélection des GPU, de la configuration, de la distribution et du déploiement des clusters, du redimensionnement automatique, des tests de performances, de la sécurité et des coûts.

Sélectionner des GPU

Vous devez déployer un service d'inférence alimenté par GPU pour convertir les segments de texte en discours, garantissant les performances, l'évolutivité et la rentabilité. Vous pouvez évaluer les modèles GPU (A10, A100, L40S) afin de déterminer le meilleur ajustement pour le cas d'utilisation.

Vous pouvez effectuer des tests d'évaluation avec différents types de GPU. Le tableau suivant fournit un modèle. Entrez des valeurs pour X et Y et utilisez ces données pour comparer vos performances réelles au coût.

Type de GPU Latence moyenne (par 250 segments) Débit (segments/s) Remarques 
A10 X ms Y (Oui) Coût réduit, adapté au développement/test
A100 X ms Y (Oui) Hautes performances, coût plus élevé
L40S X ms Y (Oui) Bon équilibre entre prix et performance
  • Recommandation : sélectionnez un GPU en fonction de la taille de la charge globale, des exigences de latence du contrat de niveau de service et du budget.
  • Optimisation : exécution avec FP16/précision mixte (si prise en charge) pour une latence réduite.

Concevoir des clusters OKE

Concevez vos clusters OKE en fonction de votre déploiement.

Dans cet exemple, nous utilisons une configuration de cluster avec deux pools de noeuds :

  • NodePool 1 (noeuds CPU) : exécute l'interface utilisateur, les processus actifs, RabbitMQ et la base de données interne.
  • NodePool 2 (noeuds GPU) : exécute les pods d'inférence TorchServe.

Assurez-vous que la valeur BV est suffisante sur les noeuds GPU.

Nommer les pools de noeuds :

  • nodepool=cpu sur les noeuds d'UC
  • nodepool-gpu et nvidia.com/gpu.present=true sur les noeuds GPU

Assurez-vous que l'extension de module d'extension de périphérique OKE NVIDIA est activée sur les noeuds GPU et que nvidia-smi fonctionne.

Valider les GPU

Pour vous assurer que les GPU sont disponibles pour le noeud OKE et les pods TorchServe, exécutez les étapes de validation suivantes.

Si les deux contrôles réussissent, il confirme que l'extension de plug-in de périphérique NVIDIA est activée et qu'aucune installation de pilote/logiciel supplémentaire n'est nécessaire.
  1. Vérifiez la visibilité des GPU sur le noeud de processus actif. Par exemple :
    [opc@oke-cvxkfx3tnkq-nkteldpxwna-s3xcmkmmoda-0 ~]$ nvidia-smi -L
GPU 0: NVIDIA A10 (UUID: GPU-eae0552a-e1d7-7c0f-dc39-886f4eafb439)
  2. Vérifiez l'accès aux GPU dans le pod TorchServe. Par exemple :
    [opc@glvoicepoc-bastion guru]$ kubectl exec -it torchserve-7859b89965-rtqw9 -- /bin/bash
model-server@torchserve-7859b89965-rtqw9:~$ nvidia-smi -L
GPU 0: NVIDIA A10 (UUID: GPU-d6d1852e-6d04-59b9-10de-f68422638fb3)

Distribution des modèles de conception

Vous avez deux options pour rendre le modèle .mar disponible pour les pods d'inférence.

  • Utilisez des buckets OCI Object Storage en tant que demande de volume persistante à l'aide du pilote Container Storage Interface (CSI).
  • Transférez votre modèle vers OCI File Storage à l'aide du protocole SCP (Secure Copy Protocol) et utilisez le système de fichiers comme point de montage pour une demande de volume persistant. Exemple : 
    scp -i /path/to/private_key /path/to/local/model.mar
      opc@<file_storage_instance_ip>:/path/to/destination/mount/point/models/

Nous recommandons OCI Object Storage pour plus de simplicité, ou OCI File Storage si vous disposez de plusieurs modèles avec des mises à jour fréquentes.

Déployer TorchServe

Validez votre méthode de déploiement de TorchServe.

Les fichiers YAML suivants fournissent des exemples de déploiement et de configuration.

  • Exposer à l'aide d'OCI Load Balancing (entrée vers OKE vers des pods TorchServe).
  • Sécuriser avec TLS sur l'équilibreur de charge.

  • N'exposez jamais le port de gestion TorchServe (8081) au réseau Internet public.

Remarques :

  • Modifiez l'instruction image: de conteneur afin qu'elle pointe vers votre version et votre emplacement de conteneur TorchServe réels.
  • multispk_20250121_tts est un nom de modèle personnalisé utilisé ici comme exemple. Vous pouvez le remplacer par le nom de votre propre modèle et le fichier .mar.

torchserve-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: torchserve
  labels:
    app: torchserve
spec:
  replicas: 1
  selector:
    matchLabels:
      app: torchserve
  template:
    metadata:
      labels:
        app: torchserve
    spec:
      nodeSelector:
        nodepool: torchserve
      tolerations:
        - key: "nvidia.com/gpu"
          operator: "Exists"
          effect: "NoSchedule"
      imagePullSecrets:
        - name: ocir-creds
      containers:
        - name: torchserve
          image: ocir.<your-region>.oci.oraclecloud.com/<tenancy-namespace>/<torchserve_image>:<version>
          ports:
            - containerPort: 8080
            - containerPort: 8081
            - containerPort: 8082
            - containerPort: 7070
            - containerPort: 7071
          env:
            - name: GPUS__DEVICES
              value: "0"
            - name: METRICS_MODE
              value: "logical"  # or "endpoint"
            - name: ENABLE_METRICS_API
              value: "true"  
          resources:
            limits:
              nvidia.com/gpu: 1
          volumeMounts:
            - name: models-volume
              mountPath: /home/model-server/model-store
      volumes:
        - name: models-volume
          persistentVolumeClaim:
            claimName: fss-voiceengine-models

configmap-torchserve.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-properties
  namespace: default # Adjust the namespace as necessary
data:
  config.properties: |
    inference_address=http://0.0.0.0:8080
    management_address=http://0.0.0.0:8081
    metrics_address=http://0.0.0.0:8082
    number_of_netty_threads=32
    job_queue_size=1000
    model_store=/home/model-server/model-store
    workflow_store=/home/model-server/wf-store
    install_py_dep_per_model=true
    max_request_size=196605000
    max_response_size=196605000
    default_workers_per_model=1
    job_queue_size=100
    metrics_mode=logical
    load_models=/home/model-server/model-store/multispk_20250121_tts.mar

Configurer le redimensionnement automatique

Configurez le redimensionnement automatique au niveau du pod et du salarié.

Configurez le redimensionnement automatique au niveau du pod à l'aide de l'outil de redimensionnement automatique basé sur les événements (KEDA) Kubernetes avec des mesures Prometheus pour redimensionner les pods TorchServe en fonction de la profondeur de la file d'attente des demandes ou des mesures personnalisées ou de l'utilisation de l'UC/GPU.

Configurez le redimensionnement automatique au niveau du salarié (TorchServe).

Remarques :

Dans les exemples suivants, nous utilisons le cycle de vie du modèle TorchServe avec multispk_20250121_tts.
  1. Enregistrez le modèle. Par exemple, exécutez la commande suivante à partir de n'importe quel client distant qui peut atteindre l'adresse TorchServe via HTTP pour inscrire votre fichier .mar auprès d'un processus actif initial.
    curl -X POST "http://10.0.20.160:8081/models?model_name=multispk_20250121_tts&url=multispk_20250121_tts.mar&initial_workers=1"

Configure initial_workers per model demand.
    L'adresse IP (10.0.20.160) et le port (8081) font référence à l'adresse d'API de gestion des inférences TorchServe.
  2. Désinscrire un modèle. Par exemple :
    curl -X DELETE "http://10.0.20.160:8081/models/multispk_20250121_tts"
  3. Redimensionner/ajouter des salariés. Par exemple, pour mettre à jour le nombre de salariés pour le modèle en cours d'exécution :
    curl -X PUT "http://10.0.20.160:8081/models/multispk_20250121_tts?min_worker=12"

Performances de test

Validez votre conception avec des tests de performances.

  1. A partir de l'application client, envoyez 250 segments simultanés. Capture:
    • Latence p50/p95
    • Débit (segments/s)
    • Utilisation de GPU (nvidia-smi)
    • Heure de fin du travail de bout en bout
  2. A partir du pod, exécutez :
    kubectl exec -it <pod_name> -- nvidia-smi
  3. A partir de l'API de mesures TorchServe (port 8082), exécutez la commande suivante :
    curl http://10.0.20.160:8082/metrics

Remarques concernant la sécurité et l'optimisation des coûts

Lors de la validation de votre conception, tenez compte des facteurs de sécurité et d'optimisation des coûts :

  • Points à prendre en compte pour la sécurité :
    • Imposez la terminaison TLS sur l'équilibreur de charge ou l'entrée.
    • Conservez l'API de gestion TorchServe en interne uniquement.
    • Utilisez OCI Identity and Access Management et les groupes de sécurité réseau pour limiter l'accès.
  • Considérations relatives à l'optimisation des coûts :
    • Choisissez votre type de GPU en fonction d'un équilibre entre contrat de niveau de service (SLA) et coût.
    • Utilisez le redimensionnement programmé (réduisez le pool de noeuds GPU en dehors des heures de pointe).
    • Utilisez OCI Object Storage sur OCI File Storage si vos modèles sont rarement mis à jour.
    • L'inférence ne fonctionne pas toujours en 24×7. Partagez des GPU inutilisés avec des charges de travail d'entraînement pendant les périodes d'inactivité afin d'optimiser l'utilisation et de réduire les coûts.