{"id":54494,"date":"2019-12-27T00:00:00","date_gmt":"2019-12-26T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/dzhedajskaya-tehnika-umensheniya-svertochnyh-setej-pruning"},"modified":"2020-02-18T14:02:30","modified_gmt":"2020-02-18T11:02:30","slug":"dzhedajskaya-tehnika-umensheniya-svertochnyh-setej-pruning","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/news\/dzhedajskaya-tehnika-umensheniya-svertochnyh-setej-pruning","title":{"rendered":"Jedi-techniek voor het verminderen van convolutionele netwerken \u2013 pruning","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Jedi-techniek<\/p>\n

<\/p>\n

Je hebt opnieuw de taak objectdetectie. Prioriteit is de snelheid van de werking met acceptabele nauwkeurigheid. Neem de YOLOv3-architectuur en train deze verder. De nauwkeurigheid (mAp75) is meer dan 0,95. Maar de snelheid van de uitvoering is nog steeds laag. Verdorie. <\/p>\n

<\/p>\n

Vandaag zullen we kwantisatie vermijden. En onder de kat kijken we naar Model Pruning<\/strong> \u2014 het verwijderen van overbodige delen van het netwerk om de inferentie te versnellen zonder de nauwkeurigheid te verliezen. Eerst heel duidelijk \u2014 waar, hoeveel en hoe je kunt uitsnijden. We zullen bespreken hoe je dit met de hand kunt doen en waar je het kunt automatiseren. Aan het einde \u2014 een repository op keras.<\/p>\n

<\/a><\/noindex><\/p>\n

Inleiding<\/h3>\n

<\/p>\n

Bij mijn vorige werk, bij het Permse Macroscop, heb ik een gewoonte ontwikkeld \u2014 altijd de uitvoeringstijd van algoritmen in de gaten te houden. En de netwerkuitvoering altijd te controleren via een adequaatheidsfilter. Meestal halen state-of-the-art modellen deze filter niet, wat me naar Pruning heeft geleid. <\/p>\n

<\/p>\n

Pruning is een oud onderwerp, dat werd besproken in de Stanford lezingen<\/a><\/noindex> in 2017. Het belangrijkste idee is het verkleinen van de grootte van het getrainde netwerk zonder verlies van nauwkeurigheid door verschillende knopen te verwijderen. Het klinkt geweldig, maar ik hoor zelden over het gebruik ervan. Misschien zijn er niet genoeg implementaties, zijn er geen Nederlandstalige artikelen of denkt iedereen gewoon dat pruning een geheim is en zwijgt.
\nMaar laten we het analyseren<\/p>\n

<\/p>\n

Een blik in de biologie<\/h3>\n

<\/p>\n

Ik hou ervan als in Deep Learning idee\u00ebn uit de biologie worden ge\u00efntegreerd. Ze kunnen worden vertrouwd (wist je dat ReLU erg lijkt op de activatiefunctie van neuronen in de hersenen<\/a><\/noindex>?) <\/p>\n

<\/p>\n

Het proces van Model Pruning is ook vergelijkbaar met biologie. De reactie van het netwerk kan hier worden vergeleken met de plasticiteit van de hersenen. Er zijn een paar interessante voorbeelden in het boek van Norman Doidge<\/a><\/noindex>:<\/p>\n

<\/p>\n

    \n
  1. De hersenen van een vrouw die vanaf geboorte maar de helft had, herschreven zichzelf om de functies van de ontbrekende helft uit te voeren.<\/li>\n
  2. Een jongen schoot een deel van zijn hersenen weg dat verantwoordelijk was voor het gezichtsvermogen. In de loop van de tijd namen andere delen van de hersenen deze functies over. (herhalen we niet)<\/li>\n<\/ol>\n

    <\/p>\n

    Zo kun je ook zwakke convoluties uit je model snijden. In het uiterste geval kunnen de resterende convoluties de uitgesneden delen vervangen. <\/p>\n

    <\/p>\n

    Hou je van Transfer Learning of leer je vanaf nul?<\/h3>\n

    <\/p>\n

    Optie nummer \u00e9\u00e9n.<\/strong> Je gebruikt Transfer Learning met Yolov3, Retina, Mask-RCNN of U-Net. Maar vaak hoeven we geen 80 klassen objecten te herkennen, zoals in COCO. In mijn ervaring blijft het vaak beperkt tot 1-2 klassen. We zouden kunnen veronderstellen dat de architectuur voor 80 klassen hier overbodig is. Het ligt voor de hand om te denken dat we de architectuur moeten verkleinen. Bovendien willen we dit graag doen zonder dat de al bestaande voorgetrainde gewichten verloren gaan.<\/p>\n

    <\/p>\n

    Optie nummer twee.<\/strong> Misschien heb je veel data en rekenkracht, of heb je gewoon een uiterst aangepaste architectuur nodig. Dat maakt niet uit. Maar je traint het netwerk vanaf nul. De normale volgorde is: we bekijken de datastructuur, kiezen een OVERBODIGE architectuur qua vermogen en duwen dropout om overfitting te voorkomen. Ik heb dropout van 0.6 gezien, Karl. <\/p>\n

    <\/p>\n

    In beide gevallen kan het netwerk verkleind worden. We zijn gemotiveerd. Laten we nu eens kijken wat pruning inhoudt.<\/p>\n

    <\/p>\n

    Algemene algoritme<\/h3>\n

    <\/p>\n

    We hebben besloten dat we convoluties kunnen verwijderen. Dit lijkt vrij eenvoudig:<\/p>\n

    <\/p>\n

    \"Jedi-techniek<\/p>\n

    <\/p>\n

    Het verwijderen van een willekeurige convolutie is stressvol voor het netwerk, wat meestal leidt tot een zekere toename van de fout. Enerzijds is deze fouttoename een indicator van hoe goed we de convoluties verwijderen (bijvoorbeeld een grote toename geeft aan dat we iets niet goed doen). Maar een kleine toename is vaak acceptabel en kan vaak worden gecorrigeerd met een lichte hertraining met een kleine LR. Laten we een stap toevoegen voor de hertraining:<\/p>\n

    <\/p>\n

    \"Jedi-techniek<\/p>\n

    <\/p>\n

    Nu moeten we begrijpen wanneer we onze cyclus van Learning<->Pruning willen stoppen. Hier kunnen exotische situaties zijn waarbij we het netwerk tot een bepaalde grootte en snelheid willen verkleinen (bijvoorbeeld voor mobiele apparaten). Echter, de meest voorkomende optie is om door te gaan met de cyclus totdat de fout boven de toegestane drempel komt. Laten we een voorwaarde toevoegen:<\/p>\n

    <\/p>\n

    \"Jedi-techniek<\/p>\n

    <\/p>\n

    Dus, het algoritme wordt duidelijk. Het enige wat overblijft is te bespreken hoe we te verwijderen convoluties kunnen identificeren.<\/p>\n

    <\/p>\n

    Zoeken naar te verwijderen convoluties<\/h3>\n

    <\/p>\n

    We need to remove some convolutions. Charging through and 'shooting down' any is a bad idea, even though it might work. But since we have a brain, we can think and try to identify the 'weak' convolutions for removal. There are several options:<\/p>\n

    <\/p>\n

      \n
    1. De laagste L1-metriek of low_magnitude_pruning<\/a><\/noindex>. Het idee is dat convoluties met lage gewichten een geringe bijdrage leveren aan de uiteindelijke beslissing. <\/li>\n
    2. De laagste L1-metriek met inachtneming van het gemiddelde en de standaardafwijking. We voegen een inschatting van de verdelingskarakteristiek toe.<\/li>\n
    3. Maskeren van convoluties en uitsluiten van de minst invloedrijke op de uiteindelijke nauwkeurigheid<\/a><\/noindex>. Een nauwkeurigere bepaling van onbeduidende convoluties, maar zeer tijd- en resource-intensief. <\/li>\n
    4. Andere <\/li>\n<\/ol>\n

      <\/p>\n

      Elk van de opties heeft recht op bestaan en zijn eigen implementatiekenmerken. We zullen de optie met de laagste L1-maat bekijken<\/p>\n

      <\/p>\n

      Handmatig proces voor YOLOv3<\/h3>\n

      <\/p>\n

      In de oorspronkelijke architectuur zijn er residuele blokken. Maar hoe geweldig ze ook zijn voor diepe netwerken, ze zullen ons iets in de weg staan. Het probleem is dat we convoluties met verschillende indexen in deze lagen niet kunnen verwijderen:<\/p>\n

      <\/p>\n

      \"Jedi-techniek<\/p>\n

      <\/p>\n

      Daarom zullen we de lagen identificeren waarvan we de convoluties vrij kunnen verwijderen:<\/p>\n

      <\/p>\n

      \"Jedi-techniek<\/p>\n

      <\/p>\n

      Laten we nu een werkcyclus opzetten:<\/p>\n

      <\/p>\n

        \n
      1. Activaties exporteren<\/li>\n
      2. Bepalen hoeveel te snijden <\/li>\n
      3. Snijden<\/li>\n
      4. Train 10 epochs met LR=1e-4 <\/li>\n
      5. Testen <\/li>\n<\/ol>\n

        <\/p>\n

        Het is nuttig om convoluties te exporteren om te beoordelen welk deel we bij een bepaalde stap kunnen verwijderen. Voorbeelden van export:<\/p>\n

        <\/p>\n

        \"Jedi-techniek<\/p>\n

        <\/p>\n

        We zien dat bijna overal 5% van de convoluties een zeer lage L1-norm heeft en we ze kunnen verwijderen. Bij elke stap werd deze export herhaald en werd beoordeeld uit welke lagen en hoeveel er kan worden gesneden. <\/p>\n

        <\/p>\n

        Het hele proces viel binnen 4 stappen (hier en overal zijn de getallen voor RTX 2060 Super):<\/p>\n

        <\/p>\n\n\n\n\n\n\n\n\n\n
        Stap<\/th>\nmAp75<\/th>\nAantal parameters, mln<\/th>\nNetwerk grootte, mb<\/th>\nVan het oorspronkelijke, %<\/th>\nTijd per run, ms<\/th>\nSneedvoorwaarde<\/th>\n<\/tr>\n<\/thead>\n
        0<\/td>\n0.9656<\/td>\n60<\/td>\n241<\/td>\n100<\/td>\n180<\/td>\n\u2014<\/td>\n<\/tr>\n
        1<\/td>\n0.9622<\/td>\n55<\/td>\n218<\/td>\n91<\/td>\n175<\/td>\n5% van allemaal<\/td>\n<\/tr>\n
        2<\/td>\n0.9625<\/td>\n50<\/td>\n197<\/td>\n83<\/td>\n168<\/td>\n5% van allemaal<\/td>\n<\/tr>\n
        3<\/td>\n0.9633<\/td>\n39<\/td>\n155<\/td>\n64<\/td>\n155<\/td>\n15% voor lagen met 400+ convoluties<\/td>\n<\/tr>\n
        4<\/td>\n0.9555<\/td>\n31<\/td>\n124<\/td>\n51<\/td>\n146<\/td>\n10% voor lagen met 100+ convoluties<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

        <\/p>\n

        Bij stap 2 kwam er een positief effect bij \u2014 de batch-grootte 4 paste in het geheugen, wat het proces van fine-tuning aanzienlijk versneld heeft.
        \nBij stap 4 werd het proces gestopt, omdat zelfs langdurige fine-tuning de mAp75 niet naar de oude waarden kon brengen.
        \nUiteindelijk is het gelukt om de inferentie te versnellen met 15%<\/strong>, de grootte te verminderen met 35% <\/strong>en geen nauwkeurigheid te verliezen. <\/p>\n

        <\/p>\n

        Automatisering voor eenvoudigere architecturen<\/h3>\n

        <\/p>\n

        Voor eenvoudigere netwerkarchitecturen (zonder voorwaardelijke add, concatenate en residuele blokken) kan men zich gerust richten op de verwerking van alle convolutielaag en het proces van het snijden van convoluties automatiseren.<\/p>\n

        <\/p>\n

        Deze optie heb ik ge\u00efmplementeerd hier<\/a><\/noindex>.
        \nHet is heel eenvoudig: u heeft alleen een verliesfunctie, optimizer en batch-generatoren nodig:<\/p>\n

        <\/p>\n

        import pruning\nfrom keras.optimizers import Adam\nfrom keras.utils import Sequence\n\ntrain_batch_generator = BatchGenerator...\nscore_batch_generator = BatchGenerator...\n\nopt = Adam(lr=1e-4)\npruner = pruning.Pruner(\"config.json\", \"categorical_crossentropy\", opt)\n\npruner.prune(train_batch, valid_batch)<\/code><\/pre>\n
        <\/p>\n
        Indien nodig kunnen de configuratieparameters worden gewijzigd:<\/p>\n
        <\/p>\n
        {\n    \"input_model_path\": \"model.h5\",\n    \"output_model_path\": \"model_pruned.h5\",\n    \"finetuning_epochs\": 10, # het aantal epochs voor training tussen de prune-stappen\n    \"stop_loss\": 0.1, # verlies voor het stoppen van het proces\n    \"pruning_percent_step\": 0.05, # deel van convs om te verwijderen bij elke prune-stap\n    \"pruning_standart_deviation_part\": 0.2 # verschuiving voor het beperken van de prune-deel\n}<\/code><\/pre>\n
        <\/p>\n
        Additionally, a limit has been implemented based on the standard deviation. The goal is to restrict the removed part, excluding convolutions with already 'sufficient' L1 measures:<\/p>\n
        <\/p>\n
        \"Jedi-techniek<\/p>\n
        <\/p>\n
        Hierdoor kunnen we alleen zwakke convoluties uit verdelingen zoals de rechter verwijderen en niet be\u00efnvloeden hoe we verwijderen uit verdelingen zoals de linker:<\/p>\n
        <\/p>\n
        \"Jedi-techniek<\/p>\n
        <\/p>\n
        Bij benadering van een normale verdeling kan de coefficient pruning_standart_deviation_part worden gekozen uit:<\/p>\n
        <\/p>\n
        \"Jedi-techniek
        \nIk raad een marge van 2 sigma aan. Of je kunt deze eigenschap negeren, waarbij je de waarde < 1.0 laat.<\/p>\n
        <\/p>\n
        Het resultaat is een grafiek van de netwerkgrootte, verlies en verwerkingstijd van het netwerk over de hele test, genormaliseerd naar 1.0. Bijvoorbeeld, hier is de netwerkgrootte bijna met de helft verminderd zonder kwaliteitsverlies (een kleine convolutienetwerk met 100k gewichten):<\/p>\n
        <\/p>\n
        \"Jedi-techniek<\/p>\n
        <\/p>\n
        De verwerkingssnelheid is onderhevig aan normale fluktuaties en is praktisch niet veranderd. Hier is een verklaring voor:<\/p>\n
        <\/p>\n
          \n
        1. Het aantal convoluties verandert van een handige (32, 64, 128) naar minder handige voor grafische kaarten - 27, 51, enzovoorts. Ik kan hierin fout zijn, maar het is waarschijnlijk dat dit invloed heeft.<\/li>\n
        2. De architectuur is niet breed, maar sequentieel. Door de breedte te verkleinen, veranderen we de diepte niet. Hierdoor verminderen we de belasting, maar veranderen we de snelheid niet.<\/li>\n<\/ol>\n
          <\/p>\n
          Daarom blijkt de verbetering in een vermindering van de CUDA-belasting van 20-30% tijdens de verwerking, maar niet in een vermindering van de verwerkingstijd.<\/p>\n
          <\/p>\n
          Conclusies<\/h3>\n
          <\/p>\n
          Laten we reflecteren. We hebben 2 varianten van pruning bekeken - voor YOLOv3 (waarbij handmatige aanpassingen nodig zijn) en voor netwerken met eenvoudigere architecturen. Het is duidelijk dat in beide gevallen de grootte van het netwerk kan worden verminderd en de snelheid kan worden verhoogd zonder nauwkeurigheid te verliezen. Resultaten:<\/p>\n
          <\/p>\n