UEC-1.0-konform · DCQCN · DLB · GLB (OcNOS 7.1) · bis zu 16k GPUs

Eine offene AI Fabric: entwickelt für das, was Ihr Trainingsjob tatsächlich erlebt.

Bei tausenden Beschleunigern misst man Switches nicht in Tbps, gemessen wird Job Completion Time, GPU-Auslastung und Tail-Latenz unter Microbursts. OcNOS-DC erreicht diese Werte auf offenem Merchant Silicon mit einem 24/7-Carrier-Grade-SLA: dieselbe technische Basis wie geschlossene KI-Stacks, ohne deren Lock-in.

16k GPU
Obergrenze des Referenzdesigns
DCQCN
Für xCCL optimiert, jeder Schwellwert in YANG modelliert
DLB + GLB
Flowlet-basiertes lokales + fabric-weites Adaptive Routing
UEC 1.0
Am Fabric-Profil ausgerichtet · offene Antwort auf IB
Die Frage des Erbauers

„Wird mein Training-Job wirklich schneller fertig?"

Im großen Maßstab verlieren klassische Netzwerkmetriken an Aussagekraft. Was zählt, ist Job Completion Time, GPU-Auslastung und Tail-Latenz unter Microbursts, denn jede Minute, in der ein milliardenschwerer Cluster auf einen Synchronisationsschritt wartet, ist verbranntes Kapital.

Die verlustfreie Low-Latency-Performance, die KI-Workloads benötigen, setzt keinen geschlossenen proprietären Stack mehr voraus. Auf offenem Merchant Silicon mit Carrier-Grade-SLA erreicht OcNOS-DC dieselbe technische Basis wie geschlossene Architekturen: ohne Vendor Lock-in: mit Congestion Management, dynamischem Sub-Millisekunden-Routing und Ultra-Ethernet-Ausrichtung, abgestimmt auf die Burst-Muster kollektiven Datenverkehrs. GPUs verbringen ihre Zeit mit Datenverarbeitung, nicht mit Warten auf das Netzwerk.

Jeder Schwellenwert ist offengelegt, sodass Ihr Team ihn gegen realen xCCL-Traffic (NCCL / RCCL / oneCCL) abstimmen kann. Nachfolgend: jedes Workload-Profil, der zugehörige Mechanismus und das Ergebnis für den Betreiber.

AllReduce / AllGather
Jede GPU spricht mit jeder anderen GPU gleichzeitig.
Statisches ECMP bindet Elephant Flows an einen einzelnen Spine-Link: Hotspots, ungenutzte Uplinks, langsame Synchronisation.
DLB bindet Flowlets im Sub-Millisekundenbereich anhand der Queue-Tiefe neu.
GLB (OcNOS 7.1) bewertet Leaf · Spine · Super-Spine.
Ergebnis: Keine Hotspots durch Hash-Kollisionen; AllReduce bleibt nahe der Line-Rate.
Microburst / Incast
N Sender konvergieren auf eine Queue in Mikrosekunden.
Ein Drop startet die Kollektive neu; ein Pause-Sturm blockiert die Leitung. In beiden Fällen kommt der Lauf zum Erliegen.
DCQCN (xCCL-optimierte ECN + CNP) begrenzen die Rate vor dem Drop.
PFC Watchdog entleert blockierte Queues automatisch pro Port.
Ergebnis: Jobs überstehen Bursts; Deadlocks lösen sich selbst, kein Power-Cycle um 3 Uhr nachts.
Multi-Rail / Scale-out
Ein Flow benötigt jeden parallelen Pfad gleichzeitig.
Hash-fixiertes Single-Path-ECMP lässt Multi-Rail-Bandbreite ungenutzt.
UEC 1.0: Packet Spray + Multi-Path-RDMA + Out-of-Order-Delivery.
→ Der heute beschaffte Switch bleibt im Einsatz, wenn UEC-NICs verfügbar werden.
Ergebnis: Tail-Latency-Ausreißer verringern sich mit dem Rollout von UEC-NICs: die offene Antwort auf InfiniBand.
~55 % → 90 %+

