Accelera il caricamento dei dati AI/ML con Hyperdisk ML

Questa guida spiega come semplificare e accelerare il caricamento dei parametri del modello di AI/ML su Google Kubernetes Engine (GKE) utilizzando Hyperdisk ML. Il driver CSI per il disco permanente di Compute Engine è il modo principale per accedere allo spazio di archiviazione ML Hyperdisk con i cluster GKE.

Panoramica

Hyperdisk ML è una soluzione di archiviazione ad alte prestazioni che può essere utilizzata per eseguire lo scaling out delle applicazioni. Fornisce una velocità effettiva aggregata elevata a molte macchine virtuali contemporaneamente, ed è ideale se vuoi eseguire carichi di lavoro di AI/ML che richiedono l'accesso a grandi quantità di dati.

Se abilitato in modalità di sola lettura, puoi utilizzare Hyperdisk ML per accelerare il caricamento dei pesi del modello fino a 11,9 volte rispetto al caricamento direttamente da un registry dei modelli. Questa accelerazione è resa possibile dall'architettura Hyperdisk di Google Cloud che consente di eseguire il ridimensionamento fino a 2500 nodi contemporaneamente a 1,2 TB/s. In questo modo puoi migliorare i tempi di caricamento e ridurre il provisioning eccessivo dei pod per i tuoi carichi di lavoro di inferenza AI/ML.

I passaggi di alto livello per creare e utilizzare Hyperdisk ML sono i seguenti:

  1. Pre-cache o idrata i dati in un'immagine disco di Persistent Disk: carica i volumi ML Hyperdisk con i dati di un'origine dati esterna (ad esempio, i pesi di Gemma caricati da Cloud Storage) che possono essere utilizzati per il servizio. Il disco permanente per l'immagine del disco deve essere compatibile con Google Cloud Hyperdisk.
  2. Crea un volume Hyperdisk ML utilizzando un Hyperdisk Google Cloud preesistente: crea un volume Kubernetes che fa riferimento al volume Hyperdisk ML caricato con i dati. Se vuoi, puoi anche creare classi di archiviazione multizona per assicurarti che i dati siano disponibili in tutte le zone in cui verranno eseguiti i pod.
  3. Crea un deployment Kubernetes per utilizzare il volume Hyperdisk ML: fai riferimento al volume Hyperdisk ML con caricamento accelerato dei dati da utilizzare dalle tue applicazioni.

Volumi Hyperdisk ML multizona

I dischi Hyperdisk ML sono disponibili solo in una singola zona. Facoltativamente, puoi utilizzare la funzionalità multizona di Hyperdisk ML per collegare dinamicamente più dischi zonali contenenti gli stessi contenuti in un singolo PersistentVolumeClaim e PersistentVolume logico. I dischi zonali a cui fa riferimento la funzionalità multizona devono trovarsi nella stessa regione. Ad esempio, se il tuo cluster regionale viene creato in us-central1, i dischi multizona devono trovarsi nella stessa regione (ad esempio us-central1-a, us-central1-b).

Un caso d'uso comune per l'inferenza AI/ML è l'esecuzione di pod in più zone per migliorare la disponibilità degli acceleratori e l'efficienza in termini di costi con le VM spot. Poiché Hyperdisk ML è a livello di zona, se il server di inferenza esegue molti pod in più zone, GKE clona automaticamente i dischi nelle varie zone per garantire che i dati seguano l'applicazione.

Idrazione di Hyperdisk ML da origini dati esterne e creazione di PV multizona per accedere ai dati in più zone.

I volumi Hyperdisk ML multizona presentano le seguenti limitazioni:

  • Le operazioni di ridimensionamento e di snapshot dei volumi non sono supportate.
  • I volumi ML Hyperdisk multizona sono supportati solo in modalità di sola lettura.
  • Quando utilizzi dischi preesistenti con un volume ML Hyperdisk multizona, GKE non esegue controlli per verificare che i contenuti dei dischi tra le zone siano gli stessi. Se uno dei dischi contiene contenuti divergenti, assicurati che la tua applicazione tenga conto della potenziale incoerenza tra le zone.

