Aidez à améliorer cette page

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page qui se trouve dans le volet droit de chaque page.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Accélérez le chargement des modèles sur Amazon EKS

Lorsque vous déployez des modèles de langage volumineux (LLM) sur Amazon EKS, le temps de chargement des modèles influe directement sur la rapidité avec laquelle les Pods peuvent commencer à traiter les demandes d'inférence. Cela est particulièrement vrai lors d'événements de mise à l'échelle, lorsque de nouveaux pods ou nœuds doivent charger le modèle avant de gérer le trafic. Le démarrage du modèle comporte deux phases que vous pouvez améliorer en ajustant et en compilant la mise en cache des artefacts :

Cette rubrique explique comment optimiser les performances du Run:ai Model Streamer et la mise en cache de torch.compile afin de réduire les deux phases du processus de chargement du modèle. Pour la procédure complète de déploiement de vLLM sur Amazon EKS à des fins d'inférence, consultez. Modèles Load & Serve sur Amazon EKS

Optimisez le chemin réseau S3 en mode automatique EKS

Si vous utilisez le mode EKS Auto avec des nœuds GPU dans des sous-réseaux privés, nous vous recommandons d'utiliser un point de terminaison Gateway VPC pour S3 afin d'optimiser le chemin réseau entre vos nœuds et S3. Avec le point de terminaison Gateway VPC, le trafic vers S3 reste sur le AWS réseau et contourne complètement la passerelle NAT. Il n'y a donc pas de plafond de bande passante partagée ni de frais de traitement des données NAT par Go. Sans le point de terminaison Gateway VPC, lorsque le trafic passe par une passerelle NAT, la passerelle NAT devient un goulot d'étranglement partagé lors de la mise à l'échelle lorsque plusieurs nœuds extraient le modèle en même temps.

Le mode automatique EKS place généralement les nœuds dans des sous-réseaux privés, de sorte que le trafic vers S3 passe par une passerelle NAT par défaut. Une passerelle NAT fournit jusqu'à 100 Gbit/s de bande passante et 55 000 connexions simultanées par destination. Cependant, cette bande passante est partagée entre tous les nœuds du sous-réseau privé. Lors d'un événement de mise à l'échelle, plusieurs nœuds téléchargeant le modèle complet en même temps se disputent la même bande passante de passerelle NAT, ce qui peut ralentir le chargement des poids du modèle sur chacun d'eux.

Run:ai Réglage des performances du modèle Streamer

Les moteurs d'inférence tels que VLLm et SGlang utilisent Run:ai Model Streamer comme mécanisme alternatif pour charger les poids lors du démarrage de l'inférence.

Par défaut, Run:ai Model Streamer utilise des paramètres de simultanéité prudents lors du téléchargement des fichiers de pondération des modèles depuis S3. L'augmentation de la simultanéité des téléchargements et de la taille des blocs réduit le temps de chargement du modèle en téléchargeant davantage de données en parallèle.

Calculez la simultanéité optimale

Calculez la valeur de simultanéité optimale comme suit :

concurrency = ceil(total_model_size_gb / chunk_size_gb)

Remplacez la concurrency valeur que vous utilisez en fonction de la taille de votre modèle et de la taille des morceaux. Consultez le tableau suivant pour quelques exemples. Par exemple, avec un modèle de 67 Go et une taille de bloc de 4 Go :ceil(67 / 4) = 17.

Appliquer la configuration

Ajoutez les arguments et variables d'environnement suivants à la spécification de votre conteneur d'inférence :

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"
         

Optimisez le démarrage à froid de torch.compile

L'torch.compileétape du processus de service d'inférence trace le graphique de calcul d'un modèle (la séquence d'opérations mathématiques) et le compile en noyaux fusionnés optimisés. CUDA/Triton Il ne compile pas les poids du modèle, mais uniquement les opérations qui les transforment.

Les moteurs d'inférence utilisent torch.compile car il fournit automatiquement des améliorations significatives du débit, sans ingénierie de noyau personnalisée par architecture de modèle :

Le tableau suivant présente les moteurs de service d'inférence courants qui utilisent torch.compile.

Le problème de démarrage à froid de torch.compile

Le compromis de torch.compile est que le premier pod d'inférence doit être compilé avant de pouvoir répondre aux requêtes. Cette compilation peut prendre plusieurs minutes selon la taille du modèle. Les artefacts compilés sont petits (environ 15 Mo pour un modèle de 60 Go) mais augmentent considérablement le temps de démarrage à froid. Comme les artefacts sont petits et déterministes pour une configuration donnée, vous pouvez les mettre en cache et les réutiliser pour éliminer la pénalité de démarrage à froid lors du démarrage ultérieur du pod et du nœud.

Les artéfacts sont les suivants :

Le compromis entre... une exigence pressante

vLLM active la capture torch.compile de graphes CUDA par défaut. L'--enforce-eagerindicateur désactive à la fois et exécute le modèle en mode impatient, où chaque opération s'exécute immédiatement via l'interpréteur Python. Étant donné que le mode Eager ignore à la fois la compilation et la capture de graphiques, certains guides de démarrage rapide, y compris le déploiement de base dansModèles Load & Serve sur Amazon EKS, permettent de démarrer les Pods --enforce-eager plus rapidement.