Referenz-Benchmark. DLB hebt die Auslastung der Fabric von ~55 % bei statischem ECMP auf über 90 % auf derselben Hardware: ohne zusätzliche Uplinks. Lokal an jedem Hop; systemweit über den gesamten AllReduce. (Von Broadcom veröffentlichter Flowlet-Rebalancing-Wert, auf TH4/TH5 reproduzierbar.)

DLB Deep-Dive →
So sieht es in einer Rack-Reihe aus

800G Spine-Leaf, verlustfrei von Rack zu Rack.

Ein 3-stufiges Clos: eBGP-Unnumbered-Underlay, ECMP auf jeder Ebene, PFC/ECN je Prioritätsgruppe, isolierter Out-of-Band-Bus für ZTP und Telemetrie. Mit dem Mauszeiger über einen Knoten fahren, um Switch, Port-Anzahl und ASIC anzuzeigen.

800G-AI-Fabric-Topologie mit Full-Mesh-eBGP und isoliertem OOB-Management Horizontale 800G-AI-Fabric. Drei GPU-Racks links speisen zwei Leaf-VTEPs unter OcNOS-DC, die über ein Full-Mesh-eBGP-ECMP-Underlay mit DLB an zwei 51,2-Tbps-Spines angebunden sind. Ein isolierter Out-of-Band-Management-Bus über der gesamten Topologie transportiert ZTP und Telemetrie. Leaf-angebundener NVMe-oF/NFS-GPU-Storage ist rechts angeordnet. ISOLIERTER OOB-MANAGEMENT-BUS OOB Mgmt Isoliertes Netz ZTP · Telemetrie GPU-Rack 1 8× GPU-Nodes RoCEv2 / RDMA GPU-Rack 2 8× GPU-Nodes RoCEv2 / RDMA GPU-Rack 3 8× GPU-Nodes RoCEv2 / RDMA Leaf-01 OcNOS-DC 64 × 400G Tomahawk 4 PFC / DCBX / ZTP LOSSLESS RoCEv2 routed Clos · no inter-leaf link Leaf-02 OcNOS-DC 64 × 400G Tomahawk 4 PFC / DCBX / ZTP LOSSLESS RoCEv2 eBGP ECMP Full Mesh Spine-01 OcNOS-DC 51,2 Tbps · DLB eBGP · ECMP · DLB Spine-02 OcNOS-DC 51,2 Tbps · DLB eBGP · ECMP · DLB GPU-Storage NVMe-oF / NFS RDMA-optimiert OcNOS-DC · AI FABRIC · HORIZONTAL CLOS · PFC · ECN · DLB · 800G
OcNOS-DC Leaf/Spine
OcNOS-DC Spine (DLB)
GPU-Server / Storage

Fahren Sie über die Knoten, um Details zu Funktionen und Plattformen zu sehen · Vollständige HCL: 40+ validierte Plattformen unter ipinfusion.com/hcl

600+OcNOS-Netze im Produktivbetrieb
26 JahreZebOS Routing-Stack im Produktivbetrieb
24×7Carrier-Grade-SLA weltweit
Innerhalb der Fabric

Vier Schichten der Verlustfreiheit: am ersten Tag korrekt.

Die meisten Ausfälle in einer AI Fabric lassen sich auf eine fehlkonfigurierte PFC-Prioritätsgruppe oder eine für Cloud, nicht für RDMA, abgestimmte ECN-Schwelle zurückführen. OcNOS-DC liefert RoCEv2-Buffer-Profile, qualifiziert je Broadcom-ASIC, damit der erste AllReduce verlustfrei läuft, ohne dass ein Tuning-Sprint nötig wird.

PFC + ECN. verlustfreie Steuerung pro Prioritätsgruppe

