DE102018129112A1 - Systemdecoder für Trainingsbeschleuniger - Google Patents

Systemdecoder für Trainingsbeschleuniger Download PDF

Info

Publication number
DE102018129112A1
DE102018129112A1 DE102018129112.4A DE102018129112A DE102018129112A1 DE 102018129112 A1 DE102018129112 A1 DE 102018129112A1 DE 102018129112 A DE102018129112 A DE 102018129112A DE 102018129112 A1 DE102018129112 A1 DE 102018129112A1
Authority
DE
Germany
Prior art keywords
fabric
icl
accelerator
platform
training
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102018129112.4A
Other languages
English (en)
Inventor
Mark Schmisseur
Kshitij Doshi
Francesc Guim Bernat
Da-Ming Chiang
Suraj Prabhakaran
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE102018129112A1 publication Critical patent/DE102018129112A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/06—Physical realisation, i.e. hardware implementation of neural networks, neurons or parts of neurons
    • G06N3/063—Physical realisation, i.e. hardware implementation of neural networks, neurons or parts of neurons using electronic means
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/40—Bus structure
    • G06F13/4063—Device-to-bus coupling
    • G06F13/4068—Electrical coupling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/36—Handling requests for interconnection or transfer for access to common bus or bus system
    • G06F13/362—Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
    • G06F13/4265—Bus transfer protocol, e.g. handshake; Synchronisation on a point to point bus
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
    • G06F13/4282—Bus transfer protocol, e.g. handshake; Synchronisation on a serial bus, e.g. I2C bus, SPI bus
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/04—Architecture, e.g. interconnection topology
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/04—Architecture, e.g. interconnection topology
    • G06N3/045—Combinations of networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/08—Learning methods
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2213/00—Indexing scheme relating to interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F2213/0026—PCI express

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Biomedical Technology (AREA)
  • Biophysics (AREA)
  • General Health & Medical Sciences (AREA)
  • Molecular Biology (AREA)
  • Computing Systems (AREA)
  • Evolutionary Computation (AREA)
  • Data Mining & Analysis (AREA)
  • Mathematical Physics (AREA)
  • Computational Linguistics (AREA)
  • Artificial Intelligence (AREA)
  • Computer Hardware Design (AREA)
  • Neurology (AREA)
  • Multi Processors (AREA)
  • Advance Control (AREA)

Abstract

Es wird ein Beispiel für ein System für künstliche Intelligenz (KI) offenbart, einschließlich: einer ersten Hardwareplattform, einer Fabric-Schnittstelle, die dazu konfiguriert ist, die erste Hardwareplattform kommunikativ an eine zweite Hardwareplattform zu koppeln; eines Prozessors, der auf der ersten Hardwareplattform gehostet wird und dazu programmiert ist, an einem KI-Problem zu arbeiten; und eines ersten Trainingsbeschleunigers, einschließlich: einer Beschleunigerhardware; eines Plattform-Inter-Chip Link (ICL), der dazu konfiguriert ist, den ersten Trainingsbeschleuniger ohne Unterstützung durch den Prozessor kommunikativ an einen zweiten Trainingsbeschleuniger auf der ersten Hardwareplattform zu koppeln; eines Fabric-ICL, um den ersten Trainingsbeschleuniger ohne Unterstützung durch den Prozessor kommunikativ an einen dritten Trainingsbeschleuniger auf einer zweiten Hardwareplattform zu koppeln; und eines Systemdecoders, der dazu konfiguriert ist, den Fabric-ICL und Plattform-ICL zu betreiben, um Daten der Beschleunigerhardware ohne Unterstützung durch den Prozessor zwischen dem ersten Trainingsbeschleuniger und zweiten und dritten Trainingsbeschleunigern zu teilen.

