Usa un acceleratore distribuito per lo storage cloud con Run:ai Model Streamer (anteprima)

Streamer di modello Run:ai legge contemporaneamente i tensori del modello e li trasmette alla memoria GPU, sovrapponendo le letture di archiviazione con i trasferimenti da CPU a GPU. Questa capacità può ridurre i tempi di caricamento del modello e il tempo di inattività della GPU durante l'avvio e lo scale-out del server di inferenza. Usarla per caricare i modelli SafeTensors da Archiviazione BLOB di Azure in vLLM perché supporta il caricamento diretto di oggetti e si integra con il caricamento di modelli di vLLM. Per l'integrazione a monte, vedere Caricamento dei modelli con lo streamer di modelli Run:ai.

Utilizzando un acceleratore distribuito per lo storage cloud (DACS), questo percorso di caricamento può anche riutilizzare i dati del modello memorizzati nella cache tra i carichi di lavoro. vLLM utilizza il backend Azure di Run:ai per caricare la libreria client nativa DACS. Le operazioni di lettura recuperano i dati memorizzati nella cache o prelevano i dati mancanti da gestione rete virtuale di Azure.

Questo articolo utilizza Run:ai Model Streamer 0.17.0, il pacchetto pubblico dacs-client==0.1.0 e la v0.1.0 build del server. La procedura principale installa le dipendenze nell'immagine del workload. Non richiede un'immagine client DACS separata né il supporto Kubernetes ImageVolume.

Completa Inizia con l'acceleratore distribuito per lo storage cloud su AKS prima di utilizzare questo articolo. Per fornire le librerie client DACS senza ricostruire l'immagine del carico di lavoro, vedi Montare le librerie client DACS con ImageVolume.

Prerequisites

• Una distribuzione DACS esistente e il suo nome host di discovery-service.
• Un pool di nodi GPU AKS con driver NVIDIA compatibili, un plugin per dispositivi e abbastanza memoria GPU per il tuo modello. Il seguente esempio utilizza bfloat16, che richiede una GPU compatibile.
• Per l'autenticazione dell'identità del carico di lavoro, un cluster del servizio Azure Kubernetes con l'emittente OIDC e ID dei carichi di lavoro di Microsoft Entra attivati. Vedi Abilita l'emittente OIDC e ID dei carichi di lavoro di Microsoft Entra su un cluster AKS.
• Un'immagine GPU vLLM compatibile e un ambiente Linux con glibc 2.35 o versioni successive. Usa lo stesso ambiente Python della tua applicazione.
• Un contenitore Blob privato per file modello.
• Un utente caricatore separato o un'identità gestita con Storage Blob Data Contributor sul contenitore del modello.
• Un'identità di inferenza con Lettore dei dati del BLOB di archiviazione sul contenitore del modello. Configurare un metodo in Configura l'autenticazione BLOB.
• Autorizzazione a compilare e pubblicare l'immagine del tuo workload e autorizzazione per AKS a estrarla.
• Interfaccia della riga di comando di Azure, AzCopy v10 e l'interfaccia della riga di comando Hugging Face sul computer di preparazione per caricare un modello.

La preparazione del modello non richiede una GPU. Puoi anche controllare l'installazione dei pacchetti, il caricamento della libreria nativa e l'autenticazione Blob sui nodi CPU con un'immagine applicativa compatibile. Questi controlli non convalidano la pianificazione della GPU, la dimensionamento della memoria o l'inferenza.

Carica file modello su gestione rete virtuale di Azure

Salta questa sezione se il modello completo è già nel tuo contenitore privato. Per un test di cache a freddo, usare un prefisso del modello non ancora caricato tramite DACS.

Usare l'identità dell'autore del caricamento per questa procedura, non l'identità di inferenza. Per le assegnazioni di ruoli con scopo container, vedi Assegna un ruolo Azure per accedere ai dati blob. Azure control-plane Owner o Contributor da soli non concedono l'accesso ai dati Blob tramite Microsoft Entra ID.