PFC pausiert Datenverkehr je Priorität, bevor Puffer überlaufen; ECN markiert Pakete frühzeitig, um den Sender zu drosseln. Keine Drops, kein portweiter Stillstand. PFC over L3 für geroutete Multi-Row-Fabrics.

DLB: adaptives Routing auf Flowlet-Ebene

Statischer Hash-ECMP kollidiert, sobald 8 NICs auf denselben Spine hashen. DLB beobachtet die Queue-Tiefe in Echtzeit und bindet Flowlets im Sub-Millisekundenbereich auf weniger belastete Pfade um: der AllReduce wird nicht länger vom langsamsten Link ausgebremst.

DCBX: Server-Konfiguration automatisch über LLDP verteilt

Der Leaf überträgt die korrekte PFC- und ETS-Konfiguration automatisch an den GPU-Server, ohne stillen Verlust der Lossless-Eigenschaft, wenn ein Node neu provisioniert wird, dem häufigsten Produktions-Fehlermodus.

gNMI-On-Change-Telemetrie: Sichtbarkeit im Sub-Sekundenbereich

PFC-Pausen, ECN-Markierung, DCQCN-Schwellen und Pufferstände als gNMI-On-Change-Sensorpfade, direkt nach Prometheus / Grafana / OpenTelemetry. Congestion wird erkannt, bevor sie einen Job ausbremst.

ai-leaf01. gNMI-Telemetrie verlustfreier Fabric STREAMING
$gnmic subscribe --path /qos/pfc/ \
--mode ON_CHANGE --encoding proto
RoCEv2 Priority Group 3. Echtzeit
et-0/0/1 PG3 PFC-Rx: 0 Tx: 0 Drop: 0
et-0/0/2 PG3 PFC-Rx: 0 Tx: 0 Drop: 0
et-0/0/3 PG3 PFC-Rx: 0 Tx: 0 Drop: 0
$gnmic subscribe --path /interfaces/counters/
et-0/0/1 in: 780 Gbps out: 776 Gbps
et-0/0/2 in: 795 Gbps out: 791 Gbps
→ Telegraf → Prometheus → Grafana
✓ verlustfrei. 0 Drops. Fabric einwandfrei
Qualifizierte AI-Fabric-Plattformen
AIS800-64D
Edgecore – Spine
800GTH5
S9321-64E
UfiSpace – Spine
800GTH5
AS9736-64D
Edgecore – Leaf
400G / 25,6T
S9321-64EO
UfiSpace – Spine (OSFP)
800GTH5

40+ qualifizierte Plattformen Vollständige HCL →

Ultra Ethernet · UEC 1.0 konform

Das Fabric-Profil ist bereit bevor die NICs es sind. Das ist der Punkt.

RoCEv2 ist 2026 der Produktivtransport; UEC ist der nächste Schritt. Das UEC-1.0-Fabric-Profil ergänzt Packet Spray, Multi-Path-RDMA und Out-of-Order-kompatibles Forwarding, und schließt damit das Single-Hash-Limit, das frühere RoCE-Generationen bei Multi-Rail-Kollektiven hinter InfiniBand zurückhielt. OcNOS-DC orientiert sich an UEC 1.0 Fabric Profil heute, während UEC NICs ausrollen. Es geht nicht darum, beim Standard voranzugehen: alle richten sich an ihm aus. Entscheidend ist, dass der in diesem Quartal beschaffte Switch nicht ersetzt werden muss, wenn die UEC-NIC eintrifft.

Packet Spray

Ein einzelner Flow nutzt alle parallelen Pfade gleichzeitig, statt an einen einzelnen ECMP-Hash gebunden zu sein. Multi-Rail-Bandbreite bleibt nicht länger ungenutzt.

Multi-Path-RDMA

Reorder-Puffer verarbeiten Out-of-Order-Zustellung in Hardware. Moderne Congestion Control ersetzt NACK-basierte Loss Recovery bei der Tail-Latenz.

Gleiche Hardware, Forward Path