Per saperne di più, consulta Creare un volume ML Hyperdisk ReadOnlyMany multizona da un VolumeSnapshot.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

  • Attiva l'API Google Kubernetes Engine.
    • Attiva l'API Google Kubernetes Engine
  • Se vuoi utilizzare Google Cloud CLI per questa attività, installa e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo gcloud components update.
  • Imposta la regione e la zona predefinite su uno dei valori supportati.
  • Assicurati che il tuo progetto Google Cloud disponga di una quota sufficiente per creare i nodi necessari in questa guida. Il codice di esempio per la creazione di cluster GKE e risorse Kubernetes richiede la seguente quota minima nella regione che preferisci: 88 CPU C3, 8 GPU NVIDIA L4.

Requisiti

Per utilizzare i volumi ML Hyperdisk in GKE, i cluster devono soddisfare i seguenti requisiti:

  • Utilizza cluster Linux che eseguono GKE versione 1.30.2-gke.1394000 o successiva. Se utilizzi un canale di rilascio, assicurati che il canale abbia la versione minima di GKE o successiva obbligatoria per questo driver.
  • Assicurati che il driver CSI per il disco permanente di Compute Engine sia abilitato. Il driver del disco permanente di Compute Engine è attivo per impostazione predefinita nei nuovi cluster Autopilot e standard e non può essere disabilitato o modificato quando si utilizza Autopilot. Se devi attivare il driver CSI per il disco permanente di Compute Engine dal tuo cluster, consulta Attivare il driver CSI per il disco permanente di Compute Engine in un cluster esistente.
  • Se vuoi ottimizzare il valore di lettura anticipata, utilizza GKE 1.29.2-gke.1217000 o versioni successive.
  • Se vuoi utilizzare la funzionalità di provisioning dinamico multizona, utilizza la versione GKE 1.30.2-gke.1394000 o successive.
  • Hyperdisk ML è supportato solo in determinati tipi di nodi e zone. Per approfondire, consulta Informazioni su Hyperdisk di Google Cloud nella documentazione di Compute Engine.

Ottieni l'accesso al modello

Per accedere ai modelli Gemma per il deployment in GKE, devi prima firmare il contratto di consenso per la licenza e poi generare un token di accesso a Hugging Face.

Per utilizzare Gemma, devi firmare il contratto di consenso. Segui queste istruzioni:

  1. Accedi alla pagina del consenso per i modelli su Kaggle.com.
  2. Verifica il consenso utilizzando il tuo account Hugging Face.
  3. Accetta i termini del modello.

Genera un token di accesso

Per accedere al modello tramite Hugging Face, devi disporre di un token Hugging Face.

Se non ne hai già uno, segui questi passaggi per generare un nuovo token:

  1. Fai clic su Il tuo profilo > Impostazioni > Token di accesso.
  2. Seleziona Nuovo token.
  3. Specifica un nome a tua scelta e un ruolo di almeno Read.
  4. Seleziona Genera un token.
  5. Copia il token generato negli appunti.

Crea un cluster GKE

Puoi pubblicare LLM su GPU in un cluster GKE Autopilot o Standard. Ti consigliamo di utilizzare un cluster Autopilot per un'esperienza Kubernetes completamente gestita. Per scegliere la modalità operativa GKE più adatta ai tuoi carichi di lavoro, consulta Scegliere una modalità operativa GKE.

Autopilot

  1. In Cloud Shell, esegui questo comando:

    gcloud container clusters create-auto hdml-gpu-l4 \
  --project=PROJECT \
  --region=REGION \
  --release-channel=rapid \
  --cluster-version=1.30.2-gke.1394000

    Sostituisci i seguenti valori:

    • PROJECT: l'ID progetto Google Cloud.
    • REGION: una regione che supporta il tipo di acceleratore che vuoi utilizzare, ad esempio us-east4 per la GPU L4.

    GKE crea un cluster Autopilot con nodi CPU e GPU come richiesto dai carichi di lavoro di cui è stato eseguito il deployment.

  2. Configura kubectl per comunicare con il cluster:

    gcloud container clusters get-credentials hdml-gpu-l4 \
  --region=REGION

Standard

  1. In Cloud Shell, esegui questo comando per creare un cluster e pool di nodi standard:

    gcloud container clusters create hdml-gpu-l4 \
    --location=REGION \
    --num-nodes=1 \
    --machine-type=c3-standard-44 \
    --release-channel=rapid \
    --cluster-version=CLUSTER_VERSION \
    --node-locations=ZONES \
    --project=PROJECT

