Kuinka ottaa TensorFlow-mallit käyttöön tuotannossa käyttämällä TF-palvelua

Johdanto

Koneoppimisen (ML) mallien asettamisesta tuotantoon on tullut suosittu, toistuva aihe. Monet yritykset ja kehykset tarjoavat erilaisia ​​ratkaisuja tämän ongelman ratkaisemiseksi.

Tämän ongelman ratkaisemiseksi Google julkaisi TensorFlow (TF) Serving -palvelun toivossa ratkaista ML-mallien käyttöönoton ongelma tuotantoon.

Tämä kappale tarjoaa käytännön opetusohjelman esikoulutetun Convolutional Semantic Segmentation Network -palvelun palvelemisesta. Tämän artikkelin loppuun mennessä voit käyttää TF-palvelua sijoittamaan ja tekemään pyyntöjä Deep CNN: lle, joka on koulutettu TF: lle. Esitän myös yleiskatsauksen TF-palvelun päälohkoista ja keskustelen sen sovellusliittymistä ja siitä, miten se kaikki toimii.

Yksi asia, jonka huomaat heti, on se, että se vaatii hyvin vähän koodia, jotta TF-malli todella toimii. Jos haluat mennä ohjeen mukana ja suorittaa esimerkin koneellasi, noudata sitä sellaisenaan. Mutta jos haluat tietää vain TensorFlow-palvelusta, voit keskittyä kahteen ensimmäiseen osioon.

Tämä kappale korostaa joitain töitä, joita teemme täällä Daitan Groupissa.

TensorFlow-palvelukirjastot - yleiskatsaus

Otetaan jonkin aikaa ymmärtää, kuinka TF Serving hoitaa ML-mallien tarjoamisen koko elinkaaren. Tässä käymme läpi (korkealla) TF Serving -palvelun kaikki pääosat. Tämän osan tavoitteena on tarjota pehmeä esittely TF-palvelusovellusliittymiin. Jos haluat perusteellisen yleiskatsauksen, siirry TF Serving -dokumentaation sivulle.

TensorFlow Serving koostuu muutamasta abstraktista. Nämä abstraktit toteuttavat API: t eri tehtäviin. Tärkeimmät ovat palvelukelpoinen, lataaja, lähde ja hallinta. Mennään miten he ovat vuorovaikutuksessa.

Lyhyesti sanottuna palvelun elinkaari alkaa, kun TF Serving tunnistaa levyllä olevan mallin. Lähde-komponentti huolehtii siitä. Se vastaa uusien ladattavien mallien tunnistamisesta. Käytännössä se seuraa tiedostojärjestelmää tunnistamaan, milloin uusi malliversio saapuu levylle. Kun se näkee uuden version, se etenee luomalla kuormaajan kyseiselle malliversiolle.

Yhteenvetona voidaan todeta, että Loader tietää melkein kaiken mallista. Se sisältää kuinka ladata se ja kuinka arvioida mallin tarvittavat resurssit, kuten pyydetty RAM ja GPU-muisti. Loaderilla on osoitin levyllä olevalle mallille sekä kaikki sen lataamiseen tarvittavat metatiedot. Mutta tässä on saalis: Loader ei saa vielä ladata mallia.

Kun olet luonut Loaderin, lähde lähettää sen Managerille Aspired-versiona.

Saatuaan mallin Aspired-version Manager jatkaa palveluprosessia. Tässä on kaksi mahdollisuutta. Yksi on se, että ensimmäinen malliversio on pakko ottaa käyttöön. Tässä tilanteessa johtaja varmistaa, että tarvittavat resurssit ovat käytettävissä. Kun ne ovat, Manager antaa Loaderille luvan ladata malli.

Toinen on se, että ajamme uuden version olemassa olevasta mallista. Tällöin johtajan on tutustuttava Version Policy -laajennukseen ennen kuin jatkat. Versiopolitiikka määrittää, kuinka uuden malliversion lataaminen tapahtuu.