Die heute für OcNOS-DC qualifizierten TH4- und TH5-Plattformen reichen bis in UEC hinein. Kein Fork. Keine zweite SKU-Linie. Eine Fabric, zwei Transportgenerationen.

Ultra-Ethernet-Deep-Dive lesen →
Wer 2026 eine Fabric auswählt

Wo OcNOS-DC einsetzt, ehrlich, namentlich.

Der Wettbewerb hat sich auf einer gemeinsamen Basis angenähert: verlustfreies RoCEv2, DCQCN, Adaptive Routing, UEC-Ausrichtung. Diese Funktionen liefern alle. Der eigentliche Unterschied ist Lösungs-Shape: vertikales Lock-in versus offenes NOS, geschlossene versus offene Hardware, Closed-Loop-IB versus standardisiertes Ethernet. Den Trade-off wählen, mit dem fünf Jahre zu leben ist.

Lösungs-Shape Beispiele Trade-off
Geschlossener vertikaler AI-Stack NVIDIA Spectrum-X + Quantum + ConnectX Hervorragende integrierte Performance. NIC, Switch und Fabric-Software an einen einzelnen Anbieter gebunden, und an dessen GPU-Roadmap.
Geschlossenes Merchant-Silicon-NOS Arista EOS · Cisco NX-OS · Juniper Junos Darunter dasselbe Broadcom-Silizium. Aufpreis je Port-Lizenz. Telemetrie und Tuning auf die Pipeline des jeweiligen Anbieters beschränkt.
Zellbasierte proprietäre Chassis-Fabric DriveNets Network Cloud Andere Architektur: Scheduled Cell Fabric, kein Ethernet-NOS. Stark im Hyperscale-Bereich; nicht auf Standard-Switches übertragbar.
Closed-Loop-InfiniBand NVIDIA Quantum InfiniBand Aktuell führend bei engen Kollektiven. Separate Verkabelung, separater Betrieb, Single-Vendor-Ökosystem. UEC schließt den Abstand auf Ethernet-Seite.
Open NOS, ohne AI-Hardening Community SONiC Open Hardware, kostenfreie Software, ohne SLA. Für xCCL-optimierte Standardwerte, Deadlock-Watchdog und Tuning-Reife ist allein der Betreiber verantwortlich.
Open NOS, AI-hardened, UEC-konform OcNOS-DC auf Edgecore / UfiSpace Identisches Broadcom-Silizium. xCCL-optimiertes DCQCN ab Werk, DLB im Sub-Millisekunden-Bereich, GLB auf der Roadmap 7.1, PFC-Deadlock-Watchdog. UEC-1.0-Fabric-Profil. 24/7-Carrier-Grade-SLA. Kein Vendor Lock-in bei NIC, GPU oder Hardware.

Jede Zeile beschreibt ein tatsächlich verfügbares Produkt, einschließlich OcNOS-DC. Die Frage ist selten ein fehlendes Feature; es ist der Trade-off, mit dem zu leben ist.

Moment, was genau ist eigentlich eine „AI Fabric“?

Was es tatsächlich ist, und wo es endet.

Ein AI-Cluster besteht aus drei Schichten. Die Fabric bewegt Bytes zwischen Switches; der NIC terminiert RDMA; der Scheduler entscheidet, was wo läuft. „AI-aware Fabric“ bedeutet in der Regel, dass ein einzelner Anbieter alle drei Ebenen unter einer SKU bündelt. OcNOS-DC verantwortet die Fabric, legt jeden Schwellenwert offen und hält sich aus den darüberliegenden Schichten heraus. Die Grenze ist hier klar benannt.

Layer 1 · Fabric

Verantwortungsbereich von OcNOS-DC.

  • Verlustfreier RoCEv2-Transport: PFC + ECN + ETS + DCBX
  • DCQCN mit xCCL-validierten Standardschwellwerten, jeder Parameter YANG-modelliert
  • DLB-Flowlet-Rebinding im Sub-Millisekundenbereich anhand der ASIC-Queue-Tiefe
  • GLB-Pfadbewertung über die gesamte Fabric (OcNOS 7.1)
  • PFC-Deadlock-Watchdog: pro Port, pro Priorität
  • Ausrichtung am UEC-1.0-Fabric-Profil: Packet-Spray-fähiges Forwarding
  • gNMI-On-Change-Telemetrie, OpenConfig YANG, Sub-Sekunden-Takt