gcloud container node-pools create gpupool \
    --accelerator type=nvidia-l4,count=2,gpu-driver-version=latest \
    --location=REGION \
    --project=PROJECT \
    --node-locations=ZONES \
    --cluster=hdml-gpu-l4 \
    --machine-type=g2-standard-24 \
    --num-nodes=2

    Sostituisci i seguenti valori:

    • CLUSTER_VERSION: la versione del tuo cluster GKE (ad esempio 1.30.2-gke.1394000).
    • REGION: la regione di calcolo per il piano di controllo del cluster. La regione deve supportare l'acceleratore che vuoi utilizzare, ad esempio us-east4, per la GPU L4. Verifica in quali regioni sono disponibili le GPU L4.
    • ZONES: le zone in cui vengono creati i nodi. Puoi specificare tutte le zone necessarie per il tuo cluster. Tutte le zone devono essere nella stessa regione del piano di controllo del cluster, specificato dal flag --zone. Per i cluster zonali, --node-locations deve contenere la zona principale del cluster.
    • PROJECT: l'ID progetto Google Cloud.

    La creazione del cluster potrebbe richiedere diversi minuti.

  2. Configura kubectl per comunicare con il cluster:

    gcloud container clusters get-credentials hdml-gpu-l4

Eseguire la pre-cache dei dati in un'immagine del disco Persistent Disk

Per utilizzare Hyperdisk ML, pre-cache i dati in un'immagine disco e crea un volume Hyperdisk ML per l'accesso in lettura da parte del tuo carico di lavoro in GKE. Questo approccio (chiamato anche idratazione dei dati) garantisce che i dati siano disponibili quando il carico di lavoro ne ha bisogno.

Per copiare i dati da Cloud Storage per pre-cache un'immagine disco di un Persistent Disk:

Crea una classe di archiviazione che supporti Hyperdisk ML

  1. Salva il seguente manifest StorageClass in un file denominato hyperdisk-ml.yaml.

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: hyperdisk-ml
parameters:
    type: hyperdisk-ml
provisioner: pd.csi.storage.gke.io
allowVolumeExpansion: false
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

  2. Crea StorageClass eseguendo questo comando:

    kubectl create -f hyperdisk-ml.yaml

Crea un PersistentVolumeClaim ReadWriteOnce (RWO)

  1. Salva il seguente manifest PersistentVolumeClaim in un file denominato producer-pvc.yaml. Utilizzerai la classe StorageClass creata in precedenza. Assicurati che il disco abbia una capacità sufficiente per archiviare i dati.

    kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: producer-pvc
spec:
  storageClassName: hyperdisk-ml
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 300Gi

  2. Crea il PersistentVolumeClaim eseguendo questo comando:

    kubectl create -f producer-pvc.yaml

Crea un job Kubernetes per compilare il volume Google Cloud Hyperdisk montato

Questa sezione mostra un esempio di creazione di un job Kubernetes che esegue il provisioning di un disco e scarica il modello ottimizzato per le istruzioni Gemma 7B da Hugging Face sul volume Google Cloud Hyperdisk montato.

  1. Per accedere all'LLM Gemma utilizzato dagli esempi in questa guida, crea un secret Kubernetes contenente il token Hugging Face:

    kubectl create secret generic hf-secret \
    --from-literal=hf_api_token=HF_TOKEN\
    --dry-run=client -o yaml | kubectl apply -f -

    Sostituisci HF_TOKEN con il token Hugging Face generato in precedenza.

  2. Salva il seguente manifest di esempio come producer-job.yaml:

    apiVersion: batch/v1
kind: Job
metadata:
  name: producer-job
