A következő fontos MI-telepítés talán nem egy óriási felhőklaszterben fog futni. Lehet, hogy egy kamerában, gyári robotban, járműben, orvostechnikai eszközben vagy kiskereskedelmi terminálon fut majd, ahol a sávszélesség, az energiafogyasztás, a késleltetés, az adatvédelem és az üzemeltetési költség fontosabb annál, hogy a lehető legnagyobb modell álljon rendelkezésre.

Ez az elmozdulás az MI-munka egy másfajta típusát hozza létre. A csapatoknak továbbra is szükségük van modellépítőkre, de olyanokra is, akik képesek a modelleket a valódi hardverhez igazítani, korlátok mellett mérni a minőséget, natív következtetési futtatókörnyezeteket integrálni, és eldönteni, mikor elég jó egy kisebb modell az adott feladathoz.

Ez a modellverseny kevésbé látványos fele: nemcsak az intelligencia javítása, hanem annak telepíthetővé tétele is.

Miért változtatják meg a kisebb modellek a telepítés kérdését?

Egy felhőben futó modell gyakran több számítási kapacitást fordíthat egy kérés megválaszolására. Egy beágyazott rendszer nem feltételezhet megbízható hálózati kapcsolatot, korlátlan akkumulátort vagy bőséges, hívásonkénti költségkeretet. Egy robot, amelynek minden észlelési vagy vezérlési döntésre több száz milliszekundumot kell várnia, nem feltétlenül biztonságos vagy hatékony. Egy olyan termék, amely minden képet vagy hangmintát egy API-nak küld, elfogadhatatlan adatvédelmi és adatátviteli költségeket okozhat.

Ezek a korlátok megváltoztatják a mérnöki célt. A kérdés így hangzik: mi az a legkisebb modell, amely a tényleges eszközön eléri az előírt pontossági, késleltetési, memória-, energia- és megbízhatósági célokat?

Ez a kérdés messze túlmutat a fogyasztói eszközökön. Fontos a gyártósoron alkatrészeket ellenőrző gyártóknak, a berendezéseket nyomon követő logisztikai vállalatoknak, érzékeny jeleket feldolgozó kórházaknak, valamint azoknak a szoftverszállítóknak, amelyek MI-funkciókat szeretnének kínálni anélkül, hogy a következtetési számlák válnának a legnagyobb változó költségükké.

Az elmozdulás mögött álló három technika

A kvantálás a modell súlyait, esetenként az aktivációkat is, kisebb pontosságú számokkal ábrázolja. Az olyan formátumokról, mint a BF16 vagy az FP16, 8 vagy 4 bites reprezentációkra váltás csökkentheti a memóriaigényt, és a hardvertől, illetve a megvalósítástól függően javíthatja az áteresztőképességet. Ennek ára, hogy a kisebb pontosság ronthatja a minőséget vagy numerikus problémákat okozhat, ezért ezt tesztelni kell, nem pedig ártalmatlannak feltételezni.

A desztilláció során egy kisebb tanulómodellt tanítanak meg arra, hogy reprodukálja egy nagyobb tanármodell hasznos viselkedését. A tanuló a tanár kimeneteiből, köztes jeleiből vagy feladatspecifikus példákból tanulhat. Nem kell újrateremtenie a nagyobb modell minden képességét; az a feladata, hogy a célmunkát elég jól végezze el.

Az optimalizált következtetés a végrehajtást egy adott futtatókörnyezethez és processzorhoz igazítja. Ez magában foglalhatja a kernel kiválasztását, a gráf fordítását, a kötegelést, a memóriatervezést, a gyorsítótárazást és a hardverspecifikus gyorsítást. A nyilvános előzetesben bejelentett NVIDIA TensorRT Model Connect egy példa az olyan eszközökre, amelyek célja, hogy a támogatott Hugging Face- vagy helyi ellenőrzőpontokat köztes ONNX-export nélkül, végponttól végpontig tartó TensorRT-következtetéssé alakítsák. A megadott célterületei közé tartoznak a robotikai, eszköz- és platformmunkafolyamatok.

Ezek a technikák erősítik egymást. A desztilláció kompakt modellt hozhat létre; a kvantálás tovább csökkentheti a méretét; az optimalizált futtatókörnyezet pedig eldöntheti, hogy az így kapott modell valóban gyors-e a célként megjelölt chipen.

A hasznos eredmény nem ugyanaz, mint egy kisebb fájl

