Contribuisci a migliorare questa pagina

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Per contribuire a questa guida per l'utente, scegli il GitHub link Modifica questa pagina su che si trova nel riquadro destro di ogni pagina.

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Accelera il caricamento dei modelli su Amazon EKS

Quando distribuisci modelli linguistici di grandi dimensioni (LLM) su Amazon EKS, il tempo di caricamento dei modelli influisce direttamente sulla rapidità con cui i Pods possono iniziare a fornire richieste di inferenza. Ciò è particolarmente vero durante gli eventi di scalabilità, quando nuovi pod o nodi devono caricare il modello prima di gestire il traffico. L'avvio del modello prevede due fasi che puoi migliorare con l'ottimizzazione e la memorizzazione nella cache degli artefatti:

Questo argomento mostra come ottimizzare le prestazioni di Run:ai Model Streamer e il caching di torch.compile per ridurre entrambe le fasi del processo di caricamento del modello. Per la procedura completa di distribuzione di vLLM su Amazon EKS per l'inferenza, consulta. Modelli Load & Serve su Amazon EKS

Ottimizza il percorso di rete S3 in EKS Auto Mode

Se utilizzi la modalità EKS Auto con nodi GPU in sottoreti private, ti consigliamo di utilizzare un endpoint Gateway VPC per S3 per ottimizzare il percorso di rete tra i tuoi nodi e S3. Con l'endpoint Gateway VPC, il traffico verso S3 rimane sulla AWS rete e bypassa completamente il NAT Gateway, quindi non vi è alcun limite di larghezza di banda condiviso e nessun costo di elaborazione dei dati NAT per GB. Senza l'endpoint Gateway VPC, quando il traffico attraversa un NAT Gateway, il NAT Gateway diventa un collo di bottiglia condiviso durante la scalabilità, quando più nodi eseguono il modello contemporaneamente.

La modalità automatica EKS colloca comunemente i nodi in sottoreti private, quindi il traffico verso S3 fluisce attraverso un gateway NAT per impostazione predefinita. Un gateway NAT fornisce fino a 100 Gbps di larghezza di banda e 55.000 connessioni simultanee per destinazione. Tuttavia, tale larghezza di banda è condivisa tra tutti i nodi della sottorete privata. Durante un evento di scalabilità, diversi nodi che scaricano contemporaneamente il modello completo si contendono la stessa larghezza di banda del NAT Gateway, il che può rallentare il caricamento dei pesi del modello su tutti.

Run:ai Ottimizzazione delle prestazioni di Model Streamer

I motori di inferenza come vLLM e SGlang utilizzano Run:ai Model Streamer come meccanismo alternativo per caricare i pesi durante l'avvio dell'inferenza.

Per impostazione predefinita, Run:ai Model Streamer utilizza impostazioni di concorrenza conservative quando scarica i file di peso del modello da S3. L'aumento della concorrenza di download e della dimensione dei blocchi riduce il tempo di caricamento dei pesi del modello scaricando più dati in parallelo.

Calcola la concorrenza ottimale

Calcola il valore di concorrenza ottimale nel modo seguente:

concurrency = ceil(total_model_size_gb / chunk_size_gb)

Sostituisci il concurrency valore che usi in base alle dimensioni del modello e alla dimensione del blocco. Per alcuni esempi, consultate la tabella seguente. Ad esempio, con un modello da 67 GB e una dimensione del blocco da 4 GB:ceil(67 / 4) = 17.

Applica la configurazione

Aggiungi i seguenti argomenti e variabili di ambiente alle specifiche del contenitore di inferenza:

containers:
- name: vllm-inference
  image: vllm/vllm-openai:v0.21.0
  command:
    - python3
    - -m
    - vllm.entrypoints.openai.api_server
  args:
  # ... your existing args ...
  - --model=s3://<MODEL_PATH>
  - --tensor-parallel-size=2
  - --load-format=runai_streamer
  - --model-loader-extra-config={"concurrency":17,"distributed":true}
  env:
  - name: RUNAI_STREAMER_CHUNK_BYTESIZE
    value: "4294967296"
  - name: RUNAI_STREAMER_S3_REQUEST_TIMEOUT_MS
    value: "3000"
  - name: RUNAI_STREAMER_S3_LOW_SPEED_LIMIT
    value: "1048576"
         

Ottimizza torch.compile cold start

La torch.compile fase del processo di elaborazione delle inferenze traccia il grafico di calcolo di un modello (la sequenza di operazioni matematiche) e lo compila in kernel fused ottimizzati. CUDA/Triton Non compila i pesi del modello, ma solo le operazioni che li trasformano.

I motori di inferenza utilizzano torch.compile perché fornisce automaticamente significativi miglioramenti del throughput, senza ingegneria del kernel personalizzata per architettura del modello:

