Accelera il caricamento dei dati IA/ML con Hyperdisk ML

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

Panoramica

Hyperdisk ML è una soluzione di archiviazione ad alte prestazioni che può essere utilizzata lo scale out delle applicazioni. Offre un'elevata velocità effettiva aggregata a molti macchine virtuali contemporaneamente, il che lo rende ideale se vuoi eseguire AI/ML carichi di lavoro 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 diretto nel registro dei modelli. Questa accelerazione è resa possibile dal software Google Cloud Hyperdisk che consente di scalare fino a 2500 nodi simultanei 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 la pubblicazione. Il disco permanente per l'immagine del disco deve essere compatibile con Hyperdisk di Google Cloud.
  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. Facoltativamente, puoi creare classi di archiviazione multizona per fare in modo che i dati siano disponibili in tutti in cui verranno eseguiti i tuoi pod.
  3. Crea un deployment Kubernetes per utilizzare il volume Hyperdisk ML: fai riferimento al volume Hyperdisk ML con velocità per il caricamento dei dati da parte delle applicazioni.

Volumi Hyperdisk ML multizona

I dischi Hyperdisk ML sono disponibili solo in una singola zona. Facoltativamente, puoi puoi utilizzare la funzionalità multizona Hyperdisk ML per collegare più dischi a livello di zona contenenti gli stessi contenuti in un'unica e PersistentVolumeClaim e PersistentVolume. I dischi zonali a cui fa riferimento la funzionalità multizona devono trovarsi nella stessa regione. Ad esempio, se viene creato un cluster a livello di regione us-central1, i dischi multizona devono trovarsi nella stessa regione (ad es. 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à e l'efficienza in termini di costi degli acceleratori con le VM spot. Poiché Hyperdisk ML è in 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.

Hydration di Hyperdisk ML da origini dati esterne e creazione di PV multizona per l'accesso ai dati tra zone.

I volumi Hyperdisk ML multizona hanno le seguenti limitazioni:

  • Le operazioni di ridimensionamento del volume e snapshot del volume non sono supportate.
  • I volumi Hyperdisk ML 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 presenta contenuti divergenti, assicurati che la tua applicazione tenga conto delle potenziali incoerenze tra le zone.

Per saperne di più, vedi Crea un volume ReadOnlymany Hyperdisk ML multizona da un volume VolumeSnapshot.

Prima di iniziare

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

  • Attiva l'API Google Kubernetes Engine.
    • Abilita 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 abbia una quota sufficiente per creare i nodi necessari in questa guida. Il codice di esempio per il cluster GKE e la creazione di risorse Kubernetes richiede la seguente quota minima nel regione di tua scelta: 88 CPU C3, 8 GPU NVIDIA L4.

Requisiti

Per utilizzare i volumi Hyperdisk ML 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 GKE minima o successiva, richieste per questo conducente.
  • Assicurati che Driver CSI per il disco permanente di Compute Engine sia abilitato. Il driver del disco permanente di Compute Engine è abilitato da automaticamente sui nuovi cluster Autopilot e Standard e o la modifica delle immagini quando si usa Autopilot. Se devi abilitare il driver CSI per il disco permanente di Compute Engine dal tuo cluster, consulta Abilitazione del driver CSI per il disco permanente di Compute Engine in un cluster esistente.
  • Se vuoi ottimizzare il valore di readahead, usa la versione 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. A Scopri di più, consulta Informazioni su Google Cloud Hyperdisk nella documentazione di Compute Engine.

Ottieni l'accesso al modello

Per ottenere l'accesso ai modelli Gemma per il deployment in GKE, devi prima firmare il contratto di consenso per la licenza, quindi generare Token di accesso a Hugging Face.

Devi firmare il contratto di consenso per utilizzare Gemma. Segui queste istruzioni:

  1. Accedi alla pagina del consenso del modello 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 usare una modalità Autopilot per un'esperienza Kubernetes completamente gestita. Per scegliere il la modalità operativa GKE più adatta ai tuoi carichi di lavoro, consulta Scegliere una modalità operativa di 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 tuo cluster:

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

Standard

  1. In Cloud Shell, esegui questo comando per creare Cluster di 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. Controlla quale regioni in cui sono disponibili le GPU L4.
    • ZONES: le zone in cui vengono creati i nodi. Puoi specificare tutte le zone necessarie per il cluster. Tutte le zone devono essere nella stessa regione del piano di controllo del cluster, specificato dal flag --zone. Per i cluster di zona, --node-locations deve contenere nella zona principale del cluster.
    • PROJECT: l'ID del progetto Google Cloud.

    La creazione del cluster potrebbe richiedere diversi minuti.

  2. Configura kubectl per comunicare con il tuo cluster:

    gcloud container clusters get-credentials hdml-gpu-l4

Pre-memorizzazione dei dati nella cache in un'immagine disco permanente

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 tuoi quando il carico di lavoro ne ha bisogno.

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

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 oggetto PersistentVolumeClaim (RWO) ReadWriteOnce

  1. Salva il seguente manifest PersistentVolumeClaim in un file denominato producer-pvc.yaml. Utilizzerai la classe StorageClass creata in precedenza. Assicurati che che il disco abbia 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 l'oggetto PersistentVolumeClaim eseguendo questo comando:

    kubectl create -f producer-pvc.yaml

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