A modellkompressziót termék- és rendszertervezési feladatként kell kezelni, nem ranglistatrükkként. Egy 40 százalékkal kisebb modell, amely gyenge fényviszonyok között nem ismeri fel a kritikus objektumokat, rosszabb lehet egy raktári robot számára. Egy tokenenként olcsó nyelvi modell, amely hibás strukturált kimenetet generál, növelheti az utólagos javítási munkát. Egy benchmarkban jól teljesítő modell megbukhat, amikor megjelenik a termikus visszaszabályozás, a kamerazaj, a szakaszos kapcsolat vagy a szokatlan felhasználói bemenet.

A Liquid AI LFM2.5 kis modelljeihez készített, kvantálástudatos desztillációról szóló jelentése hasznos példával szolgál a célra. A vállalat beszámolója szerint a BF16-teljesítmény 96,5–97,4%-át megőrizték, miközben a Q4_0 memóriaigényét és áteresztőképességét is fenntartották. Ezek a számok a vállalat jelentésein alapulnak és modellspecifikusak; nem szabad őket minden architektúrára általánosítani. Megmutatják azonban, milyen összehasonlításokat kell keresniük a gyakorlati szakembereknek: a minőségmegőrzést a memória- és sebességadatokkal együtt kell mérni, nem pusztán a tömörítési arányt.

Egy telepítés esetében az elfogadási tesztnek legalább a következőket kell tartalmaznia:

  • a feladat minősége reprezentatív, nehéz példákon;
  • a csúcsmemória- és tárhelyigény;
  • az első válaszig eltelt és az állandósult késleltetés;
  • az áteresztőképesség reális párhuzamosság mellett;
  • az energiafelhasználás vagy a hőviselkedés, ahol releváns;
  • a hibaviselkedés hiányos, zajos vagy eloszláson kívüli bemenetek esetén;
  • a modell frissítésének költsége és üzemeltetési terhe.

A pontos mérőszámok termékenként eltérnek. Egy kameránál fontos lehet a másodpercenkénti képkockaszám és a hamis negatívok aránya. Egy hangalapú kezelőfelületnél a végponttól végpontig mért válaszidő lehet fontos. Egy robotnál a vezérlési ciklus határideje és a biztonságos tartalékviselkedés számíthat. A lényeg, hogy a modellértékelést összekapcsoljuk a hiba fizikai vagy pénzügyi következményeivel.

Hol jelenik meg az új munka

A bővülő lehetőségek nem korlátozódnak azokra, akik architektúrákat találnak ki. Több gyakorlati szerepkört is magukban foglalnak:

  • Inferenciamérnökök célgyorsítókon profilozzák a modelleket, futtatókörnyezeteket választanak, optimalizálják a gráfokat, valamint feltárják a késleltetési vagy memória-szűk keresztmetszeteket.
  • Modelltömörítési mérnökök kvantálási és desztillációs folyamatokat terveznek, kalibrációs adatokat választanak, és feladatonként, illetve szegmensenként mérik a minőségromlást.
  • Edge ML-mérnökök mobil-, beágyazott, ipari vagy autóipari környezetekhez csomagolják a modelleket, és korlátozott hálózati kapcsolat mellett kezelik a frissítéseket.
  • Robotikai szoftvermérnökök az érzékelőkhöz, tervezőrendszerekhez és biztonsági korlátokhoz kapcsolják az érzékelési modelleket, olyan helyzetekben, ahol az időzítés kritikus.
  • Hardverközpontú termékmérnökök eldöntik, hogy egy munkafolyamatnak az eszközön, az edge-en vagy a felhőben van-e a helye, és zökkenőmentes átadásokat terveznek közöttük.
  • Telepítési és validációs szakértők olyan tesztkészleteket építenek, amelyek termikus, energiafogyasztási, hálózati és valós környezeti feltételeket is tartalmaznak.

Az alkalmazásfejlesztők számára is akad munka. Lehet, hogy egy termékcsapat nem tanít modellt, de akkor is ki kell választania a modellformátumot, integrálnia kell egy inferenciakönyvtárat, kezelnie kell a nem támogatott operátorokat, elérhetővé kell tennie a konfidenciát vagy a tartózkodási viselkedést, és visszafordíthatóvá kell tennie a frissítéseket.

A felhő és az edge szétválasztása egyre inkább tervezési készséggé válik