Heute lieferbar auf Edgecore / UfiSpace TH4 + TH5. GLB im OcNOS-7.1-Release.
Layer 2 · NIC + Transport

Aufgabe Ihres NIC-Anbieters.

  • Implementierung und Tuning kollektiver xCCL-Operationen
  • RDMA-Verbs, Queue Pairs, Retransmit-Logik
  • UEC-Packet-Spray-Endpunkt + Reorder-Buffer (UEC-NICs)
  • GPU-Direct Memory Access, NVLink-Koordination
  • Rate Limiting pro Flow und Congestion-Response am End-Host
NVIDIA ConnectX, BlueField, AMD Pensando, Intel Mt. Evans, Cornelis, künftiges UEC-Silizium. OcNOS interoperiert mit all diesen, und ersetzt die Wahl nie.
Layer 3 · Cluster Scheduler

Aufgabe Ihrer Orchestrierungsplattform.

  • Trainingsjob-Platzierung, Gang Scheduling, Gradient-Sync-Fenster
  • Epoch- / Trainingsphasen-Awareness
  • Mandantenisolation, Queue-Priorität, Ressourcenquoten
  • Zuordnung der xCCL-Ringtopologie, Rail-Group-Affinität
  • Erkennung von Cross-Job-Interferenz
Slurm, Kubernetes, Run:ai, NVIDIA Base Command, hauseigene Scheduler. OcNOS-DC streamt gNMI-Telemetrie in diese hinein: und versucht nicht, sie zu ersetzen.
Warum die Grenze hier verläuft: Ein Fabric, das Layer 2 und Layer 3 vollständig besitzt, lässt sich nicht mehr austauschen: NIC an den Switch gebunden, Scheduler an die NIC, GPU-Roadmap an den Anbieter. InfiniBand hat alle drei Schichten fünfzehn Jahre lang besessen, und die Netzbetreiber haben dafür bezahlt. OcNOS-DC liefert jeden Fabric-Mechanismus, den eine Workload im Jahr 2026 benötigt, validiert ihn gegen xCCL-Verkehr und endet am Wire. Deshalb ist „AI-aware Fabric“ die falsche Frage: die richtige lautet, ob das Fabric seine Aufgabe so gut erfüllt, dass NIC und Scheduler nicht dagegen ankämpfen müssen.
Weiter im Detail

Jeder Mechanismus auf dieser Seite hat einen eigenen Deep-Dive.

Die obige Seite dient der Auswahl einer Fabric. Die folgenden Inhalte dienen dem Tuning: Packet Captures, ASIC-Verhalten, YANG-Pfade und welches Feature in welchem Release-Train ausgeliefert wird.

AI Fabric · Lossless

RoCEv2 + PFC + ECN + DCQCN

Die verlustfreie RDMA-Transportschicht für GPU-Kollektivoperationen. Pufferprofile voreingestellt pro Broadcom-ASIC, DCQCN-Standardwerte der xCCL-Klasse, Jitter im Sub-µs-Bereich unter Last.

Deep-Dive lesen →
AI Fabric · Lokal

Adaptive Dynamic Load Balancing (DLB)

Sub-Millisekunden-Flowlet-Rebinding auf Basis von Live-Telemetrie zur ASIC-Queue-Tiefe. Schließt die ECMP-Hash-Kollisionslücke bei AllReduce-Elephant-Flows.

Deep-Dive lesen →
AI Fabric · Fabric-weit OcNOS 7.1

Global Load Balancing (GLB)

Ende-zu-Ende-Pfadbewertung über Leaf · Spine · Super-Spine für Cluster mit bis zu 16k GPUs. Die Multi-Hop-Adaptive-Schicht, die DLB allein nicht erfasst.

