When NPUs Are Not Always Faster: A Stage-Level Analysis of Mobile LLM Inference

Stellen Sie sich vor, Ihr Smartphone ist eine belebte Küche, die versucht, ein komplexes Gericht zuzubereiten (ein Large Language Model, oder LLM). Die Küche verfügt über zwei Hauptköche: einen CPU (einen vielseitigen, erfahrenen Küchenchef, der hervorragend beim Schneiden und Organisieren ist) und eine NPU (einen spezialisierten, hochgeschwindigkeitsfähigen Roboterarm, der speziell für repetitive, schwere Hebearbeiten konzipiert wurde).

Lange Zeit ging man davon aus, dass der Roboterarm (NPU) aufgrund seiner Bauweise für KI immer schneller sein würde. Dieses Papier zieht jedoch den Vorhang auf und zeigt, dass der Roboterarm nicht immer der schnellere Koch ist. Tatsächlich kann der menschliche Koch je nachdem, welchen Teil des Gerichts Sie zubereiten, sogar besser sein.

Hier ist die Aufschlüsselung ihrer Erkenntnisse unter Verwendung einfacher Analogien:

1. Die zwei Phasen des Kochens

Das Papier erklärt, dass die Textgenerierung in zwei sehr unterschiedlichen Phasen stattfindet, ähnlich wie zwei verschiedene Teile eines Kochprozesses:

• Die „Prefill"-Phase (Lesen des Rezepts): Dies ist der Moment, in dem das Telefon Ihren gesamten Prompt (den Eingabetext) auf einmal liest. Es ist, als würde man ein ganzes Kapitel eines Kochbuchs lesen. Dies erfordert massive, schwere Hebearbeiten (das gleichzeitige Durchführen vieler Berechnungen).

  • Die Erkenntnis: Der CPU (menschliche Koch) gewinnt hier. Der Roboterarm (NPU) ist in dieser Phase tatsächlich langsamer (bis zu 1,6-mal langsamer).
  • Warum? Der Roboterarm hat einen kleinen Arbeitsbereich (Speicher) und ist für diese spezifische Art von „schwerer Hebearbeit" noch nicht optimiert. Der menschliche Koch verfügt über eine größere Arbeitsfläche und bessere Werkzeuge für diese spezielle Aufgabe.

• Die „Decode"-Phase (Schreiben des Gerichts): Dies ist der Moment, in dem das Telefon ein Wort nach dem anderen generiert. Es ist, als würde der Roboterarm eine Garnitur auf einen Teller legen und dann auf die nächste Bestellung warten. Dies ist eine speicherintensive Aufgabe, keine Aufgabe der schweren Hebearbeit.

  • Die Erkenntnis: Die NPU (Roboterarm) ist hier schneller, aber nur geringfügig (etwa 5 % bis 20 % schneller).
  • Warum? Der Roboterarm ist gut darin, Daten geradeaus zu bewegen, was zu diesem „eins-nach-dem-anderen"-Stil passt. Die Geschwindigkeitssteigerung ist jedoch nicht enorm, da andere Probleme vorliegen (siehe unten).

2. Das „Taxi"-Problem (Planungs-Overhead)

Selbst wenn der Roboterarm beim eigentlichen Kochen schneller ist, stellte das Papier fest, dass der Prozess der Übertragung der Arbeit an den Roboter unglaublich langsam ist.

• Die Analogie: Stellen Sie sich vor, der menschliche Koch muss den Roboterarm am Telefon anrufen, warten, bis er abhebt, die Aufgabe erklären, die Zutaten übergeben, warten, bis der Roboter fertig ist, und dann das Ergebnis zurückbekommen.
• Die Realität: Bei kleinen, schnellen Aufgaben (wie dem Hinzufügen einer Prise Salz) dauert die Zeit für den Anruf und die Übergabe 8 bis 22-mal länger als die eigentliche Kochzeit.
• Das Ergebnis: Da der Roboterarm so oft „angerufen" werden muss, um einen einzigen Satz zu generieren, frisst all diese Wartezeit den Geschwindigkeitsvorteil auf. Es ist, als hätte man einen Ferrari, der 90 % seiner Zeit im Stau steht.

3. Die „falsches Werkzeug"-Strafe (Fallback)

Manchmal weiß der Roboterarm nicht, wie er eine bestimmte Aufgabe erledigen soll (wie einen komplexen Aufmerksamkeitsmechanismus).

• Die Analogie: Der Roboterarm versucht, ein Gemüse zu schneiden, merkt, dass er es nicht kann, und muss es an den menschlichen Koch zurückgeben. Da sie sich jedoch in verschiedenen Teilen der Küche befinden, muss der menschliche Koch sich die Hände waschen, hinübergehen und von vorne beginnen.
• Die Realität: Wenn die NPU eine Aufgabe nicht erledigen kann, weicht sie auf die CPU aus. Diese „Übergabe" fügt eine zusätzliche Verzögerung hinzu (etwa 1,5-mal langsamer), da die beiden Teile des Telefons ihre Daten synchronisieren müssen. Dies verlangsamt den gesamten Prozess.

4. Die Energie-Überraschung

Man könnte denken, dass die Nutzung des spezialisierten Roboterarms Batterie spart.

• Die Erkenntnis: Überraschenderweise entlädt die Nutzung der NPU die Batterie tatsächlich schneller (in einigen Fällen um bis zu 51 % mehr).
• Warum? Da das Telefon so viel Zeit und Energie damit verbringt, die „Telefonate" zwischen CPU und NPU zu verwalten und mit Fallback-Fehlern umzugehen, erhöht sich die Gesamtzeit, in der das Telefon arbeitet. Es ist, als würde man einen Marathon laufen und dabei ständig anhalten, um die Schuhe zu binden; am Ende verbraucht man mehr Energie, als wenn man einfach in einem gleichmäßigen Tempo gelaufen wäre.

Das Fazit: Was sollten Designer tun?

Die Autoren schlagen drei Regeln für die Entwickler vor, die diese Telefonchips bauen:

1. Kennen Sie Ihre Phasen: Senden Sie nicht einfach alles an den Roboter. Lassen Sie den menschlichen Koch (CPU) das „schwere Lesen" (Prefill) übernehmen und senden Sie nur das „eins-nach-dem-anderen Schreiben" (Decode) an den Roboter.
2. Stoppen Sie die Staus: Der Roboter muss Anweisungen sofort (unter 10 Mikrosekunden) akzeptieren können. Wir müssen die „Telefonanruf"-Verzögerungen stoppen.
3. Bringen Sie dem Roboter mehr Tricks bei: Der Roboter muss lernen, alle Aufgaben zu erledigen, damit er den menschlichen Koch nicht ständig um Hilfe bitten muss.

Kurz gesagt: Die NPU ist ein leistungsstarkes Werkzeug, aber auf aktuellen Mobiltelefonen wird sie oft durch schlechtes Management und Kommunikationsverzögerungen zurückgehalten. Manchmal ist der „altmodische" CPU tatsächlich die effizientere Wahl.