Bs on 射撃しつつ前転

Large Batch TrainingとCritical Batch Sizeについて

Mon, 16 Dec 2024 12:00:00 +0900

DNNの大規模学習では、大規模化に伴い、必然的にbatch sizeが上がってしまう傾向にある。しかし、batch sizeがある程度以上の規模を超えると、それ以上batch sizeを大きくしても、精度向上につながらなくなる。つまり、大量に計算機資源を投入しても、得られるリターンが（ほぼ）なくなってしまう。この臨界点をcritical batch sizeという。

以下では、いくつかの論文のお気持ちを考察しつつ、critical batch sizeの問題について考えたい。

最近のOptimizerの研究について

Thu, 12 Dec 2024 17:30:01 +0900

Optimizerはロマンである。Optimizerを変えると学習が速くなったりlossがこれまでより下がったりする。すばらしい！本記事では今年出てきた新しいOptimizerやその関連研究を眺めてみたい。

退職しました（2024年度版）

Thu, 12 Dec 2024 17:30:00 +0900

最後の記事を書いたのが2021年4月なので、3年半以上も経ってしまった。

2018年3月末から勤務していたLeapMind株式会社が2024年7月末で解散した。取締役CTOとして勤務していた当事者なので、正直、数ヶ月経ってもまだ心の整理がついていない。振り返りを色々ぐちゃぐちゃと書いてみたが、ぐちゃぐちゃの状態でインターネットにさらしてもいいことなさそうだな、と気づいたので消した。いつか公開できるところまで持っていきたい。

前に退職エントリを書いた時は、「仕事募集してます」と書いたら連絡が来過ぎて返信できなかったので、今回は仕事の募集はしない。あの時返信できなかった方、その節は申し訳ありませんでした。

このエントリはなにか一区切りつけたくて書いただけなので中身はないのだけれど、次からはしばらく、中身のある技術的なネタを書いていこうと思う。

さようならVPS、こんにちはFirebase Hosting

Mon, 05 Apr 2021 01:14:06 +0900

このブログはさくらのVPSで8年くらい運営してきたが、ちゃんとメンテナンスができてる状態ではなく、OSもUbuntu 16.04LTSで、しかも未だに32bit版である。セキュリティパッチだけはなんとかしなければ危ないので、気づいたときにパッケージのupgradeはしてきたが、あまり褒められた管理状態ではない。もはやこのVPSで動かしているのはこのweb siteだけであり、VPSを使う意義もないのだが、ここまでずるずると惰性で来てしまった。

サーバーを自分で管理するのは、今となっては重荷でしかないし、Ubuntu 16.04LTSのサポート期限もこの4月で切れるので、一念発起してFirebase Hostingに移行してみることにした。

デプロイするところまではとても簡単でなんら悩むことはなかったのだが、独自ドメインの設定だけ少しめんどくさかった。具体的には、Firebase Hostingでダッシュボード画面がどこから開けるのかが微妙にわかりづらく、15分くらい悩んだ。なんかそれっぽいところを開くとダッシュボードが開けるんだけど、左側のDashboardと書いてあるところのリンクは不正解で、正解は「デプロイの履歴」とか書いてあるあたりである。

その他、Mathjaxが機能しなくなってたのでKatexに乗り換えて、今回のメンテナンスはおしまい。さて、2021年中に、もう1回くらいは更新できるだろうか。

深層学習の極小量子化という新たなる希望

Wed, 25 Dec 2019 23:25:00 +0900

(スターウォーズのテーマをかけ、ゆっくりとスクロールしながらお読みください)

この記事は LeapMind Advent Calendar 2019 25日目の記事です。

もはや年1回の更新すら怪しくなってきたこのブログですが、今年もなんとか更新できました。来年はどうなるかな。

概要

LeapMindは極小量子化という技術にかなり注力していますが、どういうことをやっているのか、なぜそのようなことをやっているのか、CTO個人としての視点から解説します。

はじめに

LeapMindという会社の究極的な目標を端的に表現すると、機械を今よりもインテリジェントにすること、特に、データセンターにあるような計算機ではなく、身近なエッジデバイスをインテリジェントにすることです。正確なニュアンスについて知りたい方は、現在絶賛社員募集中なので、ぜひ会社見学にいらっしゃってください。

さて、このような崇高なミッションを掲げるLeapMindですが、一足飛びにミッションを達成することはできません。ミッション実現へ至る道として、現在は、ニューラルネットワークの極小量子化とその高速な実行環境の整備を中心に、いくつかの技術領域に投資を行っています。（余談1：この極小量子化という言葉は造語ですが、この分野の論文でよく使われるExtremely low bit quantizationを訳したものです。よく使われる表現としては他にUltra low bit quantizationがあり、どちらかというと後者に魅力を感じたのですが、検索ヒット数では前者の方がひと桁多く、LeapMind公式用語としては前者を採用しました。）（余談2：LeapMindは極小量子化に注力していますが、極小量子化以外はやらない、という訳ではありません。極小量子化案件以外でも、お気軽にご相談ください。）