Description

  • Gebiet der Beschreibung
  • Diese Offenbarung betrifft allgemein das Gebiet des Netzwerk-Computing und genauer, wenngleich nicht ausschließlich, ein System und Verfahren für einen Systemdecoder für Trainingsbeschleuniger.
  • Hintergrund
  • In einigen modernen Datenzentren kann die Funktion einer Vorrichtung oder Einrichtung nicht an eine spezifische, feste Hardwarekonfiguration gebunden sein. Stattdessen können Verarbeitungs-, Arbeitsspeicher-, Speicher- und Beschleunigerfunktionen in einigen Fällen von verschiedenen Orten aggregiert sein, um einen virtuellen „Verbundknoten“ zu bilden. Ein aktuelles Netzwerk kann ein Datencenter einschließen, das eine große Anzahl von generischen Hardwareservervorrichtungen hostet, die zum Beispiel in einem Server-Rack enthalten sind und durch einen Hypervisor gesteuert werden. Jede Hardwarevorrichtung kann eine oder mehrere Instanzen einer virtuellen Vorrichtung, wie einen Arbeitslastserver oder virtuellen Desktop, ausführen.
  • Figurenliste
  • Die vorliegende Offenbarung erschließt sich am besten aus der folgenden detaillierten Beschreibung, wenn diese in Verbindung mit den beigefügten Figuren gelesen wird. Es wird betont, dass verschiedene Merkmale gemäß gängiger Industriepraxis nicht notwendigerweise maßstabsgetreu gezeichnet sind und nur zu Veranschaulichungszwecken verwendet werden. Wo ein Maßstab gezeigt ist, explizit oder implizit, stellt dieser nur ein veranschaulichendes Beispiel bereit. In anderen Ausführungsformen können die Abmessungen der verschiedenen Merkmale der Klarheit der Erörterung halber beliebig erhöht oder reduziert sein.
    • 1 ist ein Blockdiagramm ausgewählter Komponenten eines Datencenters mit Netzwerkkonnektivität gemäß einem oder mehreren Beispielen der vorliegenden Anmeldung.
    • 2 ist ein Blockdiagramm ausgewählter Komponenten einer Endbenutzerrechenvorrichtung gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung.
    • 3 ist ein Blockdiagramm von Komponenten einer Rechenplattform gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung.
    • 4 ist ein Blockdiagramm eines KI-Systems mit zwei Plattformen gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung.
    • 5 ist ein Blockdiagramm eines Systemdecoders gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung.
    • 6 ist ein Signalflussdiagramm, das eine beispielhafte Broadcast-Nachricht veranschaulicht, gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung.
    • 7 ist ein Flussdiagramm eines durch einen Systemdecoder oder eine andere geeignete Vorrichtung durchgeführten Verfahrens gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung.
  • Ausführungsformen der Offenbarung
  • Die folgende Offenbarung stellt viele verschiedene Ausführungsformen oder Beispiele für das Implementieren von verschiedenen Merkmalen der vorliegenden Offenbarung bereit. Spezifische Beispiele für Komponenten und Anordnungen sind weiter unten beschrieben, um die vorliegende Offenbarung zu vereinfachen. Hierbei handelt es sich selbstverständlich nur um Beispiele, die nicht einschränkend sein sollen. Ferner können sich in der vorliegenden Offenbarung Bezugszeichen in den verschiedenen Beispielen wiederholen. Diese Wiederholung dient dem Zweck der Einfachheit und Klarheit und gibt nicht an sich eine Beziehung zwischen den verschiedenen erörterten Ausführungsformen und/oder Konfigurationen vor. Verschiedene Ausführungsformen können verschiedene Vorteile aufweisen, und kein bestimmter Vorteil einer Ausführungsform ist zwingend erforderlich.
  • Eine aktuelle Rechenplattform, wie eine von Intel® bereitgestellte Hardwareplattform oder Ähnliches, kann eine Fähigkeit zum Überwachen der Vorrichtungsleistung und Treffen von Entscheidungen über die Ressourcenbereitstellung einschließen. Zum Beispiel kann die Hardwareplattform in einem großen Datencenter, wie er durch einen Cloud-Dienst-Anbieter (Cloud Service Provider, CSP) bereitgestellt werden kann, Rack-montierte Server mit Rechenressourcen, wie Prozessoren, Arbeitsspeicher, Speicher-Pools, Beschleunigern und anderen ähnlichen Ressourcen, einschließen. Bei Verwendung in diesem Dokument schließt „Cloud Computing“ netzwerkverbundene Rechenressourcen und Technologie ein, die einen ubiquitären (oft weltweiten) Zugriff auf Daten, Ressourcen und/oder Technologie ermöglicht. Cloud-Ressourcen sind allgemein durch hohe Flexibilität gekennzeichnet, um Ressourcen gemäß aktuellen Arbeitslasten und Anforderungen dynamisch zuzuweisen. Dies kann zum Beispiel über eine Virtualisierung, wobei Ressourcen, wie Hardware, Speicher und Netzwerke, für eine virtuelle Maschine (VM) über eine Softwareabstraktionsschicht bereitgestellt werden, und/oder eine Containerisierung, wobei Instanzen von Netzwerkfunktionen in „Containern“ bereitgestellt werden, die voneinander getrennt sind, aber zugrunde liegende Betriebssystem-, Arbeitsspeicher- und Treiberressourcen teilen, erreicht werden.
  • Deep Learning-Algorithmen oder sogenannte „künstliche Intelligenz“ (KI) sind ein wichtiges aktuelles Rechenproblem. Künstliche-Intelligenz-Systeme, die zum Beispiel Convolutional Neural Networks (CNNs) einsetzen, werden für aktuelle Rechenprobleme, wie das Durchsuchen großer Datensätze, das Klassifizieren von Dokumenten, Computer Vision, selbstständig arbeitende Maschinen (einschließlich selbstfahrender Autos) und viele andere, verwendet.
  • Diese Deep Learning-Algorithmen beinhalten oft ein mehrstufiges Verfahren, einschließlich einer Trainingsphase, in der das Künstliche-Intelligenz-Modell mit einem vorgegebenen Datensatz trainiert wird, und einer Betriebsphase, in der es die Arbeit durchführt. Die Trainingsphase muss keine eigenständige Phase sein, die vor der Betriebsphase stattfindet, sondern kann in einigen Fällen ein kontinuierliches Verfahren sein, in dem das CNN fortlaufend Rückkopplungs- und zusätzliche Trainingsdaten empfängt, sodass es seine Prozesse weiter verfeinern kann. Das CNN selbst wird oft auf eine in hohem Maße verteilte Art und Weise eingesetzt, wie in einem Cluster für Hochleistungsrechnen (High Performance Computing, HPC) oder in einem großen Datencenter, wie es von einem Cloud-Dienst-Anbieter (Cloud Service Provider, CSP) bereitgestellt werden kann. Eine große Anzahl von Rechenknoten kann parallel an dem Künstliche-Intelligenz-Problem arbeiten und somit wertvolle Ergebnisse in nützlichen Zeiträumen erzeugen.
  • Betreiber dieser neuralen Netzwerke müssen möglicherweise sehr umfangreiche Trainingsaufgaben für ihre Deep Leaming-Problemsätze ausführen. In einigen Fällen kann eine Hardwarebeschleunigungslösung (wie Intel® Lake Crest) verwendet werden, um eine Beschleunigung des Trainingsproblems bereitzustellen. Der Hardwarebeschleuniger kann einen Coprozessor, eine anwenderprogrammierbare Gatteranordnung (Field Programmable Gate Array, FPGA), eine anwendungsspezifische integrierte Schaltung (Application-Specific Integrated Circuit, ASIC), eine Grafikverarbeitungseinheit (Graphics Processing Unit, GPU), Firmware oder andere beschleunigte Rechenvorrichtungen einschließen. Der Betreiber des neuralen Netzwerks muss möglicherweise dazu in der Lage sein, viele Beschleuniger auf eine flexible und transparente Weise zusammenzubringen, sodass die Kommunikation zwischen den Beschleunigern nicht für die Lösung selbst umständlich wird.
  • Einige bestehende Systeme verwenden Scale-Out-KI-Beschleuniger, wie GPUs. In diesen Architekturen kann die Koordination zwischen Beschleunigern auf der Softwareebene erfolgen. Daten müssen möglicherweise den Beschleunigern zugeführt werden, die Beschleuniger berechnen ihre Ergebnisse und dann werden Ergebnisse von Beschleunigern in Systemspeicher verschoben und von dort werden sie zwischen verschiedenen Scale-Out-Knoten und dann zu den an diese Knoten gebundenen Beschleunigern verteilt. Somit können für die Kommunikation zwischen den verschiedenen Beschleunigern in einem KI-System mehrere Ebenen des Weiterleitens von Daten von einem Beschleuniger zu einem Prozessor, von einem Prozessor zu einem Prozessor und dann von einem Prozessor zu einem anderen Beschleuniger bestehen. Dies kann Cache-Operationen, Hauptspeicherzugriffe und andere Speicheroperationen einschließen, die den Betrieb des Beschleunigers im Wesentlichen verlangsamen können. Des Weiteren führt die am Verschieben dieser Daten beteiligte Software Overhead in das Verfahren ein. Ein oder mehrere Kerne müssen möglicherweise speziell dafür vorgesehen sein, die Software zum Verschieben von Daten zwischen den verschiedenen Beschleunigern auszuführen.
  • Dies kann zu einem wesentlichen Overhead und einer erheblichen Verschwendung von Rechenressourcen führen. Zum Beispiel können Quellen von Overhead Folgendes einschließen:
    1. 1. Steuer- und Datenebene in Fabric-Software.
    2. 2. Verschiebung von Daten innerhalb verschiedener Speicherebenen.
    3. 3. Koordination von Scale-Out-Instanzen, die in Software durchgeführt werden.
  • Dieser Overhead kann zu einem einschränkenden Faktor für die Gesamtleistung des KI-Systems werden, weil die Deep Learning-Trainingsmodelle über viele Knoten, einschließlich Kernen und Beschleunigervorrichtungen, verteilt sind. Der Overhead belastet auch die beschränkten Leistungs- und Wärmekapazitäten jedes Knotens, weil sowohl CPUs als auch Beschleunigervorrichtungen fortlaufend ausgeführt werden müssen, um das Deep Learning-Training und die aus dem Training hervorgehenden Kommunikationsaufgaben durchzuführen.
  • Einige bestehende Lösungen stellen Optimierungen bereit, die systemkonfigurationsbewusst sind, um die Kommunikation und Koordination zu reduzieren, die in dem Deep Learning-Trainingssystem erforderlich ist. Diese können zum Beispiel darauf ausgerichtet sein, die Kommunikation zu reduzieren, teilweise sogar auf Kosten von Datenparallelität. Einige Softwarelösungen können sich auf eine Speicherverwaltung im Hintergrund konzentrieren, die die Verschiebung von Daten zwischen CPUs und GPUs steuert, wodurch die Ausführungsleistung optimiert wird. Andere Lösungen führen Parameterserver ein, um die Datenaustausch- und -synchronisierungsschritte zwischen den verschiedenen Knoten zu vereinfachen. Diese können von allen Anwendungen während eines Koordinationsschritts gelesen und geschrieben werden. Bei diesem Ansatz wird die Trainingsleistung abhängig von der Parameterserverimplementierung.
  • In diesen Fällen ist die Koordination in Scale-Out-Ansätzen durch die Skalierbarkeit beschränkt. Des Weiteren sind konfigurationsbewusste Optimierungen fehleranfällig und schwer zu validieren und erfordern möglicherweise eine Versuch-und-Irrtum-Methode, was letztlich zu Kompromissen führt, die erneut untersucht werden müssen, wenn sich Problemgrößen und Systemkonfigurationen ändern. Wenngleich diese Lösungen einige Vorteile bieten, vermeiden sie außerdem nicht, dass eine Datenübertragung zwischen verschiedenen Speicherebenen erfolgt.
  • In einigen Fällen berücksichtigen diese bestehenden Lösungen auch nicht die dem Problem inhärenten Kommunikationsschwierigkeiten. Zum Beispiel kann es schwierig sein, diese Ansätze im Kontext von Cloud Computing-Einrichtungen am Rand des Netzwerks einzusetzen, wo die für die Mandanten verfügbaren Ressourcen (z. B. in Form von normalen Rechenkernen) beschränkt sind. Daher können die Overhead-Faktoren nur schwer abgeschwächt werden, indem Hardwarebeschleuniger (wie Intel® Lake Crest) mit bestehenden Rechensystemen, wie gewöhnlichen x86-Prozessoren, gemischt werden. Dies kann auch Herausforderungen bei der Mandantenfähigkeit schaffen, weil die für jeden Mandanten verfügbaren Ressourcen beschränkt sind. Während somit einige Knoten eine überschüssige Beschleunigungskapazität aufweisen können, fehlen anderen möglicherweise die erforderlichen CPU-Zyklen, die für den Mandanten verfügbar sind, sodass der Mandant vom Anzapfen dieser Kapazität profitieren kann. Schließlich sind solche softwarestapelvermittelten Kommunikationen für eine „Silobildung“ anfällig.
  • Es ist jedoch möglich, die Beschränkungen von softwarestapelvermittelten Kommunikationen zwischen Beschleunigern zu berücksichtigen, indem die Beschleuniger selbst erweitert werden. Ausführungsformen der vorliegenden Beschreibung erweitern den Inter-Chip Link (ICL) des Beschleunigers, zum Beispiel den Lake Crest ICL, der die Kommunikationslogik zwischen KI-Einrichtungen innerhalb einer Plattform bereitstellt. Diese Erweiterungen können eine neuartige Logik für transparente Verbindungen mit einem Protokoll für die Kommunikation zwischen Vorrichtungen bei Einrichtungen, die auf der Ebene eines Datencenters oder mehrerer Datencenter verbunden sind, über ein sicheres Weitverkehrsnetzwerk (Wide Area Network, WAN) bereitstellen. Kommunikationstransparenz kann erreicht werden, indem das Routing und Weiterleiten in ein neuartiges Systemdecoderelement programmiert wird, das auf dem Beschleuniger selbst bereitgestellt werden kann. Der Systemdecoder kann in jeder geeigneten Form bereitgestellt werden. Wenn der Beschleuniger zum Beispiel eine GPU ist, kann der Systemdecoder in einem Festwertspeicher (Read-Only Memory, ROM) oder Firmware bereitgestellt werden oder kann als ein Coprozessor, ASIC, FPGA oder eine andere Logikvorrichtung, die die in dieser Beschreibung beschriebenen Systemdecoderfunktionen bereitstellt, bereitgestellt werden. Der hierin beschriebene Systemdecoder erreicht eine Kommunikation zwischen Vorrichtungen in demselben physischen Gehäuse (das als ein „Einschub“ oder eine „Kapsel“ bezeichnet werden kann) über einen Plattform-ICL und stellt außerdem einen neuen Fabric-ICL zwischen Plattformen bereit, der dazu konfiguriert ist, Protokollverkehr zwischen Vorrichtungen nativ über eine Fabric zwischen Gehäusen, wie Intel® Omni-Path, Ethernet oder eine andere Datencenter-Fabric, zu tunneln. Somit erstreckt sich die Kommunikationstransparenz nahtlos auf andere Vorrichtungen, die in verschiedenen Plattformeinheiten, wie verschiedenen Racks, Einschüben, Kapseln, oder sogar in verschiedenen Datenzentren angeordnet sind.
  • Dies ermöglicht es, eine Verbindung zwischen einer beliebigen Gruppierung von KI-Einrichtungen herzustellen, die miteinander verbunden sind, während die Details, wie der zwischen diesen bestehende Typ von physischem und Netzwerkkanal, herausabstrahiert werden, sodass Rechenlogik in den Einrichtungen je nach Bedarf nahtlos arbeiten kann, als ob sie in einer beliebig großen, hochskalierten Instanz arbeiten würde. Sie kann auch in herunterskalierten oder disaggregierten Instanzen arbeiten, wenn das Erfordernis einer Kommunikation mit hoher Bandbreite zwischen Vorrichtungen entfällt. Eine verhältnismäßig kleine Menge an programmierbarer Logik (wie in einer FPGA) kann eine erweiterbare Unterstützung für mehrere Kommunikationsprotokolle ermöglichen, damit die Architektur leichter weiterentwickelt werden kann und weiterhin leicht über verschiedene Datenzentren, Clouds und Fog-Designs hinweg eingesetzt werden kann.
  • Vorteilhafterweise ermöglicht der Systemdecoder der vorliegenden Beschreibung eine transparente Koordination zwischen Beschleunigern, ohne dass Datenflüsse zwischen diesen durch andere Speicherebenen, wie nach oben durch Hauptspeicher, geführt werden müssen, und ohne dass CPUs eingreifen müssen, um Übertragungen über Plattformen hinweg durchzuführen. Dies ermöglicht eine schnellere Synchronisierung, rationalisierte Datenaustausche und schnellere Ausführungszeiten bei Trainingsdatensätzen. Es bietet auch Vorteile bezogen auf bestehende Hochgeschwindigkeits-Links zwischen GPUs oder FPGAs. Im Gegensatz zu diesen bestehenden Hochgeschwindigkeits-Links, die innerhalb einer einzigen physischen Plattform arbeiten, unterstützt der Systemagent der vorliegenden Beschreibung skalierbare Zusammenstellungen von verteilten Beschleunigungsressourcen und hochskalierten und herunterskalierten Bereitstellungen auf einer dynamischen Basis über mehrere Einschübe, Module, Racks oder sogar Datenzentren hinweg.
  • Der hierin beschriebene Systemdecoder stellt nützliche Funktionen bereit, die eine dynamische Zusammenstellung von Vorrichtungen in einer KI-Anwendung ermöglichen, bei der Daten mit niedriger Latenz zwischen den Vorrichtungen geteilt werden. Der Systemdecoder erweitert die aktuelle Architektur, um eine elastische Hochskalierung und horizontale Skalierung von verfügbaren Komponenten zu erreichen, um einen hohen Durchsatz und Pipelines oder Funktionen mit niedriger Latenz zu erreichen.
  • Ein erweiterter ICL, der der Hardwarebeschleunigerplattform hinzugefügt wird, kann die folgenden Komponenten einschließen.
  • Ein System und Verfahren für einen Systemdecoder für Trainingsbeschleuniger wird jetzt unter besonderer Bezugnahme auf die beigefügten FIGUREN beschrieben. Es sei darauf hingewiesen, dass bestimmte Bezugszeichen über die gesamten FIGUREN hinweg möglicherweise wiederholt werden, um anzuzeigen, dass eine bestimmte Vorrichtung oder ein bestimmter Block über die FIGUREN hinweg vollständig oder im Wesentlichen konsistent ist. Hierdurch soll jedoch keine bestimmte Beziehung zwischen den verschiedenen offenbarten Ausführungsformen impliziert werden. In bestimmten Beispielen kann durch ein bestimmtes Bezugszeichen auf eine Gattung von Elementen verwiesen werden („Gerät 10“), während auf einzelne Spezies oder Beispiele der Gattung durch ein Bezugszeichen mit Bindestrich verwiesen wird („erstes spezifisches Gerät 10-1“ und „zweites spezifisches Gerät 10-2“).
  • 1 ist ein Blockdiagramm von ausgewählten Komponenten eines Datencenters mit Konnektivität zu einem Netzwerk 100 eines Cloud-Dienst-Anbieters (Cloud Service Provider, CSP) 102 gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung. Der CSP 102 kann als nicht einschränkendes Beispiel ein herkömmliches Unternehmensdatencenter, eine „private Cloud“ eines Unternehmens oder eine „öffentliche Cloud“ sein, das/die Dienste, wie Infrastructure as a Service (IaaS), Platform as a Service (PaaS) oder Software as a Service (SaaS), bereitstellt.
  • Der CSP 102 kann eine Anzahl von Arbeitslast-Clustern 118 bereitstellen, die Cluster von einzelnen Servern, Blade-Servern, Rack-montierten Servern oder jede andere geeignete Servertopologie sein können. In diesem veranschaulichenden Beispiel sind zwei Arbeitslast-Cluster 118-1 und 118-2 gezeigt, die jeweils Rack-montierte Server 146 in einem Gehäuse 148 bereitstellen.
  • In dieser Darstellung sind die Arbeitslast-Cluster 118 als modulare Arbeitslast-Cluster entsprechend dem Höheneinheitsstandard gezeigt, in denen ein Standard-Rack mit einer Breite von 19 Zoll gebaut werden kann, um 42 Einheiten (42HE), jeweils mit einer Höhe von 1,75 Zoll und einer ungefähren Breite von 36 Zoll, aufzunehmen. In diesem Fall können Rechenressourcen, wie Prozessoren, Arbeitsspeicher, Speicher, Beschleuniger und Switche, in ein Vielfaches von Höheneinheiten von eins bis 42 passen.
  • Jeder Server 146 kann ein eigenständiges Betriebssystem hosten und eine Serverfunktion bereitstellen, oder Server können virtualisiert sein, wobei sie in diesem Fall unter der Steuerung eines Virtual Machine Managers (VMM), Hypervisors und/oder Orchestrators stehen können, und sie können eine/n oder mehrere virtuelle Maschinen, virtuelle Server oder virtuelle Einrichtungen hosten. Diese Server-Racks können zusammen in einem einzelnen Datencenter angeordnet sein, oder sie können sich in verschiedenen geografischen Datenzentren befinden. Je nach den vertraglichen Vereinbarungen können einige Server 146 speziell für bestimmte Unternehmens-Clients oder Mandanten vorgesehen sein, während andere geteilt sein können.
  • Die verschiedenen Vorrichtungen in einem Datencenter können über eine Schalt-Fabric 170 miteinander verbunden sein, die eine oder mehrere Hochgeschwindigkeits-Routing- und/oder -Schaltvorrichtungen einschließen kann. Die Schalt-Fabric 170 kann sowohl „Nord-Süd“-Verkehr (z. B. Verkehr zu und von dem Weitverkehrsnetzwerk (Wide Area Network, WAN), wie dem Internet) als auch „Ost-West“-Verkehr (z. B. Verkehr über das Datencenter hinweg) bereitstellen. In der Vergangenheit machte der Nord-Süd-Verkehr den Großteil des Netzwerkverkehrs aus, aber mit der zunehmenden Komplexität und Verteilung von Webdiensten hat das Volumen von Ost-West-Verkehr zugenommen. In vielen Datenzentren macht Ost-West-Verkehr jetzt den Großteil des Verkehrs aus.
  • Des Weiteren kann das Verkehrsvolumen mit wachsenden Fähigkeiten jedes Servers 146 weiter zunehmen. Zum Beispiel kann jeder Server 146 mehrere Prozessorsteckplätze bereitstellen, wobei jeder Steckplatz einen Prozessor mit vier bis acht Kernen aufnimmt, sowie ausreichenden Arbeitsspeicher für die Kerne. Somit kann jeder Server eine Anzahl von VMs hosten, die jeweils ihren eigenen Verkehr erzeugen.
  • Um das große Verkehrsvolumen in einem Datencenter zu bewältigen, kann eine hochfähige Schalt-Fabric 170 bereitgestellt werden. Die Schalt-Fabric 170 ist in diesem Beispiel als ein „flaches“ Netzwerk veranschaulicht, wobei jeder Server 146 eine Direktverbindung zu einem Top-of-Rack(ToR)-Switch 120 (z. B. eine „Stern“-Konfiguration) aufweisen kann und jeder ToR-Switch 120 an einen Core-Switch 130 koppeln kann. Diese zweistufige flache Netzwerkarchitektur ist nur als ein veranschaulichendes Beispiel gezeigt. In weiteren Beispielen können andere Architekturen verwendet werden, wie als nicht einschränkendes Beispiel dreistufige Stern- oder Leaf-Spine-Architekturen (sogenannte „Fat Tree“-Topologien) basierend auf der „Clos“-Architektur, Hub-and-Spoke-Topologien, Maschentopologien, Ringtopologien oder 3-D-Maschentopologien.
  • Die Fabric selbst kann durch jede geeignete Verschaltung bereitgestellt werden. Zum Beispiel kann jeder Server 146 eine Intel® Host Fabric Interface (HFI), eine Netzwerkschnittstellenkarte (Network Interface Card, NIC) oder eine andere Host-Schnittstelle einschließen. Die Host-Schnittstelle selbst kann über eine Verschaltung oder einen Bus, wie PCI, PCIe oder Ähnliches, an einen oder mehrere Prozessoren koppeln, und in einigen Fällen kann dieser Verschaltungsbus als Teil der Fabric 170 betrachtet werden.
  • Die Verschaltungstechnologie kann als eine einzelne Verschaltung oder eine hybride Verschaltung bereitgestellt werden, wie in dem Fall, in dem PCIe eine chipinterne Kommunikation bereitstellt, 1-Gb- oder 10-Gb-Ethernet über Kupferkabel verhältnismäßig kurze Verbindungen zu einem ToR-Switch 120 bereitstellt und optische Kabel verhältnismäßig längere Verbindungen zu dem Core-Switch 130 bereitstellen. Verschaltungstechnologien schließen als nicht einschränkendes Beispiel Intel® Omni-Path™, TrueScale™, Ultra Path Interconnect (OPI) (früher als QPI oder KTI bezeichnet), FibreChannel, Ethernet, FibreChannel over Ethernet (FCoE), InfiniBand, PCI, PCIe oder Faseroptik, um nur einige zu nennen, ein. Einige von diesen eignen sich für bestimmte Bereitstellungen oder Funktionen besser als andere, und das Auswählen einer geeigneten Fabric für die vorliegende Anwendung zählt zu den Aufgaben eines Fachmanns.
  • Es sei jedoch darauf hingewiesen, dass, wenngleich High-End-Fabrics, wie Omni-Path™, hierin zur Veranschaulichung bereitgestellt werden, die Fabric 170 allgemeiner jede geeignete Verschaltung oder jeder geeignete Bus für die bestimmte Anwendung sein kann. Dies kann in einigen Fällen ältere Verschaltungen, wie lokale Netzwerke (Local Area Networks, LANs), Token Ring-Netzwerke, synchrone optische Netzwerke (Synchronous Optical NETworks, SONET), Netzwerke mit asynchronem Übertragungsmodus (Asynchronous Transfer Mode, ATM), drahtlose Netzwerke, wie WiFi und Bluetooth, Verschaltungen des analogen Telefondiensts (Plain Old Telephone System, POTS) oder Ähnliches, einschließen. Es wird außerdem ausdrücklich in Erwägung gezogen, dass in der Zukunft neue Netzwerktechnologien aufkommen werden, um einige der hier aufgeführten zu ergänzen oder zu ersetzen und dass beliebige dieser künftigen Netzwerktopologien und -technologien die Fabric 170 sein oder einen Teil davon bilden können.
  • In bestimmten Ausführungsformen kann die Fabric 170 Kommunikationsdienste auf verschiedenen „Schichten“ bereitstellen, wie ursprünglich in dem OSI-7-Schichten-Netzwerkmodell dargestellt. In der aktuellen Praxis wird dem OSI-Modell nicht streng gefolgt. Im Allgemeinen werden die Schichten 1 und 2 oft als „Ethernet“-Schicht bezeichnet (wenngleich Ethernet in großen Datenzentren oft durch neuere Technologien abgelöst wurde). Die Schichten 3 und 4 werden oft als die Übertragungssteuerungsprotokoll/Internetprotokoll(Transmission Control Protocol/Internet Control, TCP/IP)-Schicht bezeichnet (die weiter in TCP- und IP-Schichten unterteilt werden kann). Die Schichten 5 bis 7 können als die „Anwendungsschicht“ bezeichnet werden. Diese Schichtdefinitionen werden als ein nützliches Rahmenwerk offenbart, sollen aber nicht einschränkend sein.
  • 2 ist ein Blockdiagramm einer Endbenutzerrechenvorrichtung 200 gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung.
  • In diesem Beispiel wird eine Fabric 270 bereitgestellt, um verschiedene Aspekte der Rechenvorrichtung 200 zu verbinden. Die Fabric 270 kann mit der Fabric 170 von 1 identisch sein oder kann eine verschiedene Fabric sein. Wie weiter oben angegeben, kann die Fabric 270 durch jede geeignete Verschaltung bereitgestellt werden. In diesem Beispiel wird Intel® Omni-Path™ als ein veranschaulichendes und nicht einschränkendes Beispiel verwendet.
  • Wie dargestellt, schließt die Rechenvorrichtung 200 eine Anzahl von Logikelementen ein, die eine Vielzahl von Knoten bilden. Es sei klargestellt, dass jeder Knoten durch einen physischen Server, eine Gruppe von Servern oder andere Hardware bereitgestellt werden kann. Jeder Server kann eine oder mehrere virtuelle Maschinen ausführen, wie es für seine Anwendung geeignet ist.
  • Der Knoten 0 208 ist ein Verarbeitungsknoten mit einem Prozessorsockel 0 und einem Prozessorsockel 1. Die Prozessoren können zum Beispiel Intel® Xeon™-Prozessoren mit einer Vielzahl von Kernen, wie 4 oder 8 Kernen, sein. Der Knoten 0 208 kann dazu konfiguriert sein, Netzwerk- oder Arbeitslastfunktionen bereitzustellen, wie durch Hosten einer Vielzahl von virtuellen Maschinen oder virtuellen Einrichtungen.
  • Die interne Kommunikation zwischen Prozessorsockel 0 und Prozessorsockel 1 kann durch einen internen Uplink 278 bereitgestellt werden. Dies kann eine Verschaltung mit sehr hoher Geschwindigkeit und kurzer Länge zwischen den beiden Prozessorsockeln bereitstellen, sodass virtuelle Maschinen, die auf dem Knoten 0 208 ausgeführt werden, bei sehr hohen Geschwindigkeiten miteinander kommunizieren können. Um diese Kommunikation zu unterstützen, kann ein virtueller Switch (vSwitch) auf dem Knoten 0 208 bereitgestellt werden, der als Teil der Fabric 270 betrachtet werden kann.
  • Der Knoten 0 208 stellt über eine HFI 272 eine Verbindung zu der Fabric 270 her. Die HFI 272 kann eine Verbindung zu einer Intel® Omni-Path™ Fabric herstellen. In einigen Beispielen kann die Kommunikation mit der Fabric 270 getunnelt werden, wie durch ein Bereitstellen von UPI-Tunneln über Omni-Path™.
  • Da die Rechenvorrichtung 200 viele Funktionen auf eine verteilte Weise bereitstellen kann, die bei früheren Generationen intern bereitgestellt wurden, kann eine hochfähige HFI 272 bereitgestellt werden. Die HFI 272 kann bei Geschwindigkeiten von mehreren Gigabit pro Sekunde arbeiten und kann in einigen Fällen eng mit dem Knoten 0 208 gekoppelt sein. Zum Beispiel ist die Logik für die HFI 272 in einigen Ausführungsformen direkt mit den Prozessoren auf einem System-on-a-Chip verbunden. Dies stellt eine Kommunikation mit sehr hoher Geschwindigkeit zwischen der HFI 272 und den Prozessorsockeln bereit, ohne dass zwischengeschaltete Busvorrichtungen benötigt werden, die zusätzliche Latenz in die Fabric einführen können. Dies soll jedoch nicht implizieren, dass Ausführungsformen, bei denen die HFI 272 über einen herkömmlichen Bus bereitgestellt wird, auszuschließen sind. Stattdessen wird ausdrücklich in Erwägung gezogen, dass die HFI 272 in einigen Beispielen auf einem Bus, wie einem PCIe-Bus, bereitgestellt werden kann, wobei es sich um eine serialisierte Version von PCI handelt, die höhere Geschwindigkeiten als herkömmliches PCI bereitstellt. Über die gesamte Rechenvorrichtung 200 hinweg können verschiedene Knoten verschiedene Typen von HFIs 272, wie interne HFIs und Plug-in-HFIs, bereitstellen. Es sei außerdem darauf hingewiesen, dass bestimmte Blöcke in einem System-on-a-Chip als Blöcke geistigen Eigentums (Intellectual Property, IP) bereitgestellt werden können, die als eine modulare Einheit in eine integrierte Schaltung „eingefügt“ werden können. Daher kann die HFI 272 in einigen Fällen von einem solchen IP-Block abgeleitet werden.
  • Es sei darauf hingewiesen, dass der Knoten 0 208 internen Arbeitsspeicher oder Speicher gemäß dem Grundsatz „das Netzwerk ist die Vorrichtung“ möglicherweise eingeschränkt oder nicht bereitstellt. Stattdessen kann sich der Knoten 0 208 hauptsächlich auf verteilte Dienste, wie einen Arbeitsspeicherserver und einen vernetzten Speicherserver, stützen. Intern stellt der Knoten 0 208 möglicherweise nur ausreichend Arbeitsspeicher und Speicher bereit, um die Vorrichtung zu laden und deren Kommunikation mit der Fabric 270 zu ermöglichen. Diese Art von verteilter Architektur ist aufgrund der sehr hohen Geschwindigkeiten von aktuellen Datenzentren möglich und kann vorteilhaft sein, weil ein Over-Provisioning von Ressourcen für jeden Knoten nicht erforderlich ist. Stattdessen kann ein großer Pool von Hochgeschwindigkeits- oder spezialisiertem Arbeitsspeicher dynamisch zwischen einer Anzahl von Knoten bereitgestellt werden, sodass jeder Knoten auf einen großen Pool von Ressourcen zugreifen kann, diese Ressourcen jedoch nicht ungenutzt bleiben, wenn dieser bestimmte Knoten sie nicht benötigt.
  • In diesem Beispiel stellen ein Arbeitsspeicherserver 204 von Knoten 1 und ein Speicherserver 210 von Knoten 2 die operativen Arbeitsspeicher- und Speicherfunktionen des Knotens 0 208 bereit. Zum Beispiel kann der Arbeitsspeicherserverknoten 1 204 entfernten direkten Speicherzugriff (Remote Direct Memory Access, RDMA) bereitstellen, wobei der Knoten 0 208 über die Fabric 270 auf eine DMA-Weise auf Arbeitsspeicherressourcen auf dem Knoten 1 204 zugreifen kann, vergleichbar damit, wie er auf seinen eigenen internen Arbeitsspeicher zugreifen würde. Der durch den Arbeitsspeicherserver 204 bereitgestellte Arbeitsspeicher kann ein herkömmlicher Arbeitsspeicher, wie ein dynamischer Arbeitsspeicher mit wahlfreiem Zugriff (Dynamic Random Access Memory, DRAM) mit doppelter Datenrate vom Typ 3 (DDR3), sein, der flüchtig ist, oder kann ein exotischerer Arbeitsspeichertyp, wie ein dauerhafter schneller Arbeitsspeicher (Persistent Fast Memory, PFM), wie Intel® 3D Crosspoint™ (3DXP), sein, der bei DRAM-ähnlichen Geschwindigkeiten arbeitet, aber nichtflüchtig ist.
  • In ähnlicher Weise kann ein Speicherserverknoten 2 210 bereitgestellt werden, anstatt eine interne Festplatte für den Knoten 0 208 bereitzustellen. Der Speicherserver 210 kann eine vernetzte Ansammlung von Platten (Networked Bunch of Disks, NBOD), PFM, ein redundantes Array unabhängiger Festplatten (Redundant Array of Independent Disks, RAID), ein redundantes Array unabhängiger Knoten (Redundant Array of Independent Nodes, RAIN), Network Attached Storage (NAS), optischen Speicher, Bandlaufwerke oder andere nicht-flüchtige Speicherlösungen bereitstellen.
  • Somit kann der Knoten 0 208 beim Durchführen seiner bestimmten Funktion auf Arbeitsspeicher von dem Arbeitsspeicherserver 204 zugreifen und Ergebnisse auf einem durch den Speicherserver 210 bereitgestellten Speicher speichern. Jede dieser Vorrichtungen koppelt über eine HFI 272, die eine schnelle Kommunikation bereitstellt, die diese Technologien möglich macht, an die Fabric 270.
  • Zur weiteren Veranschaulichung ist auch der Knoten 3 206 dargestellt. Der Knoten 3 206 schließt auch eine HFI 272 zusammen mit zwei Prozessorsockeln, die intern durch einen Uplink verbunden sind, ein. Im Gegensatz zu dem Knoten 0 208 schließt jedoch der Knoten 3 206 seinen eigenen internen Arbeitsspeicher 222 und Speicher 250 ein. Somit kann der Knoten 3 206 dazu konfiguriert sein, seine Funktionen hauptsächlich intern durchzuführen, und es kann nicht erforderlich sein, dass er sich auf den Arbeitsspeicherserver 204 und den Speicherserver 210 stützt. Unter geeigneten Umständen kann jedoch der Knoten 3 206 ähnlich wie der Knoten 0 208 seinen eigenen internen Arbeitsspeicher 222 und Speicher 250 mit verteilten Ressourcen ergänzen.
  • Die Rechenvorrichtung 200 kann auch die Beschleuniger 230 einschließen. Diese können verschiedene beschleunigte Funktionen bereitstellen, einschließlich Hardware- oder Coprozessorbeschleunigung für Funktionen, wie Paketverarbeitung, Verschlüsselung, Entschlüsselung, Komprimierung, Dekomprimierung, Netzwerksicherheit oder andere beschleunigte Funktionen im Datencenter. In einigen Beispielen kann der Beschleuniger 230 Deep Learning-Beschleuniger einschließen, die direkt an einen oder mehrere Kerne in Knoten, wie den Knoten 0 208 oder den Knoten 3 206, gebunden sein können. Beispiele für diese Beschleuniger können als nicht einschränkendes Beispiel Intel® QuickData Technology (QDT), Intel® QuickAssist Technology (QAT), Intel® Direct Cache Access (DCA), Intel® Extended Message Signaled Interrupt (MSI-X), Intel® Receive Side Coalescing (RSC) und andere Beschleunigungstechnologien einschließen.
  • Der Basisbaublock der verschiedenen hierin offenbarten Komponenten kann als „Logikelemente“ bezeichnet werden. Logikelemente können Hardware (einschließlich zum Beispiel eines softwareprogrammierbaren Prozessors, einer ASIC oder einer FPGA), externe Hardware (digital, analog oder Mischsignal), Software, reziprozierende Software, Dienste, Treiber, Schnittstellen, Komponenten, Module, Algorithmen, Firmware, Mikrocode, Sensoren, Komponenten, programmierbare Logik oder Objekte, die koordinationsfähig sind, um eine logische Operation zu erreichen, einschließen. Des Weiteren werden einige Logikelemente durch ein greifbares, nicht-flüchtiges computerlesbares Medium bereitgestellt, auf dem ausführbare Befehle zum Anweisen eines Prozessors zum Durchführen einer bestimmten Aufgabe gespeichert sind. Ein solches nicht-flüchtiges Medium kann als nicht einschränkendes Beispiel zum Beispiel eine Festplatte, einen Halbleiterspeicher oder ein Halbleiterlaufwerk, Festwertspeicher (Read-Only Memory, ROM), dauerhaften schnellen Arbeitsspeicher (Persistent Fast Memory, PFM) (z. B. Intel® 3D Crosspoint™), externen Speicher, ein redundantes Array unabhängiger Festplatten (Redundant Array of Independent Disks, RAID), ein redundantes Array unabhängiger Knoten (Redundant Array of Independent Nodes, RAIN), Network Attached Storage (NAS), optischen Speicher, ein Bandlaufwerk, ein Sicherungssystem, Cloud-Speicher oder jede Kombination des Vorgenannten einschließen. Ein solches Medium kann auch Befehle einschließen, die in eine FPGA programmiert oder in Hardware auf einer ASIC oder einem Prozessor codiert sind.
  • 3 veranschaulicht ein Blockdiagramm von Komponenten einer Rechenplattform 302A gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung. In der dargestellten Ausführungsform sind die Plattformen 302A, 302B und 302C zusammen mit einer Datencenterverwaltungsplattform 306 und einer Datenanalytik-Engine 304 über ein Netzwerk 308 miteinander verbunden. In anderen Ausführungsformen kann ein Computersystem jede geeignete Anzahl von Plattformen (d. h. eine oder mehrere) einschließen. In einigen Ausführungsformen (wenn z. B. ein Computersystem nur eine einzelne Plattform einschließt) kann die gesamte oder ein Abschnitt der Systemverwaltungsplattform 306 auf einer Plattform 302 enthalten sein. Eine Plattform 302 kann eine Plattformlogik 310 mit einer oder mehreren zentralen Verarbeitungseinheiten (Central Processing Units, CPUs) 312, Speichern 314 (die eine beliebige Anzahl von verschiedenen Modulen einschließen können), Chipsätzen 316, Kommunikationsschnittstellen 318 und jeder anderen geeigneten Hardware und/oder Software zum Ausführen eines Hypervisors 320 oder anderen Betriebssystems, das dazu in der Lage ist, Arbeitslasten in Verbindung mit auf der Plattform 302 ausgeführten Anwendungen auszuführen, einschließen. In einigen Ausführungsformen kann eine Plattform 302 als eine Host-Plattform für ein oder mehrere Gastsysteme 322 fungieren, die diese Anwendungen aufrufen. Die Plattform 302A kann jede geeignete Rechenumgebung, wie eine Hochleistungsrechenumgebung, ein Datencenter, eine Kommunikationsdienstanbieterinfrastruktur (z. B. einen oder mehrere Abschnitte eines Evolved Paket Core), eine speicherinterne Rechenumgebung, ein Rechensystem eines Fahrzeugs (z. B. eines Autos oder Flugzeugs), eine Internet der Dinge-Umgebung, ein industrielles Steuersystem, eine andere Rechenumgebung oder eine Kombination davon, darstellen.
  • In verschiedenen Ausführungsformen der vorliegenden Offenbarung werden die akkumulierte Belastung und/oder Raten von akkumulierter Belastung einer Vielzahl von Hardwareressourcen (z. B. Kerne und Uncores) überwacht und können Entitäten (z. B. die Systemverwaltungsplattform 306, der Hypervisor 320 oder ein anderes Betriebssystem) der Computerplattform 302A Hardwareressourcen der Plattformlogik 310 zuweisen, um Arbeitslasten gemäß den Belastungsinformationen durchzuführen. In einigen Ausführungsformen können Eigendiagnosefähigkeiten mit der Belastungsüberwachung kombiniert werden, um die Integrität der Hardwareressourcen genauer zu bestimmen. Jede Plattform 302 kann die Plattformlogik 310 einschließen. Die Plattformlogik 310 umfasst neben anderer Logik, die die Funktionalität der Plattform 302 ermöglicht, eine oder mehrere CPUs 312, den Arbeitsspeicher 314, einen oder mehrere Chipsätze 316 und Kommunikationsschnittstellen 328. Wenngleich drei Plattformen veranschaulicht sind, kann die Computerplattform 302A mit jeder geeigneten Anzahl von Plattformen verbunden sein. In verschiedenen Ausführungsformen kann sich eine Plattform 302 auf einer Leiterplatte befinden, die in einem Gehäuse, einem Rack oder einer anderen geeigneten Struktur, die mehrere durch das Netzwerk 308 miteinander gekoppelte Plattformen umfasst (was z. B. einen Rack- oder Backplane-Switch umfassen kann), installiert ist.
  • Die CPUs 312 können jeweils jede geeignete Anzahl von Prozessorkernen und Unterstützungslogik (z. B. Uncores) umfassen. Die Kerne können durch einen oder mehrere Controller auf der CPU 312 und/oder dem Chipsatz 316 aneinander, an den Arbeitsspeicher 314, an zumindest einen Chipsatz 316 und/oder an eine Kommunikationsschnittstelle 318 gekoppelt sein. In besonderen Ausführungsformen ist eine CPU 312 in einem Sockel ausgeführt, der dauerhaft oder entfernbar an die Plattform 302A gekoppelt ist. Wenngleich vier CPUs gezeigt sind, kann eine Plattform 302 jede geeignete Anzahl von CPUs einschließen.
  • Der Arbeitsspeicher 314 kann jede Form von flüchtigem oder nichtflüchtigem Arbeitsspeicher umfassen, einschließlich unter anderem magnetischer Medien (z. B. ein oder mehrere Bandlaufwerke), optischer Medien, Arbeitsspeicher mit wahlfreiem Zugriff (Random Access Memory, RAM), Festwertspeicher (Read-Only Memory, ROM), Flash-Arbeitsspeicher, Wechselmedien oder aller anderen geeigneten lokalen oder entfernten Speicherkomponenten. Der Arbeitsspeicher 314 kann zur kurz-, mittel- und/oder langfristigen Speicherung durch die Plattform 302A verwendet werden. Der Arbeitsspeicher 314 kann alle geeigneten Daten oder Informationen speichern, die durch die Plattformlogik 310 genutzt werden, einschließlich Software, die in ein computerlesbares Medium eingebettet ist, und/oder codierter Logik, die in Hardware integriert oder auf andere Weise gespeichert ist (z. B. Firmware). Der Arbeitsspeicher 314 kann Daten speichern, die durch Kerne der CPUs 312 verwendet werden. In einigen Ausführungsformen kann der Arbeitsspeicher 314 auch Speicher für Befehle umfassen, die durch die Kerne der CPUs 312 oder andere Verarbeitungselemente (z. B. Logik auf den Chipsätzen 316) ausgeführt werden, um Funktionalität in Verbindung mit der Manageability Engine 326 oder anderen Komponenten der Plattformlogik 310 bereitzustellen. Eine Plattform 302 kann auch einen oder mehrere Chipsätze 316 einschließen, die jede geeignete Logik zum Unterstützen des Betriebs der CPUs 312 umfassen. In verschiedenen Ausführungsformen kann sich der Chipsatz 316 auf demselben Die oder Gehäuse wie eine CPU 312 oder auf einem oder mehreren verschiedenen Dies oder Gehäusen befinden. Jeder Chipsatz kann jede geeignete Anzahl von CPUs 312 unterstützen. Ein Chipsatz 316 kann auch einen oder mehrere Controller einschließen, um andere Komponenten der Plattformlogik 310 (z. B. die Kommunikationsschnittstelle 318 oder den Arbeitsspeicher 314) an eine oder mehrere CPUs zu koppeln. In der dargestellten Ausführungsform schließt jeder Chipsatz 316 auch eine Manageability Engine 326 ein. Die Manageability Engine 326 kann jede geeignete Logik einschließen, um den Betrieb des Chipsatzes 316 zu unterstützen. In einer bestimmten Ausführungsform ist eine Manageability Engine 326 (die auch als eine Innovations-Engine bezeichnet werden kann) dazu in der Lage, Echtzeittelemetriedaten von dem Chipsatz 316, den CPU(s) 312 und/oder dem durch den Chipsatz 316 verwalteten Arbeitsspeicher 314, anderen Komponenten der Plattformlogik 310 und/oder verschiedenen Verbindungen zwischen Komponenten der Plattformlogik 310 zu erfassen. In verschiedenen Ausführungsformen schließen die erfassten Telemetriedaten die hierin beschriebenen Belastungsinformationen ein.
  • In verschiedenen Ausführungsformen wirkt eine Manageability Engine 326 als ein asynchroner Out-of-Band-Rechenagent, der dazu in der Lage ist, mit den verschiedenen Elementen der Plattformlogik 310 verbunden zu werden, um Telemetriedaten ohne oder mit nur minimaler Störung ausgeführter Prozesse auf den CPUs 312 zu erfassen. Zum Beispiel kann die Manageability Engine 326 ein dediziertes Verarbeitungselement (z. B. einen Prozessor, einen Controller oder andere Logik) auf dem Chipsatz 316 umfassen, das die Funktionalität der Manageability Engine 326 bereitstellt (z. B. durch Ausführen von Softwarebefehlen), wodurch Verarbeitungszyklen der CPUs 312 für Operationen in Verbindung mit den durch die Plattformlogik 310 durchgeführten Arbeitslasten gespart werden. Darüber hinaus kann die dedizierte Logik für die Manageability Engine 326 in Bezug auf die CPUs 312 asynchron arbeiten und kann zumindest einige der Telemetriedaten erfassen, ohne die Last auf den CPUs zu erhöhen.
  • Eine Manageability Engine 326 kann von ihr erfasste Telemetriedaten verarbeiten (spezifische Beispiele für das Verarbeiten von Belastungsinformationen werden hierin bereitgestellt). In verschiedenen Ausführungsformen berichtet die Manageability Engine 326 die von ihr erfassten Daten und/oder die Ergebnisse ihrer Verarbeitung an andere Elemente in dem Computersystem, wie einen oder mehrere Hypervisor 320 oder andere Betriebssysteme und/oder Systemverwaltungssoftware (die auf jeder geeigneten Logik, wie der Systemverwaltungsplattform 306, ausgeführt werden kann). In besonderen Ausführungsformen kann ein kritisches Ereignis, wie ein Kern, der eine zu hohe Menge an Belastung akkumuliert hat, vor dem normalen Intervall für das Berichten von Telemetriedaten berichtet werden (z. B. kann eine Benachrichtigung unmittelbar nach dem Erkennen gesendet werden).
  • Außerdem kann die Manageability Engine 326 programmierbaren Code einschließen, der konfigurierbar ist, um festzulegen, welche CPU(s) 312 ein bestimmter Chipsatz 316 verwaltet und/oder welche Telemetriedaten erfasst werden.
  • Die Chipsätze 316 schließen jeweils auch eine Kommunikationsschnittstelle 328 ein. Die Kommunikationsschnittstelle 328 kann zur Kommunikation von Signalen und/oder Daten zwischen dem Chipsatz 316 und einer oder mehreren E/A-Vorrichtungen, einem oder mehreren Netzwerken 308 und/oder einer oder mehreren an das Netzwerk 308 gekoppelten Vorrichtungen (z. B. der Systemverwaltungsplattform 306) verwendet werden. Zum Beispiel kann die Kommunikationsschnittstelle 328 verwendet werden, um Netzwerkverkehr, wie Datenpakete, zu senden und zu empfangen. In einer bestimmten Ausführungsform umfasst eine Kommunikationsschnittstelle 328 einen oder mehrere physische Netzwerkschnittstellen-Controller (Network Interface Controllers, NICs), auch als Netzwerkschnittstellenkarten oder Netzwerkadapter bekannt. Ein NIC kann eine elektronische Schaltung einschließen, um unter Verwendung jedes geeigneten Standards der Bitübertragungsschicht und Sicherungsschicht, wie Ethernet (wie z. B. durch einen IEEE 802.3-Standard definiert), Fibre Channel, InfiniBand, Wi-Fi, oder eines anderen geeigneten Standards zu kommunizieren. Ein NIC kann einen oder mehrere physische Ports einschließen, die an ein Kabel (z. B. ein Ethernetkabel) koppeln können. Ein NIC kann die Kommunikation zwischen jedem geeigneten Element des Chipsatzes 316 (z. B. der Manageability Engine 326 oder dem Switch 330) und einer anderen an das Netzwerk 308 gekoppelten Vorrichtung ermöglichen. In verschiedenen Ausführungsformen kann ein NIC mit dem Chipsatz verbunden sein (d. h., er kann sich auf derselben integrierten Schaltung oder Leiterplatte wie der Rest der Chipsatzlogik befinden) oder kann sich auf einer verschiedenen integrierten Schaltung oder Leiterplatte befinden, die elektromechanisch an den Chipsatz gekoppelt ist.
  • In besonderen Ausführungsformen können die Kommunikationsschnittstellen 328 die Kommunikation von Daten (z. B. zwischen der Manageability Engine 326 und der Datencenterverwaltungsplattform 306) in Verbindung mit durch die Manageability Engine 326 durchgeführten Verwaltungs- und Überwachungsfunktionen ermöglichen. In verschiedenen Ausführungsformen kann die Manageability Engine 326 Elemente (z. B. einen oder mehrere NICs) der Kommunikationsschnittstellen 328 nutzen, um die Telemetriedaten (z. B. an die Systemverwaltungsplattform 306) zu berichten, um die Nutzung von NICS der Kommunikationsschnittstelle 318 für Operationen in Verbindung mit durch die Plattformlogik 310 durchgeführten Arbeitslasten zu reservieren.
  • Die Switche 330 können an verschiedene (z. B. durch NICs bereitgestellte) Ports der Kommunikationsschnittstelle 328 koppeln und können Daten zwischen diesen Ports und verschiedenen Komponenten des Chipsatzes 316 (z. B. einer oder mehreren an die CPUs 312 gekoppelten Peripheral Component Interconnect Express(PCIe)-Lanes) umschalten. Die Switche 330 können ein physischer oder virtueller (d. h. Software-) Switch sein.
  • Die Plattformlogik 310 kann eine zusätzliche Kommunikationsschnittstelle 318 einschließen. Vergleichbar mit den Kommunikationsschnittstellen 328 können die Kommunikationsschnittstellen 318 zur Kommunikation von Signalen und/oder Daten zwischen der Plattformlogik 310 und einem oder mehreren Netzwerken 308 und einer oder mehreren an das Netzwerk 308 gekoppelten Vorrichtungen verwendet werden. Zum Beispiel kann die Kommunikationsschnittstelle 318 verwendet werden, um Netzwerkverkehr, wie Datenpakete, zu senden und zu empfangen. In einer bestimmten Ausführungsform umfassen die Kommunikationsschnittstellen 318 einen oder mehrere physische NICs. Diese NICs können die Kommunikation zwischen jedem geeigneten Element der Plattformlogik 310 (z. B. den CPUs 312 oder dem Arbeitsspeicher 314) und einer anderen an das Netzwerk 308 gekoppelten Vorrichtung (z. B. Elementen von anderen Plattformen oder entfernten Rechenvorrichtungen, die durch ein oder mehrere Netzwerke an das Netzwerk 308 gekoppelt sind) ermöglichen.
  • Die Plattformlogik 310 kann alle geeigneten Typen von Arbeitslasten empfangen und durchführen. Eine Arbeitslast kann jede Anforderung zur Nutzung von einer oder mehreren Ressourcen der Plattformlogik 310, wie einem oder mehreren Kernen oder zugehöriger Logik, einschließen. Zum Beispiel kann eine Arbeitslast eine Anforderung zum Instanziieren einer Softwarekomponente, wie eines E/A-Vorrichtungs-Treibers 324 oder Gastsystems 322; eine Anforderung zum Verarbeiten eines von einer virtuellen Maschine 332 oder einer Vorrichtung außerhalb der Plattform 302A (wie eines an das Netzwerk 308 gekoppelten Netzwerkknotens) empfangenen Netzwerkpakets; eine Anforderung zum Ausführen eines Verfahrens oder Threads in Verbindung mit einem Gastsystem 322, einer auf der Plattform 302A ausgeführten Anwendung, eines Hypervisor 320 oder eines anderen auf der Plattform 302A ausgeführten Betriebssystems oder eine andere geeignete Verarbeitungsanforderung umfassen.
  • Eine virtuelle Maschine 332 kann ein Computersystem mit ihrer eigenen dedizierten Hardware emulieren. Eine virtuelle Maschine 332 kann ein Gastbetriebssystem auf dem Hypervisor 320 ausführen. Die Komponenten der Plattformlogik 310 (z. B. die CPUs 312, der Arbeitsspeicher 314, der Chipsatz 316 und die Kommunikationsschnittstelle 318) können derart virtualisiert sein, dass es dem Gastbetriebssystem scheint, dass die virtuelle Maschine 332 ihre eigenen dedizierten Komponenten aufweist.
  • Eine virtuelle Maschine 332 kann einen virtualisierten NIC (vNIC) einschließen, der durch die virtuelle Maschine als ihre Netzwerkschnittstelle verwendet wird. Einem vNIC kann eine Medienzugriffssteuerungs(Media Access Control, MAC)-Adresse oder ein anderer Identifikator zugewiesen werden, wodurch es ermöglicht wird, dass mehrere virtuelle Maschinen 332 in einem Netzwerk einzeln adressierbar sind.
  • Eine VNF 334 kann eine Softwareimplementierung eines Funktionsblocks mit definierten Schnittstellen und Verhalten umfassen, die in einer virtualisierten Infrastruktur bereitgestellt werden können. In besonderen Ausführungsformen kann eine VNF 334 eine oder mehrere virtuelle Maschinen 332 einschließen, die zusammen spezifische Funktionalitäten bereitstellen (z. B. Optimierung des Weitverkehrsnetzwerks (Wide Area Network, WAN), Abschluss eines virtuellen privaten Netzwerks (VPN), Firewall-Operationen, Lastausgleichsoperationen, Sicherheitsfunktionen usw.). Eine VNF 334, die auf der Plattformlogik 310 ausgeführt wird, kann dieselbe Funktionalität wie herkömmliche Netzwerkkomponenten bereitstellen, die durch dedizierte Hardware implementiert werden. Zum Beispiel kann eine VNF 334 Komponenten zum Durchführen von allen geeigneten NFV-Arbeitslasten, wie virtualized Evolved Packet Core(vEPC)-Komponenten, Mobilitätsverwaltungsentitäten, 3rd Generation Partnership Project(3GPP)-Steuer- und Datenebenenkomponenten usw., einschließen.
  • SFC 336 ist eine Gruppe von VNFs 334, die als eine Kette organisiert sind, um eine Reihe von Operationen, wie Netzwerkpaketverarbeitungsoperationen, durchzuführen. Die Dienstfunktionsverkettung kann die Fähigkeit bereitstellen, eine geordnete Liste von Netzwerkdiensten (z. B. Firewalls, Lastverteiler) zu definieren, die im Netzwerk zusammengefügt werden, um eine Dienstkette zu erstellen.
  • Ein Hypervisor 320 (auch als Virtual Machine Monitor bekannt) kann Logik zum Erstellen und Ausführen von Gastsystemen 322 umfassen. Der Hypervisor 320 kann Gastbetriebssysteme präsentieren, die durch virtuelle Maschinen mit einer virtuellen Betriebsplattform ausgeführt werden (d. h., es scheint den virtuellen Maschinen, dass sie auf separaten physischen Knoten ausgeführt werden, während sie tatsächlich auf einer einzelnen Hardwareplattform konsolidiert sind), und die Ausführung des Gastbetriebssystems durch die Plattformlogik 310 verwalten. Dienste des Hypervisor 320 können durch eine Softwarevirtualisierung oder durch Hardware-unterstützte Ressourcen, die nur einen minimalen Softwareeingriff erfordern, oder durch beides bereitgestellt werden. Mehrere Instanzen einer Vielfalt von Gastbetriebssystemen können durch den Hypervisor 320 verwaltet werden. Jede Plattform 302 kann eine separate Instanziierung eines Hypervisor 320 aufweisen.
  • Der Hypervisor 320 kann ein nativer oder Bare-Metal-Hypervisor sein, der direkt auf der Plattformlogik 310 ausgeführt wird, um die Plattformlogik zu steuern und die Gastbetriebssysteme zu verwalten. Alternativ dazu kann der Hypervisor 320 ein gehosteter Hypervisor sein, der auf einem Host-Betriebssystem ausgeführt wird und die Gastbetriebssysteme von dem Host-Betriebssystem abstrahiert. Der Hypervisor 320 kann einen virtuellen Switch 338 einschließen, der virtuelle Schalt- und/oder Routing-Funktionen für virtuelle Maschinen der Gastsysteme 322 bereitstellen kann. Der virtuelle Switch 338 kann eine logische Schalt-Fabric umfassen, die die vNICs der virtuellen Maschinen 332 aneinander koppelt, wodurch ein virtuelles Netzwerk erstellt wird, durch das virtuelle Maschinen miteinander kommunizieren können.
  • Der virtuelle Switch 338 kann ein Softwareelement umfassen, das unter Verwendung von Komponenten der Plattformlogik 310 ausgeführt wird. In verschiedenen Ausführungsformen kann der Hypervisor 320 mit jeder geeigneten Entität (z. B. einem SDN-Controller) in Kommunikation stehen, die den Hypervisor 320 dazu veranlassen kann, die Parameter des virtuellen Switches 338 als Reaktion auf sich ändernde Bedingungen bei der Plattform 302 (z. B. die Hinzufügung oder Löschung von virtuellen Maschinen 332 oder die Identifikation von Optimierungen, die vorgenommen werden können, um die Leistung der Plattform zu verbessern) neu zu konfigurieren.
  • Der Hypervisor 320 kann auch eine Ressourcenzuordnungslogik 344 einschließen, die Logik zum Bestimmen der Zuordnung von Plattformressourcen basierend auf den Telemetriedaten (die Belastungsinformationen einschließen können) einschließen kann. Die Ressourcenzuordnungslogik 344 kann auch Logik zum Kommunizieren mit verschiedenen Komponenten der Plattformlogik 310 von Entitäten von Plattform 302A einschließen, um eine solche Optimierung zu implementieren, wie Komponenten der Plattformlogik 310.
  • Jede geeignete Logik kann eine oder mehrere dieser Optimierungsentscheidungen treffen. Zum Beispiel kann die Systemverwaltungsplattform 306; die Ressourcenzuordnungslogik 344 des Hypervisor 320 oder eines anderen Betriebssystems oder eine andere Logik der Computerplattform 302A dazu in der Lage sein, solche Entscheidungen zu treffen. In verschiedenen Ausführungsformen kann die Systemverwaltungsplattform 306 Telemetriedaten von mehreren Plattformen 302 empfangen und die Arbeitslastplatzierung über diese hinweg verwalten. Die Systemverwaltungsplattform 306 kann mit den Hypervisor 320 (z. B. in einer Out-of-Band-Weise) oder anderen Betriebssystemen der verschiedenen Plattformen 302 kommunizieren, um durch die Systemverwaltungsplattform angewiesene Arbeitslastplatzierungen zu implementieren.
  • Die Elemente der Plattformlogik 310 können auf jede geeignete Weise miteinander gekoppelt werden. Zum Beispiel kann ein Bus beliebige der Komponenten miteinander koppeln. Ein Bus kann jede bekannte Verschaltung, wie einen Multi-Drop-Bus, eine Maschenverschaltung, eine Ringverschaltung, eine Punkt-zu-Punkt-Verschaltung, eine serielle Verschaltung, einen parallelen Bus, einen kohärenten (z. B. Cache-kohärenten) Bus, eine geschichtete Protokollarchitektur, einen differenziellen Bus oder einen Gunning Transceiver Logic(GTL)-Bus, einschließen.
  • Elemente der Computerplattform 302A können auf jede geeignete Weise, wie durch ein oder mehrere Netzwerke 308, miteinander gekoppelt werden. Ein Netzwerk 308 kann jedes geeignete Netzwerk oder jede Kombination von einem oder mehreren Netzwerken, die unter Verwendung von einem oder mehreren geeigneten Netzwerkprotokollen betrieben werden, sein. Ein Netzwerk kann eine Reihe von Knoten, Punkten und miteinander verbundenen Kommunikationspfaden zum Empfangen und Übertragen von Paketen von Informationen, die durch ein Kommunikationssystem verbreitet werden, darstellen. Zum Beispiel kann ein Netzwerk eine/n oder mehrere Firewalls, Router, Switche, Sicherheitseinrichtungen, Antivirusserver oder andere nützliche Netzwerkvorrichtungen einschließen.
  • 4 ist ein Blockdiagramm eines KI-Systems mit zwei Plattformen, nämlich Plattform 440-1 und Plattform 440-2.
  • Jede Plattform 440 schließt zum Beispiel einen oder mehrere Prozessoren 428 ein, die über eine lokale Verschaltungstechnologie, wie Intel® QuickPath Interconnect (QPI) oder Ähnliches, miteinander verbunden sein können. Zum Beispiel schließt die Plattform 440-1 einen Prozessor 428-1 und einen Prozessor 428-2 ein, die über eine QPI-Verschaltung verbunden sind. Jeder Prozessor 428 kann außerdem Zugriff auf seine eigenen lokalen Ressourcen 432 haben. Zum Beispiel hat der Prozessor 428-1 Zugriff auf die lokalen Ressourcen 432-1 und hat der Prozessor 428-2 Zugriff auf die lokalen Ressourcen 432-2. Die lokalen Ressourcen 432 können zum Beispiel eine Netzwerkschnittstellenkarte, eine Host-Fabric-Schnittstelle, Arbeitsspeicher, Speicher oder Ähnliches einschließen. Es sei darauf hingewiesen, dass in dieser Darstellung jeder Prozessor 428 so gezeigt ist, dass er Zugriff auf seine eigenen lokalen Ressourcen hat, aber es sei klargestellt, dass eine oder mehrere lokale Ressourcen 432 von den Prozessoren 428 geteilt werden können. Die Zuordnung von lokalen Ressourcen als dedizierte lokale Ressourcen zu einem Prozessor oder von geteilten lokalen Ressourcen zwischen mehreren Prozessoren zählt zu den technischen Aufgaben eines Fachmanns.
  • In diesem Beispiel schließt die Plattform 440-1 auch einen Beschleuniger 418-1 und einen Beschleuniger 418-2 ein. Es sei darauf hingewiesen, dass in diesem Beispiel jeder Prozessor 428 seinen eigenen dedizierten Beschleuniger 418 einschließt. Zum Beispiel weist der Prozessor 428-1 den dedizierten Beschleuniger 418-1 auf, während der Prozessor 428-2 den dedizierten Beschleuniger 418-2 einschließt. Die Prozessoren 428 können über eine bekannte Verschaltung, wie PCIe, miteinander verbunden sein. Es sei darauf hingewiesen, dass PCIe keine Cache-kohärente oder arbeitsspeicherkohärente Verschaltung ist. Mit anderen Worten kann der Beschleuniger 418 in bestimmten bestehenden Implementierungen von PCIe seinen lokalen Arbeitsspeicherplatz nicht direkt auf den Arbeitsspeicherplatz des Prozessors 428 abbilden. Um Daten zwischen dem Beschleuniger 418 und dem Prozessor 428 auszutauschen, muss daher möglicherweise eine CPU die PCIe-Verschaltung betreiben, um Daten hin- und herzuschieben.
  • Jeder Beschleuniger 418 kann als nicht einschränkendes Beispiel eine Beschleunigerhardware 420, eine ICL-Schnittstelle 416, einen Systemdecoder 412, einen Fabric-ICL 404 und einen Plattform-ICL 408 einschließen. Die Beschleunigerhardware 420 kann zum Beispiel eine FPGA oder eine GPU sein und kann mit einem Deep Learning-Modell programmiert sein. Wie in dieser Beschreibung verwendet, kann eine zum Durchführen einer Trainingsaufgabe programmierte Beschleunigerhardware als ein „Deep Learning-Modul“ bezeichnet werden, was so verstanden werden kann, dass es sowohl die Hardware, die die Verarbeitungsleistung bereitstellt, als auch das Programmieren, das der Beschleunigerhardware das Deep Learning-Modell bereitstellt, einschließt. Das Deep Learning-Modell kann über die Plattform 440-1 und die Plattform 440-2 hinweg identisch sein, wenn beide Plattformen an demselben KI-Problem arbeiten. Die Plattform 440-1 schließt auch einen Plattformsteuerungs-Host (Platform Control Host, PCH) 424-1 ein, der eine Plattformsteuerung zwischen dem Beschleuniger 418-1 und dem Beschleuniger 418-2 bereitstellt.
  • Es sei darauf hingewiesen, dass die Plattform 440-2 mit der Plattform 440-1 im Wesentlichen vergleichbar und möglicherweise sogar identisch ist. Die Plattform 440-2 schließt die lokalen Ressourcen 432-3, die für den Prozessor 428-3 bereitgestellt werden, und die lokalen Ressourcen 432-4, die für den Prozessor 428-4 bereitgestellt werden, ein. Der Prozessor 428-3 und der Prozessor 428-4 können über eine lokale Verschaltung, wie QPI, kommunikativ gekoppelt sein. Die Prozessoren 428-3 und 428-4 weisen jeweils auch einen jeweiligen Beschleuniger auf, nämlich den Beschleuniger 418-3 und den Beschleuniger 418-4. Wie bei der Plattform 440-1 schließt die Plattform 440-2 einen PCH 424-2 ein.
  • Die Plattform 440-1 und die Plattform 440-2 können über eine schnelle Verschaltung, wie Intel Omni-Path, oder eine Hochgeschwindigkeits-Ethernet- oder jede andere geeignete Hochgeschwindigkeitsverschaltung aneinander gekoppelt sein. In bestehenden Systemen ist jedoch möglicherweise kein Mechanismus für eine direkte Kommunikation von Beschleunigern auf der Plattform 440-1 mit Beschleunigern auf der Plattform 440-2 vorhanden.
  • Ausführungsformen der vorliegenden Beschreibung stellen den Systemdecoder 412, wie den Systemdecoder 412-1 des Beschleunigers 418-1, den Systemdecoder 412-2 des Beschleunigers 418-2, den Systemdecoder 412-3 des Beschleunigers 418-3 und den Systemdecoder 412-4 des Beschleunigers 418-4 bereit. Die Systemdecoder 412 werden bereitgestellt, um Daten von einer Trainingsmodellinstanz zu einer anderen weiterzuleiten. Mit anderen Worten definiert der Systemdecoder 412 Pfade zwischen den verschiedenen Beschleunigern 418 und leitet Daten durch diese weiter, sobald sie in einer Vorrichtung ankommen.
  • Wenn ein Trainingsmodell in der Beschleunigerhardware 420 eines Beschleunigers 418 gestartet wird, werden neue Trainingsinstanzen in den verschiedenen Beschleunigern 418 erstellt. Der Systemdecoder 412 jedes Beschleunigers 418 kann mit den erforderlichen Informationen darüber programmiert werden, welches Modell auf welchem Beschleuniger 418 geplant ist. Somit weiß jeder Systemdecoder 412, welche Modelle auf welcher Hardwarevorrichtung ausgeführt werden, sodass er Routing-Entscheidungen treffen kann. Der Systemdecoder 412 kann zum Beispiel auch eine kleine Tabelle verwenden, um Suchen durchzuführen. Er kann auch eine Tabelle in Systemspeicher oder einem Abschnitt davon, der für ihn zugänglich ist, führen. Der Systemdecoder kann auch Routing-Informationen als Header-Daten auf einem Paket platzieren, um sicherzustellen, dass Systemdecoder auf anderen Beschleunigern 418 die Daten auf geeignete Weise weiterleiten.
  • Der Plattform-ICL 408 implementiert ein Verbindungsprotokoll zwischen verschiedenen Beschleunigervorrichtungen innerhalb derselben Plattform. Dies kann ohne das Erfordernis eines Kommunizierens über die Datencenter-Fabric erreicht werden. Wenn zum Beispiel der Plattform-ICL 408-1 betrieben wird, kann der Beschleuniger 418-1 über den Plattform-ICL 408-2 direkt mit dem Beschleuniger 418-2 kommunizieren. Der Beschleuniger 418-1 kann jedoch nicht dazu in der Lage sein, über den Plattform-ICL 408 direkt mit dem Beschleuniger 418-3 oder dem Beschleuniger 418-4 zu kommunizieren. Der Systemdecoder 412 kann die Plattform-ICLs 408 betreiben, wenn Daten zu einer bestimmten Modelltrainingsinstanz von einem Beschleuniger zu einem anderen innerhalb desselben Gehäuses oder derselben Kapsel, in diesem Fall innerhalb der Plattform 440-1 oder innerhalb der Plattform 440-2, verschoben werden.
  • Der Fabric-ICL 404 stellt eine Kommunikation zwischen den Beschleunigern 418 auf verschiedenen Plattformen 440 bereit. Der Fabric-ICL 404 kann zum Beispiel eine FPGA oder andere beschleunigte Hardware sein. Der Fabric-ICL 404 wird durch den Systemdecoder 412 verwendet und implementiert das Protokoll zur Verwendung bei einer Kommunikation zwischen Beschleunigungsvorrichtungen, die in verschiedenen Plattformen 440 gehostet werden. In 4 wird der Fabric-ICL 404 zum Beispiel in einem Rechenvorgang betrieben, der in dem Beschleuniger 418-1 auf der Plattform 440-1 erfolgen muss, wobei Daten zu dem Beschleuniger 418-4 auf der Plattform 440-2 gesendet werden. Da die tatsächliche Kommunikation über die plattformübergreifende Fabric erfolgt, die auch durch die CPU und andere Plattformkomponenten verwendet wird, kann das Kommunikationsprotokoll für über die Fabric geführte Kommunikationen zwischen den Beschleunigern 418 in programmierbarer Logik, wie einer FPGA, implementiert werden. Der Fabric-ICL 404 kann ein Tunneln von Paketen bereitstellen, die für andere Beschleuniger 418 auf verschiedenen Plattformen 440 vorgesehen sind.
  • Es sei darauf hingewiesen, dass die tatsächliche Reihenfolge von Kommunikationen auf den jeweiligen Konfigurationsdaten basieren kann. Zum Beispiel kommunizieren die Beschleuniger 418 in einigen bestehenden Systemen in einem Rundlauf-Verfahren (Round-Robin), wobei in diesem Fall, wenn mehrere Beschleuniger 418 auf einer Plattform 440 vorhanden sind, ein Beschleuniger 418 durch den Systemdecoder 412 als eine „Gateway“-Vorrichtung für andere Beschleuniger auf der Plattform 440 bestimmt werden kann. Es sei darauf hingewiesen, dass in dieser Darstellung der Einfachheit halber nur zwei Prozessoren 428 mit jeweils einem Beschleuniger 418 auf jeder Plattform 440 gezeigt sind. In realen Bereitstellungen können jedoch viele Prozessoren mit vielen Beschleunigern vorhanden sein, sodass Kommunikationen komplizierter sein können.
  • In einem Beispiel kann der Beschleuniger 418-2 Daten erzeugen, die zu dem Beschleuniger 418-4 weitergeleitet werden müssen. In diesem Fall können die Beschleuniger 418-1 und 418-3 als die „Gateway“-Vorrichtungen für ihre jeweiligen Plattformen 440 bestimmt werden. Daher betreibt der Systemdecoder 412-2 seinen Fabric-ICL 404-2 nicht, um direkt mit dem Fabric-ICL 404-4 des Beschleunigers 418-4 zu kommunizieren. Stattdessen kann der Systemdecoder 412-2 zuerst den Plattform-ICL 408-2 betreiben, um die Daten über den Plattform-ICL 408-1 zu dem Beschleuniger 418-1 weiterzuleiten. Der Systemdecoder 412-1 kann dann den Fabric-ICL 404-1 betreiben, um die Daten zu dem Fabric-ICL 404-3 des Beschleunigers 418-3 weiterzuleiten. Der Systemdecoder 412-3 betreibt dann den Plattform-ICL 408-3, um die Daten über den Plattform-ICL 418-4 zu dem Beschleuniger 418-4 weiterzuleiten.
  • 5 ist ein Blockdiagramm eines Systemdecoders 512 gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung. Wie in Verbindung mit 4 angegeben, kann ein Fabric-ICL, wie der in dieser Darstellung offenbarte Fabric-ICL 504, eine FPGA oder eine andere programmierbare Logik, wie eine GPU, ein DSP, ein Coprozessor oder eine andere programmierbare Logikvorrichtung, sein. Wenn das System gestartet wird, kann der Systemdecoder 512 die geeignete Rolle für den Fabric-ICL 504 im System bestimmen. Daher muss der Systemdecoder 512 den Fabric-ICL 504 möglicherweise mit den geeigneten Routing-Tabellen, dem Verhalten und anderen Informationen programmieren, um das vorgegebene Routing-Protokoll auszuführen. Dies kann als nicht einschränkendes Beispiel zum Beispiel ein Bestimmen von bestimmten Routen für Sendeverkehr oder Punkt-zu-Punkt-Verkehr einschließen. Wie in Verbindung mit 4 erörtert, kann im Fall von Sendeverkehr ein Fabric-ICL 504 auf der Plattform als die Gateway-Vorrichtung für alle Beschleuniger auf der Plattform bestimmt werden. Im Fall von Punkt-zu-Punkt-Kommunikationen kann jeder Fabric-ICL 504 auf einem bestimmten Beschleuniger über die Netzwerk Fabric mit anderen Fabric-ICLs verbunden werden. Die Fabric-ICLs 504 können auch in einer Rundlauf- (Round-Robin-) oder Maschennetzkonfiguration oder einer beliebigen anderen Konfiguration, die für die Anforderungen einer bestimmten Bereitstellung geeignet ist, miteinander verbunden werden. Somit kann der Fabric-ICL 504 in vielen Fällen von der Flexibilität profitieren, an die spezifische Netzwerkkonfiguration anpassbar zu sein. Des Weiteren muss der Fabric-ICL 504 möglicherweise dazu in der Lage sein, sich an sich ändernde Netzwerkbedingungen anzupassen. Zum Beispiel kann der Fabric-ICL 504 auf einer bestimmten Plattform, der in Fällen, in denen ein einzelner Fabric-ICL als das Gateway bestimmt ist, als ein Gateway verwendet wird, je nach Netzwerkverkehrsbedingungen dynamisch zugeordnet werden. Zum Beispiel kann der Systemdecoder 512 die Netzwerkkosten in Verbindung mit dem Verwenden verschiedener Fabric-ICLs 504 als die Gateway-Vorrichtung berechnen oder kann die Netzwerkkosten für das Verwenden einer Gateway-Vorrichtung gegenüber dem Verwenden von Punkt-zu-Punkt- oder Maschenverbindungen vergleichen.
  • Der Systemdecoder 512 kann Zugriff auf ein oder mehrere greifbare, nicht-flüchtige computerlesbare Medien 508 haben, auf denen durch einen Computer betreibbare Befehle zum Ausführen der hierin offenbarten Verfahren gespeichert sein können. Dies kann als nicht einschränkendes Beispiel ausführbare Softwarebefehle zur Ausführung auf einer GPU, einer CPU, einem DSP oder einer anderen programmierbaren Logikvorrichtung einschließen. Dies kann auch Befehle zum Programmieren einer FPGA mit den geeigneten Routing-Informationen einschließen. In einigen Beispielen kann dies auch Befehle oder Masken zum Programmieren einer ASIC mit dem geeigneten Routing einschließen.
  • Somit kann der Systemdecoder 512 oder ein anderes durch die Ausführungsform vorgegebenes geeignetes System beim Systemstart oder zu einer anderen geeigneten Zeit auf das nicht-flüchtige computerlesbare Medium 508 zugreifen und kann darauf gespeicherte Informationen verwenden, um den Fabric-ICL 504 mit der geeigneten Routing-Konfiguration zu programmieren. Es sei darauf hingewiesen, dass das nicht-flüchtige computerlesbare Medium 508 eine Anzahl von Standardkonfigurationen einschließen kann, aus denen der Systemdecoder 512 die geeignete Konfiguration für die vorliegenden Netzwerkanforderungen auswählen kann, oder es kann kompliziertere Algorithmen für das Entwickeln einer hochspezialisierten Konfiguration für die bestimmte Netzwerkanforderung einschließen.
  • 6 ist ein Signalflussdiagramm, das eine beispielhafte Broadcast-Nachricht veranschaulicht, gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung. In diesem Beispiel sind vier Beschleunigervorrichtungen veranschaulicht, nämlich Vorrichtung 610-1, Vorrichtung 610-2, Vorrichtung 610-3 und Vorrichtung 610-4. Die Vorrichtung 610-1 und die Vorrichtung 610-2 werden beide auf der Plattform 612-1 gehostet. Die Vorrichtung 610-3 und 610-4 werden beide auf der Plattform 612-2 gehostet.
  • In dieser veranschaulichenden Ausführungsform ist der Fabric-ICL 604-1 als der Gateway-Fabric-ICL für die Plattform 612-1 für Sendezwecke bestimmt. Der Fabric-ICL 604-2 ist als der Gateway-Fabric-ICL für die Plattform 612-2 für Sendezwecke bestimmt.
  • Die Vorrichtung 610-1 kann eine Information berechnen, die zu einigen oder allen Beschleunigern im System gesendet werden soll. Zu Zwecken dieser Veranschaulichung soll die durch die Vorrichtung 610-1 berechnete Information zumindest zu der Vorrichtung 610-2, der Vorrichtung 610-3 und der Vorrichtung 610-4 gesendet werden. Es sei jedoch darauf hingewiesen, dass es erforderlich sein kann, die Information zu anderen Vorrichtungen zu senden, und die veranschaulichte Ausführungsform ist als nicht einschränkend und nur veranschaulichend zu verstehen.
  • Bei Operation 1 kann der Systemdecoder der Vorrichtung 610-1 zuerst die Information an alle Vorrichtungen auf der Plattform 612-1 verteilen. Da der Systemdecoder der Vorrichtung 610-1 weiß, dass sein eigener Fabric-ICL nicht der Gateway-Fabric-ICL für Sendezwecke auf dieser Plattform ist, muss die Vorrichtung 610-1 keine weitere Aktion durchführen. Als Teil des Sendens der Information zu allen Vorrichtungen auf der Plattform 612-1 kommuniziert die Plattform-ICL 608-1 die Information an andere Plattform-ICLs auf der Plattform 612-1, einschließlich an den Plattform-ICL 608-2.
  • Bei Operation 2 bestimmt der Systemdecoder der Vorrichtung 610-2, dass der Fabric-ICL 604-1 der bestimmte Gateway-Fabric-ICL für Sendezwecke für die Plattform 612-1 ist. Daher überträgt der Plattform-ICL 608-2 die Information zu dem Fabric-ICL 604-1.
  • Bei Operation 3 verbraucht die Vorrichtung 610-2 die Information und führt alle Arbeiten durch, die an der Information durchgeführt werden müssen.
  • Bei Operation vier überträgt der Fabric-ICL 604-1 die Information zu dem Fabric-ICL 604-2 der Plattform 612-2, weil der Fabric-ICL 604-1 der bestimmte Gateway-Fabric-ICL für die Fabric 612-1 ist. Es sei darauf hingewiesen, dass eine Anzahl von anderen Plattformen in dem KI-System vorhanden sein kann, und in diesem Fall kann der Fabric-ICL 604-1 die Information zu einer Vielzahl von Fabric-ICLs auf einer Vielzahl von Plattformen senden.
  • Bei Operation 5 überträgt der Fabric-ICL 604-2 der Vorrichtung 610-3 die Information zu dem Plattform-ICL 608-3 der Vorrichtung 610-3.
  • Bei Operation 6 identifiziert der Plattform-ICL 608-3 der Vorrichtung 610-3 die Information als eine Information, die zu anderen Vorrichtungen 610 auf der Plattform 612-2 übertragen werden soll. Daher überträgt der Plattform-ICL 608-3 die Information zu dem Plattform-ICL 608-4 der Vorrichtung 610-4. Der Plattform-ICL 608-3 kann die Information auch zu anderen Plattform-ICLs 608 von anderen Vorrichtungen 610 auf der Plattform 612-2 senden.
  • Bei Operation 7 verbraucht die Vorrichtung 610-3 die Information und führt alle Arbeiten durch, die an der Information durchgeführt werden müssen.
  • Bei Operation 8 verbraucht auch die Vorrichtung 610-4 die Information und führt alle Arbeiten durch, die an der Information durchgeführt werden müssen.
  • 7 ist ein Flussdiagramm eines durch einen Systemdecoder oder eine andere geeignete Vorrichtung durchgeführten Verfahrens 700 gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung.
  • In Block 702 wird die Beschleunigervorrichtung, die den Systemdecoder hostet, gestartet.
  • In Block 704 bestimmt der Systemdecoder die erforderliche Routing-Konfiguration für die Plattform und die Vorrichtung. Dies kann jede geeignete Routing-Konfiguration, wie eine Maschen-, Punkt-zu-Punkt-Verbindungs-, Rundlauf- (Round-Robin-), Sende- oder andere geeignete Netzwerkkonfiguration, einschließen. Der Systemdecoder kann mit anderen Systemdecodern auf der Plattform zusammenwirken und kommunizieren, um in Fällen, in denen ein Gateway bestimmt werden muss, einen Gateway-Plattform-ICL „auszuwählen“. Die Auswahl eines Gateway-Plattform-ICL kann nach einem der bekannten Verfahren zum Auswählen eines Gateway oder einer Hauptvorrichtung durchgeführt werden.
  • In Block 708 konfiguriert der Systemdecoder den Fabric-ICL gemäß der in Block 704 bestimmten Routing-Konfiguration. In einigen Beispielen kann dies ein Lesen von Daten von einem wie in 5 veranschaulichten nichtflüchtigen computerlesbaren Medium und ein entsprechende Programmieren des Fabric-ICL einschließen. Dies kann ein Programmieren einer FPGA oder ein Laden von Software zum Ausführen zum Beispiel auf einem Coprozessor oder einer GPU einschließen.
  • In Block 712 bestimmt der Fabric-ICL, dass in Block 28 Daten zur Verwendung durch diesen Fabric-ICL verfügbar sind. Daher sendet der Fabric-ICL in Block 712 die Daten gemäß der konfigurierten Routing-Konfiguration. Dies kann ein Senden der Daten zu allen Fabric-ICLs auf allen Plattformen im System einschließen, oder es kann ein Übertragen der Daten nur zu einem Fabric-ICL auf einer anderen Vorrichtung oder Plattform einschließen.
  • In ähnlicher Weise bestimmt der Fabric-ICL in Block 716, dass eingehende Daten 724 vorhanden sind. Diese Daten können von anderen Vorrichtungen oder Plattformen im System eingehen. Daher leitet der Fabric-ICL die Daten in Block 716 gemäß der Routing-Konfiguration weiter. Dies kann ein Übertragen der Daten zu dem für den Fabric-ICL lokalen Plattform-ICL und/oder ein Anweisen des Plattform-ICL zum Übertragen der Daten zu einer oder mehreren anderen Vorrichtungen auf der Plattform über den Plattform-ICL einschließen.
  • In Block 798 wird das Verfahren abgeschlossen.
  • Das Vorstehende stellt Merkmale von einer oder mehreren Ausführungsformen des hierin offenbarten Gegenstands dar. Diese Ausführungsformen werden bereitgestellt, um es einem Durchschnittsfachmann zu ermöglichen, verschiedene Aspekte der vorliegenden Offenbarung besser zu verstehen. Auf bestimmte hinreichend bekannte Begriffe sowie zugrunde liegende Technologien und/oder Standards kann Bezug genommen werden, ohne dass diese ausführlich beschrieben werden. Es wird davon ausgegangen, dass der Durchschnittsfachmann über Hintergrundwissen oder -informationen in diesen Technologien und Standards, die ausreichend sind, um die Lehren der vorliegenden Beschreibung umzusetzen, verfügt oder hierauf Zugriff hat.
  • Der Durchschnittsfachmann wird erkennen, dass er die vorliegende Offenbarung leicht als Basis für das Entwickeln oder Ändern von anderen Prozessen, Strukturen oder Variationen zum Ausführen derselben Zwecke und/oder Erreichen derselben Vorteile der hierin eingeführten Ausführungsformen nutzen kann. Der Durchschnittsfachmann wird weiterhin erkennen, dass diese äquivalenten Konstruktionen nicht vom Wesen und Umfang der vorliegenden Offenbarung abweichen und dass er hieran verschiedene Änderungen, Ersetzungen und Modifikationen vornehmen kann, ohne vom Wesen und Umfang der vorliegenden Offenbarung abzuweichen.
  • In der vorstehenden Beschreibung sind bestimmte Aspekte von einigen oder allen Ausführungsformen ausführlicher beschrieben, als es für das Umsetzen der beigefügten Ansprüche zwingend erforderlich ist. Diese Details werden nur als nicht einschränkendes Beispiel zum Zweck des Bereitstellens von Kontext und zur Darstellung der offenbarten Ausführungsformen bereitgestellt. Diese Details dürfen nicht als erforderlich verstanden werden und dürfen nicht als Einschränkungen in die Ansprüche „hineingelesen“ werden. Der Ausdruck kann sich auf „eine Ausführungsform“ oder „Ausführungsformen“ beziehen. Diese Ausdrücke und alle anderen Bezugnahmen auf Ausführungsformen sind weit gefasst so zu verstehen, dass sie sich auf jede Kombination von einer oder mehreren Ausführungsformen beziehen. Des Weiteren können die in einer bestimmten „Ausführungsform“ offenbarten verschiedenen Merkmale ebenso gut über mehrere Ausführungsformen hinweg verteilt sein. Wenn zum Beispiel die Merkmale 1 und 2 in „einer Ausführungsform“ offenbart werden, kann die Ausführungsform A das Merkmal 1, jedoch nicht das Merkmal 2 aufweisen, während die Ausführungsform B das Merkmal 2, jedoch nicht das Merkmal 1 aufweisen kann.
  • Diese Beschreibung kann Veranschaulichungen in einem Blockdiagrammformat bereitstellen, wobei bestimmte Merkmale in separaten Blöcken offenbart werden. Diese sind weit gefasst so zu verstehen, dass sie offenbaren, wie verschiedene Merkmale zusammenwirken, aber sie sollen nicht implizieren, dass diese Merkmale zwingend in separater Hardware oder Software ausgeführt werden müssen. Wo des Weiteren ein einzelner Block mehr als ein Merkmal in demselben Block offenbart, müssen diese Merkmale nicht notwendigerweise in derselben Hardware und/oder Software ausgeführt sein. Zum Beispiel kann „Arbeitsspeicher“ eines Computers unter einigen Umständen zwischen mehreren Ebenen von Cache- oder lokalem Arbeitsspeicher, Hauptarbeitsspeicher, batteriegepuffertem flüchtigem Arbeitsspeicher und verschiedenen Formen von persistentem Arbeitsspeicher, wie einer Festplatte, einem Speicherserver, einer optischen Platte, einem Bandlaufwerk oder Ähnlichem, verteilt oder abgebildet sein.
  • In bestimmten Ausführungsformen können einige der Komponenten weggelassen oder konsolidiert sein. Allgemein können die in den Figuren dargestellten Anordnungen in ihren Darstellungen logischer sein, während eine physische Architektur verschiedene Umsetzungen, Kombinationen und/oder Mischformen dieser Elemente einschließen kann. Es können zahllose mögliche Ausführungskonfigurationen verwendet werden, um die hierin dargestellten operativen Ziele zu erreichen. Entsprechend weist die zugehörige Infrastruktur eine Vielzahl von Ersatzanordnungen, Ausführungsauswahlen, Vorrichtungsmöglichkeiten, Hardwarekonfigurationen, Softwareimplementierungen und Ausrüstungsoptionen auf.
  • Es kann hierin auf ein computerlesbares Medium Bezug genommen werden, das ein greifbares und nicht-flüchtiges computerlesbares Medium sein kann. Wie in dieser Beschreibung und über die gesamten Ansprüche hinweg verwendet, ist ein „computerlesbares Medium“ so zu verstehen, dass es ein oder mehrere computerlesbare Medien identischer oder verschiedener Typen einschließt. Ein computerlesbares Medium kann als ein nicht einschränkendes Beispiel ein optisches Laufwerk (z. B. CD/DVD/Blu-Ray), eine Festplatte, ein Festkörperlaufwerk, einen Flash-Arbeitsspeicher oder ein anderes nicht-flüchtiges Medium einschließen. Ein computerlesbares Medium kann auch ein Medium, wie einen Festwertspeicher (Read-Only Memory, ROM), eine FPGA oder eine ASIC, einschließen, die dazu konfiguriert sind, die gewünschten Befehle, gespeicherte Befehle zum Programmieren einer FPGA oder ASIC zum Ausführen der gewünschten Befehle, einen Block geistigen Eigentums (Intellectual Property, IP), der in Hardware in andere Schaltungen integriert sein kann, oder Befehle, die direkt in Hardware oder Mikrocode auf einem Prozessor, wie einem Mikroprozessor, Digitalsignalprozessor (DSP), Mikrocontroller, oder in jeder anderen geeigneten Komponente oder Vorrichtung oder jedem anderen geeigneten Element oder Objekt je nach Eignung und basierend auf bestimmten Anforderungen, codiert sind, auszuführen. Ein nicht-flüchtiges Speichermedium soll hierin ausdrücklich jede nicht-flüchtige Spezial- oder programmierbare Hardware einschließen, die dazu konfiguriert ist, die offenbarten Operationen bereitzustellen oder einen Prozessor dazu zu veranlassen, die offenbarten Operationen durchzuführen.
  • Verschiedene Elemente können über diese Beschreibung und die Ansprüche hinweg „kommunikativ“, „elektrisch“, „mechanisch“ oder auf andere Weise aneinander „gekoppelt“ sein. Dieses Koppeln kann ein direktes Punkt-zu-Punkt-Koppeln sein oder kann Zwischenvorrichtungen einschließen. Zum Beispiel können zwei Vorrichtungen über einen Controller, der die Kommunikation unterstützt, kommunikativ aneinander gekoppelt sein. Vorrichtungen können über Zwischenvorrichtungen, wie Signalverstärker, Spannungsteiler oder Puffer, elektrisch aneinander gekoppelt sein. Mechanisch gekoppelte Vorrichtungen können indirekt mechanisch gekoppelt sein.
  • Jedes hierin offenbarte „Modul“ oder jede hierin offenbarte „Engine“ kann sich auf Software, einen Softwarestapel, eine Kombination von Hardware, Firmware und/oder Software, eine Schaltung, die dazu konfiguriert ist, die Funktion der Engine oder des Moduls auszuführen, oder jedes wie weiter oben offenbarte computerlesbare Medium beziehen oder diese einschließen. Diese Module oder Engines können unter geeigneten Umständen auf oder in Verbindung mit einer Hardwareplattform bereitgestellt werden, die Hardwarerechenressourcen, wie einen Prozessor, Arbeitsspeicher, Speicher, Verschaltungen, Netzwerke und Netzwerkschnittstellen, Beschleuniger oder andere geeignete Hardware, einschließen kann. Eine solche Hardwareplattform kann als eine einzelne monolithische Vorrichtung (z. B. in einem PC-Formfaktor) oder mit einem Teil der Funktion verteilt (z. B. als ein „Verbundknoten“ in einem High-End-Datencenter, in dem Rechen-, Arbeitsspeicher-, Speicher- und andere Ressourcen dynamisch zugeordnet werden können und nicht lokal füreinander vorhanden sein müssen) bereitgestellt werden.
  • Es können hierin Flussdiagramme, Signalflussdiagramme oder andere Veranschaulichungen offenbart sein, die Operationen zeigen, die in einer bestimmten Reihenfolge durchgeführt werden. Sofern nicht ausdrücklich anders angegeben oder sofern dies nicht in einem bestimmten Kontext erforderlich ist, ist die Reihenfolge nur als ein nicht einschränkendes Beispiel zu verstehen. Des Weiteren können in Fällen, in denen eine Operation als einer anderen nachfolgend gezeigt ist, auch andere dazwischenliegende Operationen erfolgen, die verbunden oder unverbunden sein können. Einige Operationen können auch gleichzeitig oder parallel durchgeführt werden. In Fällen, in denen eine Operation als „basierend auf“ oder „gemäß“ einem anderen Element oder einer anderen Operation bezeichnet wird, ist dies so zu verstehen, dass impliziert wird, dass die Operation zumindest teilweise auf dem anderen Element oder der anderen Operation basiert oder zumindest teilweise gemäß diesem/dieser ist. Dies darf nicht so ausgelegt werden, dass impliziert wird, dass die Operation nur und ausschließlich auf dem Element oder der Operation basiert oder nur und ausschließlich gemäß diesem/dieser ist.
  • Die Gesamtheit jedes hierin offenbarten Hardwareelements oder ein Teil davon kann leicht in einem System-on-a-Chip (SoC), einschließlich eines Zentralprozessor(Central Processing Unit, CPU)-Gehäuses, bereitgestellt werden. Ein SoC stellt eine integrierte Schaltung (Integrated Circuit, IC) dar, die Komponenten eines Computers oder anderen elektronischen Systems in einen Einzelchip integriert. Daher können zum Beispiel Client-Vorrichtungen oder Servervorrichtungen ganz oder teilweise in einem SoC bereitgestellt werden. Das SoC kann digitale, analoge, Mischsignal- und Hochfrequenzfunktionen enthalten, die alle auf einem Einzelchipsubstrat bereitgestellt werden. Andere Ausführungsformen können ein Multi-Chip-Modul (MCM) einschließen, wobei sich eine Vielzahl von Chips in einem einzelnen elektronischen Gehäuse befindet und dazu konfiguriert ist, durch das elektronische Gehäuse eng miteinander zu interagieren.
  • Allgemein kann jede Schaltung oder jeder Prozessor, die/der auf geeignete Weise konfiguriert ist, jeden Typ von Befehlen in Verbindung mit den Daten ausführen, um die hierin ausführlich beschriebenen Operationen zu erreichen. Jeder hierin offenbarte Prozessor kann ein Element (zum Beispiel Daten) von einem Zustand oder Ding in einen anderen Zustand oder ein anderes Ding transformieren. Des Weiteren können die Informationen, die in einem Prozessor nachverfolgt, gesendet, empfangen oder gespeichert werden, basierend auf bestimmten Anforderungen und Implementierungen in einer/einem beliebigen Datenbank, Register, Tabelle, Cache, Warteschlange, Steuerungsliste oder Speicher-Fabric bereitgestellt werden, wobei auf alle in jedem geeigneten Zeitrahmen Bezug genommen werden kann. Jedes der hierin offenbarten Arbeitsspeicher- oder Speicherelemente ist gegebenenfalls so auszulegen, dass es in den weiter gefassten Begriffen „Arbeitsspeicher“ und „Speicher“ enthalten ist.
  • Computerprogrammlogik, die die Gesamtheit oder einen Teil der hierin beschriebenen Funktionalität implementiert, ist in verschiedenen Formen ausgeführt, einschließlich einer Quellcodeform, einer computerausführbaren Form, Maschinenbefehlen oder Mikrocode, programmierbarer Hardware und verschiedenen Zwischenformen (zum Beispiel Formen, die durch einen Assembler, Compiler, Linker oder Lokator erzeugt werden), aber in keiner Weise hierauf beschränkt. In einem Beispiel schließt Quellcode eine Reihe von Computerprogrammbefehlen ein, die in verschiedenen Programmiersprachen, wie einem Objektcode, einer Assemblersprache oder einer High-Level-Sprache, wie OpenCL, FORTRAN, C, C++, JAVA oder HTML, zur Verwendung mit verschiedenen Betriebssystemen oder Betriebsumgebungen oder in Hardwarebeschreibungssprachen, wie Spice, Verilog und VHDL, implementiert sind. Der Quellcode kann verschiedene Datenstrukturen und Kommunikationsnachrichten definieren und verwenden. Der Quellcode kann in einer computerausführbaren Form (z. B. über einen Interpreter) vorliegen, oder der Quellcode kann (z. B. über einen Translator, Assembler oder Compiler) in eine computerausführbare Form umgewandelt werden oder in eine Zwischenform, wie Bytecode, umgewandelt werden. Wo dies geeignet ist, kann jedes von dem Vorgenannten verwendet werden, um geeignete diskrete oder integrierte Schaltungen, egal ob sequentiell, kombinatorisch, Zustandsmaschinen oder Anderes, herzustellen oder zu beschreiben.
  • In einer beispielhaften Ausführungsform kann eine beliebige Anzahl von elektrischen Schaltungen der FIGUREN auf einer Platte einer zugehörigen elektronischen Vorrichtung implementiert werden. Die Platte kann eine allgemeine Leiterplatte sein, die verschiedene Komponenten des internen elektronischen Systems der elektronischen Vorrichtung aufnimmt und außerdem Anschlüsse für andere Peripheriegeräte bereitstellt. Jeder geeignete Prozessor und Arbeitsspeicher kann auf geeignete Weise basierend auf bestimmten Konfigurationsanforderungen, Verarbeitungsanforderungen und Rechenausführungen an die Platte gekoppelt sein.
  • Es sei darauf hingewiesen, dass bei den zahlreichen hierin bereitgestellten Beispielen eine Interaktion in Bezug auf zwei, drei, vier oder mehr elektrische Komponenten beschrieben sein kann. Diese Vorgehensweise wurde jedoch nur zu Zwecken der Klarheit und nur als Beispiel gewählt. Es versteht sich, dass das System auf jede geeignete Weise konsolidiert oder neu konfiguriert werden kann. Bei ähnlichen Ausführungsalternativen kann jede/s der veranschaulichten Komponenten, Module und Elemente der FIGUREN in verschiedenen möglichen Konfigurationen kombiniert werden, die sich alle innerhalb des weit gefassten Umfangs dieser Beschreibung befinden.
  • Zahlreiche weitere Änderungen, Ersetzungen, Variationen und Modifikationen können von einem Fachmann festgestellt werden, und es ist beabsichtigt, dass die vorliegende Offenbarung alle diese Änderungen, Ersetzungen, Variationen und Modifikationen als in den Umfang der beigefügten Ansprüche fallend umfasst. Um das US-amerikanische Patent- und Markenamt (United States Patent and Trademark Office, USPTO) und außerdem alle Leser eines für diese Anmeldung erteilten Patents beim Interpretieren der hierzu beigefügten Ansprüche zu unterstützen, möchte der Anmelder darauf hinweisen, dass der Anmelder: (a) nicht beabsichtigt, sich für irgendeinen der beigefügten Ansprüche, wie er am Datum der Einreichung hiervon vorliegt, auf die Anwendung von Absatz sechs (6) von 35 USC, Abschnitt 112, (vor dem AIA) oder von Absatz (f) desselben Abschnitts (nach dem AIA) zu berufen, sofern nicht die Wörter „Mittel zu“ oder „Schritte zu“ ausdrücklich in den bestimmten Ansprüchen verwendet werden; und (b) nicht beabsichtigt, diese Offenbarung durch irgendeine Angabe in der Beschreibung in irgendeiner Weise zu beschränken, die sich nicht auf andere Weise ausdrücklich in den beigefügten Ansprüchen widerspiegelt.
  • Beispielhafte Implementierungen
  • Die folgenden Beispiele werden zur Veranschaulichung bereitgestellt.
  • Beispiel 1 schließt ein System für künstliche Intelligenz (KI), das Folgendes umfasst: eine erste Hardwareplattform; eine Fabric-Schnittstelle, die dazu konfiguriert ist, die erste Hardwareplattform kommunikativ an eine zweite Hardwareplattform zu koppeln; einen Prozessor, der auf der ersten Hardwareplattform gehostet wird und dazu programmiert ist, an einem KI-Problem zu arbeiten; und einen ersten Trainingsbeschleuniger, der Folgendes umfasst: eine Beschleunigerhardware; einen Plattform-Inter-Chip Link (ICL), der dazu konfiguriert ist, den ersten Trainingsbeschleuniger ohne Unterstützung durch den Prozessor kommunikativ an einen zweiten Trainingsbeschleuniger auf der ersten Hardwareplattform zu koppeln; einen Fabric-ICL, um den ersten Trainingsbeschleuniger ohne Unterstützung durch den Prozessor kommunikativ an einen dritten Trainingsbeschleuniger auf einer zweiten Hardwareplattform zu koppeln; und einen Systemdecoder, der dazu konfiguriert ist, den Fabric-ICL und Plattform-ICL zu betreiben, um Daten der Beschleunigerhardware ohne Unterstützung durch den Prozessor zwischen dem ersten Trainingsbeschleuniger und zweiten und dritten Trainingsbeschleunigern zu teilen, ein.
  • Beispiel 2 schließt das KI-System von Beispiel 1 ein, wobei die Fabric eine nichtarbeitsspeicherkohärente Fabric ist.
  • Beispiel 3 schließt das KI-System von Beispiel 2 ein, wobei die nichtarbeitsspeicherkohärente Fabric eine PCIe-Fabric ist.
  • Beispiel 4 schließt das KI-System von Beispiel 1 ein, wobei die Fabric eine OmniPath-Fabric ist.
  • Beispiel 5 schließt das KI-System von Beispiel 1 ein, wobei der Systemdecoder dazu konfiguriert ist, den ersten Trainingsbeschleuniger in einer Punkt-zu-Punkt-Konfiguration kommunikativ an den dritten Trainingsbeschleuniger zu koppeln.
  • Beispiel 6 schließt das KI-System von Beispiel 1 ein, wobei der Systemdecoder dazu konfiguriert ist, den ersten Trainingsbeschleuniger in einer Maschenkonfiguration kommunikativ an den dritten Trainingsbeschleuniger zu koppeln.
  • Beispiel 7 schließt das KI-System von Beispiel 1 ein, wobei der Systemdecoder dazu konfiguriert ist, den Fabric-ICL als einen Gateway-Fabric-ICL für die erste Hardwareplattform zu bestimmen.
  • Beispiel 8 schließt das KI-System von Beispiel 7 ein, wobei der Fabric-ICL Sendeverkehr von einem einzelnen Trainingsbeschleuniger der zweiten Hardwareplattform empfangen soll.
  • Beispiel 9 schließt das KI-System von Beispiel 7 ein, wobei der Fabric-ICL Verkehr von dem zweiten Trainingsbeschleuniger zu einer Vielzahl von Hardwareplattformen senden soll.
  • Beispiel 10 schließt das KI-System von einem der Beispiele 1 bis 9 ein, wobei der Fabric-ICL eine anwendungsspezifische integrierte Schaltung (Application-Specific Integrated Circuit, ASIC) ist.
  • Beispiel 11 schließt das KI-System von einem der Beispiele 1 bis 9 ein, wobei der Fabric-ICL eine anwenderprogrammierbare Gatteranordnung (Field-Programmable Gate Array, FPGA) ist.
  • Beispiel 12 schließt das KI-System von Beispiel 11 ein, wobei der Systemdecoder ein nicht-flüchtiges Speichermedium umfasst, auf dem Befehle zum Konfigurieren der Fabric-ICL-FPGA gespeichert sind, und wobei der Systemdecoder die Fabric-ICL-FPGA mit den Befehlen programmieren soll.
  • Beispiel 13 schließt das KI-System von Beispiel 11 ein, wobei das nicht-flüchtige Speichermedium verschiedene Befehle zum Konfigurieren des Fabric-ICL für eine Vielzahl von Rollen umfasst und wobei der Systemdecoder eine Rolle für den Fabric-ICL auswählen und den Fabric-ICL mit den Befehlen für diese Rolle programmieren soll.
  • Beispiel 14 schließt einen Systemdecoder für einen ersten Trainingsbeschleuniger zum Betreiben auf einer ersten Hardwareplattform ein, der Folgendes umfasst: ein Mittel zum kommunikativen Koppeln an eine Fabric-Schnittstelle, die dazu konfiguriert ist, die erste Hardwareplattform kommunikativ an eine zweite Hardwareplattform zu koppeln; ein Mittel zum kommunikativen Koppeln an eine Beschleunigerhardware; ein Mittel zum kommunikativen Koppeln an einen Plattform-Inter-Chip Link (ICL), der dazu konfiguriert ist, den ersten Trainingsbeschleuniger ohne Unterstützung durch einen Prozessor kommunikativ an einen zweiten Trainingsbeschleuniger auf der ersten Hardwareplattform zu koppeln; ein Mittel zum kommunikativen Koppeln an einen Fabric-ICL, um den ersten Trainingsbeschleuniger ohne Unterstützung durch den Prozessor kommunikativ an einen dritten Trainingsbeschleuniger auf einer zweiten Hardwareplattform zu koppeln; und ein Mittel zum Betreiben des Fabric-ICL und Plattform-ICL, um Daten der Beschleunigerhardware ohne Unterstützung durch den Prozessor zwischen dem ersten Trainingsbeschleuniger und zweiten und dritten Trainingsbeschleunigern zu teilen.
  • Beispiel 15 schließt den Systemdecoder von Beispiel 14 ein, wobei die Fabric eine nichtarbeitsspeicherkohärente Fabric ist.
  • Beispiel 16 schließt den Systemdecoder von Beispiel 15 ein, wobei die nichtarbeitsspeicherkohärente Fabric eine PCIe-Fabric ist.
  • Beispiel 17 schließt den Systemdecoder von Beispiel 14 ein, wobei die Fabric eine OmniPath-Fabric ist.
  • Beispiel 18 schließt den Systemdecoder von Beispiel 14 ein, wobei der Systemdecoder dazu konfiguriert ist, den ersten Trainingsbeschleuniger in einer Punkt-zu-Punkt-Konfiguration kommunikativ an den dritten Trainingsbeschleuniger zu koppeln.
  • Beispiel 19 schließt den Systemdecoder von Beispiel 14 ein, wobei der Systemdecoder dazu konfiguriert ist, den ersten Trainingsbeschleuniger in einer Maschenkonfiguration kommunikativ an den dritten Trainingsbeschleuniger zu koppeln.
  • Beispiel 20 schließt den Systemdecoder von Beispiel 14 ein, wobei der Systemdecoder dazu konfiguriert ist, den Fabric-ICL als einen Gateway-Fabric-ICL für die erste Hardwareplattform zu bestimmen.
  • Beispiel 21 schließt den Systemdecoder von Beispiel 20 ein, wobei der Fabric-ICL Sendeverkehr von einem einzelnen Trainingsbeschleuniger der zweiten Hardwareplattform empfangen soll.
  • Beispiel 22 schließt den Systemdecoder von Beispiel 20 ein, wobei der Fabric-ICL Verkehr von dem zweiten Trainingsbeschleuniger zu einer Vielzahl von Hardwareplattformen senden soll.
  • Beispiel 23 schließt den Systemdecoder von einem der Beispiele 14 bis 22 ein, wobei der Fabric-ICL eine anwendungsspezifische integrierte Schaltung (Application-Specific Integrated Circuit, ASIC) ist.
  • Beispiel 24 schließt den Systemdecoder von einem der Beispiele 14 bis 22 ein, wobei der Fabric-ICL eine anwenderprogrammierbare Gatteranordnung (Field Programmable Gate Array, FPGA) ist.
  • Beispiel 25 schließt den Systemdecoder von Beispiel 24 ein, wobei der Systemdecoder ein nicht-flüchtiges Speichermedium umfasst, auf dem Befehle zum Konfigurieren der Fabric-ICL-FPGA gespeichert sind, und wobei der Systemdecoder die Fabric-ICL-FPGA mit den Befehlen programmieren soll.
  • Beispiel 26 schließt den Systemdecoder von Beispiel 24 ein, wobei das nicht-flüchtige Speichermedium verschiedene Befehle zum Konfigurieren des Fabric-ICL für eine Vielzahl von Rollen umfasst und wobei der Systemdecoder eine Rolle für den Fabric-ICL auswählen und den Fabric-ICL mit den Befehlen für diese Rolle programmieren soll.
  • Beispiel 27 schließt den Systemdecoder von einem der Beispiele 14 bis 26 ein, wobei der Systemdecoder ein Block geistigen Eigentums (Intellectual Property, IP) ist.
  • Beispiel 28 schließt den Systemdecoder von einem der Beispiele 14 bis 26 ein, wobei der Systemdecoder eine anwenderprogrammierbare Gatteranordnung ist.
  • Beispiel 29 schließt den Systemdecoder von einem der Beispiele 14 bis 26 ein, wobei der Systemdecoder ein Prozessor ist.
  • Beispiel 30 schließt ein Verfahren zum Bereitstellen von Kommunikation zwischen einem ersten Trainingsbeschleuniger auf einer ersten Hardwareplattform, einem zweiten Trainingsbeschleuniger auf der ersten Hardwareplattform und einem dritten Trainingsbeschleuniger auf einer zweiten Hardwareplattform ein, das Folgendes umfasst: kommunikatives Koppeln an eine Fabric-Schnittstelle, die dazu konfiguriert ist, die erste Hardwareplattform kommunikativ an die zweite Hardwareplattform zu koppeln; kommunikatives Koppeln an eine Beschleunigerhardware des ersten Trainingsbeschleunigers; kommunikatives Koppeln an einen Plattform-Inter-Chip Link (ICL), der dazu konfiguriert ist, den ersten Trainingsbeschleuniger ohne Unterstützung durch einen Prozessor kommunikativ an einen zweiten Trainingsbeschleuniger auf der ersten Hardwareplattform zu koppeln; kommunikatives Koppeln an einen Fabric-ICL, um den ersten Trainingsbeschleuniger ohne Unterstützung durch den Prozessor kommunikativ an einen dritten Trainingsbeschleuniger auf einer zweiten Hardwareplattform zu koppeln; und Betreiben des Fabric-ICL und Plattform-ICL, um Daten ohne Unterstützung durch den Prozessor zwischen dem ersten Trainingsbeschleuniger und zweiten und dritten Trainingsbeschleunigern zu teilen.
  • Beispiel 31 schließt das Verfahren von Beispiel 30 ein, wobei die Fabric eine nichtarbeitsspeicherkohärente Fabric ist.
  • Beispiel 32 schließt das Verfahren von Beispiel 31 ein, wobei die nichtarbeitsspeicherkohärente Fabric eine PCIe-Fabric ist.
  • Beispiel 33 schließt das Verfahren von Beispiel 30 ein, wobei die Fabric eine OmniPath-Fabric ist.
  • Beispiel 34 schließt das Verfahren von Beispiel 30 ein, ferner umfassend ein kommunikatives Koppeln des ersten Trainingsbeschleunigers in einer Punkt-zu-Punkt-Konfiguration an den dritten Trainingsbeschleuniger.
  • Beispiel 35 schließt das Verfahren von Beispiel 30 ein, ferner umfassend ein kommunikatives Koppeln des ersten Trainingsbeschleunigers in einer Maschenkonfiguration an den dritten Trainingsbeschleuniger.
  • Beispiel 36 schließt das Verfahren von Beispiel 30 ein, ferner umfassend ein Bestimmen des Fabric-ICL als ein Gateway-Fabric-ICL für die erste Gateway-Hardwareplattform.
  • Beispiel 37 schließt das Verfahren von Beispiel 30 ein, ferner umfassend ein Empfangen von Sendeverkehr von einem einzelnen Trainingsbeschleuniger der zweiten Hardwareplattform.
  • Beispiel 38 schließt das Verfahren von Beispiel 30 ein, ferner umfassend ein Senden von Verkehr von dem zweiten Trainingsbeschleuniger zu einer Vielzahl von Hardwareplattformen.
  • Beispiel 39 schließt einen Systemdecoder ein, der dazu konfiguriert ist, das Verfahren von einem der Beispiele 30 bis 38 durchzuführen.
  • Beispiel 40 schließt den Systemdecoder von Beispiel 39 ein, wobei der Fabric-ICL eine anwendungsspezifische integrierte Schaltung (Application-Specific Integrated Circuit, ASIC) ist.
  • Beispiel 41 schließt den Systemdecoder von Beispiel 39 ein, wobei der Fabric-ICL eine anwenderprogrammierbare Gatteranordnung (Field Programmable Gate Array, FPGA) ist.
  • Beispiel 42 schließt den Systemdecoder von Beispiel 41 ein, wobei der Systemdecoder ein nicht-flüchtiges Speichermedium umfasst, auf dem Befehle zum Konfigurieren der Fabric-ICL-FPGA gespeichert sind, und wobei der Systemdecoder die Fabric-ICL-FPGA mit den Befehlen programmieren soll.
  • Beispiel 43 schließt den Systemdecoder von Beispiel 41 ein, wobei das nicht-flüchtige Speichermedium verschiedene Befehle zum Konfigurieren des Fabric-ICL für eine Vielzahl von Rollen umfasst und wobei der Systemdecoder eine Rolle für den Fabric-ICL auswählen und den Fabric-ICL mit den Befehlen für diese Rolle programmieren soll.
  • Beispiel 44 schließt den Systemdecoder von einem der Beispiele 39 bis 43 ein, wobei der Systemdecoder ein Block geistigen Eigentums (Intellectual Property, IP) ist.
  • Beispiel 45 schließt den Systemdecoder von einem der Beispiele 39 bis 43 ein, wobei der Systemdecoder eine anwenderprogrammierbare Gatteranordnung ist.
  • Beispiel 46 schließt den Systemdecoder von einem der Beispiele 39 bis 43 ein, wobei der Systemdecoder ein Prozessor ist.

