A TensorFlow modellek üzembe helyezése a TF Serving használatával

Bevezetés

A gépi tanulás (ML) modellek gyártásba vétele népszerű, visszatérő témává vált. Számos vállalat és keretrendszer kínál különböző megoldásokat, amelyek célja ennek a kérdésnek a kezelése.

Ennek a problémának a megoldása érdekében a Google kiadta a TensorFlow (TF) Serving szolgáltatást annak reményében, hogy megoldja az ML modellek gyártásba helyezésének problémáját.

Ez a cikk egy gyakorlati oktatóanyagot kínál egy előre kiképzett konvolúciós szemantikus szegmentációs hálózat kiszolgálásáról. A cikk végére a TF Serving használatával telepítheti és kéréseket küldhet a TF-ben képzett Deep CNN-hez. Ezenkívül bemutatok egy áttekintést a TF Serving fő blokkjairól, és megbeszélem az API-kat és az egész működését.

Egy dolgot azonnal észrevesz, hogy nagyon kevés kódra van szükség ahhoz, hogy a TF modellt ténylegesen kiszolgálja. Ha el akarja menni az oktatóanyagot, és futtatja a példát a gépén, kövesse azt úgy, ahogy van. De, ha csak a TensorFlow Servingről szeretne tudni, az első két szakaszra koncentrálhat.

Ez a darab néhány olyan munkát hangsúlyoz, amelyet itt a Daitan Group-nál végezünk.

A TensorFlow kiszolgáló könyvtárak - áttekintés

Szánjunk egy kis időt arra, hogy megértsük, hogyan kezeli a TF Serving az ML modellek teljes életciklusát. Itt átmegyünk (magas szinten) a TF Serving minden fő építőelemére. Ennek a szakasznak a célja a TF Serving API-k egyszerű bemutatása. Részletes áttekintésért kérjük, keresse fel a TF szerviz dokumentáció oldalát.

A TensorFlow Serving néhány absztrakcióból áll. Ezek az absztrakciók API-kat valósítanak meg különböző feladatokhoz. A legfontosabbak a Servable, a Loader, a Source és a Manager. Nézzük át, hogyan hatnak egymásra.

Dióhéjban a kiszolgálás életciklusa akkor kezdődik, amikor a TF Serving azonosít egy modellt a lemezen. A Forrás komponens gondoskodik erről. Feladata az új betölthető modellek azonosítása. A gyakorlatban figyelemmel kíséri a fájlrendszert, hogy azonosítsa, amikor új modell verzió érkezik a lemezre. Amikor új verziót lát, folytatja a Loader létrehozását a modell adott verziójához.

Összefoglalva, a Loader szinte mindent tud a modellről. Tartalmazza, hogyan töltse be, és hogyan becsülje meg a modell szükséges erőforrásait, például a kért RAM-ot és a GPU-memóriát. A Loader mutatót mutat a lemezen lévő modellre, a betöltéshez szükséges összes metaadattal együtt. De itt van egy fogás: a Loader egyelőre nem töltheti be a modellt.

A Loader létrehozása után a Forrás Aspired verzióként elküldi a Menedzsernek.

Miután megkapta a modell Aspired verzióját, a Manager folytatja a kiszolgálás folyamatát. Itt két lehetőség van. Az egyik az, hogy az első modell verziót telepítésre szorítják. Ebben a helyzetben a menedzser gondoskodik a szükséges erőforrások rendelkezésre állásáról. Ha ezek meg vannak, a menedzser engedélyt ad a betöltőnek a modell betöltésére.

A második az, hogy egy meglévő modell új verzióját toljuk. Ebben az esetben a menedzsernek konzultálnia kell a Version Policy beépülő modullal, mielőtt továbblépne. A verzió házirend meghatározza, hogyan zajlik az új modell verzió betöltése.

