こんにちは、LeapMindで楽しく働いている中村です。
競技プログラミング、してますか？
プログラミングコンテストに参加したいこと、長い人生で、たまにはありますよね。
今回は、PG BATTLE 2021にチャレンジしてみました。
<h1 id="pg-battle-とは">PG BATTLE とは？</h1>
<blockquote>
PG BATTLEは、1チーム3名による企業・学校対抗プログラミングコンテストです。作品を提出して審査する方式ではなく、出題された問題を解くプログラムを90分間に4つ書いてオンライン提出するガチ勝負。
<a href="https://products.sint.co.jp/pg_battle">https://products.sint.co.jp/pg_battle</a>
</blockquote>
まるで作品を提出して審査する方式はガチではないと言いたげです。
<h1 id="ルール">ルール</h1>
<blockquote>
3人の合計点数で競います（300点満点）。同じ点数の場合は、解答時間の短い方が上位となります。
</blockquote>
<a href="https://web-ext.u-aizu.ac.jp/pc-concours/">パソコン甲子園</a>や<a href="https://icpc.iisf.or.jp/">ICPC</a>などの他のプログラミングコンテストとの大きな違いは、チームで1つの問題に取り組むのではなく、チームの3名それぞれが別の問題に挑戦する点です。
チーム戦というよりは団体戦というべきでしょうか。
入賞を逃した際の責任の所在が明らかになりがちなため、LM社内では友情破壊コンテストと恐れられています。
<h1 id="メンバー">メンバー</h1>
PG BATTLEに問題を提供している<a href="https://atcoder.jp">AtCoder</a>のレートが高い順に三人を選びました。（社員向け：もし参加していない方で参加したメンバーよりレートが高い人がいれば教えてください）
チーム名は「超低消費電力AIアクセラレータIP EFFICIERA」。
<a href="https://leapmind.io/business/ip/">Efficieraは、FPGAデバイス上もしくはASIC/ASSPデバイス上の回路として動作するCNNの推論演算処理に特化した超低消費電力AIアクセラレータIPです。</a>
メンバー全員がEfficiera Compilation Toolの開発に携わっています。
<h1 id="結果"><a href="https://products.sint.co.jp/pg_battle_2021/result">結果</a></h1>
100+100+40の240点で、3位に入賞することができました。
1位から4位までが相異なる点数だったため、今回はタイムはあまり関係なかったようです。
賞品としてamazonギフト券6万円分を頂きました。
得点に比例させて 25000 + 25000 + 10000 に分割することも考えましたが、友情破壊を防ぐための配慮なのか、2万円分のカードが3枚送られてきたため、素直に三等分しました。
また、副賞としてトロフィーを頂いたのですが、こちらは三等分する方法が分からなかったため、オフィスに飾ってあります。
<img src="/images/posts/techblog/20211217-trophy.jpg" alt="トロフィー">
<h1 id="感想">感想</h1>
コンテストに参加したメンバーから感想を聞いてみました。
<ul>
<li>「ましゅまろ」：次回は優勝します</li>
<li>「せんべい」：素早く解いて余った時間で見直しをしようと思っていました。Dまで解いたら89分経っていました。</li>
<li>「かつおぶし」：楽しかったです</li>
</ul>
<h1 id="終わりに">終わりに</h1>
LeapMindでは、競技プログラミングで培ったアルゴリズムの経験を生かして楽しく仕事をしています。
ところで、LeapMindではエンジニアを募集しています。PG BATTLEに参加したい人も、そうでない人も、興味がある方は<a href="https://leapmind.io/careers/">ぜひ一度LeapMindの採用ページから応募してみてください</a>。

PG BATTLE 2021 に参加しました

Have you ever named your experiment <code>rnet50_sgd-cos-lr1e-2_imnet200_augs-ver8</code>?
Have you ever experienced that awkward silence when your manager asks you to reproduce an experiment,
which you cannot do, because you have overwritten original code and lost the initial value of a learning rate?
If your answer is yes, we have something for you.
<h1 id="best-practices">Best practices</h1>
In AI research, your efficiency depends on how quickly you implement and deploy ideas.
The efficiency of your team depends on how quickly they can reuse or reproduce things you crafted.
For that reason, your team should implement a standardized protocol of communication and exchange of experimental setups.
At LeapMind, we use hydra along with PyTorch Lightning templates which we believe is the best practice for organizing AI research.
<img src="/images/posts/techblog/20200828-joniak-hydra-lightning/hydra-lightning.png" alt="An overview of the environment we use at LeapMind.">
An overview of the environment we use at LeapMind.
<h1 id="organize-your-code-lightning">Organize your code: Lightning</h1>
Do you know this mantra?
Data, gpu, feed forward, loss, zero grad, backward and logging?
A lot of logging. Well, that’s the training loop which you saw a million times and which looks the same for every project.
With an exception that sometimes it might get enormously long and nasty when adding more and more functionalities.
Here is where Pytorch Lightning comes in.
Simply saying, it’s an organized way to write a training loop.
Saying precisely: it’s a way to separate research and engineering by decoupling data from model and model from the training mechanism.
Let’s look at an example.
<code>LightningModule</code>, the core of the Lightning, defines functions as: <code>configure_optimizers()</code>, <code>forward()</code>, <code>training_step()</code>, <code>training_epoch_end()</code>.
Does it sound familiar?
Yes, this is where you write logic you would normally put in the loop.
This time, however, everything is neatly organized and – hold on to your code – Lightning will launch and manage the training loop for you.
The <code>LightningModule</code> defines <code>forward()</code> – does it mean the definition of your <code>SuperResNet50</code> also goes there?
No! It stays where it’s always been, in <code>superesrnet50.py</code>, you only inject its dependency into the module and call it in the forward.
Similar happens to a dataset: it gets injected to a so called <code>DataModule</code>,
where only five methods are to be implemented: <code>setup()</code>, <code>prepare_data()</code>, <code>{train, val, test}_dataloader()</code>.
As one might guess, the Lightning engine will call these methods whenever needed – so you don’t need to worry about the training flow.
Do you see an advantage of the Lightning now?
Thanks to it, a model, data and training do not depend on each other, meaning you can easily replace any of them.
Just imagine how much flexibility it gives when trying out new network architectures!
We won’t dive into technical details on the Lighting as its official documentation is a great resource.
<h1 id="organize-your-experimental-setups-hydra">Organize your experimental setups: hydra</h1>
The most common way to pass parameters to your system is, unfortunately, the <code>argparse</code>.
Let’s face the truth: these projects are just nasty – <code>argparse</code>-ing takes a lot of code which is often totally unreadable.
On the top, how does one know what arguments to pass to reproduce your experiments? Wrap them up in a <code>.sh</code> file?
Do we add more <code>argparse</code>s as the project grows?
Certainly not.
Fortunately we have hydra.
Thanks to hydra we can elegantly separate experiment configuration from code – in the same way we decoupled model and data using lightning.
An example would tell it all.
Suppose we have a custom lightning module with following signature:
<pre><code class="hljs language-python">class SueperResNet50Module(pl.LightningModule):
def __init__(self, network: nn.Module, loss_fn: nn.Module, lr: float, epochs: int):
...
</code></pre>
Note it’s already the Lightning module, meaning we would define training logic in there.
To instantiate the module, we could write the following <code>.yaml</code> file:
<pre><code class="hljs language-yaml">_target_: src.pl_datamodules.imagenet.CustomImageNetDM

