RoCEv2 · DCQCN · DLB · 800G

OcNOS AI Fabric: offenes, verlustfreies 800G-Ethernet für GPU-Cluster

OcNOS AI Fabric bringt Carrier-Grade-Networking in den GPU-Cluster: ein vollständiges verlustfreies Ethernet-System. IP Infusion liefert es komplett als OcNOS Systems: validierte offene 800G-Switches von Edgecore oder UfiSpace mit OcNOS-DC, unter einem Supportvertrag, wobei Ihre Wahl bei NIC, GPU und Switch offen bleibt. Es betreibt heute produktiv verlustfreies RoCEv2-RDMA mit PFC, ECN-basierter Überlastkontrolle (DCQCN) und DLB im Sub-Millisekunden-Bereich. IP Infusion ist Mitglied des Ultra Ethernet Consortium.

600+OcNOS-Netze im Produktivbetrieb
60+Länder im Einsatz
Seit 1999Routing-Stack im Produktivbetrieb
Mehrere TausendGPU-Referenzdesigns
Architektur-Briefs

Architektur-Briefs herunterladen

Vier kurze Downloads, die tiefer gehen als diese Seite: die Architektur der verlustfreien AI-Fabric, das vollständige OcNOS-DC-Datenblatt, die EVPN-VXLAN-Rechenzentrumsreferenz und DCI der nächsten Generation mit IPoDWDM.

Solution Brief

Ethernet-basierte verlustfreie 800G-AI-Fabric mit OcNOS

Non-Blocking-RoCEv2-Fabric auf Tomahawk-4/5-Spines: SKU-Stufen, qualifizierte Plattformen und Deployment-Architektur.

Brief anfordern
Solution Brief

EVPN-VXLAN-Data-Center-Fabric

Offene Leaf-Spine-Data-Center-Fabric: EVPN-Type-2- und Type-5-Routen, verteiltes Anycast-Gateway, mandantenfähige VNIs.

Brief anfordern
Solution Brief

DCI der nächsten Generation mit IPoDWDM

Sparen Sie die Transponder-Ebene ein: Betreiben Sie kohärente 400G/800G-ZR- und -ZR+-Optiken direkt vom Router aus für den Data-Center-Interconnect.

Brief anfordern
Datenblatt

OcNOS-DC-Datenblatt

Vollständige OcNOS-DC-Spezifikation: Funktionsumfang für EVPN-VXLAN und Ethernet for AI, Software-SKUs, unterstützte Hardware-Plattformen und der Solution Ordering Guide.

Datenblatt abrufen
Worum es geht

Was die Job-Abschlusszeit beeinflusst

Was im großen Maßstab zählt, ist, wie schnell Jobs abgeschlossen werden und wie ausgelastet die GPUs bleiben, nicht der Switch-Durchsatz. Jedes Mal, wenn der Cluster zur Synchronisierung pausiert, verschwenden untätige GPUs Kapazität, sodass die Fabric nichts verwerfen darf und in dem Moment auf Congestion reagieren muss, in dem sie beginnt.

OcNOS-DC legt jede Einstellung offen, sodass Ihr Team die Fabric anhand Ihres realen GPU-Collective-Traffics (xCCL: NCCL, RCCL, oneCCL) abstimmt, statt das feste Profil eines Anbieters zu übernehmen. Jedes Muster unten zeigt eine Art, wie ein Cluster ins Stocken gerät, und wie OcNOS-DC ihn in Bewegung hält.