spec:
  template:  # Template for the Pods the Job will create
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: cloud.google.com/compute-class
                operator: In
                values:
                - "Performance"
            - matchExpressions:
              - key: cloud.google.com/machine-family
                operator: In
                values:
                - "c3"
            - matchExpressions:
              - key: topology.kubernetes.io/zone
                operator: In
                values:
                - "ZONE"
      containers:
      - name: copy
        resources:
          requests:
            cpu: "32"
          limits:
            cpu: "32"
        image: huggingface/downloader:0.17.3
        command: [ "huggingface-cli" ]
        args:
        - download
        - google/gemma-1.1-7b-it
        - --local-dir=/data/gemma-7b
        - --local-dir-use-symlinks=False
        env:
        - name: HUGGING_FACE_HUB_TOKEN
          valueFrom:
            secretKeyRef:
              name: hf-secret
              key: hf_api_token
        volumeMounts:
          - mountPath: "/data"
            name: volume
      restartPolicy: Never
      volumes:
        - name: volume
          persistentVolumeClaim:
            claimName: producer-pvc
  parallelism: 1         # Run 1 Pods concurrently
  completions: 1         # Once 1 Pods complete successfully, the Job is done
  backoffLimit: 4        # Max retries on failure

    Sostituisci ZONE con la zona di computing in cui vuoi che venga creato l'hyperdisk. Se la utilizzi con l'esempio di deployment, assicurati che sia una zona con capacità di macchine G2.

  3. Crea il job eseguendo questo comando:

    kubectl apply -f producer-job.yaml

    Potrebbero essere necessari alcuni minuti prima che il job completi la copia dei dati sul volume del Persistent Disk. Al termine del provisioning del job, lo stato viene contrassegnato come "Completato".

  4. Per controllare l'avanzamento dello stato del job, esegui il seguente comando:

    kubectl get job producer-job

  5. Al termine del job, puoi eseguire la relativa pulizia con questo comando:

    kubectl delete job producer-job

Crea un volume Hyperdisk ML ReadOnlyMany da un Google Cloud Hyperdisk preesistente

Questa sezione illustra i passaggi per creare una coppia di volumi permanenti ReadOnlyMany (ROM) e una richiesta di volume permanente da un volume Google Cloud Hyperdisk preesistente. Per scoprire di più, consulta Utilizzo di dischi permanenti preesistenti come volumi permanenti.

  1. In GKE versione 1.30.2-gke.1394000 e successive, GKE converte automaticamente la modalità di accesso di un volume Google Cloud Hyperdisk in READ_ONLY_MANY.READ_WRITE_SINGLE

    Se utilizzi un volume Google Cloud Hyperdisk preesistente su una versione precedente di GKE, devi modificare manualmente la modalità di accesso eseguendo il seguente comando:

    gcloud compute disks update HDML_DISK_NAME \
    --zone=ZONE \
    --access-mode=READ_ONLY_MANY

    Sostituisci i seguenti valori:

    • HDML_DISK_NAME: il nome del volume Hyperdisk ML.
    • ZONE: la zona di calcolo in cui è stato creato il volume Google Cloud Hyperdisk preesistente.

  2. Crea una coppia di PersistentVolume e PersistentVolumeClaim facendo riferimento al disco che hai compilato in precedenza.

    1. Salva il seguente manifest come hdml-static-pv.yaml:

      apiVersion: v1
kind: PersistentVolume
metadata:
  name: hdml-static-pv
spec:
  storageClassName: "hyperdisk-ml"
  capacity:
    storage: 300Gi
  accessModes:
    - ReadOnlyMany
  claimRef:
    namespace: default
    name: hdml-static-pvc
  csi:
    driver: pd.csi.storage.gke.io
    volumeHandle: projects/PROJECT/zones/ZONE/disks/DISK_NAME
    fsType: ext4
    readOnly: true
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: topology.gke.io/zone
          operator: In
          values:
          - ZONE
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  namespace: default
  name: hdml-static-pvc
spec:
  storageClassName: "hyperdisk-ml"
  volumeName: hdml-static-pv
  accessModes:
  - ReadOnlyMany
  resources:
    requests:
      storage: 300Gi

      Sostituisci i seguenti valori:

      • PROJECT: il progetto in cui è creato il cluster GKE.
      • ZONE: la zona in cui viene creato il volume Google Cloud Hyperdisk preesistente.
      • DISK_NAME: il nome del volume Google Cloud Hyperdisk preesistente.

    2. Crea le risorse PersistentVolume e PersistentVolumeClaim eseguendo questo comando:

      kubectl apply -f hdml-static-pv.yaml

Crea un volume Hyperdisk ML ReadOnlyMany multizona da un VolumeSnapshot

