Prestazioni e benchmarking dell'acceleratore AI

La valutazione dell'hardware AI da utilizzare con modelli linguistici di grandi dimensioni (LLM) come carico di lavoro principale richiede un approccio coerente e indipendente dal fornitore. Questa guida descrive una metodologia per confrontare le prestazioni dei chip di accelerazione AI di diversi fornitori come NVIDIA, AMD, Googlee AWS. I principi e la metodologia sono adattabili a qualsiasi chip o carico di lavoro AI, ma gli esempi si concentrano su un accoppiamento comune del settore di unità di elaborazione grafica (GPU) NVIDIA e Google unità di elaborazione tensoriale (TPU) che eseguono carichi di lavoro LLM.

I modelli vengono in genere ottimizzati per una piattaforma hardware specifica, pertanto la valutazione delle prestazioni del modello non è sufficiente per comprendere le funzionalità dell'hardware. Quando valuti i chip acceleratori per i LLM, considera tre dimensioni chiave: microbenchmarking, analisi roofline e benchmarking del modello per l'addestramento e l'inferenza.

Le analisi di microbenchmarking e roofline sono essenziali per comprendere le capacità e il potenziale di una determinata piattaforma di accelerazione. Una volta note queste informazioni, il benchmarking del modello tra addestramento e inferenza fornisce confronti reali dei workload tra i chip e informazioni sul fatto che l'architettura del modello sia ottimizzata per una piattaforma specifica.

Dimensioni del rendimento

Suggeriamo ai valutatori di pensare alle prestazioni in tre dimensioni per creare una comprensione più olistica di un determinato sistema di accelerazione:

  • Microbenchmarking: avere le specifiche hardware più elevate non significa che le applicazioni possono effettivamente utilizzare queste specifiche. Puoi utilizzare il microbenchmarking per valutare in che modo le operazioni in virgola mobile al secondo (FLOPS), la memoria ad alta larghezza di banda (HBM) e la larghezza di banda di rete influiscono su ciò che è realizzabile nei workload reali.
  • Analisi roofline: l'utilizzo ottimale dell'hardware può essere ostacolato dalla larghezza di banda della memoria o dalla velocità di calcolo. Puoi utilizzare un modello di profilo del tetto e l'intensità operativa (OI) di diversi componenti del sistema per vedere quanto sono adatti l'hardware e i workload l'uno all'altro. Una combinazione di microbenchmark e roofline fornisce una valutazione teorica di ciò che l'hardware selezionato può ottenere per diversi tipi di carichi di lavoro.
  • Benchmark del modello:il benchmarking tra i carichi di lavoro di addestramento e inferenza per misurare i token al secondo per chip (TPS/chip) consente di valutare lo stesso modello su piattaforme diverse. Se i risultati iniziali differiscono dall'analisi microbenchmark e roofline, è un'indicazione che è necessario un lavoro software aggiuntivo per raggiungere le roofline identificate in precedenza. Ad esempio, questo lavoro potrebbe comportare la modifica delle strategie di sharding o l'utilizzo di kernel personalizzati.