--enforce-eagerest un choix approprié pour le débogage, les déploiements à mémoire limitée ou les architectures de modèle qui ne se compilent pas correctement, et vous pouvez l'utiliser en production pour ces raisons. Bien que cela puisse atténuer les pénalités de démarrage à torch.compile froid, nous recommandons d'autres approches, telles que celles décrites dans les sections suivantes de cette page, afin de maintenir les performances d'exécution en production.

Comprenez le compromis entre le temps de démarrage et les performances d'exécution avant le déploiement en production. --enforce-eager

Mettre en cache les artefacts torch.compile sur le même nœud

Cette technique s'applique lorsque vous utilisez un moteur d'inférence compatibletorch.compile, tel que vLLM (activé par défaut) ou SGlang (activé via). --enable-torch-compile Il ne fonctionne que lorsqu'il torch.compile est actif, c'est-à-dire lorsqu'il n'--enforce-eagerest pas défini.

Lorsqu'un moteur d'inférence compile le graphique de calcul du modèle au premier démarrage, vous pouvez mettre en cache les noyaux optimisés qui en résultent sur le stockage local du nœud. Les pods suivants sur le même nœud réutilisent les artefacts mis en cache et ignorent complètement l'étape de compilation, ce qui peut réduire considérablement le temps de démarrage.

Ajouter des variables d'environnement de cache

Ajoutez les variables d'environnement suivantes à la spécification de votre conteneur d'inférence pour diriger torch.compile et le cache Triton vers un chemin d'hôte persistant. Nous vous recommandons d'utiliser le magasin d'instances NVMe local du nœud et non le volume racine Amazon Elastic Block Store (Amazon EBS) pour le. hostPath Pour des exemples, consultez la section suivante.

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

Définissez le chemin du cache vers le magasin d'instances NVMe

Les artefacts compilés et les poids diffusés bénéficient d'un stockage local rapide. Sur les instances GPU dotées d'un stockage d'instance NVMe (tel que P-family les instances G-family et), le magasin d'instances en fournit environ 30 GB/s, contre environ 1 GB/s pour le volume Amazon EBS racine. Dirigez le cache hostPath vers le point de montage NVMe pour optimiser le débit.

Le point de montage NVMe et la manière dont vous l'activez diffèrent entre le mode automatique EKS et les nœuds autogérés :

Pour le mode EKS Auto, définissez la valeur hostPath sur /mnt/.ephemeral/compile-cache dans les spécifications de votre conteneur :

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

Pour Karpenter autogéré, définissez la valeur sur /mnt/k8s-disks/0/compile-cache dans hostPath les spécifications de votre conteneur :

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

Exemple de résultats

Le tableau suivant montre l'amélioration apportée à la mise en cache sur le même nœud pour différentes tailles de modèles :

Pre-warm cache torch.compile sur les nouveaux nœuds

Cette technique s'applique lorsque vous exécutez une inférence multi-nœuds avec des GPU homogènes, un parallélisme tensoriel, des modèles et des versions sur plusieurs nœuds. PyTorch La technique Mettre en cache les artefacts torch.compile sur le même nœud se concentre sur le cas d'un seul nœud, mais les nouveaux nœuds ajoutés lors d'événements de mise à l'échelle commencent par un cache torch.compile vide. Pour réduire davantage le temps de démarrage à froid sur les nœuds nouvellement initialisés, vous pouvez implémenter un mécanisme de mise en cache qui stocke les artefacts torch.compile compilés dans S3 et les télécharge au préalable sur les nouveaux nœuds lorsqu'ils rejoignent le cluster.

L'approche générale est la suivante :

Par exemple, vous pouvez implémenter un DaemonSet qui s'exécute sur des nœuds GPU pour empaqueter et charger le cache torch.compile vers S3. Il peut également synchroniser ce cache avec le stockage du nœud local avant que des pods d'inférence ne soient planifiés sur de nouveaux nœuds.

Considérations relatives à la mise en cache entre nœuds

Lorsque vous mettez en cache des artefacts torch.compile sur plusieurs nœuds, les noyaux compilés ne sont valides que lorsque ces paramètres correspondent entre le nœud qui a généré le cache et le nœud qui le consomme. Votre mécanisme de mise en cache doit prendre en compte tous ces éléments. Une non-concordance sur un paramètre produit un cache non valide qui force la recompilation ou provoque des erreurs d'exécution. Votre outil de mise en cache doit différencier les artefacts en fonction de ces paramètres, par exemple en les incorporant dans la clé d'objet S3 ou la structure du répertoire de cache.

Exemple de résultats

Lors de tests directionnels avec préchauffage du cache entre nœuds (67 GoQwen3-6-35B-A3B, 2 GPU avec TP=2 sur p5.48xlarge), le premier pod sur des nœuds récemment redimensionnés a atteint le même temps de démarrage que les pods suivants sur un nœud déjà chaud :

Exemple de déploiement

L'exemple suivant combine le réglage des performances Run:ai du Model Streamer et un cache torch.compile dans un seul manifeste de déploiement vLLM. Remplacez les valeurs des espaces réservés par votre propre configuration :

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