Questa sezione illustra i passaggi per creare un volume ML Hyperdisk multizona in modalità di accesso ReadOnlyMany. Utilizzi un VolumeSnapshot per un'immagine disco di un disco permanente preesistente. Per scoprire di più, consulta Eseguire il backup dello spazio di archiviazione Persistent Disk utilizzando gli snapshot dei volumi.

Per creare il volume ML Hyperdisk multizona:

Crea uno snapshot del volume del disco

  1. Salva il seguente manifest come file denominato disk-image-vsc.yaml.

    apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: disk-image-vsc
driver: pd.csi.storage.gke.io
deletionPolicy: Delete
parameters:
  snapshot-type: images

  2. Crea la classe VolumeSnapshotClass eseguendo il seguente comando:

    kubectl apply -f disk-image-vsc.yaml

  3. Salva il seguente manifest come file denominato my-snapshot.yaml. Farete riferimento al PersistentVolumeClaim creato in precedenza in Creare un PersistentVolumeClaim ReadWriteOnce (RWO).

    apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: my-snapshot
spec:
  volumeSnapshotClassName: disk-image-vsc
  source:
    persistentVolumeClaimName: producer-pvc

  4. Crea il VolumeSnapshot eseguendo il seguente comando:

    kubectl apply -f my-snapshot.yaml

  5. Quando il VolumeSnapshot è contrassegnato come "Pronto", esegui il seguente comando per creare il volume Hyperdisk ML:

    kubectl wait --for=jsonpath='{.status.readyToUse}'=true \
    --timeout=300s volumesnapshot my-snapshot

Creare una classe StorageClass multi-zonale

Se vuoi che le copie dei dati siano accessibili in più di una zona, specifica il parametro enable-multi-zone-provisioning in StorageClass, che crea i dischi nelle zone specificate nel campo allowedTopologies.

Per creare StorageClass:

  1. Salva il seguente manifest come file denominato hyperdisk-ml-multi-zone.yaml.

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: hyperdisk-ml-multi-zone
parameters:
  type: hyperdisk-ml
  provisioned-throughput-on-create: "2400Mi"
  enable-multi-zone-provisioning: "true"
provisioner: pd.csi.storage.gke.io
allowVolumeExpansion: false
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowedTopologies:
- matchLabelExpressions:
  - key: topology.gke.io/zone
    values:
    - ZONE_1
    - ZONE_2

    Sostituisci ZONE_1, ZONE_2, ..., ZONE_N con le zone in cui è possibile accedere allo spazio di archiviazione.

    Questo esempio imposta volumeBindingMode su Immediate, consentendo a GKE di eseguire il provisioning del PersistentVolumeClaim prima che qualsiasi consumatore vi faccia riferimento.

  2. Crea StorageClass eseguendo il seguente comando:

    kubectl apply -f hyperdisk-ml-multi-zone.yaml

Crea un oggetto PersistentVolumeClaim che utilizzi la classe di archiviazione multi-zonale

Il passaggio successivo consiste nel creare un oggetto PersistentVolumeClaim che faccia riferimento alla classe di archiviazione.

GKE utilizza i contenuti dell'immagine disco specificata per eseguire automaticamente il provisioning di un volume Hyperdisk ML in ogni zona specificata nello snapshot.

Per creare la richiesta di volume persistente:

  1. Salva il seguente manifest come file denominato hdml-consumer-pvc.yaml.

    kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: hdml-consumer-pvc
spec:
  dataSource:
    name: my-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
  - ReadOnlyMany
  storageClassName: hyperdisk-ml-multi-zone
  resources:
    requests:
      storage: 300Gi

  2. Crea il PersistentVolumeClaim eseguendo il seguente comando:

    kubectl apply -f hdml-consumer-pvc.yaml

Crea un deployment per utilizzare il volume Hyperdisk ML

Quando utilizzi i pod con i volumi permanenti, ti consigliamo di utilizzare un controller dei carichi di lavoro (ad esempio un deployment o un StatefulSet).

Se vuoi utilizzare un PersistentVolume preesistente in modalità ReadOnlyMany con un deployment, consulta Utilizzare i dischi permanenti con più lettori.