Claims (25)

  1. System für künstliche Intelligenz (KI), das Folgendes umfasst: eine erste Hardwareplattform; eine Fabric-Schnittstelle, die dazu konfiguriert ist, die erste Hardwareplattform kommunikativ an eine zweite Hardwareplattform zu koppeln; einen Prozessor, der auf der ersten Hardwareplattform gehostet wird und dazu programmiert ist, an einem KI-Problem zu arbeiten; und einen ersten Trainingsbeschleuniger, der Folgendes umfasst: eine Beschleunigerhardware; einen Plattform-Inter-Chip Link (ICL), der dazu konfiguriert ist, den ersten Trainingsbeschleuniger ohne Unterstützung durch den Prozessor kommunikativ an einen zweiten Trainingsbeschleuniger auf der ersten Hardwareplattform zu koppeln; einen Fabric-ICL, um den ersten Trainingsbeschleuniger ohne Unterstützung durch den Prozessor kommunikativ an einen dritten Trainingsbeschleuniger auf einer zweiten Hardwareplattform zu koppeln; und einen Systemdecoder, der dazu konfiguriert ist, den Fabric-ICL und Plattform-ICL zu betreiben, um Daten der Beschleunigerhardware ohne Unterstützung durch den Prozessor zwischen dem ersten Trainingsbeschleuniger und zweiten und dritten Trainingsbeschleunigern zu teilen.
  2. KI-System nach Anspruch 1, wobei die Fabric eine nichtarbeitsspeicherkohärente Fabric ist.
  3. KI-System nach Anspruch 2, wobei die nichtarbeitsspeicherkohärente Fabric eine PCIe-Fabric ist.
  4. KI-System nach Anspruch 1, wobei die Fabric eine OmniPath-Fabric ist.
  5. KI-System nach Anspruch 1, wobei der Systemdecoder dazu konfiguriert ist, den ersten Trainingsbeschleuniger in einer Punkt-zu-Punkt-Konfiguration kommunikativ an den dritten Trainingsbeschleuniger zu koppeln.
  6. KI-System nach Anspruch 1, wobei der Systemdecoder dazu konfiguriert ist, den ersten Trainingsbeschleuniger in einer Maschenkonfiguration kommunikativ an den dritten Trainingsbeschleuniger zu koppeln.
  7. KI-System nach Anspruch 1, wobei der Systemdecoder dazu konfiguriert ist, den Fabric-ICL als einen Gateway-Fabric-ICL für die erste Hardwareplattform zu bestimmen.
  8. KI-System nach Anspruch 7, wobei der Fabric-ICL Sendeverkehr von einem einzelnen Trainingsbeschleuniger der zweiten Hardwareplattform empfangen soll.
  9. KI-System nach Anspruch 7, wobei der Fabric-ICL Verkehr von dem zweiten Trainingsbeschleuniger zu einer Vielzahl von Hardwareplattformen senden soll.
  10. KI-System nach einem der Ansprüche 1 bis 9, wobei der Fabric-ICL eine anwendungsspezifische integrierte Schaltung (Application-Specific Integrated Circuit, ASIC) ist.
  11. KI-System nach einem der Ansprüche 1 bis 9, wobei der Fabric-ICL eine anwenderprogrammierbare Gatteranordnung (Field Programmable Gate Array, FPGA) ist.
  12. KI-System nach Anspruch 11, wobei der Systemdecoder ein nicht-flüchtiges Speichermedium umfasst, auf dem Befehle zum Konfigurieren der Fabric-ICL-FPGA gespeichert sind, und wobei der Systemdecoder die Fabric-ICL-FPGA mit den Befehlen programmieren soll.
  13. KI-System nach Anspruch 11, wobei das nicht-flüchtige Speichermedium verschiedene Befehle zum Konfigurieren des Fabric-ICL für eine Vielzahl von Rollen umfasst und wobei der Systemdecoder eine Rolle für den Fabric-ICL auswählen und den Fabric-ICL mit den Befehlen für diese Rolle programmieren soll.
  14. Systemdecoder für einen ersten Trainingsbeschleuniger zum Betreiben auf einer ersten Hardwareplattform, der Folgendes umfasst: ein Mittel zum kommunikativen Koppeln an eine Fabric-Schnittstelle, die dazu konfiguriert ist, die erste Hardwareplattform kommunikativ an eine zweite Hardwareplattform zu koppeln; ein Mittel zum kommunikativen Koppeln an eine Beschleunigerhardware; ein Mittel zum kommunikativen Koppeln an einen Plattform-Inter-Chip Link (ICL), der dazu konfiguriert ist, den ersten Trainingsbeschleuniger ohne Unterstützung durch einen Prozessor kommunikativ an einen zweiten Trainingsbeschleuniger auf der ersten Hardwareplattform zu koppeln; ein Mittel zum kommunikativen Koppeln an einen Fabric-ICL, um den ersten Trainingsbeschleuniger ohne Unterstützung durch den Prozessor kommunikativ an einen dritten Trainingsbeschleuniger auf einer zweiten Hardwareplattform zu koppeln; und ein Mittel zum Betreiben des Fabric-ICL und Plattform-ICL, um Daten der Beschleunigerhardware ohne Unterstützung durch den Prozessor zwischen dem ersten Trainingsbeschleuniger und zweiten und dritten Trainingsbeschleunigern zu teilen.
  15. Systemdecoder nach Anspruch 14, wobei die Fabric eine nichtarbeitsspeicherkohärente Fabric ist.
  16. Systemdecoder nach Anspruch 15, wobei die nichtarbeitsspeicherkohärente Fabric eine PCIe-Fabric ist.
  17. Systemdecoder nach Anspruch 14, wobei die Fabric eine OmniPath-Fabric ist.
  18. Systemdecoder nach Anspruch 14, wobei der Systemdecoder dazu konfiguriert ist, den ersten Trainingsbeschleuniger in einer Punkt-zu-Punkt-Konfiguration kommunikativ an den dritten Trainingsbeschleuniger zu koppeln.
  19. Systemdecoder nach Anspruch 14, wobei der Systemdecoder dazu konfiguriert ist, den ersten Trainingsbeschleuniger in einer Maschenkonfiguration kommunikativ an den dritten Trainingsbeschleuniger zu koppeln.
  20. Systemdecoder nach Anspruch 14, wobei der Systemdecoder dazu konfiguriert ist, den Fabric-ICL als einen Gateway-Fabric-ICL für die erste Hardwareplattform zu bestimmen.
  21. Systemdecoder nach Anspruch 20, wobei der Fabric-ICL Sendeverkehr von einem einzelnen Trainingsbeschleuniger der zweiten Hardwareplattform empfangen soll.
  22. Systemdecoder nach Anspruch 20, wobei der Fabric-ICL Verkehr von dem zweiten Trainingsbeschleuniger zu einer Vielzahl von Hardwareplattformen senden soll.
  23. Systemdecoder nach einem der Ansprüche 14 bis 22, wobei der Fabric-ICL eine anwendungsspezifische integrierte Schaltung (Application-Specific Integrated Circuit, ASIC) ist.
  24. Systemdecoder nach einem der Ansprüche 14 bis 22, wobei der Fabric-ICL eine anwenderprogrammierbare Gatteranordnung (Field Programmable Gate Array, FPGA) ist.
  25. Systemdecoder nach Anspruch 24, wobei der Systemdecoder ein nicht-flüchtiges Speichermedium umfasst, auf dem Befehle zum Konfigurieren der Fabric-ICL-FPGA gespeichert sind, und wobei der Systemdecoder die Fabric-ICL-FPGA mit den Befehlen programmieren soll.