Erityisesti ladattaessa mallin uutta versiota voimme valita, säilytetäänkö (1) saatavuus tai (2) resurssit. Ensimmäisessä tapauksessa olemme kiinnostuneita varmistamaan, että järjestelmämme on aina käytettävissä saapuvien asiakkaiden pyyntöihin. Tiedämme, että Manager sallii Loaderin instantisoida uuden kaavion uusilla painoilla.

Tässä vaiheessa meillä on kaksi malliversiota ladattu samanaikaisesti. Mutta Manager purkaa vanhemman version vasta, kun lataus on valmis ja mallien välillä vaihtaminen on turvallista.

Toisaalta, jos haluamme säästää resursseja ilman, että meillä on ylimääräinen puskuri (uudelle versiolle), voimme valita resurssien säilyttämisen. Saattaa olla hyödyllistä, että erittäin raskaissa malleissa on pieni aukko saatavuudessa, vastineeksi muistin säästämisestä.

Lopussa, kun asiakas pyytää mallille kahvan, Manager palauttaa kahvan Servable-palveluun.

Tämän yleiskatsauksen avulla olemme valmiita sukeltamaan tosielämän sovellukseen. Seuraavissa osioissa kuvataan, kuinka konvoluutiohermoverkkoa (CNN) voidaan palvella TF-palvelua käyttämällä.

Vie malli näyttämistä varten

Ensimmäinen askel palvelemaan TensorFlow-palvelussa rakennettua ML-mallia on varmistaa, että se on oikeassa muodossa. Tätä varten TensorFlow tarjoaa SavedModel-luokan.

SavedModel on TensorFlow-mallien yleinen sarjakuvamuoto. Jos tunnet TF: n, olet todennäköisesti käyttänyt TensorFlow Saveria mallisi muuttujien säilyttämiseen.

TensorFlow Saver tarjoaa toimintoja mallin tarkistuspistetiedostojen tallentamiseen / palauttamiseen levylle / levyltä. Itse asiassa SavedModel kääri TensorFlow Saver -sovelluksen, ja sen on tarkoitus olla tavanomainen tapa viedä TF-malleja palvelua varten.

SavedModel-objektilla on hienoja ominaisuuksia.

Ensinnäkin sen avulla voit tallentaa useita metakuvaajia yhteen SavedModel-objektiin. Toisin sanoen, se antaa meille mahdollisuuden käyttää erilaisia ​​kaavioita eri tehtäviin.

Oletetaan esimerkiksi, että olet juuri päättänyt mallisi koulutuksen. Useimmissa tilanteissa kaavion ei tarvitse tehdä päätelmiä suorittaakseen harjoituskohtaisia ​​toimintoja. Näihin toimintoihin voi sisältyä optimoijan muuttujia, oppimisnopeuden ajoitussensoreita, ylimääräisiä esikäsittelyoptioita ja niin edelleen.

Lisäksi kannattaa ehkä näyttää kaavion kvantisoitu versio mobiilikäyttöönottoa varten.

Tässä yhteydessä SavedModel antaa sinun tallentaa kaavioita eri kokoonpanoilla. Esimerkissämme meillä olisi kolme erilaista kuvaajaa vastaavilla tunnisteilla, kuten "koulutus", "päättely" ja "mobiili". Näillä kaikilla kolmella kuvaajalla olisi myös sama muuttujasarja - mikä korostaa muistin tehokkuutta.

Ei niin kauan sitten, kun halusimme ottaa käyttöön TF-malleja mobiililaitteissa, meidän piti tietää tulo- ja lähtötiensorien nimet syötteeksi ja tietojen saamiseksi malliin / mallista. Tämä tarve pakotti ohjelmoijat etsimään tarvitsemaansa tensoria kaavion kaikkien tensorien joukosta. Jos tensoreita ei nimetä oikein, tehtävä voi olla erittäin tylsä.