Jede GPU kommuniziert gleichzeitig mit jeder anderen GPU
Standard-Load-Balancing bindet diese großen Flows an einen einzigen Uplink, sodass manche Links überlastet sind, während andere ungenutzt bleiben und die Synchronisation auf den langsamsten wartet.
→ DLB verlagert Flows in unter einer Millisekunde auf weniger ausgelastete Pfade.
→ GLB steht auf der OcNOS-Roadmap, um über die gesamte Fabric zu balancieren, nicht nur über den lokalen Hop.
Ergebnis: keine Traffic-Hotspots; der Synchronisationsschritt läuft nahezu mit voller Geschwindigkeit.
Trainings-Synchronisation (AllReduce)
Viele Sender treffen innerhalb von Mikrosekunden auf einen Port
Ein verworfenes Paket startet das gesamte Collective neu, und zu starkes Pausieren blockiert die Verbindung, daher muss die Fabric Überlast frühzeitig abwenden.
→ DCQCN bremst Sender frühzeitig ab, bevor etwas überläuft.
→ PFC-Watchdog löst einen blockierten Port eigenständig.
Ergebnis: Jobs überstehen Bursts, und ein blockierter Port erholt sich ohne manuellen Reset.
Traffic-Bursts (Incast)
Ein Flow benötigt alle parallelen Pfade gleichzeitig
Heute nimmt ein Flow einen einzigen gehashten Pfad, während die anderen Rails ungenutzt bleiben.
→ DLB verlagert Flowlets auf der RoCEv2-Fabric, die Sie heute betreiben, weg von ausgelasteten Pfaden.
→ Ultra Ethernet (UEC) ist ein Multipath-Transport, der einen Flow von UEC-fähigen NICs aus über viele Pfade verteilt.
Ergebnis: heute eine bessere Nutzung jedes Rails und ein standardisierter Multipath-Transport, sobald UEC-NICs eingeführt werden.
Scale-out (Multi-Rail)
Ziel 90 %+

Wohin die Kapazität geht. Statisches ECMP bindet jeden großen Flow an einen Pfad, sodass Elephant Flows auf wenigen Uplinks kollidieren, während andere ungenutzt bleiben. Dynamic Load Balancing bindet Flows bei Überlast in Echtzeit neu, um jeden Uplink auszulasten, sodass eine gut betriebene AI-Fabric auf denselben Switches eine Auslastung im Bereich von 90 % anstrebt, ohne zusätzliche Uplinks. OcNOS-DC liefert DLB auf Tomahawk 4 und 5.

DLB im Detail →
Referenztopologie

800G-Spine-Leaf, verlustfrei von Ende zu Ende

Dies ist das Leaf-Spine-Design (Clos), das Ihr Team bereits kennt, gebaut, um GPU-Verkehr ohne Verluste zu betreiben: Ein geroutetes eBGP-Underlay verteilt den Verkehr gleichmäßig über jeden Pfad, verlustfreie Priority-Queues schützen die RoCEv2-Flows, und ein separates Management-Netz nimmt die Switches in Betrieb und streamt eigenständig Telemetrie. Leaf-angebundener NVMe-oF- und NFS-Speicher für Checkpoints und Datensätze liegt angrenzend an die GPU-Racks; siehe die DC-Fabric für Details zur Storage-Fabric. Fahren Sie mit der Maus über einen Knoten, um Plattform, Portanzahl und Chip zu sehen.

AI-Fabric-Topologie: 800G-Spine-Leaf mit parallelen Leaves, Full-Mesh-eBGP, einem isolierten Management-Bus und Leaf-angebundenem Storage
AI-Fabric: 800G-Spine-Leaf, Full-Mesh-eBGP, ein isolierter Management-Bus und Leaf-angebundener Storage.
Rail-optimiertes Referenzdesign

Jeder GPU-NIC auf einem eigenen Rail, skalierbar über Pods hinweg

In einer rail-optimierten Fabric bindet jeder GPU-Server je einen NIC an jeden von acht dedizierten Rail-Leaves an, sodass der dominierende AllReduce-Traffic innerhalb eines Rails auf einem Leaf bleibt und nur Rail-übergreifender Traffic den Spine erreicht. Sie skaliert Pod für Pod auf denselben 800G-Tomahawk-5-Switches. Siehe den Deep-Dive zum Rail-optimierten Design und die vollständigen Referenztopologien.

Rail-optimierte AI-Fabric-Topologie: vier 800G-Tomahawk-5-Spines über acht Rail-Leaves, wobei vier GPU-Server jeweils einen ihrer acht NICs einem anderen Rail-Leaf zuordnen, sodass AllReduce innerhalb eines Rails auf einem Leaf bleibt.
Rail-optimierter Single Pod: Die 8 NICs jedes GPU-Servers sind je einer pro Rail auf 8 dedizierte Leaves abgebildet, sodass AllReduce innerhalb eines Rails auf dem Leaf bleibt und nur Rail-übergreifender Traffic den Spine erreicht.
Die Hardware