極小量子化について

情報理論における量子化とは、連続的な量を離散的な値で近似することですが、ここでは、十分な精度で表現されていた離散的な値を、より少ないビット数、例えば8bitで表現することを指します。ニューラルネットワークの量子化というと、現在の主流は32bit浮動小数点数から8bit整数への量子化ですが、LeapMindでは重みを1bit、アクティベーションを2bitに量子化しています。8bitより小さなビット幅への量子化は急激に難易度が増すことが知られており、普通の8bit量子化と区別するため、LeapMindでは極小量子化という名前を使っています。（前述の通り、研究分野では、extremely low bitが多く見られるので、それを日本語に翻訳しました。）

極小量子化の技術的な詳細については、手前味噌ですが、ニューラルネットワークの量子化についての最近の研究の進展と、その重要性 - SmartNews Engineering Blog をご覧いただければと思います。やや古い記事ではありますが、日本語でまとまったものは、私の知る限り、2019年現在でも、この記事しか存在しません。

さて、極小量子化技術の詳細については理解して頂けたものと仮定して話を進めます。

極小量子化のメリットは色々あります。単純にメモリ消費量を下げられますし、FPGAやASIC等で実装する場合、演算回路の面積も大幅に小さくできます。結果として、電力効率の大幅な改善に結びつけることができます。LeapMindでは、電力効率の改善のために、FPGA用の極小量子化DNN専用アクセラレーターの開発に取り組んできました。現在はこのアクセラレーターの汎用性の向上に取り組んでおり、2020年前半にはASICで使えるIPとしても販売することを目指しています。

そもそも、電力効率を改善すると何がいいのでしょうか。もちろん、効率が良いものと悪いものを比べれば、効率が良いほうが嬉しいのは自明ですが、それは他になにも不都合がない場合の話です。極小量子化にはメリットしか存在しないわけではありません。課題もいくつか挙げてみましょう。

単純に量子化するだけだと精度が下がってしまう
論文で解決されているのは大きな問題だけであって、実際に効率のよいアクセラレーターを作ろうとすると、未解決の技術的な課題が色々と残っている
GPUで作ったモデルがなんでも動かせるわけではない、学習時から量子化のことを考慮する必要がある
既存のOSSに乗っかれる部分が少なく、開発コストが高い

なんだかんだで色々と課題があることがわかりますね。もっとも、未解決の技術的課題や開発コストの高さは、参入障壁にもなるので、乗り越えられるならば、実は好ましい性質の課題です。一方で、GPUで作ったモデルをそのまま何でも動かせるわけではない、という制限は、プロダクトだけで完全解決できず、顧客にある種の面倒さを強要してしまうことになり、好ましくない課題です。

では、なぜLeapMindはこのような大変そうな技術に注力しているのでしょうか。

極小量子化という困難にチャレンジする理由

そもそもの問題意識は、ニューラルネットワークは計算量が大きすぎてエッジデバイスではなかなか実用化までたどり着かない、というあたりから始まっています。特に、LeapMindが極小量子化に取り組み始めた頃は、エッジデバイスでの実用例を見つけるのは本当に難しい状態でした。

ニューラルネットワークの電力効率の改善という課題自体は、多くの人が賛同する課題でしょう。一方で、そのための解決策として極小量子化というアイディアが出てくると、この会社は大丈夫なのだろうか、という疑問が湧いてくる方も多いと思われます。実はこれがポイントで、スタートアップとしては、アイディアを聞いた10人が10人、全員が「いいね！」というようなアイディアには取り組むべきではない、と考えています。全員が賛同するようなアイディアはたぶん王道で、そのようなアイディアに注力しても、大企業にはほぼ確実に勝てません。スタートアップが大企業に勝つためには、ちょっと怪しいくらいのアイディアに取り組むべきです。

また、5年後、10年後の未来を考えると、深層学習が様々なシーンで使われているであろう未来は容易に想像できます。どんなキラーアプリケーションが使われているのかはよくわかりませんが、それを支える電力効率のよいDNNアクセラレーターが必要となることは間違いないでしょう。そのための技術として、ニューラルネットワークの極小量子化が5年後にメジャーな技術になっているのかというと、正直よくわかりません（もしかしたら、スパース化が使われていたりするかもしれないですよね）が、結局、自分の勘を信じて何かにチャレンジしなければ、道は拓けません。ある程度のリスクは仕方がないでしょう。

