DNN推論用ライブラリ「Menoh」リリースについて

Shintarou Okada
エンジニア

2018-06-21 11:41:46

Python以外も使いたくないですか?  特にDeepLearning界隈で.

Menoh開発者の岡田です.この記事ではMenohの紹介と開発に至った動機について説明します.

Menohのレポジトリ: https://github.com/pfnet-research/menoh

Menoh(メノウ)は学習済みのDNNモデルをONNX形式から読み込んで動作させる推論専用のライブラリです.実装はC++で書きましたが,C言語のインターフェースを持たせて,他の言語用からもその機能を呼び出しやすくしてあります.リリース時点でC++版ラッパーとC#版ラッパー,Haskell版ラッパーがあり,Ruby版ラッパーとNodeJS版ラッパー,Java(JVM)版ラッパーが開発中です.バックエンドにはIntelの開発しているMKL-DNNを採用し,GPUが無くてもIntel CPUが使える環境で高速にモデルの推論が可能になっています.Menohを使えばChainerで学習したモデルをPython以外の言語で実装したアプリケーションに瞬時にデプロイすることが可能です.

ところでなぜDeepLearning界隈で覇権を握ったのがPythonであって,Rubyじゃなかったんでしょう? Rは? Perlは? C++は? プログラミング言語は数多くありますが,どの言語も今のPythonのように広くDL用学習フレームワークを記述するために利用される可能性はありました(もちろん言語ごとに用途の向き不向きがあって,可能性の大小はあったにせよ).我々の宇宙ではPythonが覇権を握りましたが,どこか別の宇宙ではLispが覇権を握ることもきっとあったでしょう.とは言え,我々は我々の宇宙に生きるしかなく,今日そのディープなんとかを実装するには甘美な()や{}やbeginendから離れて空虚なインデントでブロックを記述する必要があります.このことについて,なんと悲しいことかと手放しに言い切れれば良かったんですが,皆さんご存知の通り,Pythonは良い言語です.

そう,Pythonは良い言語です.豊富なライブラリ,特にNumpyが使えること,動的型付けであること,GC機能が搭載されていること――どれもがDNNを実装したり学習させたりするコードを試行錯誤しながら書くという作業をやりやすくしてくれます.もちろんChainerはPythonで記述されており,改造・拡張しやすいDNN学習フレームワークとなっています.ChainerはそのDefine-by-Runという魔法によってすばらしく使いやすい.このDefine-by-Runをもっと別の言語で実装することも出来たと思いますが,コードはより複雑に,その作業はもっと苦痛の伴うものになっていたでしょう.明らかにChainerの使い勝手の良さの一端はPythonという言語そのものが担っています.

我々にとって,DNNについて研究する作業というのは地獄ではありません.Pythonの使い勝手の良さに裏打ちされたChainerがあるからです.手軽にDNNモデルを記述して学習を回せる.素晴らしいことです.地獄なのは学習したDNNモデルをデプロイする作業です.

地獄というのは言いすぎかもしれません.Pythonがデプロイ先の環境で使えるならChainerをそのまま使えばよく,首尾貫徹して苦痛はどこにも(少なくともデプロイ作業には)ありません.でもPythonが使えない環境はどうでしょうか.研究室の外に出ると,セキュリティや計算資源的な問題などでPythonが使えない環境や,分野によっては別の言語が覇権を握っていてPythonではそこにある資産を利用できない状況というのは山ほどあります(例えば,Web界隈では今でもRubyに根強い人気があります).現在でもDLフレームワークの中には設計がデプロイまで意識されたものや,Pythonを使わずにCやC++などでDNNを記述できるものもありますが,大掛かりだったり,あまりに実装が剥き身すぎて使いづらかったりします.現状はDNNの学習については広く知見が行き渡っているのと比べて,まだまだDNNのデプロイについては発展途上であると言えます.

ただ学習したモデルを自分のアプリケーションに組み込みたいだけなのにそれがなかなか難しい.