Validierte offene Switches

OcNOS-DC läuft auf Broadcom-Tomahawk- und -Trident-Switches von Edgecore und UfiSpace, sodass jede Plattform validiert, bestellbar und aus zweiter Quelle beziehbar ist.

800G-Spine-Switch Edgecore AIS800-64D

Edgecore AIS800-64D

64 x 800G · 51.2 Tbps

QSFP-DD800 · Breakout auf 2x400G / 4x200G / 8x100G

Spine · Tomahawk 5
Datenblatt →
800G-Spine-Switch UfiSpace S9321-64E

UfiSpace S9321-64E

64 x 800G · 51.2 Tbps

QSFP-DD800 · Breakout auf 2x400G / 4x200G / 8x100G

Spine · Tomahawk 5
Datenblatt →
400G-Leaf-Switch Edgecore AS9736-64D

Edgecore AS9736-64D

64 x 400G · 25.6 Tbps

QSFP56-DD 400G · Breakout auf 4x100G / 4x25G · DAC / AOC

Leaf · Tomahawk 4
Datenblatt →

Alle 40+ validierten Plattformen in der HCL ansehen →

Wie sich die Broadcom-Tomahawk- und -Trident-Familien unterscheiden und alle offenen Switches, auf denen OcNOS läuft →

OcNOS Systems: ein Anbieter für Software, Hardware und Support

Ein Vertrag, ein Ansprechpartner

Als OcNOS Systems erworben, hat die Fabric einen einzigen Vertrag mit IP Infusion, der die OcNOS-DC-Software und die validierte Switch-Hardware gemeinsam abdeckt, sodass es einen TAC und ein SLA gibt statt eines getrennten NOS- und Hardware-Anbieters. Ein 24/7-Support-Portal ist in den Tarifen Premium und Enterprise verfügbar.

Support-Details ansehen

Eine Konsole für die Fabric

IP Maestro ist ein Element-Management-System für OcNOS: Topologie, Störungen, Konfiguration und Software-Images über jeden Switch hinweg via NETCONF, angesiedelt unterhalb Ihres bestehenden OSS. Verwaltet große Multi-Site-Flotten von einer Konsole aus.

IP Maestro erkunden

Streaming-Telemetrie und Zero-Touch

gNMI-Streaming-Telemetrie speist Prometheus und Grafana, DCBX überträgt automatisch die korrekten verlustfreien Einstellungen an jeden Server, und Zero-Touch-Provisioning bringt Switches bereits beim Booten konfiguriert in Betrieb.

Automatisierung entdecken
Offene Alternative zu Spectrum-X

Die offene Multi-Vendor-Alternative zu NVIDIA Spectrum-X

OcNOS-DC betreibt eine verlustfreie RoCEv2-AI-Fabric auf Standard-Ethernet-Switches von mehr als einem Anbieter offener Hardware, mit einem einzigen Supportvertrag beim Erwerb als OcNOS Systems. Es bietet die Fabric-Mechanismen, auf die ein AI-Trainingsjob angewiesen ist, und hält die Auswahl von NIC, GPU und Hardware offen, statt sie an einen einzigen Anbieter zu binden.

Offene AI-Fabric auf OcNOS-DC im Vergleich zu einem geschlossenen Single-Vendor-AI-Stack. Zuletzt verifiziert: Juli 2026.
Was den Ausschlag gibt Offene AI-Fabric (OcNOS-DC auf Edgecore / UfiSpace) Geschlossener NIC-plus-Switch-Stack
Hardware-Beschaffung Offenes Merchant-Silicon von mehr als einem Anbieter (Edgecore, UfiSpace) Switch, NIC und GPU aus einer Hand
Wahl von NIC und GPU Offen; NICs und GPUs unabhängig austauschbar An einen Anbieter für NIC- und GPU-Roadmap gebunden
Verlustfreies RoCEv2 (PFC, ECN, DCQCN) ✓ Details → ✓
Adaptiver Lastausgleich ✓ DLB-Flowlet-Neubindung im Sub-Millisekundenbereich Details → ✓ (proprietär)
PFC-Deadlock-Schutz ✓ Deadlock-Watchdog mit Auto-Drain Details → ✓
Streaming-Telemetrie und Automatisierung ✓ gNMI, OpenConfig, ZTP, DCBX, Ansible ✓ (Hersteller-Pipeline)
Ein einziger Supportvertrag (Switch und Software) ✓ ein TAC, ein SLA mit OcNOS Systems ✓ (ein Anbieter)
GPU-Silicon-Back-End-Integration Standard-Ethernet; kein GPU-Silicon-Co-Design NIC, Switch und GPU von einem Anbieter gemeinsam entwickelt
Fabric-Controller-Ebene Verwaltet über gNMI-Telemetrie und Ihr OSS oder IP Maestro Integrierte Fabric-Controller-Ebene des Anbieters