さて、ここまでは「極小量子化でもいい」という話で、「極小量子化がいい」という話ではありません。なぜ極小量子化を選んだのでしょうか。

なぜ極小量子化を選んだのか

隠れ層を持つニューラルネットワークでは、universal approximiation theoremという定理が成り立ちます。つまり、任意の関数を任意の精度で近似することができます。（隠れ層のニューロンの数に制限をつけない場合です。つけるとさすがに、任意の関数を任意の精度で、というわけにはいきません。）

おもしろいことに、実は、weightを量子化しても、universal approximiation theoremは成り立ちます。（[1802.03646] On the Universal Approximability and Complexity Bounds of Quantized ReLU Neural Networks）この論文では、activationは量子化していませんが、私が思うに、たぶん、activationを量子化しても、universal approximiation theoremは成り立ちます。

極小量子化したニューラルネットワークの計算は、シンプルなビットベクターの内積の計算とたまに非線形変換を繰り返すだけのものですから、結局、ビット演算とちょっとした非線形変換だけで、任意の関数を任意の精度で近似することができるのです！（ややくどいですが、この命題は未証明です。）

複雑なことをやっている世の中のプログラムの一部は、もしかすると、シンプルなビット演算だけで書き直せるのかもしれない。私は技術者として、この事実（くどいですが、「事実」とか書きましたが、未証明です。）にとてもワクワクします。このワクワクを言葉でうまく伝えるのは難しいですが、説明が難しいということは、結局、本能的な、プリミティブな喜びなのかもしれません。カレーを食べておいしいと感じる、みたいな。

まとめ

LeapMindという会社が極小量子化に取り組む理由について、自分の視点から解説してみました。最終的には言葉でうまく説明できない部分が残ってしまいましたが、ああ、とにかく、極小量子化が好きなんだな、という点にご納得いただければ幸いです。

さて、LeapMindでは現在、数多くのポジションで新規採用を実施しております。ビット演算大好き！ワクワクする！という方もそうでない方も、新卒の方も中途の方も、歓迎しております。ソフトウェアエンジニアだけではなく、ハードウェアエンジニア（特にFPGA/ASIC用のIPの開発）、ビジネスデベロップメント、セールス、全方位でメンバーを募集しております。

あまりうまく宣伝できていませんが、社員構成は国際色豊かで、メンバーの出身国は10カ国以上になります。HackDaysという取り組みを行っていたり、Education Supportで技術書を買ったりCouseraのオンラインコースが受講できたりします。ご興味のある方、ぜひご応募下さい。いきなり応募は怖いという方、私の方までメールをいただければ会社見学をアレンジすることもできます。

シリコンバレーのエンジニア給与相場が想像の倍ぐらい高かった

Fri, 12 Jan 2018 03:00:00 +0900

IM飲み会2017で、アメリカの給与相場についての話をした（もはやIMと全く関係ないが、IM開発者の人生に関係があるということで）。会社に雇われてると、こういうトピックを書くには差し障りがあったり、自慢っぽくなったりしてしまうので、タイミングよく無職である今の間に、こちらにも書いておきたい。

内容を一言に要約すると、「シリコンバレーでは、ある程度の経験を積んだソフトウェアエンジニアの年収は3000万円に容易に達しうる」ということになる。

最近、アメリカでは人工知能系のエンジニアの給料は3000万とか4000万とかが当たり前らしい、というような噂をTwitterなどで見かけるが、こういった情報は、間違ってはいないが、完全に正解であるとも言い切れない。このあたりは、日本とアメリカの報酬システムの違いを知らないと、しっかりと理解できない。

USでのエンジニアの報酬システムの概要

アメリカのテック系企業の報酬システムはどこの会社もだいたい似たようなものであって、以下のような要素で構成されるそうだ。

base salary
restricted stock unit or stock option
annual bonus

これらをまとめてtotal compensationと呼ぶ。また、この他に、転職時にsign on bonusが出たり、引っ越し手当が出たりするのも一般的らしいが、このような一時金についてはここでは触れない。

base salaryはいわゆる基本給である。restricted stock unit (RSU)やstock option (SO)は、株式（もしくは株式を購入する権利）での報酬である。 ~~このあたりは詳しくないが、上場後の企業ではRSU、未上場の企業ではSOが使われる、はず。~~ （未上場でRSUというのも珍しくないらしいので、削除。）RSUは株式を無償で受け取る権利であり、SOはある権利行使価格で株式を購入する権利である。報酬だと思って考えるとSOの存在意義が一見よくわからないが、SOには一定の制約を満たすと税金が安くなるというメリットがある。株式（っぽいもの）による報酬については、これら以外の形式での支給もあるらしいがよく知らない。そもそもRSUやSO自体、日本だとそんなに馴染みがないよね。