Pontosabban, amikor egy modell új verzióját töltjük be, választhatunk az (1) rendelkezésre állás vagy (2) erőforrások megőrzése között. Az első esetben arra vagyunk kíváncsiak, hogy rendszerünk mindig elérhető legyen a beérkező ügyfelek kéréseire. Tudjuk, hogy a Manager lehetővé teszi a Loader számára, hogy az új grafikont az új súlyokkal példányosítsa.

Ekkor két modellváltozatunk van egyszerre betöltve. De a Manager csak a betöltés után tölti le a régebbi verziót, és biztonságos a váltás a modellek között.

Másrészt, ha erőforrásokat akarunk megtakarítani úgy, hogy nincs extra pufferünk (az új verzióhoz), akkor választhatunk az erőforrások megőrzése mellett. Hasznos lehet a nagyon nehéz modellek számára, hogy a memória megtakarításáért cserébe egy kis hiányosság áll rendelkezésre.

Végül, amikor az ügyfél kér egy fogantyút a modellhez, a Manager visszaadja a fogantyút a kiszolgálónak.

Ezzel az áttekintéssel arra készülünk, hogy belevágjunk egy valós alkalmazásba. A következő szakaszokban leírjuk, hogyan lehet egy konvolúciós neurális hálózatot (CNN) kiszolgálni a TF kiszolgálás segítségével.

Modell exportálása a megjelenítéshez

A TensorFlow-ban beépített ML modell kiszolgálásának első lépése az, hogy megbizonyosodjon arról, hogy a megfelelő formátumú-e. Ehhez a TensorFlow biztosítja a SavedModel osztályt.

A SavedModel a TensorFlow modellek univerzális sorosítási formátuma. Ha ismeri a TF-t, akkor valószínűleg a TensorFlow Saver programot használta a modell változóinak megőrzéséhez.

A TensorFlow Saver olyan funkciókat kínál, amelyekkel a modell ellenőrzőpont fájljait lemezről / lemezről mentheti / állíthatja vissza. Valójában a SavedModel beburkolja a TensorFlow Saver alkalmazást, és ez a TF modellek exportálásának szokásos módja a kiszolgálásra.

A SavedModel objektumnak van néhány szép tulajdonsága.

Először lehetővé teszi több meta-grafikon mentését egyetlen SavedModel objektumba. Más szóval, lehetővé teszi számunkra, hogy különböző grafikonok legyenek a különböző feladatokhoz.

Tegyük fel például, hogy most fejezte be a modell edzését. A legtöbb helyzetben a következtetés végrehajtásához a grafikonjának nincs szüksége néhány képzésspecifikus műveletre. Ezek az opok tartalmazhatják az optimalizáló változóit, a tanulási sebesség ütemezési tenzorait, extra előfeldolgozási opciókat és így tovább.

Ezenkívül érdemes egy grafikon számszerűsített verzióját kiszolgálni a mobil telepítéshez.

Ebben az összefüggésben a SavedModel lehetővé teszi különböző konfigurációkkal rendelkező grafikonok mentését. Példánkban három különböző grafikont állítanánk elő a megfelelő címkékkel, például: „edzés”, „következtetés” és „mobil”. Ez a három grafikon ugyanazt a változókészletet osztja meg - ami hangsúlyozza a memória hatékonyságát.

Nem is olyan régen, amikor a TF modelleket szerettük volna mobil eszközökre telepíteni, tudnunk kellett a bemeneti és kimeneti tenzorok nevét az adagoláshoz és az adatok modellhez / onnan való eljuttatásához. Ez arra kényszerítette a programozókat, hogy a grafikon összes tenzora között keressék meg a szükséges tenzort. Ha a tenzorokat nem nevezték meg megfelelően, a feladat nagyon unalmas lehet.

A dolgok megkönnyítése érdekében a SavedModel támogatást nyújt a SignatureDefs számára. Összefoglalva, a SignatureDefs meghatározza a TensorFlow által támogatott számítás aláírását. Meghatározza a számítási gráf megfelelő bemeneti és kimeneti tenzorait. Egyszerűen fogalmazva, ezekkel az aláírásokkal megadhatja a bemenethez és a kimenethez használt pontos csomópontokat.