Asian helpottamiseksi SavedModel tarjoaa tukea SignatureDefsille. Yhteenvetona voidaan todeta, että SignatureDefs määrittelee TensorFlow'n tukeman laskennan allekirjoituksen. Se määrittää laskentakaavion oikean tulo- ja lähtöjännitteen. Yksinkertaisesti sanottuna, näillä allekirjoituksilla voit määrittää tarkat solmut, joita käytetään tuloon ja lähtöön.

Sisäänrakennettujen palvelusovellusliittymien käyttämiseksi TF-palvelin edellyttää, että malleissa on yksi tai useampi SignatureDefs.

Tällaisten allekirjoitusten luomiseksi meidän on annettava määritelmät syötteille, tuotoksille ja halutulle menetelmän nimelle. Tulot ja lähdöt edustavat kartoitusta merkkijonosta TensorInfo-objekteihin (lisää tästä). Tässä määritetään oletussensorit tietojen syöttämiseksi ja vastaanottamiseksi kaaviosta ja graafista. Method_name parametri kohdistuu yksi TF korkean tason palvelevat API.

Tällä hetkellä palvelevia sovellusliittymiä on kolme: Luokittelu, Ennusta ja Regressio. Jokainen allekirjoituksen määritelmä vastaa tiettyä RPC-sovellusliittymää. Luokittelua SegnatureDef käytetään Classify RPC -sovellusliittymässä. Predict SegnatureDefia käytetään Predict RPC -sovellusliittymään ja päälle.

Luokittelun allekirjoitusta varten on oltava tulotensori (tietojen vastaanottamiseksi) ja vähintään yksi kahdesta mahdollisesta ulostulosensorista: luokat ja / tai pisteet. Regressio SignatureDef vaatii täsmälleen yhden tensorin syötteelle ja toisen ulostulolle. Lopuksi, Ennusta-allekirjoitus sallii dynaamisen määrän sisään- ja ulostulojännitteitä.

Lisäksi SavedModel tukee resurssien tallennusta tapauksissa, joissa toimintojen alustus riippuu ulkoisista tiedostoista. Lisäksi sillä on mekanismeja laitteiden tyhjentämiseen ennen SavedModelin luomista.

Katsotaan nyt, miten voimme tehdä sen käytännössä.

Ympäristön asettaminen

Ennen kuin aloitamme, kloonaa tämä TensorFlow DeepLab-v3 -toteutus Githubista.

DeepLab on Googlen paras semanttinen segmentointi ConvNet. Pohjimmiltaan verkko ottaa kuvan tulona ja tuottaa maskin kaltaisen kuvan, joka erottaa tietyt objektit taustasta.

Tämä versio on koulutettu Pascal VOC -segmentointiaineistoon. Siten se voi segmentoida ja tunnistaa jopa 20 luokkaa. Jos haluat tietää enemmän semanttisegmentaatiosta ja DeepLab-v3: sta, tutustu kohtaan Sukellus syvälliseen konvoluutiosemanttisegmentointiverkostoon ja Deeplab_V3.

Kaikki palveluun liittyvät tiedostot ovat: ./deeplab_v3/serving/. Sieltä löydät kaksi tärkeää tiedostoa: deeplab_saved_model.py ja deeplab_client.ipynb

Ennen kuin jatkat, muista ladata esikoulutettu Deeplab-v3-malli. Siirry yllä olevaan GitHub-arkistoon, napsauta tarkistuspisteiden linkkiä ja lataa kansio nimeltä 16645 / .

Lopulta sinulla pitäisi olla kansio nimeltä tboard_logs / kanssa 16645 / kansio sijoitetaan se.

Nyt meidän on luotava kaksi virtuaalista Python-ympäristöä. Yksi Python 3: lle ja toinen Python 2: lle: Asenna tarvittavat riippuvuudet kullekin env: lle. Löydät ne tiedostoista serve_requirements.txt ja client_requirements.txt.

Tarvitsemme kaksi Python-env: tä, koska mallimme, DeepLab-v3, on kehitetty Python 3: n alla. . Asiakaskoodin suorittamiseen TF Serving python -sovellusliittymällä käytämme PIP-pakettia (saatavana vain Python 2: lle).