Ricorda che il benchmarking del modello è un approccio istantaneo per un determinato modello, scala e piattaforma. Gli utenti esperti prendono in considerazione anche le tendenze del settore (come l'architettura del modello), il microbenchmarking e i risultati della roofline durante la valutazione delle prestazioni.

Co-design di modello e hardware

Le valutazioni delle prestazioni devono considerare attentamente l'architettura del modello nel contesto dell'hardware in fase di test. I modelli progettati in modo efficiente vengono spesso progettati congiuntamente per una piattaforma hardware specifica per sfruttare le sfumature specifiche della piattaforma. Di conseguenza, questi modelli potrebbero non utilizzare completamente altre piattaforme o anche diverse generazioni della stessa piattaforma. Ad esempio, un modello progettato per le GPU NVIDIA Hopper potrebbe non utilizzare completamente le GPU AMD o le GPU NVIDIA Blackwell.

Questa considerazione è particolarmente importante quando si passa da una piattaforma hardware a un'altra che potrebbe differire per funzionalità, perché un modello progettato per una piattaforma potrebbe richiedere modifiche alla configurazione, al software o a entrambi per ottenere le massime prestazioni su una piattaforma diversa. Il benchmarking dei modelli ottimizzati è essenziale per convalidare le affermazioni di marketing dei fornitori relative alle prestazioni "teoriche di picco" e misurare i risultati reali. La società di analisi indipendente SemiAnalysis osserva che "Il confronto dei FLOPS teorici racconta solo una parte della storia. Ciò che conta sono i FLOPS effettivi, poiché i numeri di picco non vengono quasi mai raggiunti nei carichi di lavoro reali."

Esempio: la sfida gpt-oss-120B

Un errore comune nel benchmarking è la valutazione di un modello su hardware per cui non è stato progettato. Il gpt-oss-120B modello open-weight di OpenAI è un esempio del motivo per cui l'architettura del modello deve essere mappata attentamente al silicio di destinazione. L'esempio seguente mostra che la progettazione congiunta del modello è fondamentale e deve avvenire all'inizio del processo.

Il modello gpt-oss-120B utilizza una dimensione della testa di attenzione di 64. Sebbene questo sia lo standard per molti modelli ottimizzati per GPU, crea una mancata corrispondenza architetturale per gli acceleratori TPU. Le TPU come Trillium e Ironwood sono ottimizzate per dimensioni della matrice che sono multipli di 256 per saturare completamente le unità di moltiplicazione della matrice (MXU). Poiché la dimensione dell'intestazione, 64, non è ottimizzata per le TPU, l'esecuzione di gpt-oss-120B su un sistema TPU comporta un numero inferiore di token al secondo (TPS) e un utilizzo FLOP del modello (MFU) inferiore. L'hardware spreca in modo efficace i cicli di clock e l'alimentazione riempiendo lo spazio rimanente con zeri per adattarsi alle griglie di esecuzione 256x256.

L'utilizzo di gpt-oss-120B come benchmark per le TPU potrebbe segnalare erroneamente una scarsa capacità hardware quando in realtà riflette una mancata corrispondenza dell'architettura software. Per valutare con precisione il "limite" di un acceleratore, testalo con modelli progettati in modo specifico per la sua geometria. Ad esempio, modelli con dimensioni della testa di 128 o 256, come Gemma 4. Puoi migliorare le prestazioni di questo modello con kernel personalizzati che evitano il riempimento con zeri e "riempiono" invece l'MXU, il che richiede competenze e non raggiunge lo stesso livello di prestazioni delle GPU. Puoi anche modificare le dimensioni dell'intestazione per ottimizzarle per le TPU, ma questa modifica invalida i pesi del modello esistenti, richiedendo un nuovo addestramento.

Principi di benchmarking

Per fornire valutazioni eque e a prova di futuro, tieni conto dei seguenti principi per il benchmarking tra gli acceleratori:

  • Concentrati sul rendimento per dollaro:alcuni fornitori si concentrano sulle prestazioni grezze del singolo chip, ma le prestazioni a livello di sistema per dollaro sono più rappresentative del costo totale di proprietà (TCO) e del valore complessivi. Se il chip A è il 20% più performante e il 50% più costoso del chip B, i valutatori devono riconoscere i vantaggi in termini di prestazioni per dollaro del chip B. Considera anche le prestazioni per watt come parte del costo.
  • Rappresentare i moderni carichi di lavoro di AI: concentrati sui modelli basati su transformer più diffusi, sui cluster di grandi dimensioni e sui framework più recenti, tenendo conto delle tendenze del settore. Ad esempio, il passaggio del settore a modelli di mixture of experts (MoE) più sparsi rende più difficile ottimizzare completamente i FLOPS, richiedendo al contempo una larghezza di banda di bisezione maggiore dalle reti.
  • Garantisci un ampio supporto per i requisiti degli sviluppatori:considera le prestazioni, la flessibilità e la scalabilità in diversi carichi di lavoro: addestramento, ottimizzazione e servizio in una gamma di LLM e altri modelli.
  • Scegli modelli e strumenti indipendenti dal fornitore:scegli modelli e motori che funzionano su più acceleratori per semplificare le valutazioni cross-accelerator. Ad esempio, utilizza modelli aperti come Qwen e Gemma, nonché motori di inferenza open source che vengono eseguiti su GPU e TPU, come vLLM. Evita stack PyTorch/CUDA specifici per l'hardware. Per il benchmarking dell'addestramento dei modelli, i framework specifici del fornitore (come MaxText per le TPU e Megatron per le GPU) sono i più utili quando i modelli vengono mantenuti costanti su piattaforme diverse.
  • Progettazione congiunta del modello: gli utenti esperti progettano congiuntamente i loro modelli per ottenere il massimo dalla piattaforma hardware. Non aspettarti che un modello addestrato sul chip A abbia buone prestazioni "out-of-the-box" sul chip B.
  • Considera l'intero sistema hardware: alcuni acceleratori possono pubblicizzare prestazioni elevate in un'area come i FLOPS. Tuttavia, i colli di bottiglia in altre aree, come la larghezza di banda della memoria, possono limitare notevolmente le capacità dell'acceleratore. Altri aspetti del sistema da considerare sono le specifiche del chip, il networking del chip e l'architettura di scalabilità orizzontale.
  • Affidabilità di hardware e software: le interruzioni durante l'addestramento su larga scala o le operazioni di inferenza critiche possono essere estremamente costose. Allo stesso modo, un acceleratore AI è utile solo quanto il software che viene eseguito su di esso. Uno stack software maturo e affidabile, collaudato su vasta scala, è essenziale per massimizzare il valore.

Microbenchmark

Nel contesto del benchmarking degli acceleratori, il microbenchmarking isola componenti hardware specifici, come core di calcolo, memoria e interconnessioni, per misurarne i limiti assoluti senza l'interferenza di stack software complessi. Molti fornitori mettono in evidenza i "FLOPS di picco su un singolo chip", ma l'AI nel mondo reale è un problema di sistemi distribuiti. Il microbenchmarking ti aiuta a capire se un chip è semplicemente potente in isolamento o se è progettato per la scala del data center.

Utilizza il microbenchmarking per misurare le prestazioni di picco dell'hardware e scoprire i limiti reali del sistema, indipendentemente dall'architettura del modello. Il microbenchmarking è particolarmente utile per valutare gli acceleratori rispetto a casi d'uso e architetture di modelli futuri o indeterminati.

Per eseguire il microbenchmark degli acceleratori in modo efficace, valuta quanto segue:

Benchmark Spiegazione
Utilizzo della moltiplicazione di matrici generali dense (GEMM) Esegui kernel GEMM altamente ottimizzati in varie precisioni per misurare la potenza matematica grezza e sostenuta delle unità di calcolo principali dell'acceleratore.
Streaming HBM (High Bandwidth Memory) Esegui microbenchmark della larghezza di banda della memoria per misurare le velocità di lettura, scrittura e copia sostenute della memoria integrata dell'acceleratore. Le architetture che mantengono un rapporto byte-FLOP sano impediscono ai core di calcolo di rimanere inattivi.
Collettivi distribuiti (all-reduce e all-gather) Esegui test di comunicazione collettiva standardizzati su migliaia di chip per misurare il livello di degrado della larghezza di banda e della latenza della rete man mano che il cluster viene scalato.
Velocità di trasferimento da host a dispositivo (H2D) e da dispositivo a host (D2H) Trasferisci flussi di dati continui di grandi dimensioni tra la memoria di sistema della CPU host e l'acceleratore per misurare le velocità di trasferimento sul bus PCIe o sull'interconnessione personalizzata.
Limitazione termica e assorbimento di potenza prolungati Esegui un ciclo GEMM di utilizzo massimo ininterrottamente per 48 ore monitorando l'assorbimento di potenza a livello di rack per valutare la stabilità termica sostenuta e l'efficienza energetica nel mondo reale.

Esempio di confronto di microbenchmark

Ecco un confronto illustrativo tra due chip, in cui un ipotetico chip A potrebbe sembrare migliore di un ipotetico chip B, ma avere prestazioni peggiori nella pratica:

Nome del benchmark Risultato del test del chip A Specifica del chip A Rapporto test / specifiche Risultato del test del chip B Specifica del chip B Rapporto test / specifiche
Networking chip-to-chip 800 GBps 1000 Gbps 80,0% 850 GBps 900 GBps 94,4%
gemm/peakTOPS 1800 TFLOPS 2500 TFLOPS 72,0% 1800 TFLOPS 2000 TFLOPS 90,0%
Larghezza di banda della memoria 6000 GBps 8000 GBps 75% 6500 GBps 7500 GBps 86,7%
Da host a dispositivo 58 GBps/chip 70 GBps/chip 82,9% 60 GBps/chip 65 GBps/chip 92,3%
Da dispositivo a host 55 GBps/chip 70 GBps/chip 78,6% 55 GBps/chip 65 GBps/chip 84,6%

Analisi del profilo del tetto

Un'analisi del profilo del tetto (o modello del profilo del tetto) può fornirti una visualizzazione per analizzare l'intensità operativa (OI) dei diversi componenti del sistema e quanto bene progetti specifici si adattino a piattaforme specifiche.

Il throughput di un chip acceleratore per l'AI è limitato da tre fattori principali:

  1. Capacità di calcolo:il throughput matematico di picco del chip (FLOPS).
  2. Larghezza di banda della memoria:la velocità con cui i dati possono essere trasferiti alla o dalla memoria HBM (High Bandwidth Memory) locale del chip.
  3. Larghezza di banda della rete:la velocità con cui i dati possono essere condivisi tra più chip utilizzando il networking dei chip durante l'addestramento o l'inferenza distribuiti. Ad esempio, la velocità di trasferimento di ICI (per le TPU) o NVLink (per le GPU).

Per saperne di più sui profili del tetto, vedi Tutto sui profili del tetto.

Il grafico roofline standard è costituito da due assi:

  • Asse X (intensità operativa): l'intensità operativa è il rapporto tra il lavoro di calcolo (FLOPS) e il traffico di memoria (byte trasferiti), espresso come FLOPS per byte. Rappresenta la quantità di lavoro di calcolo eseguito per ogni byte di dati recuperati dalla memoria.
  • Asse Y (prestazioni raggiungibili): le prestazioni raggiungibili sono espresse come FLOPS al secondo. Rappresenta il throughput di calcolo effettivo ottenuto.

Un grafico del modello roofline che mostra come le prestazioni di picco dell'hardware siano limitate dalla larghezza di banda della memoria e dalla capacità di calcolo

Il "tetto" è formato da due linee che si intersecano e rappresentano i valori massimi dell'hardware:

  1. Il tetto inclinato (vincolato alla memoria): Prestazioni raggiungibili = Larghezza di banda memoria di picco × Intensità operativa. Su questa linea, le prestazioni sono strettamente limitate dalla velocità con cui i dati possono essere inviati alle unità di calcolo.
  2. Il tetto piatto (vincolato al calcolo): Prestazioni raggiungibili = Capacità di calcolo di picco. Su questa linea, i dati vengono forniti abbastanza velocemente da consentire alle unità di calcolo di funzionare alla massima capacità.

Il punto in cui queste due linee si intersecano è noto come punto di cresta. Definisce l'OI minima richiesta da un workload per ottenere l'utilizzo massimo dell'hardware.

Nell'immagine precedente, Algo 1 si trova nella parte del grafico etichettata"memory bound" e non utilizza completamente le unità di calcolo. Al contrario, l'algoritmo 2 ha un OI più elevato e si trova nella parte del grafico etichettata "compute bound". Per ottimizzare l'algoritmo 1, un utente proverebbe a modificarlo per eseguire più calcoli con meno spostamento di dati (aumentare l'OI) per spostare il rendimento a destra, verso il punto di cresta.