A beépített kiszolgáló API-k használatához a TF Serving megköveteli, hogy a modellek tartalmazzanak egy vagy több SignatureDef-et.

Ilyen aláírások létrehozásához meg kell adnunk a bemenetek, az outputok és a kívánt módszer nevének definícióit. A bemenetek és a kimenetek a karakterlánc és a TensorInfo objektumok közötti leképezést jelentenek (erről bővebben). Itt definiáljuk az alapértelmezett tenzorokat az adatok betáplálásához és fogadásához a grafikonon és onnan. A method_name paraméter megcélozza az egyik TF magas szintű kiszolgáló API-t.

Jelenleg három kiszolgáló API van: Osztályozás, Jóslás és Regresszió. Minden aláírás-definíció megegyezik egy adott RPC API-val. A Classification SegnatureDef a Classify RPC API-hoz használható. A Predict SegnatureDef a Predict RPC API-hoz és tovább használható.

A besorolás aláírásához rendelkeznie kell egy bemeneti tenzorral (az adatok fogadásához) és a két lehetséges kimeneti tenzor legalább egyikével: osztályok és / vagy pontszámok. A regressziós SignatureDef pontosan egy tenzort igényel a bemenethez, a másikat pedig a kimenethez. Végül a Predict aláírás dinamikus számú be- és kimeneti tenzort tesz lehetővé.

Ezenkívül a SavedModel támogatja az eszközök tárolását olyan esetekben, amikor az opciók inicializálása külső fájloktól függ. Emellett rendelkezik mechanizmusokkal az eszközök törléséhez a SavedModel létrehozása előtt.

Most nézzük meg, hogyan tehetjük meg a gyakorlatban.

A környezet beállítása

Mielőtt elkezdenénk, klónozza ezt a TensorFlow DeepLab-v3 megvalósítást a Githubból.

A DeepLab a Google legjobb szemantikus szegmentálása a ConvNet. Alapvetően a hálózat képet készít bemenetként, és egy maszkszerű képet ad ki, amely elválaszt bizonyos objektumokat a háttértől.

Ezt a verziót a Pascal VOC szegmentációs adatkészleten oktatták. Így akár 20 osztályt is képes szegmentálni és felismerni. Ha többet szeretne megtudni a szemantikus szegmentálásról és a DeepLab-v3-ról, akkor nézze meg a Merülés a mély konvolúciós szemantikus szegmentációs hálózatokba és a Deeplab_V3 c.

A kiszolgáláshoz kapcsolódó összes fájl a következő helyen található: ./deeplab_v3/serving/. Itt két fontos fájlt talál: deeplab_saved_model.py és deeplab_client.ipynb

Mielőtt továbblépne, feltétlenül töltse le a Deeplab-v3 előre betanított modellt. Menjen a fenti GitHub adattárba, kattintson az ellenőrzőpontok linkre, és töltse le a 16645 / nevű mappát .

Végül rendelkeznie kell egy tboard_logs / nevű mappával, amelyben a 16645 / mappa található.

Most két Python virtuális környezetet kell létrehoznunk. Az egyik a Python 3-hoz, a másik pedig a Python 2-hez. Minden env esetén ellenőrizze, hogy telepítette-e a szükséges függőségeket. Megtalálhatja őket a serve_requirements.txt és client_requirements.txt fájlokban.

Két Python env-re van szükségünk, mert a DeepLab-v3 modellünket a Python 3 alatt fejlesztették ki. A TensorFlow Serving Python API azonban csak a Python 2 esetében jelent meg. Ezért a modell exportálásához és a TF kiszolgálás futtatásához a Python 3 env-t használjuk . Az ügyfélkód futtatásához a TF Serving python API használatával a PIP csomagot használjuk (csak Python 2 esetén érhető el).