Scarica il modello

Il seguente esempio scarica i file di inferenza per SmolLM2-135M-Instruct a una revisione fissa. La sua scheda modello identifica la licenza come Apache-2.0. Installa la CLI di Hugging Face, poi esegui:

MODEL_ID="HuggingFaceTB/SmolLM2-135M-Instruct"
MODEL_REVISION="12fd25f77366fa6b3b4b768ec3050bf629380bac"
MODEL_DIR="$PWD/models/SmolLM2-135M-Instruct-$MODEL_REVISION"

hf download "$MODEL_ID" \
  config.json generation_config.json model.safetensors \
  tokenizer.json tokenizer_config.json special_tokens_map.json \
  vocab.json merges.txt README.md \
  --revision "$MODEL_REVISION" \
  --local-dir "$MODEL_DIR"

Opzionalmente, usa il comando hf cache verify di una CLI corrente per verificare i file scaricati rispetto ai checksum dell'Hub:

hf cache verify "$MODEL_ID" \
  --revision "$MODEL_REVISION" \
  --local-dir "$MODEL_DIR"

Poiché questo download seleziona solo file di inferenza, la verifica può segnalare file di repository mancanti, come varianti di modello non utilizzate. Può anche segnalare ulteriori metadati locali di download di Hugging Face. Questi messaggi non sono errori di checksum. Verificare i file imprevisti o la mancata corrispondenza del checksum prima di caricare.

Per un altro modello, includere tutti gli shard di SafeTensors e qualsiasi indice di peso, configurazione del modello e di generazione, file tokenizer e file di licenza e attribuzione applicabili. Conserva la struttura di directory richiesta. Non includere varianti ONNX non correlate, checkpoint di training, file ottimizzatori o credenziali.

Carica con AzCopy

Installa AzCopy v10. Accedi tramite interfaccia della riga di comando di Azure come utente caricatore, poi copia il contenuto della directory locale in un nuovo prefisso Blob:

TENANT_ID="<tenant-id>"
STORAGE_ACCOUNT="<storage-account>"
CONTAINER="<container>"
RUN_ID="$(date -u +%Y%m%dT%H%M%SZ)"
MODEL_PREFIX="models/SmolLM2-135M-Instruct-${MODEL_REVISION}-${RUN_ID}"
MODEL_URL="https://${STORAGE_ACCOUNT}.blob.core.windows.net/${CONTAINER}/${MODEL_PREFIX}"

az login --tenant "$TENANT_ID"
export AZCOPY_AUTO_LOGIN_TYPE=AZCLI
export AZCOPY_TENANT_ID="$TENANT_ID"

azcopy copy "$MODEL_DIR/*" "$MODEL_URL" \
  --recursive=true \
  --overwrite=false \
  --exclude-path ".cache;.git"

azcopy list "$MODEL_URL"

Il carattere jolly tra virgolette copia il contenuto della directory direttamente nel prefisso senza aggiungere un livello di directory locale. Le esclusioni omettono i metadati di download e Git. Continua solo dopo che AzCopy non riporta alcun trasferimento non riuscito e la destinazione contiene tutti i file richiesti. Per ulteriori informazioni, consulta Carica contenuti della directory con AzCopy e Autorizza AzCopy usando interfaccia della riga di comando di Azure.

Per un uploader che gira su una VM Azure, puoi invece autorizzare AzCopy con un'identità gestita. Mantieni il container privato e rimuovi le assegnazioni temporanee di ruolo di uploader dopo la preparazione. Attendere il tempo necessario affinché le nuove assegnazioni di ruolo si propaghino; non aggirare gli errori di autorizzazione aggiungendo chiavi di archiviazione o segreti client.

Registra la revisione del modello e le versioni Blob o ETags. La posizione del modello Run:ai è az://<container>/<model-prefix>. Mantieni questi file invariati tra carichi a freddo e caldo. Per un altro cold test, usa un nuovo prefisso invece di eliminare i dati da una cache condivisa.