Huomaa, että voit luopua Python 2 env: stä käyttämällä bazelin palvelusovellusliittymiä. Katso lisätietoja TF: n käyttöasennuksesta.

Kun tämä vaihe on valmis, aloitetaan siitä, mikä todella on tärkeää.

Kuinka tehdä se

SavensModelin käyttämiseksi TensorFlow tarjoaa helppokäyttöisen korkean tason apuohjelmaluokan nimeltä SavedModelBuilder. SavedModelBuilder-luokka tarjoaa toimintoja useiden metakuvaajien, niihin liittyvien muuttujien ja resurssien tallentamiseen.

Käydään läpi käynnissä oleva esimerkki siitä, kuinka Deep Segmentation CNN -malli viedään palvelua varten.

Kuten edellä mainittiin, mallin vientiin käytämme SavedModelBuilder-luokkaa. Se luo SavedModel-protokollapuskuritiedoston sekä mallin muuttujat ja varat (tarvittaessa).

Lajitellaan koodi.

SavedModelBuilder vastaanottaa (syötteenä) hakemiston, johon mallin tiedot tallennetaan. Tässä export_path- muuttuja on export_path_base- ja model_version-ketju . Tämän seurauksena eri malliversiot tallennetaan erillisiin hakemistoihin export_path_base- kansioon.

Oletetaan, että meillä on tuotannossa mallin perusversio, mutta haluamme ottaa käyttöön uuden version siitä. Olemme parantaneet mallimme tarkkuutta ja haluamme tarjota tämän uuden version asiakkaillemme.

Jos haluat viedä saman kaavion eri version, voimme vain asettaa FLAGS.model_version suuremmaksi kokonaislukuarvoksi. Sitten toinen kansio (jossa on mallin uusi versio) luodaan export_path_base- kansioon.

Nyt meidän on määritettävä mallimme tulo- ja lähtötiensorit. Tätä varten käytämme SignatureDefs. Allekirjoitukset määrittävät minkä tyyppisen mallin haluamme viedä. Se tarjoaa kartoituksen merkkijonoista (loogiset tensorien nimet) TensorInfo-objekteihin. Ajatuksena on, että sen sijaan, että viitattaisiin todellisiin tensorien nimiin tuloa / lähtöä varten, asiakkaat voivat viitata allekirjoitusten määrittelemiin loogisiin nimiin.

Semanttisen segmentoinnin CNN: n palvelemiseksi aiomme luoda ennustavan allekirjoituksen . Huomaa, että build_signature_def () -funktio vie tulo- ja lähtöjännitteiden sekä halutun sovellusliittymän kartoituksen.

SignatureDef vaatii erittelyn: tulot, lähdöt ja menetelmän nimi. Huomaa, että tuloille odotetaan kolme arvoa - kuva ja kaksi muuta tensoria, jotka määrittelevät sen mitat (korkeus ja leveys). Sillä lähdöt , määrittelimme vain yksi lopputulos - segmentointia ulostulo maski.

Huomaa, että merkkijonot 'kuva', 'korkeus', 'leveys' ja 'segmentointikartta' eivät ole tensoreita. Sen sijaan ne ovat loogisia nimiä, jotka viittaavat todellisiin tensoreihin input_tensor , image_height_tensor ja image_width_tensor . Siksi ne voivat olla mitä tahansa ainutlaatuisia merkkijonoja, joista pidät.

SignatureDefs-kartoitukset liittyvät myös TensorInfo-protobuf-objekteihin, ei varsinaisiin tensoreihin. TensorInfo-objektien luomiseen käytämme apuohjelmatoimintoa: tf.saved_model.utils.build_tensor_info (tensor) .

Se on siinä. Kutsumme nyt funktiota add_meta_graph_and_variables () rakentaaksesi SavedModel-protokollapuskuriobjektin. Suoritamme sitten save () -menetelmän ja se säilyttää tilannekuvan mallistamme levylle, joka sisältää mallin muuttujat ja varat.

Voimme nyt suorittaa deeplab_saved_model.py mallimme viemiseksi.