RSUは入社時にgrantされ、それから半年おき、1年おきなどで数年（典型的には4年）かけて少しずつvestされる。grantは「将来このタイミングでこれだけの株数をvestします」という約束であり、vestは実際の受取である。

RSUはオファーレターでは金額で提示されるが、入社後のあるタイミングで、その日の株価を使って株数に変換される。（最初から株数で提示される場合もあるらしい。というか、株数での提示のほうがメジャーかも？）その後、vestされるタイミングで株価が上がっていれば実質的な報酬はオファーレター上よりも増えるし、株価が下がっていれば実質的な報酬も減る。株価連動型の報酬になっているわけだ。

~~また、RSUは1年ごとにほぼ同額がgrantされる。つまり、入社後の収入を大雑把に書くと以下のようなイメージである。~~

~~1年目: base salary + 1/4 RSU~~
~~2年目: base salary + 1/2 RSU~~
~~3年目: base salary + 3/4 RSU~~
~~4年目: base salary + RSU~~

実際には各年のRSUの金額は同一ではないし、vestは等量ずつとも限らないので、必ずこのようになるとは限らないが、大枠としてはこんなもんだろう。

（追記）入社時のRSUの金額は2年目以降のRSUより高く設定されているのが一般的なので、2年目以降も同じ金額を期待していると裏切られる可能性が高い、とのこと。複数の情報筋から指摘があった。仮に2年目以降のRSUを1年目の半分だと仮定すると、以下のようになる。

1年目: base salary + 1/4 RSU
2年目: base salary + 3/8 RSU
3年目: base salary + 1/2 RSU
4年目: base salary + 5/8 RSU

ここでは1RSU = 1年目のRSUという単位として扱っている。

退職しました

Mon, 27 Nov 2017 12:00:00 +0900

2年と2ヶ月と少しの間勤めたスマートニュース株式会社を、少し前に退職しました。

在職中は、サムネイル画像生成サーバーの導入をしたり、Entity Linkingを実装したり、サムネイル画像の切り出しにDeep Learningを導入したりしていました。在職中には多くの方々にお世話になりました。あらためて感謝いたします。

次の職は決まってません。しばらくはお金にならなさそうなプログラムを書いて自由を満喫したいと思っていますが、無職も意外と忙しくて、なかなか時間が取れません。

とはいえ、基本的には無職は人に会う機会が少なくてでさみしいので、みなさん、遊んでやって下さい。平日でもぜんぜん大丈夫だよ！

あと、就職活動もぼちぼち始めてますので、いい仕事知ってる人、こっそり教えてください。連絡先は名字.名前@gmail.com です。

（追記）思ったよりもだいぶ多くのご連絡をいただきまして、ありがとうございます。ただ、私が何をやりたいのかを書いていなかったせいで、ミスマッチが発生しており、大変申し訳ありません。以下のような仕事に興味があります。

自然言語処理、機械学習関係のプロダクトの研究及び開発（最終的に成果をプロダクトの形にすることが重要）
海外勤務だとさらに素敵

エンジニアリングの世界では、小難しいアルゴリズムを実装するよりも、まずしっかりしたデータの整備の方が大事で、そのために正規表現でたくさんのルールを書く、みたいな作業が正解であることが多い、というかほぼ確実にそっちのルートが正解です。これまで10年ぐらい、基本的にはそうした「正解」を選択してきました。エンジニアとしては与えられた条件のもとで正解を選んできたことに誇りを持っていますが、しかし、この正解に疲れてきたというのも本音で、どこか他にも正解がないのか、他の正解がありそうな問題設定を探したい、という希望があります。

[改定新版] Emacs実践入門を読んだ

Tue, 26 Sep 2017 01:00:00 +0900

[改訂新版] Emacs実践入門を技術評論社様から御恵贈いただいたので、レビューを書きます。

2012年に出版されたEmacs実践入門が改定されて、Emacs25に対応したのが[改訂新版] Emacs実践入門です。

文章を書く時にエディタを使うべきか、プログラムを書く時にエディタを使うべきか、人によって意見は別れるところではあります。

個人的には、Emacsに慣れてしまったので、日常作業のほとんど全部をEmacsで片付けています。今この文章もEmacsで書いていますし、プログラムを書く時もだいたいEmacsで書いています。主に、モッサリしていないのが、良い。

Emacsは代表的なエディタの一つで、その割にあまり本も出版されない（実際、日本語でのEmacsについての本は、旧版のEmacs実践入門が出版されてからこの新版まで、1冊も出てないようです）ものなので、こういう本が定期的に新しい情報をまとめてくれるというのは良いことであると思います。こういう本は入門の時に一冊読めばだいたい事は足りるわけですが、でもその一冊がなかなか新しいのが出てこなかった、新しいのが出てよかったね、というのが最近の状況です。こういう入門書は版を重ねて新しい情報に追従していくのが重要ですので、改訂版が出てよかった。