NVIDIA und Spectrum-X sind Marken der NVIDIA Corporation. IP Infusion ist nicht mit NVIDIA verbunden und wird von NVIDIA nicht unterstützt; der Vergleich gibt Fähigkeiten von OcNOS-DC wieder, die überprüfbar sind in der Feature-Matrix.

Die AI-Fabric-Landschaft 2026

Wo OcNOS-DC steht

OcNOS-DC erfüllt die technische Messlatte, die die meisten AI-Fabric-Optionen 2026 teilen: verlustfreies RoCEv2, Congestion Control und adaptives Routing. Die Entscheidung läuft also hinaus auf die Ausgestaltung des Vertrags: ein offenes Betriebssystem oder ein geschlossener Stack, offene oder geschlossene Hardware, Standard-Ethernet oder geschlossenes InfiniBand. Here is where each one leaves you.

Lösungstyp Was es ist Kompromiss
Open NOS, AI-gehärtet OcNOS-DC auf Edgecore / UfiSpace Dasselbe Broadcom-Silicon, dieselbe technische Basis. DCQCN abgestimmt auf RDMA-Collective-Traffic, DLB im Sub-Millisekundenbereich, GLB auf der OcNOS-Roadmap, PFC-Deadlock-Watchdog. Ein Supportvertrag mit OcNOS Systems. Kein NIC-, GPU- oder Hardware-Lock-in.
Geschlossener vertikaler AI-Stack NIC, Switch und Fabric-Software von einem Anbieter Integrierte NIC-, Switch- und Fabric-Software, an einen Anbieter und an eine GPU-Roadmap gebunden.
NOS auf proprietärer Hardware Anbieter-NOS, nur auf den Switches dieses Anbieters erhältlich Oft dasselbe Merchant-Silicon darunter. Aufpreis durch Lizenzierung pro Port. Telemetrie und Tuning auf die eigene Pipeline des Anbieters beschränkt.
Zellbasierte proprietäre Chassis-Fabric Geplante Zell-Fabric auf proprietärer Chassis-Software Andere Architektur: eine Scheduled Cell Fabric statt eines Ethernet-NOS. Nicht auf Standard-Switches übertragbar.
Closed-Loop-InfiniBand InfiniBand-NICs und -Switches, getrennt von Ethernet Niedrige Latenz für eng gekoppelte Collectives, mit separater Verkabelung, separatem Betrieb und einem Single-Vendor-Ökosystem.
Open NOS, ohne AI-Hardening Community-Open-Source-NOS-Distributionen Offene Hardware, freie Software, kein SLA. RDMA-abgestimmte DCQCN-Standardwerte, Deadlock-Watchdog und Tuning-Reife bleiben vollständig dem Betreiber überlassen.

Jede Option zielt auf eine andere Priorität ab. OcNOS-DC überzeugt mit offener Hardware, einer Komplettlösung und ohne Lock-in.

AI-Fabric-Dimensionierungsleitfaden

Dimensionieren Sie Ihre GPU-Fabric in wenigen Minuten

Geben Sie Ihre GPU-Anzahl und NIC-Geschwindigkeit ein. Die AI Fabric Design Suite bildet daraus eine Leaf-Spine-Topologie, Switch- und Portanzahlen sowie eine Stückliste ab, die Sie direkt für ein Angebot verwenden können. Keine Tabellenkalkulation erforderlich.

AI-Fabric-Dimensionierungsleitfaden öffnen Architektur-Review vereinbaren
Verwandte Lösungen

OcNOS über das gesamte Rechenzentrum erweitern