Ne feledje, hogy a Python 2 env-ről lemondhat a Servel API-k használatával a bazelből. További részletekért tekintse meg a TF kiszolgáló telepítését.

Miután ez a lépés befejeződött, kezdjük azzal, ami igazán fontos.

Hogyan kell csinálni

A SavedModel használatához a TensorFlow egy könnyen használható, magas szintű segédprogramot nyújt, amelyet SavedModelBuildernek hívnak. A SavedModelBuilder osztály több meta-grafikon, a kapcsolódó változók és eszközök mentésére szolgáló funkciókat kínál.

Menjünk át egy futó példát arra, hogyan lehet exportálni a Deep Segmentation CNN modellt a kiszolgálásra.

Mint fent említettük, a modell exportálásához a SavedModelBuilder osztályt használjuk. Létrehoz egy SavedModel protokoll puffer fájlt, a modell változóival és eszközeivel együtt (ha szükséges).

Bontsuk szét a kódot.

A SavedModelBuilder megkapja (bemenetként) azt a könyvtárat, ahová a modell adatait el kell menteni. Itt az export_path változó az export_path_base és a model_version összefűzése . Ennek eredményeként a különböző modellváltozatok külön könyvtárakba kerülnek az export_path_base mappába.

Tegyük fel, hogy gyártásunkban van modellünk alapváltozata, de szeretnénk annak új verzióját telepíteni. Javítottuk modellünk pontosságát, és ezt az új verziót szeretnénk ajánlani ügyfeleinknek.

Ugyanazon grafikon másik verziójának exportálásához egyszerűen beállíthatjuk a FLAGS.model_version értéket magasabb egész értékre. Ezután egy másik (a modellünk új verzióját tartalmazó) mappa jön létre az export_path_base mappában.

Most meg kell adnunk modellünk bemeneti és kimeneti tenzorait. Ehhez a SignatureDefs fájlt használjuk. Az aláírások meghatározzák, hogy milyen típusú modellt szeretnénk exportálni. A sztringektől (logikai Tensor nevek) a TensorInfo objektumokig nyújt leképezést. Az elképzelés az, hogy a kliensek ahelyett, hogy a tényleges tenzornevekre hivatkoznának a bemenetre / kimenetre, hivatkozhatnak az aláírások által meghatározott logikai nevekre.

A szemantikus szegmentáció CNN kiszolgálásához létrehozunk egy előrejelző aláírást . Vegye figyelembe, hogy a build_signature_def () függvény felveszi a bemeneti és kimeneti tenzorok leképezését, valamint a kívánt API-t.

A SignatureDef megköveteli az alábbiakat: bemenetek, kimenetek és metódus neve. Vegye figyelembe, hogy a bemenetekre három értéket várunk - egy képet, és még két tenzort, amelyek meghatározzák annak méreteit (magasság és szélesség). A kimenetekhez csak egy eredményt definiáltunk - a szegmentációs kimeneti maszkot.

Vegye figyelembe, hogy a „image”, „height”, „width” és „segmentation_map” karakterláncok nem tenzorok. Ehelyett logikai nevek, amelyek a tényleges tenzorokra utalnak: input_tensor , image_height_tensor és image_width_tensor . Így tetszőleges egyedi karakterlánc lehet.

A SignatureDefs leképezései a TensorInfo protobuf objektumokra vonatkoznak, nem pedig a tényleges tenzorokra. A TensorInfo objektumok létrehozásához a tf.saved_model.utils.build_tensor_info (tensor) segédprogramot használjuk .

Ez az. Most meghívjuk az add_meta_graph_and_variables () függvényt a SavedModel protokoll pufferobjektum létrehozásához. Ezután futtatjuk a save () metódust, amely a modell változatait és eszközeit tartalmazó lemezre készít egy pillanatképet a lemezről.

Most már futtathatjuk a deeplab_saved_model.py fájlt a modellünk exportálásához.

