Systemarchitektur
Tensor Processing Units (TPUs) sind anwendungsspezifische integrierte Schaltungen (Application-Specific Integrated Circuits, ASICs), die von Google entwickelt wurden, um die beim maschinellen Lernen entstehenden Arbeitslasten zu beschleunigen. Cloud TPU ist ein Google Cloud-Dienst, der TPUs als skalierbare Ressource zur Verfügung stellt.
TPUs sind für die schnelle Ausführung von Matrixoperationen ausgelegt und eignen sich daher ideal für Arbeitslasten für maschinelles Lernen. Sie können Arbeitslasten für maschinelles Lernen auf TPUs mit Frameworks wie TensorFlow, PyTorch und JAX ausführen.
Cloud TPU-Begriffe
Wenn Sie Cloud TPUs noch nicht kennen, lesen Sie den Einstiegsleitfaden für TPUs. In den folgenden Abschnitten werden die in diesem Dokument verwendeten Begriffe und Konzepte erläutert.
Batch-Inferenz
Bei der Batch- oder Offline-Inferenz werden Inferenzen außerhalb von Produktionspipelines durchgeführt, in der Regel für eine große Menge an Eingaben. Die Batch-Inferenz wird für Offlineaufgaben wie das Datenlabeln und auch für die Bewertung des trainierten Modells verwendet. SLOs für die Latenz haben bei der Batch-Inferenz keine Priorität.
TPU-Chip
Ein TPU-Chip enthält einen oder mehrere TensorCores. Die Anzahl der TensorCores hängt von der Version des TPU-Chips ab. Jeder TensorCore besteht aus einer oder mehreren Matrixmultiplikationseinheiten (MXUs), einer Vektoreinheit und einer Skalareinheit.
Eine MXU besteht aus 256 x 256 (TPU v6e) oder 128 x 128 (TPU-Versionen vor v6e) Multiplikatoren/Akkumulatoren in einem systolischen Array. MXUs stellen den Großteil der Rechenleistung in einem TensorCore bereit. Jede MXU kann in jedem Zyklus 16.000 Multiplikations- bzw. Akkumulationsoperationen ausführen. Alle Multiplikationen nehmen bfloat16-Eingabewerte an, aber alle Akkumulationen werden im FP32-Zahlenformat ausgeführt.
Die Vektoreinheit wird für allgemeine Berechnungen wie Aktivierung und Softmax verwendet. Die Skalareinheit wird für die Ablaufsteuerung, die Berechnung der Speicheradresse und andere Wartungsvorgänge genutzt.
TPU-Kubus
Eine 4x4x4-Topologie. Dies gilt nur für 3D-Topologien (ab der TPU-Version 4).
Inferenz
Bei der Inferenz wird ein trainiertes Modell verwendet, um Vorhersagen für neue Daten zu treffen. Sie wird vom Auslieferungsprozess verwendet.
Mehrere Slices im Vergleich zu einzelnen Slices
Multislice ist eine Gruppe von Slices, die die TPU-Konnektivität über die Inter-Chip-Interconnect-Verbindungen (ICI) hinaus erweitert und das Rechenzentrumsnetzwerk (DCN) für die Übertragung von Daten über ein Slice hinaus nutzt. Die Daten innerhalb der einzelnen Zeitabschnitte werden weiterhin von ICI übertragen. Mit dieser hybriden Verbindung ermöglicht Multislice Parallelität über Slices hinweg und Sie können für einen einzelnen Job mehr TPU-Kerne verwenden, als in einem einzelnen Slice möglich sind.
Mit TPUs können Jobs entweder auf einem einzelnen oder auf mehreren Slices ausgeführt werden. Weitere Informationen finden Sie unter Multislice-Einführung.
Cloud TPU-Resilienz bei ICI
Die ICI-Resilienz trägt dazu bei, die Ausfallsicherheit optischer Verbindungen und optischer Schalter (Optical Circuit Switches, OCS) zu verbessern, die TPUs zwischen Kubussen verbinden. ICI-Verbindungen innerhalb eines Cubes verwenden Kupferverbindungen, die nicht betroffen sind. Durch die ICI-Ausfallsicherheit können ICI-Verbindungen um OCS- und optische ICI-Fehler herumgeleitet werden. Dadurch wird die Planungsverfügbarkeit von TPU-Scheiben verbessert, was jedoch zu einer vorübergehenden Beeinträchtigung der ICI-Leistung führt.
Ähnlich wie bei Cloud TPU v4 ist die ICI-Resilienz standardmäßig für v5p-Segmente aktiviert, die mindestens ein Würfel sind:
- v5p-128 bei Angabe des Beschleunigertyps
- 4x4x4 bei Angabe der Beschleunigerkonfiguration
Ressource in der Warteschlange
Eine Darstellung von TPU-Ressourcen, die zum Einreihen und Verwalten einer Anfrage für eine TPU-Umgebung mit einem oder mehreren Slices verwendet wird. Weitere Informationen finden Sie im Nutzerhandbuch für anstehende Ressourcen.
Bereitstellung
Beim Bereitstellen wird ein trainiertes Modell für maschinelles Lernen in einer Produktionsumgebung bereitgestellt, in der es für Vorhersagen oder Entscheidungen verwendet werden kann. Latenz und Verfügbarkeit auf Dienstebene sind für die Bereitstellung wichtig.
Einzelner Host, mehrere Hosts und untergeordneter Host
Ein TPU-Host ist eine VM, die auf einem physischen Computer ausgeführt wird, der mit TPU-Hardware verbunden ist. TPU-Arbeitslasten können einen oder mehrere Hosts verwenden.
Eine Arbeitslast mit einem einzelnen Host ist auf eine TPU-VM beschränkt. Bei einer Arbeitslast mit mehreren Hosts wird das Training auf mehrere TPU-VMs verteilt. Eine Subhost-Arbeitslast nutzt nicht alle Chips auf einer TPU-VM.
Slices
Ein Pod-Slice ist eine Sammlung von Chips, die sich alle im selben TPU-Pod befinden und über Hochgeschwindigkeits-Inter-Chip-Interconnects (ICI) verbunden sind. Slices werden je nach TPU-Version in Chips oder TensorCores angegeben.
Die Chipform und die Chiptopologie beziehen sich ebenfalls auf die Form der Slices.
SparseCore
SparseCores sind Dataflow-Prozessoren, die Modelle beschleunigen, die auf Einbettungen in Empfehlungsmodellen basieren. V5p enthält vier SparseCores pro Chip und V6e zwei SparseCores pro Chip.
TPU-Pod
Ein TPU-Pod ist eine zusammenhängende Gruppe von TPUs, die über ein spezielles Netzwerk gruppiert sind. Die Anzahl der TPU-Chips in einem TPU-Pod hängt von der TPU-Version ab.
TPU-VM oder ‑Worker
Eine virtuelle Maschine mit Linux, die Zugriff auf die zugrunde liegenden TPUs hat. Eine TPU-VM wird auch als Worker bezeichnet.
TensorCores
TPU-Chips haben einen oder zwei TensorCores, um Matrixmultiplikationen auszuführen. Weitere Informationen zu Tensor Cores finden Sie in diesem ACM-Artikel.
Worker
Weitere Informationen finden Sie unter TPU-VM.
TPU-Versionen
Die genaue Architektur eines TPU-Chips hängt von der verwendeten TPU-Version ab. Jede TPU-Version unterstützt außerdem unterschiedliche Slab-Größen und -Konfigurationen. Weitere Informationen zur Systemarchitektur und zu unterstützten Konfigurationen finden Sie auf den folgenden Seiten:
TPU-Architekturen
Es gibt zwei TPU-Architekturen, die beschreiben, wie eine VM physisch mit dem TPU-Gerät verbunden ist: TPU-Knoten und TPU-VM. TPU-Knoten war die ursprüngliche TPU-Architektur für TPU-Versionen v2 und v3. Mit Version 4 wurde die TPU-VM zur Standardarchitektur, aber beide Architekturen wurden unterstützt. Die TPU-Knotenarchitektur wird eingestellt und nur die TPU-VM wird unterstützt. Wenn Sie TPU-Knoten verwenden, lesen Sie den Hilfeartikel Von der TPU-Knotenarchitektur zur TPU-VM-Architektur wechseln, um von der TPU-Knotenarchitektur zur TPU-VM-Architektur zu wechseln.
TPU-VM-Architektur
Mit der TPU-VM-Architektur können Sie über SSH direkt eine Verbindung zur VM herstellen, die physisch mit dem TPU-Gerät verbunden ist. Sie haben Root-Zugriff auf die VM und können so beliebigen Code ausführen. Sie haben die Möglichkeit, auf Compiler- und Laufzeit-Debug-Logs sowie auf Fehlermeldungen zuzugreifen.
TPU-Knotenarchitektur
Die TPU-Knotenarchitektur besteht aus einer Nutzer-VM, die über gRPC mit dem TPU-Host kommuniziert. Bei dieser Architektur können Sie nicht direkt auf den TPU-Host zugreifen, was das Debuggen von Trainings- und TPU-Fehlern erschwert.
Von der TPU-Knoten- zur TPU-VM-Architektur wechseln
Wenn Sie TPUs mit der TPU-Knotenarchitektur verwenden, können Sie sie mit den folgenden Schritten ermitteln, löschen und als TPU-VMs neu bereitstellen.
Rufen Sie die Seite „TPUs“ auf:
- Suchen Sie unter der Überschrift Architektur nach Ihrer TPU und ihrer Architektur. Wenn die Architektur „TPU-VM“ lautet, müssen Sie nichts weiter unternehmen. Wenn die Architektur „TPU-Knoten“ lautet, müssen Sie die TPU löschen und neu bereitstellen.
Löschen Sie die TPU und stellen Sie sie neu bereit.
Eine Anleitung zum Löschen und Neubereitstellen von TPUs finden Sie unter TPUs verwalten.