Esempi di workload con I/O basso e alto

  • Bassa intensità operativa HBM (vincolo di memoria): carichi di lavoro come operazioni element-wise (funzioni di attivazione come ReLU o GeLU), normalizzazione dei livelli e decodifica autoregressiva (inferenza con dimensione del batch = 1).
  • Elevata intensità operativa HBM (vincolo di calcolo): workload come GEMM o reti neurali convoluzionali di grandi dimensioni. La moltiplicazione di matrici riutilizza i dati recuperati molte volte (moltiplicando le righe per le colonne), quindi l'OI è molto alto e i carichi di lavoro si trovano sotto il tetto del calcolo piatto.

Benchmarking del modello

Il benchmarking del modello misura le prestazioni effettive del modello. I benchmark di addestramento e inferenza ti consentono di confrontare le prestazioni dei modelli più diffusi in un momento specifico.

La tabella seguente confronta gli approfondimenti che puoi ottenere dal benchmarking dei modelli per i workload di addestramento e inferenza:

Insight Workload di addestramento Workload di inferenza
Scala Spesso test su larga scala (oltre 10.000 chip, fino a oltre 100.000 per i modelli più grandi). Fornisce informazioni dettagliate sui carichi di lavoro distribuiti, sull'overhead di comunicazione e sui limiti di networking a livello di cluster. Spesso test più piccoli (1-64+ chip). Fornisce informazioni su come la piattaforma gestisce utenti simultanei e un rapido aumento del carico.
Prestazioni Spesso più vincolati alla potenza di calcolo. Misura i token elaborati al secondo per chip e l'utilizzo FLOP del modello (MFU). Sensibile alla latenza. Misura il tempo al primo token (TTFT), la latenza tra i token e il numero totale di token generati al secondo per utente.
Latenza Latenza I/O e di interconnessione che evidenzia i colli di bottiglia dello spazio di archiviazione durante il caricamento di set di dati di grandi dimensioni e la latenza di rete tra i nodi durante gli aggiornamenti sincroni del gradiente. Latenza di risposta end-to-end che evidenzia i ritardi di accodamento, la latenza dell'endpoint e i tempi di attesa per gli utenti.

