MI-chipek: mit tudnak valójában?
Ahhoz, hogy megértsük, mihez kezdhetünk az NPU-kkal, érdemes áttekinteni, pontosan mi is a feladatuk. Ugyanúgy, ahogy a CPU az alkalmazások futtatásáért, a GPU a grafikus teljesítményért, az ISP pedig a képfeldolgozásért felel, az NPU az MI-feladatok gyors és hatékony elvégzésére specializált. Ezt különféle matematikai műveletekkel, kis adatméretekkel, párhuzamos számításokkal valósítja meg: a tipikus 4 vagy 2 bites modellektől a legbonyolultabb műveletekig.
Emiatt ma már az okostelefonokban az MI-feladatokat jellemzően egy NPU futtatja, hiszen a CPU kevésbé erős ilyen téren, míg a GPU nagyobb fogyasztással dolgozik, ráadásul nem optimalizált a nehéz MI-számításokra. Nem elhanyagolható tényező, hogy az NPU-k használatával a telefonok energiahatékonyabbá válnak, így az MI-funkciók nem merítik le az akkumulátort pillanatok alatt.
Miért nem uralják már most az MI-chipek a mobilokat?
Felmerül a kérdés: ha léteznek ezek a szupergyors, energiatakarékos dedikált MI-chipek, miért nem használ minden alkalmazás ilyeneket? A válasz a fejlesztői környezet bonyolultságában rejlik.
A nagy teljesítményű asztali MI-alkalmazások világszerte leginkább az NVIDIA CUDA architektúráját használják, ami mélyszintű optimalizációkat tesz lehetővé. Ezt mobil környezetben a különböző gyártók eltérő, gyakran zárt fejlesztői platformjai váltják fel: ilyen például a Qualcomm Neural Processing SDK, az Apple Neural Engine vagy az Arm Compute Library. Ezek mind saját szabványaik szerint működnek, különféle képességekkel – emiatt a harmadik féltől származó fejlesztőknek minden platformra egyedileg kellene optimalizálniuk alkalmazásaikat.
Így az egységes fejlesztés szinte lehetetlen, a közös, univerzális API-k pedig gyakran elavulnak vagy támogatás nélkül maradnak – ilyen volt a Samsung Neural SDK leállítása, illetve az Android NNAPI (Neural Networks API) elavulása is. Emiatt csak néhány nagy szereplő – főként a Google – képes teljes mértékben kihasználni a hardver kínálta lehetőségeket, a többi alkalmazásnak maradnak a kevésbé hatékony, de univerzálisabb CPU/GPU-megoldások vagy felhőalapú szolgáltatások.
LiteRT: a mobil MI-ökoszisztéma reménye
2024-ben új szín került a palettára: a Google bemutatta a LiteRT-t, amely végre egységes futtatókörnyezetként szolgál a CPU, a GPU és az NPU között. A LiteRT célja, hogy automatikusan maximalizálja a készüléken elérhető hardveres gyorsítást, közvetlenül futtatva a modelleket Androidon, iOS-en, beágyazott rendszereken és akár asztali környezetekben is.
Nem elhanyagolható módon a LiteRT végre valóban elrejti a fejlesztők elől a platformfüggő hardver sajátosságait, leválasztja őket a chipgyártók fejlesztési ütemtervéről, és elhozza az MI-alapú alkalmazások gyors, megbízható futását. Bár a TensorFlow Lite-modellek előre rögzített paraméterekkel rendelkeznek (precizitás, kvantálás, futtatási módok), az absztrakció végre működik: a programozónak most már kevesebb fejfájást okoz, milyen hardveren fog futni a kód.
Ugyanakkor érdemes megemlíteni, hogy a CPU-k is egyre összetettebb MI-számítási utasításokat támogatnak; az Arm SME2 utasításkészlet például akár négyszeres gyorsulást ígér, miközben a GPU-k natív támogatást kaptak a legkorszerűbb kvantizált (INT8, FP8) modellekhez – a Samsung Galaxy S28 sorozatban akár már találkozhatunk ezekkel az újításokkal.
Mi várható a következő években?
Habár az NPU-k nem fognak eltűnni a közeljövőben, jelentőségük átalakul: inkább gyorsítók maradnak, mintsem egyetlen belépési pontok. A harmadik féltől származó alkalmazások számára továbbra is a CPU és a GPU viseli a fő terhet, ahogy ezek egyre inkább optimalizálódnak MI-műveletekre is. Ha a LiteRT sikeres lesz, a fejlesztők végre nem chipgyártóhoz kötött MI-fejlesztésen törhetik a fejüket, hanem koncentrálhatnak az alkalmazásokra – ettől pedig végre valóban gazdagabbá válhat a mobil MI-ökoszisztéma.
Az események láncolata itt még nem ért véget – de közelebb vagyunk ahhoz, hogy a készülékeinkben lapuló MI-chip végre mindenki számára elérhető, izgalmas lehetőségeket hozzon.
