Salta al contenuto principale
27 Mar 2026 Hammer Enterprise

Accelerare l'innovazione automobilistica in Europa con Cornelis Networks CN5000® e Hammer

 

La ricerca e sviluppo automobilistica europea è in una fase di sprint: i programmi di elettrificazione, i veicoli definiti dal software, la validazione ADAS/AV e i gemelli digitali delle fabbriche spingono tutti i carichi di lavoro di simulazione e intelligenza artificiale su cluster GPU/CPU più grandi con cicli di iterazione più serrati.

Il limite nascosto non è più il calcolo. È la rete—spostare gradienti, dataset di sensori, mesh e messaggi MPI abbastanza velocemente da non far arenare i team a causa di latenza di coda, congestione o prestazioni imprevedibili sotto carico.

È qui che si inserisce Cornelis Networks CN5000: un'interconnessione end-to-end progettata su misura per un traffico senza perdite e senza congestione a 400G con latenza MPI sub-microsecondo e gestione della congestione a livello di fabric, basata sull'architettura Omni-Path.

E, abbinato alle capacità di distribuzione e integrazione di Hammer focalizzate sull'Europa, diventa un percorso pratico per le organizzazioni automobilistiche per implementare e supportare reti ad alte prestazioni tra team di ingegneria multi-sito. 

Perché l'innovazione automobilistica ora dipende dalla rete

I flussi di lavoro dell'ingegneria automobilistica sono sempre più interconnessi e iterativi:

    • Simulazione di crash & sicurezza (grandi job MPI, molti messaggi piccoli, sensibile alla latenza e alla latenza di coda)
    • CFD, analisi aerodinamica e termica (grandi decomposizioni di dominio con comunicazione all-to-all)
    • Modellazione di batterie ed elettronica di potenza (multi-fisica, grandi insiemi)
    • Addestramento della percezione ADAS e della fusione dei sensori (comunicazione collettiva AI distribuita)
    • Gemelli digitali di veicoli e impianti (flussi di dati continui, test rapidi di scenari)

Man mano che i cluster crescono, “una buona larghezza di banda media” non è più sufficiente.. I team automobilistici hanno bisogno di:

    • Prestazioni prevedibili sotto carico
    • Bassa latenza di coda (così il rank/worker più lento non domina il tempo di step)
    • Gestione della congestione che regge in condizioni reali di uso misto, non solo nei modelli di traffico migliori

Il CN5000 in un minuto

CN5000 è posizionato come una rete scale-out senza perdite e senza congestione per AI e HPC, progettata per mantenere prestazioni stabili mentre si cresce.

A colpo d'occhio:

    • Larghezza di banda 400G per porta
    • < 1 µs di latenza MPI (punti salienti di Switch e SuperNIC)
    • I blocchi costruttivi architetturali includono:
      • Controllo del flusso basato su credito
      • Ritrasmissioni a livello di collegamento
      • Gestione della congestione a livello di fabric

Routing multipathRouting adattivo a grana fine (FGAR) e controllo del flusso consapevole dell'incast indicati come parte dell'approccio alla gestione della congestione

Con oltre 240 ingegneri e tecnologi dedicati al progresso dell'innovazione di rete, Cornelis e Hammer sono focalizzati sullo sblocco di una maggiore efficienza dei data center. Il nostro portfolio completo di SuperNIC e switch si basa sulla nostra eredità di inventori di Omni-Path, un'architettura progettata per offrire le prestazioni di rete più elevate nell'era del scale-out e un set di funzionalità fondamentali per Ultra Ethernet. Offriamo prestazioni leader del settore, tra cui latenza ultra-bassa, velocità di messaggio elevate e prestazioni applicative ottimizzate.

Esempio di impatto per il cliente:
Miglioramento della produttività delle simulazioni aerodinamiche per i team automotive e meccanici, con un aumento fino a 2× della produttività delle iterazioni di progettazione, riducendo al contempo la dipendenza da costosi prototipi fisici e test in galleria del vento.


    • CN5000 Switch:
      • 48 porte da 400G

 