AI ist ein Segment des Rechenzentrums. Dasselbe OcNOS-Image erstreckt sich auf Compute, Storage und entfernte Standorte: dasselbe NOS, dieselbe CLI, derselbe Support.

DC-Fabric

EVPN-VXLAN-Leaf-Spine-Fabric für Compute und Storage, auf demselben OcNOS-Image und derselben CLI.

DC-Fabric entdecken →

IPoDWDM & DCI

Verbinden Sie AI-Cluster und Rechenzentren standortübergreifend über IP-over-DWDM, ohne externe Transponder.

IPoDWDM entdecken →

Produkt OcNOS-DC

Vollständige Funktionsliste, SKU-Stufen und Lizenzierung für das OcNOS-Data-Center-NOS.

OcNOS-DC ansehen →
Häufige Fragen

Häufig gestellte Fragen

Ist OcNOS-DC wirklich "AI-native", oder einfach nur RoCEv2 mit Zusätzen?
Kein Merchant-Silicon-Ethernet-NOS ist im wörtlichen Sinne AI-nativ: keines verarbeitet xCCL-Collectives (NCCL / RCCL / oneCCL) oder plant Jobs am Switch; das liegt in der NIC und im Scheduler. OcNOS-DC implementiert jeden Fabric-Mechanismus, den ein AI-Workload im Jahr 2026 benötigt: verlustfreies RoCEv2, DCQCN-Buffer-Profile, abgestimmt auf RDMA-Collective-Verkehrsmuster, DLB-Flowlet-Rebinding im Submillisekunden-Bereich und einen PFC-Deadlock-Watchdog, und hält sich aus den darüberliegenden Schichten heraus. „AI-aware fabric“ bedeutet meist nur, dass ein 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?
OcNOS-DC liefert die vollständige AI-Fabric: validierte offene Switches und OcNOS-DC, geliefert als OcNOS Systems unter einem Supportvertrag, aus derselben OcNOS-Familie, die Service-Provider-Netze betreibt. Es läuft auf Broadcom-Silicon mit verlustfreiem RoCEv2 (PFC, ECN, DLB im Sub-Millisekunden-Bereich mit Reactive Path Rebalance), PFC-Deadlock-Recovery und 24/7-Support in den Tarifen Premium und Enterprise, ohne Bindung an NIC, GPU oder Hardware. Die anderen Optionen unterscheiden sich in der Form des Geschäfts. Geschlossene NIC-plus-Switch-Stacks binden die Fabric bei NIC, Switch und GPU-Roadmap an einen Anbieter. NOS-Optionen auf proprietärer Hardware betreiben ähnliche RoCEv2-Funktionen auf gebundener Hardware mit Lizenzierung pro Port. Community-Open-Source-NOS-Distributionen überlassen AI-optimierte Standardeinstellungen, einen Deadlock-Watchdog und ein SLA dem Betreiber. Zellbasierte Chassis-Fabrics nutzen eine geplante Zellarchitektur statt eines Standard-Ethernet-NOS.
Was bedeutet Ultra Ethernet (UEC) 1.0 für OcNOS AI Fabric?
OcNOS-DC betreibt heute produktiv verlustfreies RoCEv2 mit DCQCN und DLB im Sub-Millisekunden-Bereich, und IP Infusion ist Mitglied des Ultra Ethernet Consortium (UEC). UEC 1.0 definiert einen Multipath-Ethernet-Transport, der einen Flow über viele Pfade verteilt, statt ihn an einen einzelnen ECMP-Hash zu binden; dieses Endpunktverhalten läuft auf UEC-fähigen NICs. Wie UEC zu einem konkreten Aufbau passt, klären Sie am besten mit einem Engineer von IP Infusion; siehe auch den Ultra-Ethernet-Deep-Dive.
Was ist RoCEv2 und warum erfordert es eine verlustfreie Ethernet-Fabric?
Ihre Training-Collectives, AllReduce und AllGather, bewegen Daten GPU-zu-GPU über RoCEv2 ohne CPU im Pfad, und RDMA überträgt nie erneut, sodass ein einziges verlorenes Paket die Operation über jede GPU im Job neu startet. Deshalb benötigt produktives RoCEv2 eine wirklich verlustfreie Fabric (PFC plus ECN), und OcNOS-DC liefert die RoCEv2-Buffer-Profile und DCQCN-Voreinstellungen, abgestimmt auf RDMA-Collective-Verkehr, sodass Ihr Team dieses verlustfreie Verhalten nicht von Grund auf aufbauen muss.
Wie hält OcNOS-DC die Fabric verlustfrei, und was schützt vor PFC-Deadlocks?
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 ist GLB auf der OcNOS-Roadmap?
Während AllReduce kollidieren Ihre größten Flows, wenn standardmäßiges ECMP jeden einzelnen für seine gesamte Lebensdauer an einen einzigen Uplink bindet, und die Synchronisation wartet auf die blockierte Verbindung. DLB liest live die ASIC-Queue-Depth-Telemetrie und bindet Flowlets in unter einer Millisekunde auf weniger ausgelastete Pfade um, sodass verlorener Durchsatz heute am lokalen Hop zurückgewonnen wird. GLB steht auf der OcNOS-7.x-Roadmap, um dieselbe Idee fabricweit auszudehnen: Spines veröffentlichen Pfadqualitäts-Telemetrie zurück an die Ingress-Leaves, sodass das Routing den vollständigen Multi-Hop-Pfad über große Cluster mit mehreren Tausend GPUs bewertet.
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 arbeiten mit 400G / 25,6 Tbps und On-Chip-Buffering; Trident 4 deckt kleinere 100G/400G-Fabrics ab. Referenzdesigns umfassen Rail-only-, Rail-optimierte und dreistufige Clos-Topologien für große Cluster mit mehreren tausend GPUs: siehe den Deep-Dive zu AI-Fabric-Topologien.
Unterstützt OcNOS-DC Automatisierung und Telemetrie für den Betrieb von AI-Fabrics?
Ja. DCBX automatisiert die RoCEv2-Konfiguration von Server zu Switch, ZTP (IPv4/IPv6) übernimmt das Zero-Touch-Onboarding, und gNMI streamt On-Change-Telemetrie über OpenConfig YANG. PFC-Pauses, ECN-Marking, DCQCN-Schwellenwerte und Buffer-Tiefen sind gNMI-Sensorpfade, die von Prometheus, InfluxDB, Telegraf, Grafana oder jeder OpenTelemetry-Pipeline nutzbar sind. Ansible-Playbooks decken Day-0 bis Day-2 ab, mit einem Terraform-Provider auf der Roadmap. IP Maestro, ein Element-Management-System für OcNOS, verwaltet Topologie, Fehler, Konfiguration und Software-Images über NETCONF und verwaltet große Multi-Site-Flotten von einer Konsole aus.
Welche Switch-Hardware und 800G-Optiken unterstützt OcNOS AI Fabric?
Die Fabric läuft auf validierten Broadcom-Tomahawk-4- und -5-Switches von Edgecore und UfiSpace. Die 800G-Spines (Edgecore AIS800-64D und UfiSpace S9321-64E, Tomahawk 5, 64 x 800G QSFP-DD800, 51.2 Tbps) unterstützen Breakout auf 400G, 200G und 100G; der 400G-Leaf (Edgecore AS9736-64D, Tomahawk 4, 64 x 400G QSFP56-DD, 25.6 Tbps mit On-Chip-Buffering) unterstützt Breakout auf 100G und 25G. Optiken mehrerer Hersteller haben nachgewiesene Interoperabilität, daher kontaktieren Sie uns für die Transceiver-Liste für Ihren Aufbau. Die Switch-Plattformen sind in der HCL aufgeführt.
Wer bietet Support für die AI-Fabric, und ist die Hardware ebenfalls abgedeckt?
Wird die Fabric als OcNOS Systems erworben, deckt ein einziger Vertrag mit IP Infusion die OcNOS-DC-Software und die validierte Switch-Hardware gemeinsam ab, sodass es einen TAC und ein SLA gibt. Der Support ist gestaffelt: Standard umfasst E-Mail-TAC, Telefonsupport zu Geschäftszeiten und Hardware-RMA-Koordination mit einer P1-Reaktionszeit von 8 Stunden; Premium ergänzt ein 24/7-Kundensupport-Portal und eine P1-Reaktionszeit von 2 Stunden; Enterprise ergänzt eine P1-Reaktionszeit von 30 Minuten sowie einen Customer Success Manager. Das 24/7-Portal ist in Premium und Enterprise verfügbar.
Detailanalysen pro Mechanismus
RoCEv2 + PFC / ECN DCQCN DLB GLB (auf der Roadmap) PFC-Deadlock-Watchdog Ultra Ethernet (UEC) AI-Fabric-Topologien InfiniBand vs. Ethernet gNMI-Telemetrie