Emacsの押し付けはエディハラ（エディタハラスメント）になってしまうので気をつけないといけませんが、会社や研究室に入ってきた新人には、こういう本を渡して勉強してもらうとよいでしょう。ただ、エディタの選択の自由は与えるべきだと、思います。

Emacsに話を戻すと、Emacsもこの5年で色々と変わりました。iswitchb-modeはobsoluteになったし、候補選択用のパッケージも色々でてきた（ivyとか）し、anythingよりもhelmの方がメジャーになってきたぽい雰囲気を感じます。プログラムを書くときの補完も、以前よりはだいぶインテリジェントに行える言語が増えました。パッケージ管理の普及も随分と変わったことの一つですね。おそらく、次の5年でもまた、Emacsは変化していくのでしょう。その変化を楽しみに待ちたいと思います。

ビッグデータを支える技術を読んだ

Tue, 26 Sep 2017 00:00:00 +0900

ビッグデータを支える技術を技術評論社様から御恵贈いただいたので、レビューを書きます。

個人的に、著者の西田さんとは一度お会いしたことがあります。（先方は覚えてらっしゃらないでしょうが。）いかなごの釘煮を頂いた事を今でも覚えています。

西田さんは2008年にGoogleを支える技術という本を出版され、そちらの方は私も購入して読んだ記憶があります。思えば、技評の「支える技術」シリーズはGoogleを支える技術から始まったような気がします。

ビッグデータを支える技術は、ある種、Googleを支える技術の続編といえるかもしれません。まだ当時はHadoopを中心としたデータ処理のエコシステムは完成したとは言えない状態でしたが、あれから9年が経ち、Hiveがリリースされ、Prestoがリリースされ、あの頃思い描いていたものとは少し違う気もしますが、ともかく、それなりの大規模データであっても分析できる環境がGoogleの外でも構築できるようになってきましたし、実際に色んな所で使われています。

あの頃思い描いていたのとは少し違う、という個人的な疑問は、結局分析に使うのは全部SQLライクななにかなのか、という点にあります。そういう意味では、自分の中では、Sparkの方が思い描いていたステキな分散処理のサムシングに近いのですが、SparkはSparkで、同僚が使っているところを見ると、まだまだ発展途上のソフトウェアで、結構しんどい印象があります。

話が少しずれましたが、本書に書いてある話は、一言で表現するならば「データを集めて集計するにはどうするか」だけです。それだけで283ページの本です。この本には、どういう解析をすると効果的なのかとか、どういうところに気をつけてシステムを設計すればいいのか、みたいなことは書いてません。（書いてたらたぶん3倍ぐらいにページ数が膨らんでしまうでしょう。）単に、集めて集計する、ということが、システムが大規模になるとどれだけ難しいのかということが、ここからもわかります。

もっとも、よく考えてみればだいたいの物事と言うのはそんな感じで、電池と電球をつないで電気を流すのは小学生の実験でもやりますが、それを大規模に行う発電システムと送電システムは複雑さのかたまりと言ってもいいぐらい複雑です。スケールが大きくなると、物事はだいたいなんでも話がややこしくなるものなのでしょう。本書は、カタログ的にいろんな技術の触り方について解説をしていて、それはそれでよいのです（特に、Prestoについての解説が日本語で読める本というのはたぶんこれまでなかったと思います）が、各種のソフトウェアについて深く掘り下げた別の本がない、という点を残念に思います。日本の技術書市場の広さを考えると、これからも、それぞれを深く掘り下げた本が出てくるのはなかなか難しいのかな、という気もしますが、GPUを支える技術みたいなマニアックな本まで出してしまう技評さんになら、そういう本を期待してもいいんでしょうか。

最近は深層学習ブームのせいで、うちもAIやるんや、みたいな会社が多くなってきてる印象がありますが、正直、その大半は地に足がついてません。それよりは、AIに背を向けて地道にデータ分析をしようという方が、ビジネスとしては良さそうに思います。

終わり方がよくわからなくなってきましたが、「我が社もビッグデータ分析や！」みたいなことを社長が言いだした、でもそういう分野には詳しくないんだけどどうしよう、みたいなときにはこの本を読むととても良いでしょう。データ分析は魔窟と言って良いぐらい複雑な分野なので、この1冊でオールオッケーというわけにはいきませんが、地図なしで荒野をさまようよりは、地図を持って荒野をさまよったほうが良いでしょう。生き残る確率が上がります。

SqueezeNet: AlexNet-level accuracy with 50x fewer parameters and <1MB model sizeを読んだ