Deep-Dive lesen →
AI Fabric · Frontier UEC 1.0

Ultra Ethernet (UEC)

Packet Spray, Multi-Path-RDMA, Out-of-Order-Zustellung, moderne Congestion Control. Die standardbasierte offene Antwort auf InfiniBand.

Deep-Dive lesen →
AI Fabric · Referenzdesigns

Topologien: Single-Pod bis 16k GPU

Rail-only- und Rail-optimized-Designs bilden die Fabric-Form direkt auf das xCCL-Multi-NIC-Muster mit 8 Rails ab. Dreistufiges Clos für Multi-Pod-Scale-out bis zur Obergrenze von 16.000 GPUs. Port-Zahlen auf TH4 / TH5.

Deep-Dive lesen →
AI Fabric · Congestion Control

DCQCN: RDMA-Congestion-Control

WRED-ECN-Marking, CNP-Feedback, quantisierte Ratenregelung. Standardwerte der xCCL-Klasse ab Werk; jeder Schwellenwert ist für das Tuning in YANG modelliert.

Deep-Dive lesen →
AI Fabric · Survival

Watchdog: PFC-Deadlock-Detection

Watchdog je Port und je Priorität erkennt Zyklen pausierter Queues und leert die betroffene Queue automatisch, bevor Trainingsjobs hängen.

Deep-Dive lesen →
AI Fabric · Entscheidungsleitfaden

InfiniBand vs. Ethernet für AI

Workload-spezifischer Entscheidungsleitfaden. Wo modernes Ethernet (RoCEv2 + DLB + UEC) den Abstand schließt, wo IB weiterhin vorn liegt und wie zu wählen ist.

Deep-Dive lesen →
Observability

gNMI-Streaming-Telemetrie

gNMI Subscribe über gRPC, OpenConfig YANG, Dial-Out-Collectors. Integrationen mit Telegraf, Prometheus und Grafana.

Deep-Dive lesen →
Was tatsächlich gebaut wird

Drei Cluster-Shapes. Drei Fabric-Geschichten.

Gegliedert nach dem, was der Job spürt — nicht nach Switch-Features. Das nächstliegende Profil wählen; die Vertiefungen enthalten die Konfigurationen.

SHAPE 01 · LLM PRE-TRAINING

Der mehrwöchige LLM-Pre-Training-Lauf.

AllReduce dominiert das Netzwerk. Jede GPU muss eine hohe In-Collective-Auslastung halten und Mikrobursts überstehen, ohne einen neuntägigen Lauf neu zu starten.

Mechanismen: DCQCN + DLB + PFC-Watchdog. Rail-Optimized für Single-Pod; 3-stufiges Clos mit GLB für Multi-Pod-Scale-out.
Ergebnis: AllReduce mit Line-Rate, null Collective-Restarts, JCT im Zeitplan.

SHAPE 02 · LIVE INFERENCE

Die High-Throughput-Inferenz-Flotte hinter einer öffentlichen API.

Echtzeit-Inferenz, bei der die p99-Tail-Latenz das SLO bestimmt. Inferenz darf niemals hinter Batch-Retraining warten, und der Betrieb benötigt Sichtbarkeit je Flow in dem Moment, in dem die Latenz abdriftet.

Mechanismen: ETS Strict-Priority + gNMI-On-Change-Telemetrie nach Prometheus / OpenTelemetry.
Ergebnis: p99 innerhalb des SLO gehalten; Regressionen werden in Millisekunden erkannt, nicht erst über den Support.

SHAPE 03 · GPU-AS-A-SERVICE

Die Neocloud, die H100 / H200 / Blackwell an Mandanten vermietet.

Eine Multi-Mandanten-GPU-Cloud. Jeder Mandant benötigt isolierte verlustfreie RoCEv2-Pfade, ohne ein separates Fabric-Segment je Kunde und ohne ein zweites NOS-Image.

