Convalida un'architettura

Se si desidera distribuire un'architettura simile a quella descritta in questa soluzione, è necessario convalidarla in base ai criteri negli argomenti seguenti. Prendi in considerazione la selezione della GPU, l'impostazione del cluster, la distribuzione e la distribuzione, il ridimensionamento automatico, il test delle prestazioni, la sicurezza e i costi.

Seleziona GPU

Devi implementare un servizio di inferenza basato su GPU per convertire i segmenti di testo in parlato, garantendo performance, scalabilità ed efficienza dei costi. È possibile valutare i modelli GPU (A10, A100, L40S) per determinare la soluzione più adatta al caso d'uso.

È possibile eseguire test di benchmarking con tipi di GPU diversi. Nella tabella seguente viene fornito un modello. Inserire i valori per X e Y e utilizzare tali dati per confrontare le prestazioni effettive con i costi.

Tipo GPU Latenza media (per 250 segmenti) Throughput (segmenti/sec) Note
A10 X ms S Costo inferiore, adatto per sviluppo/test
A100 X ms S Prestazioni elevate, costi più elevati
L40S X ms S Buon equilibrio tra prezzo/prestazioni
  • Suggerimento: selezionare la GPU in base alle dimensioni del carico di lavoro, ai requisiti di latenza SLA e al budget.
  • Ottimizzazione: esegui con precisione FP16/mixed (se supportato) per una latenza ridotta.

Progetta cluster OKE

Progettare i cluster OKE in base alla distribuzione.

In questo esempio viene utilizzata un'impostazione cluster con due pool di nodi:

  • NodePool 1 (nodi CPU): esegue UI, worker, RabbitMQ e DB interno
  • NodePool 2 (nodi GPU): esegue i pod di inferenza TorchServe

Garantire un valore BV sufficiente sui nodi GPU.

Etichetta i pool di nodi:

  • nodepool=cpu sui nodi CPU
  • nodepool-gpu e nvidia.com/gpu.present=true sui nodi GPU

Assicurarsi che il componente aggiuntivo del plugin del dispositivo OKE NVIDIA sia abilitato sui nodi GPU e che nvidia-smi funzioni.

Convalida GPU

Per garantire che le GPU siano disponibili sia per il nodo OKE che per i pod TorchServe, eseguire i passi di convalida riportati di seguito.

Se entrambi i controlli hanno esito positivo, conferma che l'addon del plugin del dispositivo NVIDIA è abilitato e non è necessaria alcuna installazione aggiuntiva di driver/software.
  1. Verifica la visibilità GPU sul nodo di lavoro. Ad esempio:
    [opc@oke-cvxkfx3tnkq-nkteldpxwna-s3xcmkmmoda-0 ~]$ nvidia-smi -L
    GPU 0: NVIDIA A10 (UUID: GPU-eae0552a-e1d7-7c0f-dc39-886f4eafb439)
  2. Verifica l'accesso GPU all'interno del pod TorchServe. Ad esempio:
    [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)

Distribuzione modello progettazione

Sono disponibili due opzioni per rendere il modello .mar disponibile per i pod di inferenza.

  • Utilizza i bucket di OCI Object Storage come richiesta di rimborso del volume persistente (PVC) utilizzando il driver CSI (Container Storage Interface).
  • Trasferire il modello in OCI File Storage utilizzando il protocollo SCP (Secure Copy Protocol) e utilizzare il file system come punto di attivazione per un PVC. Ad esempio:
    scp -i /path/to/private_key /path/to/local/model.mar
          opc@<file_storage_instance_ip>:/path/to/destination/mount/point/models/

Consigliamo lo storage degli oggetti OCI per semplicità o lo storage di file OCI se hai più modelli con aggiornamenti frequenti.

Distribuisci TorchServe

Convalidare il metodo per distribuire TorchServe.

I seguenti file YAML forniscono esempi di distribuzione e configurazione.

  • Esporre utilizzando il bilanciamento del carico OCI (ingresso in OKE ai pod TorchServe).
  • Protezione con TLS nel load balancer.
  • Non esporre mai la porta di gestione TorchServe (8081) alla rete Internet pubblica.

Nota

  • Modificare l'istruzione image: del contenitore in modo che punti alla posizione e alla versione effettive del contenitore TorchServe.
  • multispk_20250121_tts è un nome di modello personalizzato utilizzato qui come esempio. È possibile sostituirlo con il nome del modello e il file .mar.

torcia-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

Imposta ridimensionamento automatico

Imposta il ridimensionamento automatico a livello di pod e lavoratore.

Imposta il ridimensionamento automatico a livello di pod utilizzando Autoscaler (KEDA) basato sugli eventi Kubernetes con le metriche Prometheus per ridimensionare i pod TorchServe in base alla profondità della coda di richieste o a metriche personalizzate o all'utilizzo di CPU/GPU.

Impostare il ridimensionamento automatico a livello di lavoratore (TorchServe).

Nota

Negli esempi seguenti viene utilizzato il ciclo di vita del modello TorchServe con multispk_20250121_tts.
  1. Registrare il modello. Ad esempio, eseguire il comando seguente da qualsiasi client remoto in grado di raggiungere l'endpoint TorchServe tramite HTTP per registrare il file .mar con un worker iniziale.
    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'IP (10.0.20.160) e la porta (8081) fanno riferimento all'endpoint API di gestione delle inferenze TorchServe.
  2. Annullare la registrazione di un modello. Ad esempio:
    curl -X DELETE "http://10.0.20.160:8081/models/multispk_20250121_tts"
  3. Ridimensionare/aggiungere i lavoratori. Ad esempio, per aggiornare il numero di lavoratori per il modello in esecuzione:
    curl -X PUT "http://10.0.20.160:8081/models/multispk_20250121_tts?min_worker=12"

Prestazioni del test

Convalida la tua progettazione con test delle prestazioni.

  1. Dall'applicazione client, inviare 250 segmenti concorrenti. Acquisisci:
    • Latenza p50/p95
    • Throughput (segmenti/sec)
    • Utilizzo della GPU (nvidia-smi)
    • Tempo di completamento job end-to-end
  2. Dal pod, eseguire:
    kubectl exec -it <pod_name> -- nvidia-smi
  3. Dall'API delle metriche TorchServe (porta 8082), eseguire:
    curl http://10.0.20.160:8082/metrics

Considerazioni per la sicurezza e l'ottimizzazione dei costi

Quando si convalida la progettazione, considerare i fattori di sicurezza e ottimizzazione dei costi:

  • Considerazioni di sicurezza:
    • Applica l'interruzione TLS nel load balancer o in entrata.
    • Conserva l'API di gestione TorchServe solo internamente.
    • Utilizzare OCI Identity and Access Management e i gruppi di sicurezza di rete per limitare l'accesso.
  • Considerazioni sull'ottimizzazione dei costi:
    • Scegliere il tipo di GPU in base a un saldo tra l'accordo livello di servizio (SLA) e il costo.
    • Usa scalabilità pianificata (ridimensiona pool di nodi GPU durante ore non di punta).
    • Utilizzare OCI Object Storage su OCI File Storage se i modelli non vengono aggiornati di frequente.
    • L'inferenza non sempre funziona 24×7. Condividi GPU inutilizzate con carichi di lavoro di formazione durante i periodi di inattività per massimizzare l'utilizzo e ridurre i costi.