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

Stel je voor dat je smartphone een drukke keuken is die probeert een complex gerecht te bereiden (een Large Language Model, of LLM). De keuken heeft twee hoofdkoks: een CPU (een veelzijdige, ervaren sous-chef die uitstekend is in hakken en organiseren) en een NPU (een gespecialiseerde, hoogwaardige robotarm die specifiek is ontworpen voor repetitief, zwaar tillen).

Lange tijd werd aangenomen dat de robotarm (NPU) altijd sneller zou zijn omdat deze voor AI is gebouwd. Dit artikel trekt echter de gordijnen open om te laten zien dat de robotarm niet altijd de snellere kok is. Sterker nog, afhankelijk van welk onderdeel van het gerecht je maakt, kan de menselijke kok eigenlijk beter zijn.

Hier is de uiteenzetting van hun bevindingen met behulp van eenvoudige analogieën:

1. De twee fasen van koken

Het artikel legt uit dat het genereren van tekst gebeurt in twee zeer verschillende fases, zoals twee verschillende onderdelen van een kookproces:

• De "Prefill"-fase (Het recept lezen): Dit is het moment waarop de telefoon je volledige prompt (de invoertekst) in één keer leest. Het is alsof je een heel hoofdstuk uit een kookboek leest. Dit vereist massaal, zwaar tillen (vele berekeningen tegelijkertijd uitvoeren).

  • De bevinding: De CPU (Menselijke Kok) wint hier. De robotarm (NPU) is op dit stadium eigenlijk trager (tot 1,6 keer trager).
  • Waarom? De robotarm heeft een kleine werkruimte (geheugen) en is nog niet geoptimaliseerd voor dit specifieke type "zwaar tillen". De menselijke kok heeft een groter aanrecht en betere tools voor deze specifieke klus.

• De "Decode"-fase (Het gerecht schrijven): Dit is het moment waarop de telefoon één woord per keer genereert, achter elkaar. Het is alsof de robotarm één garnering op een bord legt, en dan wacht op de volgende bestelling. Dit is een geheugentijdsintensieve taak, geen zwaar-tillende taak.

  • De bevinding: De NPU (Robotarm) is hier sneller, maar slechts een beetje (ongeveer 5% tot 20% sneller).
  • Waarom? De robotarm is goed in het verplaatsen van data in een rechte lijn, wat past bij deze "één voor één"-stijl. De snelheidswinst is echter niet groot vanwege andere problemen (zie hieronder).

2. Het "Taxi"-probleem (Scheduling-overhead)

Zelfs wanneer de robotarm wel sneller is bij het daadwerkelijke koken, stelde het artikel vast dat het proces om het werk naar de robot te sturen ontzettend traag is.

• De analogie: Stel je voor dat de menselijke kok de robotarm moet bellen via een telefoon, moet wachten tot hij opneemt, de taak moet uitleggen, de ingrediënten moet overhandigen, moet wachten tot de robot klaar is, en vervolgens het resultaat moet terugkrijgen.
• De realiteit: Voor kleine, snelle taken (zoals een snufje zout toevoegen), duurt de tijd die wordt besteed aan het telefoontje en de overdracht 8 tot 22 keer langer dan de daadwerkelijke kooktijd.
• Het resultaat: Omdat de robotarm zo vaak moet worden "opgebeld" om een enkele zin te genereren, vreet al die wachttijd het snelheidsvoordeel op. Het is alsof je een Ferrari hebt die 90% van de tijd in de file staat.

3. De "Verkeerd Gereedschap"-boete (Fallback)

Soms weet de robotarm niet hoe hij een specifieke taak moet uitvoeren (zoals een complex attentiemechanisme).

• De analogie: De robotarm probeert een groente te hakken, beseft dat hij het niet kan, en moet het teruggeven aan de menselijke kok. Maar omdat ze in verschillende delen van de keuken werken, moet de menselijke kok zijn handen schoonmaken, erheen lopen, en van voren af aan beginnen.
• De realiteit: Wanneer de NPU een klus niet kan doen, valt het terug op de CPU. Deze "overdracht" voegt extra vertraging toe (ongeveer 1,5 keer trager) omdat de twee delen van de telefoon hun data moeten synchroniseren. Dit vertraagt het hele proces.

4. De energie-verrassing

Je zou denken dat het gebruik van de gespecialiseerde robotarm batterij bespaart.

• De bevinding: Verrassend genoeg verbruikt het gebruik van de NPU de batterij sneller (in sommige gevallen tot 51% meer).
• Waarom? Omdat de telefoon zoveel tijd en energie besteedt aan het beheren van de "telefoongesprekken" tussen de CPU en NPU, en het oplossen van fallback-fouten, neemt de totale tijd dat de telefoon werkt toe. Het is alsof je een marathon loopt terwijl je constant stopt om je schoenen te strikken; je gebruikt uiteindelijk meer energie dan als je gewoon in een steady tempo zou lopen.

De conclusie: Wat moeten ontwerpers doen?

De auteurs stellen drie regels voor voor de mensen die deze telefoonchips bouwen:

1. Ken je fases: Stuur niet alles naar de robot. Laat de menselijke kok (CPU) het "zware lezen" (Prefill) afhandelen en stuur alleen het "één voor één schrijven" (Decode) naar de robot.
2. Stop de file: De robot moet instructies direct kunnen accepteren (onder de 10 microseconden). We moeten de "telefoongesprek"-vertragingen stoppen.
3. Leer de robot meer trucs: De robot moet leren hoe hij alle taken uitvoert, zodat hij niet steeds de menselijke kok om hulp hoeft te vragen.

Kortom: De NPU is een krachtig hulpmiddel, maar op huidige mobiele telefoons wordt het vaak tegengehouden door slecht beheer en communicatievertragingen. Soms is de "ouderwetse" CPU eigenlijk de efficiëntere keuze.