DE102018129112.4A 2017-12-20 2018-11-20 Systemdecoder für Trainingsbeschleuniger Pending DE102018129112A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15/848,218 US11263162B2 (en) 2017-12-20 2017-12-20 System decoder for training accelerators
US15/848,218 2017-12-20

Publications (1)

Publication Number Publication Date
DE102018129112A1 true DE102018129112A1 (de) 2019-06-27

Family

ID=65231536

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102018129112.4A Pending DE102018129112A1 (de) 2017-12-20 2018-11-20 Systemdecoder für Trainingsbeschleuniger

Country Status (2)

Country Link
US (4) US11263162B2 (de)
DE (1) DE102018129112A1 (de)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180150256A1 (en) * 2016-11-29 2018-05-31 Intel Corporation Technologies for data deduplication in disaggregated architectures
US10698766B2 (en) * 2018-04-18 2020-06-30 EMC IP Holding Company LLC Optimization of checkpoint operations for deep learning computing
US11315013B2 (en) * 2018-04-23 2022-04-26 EMC IP Holding Company LLC Implementing parameter server in networking infrastructure for high-performance computing
US11710034B2 (en) * 2019-02-27 2023-07-25 Intel Corporation Misuse index for explainable artificial intelligence in computing environments
US11249786B2 (en) * 2019-07-03 2022-02-15 Vmware, Inc. Virtualizing hardware components that implement AI applications
WO2021092890A1 (en) * 2019-11-15 2021-05-20 Baidu.Com Times Technology (Beijing) Co., Ltd. Distributed ai training topology based on flexible cable connection
US20230047880A1 (en) * 2021-08-12 2023-02-16 Verizon Patent And Licensing Inc. Sidecar proxy as a service

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7478152B2 (en) 2004-06-29 2009-01-13 Avocent Fremont Corp. System and method for consolidating, securing and automating out-of-band access to nodes in a data network
EP1615141B1 (de) * 2004-07-01 2018-03-07 Harman Becker Automotive Systems GmbH Rechnerarchitektur für in einem fahrzeug verwendbares mobiles multimediasystem
US8738860B1 (en) * 2010-10-25 2014-05-27 Tilera Corporation Computing in parallel processing environments
US10671938B2 (en) * 2016-01-27 2020-06-02 Bonsai AI, Inc. Artificial intelligence engine configured to work with a pedagogical programming language to train one or more trained artificial intelligence models
US10282811B2 (en) * 2017-04-07 2019-05-07 Intel Corporation Apparatus and method for managing data bias in a graphics processing architecture
US20200311559A1 (en) * 2017-06-20 2020-10-01 Rita Chattopadhyay Optimized decision tree machine learning for resource-constrained devices
US11003982B2 (en) * 2017-06-27 2021-05-11 D5Ai Llc Aligned training of deep networks
US10687435B2 (en) 2017-08-28 2020-06-16 Facebook, Inc. Apparatus, system, and method for enabling multiple storage-system configurations
US11263143B2 (en) * 2017-09-29 2022-03-01 Intel Corporation Coherent accelerator fabric controller
US11270201B2 (en) * 2017-12-29 2022-03-08 Intel Corporation Communication optimizations for distributed machine learning
US20190286973A1 (en) * 2018-03-14 2019-09-19 Microsoft Technology Licensing, Llc Hardware accelerated neural network subgraphs
US10728091B2 (en) * 2018-04-04 2020-07-28 EMC IP Holding Company LLC Topology-aware provisioning of hardware accelerator resources in a distributed environment
US11315013B2 (en) * 2018-04-23 2022-04-26 EMC IP Holding Company LLC Implementing parameter server in networking infrastructure for high-performance computing
US10310760B1 (en) * 2018-05-21 2019-06-04 Pure Storage, Inc. Layering communication fabric protocols
US11216314B2 (en) * 2018-11-02 2022-01-04 EMC IP Holding Company LLC Dynamic reallocation of resources in accelerator-as-a-service computing environment
US20230094125A1 (en) * 2021-09-24 2023-03-30 Nvidia Corporation Implementing trusted executing environments across multiple processor devices