Mon, 28 Mar 2016 01:31:00 +0900

SqueezeNet: AlexNet-level accuracy with 50x fewer parameters and <1MB model size を読んだメモ。

XNOR-Netが二値化ニューラルネットの性能を大きく改善する

Mon, 28 Mar 2016 01:30:00 +0900

XNOR-Net: ImageNet Classification Using Binary Convolutional Neural Networks が出てきた。Abstractを読むと、「This results in 58x faster convolutional operations」とか「XNOR-Nets offer the possibility of running state-of-the-art networks on CPUs (rather than GPUs) in real-time」とか、ワクワクするようなことが書いてある。というわけで中身もザッと読んでみた。

なぜcuDNNのConvolutionは高速なのか

Sun, 06 Mar 2016 03:24:00 +0900

cuDNNはNVIDIAが公開しているDeep Learning用のライブラリである。このライブラリを使うとCaffeやChainerなどのDeep Learning用のソフトウェアの速度が向上する。この速度向上に寄与している最も大きな部分がConvolutionの高速化である。

個人的には、CPUでどこまで高速にConvolutionが実現できるのかに興味がある。本記事は、その準備段階として、どういう高速化戦略がありえるのかを調べたものである。

BinaryNetとBinarized Deep Neural Network

Fri, 12 Feb 2016 22:50:00 +0900

BinaryNet が最近話題になっている。ニューラルネットワークの二値化については前から興味があったので読んでみた。

ニューラルネットを高速化する手段としてのスパース化

Fri, 12 Feb 2016 22:50:00 +0900

近年の大規模ニューラルネットワークを用いたシステムの運用には、GPUがほぼ必須であると考えられている。

しかし、プロダクションシステムがAWSなどのクラウド上に置かれている場合、GPUを使ったニューラルネットワークは使いづらい。AWS EC2のGPUインスタンスは高額だし、AzureやGCEは今のところGPUインスタンスを提供していない。という訳で、学習時にはGPUを使っても構わないのだが、テスト時にはCPUでもそこそこ高速に動いてくれるネットワークが構築できると嬉しい。

最近のニューラルネットワークの計算が重たいのは、2D Convolutionの計算量がとても大きいからである。高速に動かすためには、とにかく計算量を減らさないといけない。

考えられる方向は3つ存在する。1つ目がConvolution自体の高速化、2つ目が計算の低精度化、３つ目がスパース化である。

Convolution自体の高速化については、今のところの最速はWinograd Algorithmである。Winogradを使ったConvolutionのCPU実装にはnnpackが存在する。しかし、この方向は、極めても現状の数倍程度の高速化にしかならないようである。もう少し速くしたい。あと、strideのサポートに制限があったり（論文の計算式を見てもstrideのサポートは難しそうな雰囲気に見える）とか、実用上はちょっとやっかいな所がある。

（余談だが、Winograd Algorithmの二次元への拡張、論文だと「ネストするとこんな感じ」でいきなり計算式が出てくるのだが、導出がまったく理解できない。どなたか知ってたら教えて下さい。）

2つ目、計算の低精度化については、CPUで計算する場合は、2値化、3値化ぐらいにまで極端な低精度化をしないと、メリットが薄い。そして、そこまで極端に低精度にしてしまうと、現状では精度が犠牲になってしまう。その割にはAVX命令を使った場合と比べてせいぜい数倍程度の高速化にしかならない。FPGAやASICを使って自分で回路を組めるなら効果は劇的だが、CPUの場合はそこまで華々しい効果は得られない。

3つ目、今回のテーマのスパース化は、値が0の部分の計算を省略できるので、高速化につながる可能性がある。ニューラルネットワークには膨大なパラメーターが存在するが、そのすべてが本当に必要なのかというと疑わしい。実際、重み行列のほとんどを0にしてしまっても、ニューラルネットワークはうまく動作するのである。

Learning both Weights and Connections for Efficient Neural Networks

Hanらは、以下の様な手法で学習したニューラルネットは、スパースであり、かつ精度もほとんど落ちない（それどころか、場合によっては精度が多少向上する）ことを実験的に示した。

普通にニューラルネットを学習する。この際に、L1正則化もしくはL2正則化を行う
パラメーターのうち、しきい値以下のものを削除する
削除してスパース化されたネットワークで再学習を行う

3.のステップがないと、精度はかなり低下するそうである。また、いきなり極端にスパース化してしまうより、1〜3を繰り返して徐々にスパース化した方が、精度はよくなる。ただし学習にかかる時間は伸びる。