Prepara l'immagine del carico di lavoro senza ImageVolume

Installa le dipendenze durante la costruzione dell'immagine, non all'avvio del pod. Mantenere l'applicazione esistente, l'immagine di base e il punto di ingresso. Utilizzare il gestore di pacchetti dell'applicazione e il flusso di lavoro di requisiti o vincoli per preservare dipendenze compatibili, inclusi Torch, CUDA e NumPy.

Usa un'immagine vLLM abilitata alla GPU con versioni Torch e CUDA compatibili con i tuoi nodi GPU e i driver NVIDIA. Controlla i pacchetti Run:ai core e backend Azure installati nell'immagine prima di aggiungere dipendenze; non tutte le immagini vLLM includono il backend Azure.

Risolvere i conflitti di dipendenza nell'immagine del carico di lavoro prima di eseguire la distribuzione. Il passaggio pip check nella sezione seguente deve essere completato con successo. Usa i vincoli di dipendenza della tua applicazione per preservare la compatibilità con altri pacchetti installati.

1. Se la tua immagine non contiene già i pacchetti compatibili di Run:ai core e Azure backend, aggiungi la seguente istruzione al tuo Dockerfile:

   RUN python3 -m pip install --no-cache-dir "runai-model-streamer[azure]==0.17.0"
   

2. Installa il pacchetto client DACS pubblico, che fornisce le librerie client native, nello stesso ambiente Python:

   RUN python3 -m pip install --no-cache-dir "dacs-client==0.1.0" && \
       python3 -m pip check
   

   Azure extra di Run:ai non installa le librerie client DACS. Se la tua applicazione ha già pacchetti Run:ai compatibili, è necessaria solo l'installazione del pacchetto client DACS.

3. Compila e spingi usando il tuo Dockerfile e il contesto di build esistente. Esegui i seguenti comandi in Bash sulla tua macchina di preparazione. Questo esempio è costruito per nodi x86-64:

   REGISTRY_NAME="<registry-name>"
   REGISTRY_SERVER="$(az acr show --name "$REGISTRY_NAME" --query loginServer --output tsv)"
   WORKLOAD_IMAGE="$REGISTRY_SERVER/workload-runai-dacs:0.17.0-0.1.0"
   
   az acr login --name "$REGISTRY_NAME"
   docker build --platform linux/amd64 -t "$WORKLOAD_IMAGE" .
   docker push "$WORKLOAD_IMAGE"
   

4. Nella stessa sessione Bash, risolvi il percorso della libreria nativa dall'immagine costruita:

   docker run --rm --entrypoint python3 "$WORKLOAD_IMAGE" \
     -c 'from importlib.metadata import distribution; from pathlib import Path; p=Path(distribution("dacs-client").locate_file("py_dacs_client/libStorageDirect.so")).resolve(); assert p.is_file(), p; print(p)'
   

   Usa il percorso assoluto stampato quando configuri il workload. Mantenere l'installazione completa del client, incluse le librerie native di pari livello.

Preferisci un digest immutabile dell'immagine durante il dispiegamento. Aggiornare il client integrato richiede di ricostruire e ridistribuire l'immagine del carico di lavoro.

Configura l'autenticazione Blob

Usa l'identità del carico di lavoro AKS per l'autenticazione del Blob. L'esempio di distribuzione utilizza questo metodo con Storage Blob Data Reader con ambito sul contenitore del modello. Il permesso di scrittura dell'utente che carica non è necessario per l'inferenza. Per altri metodi di autenticazione, vedi autenticazione Azure nella documentazione di Run:ai Model Streamer.

Usa l'identità del carico di lavoro AKS

L'esempio di distribuzione utilizza ServiceAccount runai-reader nel runai-dacs namespace. Completare i seguenti passaggi prima di distribuire il carico di lavoro:

1. Abilita l'emittente OIDC e ID dei carichi di lavoro di Microsoft Entra sul tuo cluster AKS esistente, se non sono già abilitati.

2. Recupera l'URL dell'emittente OIDC.

3. Crea un'identità gestita, oppure seleziona un'identità esistente.

4. Se il runai-dacs spazio dei nomi non esiste già, crealo.

   kubectl create namespace runai-dacs
   

5. Crea un Kubernetes ServiceAccount annotato con l'ID client di quell'identità.

6. Crea la credenziale di identità federata per lo spazio di nomi esatto e ServiceAccount. Non è necessario completare i passaggi successivi di Key Vault.

Assegnare il ruolo di lettore BLOB all'identità gestita federata all'applicazione ServiceAccount. Per un esempio di assegnazione con scopo container, vedi Concedere accesso di lettura ai dati del modello, sostituendo questa identità con l'identità kubelet del quickstart.

Il pod deve selezionare il ServiceAccount e avere l'etichetta azure.workload.identity/use: "true". AKS inietta le impostazioni di identità e il token proiettato. Non aggiungere manualmente segreti client o chiavi di account di archiviazione.

Configura separatamente l'accesso al pull dell'immagine

Per le immagini del Registro Azure Container private, configurare le autorizzazioni di pull dell'identità kubelet come descritto in Aggiungere il client a un'immagine del carico di lavoro. Usa AcrPull per il classico RBAC. Per un registro abilitato per ABAC, utilizzare Container Registry Repository Reader con un accesso appropriato al repository. Non usare --attach-acr per il registro.

L'accesso in lettura BLOB per l'identità dell'applicazione non concede l'accesso del pull dell'immagine al kubelet. Per ImageVolume, l'accesso pull deve coprire sia il carico di lavoro che le immagini client, inclusi registri o repository separati quando applicabile.

Configurare e distribuire il carico di lavoro

Imposta queste quattro variabili applicative prima di iniziare vLLM. Sono separate dalle impostazioni di identità fornite dal tuo metodo di autenticazione:

Usa il formato URI modello di Run:ai, az://<container>/<model-prefix>, con l'account fornito tramite AZURE_STORAGE_ACCOUNT_NAME. Questo formato URI differisce dall'URI canonico del client Python nativo, che include il nome host dell'account.

Sostituisci i segnaposto nell'esempio seguente e salvalo con il nome runai-dacs-pod.yaml. Usa il prefisso modello del tuo upload e il percorso della libreria nativa stampato dall'immagine costruita. L'esempio utilizza l'identità del carico di lavoro e non contiene né ImageVolume né contenitore init:

apiVersion: v1
kind: Pod
metadata:
  name: runai-dacs-vllm
  namespace: runai-dacs
  labels:
    azure.workload.identity/use: "true"
spec:
  serviceAccountName: runai-reader
  restartPolicy: Never
  nodeSelector:
    agentpool: "<gpu-nodepool-name>"
  tolerations:
    - key: nvidia.com/gpu
      operator: Exists
      effect: NoSchedule
  containers:
    - name: vllm
      image: "<workload-image>"
      command: ["vllm", "serve"]
      args:
        - "az://<container>/<model-prefix>"
        - "--load-format"
        - "runai_streamer"
        - "--served-model-name"
        - "cached-model"
        - "--dtype"
        - "bfloat16"
        - "--max-model-len"
        - "1024"
      env:
        - name: AZURE_STORAGE_ACCOUNT_NAME
          value: "<storage-account>"
        - name: CACHE_DISCOVERY_URL
          value: "<cache-discovery-hostname>"
        - name: CACHE_SERVER_PORT
          value: "9065"
        - name: RUNAI_STREAMER_EXPERIMENTAL_AZURE_CACHE_LIB
          value: "<dacs-native-library-path>"
        - name: RUNAI_STREAMER_CHUNK_BYTESIZE
          value: "8388608"
        - name: SI_streamingChunkSize
          value: "8388608"
      resources:
        requests:
          cpu: "4"
          memory: 16Gi
        limits:
          cpu: "4"
          memory: 16Gi
          nvidia.com/gpu: 1
      ports:
        - containerPort: 8000
      readinessProbe:
        httpGet:
          path: /health
          port: 8000
        periodSeconds: 10
        timeoutSeconds: 5
      volumeMounts:
        - name: shm
          mountPath: /dev/shm
  volumes:
    - name: shm
      emptyDir:
        medium: Memory
        sizeLimit: 2Gi