Jos kaikki meni hyvin, näet kansion ./serving/versions/1 . Huomaa, että '1' edustaa mallin nykyistä versiota. Jokaisen version alihakemiston sisällä näet seuraavat tiedostot:

  • saved_model.pb tai saved_model.pbtxt. Tämä on sarjatuotettu SavedModel-tiedosto. Se sisältää yhden tai useamman mallin graafin määrittelyn sekä allekirjoituksen määritelmät.
  • Muuttujat. Tämä kansio sisältää kaavioiden sarjoitetut muuttujat.

Nyt olemme valmiita käynnistämään mallipalvelimemme. Voit tehdä sen suorittamalla:

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

Model_base_path viittaa jos viety malli tallennettiin. Emme myöskään määritä versiokansiota polussa. Malliversioiden hallintaa hoitaa TF Serving.

Luodaan asiakaspyyntöjä

Asiakaskoodi on hyvin yksinkertainen. Katsokaa sitä osoitteessa: deeplab_client.ipynb.

Ensin luemme kuvan, jonka haluamme lähettää palvelimelle, ja muunnamme sen oikeaan muotoon.

Seuraavaksi luodaan gRPC-tynkä. Oman avulla voimme kutsua etäpalvelimen menetelmiä. Tätä varten instantioimme prediction_service_pb2- moduulin beta_create_PredictionService_stub- luokan . Tässä vaiheessa tynkillä on tarvittava logiikka etämenettelyjen (palvelimelta) kutsumiseen ikään kuin ne olisivat paikallisia.

Nyt meidän on luotava ja asetettava pyyntöobjekti. Koska palvelimemme toteuttaa TensorFlow Predict -sovellusliittymän, meidän on jäsennettävä ennakointipyyntö. Antaa ennustaa pyynnön, ensin meidän instanssia PredictRequest luokan päässä predict_pb2 moduuli. Meidän on myös määritettävä mallin_spec.name ja malli_spec.signature_name parametrit. Nimi param on "MODEL_NAME väitettä, jonka määrittelimme kun aloitimme palvelimelle. Ja signature_name viittaa looginen nimi määritetty signature_def_map () parametrin add_meta_graph () rutiinia.

Seuraavaksi meidän on toimitettava syötetiedot palvelimen allekirjoituksessa määritellyllä tavalla. Muista, että palvelimessa määritimme Predict-sovellusliittymän odottamaan kuvaa sekä kahta skalaaria (kuvan korkeus ja leveys). Syöttääksesi syötetiedot pyyntöobjektiin, TensorFlow tarjoaa apuohjelman tf.make_tensor_proto () . Tämä menetelmä luo TensorProto-objektin numpy / Python-objektista. Voimme käyttää sitä kuvan ja sen mittojen syöttämiseen pyyntöobjektiin.

Näyttää siltä, ​​että olemme valmiita soittamaan palvelimelle. Tätä varten kutsumme Predict () -menetelmää (käyttäen tynkä) ja välitämme pyyntöobjektin argumenttina.

Pyynnöille, jotka palauttavat yhden vastauksen, gRPC tukee sekä synkronisia että asynkronisia puheluita. Näin ollen, jos haluat tehdä töitä, kun pyyntö käsitellään, voisimme kutsua Predict.future () sijasta ennustaa () .

Nyt voimme noutaa ja nauttia tuloksista.

Toivottavasti pidit tästä artikkelista. Kiitos lukemisesta!

Jos haluat enemmän, tutustu:

Oman FaceID ConvNetin kouluttaminen TensorFlow Eager -sovelluksella

Kasvot ovat kaikkialla - valokuvista ja videoista sosiaalisen median verkkosivustoilla kuluttajien tietoturvasovelluksiin, kuten… medium.freecodecamp.org Sukeltaminen syvään kääntyvään semanttiseen segmentointiverkostoon ja Deeplab_V3

Deep Convolutional Neural Networks (DCNN) on saavuttanut huomattavaa menestystä erilaisissa Computer Vision -sovelluksissa ... medium.freecodecamp.org