Benchmarking dell'addestramento

Per determinare la vera efficienza di hardware e networking, devi normalizzare il rendimento in una singola metrica comparabile tra gli acceleratori: Token al secondo per chip (TPS/chip), mantenendo costante un'architettura di modello rappresentativa specifica. Monitorando il comportamento di TPS/chip man mano che aumenti le dimensioni di un cluster, scopri la "tassa di scalabilità" nascosta del sistema.

Per normalizzare il rendimento in base al costo degli acceleratori, dividi ulteriormente TPS/chip per il costo di ogni chip per ottenere TPS/chip/$, che diventa un altro punto di confronto.

Per ogni modello di cui viene eseguito il benchmark, valuta quanto segue:

Benchmark Spiegazione
Misura TPS/chip e TPS/chip/$ di base

Esegui il modello di destinazione sul cluster più piccolo possibile. Registra il throughput di addestramento globale (token totali elaborati al secondo) e dividilo per il numero di chip per stabilire il TPS/chip di base. Dividi per il costo dell'acceleratore per ottenere TPS/chip/$.

In alternativa, osserva l'utilizzo FLOP del modello (MFU) durante l'addestramento per misurare il rapporto tra il throughput osservato e il massimo teorico. Questo è utile per capire quanto le prestazioni dell'hardware si avvicinano al benchmarking. Tuttavia, non fornisce un confronto tra chip altrettanto utile di TPS/chip.
Valuta il degrado della scalabilità Scala il cluster a 256, 1024 e 4096 chip, eseguendo esattamente lo stesso modello. Ricalcola TPS/chip a ogni scala.
Account per il goodput