network:
	_target_: src.architecture.SuperResNet50
loss_fn:
	_target_: torch.nn.CrossEntropyLoss
lr: 1e-2
epoch: 100
</code></pre>
First, notice the special keyword, <code>_target_</code> which specifies instantiatable objects.
As a value, it takes a package name followed by a class name.
It can be either a library (eg. <code>torch.nn.CrossEntropyLoss</code>), or our own package (<code>src.pl_datamodules.imagenet.CustomImageNetDM</code>).
Second, hydra will automatically attempt to match targets with object argument names, i.e. config value <code>lr</code> will be passed to the <code>lr</code> argument, and so on.
Do you need to run an experiment with a different learning rate now?
It’s as easy as writing a new config file – clean and easy to reproduce.
But hold on, isn't it burdensome to create a new file which differs on only one value?
Absolutely not! Keep in mind that the goal is to create an environment where everything is easily reproducible
(one could suggest overriding hydra config at terminal level just for that one value – we strongly disrecommend it for the same reasons as <code>argpase</code>-ing).
<h1 id="putting-it-all-together">Putting it all together</h1>
Of course, we don’t need to put the whole experimental setup in one big <code>yaml</code> file.
Actually, we do strive for modular configs, in the same fashion as we write our code modular.
Consequently, we would have separate files to configure model, data module, optimizer, and even a tensorboard logger.
Here is an outline of a template we use at LeapMind,it is inspired on
<a href="https://github.com/ashleve/lightning-hydra-template">ashleve</a>’s
theme:
<pre><code>.
├── configs
│ ├── callbacks
│ ├── datamodule
│ ├── experiment
│ ├── logger
│ ├── model
│ ├── optimizer
│ ├── scheduler
│ ├── trainer
│ ├── transforms
│ └── config.yaml
├── src
│ ├── architecture 
│ ├── datasets 
│ ├── pl_datamodules 
│ ├── pl_models
│ └── utils
└── run.py
</code></pre>
Generally, <code>src</code> includes all python scripts and <code>configs</code> has all <code>yaml</code> files.
The heart of the system is <code>run.py</code> – it’s hydra wrapper which glues both <code>configs</code> with <code>src</code>.
See
<a href="https://hydra.cc/docs/intro/#quick-start-guide">official tutorial</a>
to learn how to do it (spoiler: it’s super easy, it’s just one decorator).
We recommend that initially <code>configs</code> contain the default configuration of a model, e.g a baseline.
Once confings for each single part of a project are defined, “aggregate” them in one master file, <code>config.yaml</code>:
<pre><code class="hljs language-yaml">defaults:
 - trainer: superresnet50_trainer.yaml
 - model: superresnet50.yaml
 - optimizer: sgd.yaml
 - datamodule: imagenet.yaml
 - logger: tensorboard.yaml 
</code></pre>
Suppose you need to conduct an experiment with a new lr value.
First, create a new config under <code>configs/experiments</code>, then include the default configs, and finally override only those that you need:
<pre><code class="hljs language-yaml">defaults:
 - override /trainer: superresnet50_trainer.yaml
 - override /model: superresnet50.yaml
 - override /optimizer: sgd.yaml
 - override /datamodule: imagenet.yaml
 - override /logger: tensorboard.yaml

datamodule:
data_dir: /data/imagenet-small
	batch_size: 64

model:
num_classes: 200
learning_rate: 1e-3
</code></pre>
In the development stage, feel free to modify the experiment configs.
However, as soon as you made progress, freeze the configs and share it with your team, e.g by merging it to master branch on git, where it would remain untouched forever.
If you want to add further changes, create a new config file!
<h2 id="ready-to-boost-your-ai-research">Ready to boost your AI research?</h2>
Adding more layers of abstraction to the project might seem just cumbersome – but believe us – it’s really not!
At LeapMind, hydra+lightning template was initially deployed on a small internal project,
but eventually ended up being used company-wide, with many engineers using the same config files.
It did save us many hours and it significantly boosted our workflow.
Are you ready to boost your AI research now?
Or maybe would you like to write some configs <a href="https://leapmind.io/careers/">with us</a>?
 