Questa sezione mostra un esempio di creazione di un job Kubernetes che esegue il provisioning di e scarica il modello ottimizzato per l'istruzione 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 l'Hyperdisk da creare. Se la utilizzi con Esempio di deployment: assicurati che sia una zona con capacità della macchina G2.

  3. Crea il job eseguendo questo comando:

    kubectl apply -f producer-job.yaml

    Il job potrebbe richiedere alcuni minuti per completare la copia dei dati volume Persistent Disk. Quando il job completa il provisioning, il suo stato è 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 ReadOnly Many Hyperdisk da un volume 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 Hyperdisk di Google Cloud preesistente. Per saperne 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 Hyperdisk di Google Cloud in READ_ONLY_MANY.

    Se utilizzi un volume Google Cloud Hyperdisk preesistente su una piattaforma di GKE, devi modificare manualmente la modalità di accesso eseguendo questo 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 computing in cui viene creato il volume preesistente Google Cloud Hyperdisk.

  2. Creare una coppia PersistentVolume e PersistentVolumeClaim, facendo riferimento popolato 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 viene creato il cluster GKE.
      • ZONE: la zona in cui viene creato il volume preesistente Google Cloud Hyperdisk.
      • DISK_NAME: il nome del volume Google Cloud Hyperdisk preesistente.

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

      kubectl apply -f hdml-static-pv.yaml

crea un volume ReadOnly Many Hyperdisk multizona da un oggetto VolumeSnapshot

Questa sezione illustra i passaggi per creare un volume Hyperdisk ML multizona in modalità di accesso ReadOnly Many. Utilizzi un VolumeSnapshot per un'immagine disco di un disco permanente preesistente. Per ulteriori informazioni, consulta Backup di un Persistent Disk spazio di archiviazione utilizzando snapshot di volumi.

Per creare il volume Hyperdisk ML multizona:

Crea un oggetto VolumeSnapshot del tuo 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 l'oggetto VolumeSnapshotClass eseguendo questo comando:

    kubectl apply -f disk-image-vsc.yaml

  3. Salva il seguente manifest come file denominato my-snapshot.yaml. Dovrai fare riferimento all'oggetto PersistentVolumeClaim creato Crea un oggetto ReadWriteOnce (RWO) PersistentVolumeClaim.

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

  4. Crea l'oggetto VolumeSnapshot eseguendo questo 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 tuoi dati siano accessibili in più di una zona, specifica il parametro enable-multi-zone-provisioning in StorageClass, crea 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 l'oggetto StorageClass eseguendo questo comando:

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

crea un oggetto PersistentVolumeClaim che utilizza un oggetto StorageClass multizona

Il passaggio successivo consiste nel creare un PersistentVolumeClaim che fa riferimento StorageClass.

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 PersistentVolume:

  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 l'oggetto PersistentVolumeClaim eseguendo questo comando:

    kubectl apply -f hdml-consumer-pvc.yaml

crea un deployment per consumare 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 usare un PersistentVolume preesistente in modalità ReadOnly Many con una Per il deployment, fai riferimento a Utilizzare 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 Hyperdisk Google Cloud esistente.
    • hdml-consumer-pvc: se utilizzano un volume Hyperdisk ML da un'immagine disco VolumeSnapshot.

  2. Esegui questo 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, potrebbero trarre vantaggio dall'ottimizzazione il valore readahead. 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 notare un miglioramento delle prestazioni con un valore di lettura di 1024 kB o superiore.

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 readahead 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 preesistente Google Cloud Hyperdisk.
  • ZONE: la zona in cui viene creato il volume preesistente Google Cloud Hyperdisk.

Eseguire test e benchmark sul rendimento del volume dell'apprendimento automatico di Hyperdisk

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 le prestazioni del volume per configurazioni e carichi di lavoro 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 tuo PersistentVolumeClaim (ad esempio, hdml-static-pvc).

  2. Crea il job eseguendo il seguente comando:

    kubectl apply -f benchmark-job.yaml.

  3. Utilizza i log di 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 la velocità effettiva o le IOPS su un volume ML Hyperdisk

Per monitorare le prestazioni di cui è stato eseguito il provisioning del volume Hyperdisk ML, vedi Analizzare la velocità effettiva e le IOPS sottoposte a provisioning nella documentazione di Compute Engine.

aggiornare la velocità effettiva o le IOPS di cui è stato eseguito il provisioning di un Hyperdisk ML esistente. o per saperne di più sui parametri aggiuntivi di Google Cloud Hyperdisk che puoi specifica in StorageClass, consulta Scalare le prestazioni di archiviazione utilizzando Google Cloud Hyperdisk.

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 persistente con modalità di accesso ReadOnlyMany. L'aggiornamento viene eseguito quando il disco collegate 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 carico di lavoro che utilizza l'oggetto PersistentVolume in modalità ReadOnlyDeploy.

Impossibile collegare il disco con la modalità READ_WRITE

L'errore seguente indica che GKE ha tentato di collegare un volume Hyperdisk ML in modalità di accesso READ_ONLY_MANY a un cluster 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 è utilizzato da una PersistentVolume in modalità di accesso ReadOnlyOnly. Tuttavia, GKE aggiorna 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 le Se esegui la pre-cache dei dati in un'immagine disco permanente hai bisogno di contenuti aggiornati. Se hai bisogno di un maggiore controllo la modalità di accesso al volume Hyperdisk ML e altre impostazioni, vedi Modificare le impostazioni di un volume Google Cloud Hyperdisk.

Quota superata - Quota di velocità effettiva insufficiente

Il seguente errore indica che Hyperdisk ML era insufficiente della velocità effettiva massima al momento del provisioning del disco.

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

Per risolvere questo problema, consulta Quote del disco per scopri di più sulla quota Hyperdisk e su come aumentare il disco per il progetto.

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

Passaggi successivi