Il TPS/chip grezzo è importante solo se il modello sta effettivamente apprendendo. Calcola il goodput per misurare la velocità di calcolo utile che fa avanzare direttamente lo stato di addestramento di un LLM, escludendo esplicitamente il tempo e l'energia sprecati per guasti hardware, interruzioni di rete o recuperi dei checkpoint.

Quando valuti gli acceleratori AI su larga scala, il goodput fornisce un'immagine più realistica del ritorno sull'investimento rispetto al throughput teorico grezzo, in quanto rivela l'efficacia con cui l'hardware mantiene le prestazioni in cluster reali e soggetti a errori.

La seguente tabella elenca i modelli consigliati per il benchmark per l'addestramento:

Dimensioni Architettura Modello Rationale
Small (8B) Denso Llama 3.1 8B Llama 3 è un modello standard, popolare da anni con standard di benchmarking come MLPerf.
Medio (70B) Denso Llama 3.1 70B Llama 3 è un modello standard, popolare da anni con standard di benchmarking come MLPerf.
Large (671B) MoE DeepSeek-V3 671B DeepSeek-V3 ha stabilito un nuovo standard di dimensioni e prestazioni nel 2025 ed è ben ottimizzato su molte piattaforme multi-chip.

Esempio: normalizzazione in base al rendimento per dollaro

Considera un confronto benchmark tra Chip_A, Chip_B e Chip_C in cui hai eseguito benchmark di addestramento per modelli comuni per visualizzare le prestazioni in TPS. Poi esamini il rapporto tra le prestazioni di Chip_A e quelle di Chip_B e Chip_C per lo stesso modello:

Benchmark TPS di Chip_A come frazione del TPS di Chip_B TPS di Chip_A come frazione del TPS di Chip_C
Small dense: Llama 3.1 8B 0,82 0,62
MoE: Mixtral 8x7B 0,72 0,55
Large dense: Llama 3.1 405B 0,77 0,61
Large MoE: DeepSeek-V3 0,85 0,62
Valore medio 0.79 0,60

In base ai dati della tabella precedente, il rendimento di Chip_A è in media pari allo 0,79 del rendimento di Chip_B e allo 0,60 del rendimento di Chip_C. Senza ulteriori informazioni, la conclusione sarebbe che Chip_C è superiore.

Tuttavia, se il chip A costa 100 $, il chip B costa 180 $e il chip C costa 200 $, la normalizzazione del rendimento per dollaro (rendimento/$) cambia il risultato:

Benchmark Chip_A perf/$ come frazione di Chip_B perf/$ Chip_A perf/$ come frazione di Chip_C perf/$
Small dense: Llama 3.1 8B 1,48 1,24
MoE: Mixtral 8x7B 1,30 1,10
Large dense: Llama 3.1 405B 1,39 1,22
Large MoE: DeepSeek-V3 1,53 1,24
Valore medio 1,42 1,20

Se consideri il rendimento/€ come punto di confronto, Chip_A supera Chip_B in media del 42% e Chip_C in media del 20%.

Benchmarking dell'inferenza

L'addestramento è un'enorme spesa in conto capitale iniziale, ma l'erogazione (e quindi l'inferenza) rappresenta una spesa operativa a lungo termine. Un TPS/chip più elevato significa che hai bisogno di meno server fisici per supportare gli stessi workload operativi, riducendo drasticamente il consumo energetico e l'impronta del data center.

Nell'inferenza, l'obiettivo è massimizzare la velocità effettiva senza violare i requisiti di latenza per garantire un'esperienza utente reattiva. Standardizzando la valutazione su TPS/chip per un modello fisso, puoi confrontare direttamente il rendimento tra chip diversi.

Quando esegui il benchmarking dell'inferenza, normalizza le prestazioni calcolando TPS/chip/$:

Benchmark Spiegazione
Stabilisci l'SLA di latenza

Innanzitutto, imposta un SLA rigoroso per l'esperienza utente. Ad esempio, una latenza di coda (P99) prevedibile di 100 millisecondi. Misura l'esperienza utente di reattività utilizzando TTFT (meno di 500 ms) e Time Per Output Token (TPOT).
Aumenta la dimensione del batch Aumenta gradualmente il numero di richieste simultanee (dimensione del batch) rispetto all'hardware. All'aumentare della dimensione del batch, la velocità effettiva aumenta, ma la latenza alla fine peggiora.
Registra il TPS/chip massimo sostenuto

Quando l'hardware viola l'SLA di latenza P99, interrompi. Registra il throughput totale del sistema con le dimensioni esatte del batch e dividilo per il numero di chip. Questo è il valore TPS/chip.

Tieni presente che alcuni acceleratori per uso generico hanno difficoltà con la "latenza di coda" (picchi casuali nel tempo di elaborazione) in caso di carichi batch elevati, costringendo gli operatori a eseguirli a un utilizzo inferiore per mantenere gli utenti soddisfatti.

Assicurati di misurare le due fasi distinte del precompilamento (vincolato al calcolo) e della decodifica (vincolato alla larghezza di banda della memoria).
Calcolare il TCO per mille o un milione di token Dividi il costo ammortizzato del capitale e dell'energia di un chip per il suo TPS/chip massimo sostenuto. In questo modo, il benchmark tecnico viene convertito in una metrica finanziaria, rivelando il costo effettivo.

La seguente tabella elenca i modelli consigliati per il benchmark per l'inferenza:

Dimensioni Architettura Modello Rationale
Small (8B) Denso Llama 3.1 8B Llama 3 è un modello standard, popolare da anni con standard di benchmarking come MLPerf.
Medio (70B) Denso Llama 3.1 70B Llama 3 è un modello standard, popolare da anni con standard di benchmarking come MLPerf.
Grande (480 B) MoE Qwen3 Coder 480B Qwen3 480B è un modello di programmazione OSS leader.

Passaggi successivi