AI-Fabric- & DC-Deployments

Produktive AI-Cluster und Data-Center-Fabrics, die OcNOS-DC auf Broadcom Tomahawk 4/5 betreiben.

NTT
APAC

NTT DATA ist eine Partnerschaft mit IP Infusion eingegangen, um Open-Networking-Lösungen auf den Markt zu bringen, mit OcNOS-basierten Cell-Site-Routern, Routed Optical…

Story lesen →
Scott Data
Amerika

Scott Data hat OcNOS mit Open-Networking-Hardware von UfiSpace, Edgecore Networks und Celestica implementiert und damit Legacy-Vendor-Stacks in seinem gesamten…

Story lesen →
Madeo
EMEAI

Madeo Consultant, ein in Frankreich ansässiger Rechenzentrums-Systemintegrator, hat Cisco-Nexus- und -Catalyst-Switches durch IP Infusion OcNOS auf Edgecore… ersetzt

Story lesen →
Prosoluce
EMEAI

Prosoluce, ein französischer ISP und Anbieter von Managed Services, rüstete seinen Core auf ein 100G-EVPN-VXLAN-Backbone mit IP Infusion OcNOS auf…

Story lesen →
Alle Kundenbereitstellungen durchsuchen →
Aus dem Blog

Passend aus dem Blog