LeNet, Alexnet, VGGNetについて実験を行い、パラメーター数は概ね1/10程度に削減できることを示した。ただ、計算量も1/10まで減らせるかというとそうではなく、最初の方のConvolutionはあまりスパースにできない（論文中にはレイヤーごとにスパース化した場合の精度低下を表すグラフがあるが、前段の方はスパース化による精度低下が激しい）ので、高速化としては3〜5倍程度の効果になるようだ。

Winograd Algorithmとスパース化の組み合わせ

らはWinogradやFFTを使った場合のConvolutionのスパース化の組み合わせを実験している。この結果によると、Winograd Algorithとスパース化は問題なく組み合わせられるようである。WinogradでConvolutionが2倍ぐらいに高速化できるとして、スパース化と組み合わせると、6〜10倍程度の高速化が実現できるわけだ。

http://cs231n.stanford.edu/reports2016/117_Report.pdf

なぜNVIDIAがスパース化を研究するのか？

Hanらのスパース化の論文は、著者の半分がNVIDIAに所属している。GPUではスパース化は効果が薄い。Intelがこの論文を出すなら納得できるのだが、NVIDIAがこういうものに関わるのはちょっと不思議に感じられる。

この謎は、同グループによる次の論文で解けた。内容は、スパース化を含む様々な工夫を凝らしたハードウェア実装である。通常のCPU実装と比べて189倍、GPU実装と比べて13倍高速で、電力効率もGPUと比べて数千倍以上が達成できたとしている。これだけ効率化が進めば、モバイルデバイスに載せるのも現実的と言えそうだ。NVIDIAは車載向けを本気で狙ってるっぽいし、次のTegraか次の次のTegraぐらいには、このような機能が実装されていたとしてもおかしくない。

[1602.01528] EIE: Efficient Inference Engine on Compressed Deep Neural Network

SqueezeNetを読み返す

SqueezeNetはニューラルネットワークのサイズ削減のための有望な手段である。改めてSqueezeNetの論文を読み返してみると、Hanらのスパース化のアイディアや、ResNetにインスパイアされたバイパスの導入など、多くの工夫を組み込むことで、最終的にはモデルサイズを通常の1/500程度にまで削減することに成功している。Squeezeによる計算量の削減は、論文から読み取れる設定（1/4にsqueezeして、同数の1x1と3x3でexpandする）で計算すると13.5倍の高速化になる。

やや余談だが、この論文、4月に出ている第3版でページ数が9ページに増えていて、Sensitivity Analysisとか、いくつか情報が増えている。その中に、Densifying Sparse Modelsという項目が増えているのだが、これがシンプルな割に劇的に効くようである。

普通にスパース化する。つまり、小さな値のパラメーターを削除して再学習、を繰り返す。
1で削除したパラメーターを復活させる。この際、復活したパラメーターは0に初期化する。
再学習をかける。

これだけで、ImageNetのtop1-accuracyが4%も向上したと報告している。ということは、オリジナルのAlexNetよりも4%も精度が高いということである。これはかなり驚くべき話である。

SqueezeNet + ResNet

らは、SqueezeNetにResNetを組み合わせるアイデアをさらに推し進めた実験を行っている。オリジナルのSqueezeNetと比べ、ResNet化によって、Tiny ImageNetの分類精度が、top-1 accuracyで44ptから58ptと、大幅に向上した。また、彼らの実験設定では、Batch Normalizationを使っているのだが、そこにDropoutを組み合わせることで、オーバーフィットを大きく軽減することができたと述べている。

http://cs231n.stanford.edu/reports2016/410_Report.pdf

積み重ねるとどうなるか

Winogradとスパース化の組み合わせを効率的に実装するのは大変なのであきらめるとして、WinogradとSqueezeNet、もしくはスパース化とSqueezeNetを組み合わせることで、27倍〜39倍程度の高速化が期待できる。これぐらい高速化できれば、CPU実装でもそれなりに使い物になるだろう。

参考文献

[1506.02626] Learning both Weights and Connections for Efficient Neural Networks

Installation procedure of Chainer 1.6 on Ubuntu 14.04

Sun, 31 Jan 2016 05:35:31 +0900

It is sometimes time consuming task to install Chainer, because installing Cuda has some caveats. Therefore I write my own install log of Chainer with Cuda.

JustTechTalk#2で形態素解析の話を聞いてきた

Mon, 03 Aug 2015 00:00:00 +0000

ちょっと前の話になるが、形態素解析のあれやこれや@ジャストシステムで、ジャストシステムの形態素解析器JMATの学習の方法についての話を聞いてきた。2000年台後半の話だそうなので、今は変わってるところもあるかも。

Bayesian Optimizationに関するメモ

Fri, 31 Jul 2015 23:34:35 +0900

先日のNL研で@issei_satoさんのBayesian Optimizationの講演を聞いてきたので、自分なりにメモをまとめておく。