A kis modellek nem szüntetik meg a felhőben futó modellek szükségességét. Vonzóbbá teszik a hibrid rendszereket. Egy eszköz kompakt modellt használhat az azonnali észleléshez, majd a kiválasztott eseményeket elküldheti egy nagyobb modellnek magyarázat vagy mélyebb elemzés céljából. Egy robot a biztonság szempontjából kritikus érzékelést helyben tarthatja, miközben a felhőt flottaszintű tanulásra használja. Egy ügyfélszolgálati termék a rutinszerű osztályozást egy kis modellre bízhatja, a bizonytalan eseteket pedig egy nagyobb képességű modellhez továbbíthatja.

Ez az architektúra csökkentheti a sávszélesség-igényt és a késleltetést, de olyan döntéseket vezet be, amelyekhez egyértelmű felelősségi körök szükségesek. Milyen információ kerül ki az eszközről? Mi történik kapcsolat nélkül? Melyik modellverzió hozott létre egy műveletet? Biztonságosan vissza tud állni az eszköz? Hogyan monitorozható a teljesítmény, ha az egyes hardverkonfigurációk eltérően viselkednek?

Ezek telepítési kérdések, nem pusztán modellkérdések. Azokat a szakembereket jutalmazzák, akik értik a gépi tanulás, a beágyazott rendszerek, a hálózatok, a termékkövetelmények és az üzemeltetés közötti kapcsolódási pontokat.

Gyakorlati tanulási út

Ha ebbe az irányba szeretnél elmozdulni, inkább építs fel egy kicsi, de mérhető telepítést, mintsem csak modell-tanúsítványokat gyűjts. Kezdj egy egyértelmű célértékkel rendelkező feladattal, például képosztályozással, kulcsszófelismeréssel, dokumentumkategorizálással vagy egy kompakt helyi asszisztenssel.

  1. Állíts fel egy alapértéket. Rögzítsd a minőséget, a modell méretét, a memóriahasználatot, a késleltetést és az áteresztőképességet reprodukálható tesztkészlettel.
  2. Kvantáld. Hasonlíts össze legalább egy alacsonyabb pontosságú verziót az alapértékkel. Dokumentáld, mely példák változnak, és hogy a hibák egy fontos kategóriában összpontosulnak-e.
  3. Próbáld ki a desztillációt vagy a feladatspecifikus finomhangolást. Mérd meg, hogy egy kisebb modell képes-e megőrizni azt a viselkedést, amelyre a terméknek ténylegesen szüksége van.
  4. Futtasd célhardveren. Egy asztali számítógépen végzett benchmark nem szolgáltat bizonyítékot egy telefonról, mikroszámítógépről, GPU-ról, gyorsítóról vagy robot számítógépéről.
  5. Csomagold telepíthetővé. Tartalmazza az előfeldolgozást, az utófeldolgozást, a verziómetaadatokat, az állapotellenőrzéseket és egy tartalék útvonalat.
  6. Írd meg a kompromisszumokról szóló jelentést. Magyarázd el, miért teljesít a kiválasztott modell a legjobban a minőség, a késleltetés, a memória, az energia, az adatvédelem és a költség szempontjából összességében — ne csak azt, miért ennek a legjobb a pontszáma.

A hasznos eszközök a célzott technológiai készlettől függnek, az átvihető készségek azonban állandók: profilozás, numerikus gondolkodás, adatválasztás, teszttervezés, hibakeresés és a kompromisszumok világos kommunikációja. Tanulj meg modellgráfot olvasni, megvizsgálni az operátorok támogatását, felismerni a memória mozgatását mint szűk keresztmetszetet, és megkülönböztetni az elméleti számítási kapacitást a mért, végponttól végpontig terjedő késleltetéstől.

A karrier szempontjából fontos jelzés

A fontos karrierváltás abban áll, hogy a „Melyik modell a legintelligensebb?” kérdését felváltja a „Melyik rendszer biztosítja a kívánt eredményt a valós korlátok között?” kérdése. A nagy modellek továbbra is értékesek maradnak, különösen a nyitott végű következtetés és az összetett generálás terén. Számos kereskedelmi és fizikai világbeli feladat azonban elég szűk ahhoz, hogy egy kompakt, gyors és privát modell jobb termék legyen.

Ez teret ad azoknak a gyakorlati szakembereknek, akik hidat tudnak képezni a kutatás és a telepítés között. Nem mindig azok lesznek a győztesek, akiknek a legnagyobb modelljük van. Lehet, hogy azok a csapatok nyernek, amelyek megértik a munkafolyamatot, intelligensen tömörítenek, őszintén benchmarkolnak, és megbízható rendszert szállítanak az elérhető hardveren.

Egy AI-karrier szempontjából ez tartós érvényű tanulság: az intelligencia csak a szállítandó eredmény egyik része. A másik rész az, hogy illeszkedjen.