Per creare e testare il deployment:

  1. Salva il seguente manifest di esempio come vllm-gemma-deployment.

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-gemma-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: gemma-server
  template:
    metadata:
      labels:
        app: gemma-server
        ai.gke.io/model: gemma-7b
        ai.gke.io/inference-server: vllm
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: security
                  operator: In
                  values:
                  - S2
              topologyKey: topology.kubernetes.io/zone
      containers:
      - name: inference-server
        image: us-docker.pkg.dev/vertex-ai/vertex-vision-model-garden-dockers/pytorch-vllm-serve:latest
        resources:
          requests:
            cpu: "2"
            memory: "25Gi"
            ephemeral-storage: "25Gi"
            nvidia.com/gpu: 2
          limits:
            cpu: "2"
            memory: "25Gi"
            ephemeral-storage: "25Gi"
            nvidia.com/gpu: 2
        command: ["python3", "-m", "vllm.entrypoints.api_server"]
        args:
        - --model=$(MODEL_ID)
        - --tensor-parallel-size=2
        env:
        - name: MODEL_ID
          value: /models/gemma-7b
        volumeMounts:
        - mountPath: /dev/shm
          name: dshm
        - mountPath: /models
          name: gemma-7b
      volumes:
      - name: dshm
        emptyDir:
            medium: Memory
      - name: gemma-7b
        persistentVolumeClaim:
          claimName: CLAIM_NAME
      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

    Sostituisci CLAIM_NAME con uno di questi valori:

    • hdml-static-pvc: se utilizzi un volume Hyperdisk ML da un Google Cloud Hyperdisk esistente.
    • hdml-consumer-pvc: se utilizzi un volume Hyperdisk ML da un'immagine disco VolumeSnapshot.

  2. Esegui il seguente comando per attendere che il server di inferenza sia disponibile:

    kubectl wait --for=condition=Available --timeout=700s deployment/vllm-gemma-deployment

  3. Per verificare che il server vLLM sia attivo e funzionante:

    1. Esegui il seguente comando per configurare il port forwarding al modello:

      kubectl port-forward service/llm-service 8000:8000

    2. Esegui un comando curl per inviare una richiesta al modello:

      USER_PROMPT="I'm new to coding. If you could only recommend one programming language to start with, what would it be and why?"

curl -X POST http://localhost:8000/generate \
-H "Content-Type: application/json" \
-d @- <<EOF
{
    "prompt": "<start_of_turn>user\n${USER_PROMPT}<end_of_turn>\n",
    "temperature": 0.90,
    "top_p": 1.0,
    "max_tokens": 128
}
EOF

    Il seguente output mostra un esempio di risposta del modello:

    {"predictions":["Prompt:\n<start_of_turn>user\nI'm new to coding. If you could only recommend one programming language to start with, what would it be and why?<end_of_turn>\nOutput:\nPython is often recommended for beginners due to its clear, readable syntax, simple data types, and extensive libraries.\n\n**Reasons why Python is a great language for beginners:**\n\n* **Easy to read:** Python's syntax is straightforward and uses natural language conventions, making it easier for beginners to understand the code.\n* **Simple data types:** Python has basic data types like integers, strings, and lists that are easy to grasp and manipulate.\n* **Extensive libraries:** Python has a vast collection of well-documented libraries covering various tasks, allowing beginners to build projects without reinventing the wheel.\n* **Large supportive community:**"]}

Ottimizza il valore di lettura anticipata

Se hai carichi di lavoro che eseguono I/O sequenziali, potresti trarre vantaggio dalla regolazione del valore di lettura anticipata. In genere, si applica ai carichi di lavoro di inferenza o addestramento che devono caricare i pesi dei modelli di IA/ML nella memoria. La maggior parte dei carichi di lavoro con I/O sequenziale solitamente registra un miglioramento delle prestazioni con un valore di lettura anticipata pari o superiore a 1024 KB.

Puoi specificare questa opzione tramite l'opzione di montaggio read_ahead_kb quando esegui il provisioning statico di un nuovo PersistentVolume o quando modifichi un PersistentVolume di cui è stato eseguito il provisioning dinamico.

L'esempio seguente mostra come ottimizzare il valore di lettura anticipata su 4096 KB.

apiVersion: v1
kind: PersistentVolume
  name: DISK_NAME
spec:
  accessModes:
  - ReadOnlyMany
  capacity:
    storage: 300Gi
  csi:
    driver: pd.csi.storage.gke.io
    fsType: ext4
    readOnly: true
    volumeHandle: projects/PROJECT/zones/ZONE/disks/DISK_NAME
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: topology.gke.io/zone
          operator: In
          values:
          - ZONE
  storageClassName: hyperdisk-ml
  mountOptions:
  - read_ahead_kb=4096

