Per eseguire NVIDIA Nemotron 3.5 Super VL sul percorso EKS standard di AWS servono accesso a istanze GPU specifiche, Git e Docker in locale e credenziali con i permessi necessari. L’esempio AWS descrive i primi passaggi per creare il cluster; poi prosegue con installazione dei componenti, distribuzione del modello e benchmark.

Cosa serve prima di iniziare

L’esempio AWS richiede un account con accesso a istanze EC2 P5en.48xlarge o P6-b200.48xlarge. Potrebbe essere necessario chiedere un aumento della quota GPU o prenotare capacità. Sul computer da cui si avvia la procedura servono Git e Docker; le credenziali AWS devono poter gestire EC2, EKS e FSx for Lustre. L’esempio AWS circoscrive questi requisiti al proprio percorso.

I primi passaggi con EKS standard

La sequenza seguente riguarda la fase iniziale del percorso EKS standard. I comandi ./... vanno eseguiti nella posizione indicata dalla guida: prima nel repository, poi nell’ambiente ausiliario.

  1. Clona il repository aws-do-eks con git clone https://github.com/aws-samples/aws-do-eks ed entra nella cartella con cd aws-do-eks. Questo prepara i file usati dall’esempio.
  2. Imposta la regione AWS con ./config.sh.
  3. Crea l’immagine locale del container ausiliario con ./build.sh.
  4. Avvia il container con ./run.sh e controllane lo stato con ./status.sh.
  5. Apri la shell del container con ./exec.sh.
  6. Nell’ambiente ausiliario, configura le credenziali con aws configure.
  7. Seleziona il manifest del cluster con ./env-config.sh, quindi modifica le impostazioni con ./eks-config.sh.
  8. Avvia la creazione del cluster con ./eks-create.sh. AWS indica che questa operazione può richiedere fino a 30 minuti.
  9. Controlla i nodi creati con kubectl get nodes.

Dopo la creazione del cluster, l’esempio continua con driver, plugin e operatori Kubernetes, validazione, download dei pesi, deployment, benchmark e rimozione delle risorse create.

Scegliere orchestrazione e configurazione GPU

AWS descrive tre opzioni di orchestrazione: Amazon EKS standard, Amazon EKS Auto Mode e Amazon SageMaker HyperPod EKS. Auto Mode gestisce scaling, GPU ed Elastic Fabric Adapter (EFA); AWS indica che gli stessi manifest Kubernetes possono essere usati con tutte e tre le opzioni. L’esempio contempla inoltre storage su EBS insieme a FSx oppure su FSx soltanto, precisione BF16 o NVFP4 e serving aggregato o disaggregato. Per quest’ultimo, NVIDIA Dynamo può separare le fasi di prefill e decode su nodi diversi.

La tabella riporta i minimi di GPU indicati da AWS per servire il modello con vLLM. Sono requisiti minimi del serving, non un dimensionamento completo del cluster.

Modello GPUGPU minime con BF16GPU minime con NVFP4
B200/GB20082
B300/GB30041
H20084
H100168

Nell’architettura descritta da AWS, i nodi CPU e GPU lavorano insieme; Amazon ECR ospita le immagini dei container, FSx for Lustre conserva i pesi del modello e EFA collega i nodi GPU. La scelta tra i minimi GPU e la configurazione reale dipende quindi anche dall’architettura del cluster e dal carico da servire.

Come interpretare il benchmark di latenza

AWS riporta un tempo al primo token (TTFT) più basso e una latenza tra token (ITL) simile per una configurazione disaggregata a due nodi rispetto a una aggregata. Il grafico riguarda Nemotron 3.5 Super VL 120B-A12B in BF16 su H200, con 1.024 token di input, 512 di output, concorrenza da 1 a 128 e un’esecuzione per ciascun punto. La configurazione aggregata usa 8 GPU, quella disaggregata 16. Il risultato descrive dunque configurazioni con risorse diverse, non un confronto a parità di GPU. AWS presenta il test e le sue condizioni.

Per verificare il cluster, AWS indica un microbenchmark all-reduce di NCCL: durante il test, l’attività sulle GPU e sugli adattatori EFA è un segnale che cluster e rete funzionano come previsto. Per misurare il modello, suggerisce NVIDIA aiperf, che rileva TTFT, ITL e throughput a diversi livelli di concorrenza. AWS collega un aumento dell’ITL alla necessità di aggiungere capacità di decode e un aumento del TTFT a quella di aggiungere capacità di prefill. Misurare il proprio carico con queste metriche permette di valutare le configurazioni in base ai tempi di risposta e al throughput richiesti.