- Google TPU v1 ist ein ASIC, das Ende 2013 entwickelt und in 15 Monaten fertiggestellt wurde, um die Kosten und den Umfang der Inferenz für Deep-Learning-Dienste zu bewältigen, mit dem Ziel einer 10-fach besseren Preis-Leistung als GPUs
- Der Kern ist die Umsetzung des systolischen Arrays aus dem Jahr 1978 von H.T. Kung und Charles E. Leiserson als 256×256-MAC-Struktur, wodurch Speicher-Roundtrips für Zwischenergebnisse bei Matrixmultiplikationen reduziert werden
- TPU v1 kommuniziert per PCIe mit dem Host und speichert Gewichte in DDR3-2133; der Inferenzablauf wird mit wenigen Befehlen wie
Read_Host_Memory, Read_Weights, Matrix_Multiply / Convolve, Activate und Write_Host_Memory aufgebaut
- Mit 8-bit×8-bit-Ganzzahlmultiplikation und Quantisierung wurde der Flächenbedarf von Floating-Point-Berechnungen auf dem Die vermieden; User Space Driver und Kernel Driver, die mit TensorFlow gekoppelt sind, steuern die Ausführung
- Intel-Haswell-CPUs und Nvidia-K80-GPUs waren damals die Vergleichsmaßstäbe; TPU v1 war bei der Inferenz etwa 15–30-mal schneller und bot gegenüber GPUs eine 25–29-mal höhere relative inkrementelle Leistung pro Watt, war jedoch kein Gerät für Training
Ausgangspunkt von TPU v1 zur Senkung der Inferenzkosten
- Das Ziel des TPU-v1-Projekts war, schnell einen ASIC für Inferenz zu bauen, um die hohen Hardwarekosten großskaliger Deep-Learning-basierter Dienste zu senken
- Das Ziel war eine 10-fach bessere Preis-Leistung bei der Inferenz im Vergleich zu GPUs
- Gefordert waren schnelle Entwicklung, hohe Leistung, großflächiger Einsatz, sofortige Unterstützung neuer Workloads und Kosteneffizienz
- Der Name TPU stammt daher, dass es sich um ein Gerät zur Beschleunigung von Tensor-Operationen handelt
- Die zentralen Berechnungen, die die tatsächliche TPU-v1-Hardware ausführt, sind vor allem Vektor- und Matrixoperationen
- Verborgene Schichten und Ausgabeschichten neuronaler Netze lassen sich als Ergebnis der Anwendung einer Aktivierungsfunktion auf das Produkt aus Eingabevektor und Gewichtsmatrix darstellen
- Bei mehreren Eingabedaten wird auf jeden Eintrag des Matrixmultiplikationsergebnisses eine Aktivierungsfunktion angewendet
Verarbeitung von Matrixmultiplikationen mit systolischen Arrays
- TPU v1 nutzt das Konzept des systolischen Systems aus der Arbeit Systolic Arrays (for VLSI) von H.T. Kung und Charles E. Leiserson aus dem Jahr 1978
- Es ist eine Struktur, in der mehrere Prozessoren Daten in einem regelmäßigen Rhythmus berechnen und weiterreichen
- Jeder Prozessor führt kurze Berechnungen aus und bewegt dabei kontinuierlich Daten nach innen und außen
- Bei einer einfachen 2×2-Matrixmultiplikation entstehen die Ergebnisse natürlich aus einem 2×2-MAC-Array, wenn Eingabewerte von oben und links in der richtigen Reihenfolge eingespeist werden
- Jeder MAC führt Multiplikation und Akkumulation aus
- Teilsummen werden im Array gespeichert, und das Endergebnis erscheint in Form einer wandernden Diagonale
- Das 2×2-Beispiel benötigt 4 Schritte, aber in der Praxis kann, sobald der MAC oben links frei wird, sofort die nächste Matrixmultiplikation beginnen, sodass alle 2 Zyklen eine neue Matrixmultiplikation möglich ist
- Entscheidend ist, dass der Fluss von Werten und Ergebnissen selbst die benötigte Berechnungsreihenfolge erzeugt, wenn Daten in der richtigen Reihenfolge in das systolische Array eingespeist werden
- Zwischenergebnisse müssen nicht im Hauptspeicher gespeichert und später wieder geladen werden
- Durch die Struktur der Matrixmultiplikationseinheit und die Eingabereihenfolge stehen Zwischenergebnisse automatisch genau dann bereit, wenn sie benötigt werden
Systemaufbau von TPU v1
- TPU v1 kommuniziert mit dem Host-Computer über den schnellen seriellen Bus PCIe und greift direkt auf eigenes DDR3-DRAM zu
- Die wichtigsten Komponenten sind:
- DDR3 DRAM / Weight FIFO
- Gewichte werden in DDR3-RAM-Chips gespeichert, die über eine DDR3-2133-Schnittstelle angebunden sind
- Nach dem Vorabladen aus dem Host-Speicher über PCIe werden sie in die Weight FIFO verschoben, damit die Matrix Multiply Unit sie verwenden kann
- Matrix Multiply Unit
- Ein systolisches Array aus 256×256 MACs
- Es empfängt 256 Gewichte von oben und 256 Dateneingaben von links
- Accumulators
- Sie speichern die Ergebnisse, die aus dem systolischen Matrix-Array an der Unterseite herauskommen
- Activation
- Dies ist die Stufe, die die Aktivierungsfunktion des neuronalen Netzes anwendet
- Unified Buffer / Systolic Data Setup
- Speichert die Ergebnisse nach Anwendung der Aktivierungsfunktion und bereitet ihre erneute Einspeisung als Eingabe für die Matrix Multiply Unit zur Berechnung der nächsten Schicht vor
Zahlenformat und Befehlssatz
- Die Matrix Multiply Unit von TPU v1 führt 8-bit×8-bit-Ganzzahlmultiplikation aus
- Durch Quantisierung werden Floating-Point-Berechnungen vermieden, die eine größere Die-Fläche benötigen
- Der Befehlssatz ist ein CISC-Design mit rund 20 Befehlen
- Die Befehle werden nicht aus dem Speicher geholt, sondern vom Host-Computer über PCIe gesendet
- Der Großteil des Inferenzablaufs besteht aus fünf Hauptbefehlen
Read_Host_Memory
- Liest Eingabewerte aus dem Host-Speicher über PCIe in den Unified Buffer
Read_Weights
- Liest Gewichte aus dem Gewichtsspeicher in die Weight FIFO
Matrix_Multiply / Convolve
- Sendet Eingaben aus dem Unified Buffer an die Accumulators und führt Matrixmultiplikation oder Faltung aus
- Multipliziert B×256-Eingaben mit konstanten 256×256-Gewichten und erzeugt B×256-Ausgaben; dafür werden B Pipeline-Zyklen benötigt
Activate
- Wendet nichtlineare Funktionen künstlicher Neuronen wie ReLU oder Sigmoid auf die Eingaben der Accumulators an und schreibt das Ergebnis in den Unified Buffer
Write_Host_Memory
- Schreibt die Ergebnisse aus dem Unified Buffer über PCIe in den Host-Speicher
- Dieser Ablauf kann grob wie folgt dargestellt werden
Read_Host_Memory
Read_Weights
Loop_Start
Matrix_Multiply
Activate
Loop_End
Write_Host_Memory
- Die Matrixeinheit verwendet systolische Ausführung, um Lese- und Schreibzugriffe auf den Unified Buffer zu reduzieren und so Energie zu sparen
- Daten kommen von links hinein, Gewichte werden von oben geladen
- MAC-Operationen mit 256 Elementen laufen wie eine diagonale Wellenfront durch die Matrix
TensorFlow und der Treiber-Stack
- Damit TPU-v1-Hardware in realen Diensten eingesetzt werden konnte, war ein unterstützender Software-Stack erforderlich
- Da Google TensorFlow entwickelte und nutzte, war die Entwicklung von Treibern, damit TensorFlow mit TPU v1 funktioniert, ein zentraler Schritt
- Der TPU-Software-Stack musste mit den Stacks für CPU und GPU kompatibel sein
- Anwendungen mussten sich schnell auf TPU portieren lassen
- Die auf TPU laufenden Teile einer Anwendung werden in der Regel in TensorFlow geschrieben und in eine API kompiliert, die auf GPU oder TPU ausgeführt werden kann
- Wie bei GPUs ist auch der TPU-Stack in User Space Driver und Kernel Driver aufgeteilt
- Der Kernel Driver bleibt schlank, übernimmt nur Speicherverwaltung und Interrupts und zielt auf langfristige Stabilität
- Der User Space Driver ändert sich häufig und ist zuständig für die Konfiguration und Steuerung der TPU-Ausführung, die Umformatierung von Daten passend zur TPU-Reihenfolge, die Umwandlung von API-Aufrufen in TPU-Befehle und die Erzeugung von Application Binaries
28-nm-Prozess und Die-Layout
- TPU v1 wurde im vergleichsweise ausgereiften 28-nm-Prozess von TSMC gefertigt
- Die damals in Googles Rechenzentren eingesetzten Intel-Haswell-CPUs und Nvidia-K80-GPU-Chips wurden in fortschrittlicheren Prozessen hergestellt
- Laut Google beträgt die Die-Fläche von TPU v1 weniger als die Hälfte der Die-Fläche dieser Chips
- Die einfache ISA reduzierte den Die-Overhead für Dekodierung und verwandte Aufgaben
- Der Bereich
control nimmt nur 2 % der Die-Fläche ein
- Die Matrix Multiply Unit belegt 24 %, der Unified Buffer 29 %
Leistungsvergleich und klare Grenzen
- TPU v1 ist ein Gerät für Inferenz, das bereits trainierte Modelle in realen Diensten im Google-Maßstab effizienter nutzen soll
- Es wurde nicht entwickelt, um Trainingsgeschwindigkeit oder Trainingseffizienz zu verbessern
- Inferenz und Training stellen bei der Entwicklung spezialisierter Hardware unterschiedliche Anforderungen
- Im Jahr 2013 waren Intel-Haswell-CPUs und Nvidia-K80-GPUs die zentralen Vergleichsmaßstäbe
- TPU v1 hat 25-mal so viele MACs wie die K80-GPU
- TPU v1 hat 3,5-mal so viel On-Chip-Speicher wie die K80-GPU
- TPU v1 ist bei der Inferenz etwa 15–30-mal schneller als K80-GPU und Haswell-CPU
- Die relative inkrementelle Leistung pro Watt gegenüber GPUs liegt bei 25–29-mal
- Dank der maßgeschneiderten Architektur erreichte TPU v1 damals eine höhere Inferenzleistung und einen geringeren Energieverbrauch als CPUs und GPUs
- Da das Design der ersten Generation konsequent auf das eine Ziel schneller Inferenz und hoher Energieeffizienz ausgerichtet war, blieb die Einschränkung bestehen, dass es nicht für Training ausgelegt war
1 Kommentare
Meinungen auf Hacker News
Groq-CEO Jonathan Ross erzählte kürzlich in einem Podcast-Interview, wie die frühen TPUs bei Google entstanden: Ursprünglich sei es ein FPGA gewesen, den er in seiner 20-%-Zeit baute, nachdem er in der Nähe eines Teams gesessen hatte, das Probleme mit der Inferenzgeschwindigkeit hatte.
Nachdem ein funktionierendes System entstanden war, habe Jeff Dean nachgerechnet und entschieden, auf ein ASIC zu gehen.
Aus heutiger Sicht sollte Google das TPU-Team als eigenständiges Unternehmen ausgliedern. Es ist der einzige wirklich glaubwürdige Konkurrent zu Nvidia, und auch beim Software-Support liegt es direkt hinter Nvidia.
https://open.spotify.com/episode/0V9kRgNS7Ds6zh3GjdXUAQ?si=q...
Aber jeder dieser Punkte hat Schwächen. Foundry-Kapazitäten sind knapp, aber Nvidia kann den Markt für Consumer-GPUs opfern, wenn sich teurere AI-Chips verkaufen lassen. Wenn ein Wettbewerber schon vor einigen Jahren groß darauf gesetzt hat oder ein Unternehmen mit viel Fertigungskapazität wie Intel seine Prioritäten ändert, verschwindet dieser Vorteil.
Proprietäre Software als Industriestandard ist bequem, aber ihre tatsächliche Bedeutung hängt stark vom Anwendungsfall ab. Das Hardware-Design für TPUs wirkt grundsätzlich deutlich einfacher als das von GPUs: Man braucht kein Raytracing, keine Texture Sampler und keine Rasterisierung, sondern vor allem Matrixmultiplikation und viel Speicher.
Kundenbeziehungen helfen dabei, in Gesprächen ständig präsent zu sein. In einem Markt, der nach jedem kleinen Vorteil sucht, wird aber der Hardwareanbieter mit den meisten FLOPS pro Dollar genug Kunden finden, um seine Produktionskapazität auszulasten. Deshalb dürfte Wettbewerb in ein paar Jahren ziemlich schnell Realität werden.
Allerdings sind TPUs auch intern bei Google eine vergleichsweise knappe Compute-Ressource, und es dürfte schon schwierig sein, die interne Nachfrage zu decken.
Ich sage fast nie, dass ich ein Unternehmen so sehr respektiere, aber Groq respektiere ich wirklich.
Google hat die TPU erfunden, und Google Research hat sogar LLM-Paper veröffentlicht. Ich verstehe nicht, warum NVDA und AI-Startups fast 100 % des Werts abgeschöpft haben.
Auf Google übertragen: Wenn jemand vorschlägt, etwas wie ChatGPT breit bereitzustellen, könnte das bezahlte Platzierungen in der Suche und Werbeumsätze von Websites kannibalisieren, die Nutzer dann gar nicht mehr besuchen müssen. Deshalb könnte die Entscheidung gewesen sein, es nur dann vorsichtig und weniger disruptiv einzuführen, wenn der Wettbewerb es erforderlich macht.
In Wirklichkeit ist es sicher nicht so einfach, aber wenn das der Grund wäre, wäre es ziemlich lustig.
https://www.linkedin.com/posts/eolver_googles-defense-agains...
Ich arbeite bei Google; wenn ihr euch TPUs eine Weile nicht angesehen habt, schaut euch v5 an. Inzwischen werden PyTorch/JAX unterstützt, wodurch sie viel einfacher zu nutzen sind als zu der Zeit, als sie nur für TensorFlow gedacht waren.
Dieser Artikel hat gut verbunden, wie mehrere abstrakt verstreute Puzzleteile tatsächlich im Silizium fließen.
Besonders gut fand ich zu sehen, dass einfache CISC-Befehle fast direkt den Schritten der LLM-Inferenz entsprechen.
Vielleicht ist das eine dumme Frage, die nur zeigt, dass ich mich nicht gut auskenne, aber im Consumer-Bereich hört man immer wieder, dass M1- bis M4-Chips für manche AI-Aufgaben gut seien.
Was mir derzeit am wichtigsten ist, sind Tools wie Photoshop und Resolve, und ich habe gesehen, dass sie auf Apples neuen eigenen Chips viel schneller laufen als auf meiner alten Maschine.
Das lässt sich vielleicht nicht gut auf das übertragen, was diese Chips oder ein H100 leisten können, aber ich frage mich, ob es sich zumindest teilweise übertragen lässt. Natürlich verkauft Apple seine eigenen Chips nicht separat; für eine praktische Umsetzung müssten sie also wohl eine Art externen Server mit vielen GPUs und AI-Chips anbieten.
M*-Chips nutzen Unified Memory, und insbesondere Pro/Max/Ultra haben im Vergleich zu GPUs wie einer 1080 eine sehr hohe Speicherbandbreite. Die Speicherbandbreite des M1 Ultra liegt ungefähr zwischen einer 2080 und einer 3090.
Bei kleinen Batch-Größen, besonders bei Batch 1 wie bei den meisten lokalen Aufgaben, wird Inferenz eher durch Speicherbandbreite als durch Rechenleistung begrenzt. Daher kommt die Aussage, dass M*-Chips gut für Machine Learning seien.
H100 wird jedoch vor allem für Training mit riesigen Batch-Größen eingesetzt, und um große Modelle zu trainieren, braucht man viel Interconnect. In diesem Maßstab ist die arithmetische Intensität sehr hoch; selbst wenn man M*-Chips vernetzen könnte, wären sie nicht besonders konkurrenzfähig. Sie wählen einfach einen anderen Punkt auf der Leistungs-/Effizienz-Pareto-Kurve als ein stromhungriger Chip wie H100.
Was Google wirklich tun muss, ist in den Bereich von 2 nm EUV vorzustoßen und unter 2 nm zu kommen.
Wenn sie so etwas hätten – ob Elektronenlithografie oder die Technik, mit der ASML Strukturen auf Chips bringt –, wären sie wirklich gefährlich. Dafür bräuchte es wohl ein Hardcore-Moonshot-Projekt im Stil von Google X.
Oder vielleicht haben sie ja rund 500 Millionen Dollar übrig, um eine einzelne Anlage zu kaufen. Wenn TPUs wirklich so gut sind, könnte es ein gutes Geschäft sein, vertikal bis hin zu eigener Technologie und eigener Fab zu integrieren.
Dass moderne Fabs heute Gewinn machen, liegt daran, dass sie universelle Computing-Bausteine für viele verschiedene Kunden und Anwendungen herstellen, gestützt auf über Jahrzehnte aufgebautes Talent und Engineering. Außerdem treiben die Kunden unabhängig voneinander Innovationen in Schlüsselbereichen voran, etwa Microns Verbesserungen der Chip-on-Chip-HDI-Ausbeute oder Xilinx’ Kommunikations-Fabric zwischen Dies und Multi-Chip-Substratdesigns.
TPUs können niemals die nötigen Stückzahlen erzeugen und auch keine Kunden anziehen, die profitable Skaleneffekte ermöglichen. Google müsste außerdem gegenüber Wettbewerbern attraktive Preise bieten.
Wenn der Business Case überzeugend genug wäre, würden bestehende Fabs ihnen bereitwillig Kapazität zuteilen. TPUs sind davon noch weit entfernt.
Ich habe einen Vortrag von Jim Keller von Tenstorrent gehört, in dem er einen anderen Ansatz zum Bau von AI-Cores erklärt hat. Dabei werden fünf RISC-V-Cores verwendet: einer zum Laden von Daten, einer zum Hochladen von Daten, die übrigen speziell für Matrixoperationen.
Er erwähnte auch Googles TPU und sagte, die Programmierung fühle sich an, als würde man mit VLIW arbeiten, und etwa 500 Leute seien am Compiler beteiligt gewesen.
Im Original steht, „TPU v1 ist ein CISC-Design mit nur etwa 20 Befehlen“, und ich finde es witzig, wie CISC/RISC offenbar von einer scharfsinnigen Beobachtung über ein Forschungsprogramm, eine revolutionäre Technologie und ein Marketing-Buzzword schließlich bei völlig bedeutungslosem Gerede angekommen ist.
Man könnte es wohl den Lebenszyklus eines Begriffs nennen.
Daher könnte eine TPU CISC sein, wenn die einzelnen Befehle ziemlich komplex sind, auch wenn es nur wenige davon gibt. Allerdings habe ich Rechnerarchitektur zuletzt vor 15 Jahren in einem Graduiertenkurs gehört, daher ist meine Erinnerung unscharf. Außerdem haben wir den größten Teil des Semesters mit Arbeiten zu Itanium verbracht, was inzwischen nutzlos geworden ist.
Die Nachfrage nach Foundry-Kapazität scheint enorm zu sein, daher frage ich mich, wie Microsoft oder Google ganz nach vorne in die Schlange kommen, wenn sie eigene Chips entwickeln und Produktion brauchen.
Sind die Chips einfach genug, dass sie auch in „älteren, weniger nachgefragten“ Fabs hergestellt werden können? Soweit ich weiß, haben Apple und Nvidia bereits viel Foundry-Kapazität gebucht.
https://en.wikipedia.org/wiki/Tensor_Processing_Unit#Product...
Auch in Bereichen wie HBM haben sie eine beträchtliche Präsenz und geben viel aus; SemiAnalysis hat dazu einige gute Artikel.
Ich frage mich, wie sich Hardware verändern wird, wenn sich bei LLMs wirklich -1, 0, 1-Quantisierung in großem Stil durchsetzt.