Inhaltsverzeichnis

Corsica

Microsoft schilderte auf der Hot Chips die Hintergründe, die zur Entwicklung des hauseigenen Spezialchips Corsica geführt haben: Sämtliche Nutzerdaten eines Cloud-Servers müssen vor dem Speichern komprimiert und individuell verschlüsselt werden. Sollen Daten von Storage-System geholt werden, fallen die rechenintensiven Schritte in umgekehrter Reichenfolge an. Der Bedarf für einen Beschleuniger besteht in allen Azure-Servern, und die Anforderungen an die Hardware sind relativ gering – beste Voraussetzungen für die Entwicklung eines genau dafür bestimmten ASICs.

Corsica macht denn auch nichts anderes als die eben genannten Schritte. Der Chip wird per NVMe angesprochen und kommt ohne lokalen Speicher aus: Sämtliche Nutzdaten werden als Stream durchgeschoben. Neben einem hohen Datendurchsatz und einer geringen Latenz stand eine gleichzeitig extrem geringe Fehlerrate im Pflichtenheft.

Um auch bei einer Datenrate von 100 GBit/s etwa von Alpha-Teilchen ausgelöste Bit-Flips zu erkennen, wurden zwei Sicherungen integriert. So werden die Daten nach Kompression und Verschlüsselung beiseitegelegt und gleich wieder on-chip entschlüsselt und entpackt. Nur wenn eine dann generierte Checksumme mit der übereinstimmt, die beim Eingang der Daten erstellt wurde, werden die verschlüsselten, komprimierten Daten ausgegeben.

Zusätzlich sind zwei baugleiche Schlüsselgeneratoren involviert, die mit demselben Input gefüttert werden. Zur Verschlüsselung wird der Schlüssel von einem Generator verwendet, zur on-chip-Entschlüsselung für die Checksummenprüfung kommt der – im Regelfall identische – Schlüssel des anderen Generators zum Einsatz. Damit stellt Microsoft sicher, dass die Daten nicht versehentlich mit einem Bitfehler-behafteten Schlüssel gesichert wurden und später auch garantiert wieder korrekt entschlüsselt werden können.

TPU v3

Googles Vortrag zum hauseigenen KI-Beschleuniger TPU v3 predigte die Prämisse, dass Hardware-Designer sich doch möglichst mit involvierten Parteien wie KI-Spezialisten oder Server-Integratoren zusammensetzen sollten, um einen möglichst optimalen Spezialchip zu entwickeln. Im Laufe der Präsentation wurde indirekt klar, dass dies Google-intern bei der allerersten TPU wohl anders gelaufen sein muss: TPU v1 und TPU v2 unterscheiden sich recht deutlich.

So schrumpfte bei dem Generationswechsel der Matrix-Multiplizierer recht deutlich von 256 × 256 auf 128 × 128 – bei der ersten Version waren die praktischen Einschränkungen hinsichtlich Stromverbrauch, Latenz, Datendurchsatz etc. wohl größer als der Nutzwert des riesigen Arrays. Die aktuelle TPU v3 ist vom Chipdesign her denn auch eher ein TPU v2.5: Abgesehen von größeren Speicher wurde pro Kern lediglich ein zweiter Matrix-Multiplizierer integriert.

Alle anderen Veränderungen haben mit dem Gesamtsystem zu tun. So gibt es eine Wasserkühlung, um eine höhere Packdichte im Serverrack zu erreichen. Zudem wurde an der Vernetzung der einzelnen TPUs über Mainboardgrenzen hinaus gearbeitet: Es sind sowohl größere Verbände möglich als auch eine granularere Partitionierung. Der Latenz zuliebe ist der Netzwerkchip auch nicht mehr separat, sondern ebenfalls Teil der TPU geworden.

Zu einer möglichen TPU v4 wollten beziehungsweise durften die anwesenden Google-Mitarbeiter nichts sagen. Sie ließen einzig und allein durchblicken, dass sie derzeit bei allen verwendeten KI-Modellen sehr gut mit der 128-×-128-Matrixeinheit zurechtkommen und es somit keinen Bedarf gäbe, daran etwas zu ändern. (mue)