Queste risorse illustrano un modello piccolo, non un modello 30B. Mantieni la pianificazione richiesta del carico di lavoro, le risorse, le sonde, la memoria condivisa e altri argomenti vLLM. Regola il numero di GPU, il parallelismo tensoriale, la lunghezza del modello e la dimensione della memoria per il tuo modello. Per un Deployment o uno StatefulSet, applica le etichette del Pod in spec.template.metadata e le impostazioni del Pod in spec.template.spec.

La prima distribuzione avvia vLLM e carica il modello prima che il Pod sia pronto. Per un confronto della cold cache, completare questi passaggi in ordine:

1. Selezionare i dati del modello che la cache non ha letto, come il prefisso aggiornato dalla procedura di caricamento. Non rimuovere i dati da una cache condivisa.

2. Prima di distribuire il Pod dell'applicazione, acquisisci un'istantanea di riferimento delle metriche da ogni Pod del server cache, come descritto in Monitorare l'acceleratore distribuito per l'archiviazione cloud. Registra il timestamp e i cache_server_upload_request_size_bytes_sum, cache_server_download_request_size_bytes_sum e cache_server_cache_size_bytes di ogni server.

3. Distribuire e ispezionare il pod accettato:

   kubectl apply --dry-run=server -f runai-dacs-pod.yaml
   kubectl apply -f runai-dacs-pod.yaml
   kubectl -n runai-dacs get pod runai-dacs-vllm -o yaml
   kubectl -n runai-dacs wait --for=condition=Ready pod/runai-dacs-vllm --timeout=30m
   

Controlla il runtime del carico di lavoro

Esegui questo controllo all'interno del container dell'applicazione vLLM, utilizzando l'eseguibile Python dell'applicazione. Verifica la coerenza dei pacchetti e il caricamento della libreria nativa, non l'autenticazione Blob o l'uso della cache:

kubectl -n runai-dacs exec -i runai-dacs-vllm -c vllm -- python3 - <<'PY'
import ctypes
import os
import subprocess
import sys
from importlib.metadata import version

for package in (
    "vllm",
    "torch",
    "runai-model-streamer",
    "runai-model-streamer-azure",
):
    print(f"{package}: {version(package)}", flush=True)

subprocess.run([sys.executable, "-m", "pip", "check"], check=True)

path = os.environ["RUNAI_STREAMER_EXPERIMENTAL_AZURE_CACHE_LIB"]
print(f"Checking DACS native library: {path}", flush=True)
library = ctypes.CDLL(path)
print(f"DACS native library loaded: {path}")
PY

Risolvere gli errori prima di continuare. Per il deployment della GPU, controlla anche la visibilità GPU e i log del motore di vLLM per confermare l'esecuzione CUDA e il modello dtype previsto. La prontezza o un caricamento riuscito della libreria da soli non dimostrano l'esecuzione della GPU o l'uso della cache DACS.

Verifica il comportamento della cache a freddo e a caldo

Usare la baseline delle metriche pre-distribuzione raccolte in Configurare e distribuire il carico di lavoro. Il caricamento del modello eseguito durante la distribuzione è il caricamento a freddo.

Verificare il carico a freddo

Ispeziona il registro delle applicazioni:

kubectl -n runai-dacs logs runai-dacs-vllm -c vllm