Sostituisci i seguenti valori:

  • DISK_NAME: il nome del volume Google Cloud Hyperdisk preesistente.
  • ZONE: la zona in cui viene creato il volume Google Cloud Hyperdisk preesistente.

Eseguire test e benchmark sul rendimento del volume Hyperdisk ML

Questa sezione mostra come utilizzare Flexible I/O Tester (FIO) per eseguire il benchmark delle prestazioni dei volumi ML Hyperdisk per la lettura di dati preesistenti . Puoi utilizzare queste metriche per valutare il rendimento del volume per carichi di lavoro e configurazioni specifici.

  1. Salva il seguente manifest di esempio come benchmark-job.yaml:

    apiVersion: batch/v1
kind: Job
metadata:
  name: benchmark-job
spec:
  template:  # Template for the Pods the Job will create
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: cloud.google.com/compute-class
                operator: In
                values:
                - "Performance"
            - matchExpressions:
              - key: cloud.google.com/machine-family
                operator: In
                values:
                - "c3"

      containers:
      - name: fio
        resources:
          requests:
            cpu: "32"
        image: litmuschaos/fio
        args:
        - fio
        - --filename
        - /models/gemma-7b/model-00001-of-00004.safetensors:/models/gemma-7b/model-00002-of-00004.safetensors:/models/gemma-7b/model-00003-of-00004.safetensors:/models/gemma-7b/model-00004-of-00004.safetensors:/models/gemma-7b/model-00004-of-00004.safetensors
        - --direct=1
        - --rw=read
        - --readonly
        - --bs=4096k
        - --ioengine=libaio
        - --iodepth=8
        - --runtime=60
        - --numjobs=1
        - --name=read_benchmark
        volumeMounts:
        - mountPath: "/models"
          name: volume
      restartPolicy: Never
      volumes:
      - name: volume
        persistentVolumeClaim:
          claimName: hdml-static-pvc
  parallelism: 1         # Run 1 Pods concurrently
  completions: 1         # Once 1 Pods complete successfully, the Job is done
  backoffLimit: 1        # Max retries on failure

    Sostituisci CLAIM_NAME con il nome del PersistentVolumeClaim (ad esempio hdml-static-pvc).

  2. Crea il job eseguendo il seguente comando:

    kubectl apply -f benchmark-job.yaml.

  3. Utilizza i log kubectl per visualizzare l'output dello strumento fio:

    kubectl logs benchmark-job-nrk88 -f

    L'output è simile al seguente:

    read_benchmark: (g=0): rw=read, bs=4M-4M/4M-4M/4M-4M, ioengine=libaio, iodepth=8
fio-2.2.10
Starting 1 process

read_benchmark: (groupid=0, jobs=1): err= 0: pid=32: Fri Jul 12 21:29:32 2024
read : io=18300MB, bw=2407.3MB/s, iops=601, runt=  7602msec
    slat (usec): min=86, max=1614, avg=111.17, stdev=64.46
    clat (msec): min=2, max=33, avg=13.17, stdev= 1.08
    lat (msec): min=2, max=33, avg=13.28, stdev= 1.06
    clat percentiles (usec):
    |  1.00th=[11072],  5.00th=[12352], 10.00th=[12608], 20.00th=[12736],
    | 30.00th=[12992], 40.00th=[13120], 50.00th=[13248], 60.00th=[13376],
    | 70.00th=[13504], 80.00th=[13632], 90.00th=[13888], 95.00th=[14016],
    | 99.00th=[14400], 99.50th=[15296], 99.90th=[22144], 99.95th=[25728],
    | 99.99th=[33024]
    bw (MB  /s): min= 2395, max= 2514, per=100.00%, avg=2409.79, stdev=29.34
    lat (msec) : 4=0.39%, 10=0.31%, 20=99.15%, 50=0.15%
cpu          : usr=0.28%, sys=8.08%, ctx=4555, majf=0, minf=8203
IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=99.8%, 16=0.0%, 32=0.0%, >=64=0.0%
    submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
    complete  : 0=0.0%, 4=100.0%, 8=0.1%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
    issued    : total=r=4575/w=0/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
    latency   : target=0, window=0, percentile=100.00%, depth=8