Also Published As

Publication number Publication date
US20230039631A1 (en) 2023-02-09
US20220147395A1 (en) 2022-05-12
US11269801B2 (en) 2022-03-08
US11263162B2 (en) 2022-03-01
US11586575B2 (en) 2023-02-21
US20210103544A1 (en) 2021-04-08
US20190042515A1 (en) 2019-02-07

Similar Documents

Publication Publication Date Title
DE102018129112A1 (de) Systemdecoder für Trainingsbeschleuniger
DE102018210537A1 (de) Mikrodienste-Architektur
DE112020007201T5 (de) Speicherzuordnung für verteilte Verarbeitungsvorrichtungen
DE102021122880A1 (de) Infrastrukturverarbeitungseinheit
DE112013000731B4 (de) Skalierbare virtuelle Geräte-Cloud
DE102018214775A1 (de) Technologien zum Aufteilen der Arbeit über Beschleunigervorrichtungen hinweg
DE102018005103A1 (de) Techniken zum Migrieren einer virtuellen Maschine unter Verwendung von verteilten Rechenbetriebsmitteln
DE102018004111B4 (de) Rechensystem, computerlesbares medium und bedarfsskalierungsengine zum kommunikativen koppeln an einen prozessor
DE112016004347T5 (de) Lokale und globale Datenzentrumsnetzoptimierungen in Echtzeit basierend auf Plattformtelemetriedaten
DE102020201834A1 (de) Technologien für netzvorrichtungslastausgleichseinrichtungen für beschleunigte funktionen-als-dienst
DE102022104207A1 (de) Pooling von Netzwerkverarbeitungsressourcen
US20210044503A1 (en) Oversubscribable resource allocation
DE112013000408T5 (de) Verfahren und Vorrichtung zur gemeinsamen Nutzung einer Netzwerk-Schnittstellensteuerung
DE102013208431A1 (de) Großer verteilter Switch auf Fabric-Basis unter Verwendung virtueller Switches und virtueller Steuereinheiten
DE112012001198T5 (de) Verfahren zum Bereitstellen ortsunabhängigen Anschlussspiegelns auf verteilten virtuellen Switches
DE112018007780T5 (de) Transparente verschlüsselung
DE112012002404B4 (de) Konfiguration und Management virtueller Netzwerke
DE102018127751A1 (de) Einheitlicher Adressraum für mehrere Verbindungen
DE102018202432A1 (de) Strukturunterstützung für die Dienstgüte
DE112019000965T5 (de) Technologien zur reduzierung der nic-anschlüsse mit beschleunigter schaltung
DE102019130686A1 (de) Technologien zur bereitstellung dynamischer auswahl von edge- und lokalen beschleunigerressourcen
DE102018214007A1 (de) Zusammenwirken von Altvorrichtungen in virtualisierten Netzwerken
DE112022003720T5 (de) Verwenden eines fernen pods in kubernetes
DE112012004957T5 (de) Flexibles und skalierbares Enhanced-Transmission-Selection-Verfahren für Netzwerkstrukturen
DE112022002284T5 (de) Auslagerung der vermittlungsschicht 7 an eine infrastrukturverarbeitungseinheit für ein vermaschtes dienstnetz

Legal Events

Date Code Title Description
R130 Divisional application to

Ref document number: 102018010421

Country of ref document: DE