What actually runs: a measurement study of language model placement and decode speed on the Apple Neural Engine
Durch eine rigorose Messstudie zur Platzierung von Sprachmodellen und der Dekodiergeschwindigkeit auf der Apple Neural Engine demonstriert der Autor, dass die komputationale Expression und die Gewichtskodierung statt der Modellarchitektur allein über die Beschleuniger-Residenz und Performance entscheiden, was zu einem Designverfahren führt, das die Kodierungseffizienz priorisiert, um signifikant kleinere und schnellere ternäre Modelle zu erreichen.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich ein Smartphone vor, das versucht, ein Gespräch zu verstehen. Um dies zu tun, muss es ein massives digitales Gehirn, ein Sprachmodell, direkt auf dem Gerät ausführen. Damit dies reibungslos funktioniert, benötigt das Telefon einen speziellen, ultraschnellen Prozessor, der genau für diese Art des Denkens gebaut wurde, anstatt seines allgemeinen, universellen Hauptgehirns. Die Herausforderung besteht darin, dass dieser spezielle Prozessor wählerisch ist; er wird nur bestimmte Arten von Berechnungen ausführen und weigert sich, andere auszuführen, selbst wenn diese mathematisch identisch sind. Jahrelang haben Entwickler versucht zu erraten, welche Berechnungen funktionieren werden und wie man sie schnell macht, wobei sie sich oft auf Faustregeln verließen, die sich als falsch herausstellten. Sie nahmen an, dass ein Modell gut genug laufen würde, wenn es klein genug sei, oder dass das Verkleinern der Zahlen immer helfen würde. Aber niemand hatte den Prozessor tatsächlich beobachtet, um zu sehen, was er wirklich tut, oder um genau zu messen, wie die Größe des Modells und die Art und Weise, wie seine Zahlen gespeichert werden, seine Geschwindigkeit veränderten.
Ein Forscher namens Shahir M A beschloss, nicht länger zu raten, sondern zu beobachten. Mit einem Apple-Computer mit einem M1-Chip baute er eine Reihe von Experimenten auf, um genau zu sehen, was passiert, wenn ein Sprachmodell versucht, auf dem speziellen Prozessor eines Telefons zu laufen, der als Neural Engine bekannt ist. Er schaute nicht nur darauf, was die Software zu tun vorgab; er maß den tatsächlichen Stromfluss und den Datendurchsatz durch den Chip, um zu sehen, was wirklich geschah. Er testete Dutzende verschiedener Wege, dieselbe mathematische Operation aufzubauen, trainierte echte Modelle unterschiedlicher Größen und änderte die Art und Weise, wie die Zahlen innerhalb dieser Modelle gespeichert wurden – von Standardpräzision bis hin zu sehr komprimierten, niederpräzisen Formaten. Sein Ziel war einfach: herauszufinden, was ein Modell tatsächlich auf den schnellen Prozessor bringt und wie schnell es sprechen kann, sobald es dort ist.
Das Erste, was er entdeckte, war, dass der Prozessor nicht darum kümmert, was eine Berechnung bedeutet, sondern nur darum, wie sie geschrieben ist. Er fand heraus, dass man, wenn man eine bestimmte Art der Normalisierung – ein Schritt, der hilft, die Zahlen des Modells stabil zu halten – auf eine bestimmte Weise schreibt, der Prozessor sie sofort akzeptiert und mit voller Geschwindigkeit ausführt. Wenn man jedoch denselben mathematischen Schritt mit einem etwas komplizierteren Satz von Anweisungen schreibt, weigert sich der Prozessor, ihn anzufassen, und zwingt das Telefon dazu, sein langsameres, allgemeines Gehirn zu benutzen. Es ist, als ob der Prozessor einen spezifischen mathematischen Dialekt spricht; wenn man den richtigen Dialekt verwendet, hört er zu, aber wenn man einen anderen verwendet, selbst wenn die Bedeutung dieselbe ist, geht er weg. Das bedeutet, dass die Art und Weise, wie ein Entwickler den Code schreibt, genauso wichtig ist wie die Mathematik selbst.
Die zweite, und vielleicht überraschendste, Erkenntnis war, dass die Größe des Modells nicht das Einzige ist, was entscheidet, ob es auf dem schnellen Prozessor laufen kann. Die Forscher fanden heraus, dass ein Modell mit etwa sechsundzwanzig Millionen Parametern, geschrieben in Standardpräzision, zu klein war, um auf dem speziellen Prozessor zu laufen. Es wurde gezwungen, auf dem langsamen Gehirn zu laufen, was über eine Sekunde dauerte, um jedes Wort zu generieren. Doch als sie genau dieses Modell nahm und die Zahlen darin komprimierten, um weniger Bits zu verwenden, akzeptierte der Prozessor es plötzlich. Die komprimierte Version lief auf dem schnellen Prozessor und generierte Wörter in weniger als einer Sekunde. Tatsächlich war für kleinere Modelle die Komprimierung der Zahlen der einzige Weg, sie überhaupt auf den schnellen Prozessor zu bringen. Der Prozessor hatte eine versteckte Regel: Er würde kleine Modelle nicht ausführen, es sei denn, sie waren komprimiert. Dies kehrte die gängige Annahme um, dass größere Modelle immer den schnellen Prozessor benötigen; hier brauchten die kleinen Modelle die Kompression, um überhaupt durch die Tür zu kommen.
Sobald das Modell im schnellen Prozessor war, wurde die Geschwindigkeit fast ausschließlich davon bestimmt, wie viele Daten bewegt werden mussten, nicht durch die Komplexität der Mathematik. Die Forscher maßen den Datenfluss und fanden heraus, dass das Modell für jedes Wort, das es generierte, den gesamten Satz seiner Gewichte – also der Zahlen, die sein Wissen ausmachen – durch den Prozessor streamen musste. Dies geschah für jedes einzelne Wort, egal wie lang das Gespräch war. Aus diesem Grund war die Geschwindigkeit direkt an die Anzahl der Bits in diesen Gewichten gekoppelt. Ein Modell mit komprimierten, niederpräzisen Zahlen bewegte viel weniger Daten und war daher viel schneller. Sie fanden heraus, dass ein Modell mit Zwei-Bit-Zahlen fast dreimal schneller war als ein Modell mit Standardzahlen, einfach weil es weniger Daten bewegen musste. Die Art der Mathematik, die das Modell verwendete, wie zum Beispiel, ob es sich mehr auf Attention oder auf Convolution konzentrierte, spielte für die Geschwindigkeit eine sehr geringe Rolle, sobald es bereits auf dem Prozessor lief. Das Einzige, was zählte, war die Menge der bewegten Daten.
Die Forscher kamen zu dem Schluss, dass der beste Weg, ein Sprachmodell für ein Telefon zu bauen, darin besteht, mit der Kompression zu beginnen, nicht mit der Größe. Anstatt ein großes Modell zu bauen und dann zu versuchen, es zu schrumpfen, sollte man zuerst das am stärksten komprimierte Format wählen und dann das verfügbare Speicherbudget nutzen, um mehr Parameter hinzuzufügen. Sie fanden heraus, dass ein Modell mit fünfundzwanzig Millionen Parametern, das eine spezifische Art von komprimierter Mathematik verwendet, nur zehn Megabyte Platz beanspruchen und Wörter in etwa sechs Zehntel Millisekunden generieren konnte. Dies war fast zehnmal kleiner und dreimal schneller als die Standardmodelle mit unkomprimierten Zahlen, mit denen Entwickler normalerweise beginnen. Die Studie zeigte, dass der Weg zu einem schnellen, auf dem Gerät laufenden Sprachmodell nicht darin besteht, das Modell größer oder komplexer zu machen, sondern die richtige Art der mathematischen Formulierung und die richtige Art der Datenspeicherung zu wählen. Durch die Messung des tatsächlichen Datenflusses bewiesen sie, dass der Schlüssel zur Geschwindigkeit nicht nur ein schneller Prozessor ist, sondern zu wissen, wie man ihn genau füttert.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.