{"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\/en\/blog\/news\/dzhedajskaya-tehnika-umensheniya-svertochnyh-setej-pruning","title":{"rendered":"Jedi technique for reducing convolutional networks \u2014 pruning","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Jedi<\/p>\n

<\/p>\n

You are once again faced with the task of object detection. The priority is the speed of operation with acceptable accuracy. You take the YOLOv3 architecture and fine-tune it. The accuracy (mAP75) should be above 0.95. However, the processing speed is still low. Damn. <\/p>\n

<\/p>\n

Today we will bypass quantization. Below, we will consider Model Pruning<\/strong> \u2014 trimming redundant parts of the network to speed up inference without losing accuracy. Clearly showing where, how much, and how you can cut. We will discuss how to do this manually and where automation can be applied. At the end \u2014 a repository on Keras.<\/p>\n

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

Introduction<\/h3>\n

<\/p>\n

At my last job, at Macroscop in Perm, I acquired a habit \u2014 always monitoring the execution time of algorithms. And always checking the networks' processing times through a sanity filter. Usually, state-of-the-art models don\u2019t pass this filter in production, which led me to Pruning. <\/p>\n

<\/p>\n

Pruning is an old topic, discussed in Stanford lectures<\/a><\/noindex> in 2017. The main idea is to reduce the size of the trained network without losing accuracy by removing different nodes. It sounds great, but I rarely hear about its application. Perhaps, there\u2019s a lack of implementations, no articles in Russian, or maybe everyone considers pruning a proprietary technique and remains silent.
\nBut let's break it down<\/p>\n

<\/p>\n

A glance at biology<\/h3>\n

<\/p>\n

I love when ideas from biology peek into Deep Learning. You can trust them, just like evolution (did you know that ReLU is quite similar to the activation function of neurons in the brain?<\/a><\/noindex>?) <\/p>\n

<\/p>\n

The Model Pruning process is also close to biology. The network's reaction can be compared to the plasticity of the brain. There are a couple of interesting examples in the book by Norman Doidge.<\/a><\/noindex>:<\/p>\n

<\/p>\n

    \n
  1. A woman's brain, which was born with only one hemisphere, reprogrammed itself to perform the functions of the missing hemisphere.<\/li>\n
  2. A guy shot himself in the part of the brain responsible for vision. Over time, other parts of the brain took over these functions. (We are not trying to repeat this)<\/li>\n<\/ol>\n

    <\/p>\n

    Just as you can cut parts of weak convolutions from your model. In the worst case, the remaining convolutions will help compensate for the ones that were cut. <\/p>\n

    <\/p>\n

    Do you prefer Transfer Learning or start from scratch?<\/h3>\n

    <\/p>\n

    Option number one.<\/strong> You are using Transfer Learning with Yolov3, Retina, Mask-RCNN, or U-Net. But most often we don't need to recognize 80 object classes like in COCO. In my experience, it's usually limited to 1-2 classes. One might assume that the architecture for 80 classes is excessive here. It raises the question of reducing the architecture. Moreover, I would like to do this without losing the existing pretrained weights.<\/p>\n

    <\/p>\n

    Option two.<\/strong> Maybe you have a lot of data and computational resources or just need a highly customized architecture. It doesn't matter. But you are training the network from scratch. The usual order is to look at the data structure, select an OVERLY powerful architecture, and apply dropout to combat overfitting. I have seen dropouts of 0.6, Carl. <\/p>\n

    <\/p>\n

    In both cases, the network can be reduced. You motivated me. Now let's figure out what pruning is.<\/p>\n

    <\/p>\n

    General algorithm<\/h3>\n

    <\/p>\n

    We decided that we can remove convolutions. This looks quite simple:<\/p>\n

    <\/p>\n

    \"Jedi<\/p>\n

    <\/p>\n

    Removing any convolution is a stress for the network, which usually leads to some increase in error. On one hand, this increase in error indicates how correctly we are removing convolutions (for example, a significant increase suggests that we are doing something wrong). However, a small increase is quite acceptable and is often mitigated by subsequent light retraining with a small LR. We add a retraining step:<\/p>\n

    <\/p>\n

    \"Jedi<\/p>\n

    <\/p>\n

    Now we need to understand when we want to stop our LearningPruning cycle. There can be exotic cases where we need to reduce the network to a specific size and speed of execution (for example, for mobile devices). However, the most common scenario is to continue the cycle until the error exceeds the acceptable level. We add a condition:<\/p>\n

    <\/p>\n

    \"Jedi<\/p>\n

    <\/p>\n

    So, the algorithm becomes clear. We just need to figure out how to identify removable convolutions.<\/p>\n

    <\/p>\n

    Finding removable convolutions<\/h3>\n

    <\/p>\n

    We need to remove certain wrappers. Blasting through and 'shooting' any of them is a bad idea, even if it might work. However, since we have intelligence, we can think and try to identify the 'weak' wrappers for removal. There are several options:<\/p>\n

    <\/p>\n

      \n
    1. Smallest L1 measure or low_magnitude_pruning<\/a><\/noindex>. The idea here is that convolutions with small weight values contribute little to the final decision-making. <\/li>\n
    2. Smallest L1 measure considering the mean and standard deviation. We complement with an evaluation of the distribution characteristics.<\/li>\n
    3. Masking of convolutions and excluding those with minimal impact on the final accuracy<\/a><\/noindex>. A more accurate definition of insignificant convolutions, but quite time-consuming and resource-intensive. <\/li>\n
    4. Others <\/li>\n<\/ol>\n

      <\/p>\n

      Each option has its place and specific implementation characteristics. Here, we will consider the option with the least L1 measure<\/p>\n

      <\/p>\n

      Manual process for YOLOv3<\/h3>\n

      <\/p>\n

      The original architecture contains residual blocks. But no matter how effective they are for deep networks, they are somewhat obstructive for us. The complexity lies in the fact that we cannot remove convolutions with different indices in these layers:<\/p>\n

      <\/p>\n

      \"Jedi<\/p>\n

      <\/p>\n

      Therefore, we will highlight the layers from which we can freely remove convolutions:<\/p>\n

      <\/p>\n

      \"Jedi<\/p>\n

      <\/p>\n

      Now let's construct the workflow loop:<\/p>\n

      <\/p>\n

        \n
      1. Dumping activations<\/li>\n
      2. Assessing how much to cut <\/li>\n
      3. Cutting<\/li>\n
      4. Training for 10 epochs with LR=1e-4 <\/li>\n
      5. Testing <\/li>\n<\/ol>\n

        <\/p>\n

        Dumping convolutions is useful to estimate what part we can remove at a given step. Examples of dumping:<\/p>\n

        <\/p>\n

        \"Jedi<\/p>\n

        <\/p>\n

        We see that almost everywhere 5% of the convolutions have a very low L1 norm, and we can remove them. This dumping was repeated at every step, and assessments were made regarding which layers and how much could be cut. <\/p>\n

        <\/p>\n

        The entire process was completed in 4 steps (here and everywhere numbers are for RTX 2060 Super):<\/p>\n

        <\/p>\n\n\n\n\n\n\n\n\n\n
        Step<\/th>\nmAp75<\/th>\nNumber of parameters, million<\/th>\nNetwork size, MB<\/th>\nFrom the original, %<\/th>\nRun time, ms<\/th>\nTrimming condition<\/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% of all<\/td>\n<\/tr>\n
        2<\/td>\n0.9625<\/td>\n50<\/td>\n197<\/td>\n83<\/td>\n168<\/td>\n5% of all<\/td>\n<\/tr>\n
        3<\/td>\n0.9633<\/td>\n39<\/td>\n155<\/td>\n64<\/td>\n155<\/td>\n15% for layers with 400+ convolutions<\/td>\n<\/tr>\n
        4<\/td>\n0.9555<\/td>\n31<\/td>\n124<\/td>\n51<\/td>\n146<\/td>\n10% for layers with 100+ convolutions<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

        <\/p>\n

        By the second step, one positive effect emerged \u2014 the batch size of 4 fit into memory, significantly speeding up the retraining process.
        \nAt the fourth step, the process was halted, as even prolonged retraining did not raise mAp75 to previous values.
        \nIn the end, inference was accelerated by 15%<\/strong>, reduced size by 35% <\/strong>and accuracy was not lost. <\/p>\n

        <\/p>\n

        Automation for simpler architectures<\/h3>\n

        <\/p>\n

        For simpler network architectures (without conditional add, concatenate, and residual blocks), it's quite feasible to focus on processing all convolutional layers and automate the process of trimming convolutions.<\/p>\n

        <\/p>\n

        I implemented this approach here<\/a><\/noindex>.
        \nIt's simple: you only need to provide the loss function, optimizer, and batch generators:<\/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
        If necessary, configuration parameters can be adjusted:<\/p>\n
        <\/p>\n
        {\n    \"input_model_path\": \"model.h5\",\n    \"output_model_path\": \"model_pruned.h5\",\n    \"finetuning_epochs\": 10, # the number of epochs for train between pruning steps\n    \"stop_loss\": 0.1, # loss for stopping process\n    \"pruning_percent_step\": 0.05, # part of convs for delete on every pruning step\n    \"pruning_standart_deviation_part\": 0.2 # shift for limit pruning part\n}<\/code><\/pre>\n
        <\/p>\n
        Additionally, a constraint based on standard deviation has been implemented. The goal is to limit the portion being removed, excluding wrappers that already have 'sufficient' L1 measures:<\/p>\n
        <\/p>\n
        \"Jedi<\/p>\n
        <\/p>\n
        Thus, we allow only weak convolutions to be removed from distributions similar to the right and not affect the removal from distributions similar to the left:<\/p>\n
        <\/p>\n
        \"Jedi<\/p>\n
        <\/p>\n
        As the distribution approaches normality, the coefficient pruning_standart_deviation_part can be selected from:<\/p>\n
        <\/p>\n
        \"Jedi
        \nI recommend a tolerance of 2 sigma. Or you can disregard this feature, leaving the value < 1.0.<\/p>\n
        <\/p>\n
        The output generates a graph of the network size, loss, and execution time throughout the test, normalized to 1.0. For example, here the network size was reduced almost by half without loss in quality (a small convolutional network with 100k weights):<\/p>\n
        <\/p>\n
        \"Jedi<\/p>\n
        <\/p>\n
        The execution speed is subject to normal fluctuations and has changed little. There is an explanation for this:<\/p>\n
        <\/p>\n
          \n
        1. The number of convolutions changes from convenient (32, 64, 128) to less convenient for graphics cards\u201427, 51, etc. I might be mistaken here, but this likely has an impact.<\/li>\n
        2. The architecture isn\u2019t wide, but it is sequential. By decreasing the width, we do not touch the depth. Thus, we reduce the load without changing the speed.<\/li>\n<\/ol>\n
          <\/p>\n
          Therefore, the improvement manifested as a 20-30% decrease in CUDA load during execution, but not in the execution time.<\/p>\n
          <\/p>\n
          Summary<\/h3>\n
          <\/p>\n
          Let's reflect. We examined 2 pruning options\u2014 for YOLOv3 (when manual intervention is needed) and for simpler architecture networks. It is evident that in both cases, a reduction in network size and acceleration can be achieved without loss of accuracy. Results:<\/p>\n
          <\/p>\n