<hr>
 
Written by Przemyslaw Joniak
Przemyslaw is a graduate student at The University of Tokyo. He appears at LeapMind a few days a week where he works on improving performance of our models.

Learn the best practices we use at LeapMind.

Boost your AI research with hydra+Lightning templates

Buildkiteを利用して拡張性の高いセルフホスト型のCI環境を構築する

LeapMindの<a href="https://mogel.la/">花元</a>です。
ディープラーニング、してますか？
ディープラーニングするとき、最も困ることの1つはデータセットを見つけることです。特に、商用利用する場合にはライセンスの問題で利用できるデータセットがかなり限られてしまいます。また、商用利用可能となっているデータセットも、画像の権利関係が不明である等、利用にリスクがあるケースがあり、データセットの選定に苦労している人は多いのではないかと思います。
今回はこのような問題を解決してくれるかもしれないデータセットについて紹介します。
<h2 id="pre-training-without-natural-images">Pre-training without Natural Images</h2>
<a href="https://hirokatsukataoka16.github.io/Pretraining-without-Natural-Images/">Pre-training without Natural Images</a>は、ImageNetのような自然画像からなるデータセットの代替として、人工画像であるフラクタル画像を自動生成するアルゴリズム及びデータセットを提案しています。また、単にパラメータからフラクタル画像を自動生成するのみならず、同一のカテゴリに含まれるフラクタル画像を生成するためのパラメータを生成するアルゴリズムも提案していることから、事実上無制限に画像を生成することが可能となっています。
<h3 id="実験">実験</h3>
実験では、CIFAR-10/100等のClassificationタスクについて、1.スクラッチで学習、2.Self-supervisionによるPre-train、3.ImageNet等の自然画像によるPre-trainによる精度と提案手法（本データセットによるPre-train）とで比較しています。
結果として、1.スクラッチで学習したモデルよりも高い精度が得られており、2.Self-supervisionによるPre-train、3.ImageNet等の自然画像によるPre-trainと比較してもタスクによっては高い精度が得られていることが示されています。
また、それぞれのデータセットでPre-trainさせた際の最初の畳込み層を可視化しており、本手法でPre-trainさせた場合、自然画像で学習したものと比較して大きく異なる特徴を捉えていることが示されています。（下図）。
<img src="/images/posts/techblog/20210812-hanamoto-fractaldb.png" alt="This is a image">(<a href="https://hirokatsukataoka16.github.io/Pretraining-without-Natural-Images/%E3%82%88%E3%82%8A%E5%BC%95%E7%94%A8%E3%80%82(c)%E5%8F%8A%E3%81%B3(d)%E3%81%8C%E6%9C%AC%E6%8F%90%E6%A1%88%E6%89%8B%E6%B3%95%E3%81%AB%E3%82%88%E3%82%8B%E3%82%82%E3%81%AE%E3%81%A7%E3%81%82%E3%82%8B%EF%BC%89">https://hirokatsukataoka16.github.io/Pretraining-without-Natural-Images/より引用。(c)及び(d)が本提案手法によるものである）</a>
<h2 id="応用可能性">応用可能性</h2>
ここから先は私個人の考えを記述します。本データセットが活用できうるタスクの1つに、異常検知タスクがあると考えています。理由としては、以下の2つが挙げられます。
<ol>
<li>提案手法で学習したCNNは、異常検知に必要と考えられる、テクスチャの特徴を抽出することに強い可能性がある</li>
<li>異常検知タスクにおけるモデルでは、Fine-tuningが不要な可能性がある</li>
</ol>
1つめに関して、<a href="https://arxiv.org/abs/1811.12231">ImageNet-trained CNNs are biased towards texture; increasing shape bias improves accuracy and robustness</a>では、ImageNetで学習したCNNが、物体の形状よりも物体のテクスチャを重要視して物体を認識する傾向があることが示されています。ここで、上で示した最初の畳込み層の可視化画像を見ると、Fractal-1K/10Kで学習した畳込み層の方が、ImageNetのものより更に物体のテクスチャを認識するように層が形成されている傾向があるように見受けられます。例えば、Fractal-1K/10Kで学習した層では市松模様のようなテクスチャに発火する層が多くあります。
人間は普通テクスチャよりも形状をヒントに物体を認識する傾向があることから、物体のテクスチャ認識の方により強いバイアスがかかることは一見デメリットのように感じられますが、異常検知タスクにおいてはテクスチャの特徴を抽出できることがメリットとなる可能性があります。例えば、LeapMindでは<a href="https://github.com/LeapMind/MLF-SC">MLF-SC</a>という異常検知手法の研究開発を行っていますが、本手法ではテクスチャの特徴を捉えていると考えられる中間層の特徴を活用することで、より高い異常検知性能を得ることに成功しています。ここで、もしFractal-1K/10Kでテクスチャの特徴をより捉えることができれば、より高い異常検知性能を得られる可能性があります。
2つめに関して、<a href="https://arxiv.org/abs/2005.14140">Modeling the Distribution of Normal Data in Pre-Trained Deep Features for Anomaly Detection</a>のような、Pre-trainモデルを用いて特徴抽出を行い、正常データの特徴分布を用いて異常検知をする手法では、正常データそのものを使ってPre-trainしたモデルや、モデルの出力に近すぎる層（domain-specificになっている層）から特徴を抽出すると、かえって異常検知性能が落ちてしまう可能性が示唆されています。これは、異常検知を行いたい対象と特徴が大きく異なるデータセットでPre-trainした方が異常検知性能が向上する可能性を示しており、人工画像であるFractal-1K/10Kを用いることでさらなる異常検知性能の向上が得られるかもしれません。
<h2 id="まとめ">まとめ</h2>
この記事では自然画像ではなく、人工的に生成したフラクタル画像からなるデータセットを紹介しました。このデータセットを用いることで、データセットの権利に係る問題を回避できるだけでなく、タスクによってはImageNetのような自然画像からなるデータセットでPre-trainした場合よりも高い精度が得られることが論文では主張されています。
また、私個人の考えでは、異常検知タスクにこのようなデータセットが有効ではないかと想定しており、実際に高い精度が得られることを期待しています。

論文紹介: Pre-training without Natural Images

バッファアロケーションをパス被覆問題として解く

こんにちは、LeapMindの徳永です。
確率分布からのサンプリング、してますか？
確率分布からのサンプリングを高速化したいこと、長い人生で、たまにはありますよね。
今回は、低次元（というか、一次元）の連続確率分布からのサンプリングの高速化にチャレンジしてみます。
<h1 id="確率分布からのサンプリングとは">確率分布からのサンプリングとは？</h1>
とりあえず、確率分布という言葉については読者はなんとなく理解しているという前提で話を進めます。
確率分布からのサンプリングとは、ある確率分布に従うサンプルを生成することです。従う、という言葉の意味については一旦見なかったことにして、とりあえず、平均0, 分散1の正規分布から1つ、サンプルを生成してみましょう。以下のスクリプトをPythonで実行してみてください。
<pre><code>import random
print(random.gauss(0, 1))
</code></pre>
手元でこのコードを実行してみると、<code>-0.2090941660155127</code>という答えが帰ってきました。しかし、この<code>-0.2090941660155127</code>という値を見ても、これが平均0, 分散1の正規分布から生成されたサンプルなのかどうかはよくわかりません。こういうものは何個もサンプルを取ってこないとわからないものなのです。
試しに、10000個のサンプルを生成して、その平均と分散を調べてみましょう。
<pre><code>import statistics
import random
 
vals = []
for i in range(0, 10000):
 vals.append(random.gauss(0, 1))
print(statistics.mean(vals), statistics.variance(vals))

</code></pre>
手元の環境で実行すると次のような結果がかえってきました。
<pre><code>-0.008574148690941068 1.003605854695149
</code></pre>
本当に正規分布に従っているのかはこれだけだとよくわかりませんが、ひとまず、平均と分散の値はそれっぽいですね。
<h1 id="様々なサンプリング手法について">様々なサンプリング手法について</h1>
サンプリングしたい確率分布がよく知られたものであれば、大抵の場合、効率的なサンプリング手法が確立されているので、それを使えば用は足ります。バグってるかどうかの確認が難しいので、可能な限り自力での実装は避けたほうが無難です。ライブラリを使いましょう。
さて、「自力での実装は避けましょう」と書いたばかりですが、今回は、既存実装の速度に不満がありますので、自力で実装してみたいと思います。どんな確率分布からのサンプリングをしているのかは業務上の秘密に当たるかもしれないので、本稿では例として正規分布からのサンプリングの高速化にトライしてみます。
実は、今回の実装では、確率分布からの厳密なサンプリングは要求されません。そこそこそれっぽく近似できていれば用は足ります。また、確率分布のパラメーターは固定した状態でなんどもサンプリングを行うので、初期化にはかなりの時間をかけても大丈夫です。1秒くらい使ってもまったく問題ありません。
ということで、「厳密じゃなくてもいい」「初期化には時間を使ってもよい」という2点を頭に入れつつ、どういう実装をするかを考えてみます。さらにもう一つ、Pythonで書かれたコードに組み込みたいので、可能であればPythonで書きたい、という制約もつきます。Pythonでループをベタ書きするとscipy等よりも遅くなる可能性が高いので、Ziggurat法みたいなループ回数が事前に決まらない方法は選択肢から外れます。
というわけで、今回は、累積分布関数を区分線形関数で近似して、逆関数法を高速化してみましょう。
<h1 id="逆関数法の区分線形関数による近似">逆関数法の区分線形関数による近似</h1>
逆関数法の詳しい説明は<a href="https://ja.wikipedia.org/wiki/%E9%80%86%E9%96%A2%E6%95%B0%E6%B3%95">Wikipediaに譲ります</a>が、ある確率分布の累積分布関数の逆関数が計算できれば、その逆関数を使って、一様分布からのサンプリング結果をある確率分布からのサンプリング結果へと変換することができます。
かなり幅広く使える手法ですが、今回の問題設定では、以下のような問題があります。
<ul>
<li>ある確率分布の累積分布関数の逆関数をどうやって求めればいいのかわからない。今回の正規分布を例に取ると、そもそも解析的に求められなさそう。</li>
<li>いい感じに近似できたとしても、それが複雑な形をしていたら、結局、高速化にはつながらない。</li>
</ul>
複雑な近似を避けて、いくつかの線分で近似しよう、というのが今回の発想です。累積分布関数を区分線形関数で近似してしまいます。こうすれば、複雑な累積分布関数の逆関数を計算する必要がなくなります。
正規分布の累積分布関数をグラフに書くと下図のようになります。
<img src="/images/posts/techblog/fig/gauss-cdf.png" alt="Cumulative distribution of Gauss distribution">
さて、この累積分布関数を、10個の区分線形関数で横方向に輪切りしてみましょう。結果が下図になります。
<img src="/images/posts/techblog/fig/gauss-cdf-piecewise-linear.png" alt="Piecewise linear approximation of cumulative distribution of Gauss distribution">
いい感じの図を描くのをサボったので輪切り感が薄いですが、横方向に輪切りにしていると思って心の目でご覧ください。本当は <a href="https://k11i.biz/blog/2016/11/05/approximate-gaussian-rng/">「一様乱数の平均値を正規乱数として代用する」という話をゆるふわ統計的に検証する - k11i.biz</a> にあるような図が描きたかった…。
さて、10個で近似してしまうと裾の部分が見た目からして明らかにヤバい感じになっておりますが、10000個くらいで近似すると、見た目ではほぼ区別がつかないようになります。
この輪切りされた領域一つ一つをビンと呼ぶことにすると、正規分布からのサンプリングの問題が、ランダムにビンを選択した後、直線のなかの1点をランダムに選ぶ、という問題になります。
これを素直に実装したのが下のコードになります。
<pre><code>import numpy as np
import scipy.stats

class FastGaussianSampler:
 def __init__(self, num_bins=8192):
 x = np.linspace(1.0e-13, 1.0 - 1e-13, num_bins + 1)
 ppf = scipy.stats.norm.ppf(x)

 lowers = ppf[0:-1]
 uppers = ppf[1:]

 self.a = lowers
 self.b = uppers - lowers
 self.num_bins = num_bins

 def generate(self, num):
 rands = np.random.randint(0, self.num_bins, size=num)
 rands2 = np.random.rand(num)
 return self.a[rands] + rands2 * self.b[rands]
</code></pre>
<h1 id="動作確認してみる">動作確認してみる</h1>
本当に正規分布らしくサンプリングできているのか、検定をしてみましょう。scipyにはシャピロ・ウィルク検定が実装されているので、標準正規分布であれば簡単に検定できます。検定してみると、手元では以下のような結果が得られました。
<pre><code>ShapiroResult(statistic=0.9980301856994629, pvalue=0.29549142718315125)
</code></pre>
P値が0.05より大きければ帰無仮説（＝正規分布からサンプリングされている）が棄却されないので、検定を通るくらいには正規分布っぽいと言ってよいでしょう。
ただ、シャピロウィルク検定の中身をしっかり理解できているわけでもないですし、これだけではすこし不安ですね。ねんのためにヒストグラムも描いてみましょう。
<img src="/images/posts/techblog/fig/fast-gauss-sampler-histogram.png" alt="fast gauss sampler histogram">
うん、よさそうです。
<h1 id="実験結果">実験結果</h1>
さて、ではお楽しみの速度比較です。どれくらい高速化されたのでしょうか。手元の環境では、65536サンプルを一気に生成してみた場合、以下のような結果になりました。単位は秒です。
<pre><code>ours: 0.0109
scipy: 0.0121
</code></pre>
うーん、10%くらいは速くなりましたね。まったく効果がないわけではありませんが、うれしい、と手放しで喜べるほどの結果でもありません。困りました。
<h1 id="gpuを使って高速化してみる">GPUを使って高速化してみる</h1>
さて、profileを取ってみると、<code>np.random.randint</code>と<code>np.random.random</code>の2つで40%ちょっとの時間を使っていることがわかりました。ここの部分は軽い乱数生成器を使えばもっと軽くできそうではありますが、もしここが10倍速くなったとしても、全体としては2倍も速くなりません。
根本的に発想を変えて、GPUを使ってみることにしましょう。今回はPyTorchを使ってみます。
コードの書き換えは機械的に行えます。<code>np.random.rand</code>を<code>torch.randint</code>に置き換えて、<code>np.random.rand</code>を<code>torch.rand</code>に置き換えれば大体できあがりです。
GPUを使う都合上、65536サンプルでは速度差がつきづらかったので、サンプル数は1048576個に増やしました。実験してみましょう。結果は以下になります。
<pre><code>ours(cpu): 0.03430
ours(gpu): 0.00142
scipy: 0.04075
</code></pre>
元のSciPyでのサンプリングと比較すると、ours(gpu)は28倍くらい速くなっています。これくらい速くなれば、速くなったと言ってもよいでしょう。CPU実装も前の実験と比較するとなんだかパフォーマンスが上がってるっぽい感じですが、これはサーバーでCPUコア数が多いことが原因だと思われます。
GPUを使っているので、パフォーマンス計測に関しては注意する必要があります。今回は、<a href="https://www.mattari-benkyo-note.com/2021/03/21/pytorch-cuda-time-measurement/">PyTorchでGPUの計算時間を正しく計測する - まったり勉強ノート</a>を参考に、<code>torch.cuda.synchronize()</code>を用いました。
<h1 id="今後の改善点">今後の改善点</h1>
今回は1つのサンプルを生成するために一様乱数を2つ使っていますが、頑張れば1つでも実装できそうです。（64bit分生成して、上位32bitと下位32bitに分ける、など。疑似乱数の性質がちゃんと保てることを検証しないといけないですが。）今回は元の3〜4倍くらい速くなれば全然ボトルネックにならなくなる（GPU側の計算がボトルネックになる）でこの結果には十分以上に満足しています（ちょっと嘘です、PyTorchのDataLoaderの中でGPUを使うコードを書くとかなり面倒なので、本当はGPUを使わずに済ませたかった。）が、もっとこだわりたいならば、高速化できる余地は残っていると言えそうです。
<h1 id="まとめ">まとめ</h1>
確率分布の累積分布関数を区分線形関数で近似することで、逆関数法をつかったサンプリングを高速化してみました。SciPyの実装と比較して、NumPyでの独自実装は10-20%程度高速化できました。また、PyTorchを使ってGPUで並列化してみたところ、元の28倍くらいの高速化を達成できました。
さて、LeapMindでは確率分布からのサンプリングを高速化したり、それとは全く関係なくいい感じのニューラルネットワークのモデル開発をエンジョイしたりするエンジニアを絶賛募集中です。我こそはと思われる方は以下のURLからどしどし応募してください。
<a href="https://leapmind.io/careers/">https://leapmind.io/careers/</a>
<a href="https://hrmos.co/pages/leapmind/jobs/0010028">今からでも間に合う！！ サマーインターンも募集中です！</a>

一次元確率分布からのサンプリングの高速化

LeapMindの<a href="https://tkng.org/">徳永</a>です。
ResNet、使ってますか？
ResNetからSkip Connectionを取り除きたくなること、長い人生で、たまにはありますよね。今日はそんな話をしたいと思います。
<h2 id="はじめに">はじめに</h2>
Residual Networkは、画像処理においてよく用いられる、代表的なネットワークの一つです。
2015年に提案されたこのネットワークは、学習のしやすさにおいて、それまでのものとは一線を画していました。
さて、そんなResidual NetworkはSkip Connection、<a href="https://arxiv.org/abs/1502.03167">Batch Normalization</a>、<a href="https://arxiv.org/abs/1502.01852">Kaiming Initialization</a>の3つの組み合わせでできた手法です。これらのどれかが欠けてしまうと、学習が遅くなったり、そもそも性能が出なくなったりしてしまいます。例えば、Skip Connectionがないと、層数が増えた場合に精度が向上しないどころか、逆に低下してしまいます。
このSkip Connectionですが、実用上は以下のような課題があります。
<ul>
<li>推論時のメモリ消費量が増える</li>
<li>推論時に計算量の割に実際の計算が重たくなりがち（特にDNN専用アクセラレーターにおいてその傾向がありがち）</li>
</ul>
このため「Skip Connectionなしで精度を出したい」という研究がいくつも試されてきました。今回は、それらの研究の中から、「Residual NetworkからSkip Connectionを取り除く」ことを主眼とした研究を中心に紹介します。DenseNetのように大きくネットワークの形が変わるものについては、今回は触れません。
<h2 id="diracnets">DiracNets</h2>
<ul>
<li><a href="https://arxiv.org/abs/1706.00388">[1706.00388] DiracNets: Training Very Deep Neural Networks Without Skip-Connections</a></li>
</ul>
Zagoruykoらは、Skip Connectionを使う代わりに、似たような挙動をする畳み込みパラメーターをデザインしました。
<div class="math math-display"><math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><semantics><mtable rowspacing="0.16em" columnspacing="1em"><mtr><mtd class="mtr-glue"></mtd><mtd><mstyle scriptlevel="0" displaystyle="true"><mrow><mi mathvariant="bold-italic">y</mi><mo>=</mo><mi mathvariant="bold-italic">x</mi><mo>+</mo><mi>σ</mi><mo stretchy="false">(</mo><mi mathvariant="bold-italic">W</mi><mo>⊙</mo><mi mathvariant="bold-italic">x</mi><mo stretchy="false">)</mo></mrow></mstyle></mtd><mtd class="mtr-glue"></mtd><mtd class="mml-eqn-num"></mtd></mtr></mtable><annotation encoding="application/x-tex">\begin{equation}
 \boldsymbol{y} = \boldsymbol{x} + \sigma (\boldsymbol{W} \odot \boldsymbol{x})
\end{equation}</annotation></semantics></math></div>
これに対して、DiracNetsでは、次式のように、畳み込みの結果に対して<math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi mathvariant="bold-italic">x</mi></mrow><annotation encoding="application/x-tex">\boldsymbol{x}</annotation></semantics></math>を足し合わせた後で非線形変換を行います。
<div class="math math-display"><math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><semantics><mtable rowspacing="0.16em" columnspacing="1em"><mtr><mtd class="mtr-glue"></mtd><mtd><mstyle scriptlevel="0" displaystyle="true"><mrow><mi mathvariant="bold-italic">y</mi><mo>=</mo><mi>σ</mi><mo fence="false" stretchy="true" minsize="1.2em" maxsize="1.2em">(</mo><mi mathvariant="bold-italic">x</mi><mo>+</mo><mi mathvariant="bold-italic">W</mi><mo>⊙</mo><mi mathvariant="bold-italic">x</mi><mo fence="false" stretchy="true" minsize="1.2em" maxsize="1.2em">)</mo></mrow></mstyle></mtd><mtd class="mtr-glue"></mtd><mtd class="mml-eqn-num"></mtd></mtr></mtable><annotation encoding="application/x-tex">\begin{equation}
 \boldsymbol{y} = \sigma\big(\boldsymbol{x} + \boldsymbol{W} \odot \boldsymbol{x}\big)
\end{equation}</annotation></semantics></math></div>
DNNにおける畳み込みは線形変換なので、これは結局、畳み込みパラメーターに対して同次元のidentity matrixを足し合わせることと等価であることがわかります。
<div class="math math-display"><math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><semantics><mtable rowspacing="0.16em" columnspacing="1em"><mtr><mtd class="mtr-glue"></mtd><mtd><mstyle scriptlevel="0" displaystyle="true"><mrow><mi mathvariant="bold-italic">y</mi><mo>=</mo><mi>σ</mi><mo fence="false" stretchy="true" minsize="1.2em" maxsize="1.2em">(</mo><mi mathvariant="bold-italic">x</mi><mo>+</mo><mi mathvariant="bold-italic">W</mi><mo>⊙</mo><mi mathvariant="bold-italic">x</mi><mo fence="false" stretchy="true" minsize="1.2em" maxsize="1.2em">)</mo><mo>=</mo><mi>σ</mi><mo fence="false" stretchy="true" minsize="1.2em" maxsize="1.2em">(</mo><mo stretchy="false">(</mo><mi mathvariant="bold-italic">I</mi><mo>+</mo><mi mathvariant="bold-italic">W</mi><mo stretchy="false">)</mo><mo>⊙</mo><mi mathvariant="bold-italic">x</mi><mo fence="false" stretchy="true" minsize="1.2em" maxsize="1.2em">)</mo></mrow></mstyle></mtd><mtd class="mtr-glue"></mtd><mtd class="mml-eqn-num"></mtd></mtr></mtable><annotation encoding="application/x-tex">\begin{equation}
 \boldsymbol{y} = \sigma\big(\boldsymbol{x} + \boldsymbol{W} \odot \boldsymbol{x}\big) = \sigma\big((\boldsymbol{I} + \boldsymbol{W}) \odot \boldsymbol{x}\big) 
\end{equation}</annotation></semantics></math></div>
つまり、畳み込みパラメーターに対してidentity matrixを足し合わせることで、Skip Connectionそのものではありませんが、似たような効果が期待できます。実際の仕組みとしては、identity matrixの部分には学習可能なscaling parameterが乗されており、もう少し複雑ではありますが、DiracNetsのお気持ちはこの式で表現されるものがほぼ全てです。
Plainな34層のネットワークでは18層のネットワークよりもむしろ精度が低下することが知られていますが、DiracNetsを用いることで、34層のネットワークの方が18層のネットワークよりも高精度になります。ただし、Skip Connectionを用いた場合と比べると、精度は幾分低下します。
<h2 id="avoiding-degradation-in-deep-feed-forward-networks-by-phasing-out-skip-connections">Avoiding degradation in deep feed-forward networks by phasing out skip-connections</h2>
<ul>
<li><a href="https://openreview.net/forum?id=BJQPG5lR-">Avoiding degradation in deep feed-forward networks by phasing out skip-connections | OpenReview</a></li>
</ul>
Montiらは、Skip Connectionありのネットワークから学習を開始し、最終的にネットワークからSkip Connectionを取り除く手法を提案しました。
具体的には、Skip Connectionの部分に(1-<math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>α</mi></mrow><annotation encoding="application/x-tex">\alpha</annotation></semantics></math>)を係数として乗じました。- <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>α</mi></mrow><annotation encoding="application/x-tex">\alpha</annotation></semantics></math>が1であればPlainCNNに、<math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>α</mi></mrow><annotation encoding="application/x-tex">\alpha</annotation></semantics></math>が0であればResNetになります。最終的には<math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>α</mi><mo>=</mo><mn>1</mn></mrow><annotation encoding="application/x-tex">\alpha=1</annotation></semantics></math>になっていてほしいので、目的関数にラグランジュ変数を導入し、<math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>L</mi><mo>+</mo><mi>λ</mi><mo stretchy="false">(</mo><mi>α</mi><mo>−</mo><mn>1</mn><mo stretchy="false">)</mo></mrow><annotation encoding="application/x-tex">L + \lambda (\alpha-1)</annotation></semantics></math>を最適化します。
残念ながら、実験結果は他の手法と適切に比較できるようになっておらず、どれくらいの効果があるのかをフェアに比較できる状態にはなっていません。
<h2 id="residual-distillation">Residual Distillation</h2>
<ul>
<li><a href="https://papers.nips.cc/paper/2020/file/657b96f0592803e25a4f07166fff289a-Paper.pdf">Residual Distillation: Towards Portable Deep Neural Networks without Shortcuts</a></li>
</ul>
Liらは、まずResNetを学習し、それを教師としてPlainCNNを学習する手法を提案しました。通常のDistillationでは最終層の類似度のみを用いますが、Residual Distillationでは、生徒ネットワークの中間層の出力を教師ネットワークの中間に入れてからbackpropして勾配を得ます。以下に特徴を箇条書きで挙げます。
<ul>
<li>LIT: Learned Intermediate Representation Training for Model Compressionと似ているが、こちらが中間層の類似度のノルムをloss functionに加えるのに対し、Residual Distillationでは、生徒ネットワークの中間データを別のネットワークに流し込むという荒業を用いています。手元での再現実験では、理由はよくわかりませんが、Residual Distillationの方が高い効果が得られました。ただ、学習はResidual Distillationの方がかなり遅くなります。</li>
<li>生徒ネットワークの初期化にはDiracNetのやり方を使います。</li>
<li>CIFAR-10/100では50層にしても性能が下がらない、程度の効果しかないが、ImageNetでは34層より50層の方が3ptくらい精度が上がります。</li>
<li>さらに通常のKDと組み合わせるともっと精度が上がります。</li>
</ul>
注目すべきは、50層のPlainCNNで76.08%のtop-1 accuracyを達成していることです。ResNet-50は76.11%なので、ほぼ同精度を達成できていると言って良いでしょう。
また、この論文は、単にSkip Connectionを取り除ける、というだけではなく、取り除くことで、最大メモリ消費量がどれくらい減るか、mobile NPUでの実行速度がどれくらい向上するのかを定量的に評価しています。（メモリ消費量は20%弱削減され、実行速度は20%〜30%程度高速になります。）隙がないですね。
Residual Distillationは50層でもResNetとほぼ変わらない性能をPlainCNNで実現できており、かなり有望な手法です。今のところ、この手法が決定版と言ってよいでしょう。
<h2 id="repvgg">RepVGG</h2>
<ul>
<li><a href="https://arxiv.org/abs/2101.03697">[2101.03697] RepVGG: Making VGG-style ConvNets Great Again</a></li>
</ul>
Dingらは、DiracNetsの考え方を発展させ、3x3convと1x1convとDiracNetsを組み合わせたRepVGGというネットワークを提案しました。肝となるアイデアは、これらが最終的に単なる1つの3x3convに置き換え可能であることです。
最終的なRepVGGネットワークは、GPU上では実行速度を基準にして同程度のモデルであれば、ResNetやEfficientNetよりも精度が高いネットワークとなっています。
手法としてはDiracNetsの発展形となっており、これでResNetからSkip Connectionをなくしたらどうなるのか、という点に興味がわきますが、残念ながら論文中にはそのような実験結果は載っていませんでした。コードは公開されているので、いつか自分で実験したみたいところです。
<h1 id="まとめ">まとめ</h1>
Skip Connectionを使わずに深いネットワークで精度を出すための研究をいくつか紹介しました。これらの手法は技術的に面白いだけではなく、ネットワーク構造がシンプルになり、ハードウェアに優しい、という利点があります。数年後には一般的に使われる技術になっているかもしれません。かもしれませんと書きましたが、個人的には、使われるようになっている可能性がかなり高いと予想しています。
ところで、LeapMindでは、Skip Connectionを使わないで高い精度を出すニューラルネットワークに興味がある方もそうでない方も、様々な職種で現在採用活動を実施しております。特に機械学習、深層学習が得意なエンジニアを強く募集しておりますので、興味がある方は<a href="https://leapmind.io/careers/">ぜひ一度LeapMindの採用ページから応募してみてください</a>。いきなり採用面接は怖い、という人はカジュアル面談から始めることもできます（もちろん、カジュアル面談の後に、実際に選考プロセスを進めない、という選択も可能です。そのためのカジュアル面談ですので。）

ResNetからSkip Connectionを取り除く研究についてのサーベイ

LeapMindでCTOをやっております、徳永と申します。（ネット上ではだいたい<a href="https://tkng.org/">tkng</a>という名前で活動しています。）弊社ではニューラルネットワークにフォーカスし、具体的には極小量子化（extremely low bit quantization、ultra low bit quantization）と呼ばれる技術を使った製品開発に取り組んでいます。昨年、その成果として、<a href="https://leapmind.io/business/ip/">Efficiera</a>という極小量子化DNN専用アクセラレーターを発売しました。これはFPGA上でも動作しますし、ASICにすることもできるIPです。
さて、すでに会社には<a href="https://leapmind.io/blog/">公式ブログが存在している</a>のですが、Markdownでサクサクと数式を入れた記事を書きたい、ということで、新しいBlogを作ってしまいました。とにかく、軽い気持ちでうっかりと更新できるような、社外に対してメッセージを発信する場所が欲しかったのです。LeapMindは、コンシューマービジネスをやっていないので、日本国内ですら、正直、あまり知名度が高くありません。とにかく、なんらかのきっかけで、LeapMindの存在を知ってもらいたい。技術的にまっとうなことを目指している会社だとわかってもらいたい。こういう気持ちが、新しくTech Blogを開設した根源にはあります。
このような目的を達成するためには、技術的にまっとうに内容がある記事を、それなりに頻繁なペースで更新することが大事だと考えています。信頼を得るためには継続が大事ですから、まずは1年間、全社員の力を借りながら、2週間に一度くらいを目標に更新していく予定です。このブログのデザインを見てもおわかりのように、他のページとデザインも融和してない、なんならまだ公式サイトのトップページからリンクも張られていないような状態ですが、徐々にデザインの改善も行いつつ、コンテンツの拡充を進めてまいります。
それではさっそく、実質的な一記事目、<a href="/blog/remove-skip-connections/">ResNetからSkip Connectionを取り除く研究についてのサーベイ</a>をお楽しみください。

LeapMind Tech Blogをはじめます

2019年 AI / 機械学習 業界別ニュース 総まとめ【マップ付】

こんにちは。<a href="https://github.com/blue-oil/blueoil">Blueoil</a> 開発チームの飯塚です。
技術評論社から発売しました「<a href="https://gihyo.jp/book/2019/978-4-297-10744-4">Practical Developers</a>」の 6 章に、弊社 CTO の徳永と共著で記事を寄稿しました。
LeapMind では、ニューラルネットワークの量子化技術に力を入れています。そしてその研究開発の成果の一部を <a href="https://github.com/blue-oil/blueoil">Blueoil</a> というオープンソースソフトウェアとして公開しています。今回寄稿した記事には、ニューラルネットの量子化技術の基礎やニューラルネットワークアクセラレータをなぜ作るのか、そして Blueoil の紹介といったことを幅広く書きました。
また、社内で利用されている深層学習向けインフラの構成についても触れています。現在オンプレミスの GPU サーバ群から Google Cloud Platform を用いた Kubernetes クラスタに学習環境を徐々に移行している最中なのですが、その次世代のインフラ構成について書いてあります。
章の後半では、弊社が共同研究をさせていただいた企業様との事例を書かせていただきました。LeapMind が社会にどのような形で価値を提供しているのか、普段社外に出ることの少ない事例についてご覧いただけます。
さて、本記事執筆時には Blueoil は v0.5.0 だったのですが、いまは <a href="https://github.com/blue-oil/blueoil/releases/tag/v0.10.0">v0.10.0</a> まで開発が進み、大幅にアップデートされています。最新の情報は Github でチェックしてみてください！
技術評論社のページ
<a href="https://gihyo.jp/book/2019/978-4-297-10744-4">https://gihyo.jp/book/2019/978-4-297-10744-4</a>
Blueoil
<a href="https://github.com/blue-oil/blueoil">https://github.com/blue-oil/blueoil</a>