Das AI Network Decision Framework: GPU-Fabric für Geschwindigkeit, ROI, strategische Freiheit

Framework auf Käuferseite für Entscheidungen zur GPU-Fabric mit RoCEv2 und offener Hardware

Beitrag lesen →

OcNOS 7.0 für Rechenzentren: AI-Fabric, 800G-Plattformen, EVPN-VXLAN im großen Maßstab

800G-AI-Fabric-Features und Tomahawk-5-Plattformen, die in OcNOS 7.0 ausgeliefert werden

Beitrag lesen →

OcNOS 7.0: Neuerungen für AI, Transport und Cloud

Hebt verlustfreien RoCEv2-Transport mit PFC für GPU-Cluster hervor

Beitrag lesen →

OcNOS 6.6 für Rechenzentren: AI-Fabric-PFC/ETS, EVPN-Policy, 400G

Verlustfreie PFC/ETS-DCB-Features, die OcNOS-AI-Fabric-Deployments zugrunde liegen

Beitrag lesen →
Alle Blog-Beiträge →
AI-Fabric

Die gesamte AI-Fabric mit OcNOS entwerfen

Vom Business Case bis zur Portanzahl-Berechnung: Steigen Sie dort ein, wo Sie beim Aufbau gerade stehen.

Sie sind hier Offene AI-Fabric Die komplette 800G-AI-Fabric: offene Switches, OcNOS-DC und Support aus einem Vertrag.
Referenzdesigns AI-Fabric-Topologien Rail-optimiert, scheduled 3-stufiges Clos und kohärentes DCI, dimensioniert in realen Portanzahlen. Dimensionierung & Aufbau AI Fabric Design Suite Dimensionieren Sie eine GPU-Fabric: Leaf-, Spine- und Super-Spine-Anzahl mit einer Übersicht zu Komponenten und Leistungsaufnahme.
Neu bei AI-Fabrics? Hier starten Was ist eine AI-Fabric? Was ist eine GPU-Fabric? Was ist verlustfreies Ethernet? Was ist RDMA? AI-Networking-Switches
Die Technologie im Inneren Verlustfreies RoCEv2 Rail-optimiertes Netzwerk DLB-adaptives Routing GLB (7.1) Ultra Ethernet Tomahawk 6 at 1.6T DCQCN PFC-Deadlock InfiniBand vs. Ethernet RoCE vs. InfiniBand AI-Fabric-Architektur Kohärentes DCI