Ha minden jól sikerült, akkor megjelenik a ./serving/versions/1 mappa . Vegye figyelembe, hogy az '1' a modell aktuális változatát jelenti. Minden verzió alkönyvtárban a következő fájlokat látja:

  • saved_model.pb vagy saved_model.pbtxt. Ez a sorosított SavedModel fájl. Ez magában foglalja a modell egy vagy több grafikondefinícióját, valamint az aláírás-definíciókat.
  • Változók. Ez a mappa a grafikonok sorosított változóit tartalmazza.

Most készen állunk a modellkiszolgáló elindítására. Ehhez futtassa:

$ tensorflow_model_server --port=9000 --model_name=deeplab --model_base_path=

A model_base_path arra utal, hogy hova mentették az exportált modellt. Továbbá nem adjuk meg a verzió mappát az elérési útban. A modell verzióvezérlést a TF Serving kezeli.

Ügyfélkérések generálása

Az ügyfélkód nagyon egyszerű. Vessen egy pillantást a következőre: deeplab_client.ipynb.

Először elolvassuk azt a képet, amelyet el akarunk küldeni a szerverre, és átalakítjuk a megfelelő formátumra.

Ezután létrehozunk egy gRPC csonkot. A csonk lehetővé teszi a távoli szerver metódusainak meghívását. Ehhez példányosítjuk a prediction_service_pb2 modul beta_create_PredictionService_stub osztályát . Ezen a ponton a csonk rendelkezik a szükséges logikával a távoli eljárások (a szerverről érkező) hívásához, mintha azok lokálisak lennének.

Most létre kell hoznunk és be kell állítanunk a kérés objektumot. Mivel szerverünk implementálja a TensorFlow Predict API-t, elemeznünk kell egy Predict kérést. A Predict kérés kiadásához először a PredictRequest osztályt példányosítjuk a predict_pb2 modulból. Meg kell adnunk a model_spec.name és model_spec.signature_name paramétereket is. A név param a „MODEL_NAME” érvelés, hogy meghatározott, amikor elindítottuk a szerveren. És signature_name utal, hogy a logikai rendelt név signature_def_map () paramétere add_meta_graph () rutin.

Ezután meg kell adnunk a bemeneti adatokat a szerver aláírásában meghatározottak szerint. Ne feledje, hogy a kiszolgálón meghatároztunk egy Predict API-t, amely elvárja a képet, valamint két skalárt (a kép magasságát és szélességét). A bemeneti adatoknak a kérelemobjektumba történő betáplálásához a TensorFlow biztosítja a tf.make_tensor_proto () segédprogramot . Ez a módszer egy TensorProto objektumot hoz létre egy numpy / Python objektumból. Használhatjuk arra, hogy a képet és annak méreteit betápláljuk a kérelemobjektumba.

Úgy tűnik, készen állunk a szerver hívására. Ehhez meghívjuk a Predict () metódust (a csonk segítségével), és argumentumként továbbítjuk a kérés objektumot.

Azon válaszok esetén, amelyek egyetlen választ adnak vissza, a gRPC egyaránt támogatja: szinkron és aszinkron hívásokat. Így, ha azt szeretné, hogy némi munkát, míg a kérés feldolgozása folyamatban van, nevezhetjük Predict.future () helyett Tippelje () .

Most lehívhatjuk és élvezhetjük az eredményeket.

Remélem tetszett ez a cikk. Köszönöm, hogy elolvasta!

Ha többet szeretne, nézze meg:

Hogyan képezheti ki saját FaceID ConvNet-jét a TensorFlow Eager végrehajtásával

Az arcok mindenütt megtalálhatók - a közösségi média webhelyein található fényképektől és videóktól kezdve a fogyasztói biztonsági alkalmazásokig, például a… medium.freecodecamp.org Bemerülés a mély konvolúciós szemantikus szegmentációs hálózatokba és a Deeplab_V3

A mély konvolúciós neurális hálózatok (DCNN) figyelemre méltó sikereket értek el a különböző Computer Vision alkalmazásokban ... medium.freecodecamp.org