CN5000 vs InfiniBand vs RoCEv2 Ethernet (Confronto focalizzato sull'automotive)

Cosa stai confrontando

Cornelis Networks CN5000 (Omni-Path)

InfiniBand NDR 400 (es. Quantum-2)

Ethernet 400G con RoCEv2

Intento primario

Fabric scale-out progettato appositamente per AI + HPC con un focus progettuale lossless e congestion-free.

Fabric HPC/AI con routing adattivo e controllo della congestione come parte del valore della piattaforma.

Ethernet open-standard adattato per AI/HPC a bassa latenza utilizzando tecniche “lossless” (spesso PFC + ECN + controllo della congestione end-to-end come DCQCN).

Classe di velocità del collegamento

400G per porta (opzioni Switch e SuperNIC).

400Gb/s per porta (NDR 400).

Comunemente Ethernet 400G; RoCEv2 utilizzato per RDMA (dipende dal design/fornitore).

Densità di porte switch 1U (esempio)

48 × 400G Switch; 38.4T full duplex.

Spesso 64 × 400Gb/s in 1U (dipende dal modello).

Varia ampiamente; il comportamento dipende fortemente da ASIC/fornitore e dalle tue scelte di QoS/buffer/ECMP/telemetria e ottimizzazione.

Approccio alla congestione / senza perdite (alto livello)

Credit-based flow control, link-level retransmissions, fabric-level congestion management, multipath routing—aimed at predictable performance and reduced tail latency.

Controllo della congestione a livello di piattaforma, QoS/lane virtuali, routing adattivo; può includere funzionalità di accelerazione in rete (specifiche della piattaforma).

“Ethernet senza perdite” utilizza tipicamente PFC per evitare cadute più ECN per marcare la congestione e segnalare la riduzione della velocità; il successo operativo dipende dalla disciplina di configurazione.

Avvertenze operative

Trattalo come un sistema end-to-end (Switch + SuperNIC + software) per allinearsi all'architettura prevista.

Scelta forte dove l'ecosistema/strumentazione IB e i flussi di lavoro esistenti sono consolidati.

I risultati di RoCEv2 dipendono fortemente da una corretta progettazione PFC/ECN e da una disciplina operativa continua; le configurazioni errate possono creare gravi comportamenti di congestione/latenza.

 

Cosa significa “Lossless, Congestion-Free” nei risultati ingegneristici quotidiani

Tempi di risoluzione del solver più rapidi -

Nelle grandi simulazioni MPI, il tempo di esecuzione può essere dominato dalle fasi di comunicazione (scambio di halo, riduzioni, sincronizzazione). CN5000 enfatizza l'ottimizzazione della velocità dei messaggi e della latenza insieme alla gestione della congestione—puntando a prestazioni prevedibili sotto carico.

Migliore efficienza dell'addestramento AI distribuito (stack ADAS/AV e autonomia)

CN5000 si posiziona come una fabric progettata per l'addestramento e l'inferenza AI che mantiene la produttività sotto carico minimizzando gli eventi di congestione e la latenza di coda.

Dove lo sentirai: maggiore utilizzo della GPU (meno tempo in attesa delle collettive), tempi di step più stabili, miglioramento del time-to-train per nuovi domini sensoriali o varianti di modello.

Controllo pratico tramite telemetria (non congetture)

Quando più team condividono la stessa piattaforma, i modelli di traffico possono cambiare di ora in ora. CN5000 evidenzia la telemetria e la visibilità in tempo reale per supportare una gestione del traffico consapevole del carico di lavoro.

Dove lo noterai: individuazione più rapida della causa principale per il jitter delle prestazioni e una pianificazione della capacità più chiara, soprattutto in cluster a uso misto. 


Progettazione di CN5000 in cluster HPC e AI automobilistici reali

Trattare la congestione come il caso normale, non come un caso limite

Le piattaforme automotive sono quasi sempre a uso misto: CAE al mattino, training nel pomeriggio, pipeline di digital twin in background e tutti che spingono per “un'altra esecuzione” prima di una scadenza. CN5000 evidenzia la gestione della congestione a livello di fabric, il controllo di flusso incast-aware e il routing adattivo per sostenere le prestazioni sotto carico.

Mantieni la tua storia “lossless” end-to-end

Cornelis definisce la “trasmissione senza perdite e senza congestione” come una proprietà architetturale di CN5000 (Switch + SuperNIC + routing/controllo del flusso). In pratica: specificarlo come sistema, validarlo come sistema.

Vuoi saperne di più?