Mechanismen: EVPN-VXLAN-Isolation + verlustfreies RoCEv2 auf einer OcNOS-DC-Instanz.
Ergebnis: Isolation pro Mandant, ein Betriebsmodell, ein SLA, ein Image für Upgrades.

Mit einem Netzwerkarchitekten sprechen

Bringen Sie Ihre Topologie mit. Wir zeigen Ihnen den Weg.

Jeder Architektur-Review von IPI wird von einem Netzwerk-Engineer geführt, der OcNOS im Produktivbetrieb betreibt: keine Folien, keine Vertriebsinszenierung. GPU-Anzahl, NIC-Auswahl und Ziel-JCT mitbringen; die Abbildung auf Topologie, SKUs und heute lieferbare Konfigurationen erfolgt im Gespräch.

Fragen, die ein AI-Cluster-Architekt tatsächlich stellt

Ehrlich gesagt FAQ.

Ist OcNOS-DC wirklich "AI-native", oder einfach nur RoCEv2 mit Zusätzen?
Kein NOS auf Merchant Silicon ist im Wortsinn AI-native: keines verarbeitet xCCL-Kollektive (NCCL / RCCL / oneCCL) oder plant Jobs auf dem Switch; das liegt in der NIC und im Scheduler. OcNOS-DC implementiert jeden Fabric-Mechanismus, den ein KI-Workload 2026 benötigt: verlustfreies RoCEv2, DCQCN mit xCCL-qualifizierten Voreinstellungen, Sub-ms-DLB, GLB (OcNOS 7.1), PFC-Deadlock-Watchdog, UEC-1.0-Ausrichtung: und hält sich aus den darüberliegenden Schichten heraus. „AI-aware Fabric“ bedeutet in der Regel lediglich, dass ein einzelner Anbieter NIC + Switch + Scheduler als eine geschlossene SKU verkauft.
Wo endet OcNOS-DC und wo übernehmen NIC und Cluster-Scheduler?
OcNOS-DC verantwortet Layer 1: verlustfreien RDMA-Transport, Congestion Control, Adaptive Routing, Deadlock-Recovery, Telemetrie. Die NIC verantwortet Layer 2 (xCCL, RDMA-Verbs, Packet Spray, GPU-Direct Memory); der Scheduler verantwortet Layer 3 (Job Placement, Gradient-Sync-Fenster, Mandantentrennung). OcNOS-DC streamt gNMI-Telemetrie in Layer 3, beansprucht aber nie die Rolle des Schedulers: diese Trennung hält NIC, GPU und Orchestrierung austauschbar.
Wie schneidet OcNOS AI Fabric im Vergleich zu NVIDIA Spectrum-X, SONiC, Arista, Cisco oder DriveNets ab?
Spectrum-X ist ein geschlossener Stack aus NVIDIA-NIC, -Switch und -Software: hervorragende Performance, Single-Vendor-Lock-in. Arista, Cisco und Juniper bieten vergleichbare RoCEv2-Funktionen auf proprietärer Hardware mit proprietärer Lizenzierung. Community-SONiC ist offen, liefert jedoch keine KI-gehärteten Voreinstellungen, keinen Watchdog und kein SLA. DriveNets DDC ist eine proprietäre Cell-Fabric, kein Ethernet-NOS. OcNOS-DC: offenes NOS auf demselben Broadcom-Silizium, UEC-konform, xCCL-abgestimmtes DCQCN, 24/7-SLA: dieselbe technische Basis, kein Lock-in.
Was bedeutet Ultra Ethernet (UEC) 1.0 für OcNOS AI Fabric?
UEC 1.0 bringt Packet-Spray, Multi-Path-RDMA und Out-of-Order-Delivery ins Ethernet: die offene Antwort auf InfiniBand. Produktiv-Fabrics betreiben heute RoCEv2 + DCQCN + DLB, alles vollständig unterstützt; UEC parallelisiert jeden Flow über mehrere Pfade, statt ihn an einen einzelnen ECMP-Hash zu binden. OcNOS-DC verfolgt das UEC 1.0-Fabric-Profil, sodass der Switch, den Sie heute kaufen, ohne NOS- oder Hardware-Wechsel auf UEC-NICs übergeht. Siehe den Ultra Ethernet Deep-Dive.
Was ist RoCEv2 und warum erfordert es ein verlustfreies Ethernet-Fabric?
RoCEv2 ermöglicht direkte GPU-zu-GPU-Speicherübertragungen ohne CPU-Overhead für Kollektive wie AllReduce und AllGather. RDMA kennt keine Neuübertragung: ein verworfenes Paket startet die Operation auf jeder GPU neu: daher ist eine verlustfreie Fabric (PFC + ECN) im Produktivbetrieb zwingend erforderlich. OcNOS-DC liefert RoCEv2-Buffer-Profile und DCQCN-Voreinstellungen, die auf xCCL-Kollektivmuster abgestimmt sind.
Wie stellt OcNOS-DC verlustfreien Betrieb sicher, und was schützt vor PFC-Deadlock?
Drei Mechanismen: PFC pausiert Datenverkehr je Priorität, bevor Puffer überlaufen; ECN markiert Pakete frühzeitig, um Sender zu drosseln; ETS hält RDMA-Flows vor niedriger priorisiertem Verkehr. Darüber liegt ein Deadlock-Watchdog je Port und je Priorität, der Zyklen pausierter Queues erkennt und die Queue automatisch leert, bevor Jobs hängen: bislang der Fehlerfall, der mitten im Lauf einen Power-Cycle des Switches erzwang. PFC over L3 wird über geroutete Grenzen hinweg unterstützt.
Was ist DLB, und was ändert sich mit GLB in OcNOS 7.1?
Standard-ECMP bindet einen Flow für seine gesamte Lebensdauer an einen Uplink und führt während AllReduce zu Elephant-Flow-Kollisionen. DLB nutzt Live-Telemetrie der ASIC-Queue-Tiefe, um Flowlets im Sub-Millisekundenbereich auf weniger belastete Pfade umzubinden, und schließt damit die Lücke am lokalen Hop. GLB (OcNOS 7.1) erweitert dies Ende-zu-Ende: Spines spielen Pfadqualitäts-Telemetrie an die Ingress-Leaves zurück, sodass das Routing die volle Multi-Hop-Bewertung berücksichtigt und sich sauber bis auf Cluster mit 16k GPUs skalieren lässt.
Welche Skalierung unterstützt OcNOS AI Fabric, und welche Referenzdesigns sind qualifiziert?
OcNOS-DC unterstützt 400G- und 800G-Leaf-Spine-Fabrics. Tomahawk 5-Spines (Edgecore AIS800-64D, UfiSpace S9321-64E) liefern 51,2 Tbps / 64 × 800G; Tomahawk 4-Leaves laufen mit 400G / 25,6 Tbps und Deep-HBM-Buffer; Trident 4 deckt kleinere 100G/400G-Fabrics ab. Die Referenzdesigns umfassen Rail-Only-, Rail-Optimized- und 3-stufige Clos-Topologien bis zu 16k GPU: siehe den AI Fabric Topologies Deep-Dive.
Unterstützt OcNOS-DC Automatisierung und Telemetrie für den Betrieb von AI Fabrics?
Ja. DCBX automatisiert die RoCEv2-Konfiguration zwischen Server und Switch, ZTP (IPv4/IPv6) übernimmt das Zero-Touch-Onboarding, und gNMI streamt On-Change-Telemetrie über OpenConfig YANG. PFC-Pausen, ECN-Markierung, DCQCN-Schwellen und Pufferstände stehen als gNMI-Sensorpfade bereit und sind über Prometheus, InfluxDB, Telegraf, Grafana oder jede OpenTelemetry-Pipeline konsumierbar. Ansible-Playbooks und ein Terraform-Provider decken Day-0 bis Day-2 ab.