Run status group 0 (all jobs):
READ: io=18300MB, aggrb=2407.3MB/s, minb=2407.3MB/s, maxb=2407.3MB/s, mint=7602msec, maxt=7602msec

Disk stats (read/write):
nvme0n2: ios=71239/0, merge=0/0, ticks=868737/0, in_queue=868737, util=98.72%

Monitorare il throughput o le IOPS su un volume Hyperdisk ML

Per monitorare le prestazioni di provisioning del volume ML Hyperdisk, consulta Analisi delle IOPS e del throughput di provisioning nella documentazione di Compute Engine.

Per aggiornare il throughput o le IOPS di un volume Hyperdisk per l'apprendimento automatico esistente o per scoprire altri parametri di Google Cloud Hyperdisk che puoi specificare nella classe di archiviazione, consulta Eseguire la scalabilità delle prestazioni di archiviazione utilizzando Hyperdisk di Google Cloud.

Risoluzione dei problemi

Questa sezione fornisce indicazioni per la risoluzione dei problemi relativi ai volumi ML Hyperdisk su GKE.

Impossibile aggiornare la modalità di accesso al disco

Il seguente errore si verifica quando un volume ML Hyperdisk è già in uso e collegato da un nodo in modalità di accesso ReadWriteOnce.

AttachVolume.Attach failed for volume ... Failed to update access mode:
failed to set access mode for zonal volume ...
'Access mode cannot be updated when the disk is attached to instance(s).'., invalidResourceUsage

GKE aggiorna automaticamente il valore accessMode del volume Hyperdisk ML da READ_WRITE_SINGLE a READ_ONLY_MANY quando viene utilizzato da un volume Persistent con modalità di accesso ReadOnlyMany. Questo aggiornamento viene eseguito quando il disco viene collegato a un nuovo nodo.

Per risolvere il problema, elimina tutti i pod che fanno riferimento al disco utilizzando un volume permanente in modalità ReadWriteOnce. Attendi che il disco venga scollegato, quindi ricrea il workload che utilizza il PersistentVolume in modalità ReadOnlyMany.

Il disco non può essere collegato con la modalità READ_WRITE

Il seguente errore indica che GKE ha tentato di collegare un volume ML Hyperdisk in modalità di accesso READ_ONLY_MANY a un nodo GKE utilizzando la modalità di accesso ReadWriteOnce.

AttachVolume.Attach failed for volume ...
Failed to Attach: failed cloud service attach disk call ...
The disk cannot be attached with READ_WRITE mode., badRequest

GKE aggiorna automaticamente il valore accessMode del volume Hyperdisk ML da READ_WRITE_SINGLE a READ_ONLY_MANY quando viene utilizzato da un volume Persistent con modalità di accesso ReadOnlyMany. Tuttavia, GKE non aggiornerà automaticamente la modalità di accesso da READ_ONLY_MANY a READ_WRITE_SINGLE. Si tratta di un meccanismo di sicurezza per garantire che i dischi multizona non vengano scritti per errore, poiché ciò potrebbe comportare contenuti divergenti tra i dischi multizona.

Per risolvere il problema, ti consigliamo di seguire il flusso di lavoro Pre-cache data to a Persistent Disk disk image (Pre-cache i dati in un'immagine disco del disco permanente) se hai bisogno di contenuti aggiornati. Se hai bisogno di un maggiore controllo sulla modalità di accesso e su altre impostazioni del volume Hyperdisk ML, consulta Modificare le impostazioni di un Google Cloud Hyperdisk Cloud.

Quota superata: quota di throughput insufficiente

Il seguente errore indica che la quota di throughput Hyperdisk ML era insufficiente al momento del provisioning del disco.

failed to provision volume with StorageClass ... failed (QUOTA_EXCEEDED): Quota 'HDML_TOTAL_THROUGHPUT' exceeded

Per risolvere il problema, consulta la sezione Quota di disco per scoprire di più sulla quota Hyperdisk e su come aumentarla nel tuo progetto.

Per ulteriori indicazioni sulla risoluzione dei problemi, consulta Escala le prestazioni dello spazio di archiviazione con Hyperdisk di Google Cloud.

Passaggi successivi