{"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\/it\/blog\/novosti-interneta\/dzhedajskaya-tehnika-umensheniya-svertochnyh-setej-pruning","title":{"rendered":"Tecnica Jedi per ridurre le reti convoluzionali \u2014 pruning","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Tecnica<\/p>\n

<\/p>\n

Hai di nuovo un compito di rilevamento degli oggetti. La priorit\u00e0 \u00e8 la velocit\u00e0 operativa mantenendo una precisione accettabile. Utilizzi l'architettura YOLOv3 e fai un ulteriore addestramento. La precisione (mAp75) \u00e8 superiore a 0,95. Ma la velocit\u00e0 di esecuzione \u00e8 ancora bassa. Accidenti. <\/p>\n

<\/p>\n

Oggi eviteremo la quantizzazione. Sotto il post daremo uno sguardo a Model Pruning<\/strong> \u2014 potatura delle parti ridondanti della rete per velocizzare l'Inference senza perdita di precisione. In modo visivo \u2014 da dove, quanto e come possiamo rimuovere. Analizzeremo come farlo manualmente e dove possiamo automatizzare. Alla fine \u2014 un repository su keras.<\/p>\n

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

Introduzione<\/h3>\n

<\/p>\n

Nel mio precedente lavoro presso Macroscop a Perm, ho acquisito un'abitudine: monitorare sempre i tempi di esecuzione degli algoritmi. E i tempi di esecuzione delle reti devono sempre essere controllati tramite un filtro di adeguatezza. Di solito, i modelli state-of-the-art non superano questo filtro, il che mi ha portato al Pruning. <\/p>\n

<\/p>\n

Il Pruning \u00e8 un tema vecchio, di cui si parlava nelle lezioni di Stanford<\/a><\/noindex> del 2017. L'idea principale \u00e8 quella di ridurre le dimensioni di una rete addestrata senza perdere precisione attraverso la rimozione di vari nodi. Sembra interessante, ma raramente sento parlare del suo utilizzo. Forse mancano implementazioni, non ci sono articoli in russo o semplicemente tutti considerano il pruning come un know-how e tacciono.
\nMa andiamo a esplorare<\/p>\n

<\/p>\n

Uno sguardo alla biologia<\/h3>\n

<\/p>\n

Mi piace quando nel Deep Learning si introducono idee derivate dalla biologia. A queste, come all'evoluzione, ci si pu\u00f2 fidare (sapevi che ReLU \u00e8 molto simile alla funzione di attivazione dei neuroni nel cervello<\/a><\/noindex>?) <\/p>\n

<\/p>\n

Il processo di Model Pruning \u00e8 anch'esso vicino alla biologia. La reazione della rete qui pu\u00f2 essere paragonata alla plasticit\u00e0 del cervello. Ci sono alcuni esempi interessanti nel libro di Norman Doidge<\/a><\/noindex>:<\/p>\n

<\/p>\n

    \n
  1. Il cervello di una donna, nata con solo met\u00e0, ha riprogrammato se stesso per eseguire le funzioni della met\u00e0 mancante.<\/li>\n
  2. Un ragazzo si \u00e8 sparato in testa, colpendo la parte del cervello responsabile della vista. Col tempo, altre parti del cervello hanno preso in carico tali funzioni. (non cerchiamo di ripetere)<\/li>\n<\/ol>\n

    <\/p>\n

    Cos\u00ec puoi rimuovere parte delle convoluzioni dalla tua modella. In casi estremi, le convoluzioni rimanenti potranno sostituire quelle rimosse. <\/p>\n

    <\/p>\n

    Preferisci il Transfer Learning o addestri da zero?<\/h3>\n

    <\/p>\n

    Opzione numero uno.<\/strong> Utilizzi il Transfer Learning su Yolov3. Retina, Mask-RCNN o U-Net. Ma molto spesso non abbiamo bisogno di riconoscere 80 classi di oggetti, come nel COCO. Nella mia esperienza, ci limitiamo a 1-2 classi. Si potrebbe supporre che l'architettura per 80 classi sia eccessiva qui. Il pensiero di ridurre l'architettura si impone. Inoltre, si desidera fare ci\u00f2 senza perdere i pesi pre-addestrati esistenti.<\/p>\n

    <\/p>\n

    Opzione numero due.<\/strong> Potresti avere molti dati e risorse computazionali o semplicemente una architettura super personalizzata. Non importa. Ma stai addestrando la rete da zero. L'ordine abituale \u00e8 analizzare la struttura dei dati, selezionare un'architettura sovrabbondante in potenza e spingere i dropout contro il sovra-adattamento. Ho visto dropout a 0,6, Carl. <\/p>\n

    <\/p>\n

    In entrambi i casi la rete pu\u00f2 essere ridotta. Ti abbiamo motivato. Ora andiamo a capire che cos'\u00e8 la potatura.<\/p>\n

    <\/p>\n

    Algoritmo generale<\/h3>\n

    <\/p>\n

    Abbiamo deciso che possiamo rimuovere convoluzioni. Sembra abbastanza semplice:<\/p>\n

    <\/p>\n

    \"Tecnica<\/p>\n

    <\/p>\n

    Rimuovere qualsiasi convoluzione \u00e8 uno stress per la rete, che di solito porta a un certo aumento dell'errore. Da un lato, questo aumento dell'errore \u00e8 un indicatore di quanto correttamente stiamo rimuovendo le convoluzioni (ad esempio, un grande aumento indica che stiamo facendo qualcosa di sbagliato). Ma un lieve aumento \u00e8 piuttosto accettabile e spesso viene eliminato con un successivo leggero riaddestramento con un LR ridotto. Aggiungiamo un passo per il riaddestramento:<\/p>\n

    <\/p>\n

    \"Tecnica<\/p>\n

    <\/p>\n

    Ora dobbiamo capire quando vogliamo interrompere il nostro ciclo Learning<->Pruning. Qui possono esserci varianti esotiche, quando dobbiamo ridurre la rete a una certa dimensione e velocit\u00e0 di esecuzione (ad esempio, per dispositivi mobili). Tuttavia, la variante pi\u00f9 comune \u00e8 continuare il ciclo finch\u00e9 l'errore non supera i limiti accettabili. Aggiungiamo una condizione:<\/p>\n

    <\/p>\n

    \"Tecnica<\/p>\n

    <\/p>\n

    Quindi, l'algoritmo diventa chiaro. Resta da capire come determinare le convoluzioni da rimuovere.<\/p>\n

    <\/p>\n

    Ricerca delle convoluzioni da rimuovere<\/h3>\n

    <\/p>\n

    Dobbiamo rimuovere alcuni involtini. Andare a rompere e 'abbattere' qualsiasi cosa \u00e8 una cattiva idea, anche se funzioner\u00e0. Ma se si usa la testa, si pu\u00f2 pensare e provare a isolare per la rimozione gli involtini 'deboli'. Ci sono diverse opzioni:<\/p>\n

    <\/p>\n

      \n
    1. Minimo L1 o low_magnitude_pruning<\/a><\/noindex>. L'idea \u00e8 che le convoluzioni con valori di pesi bassi contribuiscono poco alla decisione finale. <\/li>\n
    2. Minimo L1 con medio e deviazione standard. Completiamo la valutazione della distribuzione.<\/li>\n
    3. Mascheramento delle convoluzioni ed esclusione delle meno influenti sulla precisione finale.<\/a><\/noindex>. Una definizione pi\u00f9 precisa delle convoluzioni insignificanti, ma piuttosto costosa in termini di tempo e risorse. <\/li>\n
    4. Altre <\/li>\n<\/ol>\n

      <\/p>\n

      Ognuna delle opzioni ha diritto di esistere e le proprie caratteristiche di implementazione. Qui analizzeremo l'opzione con il minimo L1.<\/p>\n

      <\/p>\n

      Processo manuale per YOLOv3<\/h3>\n

      <\/p>\n

      Nell'architettura originale ci sono blocchi residui. Ma per quanto possano essere utili per le reti profonde, possono darci qualche problema. La difficolt\u00e0 sta nel non poter rimuovere le convoluzioni con indici diversi in questi strati:<\/p>\n

      <\/p>\n

      \"Tecnica<\/p>\n

      <\/p>\n

      Pertanto, evidenziamo gli strati da cui possiamo rimuovere liberamente le convoluzioni:<\/p>\n

      <\/p>\n

      \"Tecnica<\/p>\n

      <\/p>\n

      Ora creiamo un ciclo di lavoro:<\/p>\n

      <\/p>\n

        \n
      1. Scarichiamo le attivazioni<\/li>\n
      2. Stabiliamo quanto tagliare <\/li>\n
      3. Tagliamo<\/li>\n
      4. Alleniamo per 10 epoche con LR=1e-4 <\/li>\n
      5. Testiamo <\/li>\n<\/ol>\n

        <\/p>\n

        Scaricare le convoluzioni \u00e8 utile per valutare quale parte possiamo rimuovere in un determinato passo. Esempi di scarico:<\/p>\n

        <\/p>\n

        \"Tecnica<\/p>\n

        <\/p>\n

        Osserviamo che quasi ovunque il 5% delle convoluzioni ha una norma L1 molto bassa e possiamo rimuoverle. A ogni passo, questo scarico veniva ripetuto e veniva effettuata una valutazione di quali strati e quanto si poteva rimuovere. <\/p>\n

        <\/p>\n

        L'intero processo si \u00e8 svolto in 4 passi (qui e ovunque i numeri sono per RTX 2060 Super):<\/p>\n

        <\/p>\n\n\n\n\n\n\n\n\n\n
        Passo<\/th>\nmAp75<\/th>\nNumero di parametri, mln<\/th>\nDimensione della rete, mb<\/th>\nDall'iniziale, %<\/th>\nTempo di esecuzione, ms<\/th>\nCondizione di pruning<\/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% del totale<\/td>\n<\/tr>\n
        2<\/td>\n0.9625<\/td>\n50<\/td>\n197<\/td>\n83<\/td>\n168<\/td>\n5% del totale<\/td>\n<\/tr>\n
        3<\/td>\n0.9633<\/td>\n39<\/td>\n155<\/td>\n64<\/td>\n155<\/td>\n15% per strati con oltre 400 convoluzioni<\/td>\n<\/tr>\n
        4<\/td>\n0.9555<\/td>\n31<\/td>\n124<\/td>\n51<\/td>\n146<\/td>\n10% per strati con oltre 100 convoluzioni<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

        <\/p>\n

        Al secondo passo \u00e8 emerso un effetto positivo: \u00e8 riuscito a far entrare nella memoria un batch size di 4, che ha notevolmente accelerato il processo di riaddestramento.
        \nNel quarto passo, il processo si \u00e8 fermato, poich\u00e9 anche un lungo riaddestramento non ha aumentato il mAp75 ai valori precedenti.
        \nIn definitiva, siamo riusciti ad accelerare l'inferenza di 15%<\/strong>, ridurre la dimensione di 35% <\/strong>e non perdere in precisione. <\/p>\n

        <\/p>\n

        Automazione per architetture pi\u00f9 semplici<\/h3>\n

        <\/p>\n

        Per architetture di rete pi\u00f9 semplici (senza blocchi condizionali add, concatenate e residual) \u00e8 possibile orientarsi al trattamento di tutti gli strati convoluzionali e automatizzare il processo di rimozione delle convoluzioni.<\/p>\n

        <\/p>\n

        Questa opzione l'ho implementata qui<\/a><\/noindex>.
        \n\u00c8 semplice: a voi serve solo la funzione di perdita, l'ottimizzatore e i generatori di batch:<\/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
        \u00c8 possibile modificare i parametri di configurazione se necessario:<\/p>\n
        <\/p>\n
        {\n    \"input_model_path\": \"model.h5\",\n    \"output_model_path\": \"model_pruned.h5\",\n    \"finetuning_epochs\": 10, # il numero di epoche per l'allenamento tra i passi di pruning\n    \"stop_loss\": 0.1, # perdita per fermare il processo\n    \"pruning_percent_step\": 0.05, # parte delle convoluzioni da eliminare a ogni passo di pruning\n    \"pruning_standart_deviation_part\": 0.2 # limite per la parte di pruning\n}<\/code><\/pre>\n
        <\/p>\n
        \u00c8 stata inoltre implementata una limitazione basata sulla deviazione standard. L'obiettivo \u00e8 limitare la parte da rimuovere, escludendo gli involtini con gi\u00e0 'sufficienti' misure L1:<\/p>\n
        <\/p>\n
        \"Tecnica<\/p>\n
        <\/p>\n
        In questo modo, permettiamo di rimuovere solo le convoluzioni deboli dalle distribuzioni simili a quella di destra, senza influenzare la rimozione dalle distribuzioni simili a quella di sinistra:<\/p>\n
        <\/p>\n
        \"Tecnica<\/p>\n
        <\/p>\n
        Avvicinandosi a una distribuzione normale, il coefficiente pruning_standart_deviation_part pu\u00f2 essere scelto da:<\/p>\n
        <\/p>\n
        \"Tecnica
        \nConsiglio di utilizzare una tolleranza di 2 sigma. Oppure si pu\u00f2 non fare riferimento a questa caratteristica, mantenendo il valore < 1.0.<\/p>\n
        <\/p>\n
        In output, arriva un grafico della dimensione della rete, delle perdite e del tempo di esecuzione della rete durante tutto il test, normalizzati a 1.0. Ad esempio, qui la dimensione della rete \u00e8 stata ridotta di quasi la met\u00e0 senza perdita di qualit\u00e0 (una piccola rete convoluzionale con 100k pesi):<\/p>\n
        <\/p>\n
        \"Tecnica<\/p>\n
        <\/p>\n
        La velocit\u00e0 di esecuzione \u00e8 soggetta a normali fluttuazioni e in sostanza non \u00e8 cambiata. Ci\u00f2 ha una spiegazione:<\/p>\n
        <\/p>\n
          \n
        1. Il numero di convoluzioni cambia da valori possibili (32, 64, 128) a valori non cos\u00ec comodi per le schede grafiche \u2014 27, 51 ecc. Potrei sbagliarmi, ma \u00e8 probabile che questo influisca.<\/li>\n
        2. L'architettura non \u00e8 ampia, ma sequenziale. Riducendo la larghezza, non tocchiamo la profondit\u00e0. Di conseguenza, riduciamo il carico senza modificare la velocit\u00e0.<\/li>\n<\/ol>\n
          <\/p>\n
          Pertanto, il miglioramento si \u00e8 tradotto in una riduzione del carico CUDA durante l'esecuzione dal 20 al 30%, ma non in una riduzione del tempo di esecuzione.<\/p>\n
          <\/p>\n
          Risultati<\/h3>\n
          <\/p>\n
          Riflettiamo. Abbiamo esaminato 2 opzioni di pruning \u2014 per YOLOv3 (quando \u00e8 necessario lavorare manualmente) e per reti con architetture pi\u00f9 semplici. \u00c8 evidente che in entrambi i casi si possono ottenere dimensioni di rete inferiori e velocizzazione senza perdere precisione. Risultati:<\/p>\n
          <\/p>\n