Cercare le ReadChunk stats native. RemoteClient conta le letture ponderate dell'archivio di supporto; RemoteCache conta le letture nella cache remota. Alcuni hit di cache durante il primo caricamento sono normali perché le letture precedenti possono popolare i dati. GetProperties Gli hit della cache descrivono i metadati, non gli hit dei pesi del modello.

Invia una richiesta di inferenza:

kubectl -n runai-dacs exec -i runai-dacs-vllm -c vllm -- python3 - <<'PY'
import json
import urllib.request

body = json.dumps({
    "model": "cached-model",
    "prompt": "Once upon a time",
    "max_tokens": 16,
    "temperature": 0,
}).encode()
request = urllib.request.Request(
    "http://127.0.0.1:8000/v1/completions", data=body,
    headers={"Content-Type": "application/json"},
)
with urllib.request.urlopen(request, timeout=600) as response:
    result = json.load(response)
print(json.dumps(result, indent=2))
assert result["choices"][0]["text"].strip()
assert result["usage"]["completion_tokens"] > 0
PY

Confermare le letture non zero dell'archivio di supporto a freddo. Tieni attivo il Pod dell'applicazione mentre controlli la popolazione della cache asincrona:

1. Esempio di cache_server_upload_request_size_bytes_sum e cache_server_cache_size_bytes da ogni pod del server di cache per la risorsa cache selezionata ogni 10 secondi, per un massimo di cinque minuti. Usa la procedura endpoint metrics. Usare esempi aggiornati, non copie ripetute di uno scorporamento memorizzato.
2. Confrontare gli esempi con la baseline di pre-distribuzione. Richiedere un aumento del totale di byte caricati e del totale di byte nella cache su quei server. Non richiedere che ogni server riceva dati.
3. Aspettare che il contatore di byte di upload di ogni server rimanga invariato per tre intervalli di campionamento consecutivi dopo l'aumento totale dell'upload. Conferma che nessun server si sia riavviato e che nessun contatore sia stato reimpostato durante il confronto.
4. Salvare quell'ultimo esempio come snapshot post-raffreddamento, incluso cache_server_download_request_size_bytes_sum da ogni server come base per il carico a caldo.

Se queste condizioni non vengono soddisfatte entro cinque minuti, interrompere il confronto invece di considerare la cache come a caldo. Controlla gli errori di upload del client, lo stato del server di cache e il traffico in corso prima di riprovare. I modelli più grandi possono richiedere una finestra di osservazione più lunga. Una metrica mancante o uno scrape fallito non è un valore zero o una prova che i caricamenti siano terminati.

I contatori stabili sono un segnale di prontezza, non una prova che ogni chunk del modello è archiviato. Il traffico della cache condivisa può anche impedire la stabilizzazione o spiegare gli aumenti. Usa una finestra di validazione silenziosa quando possibile e richiedi i controlli warm-read del fresh-Pod qui sotto per confermare il riutilizzo della cache distribuita.

Verifica un caricamento a caldo in un pod nuovo

Salva il cold log e l'UID del pod. Ricrea solo il pod applicativo utilizzando gli stessi file modello, endpoint cache, libreria e dimensione del chunk:

kubectl -n runai-dacs logs runai-dacs-vllm -c vllm > runai-cold.log
kubectl -n runai-dacs get pod runai-dacs-vllm -o jsonpath='{.metadata.uid}' > runai-cold.uid
kubectl -n runai-dacs delete pod runai-dacs-vllm --wait=true
kubectl apply -f runai-dacs-pod.yaml
kubectl -n runai-dacs wait --for=condition=Ready pod/runai-dacs-vllm --timeout=30m
kubectl -n runai-dacs get pod runai-dacs-vllm -o jsonpath='{.metadata.uid}' > runai-warm.uid
kubectl -n runai-dacs logs runai-dacs-vllm -c vllm > runai-warm.log