Kodi（旧XBMC）でUSBスピーカーをAirplayスピーカー化する

Wed, 08 Apr 2015 00:00:00 +0000

ちゃんとしたスピーカーで音楽を聴きたいのだが、パソコンとスピーカーをケーブルで接続するのは面倒だ。無線で音を鳴らせないものか。

hugoに移行した

Wed, 01 Apr 2015 00:00:00 +0000

ふとGoogle PageSpeedで自分のサイトをチェックしてみると、Google Analyticsのコードが古くなっていたりと、問題がいくつかあることがわかった。

このブログはこれまでOctopressというツールで構築していたのだが、Octopressはページ生成のrake newコマンドの仕様とか、挙動が全体的にもっさりいるところなどに違和感があったので、これを機にHugoというツールに移行してみた。

もっさりしたYosemiteの日本語入力を高速化する

Tue, 31 Mar 2015 00:00:00 +0000

いつ頃からか、Macbook Proでの日本語入力がもっさりするようになってしまっていた。Mavericksの頃にどうだったのかよく覚えていないのだが、テキストエディットやらTerminalやら、とにかくなにで入力をしていても、とてつもなく動作が重い。

Let's Encryptとはなにか？

Wed, 07 Jan 2015 00:00:00 +0000

Let’s Encryptのプレスリリースが出てきた時、なにがなんだかよくわからなかった。年末年始にちょっと調べてみたので、簡単にまとめておく。

近年、インターネットにおいて、通信をエンドツーエンドでできるだけ暗号化しようという動きが始まっている。これは、セキュリティやプライバシーのことを考えてのことであり、望ましいものである。

2014年を振り返って

Sun, 04 Jan 2015 00:00:00 +0000

あけましておめでとうございます。お久しぶりです。

最近の仮想化界隈を知る：VMWareからCoreOSまで

Sun, 17 Nov 2013 00:00:00 +0000

　仮想化の分野はどんどんと新しいものが出てくる。全部を実際に試すことは出来なくても、筋が良さそうなものについては、どういうものなのかある程度把握しておきたい。最近はちょっと忙しくてあまり情報収集ができてなかったので、追いつこうと思ってちょっと調べてみた。

週刊少年ジャンプの連載作品名からGoogleのアダルト語判定アルゴリズムの挙動を推測する

Sat, 07 Sep 2013 00:00:00 +0000

　Googleはアダルトであると判定された検索文字列に対し、サジェストを表示しないらしい。その事実はなんとなく知っていたのだが、先日「セクシーコマンドー外伝すごいよマサルさん」に対してサジェストが一切行われない事に気づき、どういう挙動をしているのかと興味を持った。

"データサイエンティスト"に対する違和感

Sat, 31 Aug 2013 00:00:00 +0000

データサイエンティストという言葉に違和感がある。

今働いている会社的には、データサイエンティストという言葉は、微妙な言葉である。乗っかるべきなのかどうなのか迷うというか、いい言葉になるのかどうか、見通しがつかないというか。

おいしいカレーが食べられる店を思いつくままに挙げてみる

Sun, 11 Aug 2013 00:00:00 +0000

自分が再訪したいと思っている、もしくは再訪したことのある店だけを挙げてみた。

Stochastic Average Gradient法を解説する

Mon, 27 May 2013 00:00:00 +0000

　Stochastic Average Gradient (SAG)はNIPS 2012で提案された新しい最適化手法である。目的関数がstrongly convexである場合、という条件付きではあるが、線形収束が保証されている。要するに、速い。

A Stochastic Gradient Method with an Exponential Convergence Rate for Finite Training Sets

　論文の解説についてはOiwa神の記事を参照すると良いと思う。以下では、SAGの考え方について、一般的なSGDとの差異を中心に説明したい。

データ解析あるある

Sun, 26 May 2013 00:00:00 +0000

NIPS2013（たぶん）会場情報

Tue, 05 Feb 2013 00:00:00 +0000

　12/3～12/8に開催されたNIPS (Neural Information Processing Systems) 2012に参加してきた。NIPSは機械学習系だとICMLなどと並んでトップ会議のひとつである（はず）。

　会議の内容については会社ブログのほうでまとめたので、こちらでは裏話的というか、どういう場所だったかということを書いておきたい。今年からしばらくの間（少なくとも2014年までは）は同じ場所で開催されるっぽいので、2013年以降に参加する人の参考になると嬉しい。

ブログを移転するよ

Sun, 03 Feb 2013 00:00:00 +0000

　2005年ぐらいから、はてなダイアリーというサービスで、射撃しつつ前転というブログを書いてきた。それなりにブックマークを集めたりもしたのだが、最近は更新回数も減ってきている。忙しいと更新できなくなってしまう。