**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** 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à. # Avvio rapido: inferenza LLM ad alto rendimento con vLLM su Amazon EKS ## Introduzione Questa guida rapida fornisce una procedura dettagliata per la distribuzione di Large Language Models () LLMs su Amazon EKS utilizzando VLLM e GPUs per applicazioni di inferenza in tempo reale basate su testo. La soluzione sfrutta Amazon EKS per l'orchestrazione dei container e VLLM per un servizio di modelli efficiente, consentendoti di creare applicazioni AI scalabili con accelerazione GPU e server di inferenza ad alto rendimento. [Il modello Llama 3.1 8B Instruct viene utilizzato a scopo dimostrativo, ma è possibile implementare qualsiasi altro LLM supportato da vLLM (consulta la documentazione di VLLm per un elenco dei modelli supportati).](https://docs.vllm.ai/en/latest/models/supported_models.html#list-of-text-only-language-models) Per testare l'inferenza LLM, utilizziamo un'applicazione chatbot di esempio basata sul progetto. [nextjs-vllm-ui](https://github.com/yoziru/nextjs-vllm-ui) Infine, utilizziamo GuideLM per confrontare e ottimizzare i parametri di configurazione vLLM per ottimizzare le prestazioni di inferenza. **Architettura VLLm su EKS** ![\[Diagramma dell'architettura VLLm\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/llm-inference-vllm-architecture.png) Una volta completata questa procedura, disporrete di un endpoint di inferenza VLLm ottimizzato per la velocità effettiva e la bassa latenza e sarete in grado di interagire con un modello Llama tramite un'applicazione di chat frontend, dimostrando un tipico caso d'uso per gli assistenti di chatbot e altre applicazioni basate su LLM. [Per ulteriori indicazioni e risorse di implementazione avanzate, consulta la nostra guida alle migliori pratiche EKS per i carichi di lavoro e l'intelligenza artificiale pronta per la produzione sui grafici di inferenza [EKS](https://docs.aws.amazon.com/eks/latest/best-practices/aiml.html). AI/ML ](https://github.com/awslabs/ai-on-eks/tree/main/blueprints/inference/inference-charts) ## Prima di iniziare Prima di iniziare, assicurati di avere: + Un cluster Amazon EKS con i seguenti componenti principali: pool di nodi Karpenter con famiglia di EC2 istanze G5 o G6, NVIDIA Device Plugin installato sui nodi di lavoro abilitati alla GPU e il driver S3 Mountpoint CSI installato. Per creare questa configurazione di base, segui i passaggi indicati, fino al completamento del passaggio \$14. [Guida alle best practice per la configurazione dei cluster per l’inferenza in tempo reale su Amazon EKS](ml-realtime-inference-cluster.md) + Un account Hugging Face. Per registrarti, consulta https://huggingface.co/login. ## Configurazione dello storage modello con Amazon S3 Archivia in modo efficiente file LLM di grandi dimensioni in Amazon S3 per separare lo storage dalle risorse di elaborazione. Questo approccio semplifica gli aggiornamenti dei modelli, riduce i costi e semplifica la gestione nelle configurazioni di produzione. S3 gestisce file di grandi dimensioni in modo affidabile, mentre l'integrazione con Kubernetes tramite il driver CSI Mountpoint consente ai pod di accedere a modelli come l'archiviazione locale, senza bisogno di lunghi download all'avvio. Segui questi passaggi per creare un bucket S3, caricare un LLM e montarlo come volume nel tuo contenitore di servizi di inferenza. Su EKS sono disponibili anche altre soluzioni di storage per la memorizzazione nella cache dei modelli, come EFS e FSx Lustre. Per ulteriori informazioni, consulta [EKS Best](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-storage.html) Practices. ### Impostazione delle variabili di ambiente Crea un nome univoco per un nuovo bucket Amazon S3 che creeremo più avanti in questa guida. Una volta creato, usa lo stesso nome di bucket per tutti i passaggi. Esempio: ``` MY_BUCKET_NAME=model-store-$(date +%s) ``` Definisci le variabili di ambiente e memorizzale in un file: ``` cat << EOF > .env-quickstart-vllm export BUCKET_NAME=${MY_BUCKET_NAME} export AWS_REGION=us-east-1 export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) EOF ``` Carica le variabili di ambiente nell'ambiente della shell. Se chiudi l'ambiente di shell corrente e ne apri uno nuovo, assicurati di rifornire le variabili di ambiente usando lo stesso comando: ``` source .env-quickstart-vllm ``` ### Crea un bucket S3 per archiviare i file del modello Crea un bucket S3 per archiviare i file del modello: ``` aws s3 mb s3://${BUCKET_NAME} --region ${AWS_REGION} ``` ### Scarica il modello da Hugging Face Hugging Face è uno dei principali hub di modelli per l'accesso ai modelli LLM. Per scaricare il modello Llama, dovrai accettare la licenza del modello e configurare l'autenticazione tramite token: 1. Accetta la licenza del modello Llama 3.1 8B Instruct all'indirizzo https://huggingface. co/meta-llama/Llama-3.1-8B-Instruct. 1. Genera un token di accesso (vai al tuo profilo > Impostazioni > Token di accesso, quindi crea un nuovo token usando il tipo di token Read). Imposta una variabile di ambiente con il tuo token Hugging Face: ``` export HF_TOKEN=your_token_here ``` Installa il pacchetto pip3 se non è già installato nel tuo ambiente. Comando di esempio in Amazon Linux 2023: ``` sudo dnf install -y python3-pip ``` Installa la CLI [Hugging Face](https://huggingface.co/docs/huggingface_hub/main/en/guides/cli): ``` pip install huggingface-hub ``` Scarica il modello Llama-3.1-8B-Instruct da Hugging Face (\$115 GB) `--exclude` usando il flag per saltare il formato precedente e scaricare solo i file in formato safetensors ottimizzato, che riduce PyTorch le dimensioni di download mantenendo la piena compatibilità con i motori di inferenza più diffusi: ``` huggingface-cli download meta-llama/Meta-Llama-3.1-8B-Instruct \ --exclude "original/*" \ --local-dir ./llama-3.1-8b-instruct \ --token $HF_TOKEN ``` Verifica i file scaricati: ``` $ ls llama-3.1-8b-instruct ``` L’output previsto dovrebbe essere simile al seguente: ``` LICENSE config.json model-00002-of-00004.safetensors model.safetensors.index.json tokenizer_config.json README.md generation_config.json model-00003-of-00004.safetensors special_tokens_map.json USE_POLICY.md model-00001-of-00004.safetensors model-00004-of-00004.safetensors tokenizer.json ``` ### Carica i file del modello Abilita AWS Common Runtime (CRT) per migliorare le prestazioni di trasferimento S3. Il client di trasferimento basato su CRT offre velocità di trasmissione e affidabilità migliorate per operazioni su file di grandi dimensioni: ``` aws configure set s3.preferred_transfer_client crt ``` Carica il modello: ``` aws s3 cp ./llama-3.1-8b-instruct s3://$BUCKET_NAME/llama-3.1-8b-instruct \ --recursive ``` L’output previsto dovrebbe essere simile al seguente: ``` ... upload: llama-3.1-8b-instruct/tokenizer.json to s3://model-store-1753EXAMPLE/llama-3.1-8b-instruct/tokenizer.json upload: llama-3.1-8b-instruct/model-00004-of-00004.safetensors to s3://model-store-1753890326/llama-3.1-8b-instruct/model-00004-of-00004.safetensors upload: llama-3.1-8b-instruct/model-00002-of-00004.safetensors to s3://model-store-1753890326/llama-3.1-8b-instruct/model-00002-of-00004.safetensors upload: llama-3.1-8b-instruct/model-00003-of-00004.safetensors to s3://model-store-1753890326/llama-3.1-8b-instruct/model-00003-of-00004.safetensors upload: llama-3.1-8b-instruct/model-00001-of-00004.safetensors to s3://model-store-1753890326/llama-3.1-8b-instruct/model-00001-of-00004.safetensors ``` ### Configura le autorizzazioni S3 Mountpoint CSI Il driver S3 Mountpoint CSI consente l'integrazione nativa tra Kubernetes e S3, consentendo ai pod di accedere direttamente ai file del modello come se fossero archiviazione locale, eliminando la necessità di copie locali durante l'avvio del contenitore. Crea una policy IAM per consentire al punto di montaggio S3 di leggere dal tuo bucket S3: ``` aws iam create-policy \ --policy-name S3BucketAccess-${BUCKET_NAME} \ --policy-document "{\"Version\": \"2012-10-17\", \"Statement\": [{\"Effect\": \"Allow\", \"Action\": [\"s3:GetObject\", \"s3:GetObjectVersion\", \"s3:ListBucket\", \"s3:GetBucketLocation\"], \"Resource\": [\"arn:aws:s3:::${BUCKET_NAME}\", \"arn:aws:s3:::${BUCKET_NAME}/*\"]}]}" ``` Trova il nome del ruolo IAM utilizzato dal driver CSI S3 Mountpoint controllando le annotazioni dell'account del servizio S3 CSI Driver: ``` ROLE_NAME=$(kubectl get serviceaccount s3-csi-driver-sa -n kube-system -o jsonpath='{.metadata.annotations.eks\.amazonaws\.com/role-arn}' | cut -d'/' -f2) ``` Allega la tua policy IAM al ruolo CSI di S3 Mountpoint: ``` aws iam attach-role-policy \ --role-name ${ROLE_NAME} \ --policy-arn arn:aws:iam::${AWS_ACCOUNT_ID}:policy/S3BucketAccess-${BUCKET_NAME} ``` Se S3 Mountpoint CSI non è installato nel cluster, segui la procedura di distribuzione riportata in. [Guida alle best practice per la configurazione dei cluster per l’inferenza in tempo reale su Amazon EKS](ml-realtime-inference-cluster.md) ### Monta il bucket S3 come volume Kubernetes Crea un Persistent Volume (PV) e un Persistent Volume Claim (PVC) per fornire l'accesso in sola lettura al bucket S3 su più pod di inferenza. La modalità di ReadOnlyMany accesso garantisce l'accesso simultaneo ai file del modello, mentre il driver CSI gestisce il montaggio del bucket S3: ``` cat < ### Nodi del cluster Stiamo usando il cluster EKS creato in[Guida alle best practice per la configurazione dei cluster per l’inferenza in tempo reale su Amazon EKS](ml-realtime-inference-cluster.md). Questo cluster include pool di nodi Karpenter in grado di fornire ai nodi abilitati alla GPU uno spazio di archiviazione sufficiente per scaricare l'immagine del contenitore VLLm. Se utilizzi un cluster EKS personalizzato, assicurati che possa avviare nodi abilitati alla GPU. **Selezione dell'istanza** La corretta selezione delle istanze per l'inferenza LLM richiede che la memoria GPU disponibile sia sufficiente per caricare i pesi del modello. I pesi dei modelli per Llama 3.1 8B Instruct sono di circa 16 GB (dimensione dei file del modello .safetensor), pertanto è necessario fornire almeno questa quantità di memoria al processo vllm per caricare il modello. [ EC2 Le istanze Amazon G5](https://aws.amazon.com/ec2/instance-types/g5/) con A10G GPUs e le istanze [G6 con L4 forniscono GPUs entrambe 24 GB di VRAM per GPU, sufficienti per caricare EC2 pesi Llama 3.1 8B Instruct](https://aws.amazon.com/ec2/instance-types/g6/). Se stai implementando un modello con pesi maggiori, prendi in considerazione l'utilizzo di un tipo di istanza multi-GPU o di una configurazione multinodo. **Driver per dispositivi NVIDIA** I driver NVIDIA forniscono l'ambiente di runtime necessario per consentire ai container di accedere alle risorse GPU in modo efficiente. Consente l'allocazione e la gestione delle risorse GPU all'interno di Kubernetes, rendendole disponibili come risorse pianificabili. GPUs Il nostro cluster utilizza EKS Bottlerocket AMIs, che include tutti i driver e i plug-in dei dispositivi NVIDIA necessari su tutti i nodi abilitati alla GPU, garantendo l'accessibilità immediata della GPU per carichi di lavoro containerizzati senza configurazioni aggiuntive. Se utilizzi altri tipi di nodi EKS, devi assicurarti che siano installati tutti i driver e i plugin necessari. ### Testa l'infrastruttura GPU Metti alla prova le funzionalità della GPU del tuo cluster eseguendo i passaggi seguenti per assicurarti che i pod possano accedere alle risorse GPU NVIDIA e pianificare correttamente sui nodi abilitati alla GPU. Implementa un pod di test Nvidia SMI: ``` cat < Lo stack di servizi determina sia le prestazioni che le capacità di scalabilità dell'infrastruttura di inferenza. vLLM si è affermata come una soluzione leader per le implementazioni di produzione. L'architettura di vLLM fornisce il batching continuo per l'elaborazione dinamica delle richieste, ottimizzazioni del kernel per un'inferenza più rapida e una gestione efficiente della memoria GPU tramite. PagedAttention Queste funzionalità, combinate con un'API REST pronta per la produzione e il supporto per i formati di modello più diffusi, lo rendono una scelta ottimale per implementazioni di inferenza ad alte prestazioni. ### Seleziona l'immagine del Deep Learning Container AWS [AWS Deep Learning Containers](https://github.com/aws/deep-learning-containers/tree/master) (DLCs) forniscono ambienti preottimizzati con aggiornamenti di sicurezza, compatibilità AWS dell'infrastruttura e configurazioni ottimizzate dei driver. Ciò riduce la complessità di implementazione e il sovraccarico di manutenzione, garantendo al contempo la disponibilità della produzione. Per questa implementazione, utilizzeremo il AWS DLC per VLLm 0.9, che include le librerie Nvidia e configurazioni ottimizzate delle prestazioni della GPU specificamente ottimizzate per l'inferenza del modello di trasformatore su istanze GPU. AWS ``` image: 763104351884.dkr.ecr.us-east-1.amazonaws.com/vllm:0.9-gpu-py312-ec2 ``` ### Applica i manifesti di VLM Kubernetes Esistono diversi modi per implementare vLLm in EKS. Questa guida illustra l'implementazione di VLLM utilizzando una distribuzione Kubernetes, un modo semplice e nativo di Kubernetes per iniziare. [https://docs.vllm.ai/en/latest/deployment/k8s.html](https://docs.vllm.ai/en/latest/deployment/k8s.html) Definisci i parametri di implementazione tramite i manifesti di Kubernetes per controllare l'allocazione delle risorse, il posizionamento dei nodi, i controlli sullo stato di salute, l'esposizione del servizio, ecc. Configura la distribuzione per eseguire un pod abilitato alla GPU utilizzando l'immagine del Deep Learning Container per vLLM. AWS Imposta parametri ottimizzati per l'inferenza LLM ed esponi l'endpoint compatibile con VLLM OpenAPI tramite il servizio Load Balancer: AWS ``` cat < Esponi l'endpoint di inferenza localmente tramite il port forwarding di Kubernetes per lo sviluppo e il test locali. Lascia questo comando in esecuzione in una finestra di terminale separata: ``` export POD_NAME=$(kubectl get pod -l app=vllm-inference-app -o jsonpath='{.items[0].metadata.name}') kubectl port-forward pod/$POD_NAME 8000:8000 ``` Il AWS Load Balancer Controller crea automaticamente un Network Load Balancer che espone l'endpoint del servizio VLLm all'esterno. Recupera l'endpoint NLB eseguendo: ``` NLB=$(kubectl get service vllm-inference-svc -o jsonpath='{.status.loadBalancer.ingress[0].hostname}') ``` Devi installare AWS Load Balancer Controller? Segui le fasi di implementazione riportate in[Indirizza il traffico Internet con AWS Load Balancer Controller](aws-load-balancer-controller.md). ## Esecuzione dell’inferenza ### Convalida il pod di inferenza Convalida la funzionalità del contenitore di inferenza localmente tramite la porta inoltrata. Invia una richiesta di connessione e assicurati che la risposta includa il codice HTTP 200: ``` $ curl -IX GET "http://localhost:8000/v1/models" ``` ``` HTTP/1.1 200 OK date: Mon, 13 Oct 2025 23:24:57 GMT server: uvicorn content-length: 516 content-type: application/json ``` Verifica le capacità di inferenza e convalida la connettività esterna inviando una richiesta di completamento all'LLM tramite l'endpoint NLB: ``` curl -X POST "http://$NLB:80/v1/completions" \ -H "Content-Type: application/json" \ -d '{ "model": "/mnt/models/llama-3.1-8b-instruct", "prompt": "Explain artificial intelligence:", "max_tokens": 512, "temperature": 0.7 }' ``` Questo endpoint segue il formato API OpenAI, rendendolo compatibile con le applicazioni esistenti e fornendo parametri di generazione configurabili come lunghezza e temperatura di risposta per il controllo della diversità di output. ### Esegui l'app chatbot A scopo dimostrativo, questa guida esegue un'applicazione chatbot di esempio che utilizza Project [nextjs-vllm-ui](https://github.com/yoziru/nextjs-vllm-ui)per mostrare le interazioni degli utenti con il modello. Esegui un'interfaccia utente di chatbot come contenitore Docker che mappa la porta 3000 su localhost e si connette all'endpoint VLLM NLB: ``` docker run --rm \ -p 3000:3000 \ -e VLLM_URL="http://${NLB}:80" \ --name nextjs-vllm-ui-demo \ ghcr.io/yoziru/nextjs-vllm-ui:latest ``` Apri il tuo browser web e vai a: http://localhost:3000/ Dovresti vedere l'interfaccia di chat in cui puoi interagire con il modello Llama. **Interfaccia utente di chat** ![\[Interfaccia utente di chat\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/llm-inference-vllm-chatui.png) ## Ottimizza le prestazioni di inferenza I motori di inferenza specializzati come VLLm offrono funzionalità avanzate che aumentano in modo significativo le prestazioni di inferenza, tra cui il batching continuo, il caching KV efficiente e meccanismi di attenzione della memoria ottimizzati. È possibile ottimizzare i parametri di configurazione VLLm per migliorare le prestazioni di inferenza soddisfacendo al contempo i requisiti specifici dei casi d'uso e i modelli di carico di lavoro. Una configurazione corretta è essenziale per raggiungere la saturazione della GPU, in quanto consente di estrarre il massimo valore dalle costose risorse GPU, garantendo al contempo un throughput elevato, una bassa latenza e operazioni convenienti. Le seguenti ottimizzazioni vi aiuteranno a massimizzare le prestazioni della vostra implementazione vLLm su EKS. ### Configurazioni VLLm di benchmark [Per ottimizzare i parametri di configurazione VLLM in base al tuo caso d'uso, esegui il benchmark di diverse impostazioni utilizzando uno strumento completo di benchmarking dell'inferenza come GuideLM.](https://github.com/vllm-project/guidellm) Questo raccoglierà metriche chiave come il throughput della richiesta al secondo (RPS), la latenza (E2E), il time to first token (TTFT) e end-to-end la latenza di coda (TPOT) per confrontare diverse configurazioni. ### Configurazione vLLM di base Questa è la configurazione di base utilizzata per eseguire VLLm: | Parametro vLLm | Description | | --- | --- | | tensor\$1parallel\$1size: 1 | Distribuisci il modello su 1 GPU | | gpu\$1memory\$1utilization: 0,90 | Riserva il 10% di memoria GPU per il sovraccarico del sistema | | lunghezza massima della sequenza: 8192 | Lunghezza totale massima della sequenza (ingresso\$1uscita) | | max\$1num\$1seqs: 1 | Numero massimo di richieste simultanee per GPU (Batching) | Esegui GuideLLM con questa configurazione di base per stabilire una linea di base delle prestazioni. Per questo test, GuidellM è configurato per generare 1 richiesta al secondo, con richieste a 256 token e risposte a 128 token. ``` guidellm benchmark \ --target "http://${NLB}:80" \ --processor meta-llama/Llama-3.1-8B-Instruct \ --rate-type constant \ --rate 1 \ --max-seconds 30 \ --data "prompt_tokens=256,output_tokens=128" ``` Output previsto: **Risultati del benchmark di base** ![\[Risultati del benchmark di base\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/llm-inference-vllm-guidellm-baseline.png) ### Configurazione VLLm ottimizzata Regola i parametri VLLm per utilizzare meglio le risorse della GPU e la parallelizzazione: | Parametro VLLm | Description | | --- | --- | | tensor\$1parallel\$1size: 1 | Mantieni 1 GPU. La parallelizzazione dei tensori deve corrispondere al numero di che deve essere utilizzato da vLLM GPUs | | gpu\$1memory\$1utilization: 0,92 | Riduci il sovraccarico di memoria della GPU, se possibile, assicurando al contempo che VLLm continui a funzionare senza errori | | lunghezza massima della sequenza: 4096 | Adatta la sequenza massima in base ai requisiti del caso d'uso; una sequenza massima inferiore libera risorse che possono essere utilizzate per una maggiore parallelizzazione | | max\$1num\$1seqs: 8 | L'aumento del numero massimo di seq aumenta il throughput ma aumenta anche la latenza. Aumentate questo valore per massimizzare il throughput assicurandovi al contempo che la latenza rimanga entro i requisiti del vostro caso d'uso | Applica queste modifiche alla distribuzione in esecuzione utilizzando il comando kubectl patch: ``` kubectl patch deployment vllm-inference-app --type='json' -p='[ {"op": "replace", "path": "/spec/template/spec/containers/0/args/4", "value": "--gpu-memory-utilization=0.92"}, {"op": "replace", "path": "/spec/template/spec/containers/0/args/5", "value": "--max-model-len=4096"}, {"op": "replace", "path": "/spec/template/spec/containers/0/args/6", "value": "--max-num-seqs=8"} ]' ``` Verifica che il pod VLLm sia nello stato: `Ready 1/1` ``` kubectl get pod -l app=vllm-inference-app -w ``` Output previsto: ``` NAME READY UP-TO-DATE AVAILABLE AGE vllm-inference-app-65df5fddc8-5kmjm 1/1 1 1 5m ``` Quindi esegui nuovamente GuideLM utilizzando gli stessi valori di benchmarking di prima: ``` guidellm benchmark \ --target "http://${NLB}:80" \ --processor meta-llama/Llama-3.1-8B-Instruct \ --rate-type constant \ --rate 1 \ --max-seconds 30 \ --data "prompt_tokens=256,output_tokens=128" ``` Output previsto: **Risultati di benchmark ottimizzati** ![\[Risultati di benchmark ottimizzati\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/llm-inference-vllm-guidellm-optimized.png) ### Risultati del benchmarking Calcola i risultati del benchmarking in una tabella per la configurazione vLLM di base e ottimizzata: | Valori medi | Configurazione di base | Configurazione ottimizzata | | --- | --- | --- | | RPS | 0,23 giri/sec | 0,86 giri/sec | | E2E | 12,99 s | 5,19 s | | TTFT | 8637,2 ms | 147,9 ms | | TROTTARE | 34,0 ms | 39,5 ms | Le configurazioni vLLM ottimizzate hanno migliorato significativamente il throughput di inferenza (RPS) e ridotto la latenza (E2E, TTFT) con solo un lieve aumento di millisecondi della latenza di coda (TPOT). Questi risultati dimostrano come vLLM migliori in modo significativo le prestazioni di inferenza, consentendo a ciascun contenitore di elaborare più richieste in meno tempo per un funzionamento conveniente.