Ripeti il controllo di runtime e la richiesta di inferenza. Poi, cattura uno snapshot delle metriche post-warm da ogni server di cache. Confermare gli UID di pod diversi, un aumento della frequenza di riscontri della cache remota e una riduzione delle letture nell'archivio di supporto. Confronta cache_server_download_request_size_bytes_sum con lo snapshot post-cold per confermare le letture della cache calda. Un processo nuovo evita di confondere il prefetch locale in memoria con un hit della cache distribuita.

La frequenza di hit dell'origine remota è RemoteCache / (RemoteCache + RemoteClient), escludendo il prefetch locale. Usa l'ultima snapshot cumulativa per ogni processo nativo, punto di montaggio e dimensione del chunk; non sommare campioni periodici. Escludere le misurazioni interessate dai riavvii o dalle reimpostazioni del server di cache. I contatori server condivisi corroborano i log delle applicazioni ma non attribuiscono tutto il traffico a un unico carico di lavoro.

Il servizio Metadata può comunque accedere all'archiviazione BLOB anche quando i contatori delle letture ponderate a caldo non mostrano letture dell'archivio di supporto.

Montare le librerie client DACS con ImageVolume

Usa questa alternativa solo quando il runtime del nodo supporta ImageVolume e hai un'immagine client estraibile costruita dal wheel DACS pubblico. Non dare per scontato che un'immagine o un tag MCR proposti siano pubblicati. Se non è disponibile un'immagine client adeguata, si utilizza la procedura workload-image della sezione precedente.

La tua immagine vLLM GPU deve già contenere pacchetti compatibili Run:ai core e Azure. Non è necessario installare il pacchetto client DACS nel suo ambiente Python perché il volume immagine fornisce le librerie client native.

Adatta l'esempio del pod come segue:

1. Mantieni la tua immagine vLLM compatibile esistente invece di ricostruirla per installare le librerie client DACS.

2. Aggiungi un volume di immagine client in sola lettura e montalo:

   # Add to spec.volumes.
   - name: dacs-client
     image:
       reference: "<accessible-client-image>"
       pullPolicy: IfNotPresent
   
   # Add to the vLLM container's volumeMounts.
   - name: dacs-client
     mountPath: /opt/cache-client
     readOnly: true
   

3. Imposta RUNAI_STREAMER_EXPERIMENTAL_AZURE_CACHE_LIB sul percorso assoluto di libStorageDirect.so sotto /opt/cache-client, in base al layout effettivo di quell'immagine. Preservare le dipendenze native di pari livello.

4. Distribuire e confermare che il volume dell'immagine e il montaggio di sola lettura rimangano nella specifica del pod in tempo reale. Verificare che il file esista, poi eseguire lo stesso runtime del contenitore dell'applicazione e i controlli a freddo/a caldo.

Alcuni cluster più vecchi possono rimuovere campi e montaggi di volume dell'immagine non supportati dal pod accettato. La versione Kubernetes e il dry-run del server da soli non sono sufficienti. Non installare o precaricare una versione conflittuale delle librerie client DACS insieme al client montato; un percorso assoluto di libreria non isola il suo namespace nativo di dipendenza.

Ottimizza le prestazioni di lettura

Perché ottimizzare la dimensione dei chunk? I modelli hanno dimensioni di tensori e pattern di lettura diversi, quindi una dimensione di un blocco potrebbe non offrire le migliori prestazioni di caricamento del modello per ogni modello. I blocchi sovradimensionati ottengono più dati di quanti ne serva una lettura e aumentano il buffering. Blocchi sottodimensionati aumentano il numero di richieste e il sovraccarico per richiesta. La scelta di una dimensione adatta ai tensori più comuni del modello bilancia questi costi, migliora la capacità effettiva di lettura ponderata e riduce i tempi di caricamento del modello, inclusi i carichi a caldo provenienti da DACS. Considera le seguenti raccomandazioni come punti di partenza e misura separatamente i tempi di caricamento freddo e caldo. I guadagni dipendono dal modello, dalla concorrenza del loader e dalle prestazioni di storage e rete.

