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 CPUnodepool-gpu
envidia.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.
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 conmultispk_20250121_tts
.
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.