La tabella seguente mostra i motori di inferenza più comuni che utilizzano torch.compile.

Il problema dell'avvio a freddo di torch.compile

Il compromesso di torch.compile è che la prima inferenza Pod deve essere compilata prima di poter soddisfare le richieste. Questa compilazione può richiedere fino a diversi minuti a seconda delle dimensioni del modello. Gli artefatti compilati sono piccoli (~15 MB per un modello da 60 GB) ma aumentano notevolmente il tempo di avvio a freddo. Poiché gli artefatti sono piccoli e deterministici per una determinata configurazione, è possibile memorizzarli nella cache e riutilizzarli per eliminare la penalizzazione dovuta all'avvio a freddo al successivo avvio del Pod e del nodo.

Gli artefatti sono costituiti da:

Il compromesso --enforce-eager

Per impostazione predefinita, vLLM abilita l'acquisizione di grafici CUDA. torch.compile Il --enforce-eager flag disattiva entrambi ed esegue il modello in modalità eager, in cui ogni operazione viene eseguita immediatamente tramite l'interprete Python. Poiché la modalità eager salta sia la compilazione che l'acquisizione di grafici, alcune guide rapide, inclusa la distribuzione di base in, vengono utilizzate per avviare i Pod più velocemente. Modelli Load & Serve su Amazon EKS --enforce-eager

--enforce-eagerè una scelta valida per il debug, le implementazioni con limiti di memoria o le architetture di modelli che non vengono compilate in modo corretto, ed è possibile utilizzarla in produzione per questi motivi. Sebbene possa mitigare i problemi legati all'avvio a torch.compile freddo, consigliamo altri approcci, come quelli descritti nelle sezioni successive di questa pagina, per mantenere le prestazioni di runtime in produzione.

Comprendi il compromesso tra tempo di avvio e prestazioni in fase di esecuzione prima dell'implementazione in produzione. --enforce-eager

Memorizza gli artefatti torch.compile sullo stesso nodo

Questa tecnica si applica quando si utilizza un motore di inferenza che supportatorch.compile, ad esempio vLLM (abilitato per impostazione predefinita) o SGlang (abilitato tramite). --enable-torch-compile Funziona solo quando torch.compile è attivo, cioè quando non è impostato. --enforce-eager

Quando un motore di inferenza compila il grafico di calcolo del modello al primo avvio, puoi memorizzare nella cache i kernel ottimizzati risultanti nella memoria locale del nodo. I pod successivi sullo stesso nodo riutilizzano gli artefatti memorizzati nella cache e saltano completamente la fase di compilazione, il che può ridurre significativamente i tempi di avvio.

Aggiungi variabili di ambiente alla cache

Aggiungete le seguenti variabili di ambiente alle specifiche del contenitore di inferenza per indirizzare torch.compile e Triton cache a un percorso host persistente. Ti consigliamo di utilizzare lo store di istanze NVMe locale del nodo e non il volume principale di Amazon Elastic Block Store (Amazon EBS) per. hostPath Per esempi, consulta la sezione seguente.

containers:
- name: vllm-inference
  env:
  # torch.compile cache
  - name: XDG_CACHE_HOME
    value: "/compile-cache"
  - name: TORCHINDUCTOR_CACHE_DIR
    value: "/compile-cache/inductor"
  - name: TRITON_CACHE_DIR
    value: "/compile-cache/triton"
  volumeMounts:
  - name: compile-cache
    mountPath: /compile-cache
volumes:
- name: compile-cache
  hostPath:
    path: /mnt/k8s-disks/0/compile-cache
    type: DirectoryOrCreate

Imposta il percorso della cache per l'archivio di istanze NVMe

Gli artefatti compilati e i pesi trasmessi in streaming traggono vantaggio dall'archiviazione locale veloce. Nelle istanze GPU con storage di istanze NVMe (come le P-family istanze G-family and), l'instant store ne fornisce circa 30 GB/s, rispetto a circa 1 del volume Amazon EBS principale. GB/s Indirizza la cache al punto di montaggio hostPath NVMe per ottimizzare il throughput.

Il punto di montaggio NVMe e il modo in cui viene abilitato differiscono tra la modalità automatica EKS e i nodi autogestiti:

Per EKS Auto Mode, imposta il valore su nelle specifiche del contenitore: hostPath /mnt/.ephemeral/compile-cache

volumes:
- name: compile-cache
  hostPath:
    path: /mnt/.ephemeral/compile-cache
    type: DirectoryOrCreate

Per Karpenter autogestito, imposta il hostPath to /mnt/k8s-disks/0/compile-cache nelle specifiche del contenitore:

volumes:
- name: compile-cache
  hostPath:
    path: /mnt/k8s-disks/0/compile-cache
    type: DirectoryOrCreate

Risultati di esempio

La tabella seguente mostra il miglioramento della memorizzazione nella cache dello stesso nodo per modelli di dimensioni diverse:

Pre-warm torch.compile cache sui nuovi nodi

Questa tecnica si applica quando si esegue l'inferenza multinodo con GPU omogenee, parallelismo tensoriale, modelli e versioni tra nodi. PyTorch La tecnica Memorizza gli artefatti torch.compile sullo stesso nodo si concentra sul caso di un singolo nodo, ma i nuovi nodi aggiunti durante gli eventi di scalabilità iniziano con una cache torch.compile vuota. Per ridurre ulteriormente i tempi di avvio a freddo sui nodi appena inizializzati, puoi implementare un meccanismo di caching che memorizza gli artefatti torch.compile compilati in S3 e li prescarica in nuovi nodi quando si uniscono al cluster.

L'approccio generale è:

Ad esempio, puoi implementare uno DaemonSet che viene eseguito su nodi GPU che impacchetta e carica la cache torch.compile su S3. Può anche sincronizzare la cache con l'archiviazione dei nodi locali prima che i pod di inferenza vengano pianificati su nuovi nodi.

Considerazioni sulla memorizzazione nella cache tra nodi

Quando si memorizzano nella cache gli artefatti torch.compile tra i nodi, i kernel compilati sono validi solo quando questi parametri corrispondono tra il nodo che ha generato la cache e il nodo che la consuma. Il meccanismo di caching deve tenere conto di tutti questi fattori. Una mancata corrispondenza su qualsiasi parametro produce una cache non valida che impone la ricompilazione o causa errori di runtime. Lo strumento di caching deve distinguere gli artefatti in base a questi parametri, ad esempio incorporandoli nella chiave oggetto S3 o nella struttura della directory della cache.

Risultati di esempio

Nei test direzionali con preriscaldamento della cache tra nodi (Qwen3-6-35B-A3B, 67 GB, 2 GPU con TP=2 su p5.48xlarge), il primo Pod su nodi appena scalati ha raggiunto lo stesso tempo di avvio dei Pod successivi su un nodo già caldo:

Esempio di implementazione

L'esempio seguente combina l'ottimizzazione delle prestazioni di Run:ai Model Streamer e una cache torch.compile in un unico manifest di vLLM Deployment. Sostituisci i valori segnaposto con la tua configurazione:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-inference
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: vllm-inference
  template:
    metadata:
      labels:
        app: vllm-inference
    spec:
      serviceAccountName: <SERVICE_ACCOUNT_NAME>
      nodeSelector:
        karpenter.sh/nodepool: <GPU_NODEPOOL>
      tolerations:
        - key: nvidia.com/gpu
          operator: Exists
          effect: NoSchedule
      containers:
        - name: vllm
          image: vllm/vllm-openai:v0.21.0
          command:
            - python3
            - -m
            - vllm.entrypoints.openai.api_server
          args:
            - --model=s3://<BUCKET_NAME>/<MODEL_PATH>
            - --load-format=runai_streamer
            - --model-loader-extra-config={"concurrency":17,"distributed":true}
            - --tensor-parallel-size=2
            - --max-model-len=8192
            - --host=0.0.0.0
            - --port=8000
          ports:
            - containerPort: 8000
              name: http
          env:
            # Run:ai streamer tuning
            - name: RUNAI_STREAMER_CHUNK_BYTESIZE
              value: "4294967296"
            - name: RUNAI_STREAMER_S3_REQUEST_TIMEOUT_MS
              value: "3000"
            - name: RUNAI_STREAMER_S3_LOW_SPEED_LIMIT
              value: "1048576"
            # torch.compile cache
            - name: XDG_CACHE_HOME
              value: "/compile-cache"
            - name: TORCHINDUCTOR_CACHE_DIR
              value: "/compile-cache/inductor"
            - name: TRITON_CACHE_DIR
              value: "/compile-cache/triton"
          resources:
            requests:
              cpu: "12"
              memory: 80Gi
              nvidia.com/gpu: "2"
            limits:
              nvidia.com/gpu: "2"
          volumeMounts:
            - name: compile-cache
              mountPath: /compile-cache
          startupProbe:
            httpGet:
              path: /health
              port: 8000
            periodSeconds: 10
            failureThreshold: 60
            initialDelaySeconds: 30
          readinessProbe:
            httpGet:
              path: /health
              port: 8000
            periodSeconds: 5
            timeoutSeconds: 3
      volumes:
        - name: compile-cache
          hostPath:
            path: /mnt/k8s-disks/0/compile-cache
            type: DirectoryOrCreate