Scegli la dimensione di un blocco seguendo le seguenti raccomandazioni specifiche per modello. Per altri modelli, ispezionare i metadati tensoriali come descritto nella sezione successiva, oppure utilizzare 32 MiB se l'ispezione dei metadati non è disponibile.

Scegliere una dimensione del blocco per un altro modello

Usa un visualizzatore di metadati Safetensors o uno strumento di ispezione delle header per ispezionare tutti gli shard del modello, senza caricare i contenuti del tensore:

1. Trova la dimensione memorizzata di ogni tensore in byte: il suo offset dati finale meno il suo offset iniziale. Escludi la voce __metadata__.
2. Considerare ogni dimensione superiore a 32 MiB come 32 MiB prima di contare le occorrenze.
3. Seleziona la dimensione più frequente su tutti gli shard. Se più dimensioni si verificano con la stessa frequenza, scegliere quella più grande.
4. Se la dimensione selezionata è inferiore a 2 MiB, usa 2 MiB.

Ad esempio, se i tensori a 3 MiB si verificano più frequentemente dopo il limite massimo, usare 3 MiB (3145728 byte). Se l'ispezione dei metadati non è disponibile, utilizzare 32 MiB (33554432byte).

Configurare l'applicazione

Imposta entrambi RUNAI_STREAMER_CHUNK_BYTESIZE e SI_streamingChunkSize al valore del byte risultante nell'ambiente del container applicativo. Ad esempio, per una raccomandazione da 3 MiB:

env:
  - name: RUNAI_STREAMER_CHUNK_BYTESIZE
    value: "3145728"
  - name: SI_streamingChunkSize
    value: "3145728"

Imposta questi valori esplicitamente; la tabella descrive le raccomandazioni, non il rilevamento automatico dei modelli o i valori predefiniti integrati. Ricreare il pod dell'applicazione dopo aver apportato le modifiche; i server di cache non hanno bisogno di essere riavviati. I lettori e i processi di popolamento che condividono dati in cache dovrebbero usare la stessa dimensione del chunk.

La dimensione di lettura di Run:ai e la dimensione nativa del blocco di cache sono controlli separati, configurati insieme sopra. Confronta la raccomandazione con il carico di lavoro e regola separatamente la concorrenza del loader. Confronta separatamente i carichi freddi e caldi. Cambiare la dimensione del blocco della cache crea chiavi di cache diverse e può aumentare temporaneamente l'occupazione della cache. Cambia un'impostazione alla volta e misura il tempo di caricamento, i contatori nativi, le metriche di cache, CPU, GPU e memoria host, e l'uso della rete. L'allineamento tensoriale da solo non garantisce prestazioni migliori.

Troubleshoot

Per un confronto diretto separato con Blob, imposta RUNAI_STREAMER_EXPERIMENTAL_AZURE_CACHE_ENABLED=0 e ricrea un Pod di test. L'impostazione su 1 fa sì che gli errori di caricamento del provider impediscano l'avvio, anziché eseguire il fallback silenziosamente. Nessuna delle due impostazioni dimostra i riscontri della cache; ispezionare i contatori di lettura dei dati.

Pulire l'esempio

Se hai creato il Pod di esempio standalone, eliminalo quando hai finito:

kubectl -n runai-dacs delete pod runai-dacs-vllm --wait=true

Rimuovi solo prefissi di modello, immagini, identità, federazioni, namespace e assegnazioni di ruolo che hai creato per questo esempio e che non ti servono più. Non cancellare una cache o un'identità condivisa esistente. I dati del modello memorizzati sono ora in cache calda; usa un prefisso nuovo per un'altra validazione della cache fredda.

Passaggi successivi

• Usa il client Python del DACS.
• Monitorare un acceleratore distribuito per l'archiviazione cloud.
• Gestisci un acceleratore distribuito per lo storage cloud.
• Risoluzione dei problemi con acceleratore distribuito per lo storage cloud.