以上が私がMenohの開発を始めた動機です.

MenohはPFNが社内で定められた20%ルールの下でのプロジェクトの成果です.20%ルールとは「PFNメンバーは公式にアサインされたタスクとは別に20%の時間を各自の好きなタスクやプロジェクトに充てても良い」というもので,Menohプロジェクト以外にも様々な個人やチームのプロジェクトや勉強会が進行しています.

MenohはChainer Advent Calendar 2017で開発した「Instant」というライブラリが元になっています.20%の時間を使って,Instantの機能を拡充していく中で,設計の助言をしてくれたり,他の言語のラッパーを書いてくれたりするメンバーが現れて,そうした自発的に協力してくれたメンバー達のお陰でInstantはMenohに名前を変えて実験的なプロダクトとしてpfn-researchにてリリースするに至りました.これからも20%の時間を使って開発は継続していく予定なので,ぜひ利用してもらって,バグや要望等あればどんどんIssueに投げていただければと思います.

Go言語でのCI環境構築

kashihara
エンジニア

2015-12-01 10:55:56

PFNの柏原です。Go言語製のソフトウェアのCI(Continuous Integration, 継続的インテグレーション)環境の構築方法(導入方法)について解説します。想定としてはgithub上にホストしているOSSプロジェクトのソースツリーをCIの対象とします。OSSのpublicリポジトリなため、無料で使えるサービスを利用対象とします。

紹介する各CIサービスすべてでGo言語を扱えますが、まず最初にサービスを利用する上で各サービスについて結論から述べます。その後、各CI環境(OS、Goバージョン)、設定ファイルの例を説明します。

今回はTravis CICircleCICodeshipAppVeyor の4つのサービスを紹介します。

結論から

結論から書きますと、Linux, OS X, Windowsの各種OSプラットフォームで同時にCIを動かしたいなら、Travis CI(Linux, OS X), CircleCI(Linux), AppVeyor(Windows)のような構成で利用するとよいでしょう。Travis CIはMulti-OS Featureがあるため、1つの設定ファイルでLinuxとOS XでCIを同時に実行できそうです。

Travis CIとCircleCIはどちらも同じくらい設定は簡単そうに見えます。Travis CIのほうが老舗でCircleCIは設定記述がモダンな印象があります(CircleCIの公開日を調べていませんが…)。CircleCIは所々モダンさを感じるところですが(設定記述の省力化)、かえって設定が省略されすぎており、また、ドキュメントから設定方法が探しづらい面もあります。その点のバランス加減は、採用者の好みがわかれるところでしょう。また、Travis CIはsudoコマンドが扱えるため、追加のバイナリパッケージをインストールできたりするのが便利かもしれません。ここはTravis CIがVMとコンテナ型の両方の形式をサポートしている強みです。
Codeshipはビルドログが非公開な点がOSSには向いてなさそうです。また、使い方・環境情報のようなドキュメントが他サービスと比べて少なく、比較したり調べづらいです。具体的にはCIの実行環境情報が少ないのが難しいところです。

Windowsも使うならAppVeyorがあります。必要そうなソフトウェアはおおよそ揃っているように見えます(Installed Software)。実行環境は64ビットCPU(x64)ですが32ビットバイナリも提供されています。他サービスとの細かい比較はしていませんが、必要十分な機能が揃っていると感じました。

特徴としてはTravis CIはVMベース/コンテナ型の両方を採用してるようです。CircleCIはコンテナ型、CodeshipはDockerらしい記述がドキュメントから見つかります。AppVeyorは特に見ていませんが、WindowsなのでVMベースみたいですね。

各サービスいずれも、ビルド結果の通知にはE-Mailやチャット(Slack、HipChat)などに対応しているようです。

Goリポジトリのサンプル

設定ファイルは後に貼り付けますが、リポジトリ及びバッジ(ビルドステータス)などを確認したい場合は以下のリポジトリを参照してください。わざとテストが失敗するようなコードを書いています。