TensorFlow Paper 感想

当方機械学習素人につき大して興味はなかったものの、実は Jeff Dean 案件だと気付き whitepaper くらいは読むことにした。

ぎもん: Jeff Dean といえば MapReduce や GFS を作った Google の神話級プログラマ。そんな分散インフラの達人がなぜまた深層学習に手を出したのだろう。

わかったこと: TensorFlow は、行列(というかテンソル)に特化したデータフロー・プログラミングの分散実行処理系だった。

データフロー・プログラミングとは、データを受け取り何か計算して結果を誰かに渡す、という単位のオブジェクト(ノード、カーネルなどと呼ぶ)をつなぎ合わせてグラフをつくり、より大きな計算を表現する抽象化のパターン。最近はリアクティブの文脈で目にすることが増えた。

そして MapReduce/Hadoop も今はデータフローの枠組みでコードを書くことが多い。Flume(Cloud Dataflow)とか Scalding とか。要するに既存の分散計算技術もいつの間にかデータフローの処理系みたいになっていた。Spark も似たようなものという理解。

TensorFlow は深層学習に特化したデータフローの処理系を分散環境で動かす試みと言える。 分散、データフロー、処理系、というあたりに MapReduce と通じるものがある。そして扱う計算の種類が全然違うから従来の MapReduce インフラは使い回せない。新しく作る口実はある。Jeff Dean 案件として腑に落ちてきた、でしょ？

何が違うのか。まず巨大な行列の掛け算とかは CPU intensive. CPU のみならず GPU もあればあるだけ使いたい。扱うデータはオンメモリ。何かとファイルに書きたがる IO 主体の MapReduce 族とは違う。

データをファイルに書かないため耐故障性は低め。失敗したら全部やりなおしが基本で、それが嫌なら節目で明示的にデータを保存する。Variable node という仕組みがそのチェックポイント業を助ける。

メモリ上のデータを受け渡す以上、グラフ上で隣接するノードはなるべく同一プロセス内に詰め込みたい。だから基本はプロセスの中で計算し、はみ出す部分を別プロセスや別マシンに追い出すデザインぽい。基本単位がプロセス、最適化としてマルチスレッドや資源の局所性を扱う MapReduce とは対照的。

そのプロセス内演算はなるはやで仕事を済ますべくうまいこと計算を並列化し CPU や GPU を使い切る責務がある。だから MapReduce/Hadoop では Borg/YARN まかせだったスケジューラをプロセス内部用に自分で持たないといけない。ここも違う。

MapReduce は、データフローのノードがやる計算(つまり map と reduce)をエンドユーザたるプログラマが書く。TensorFlow だとノードというかカーネルは基本的に用意されたものを使う。行列演算みたいに専門家がチューニングするカーネルが大半だから。

逆に言うと、TensorFlow は MapReduce みたいにプログラマが書いたバイナリをクラスタに撒く必要がない。プログラマはグラフの形を指定するだけ。あとは TensorFlow クラスタがよろしくやる。これは SQL を実行するだけの Dremel にある意味近いと言えなくもない。バイナリを作らなくて済むのはちょっといいね。Python 版の意味がありそう。

あるベンチマークによると、単一マシン上でのTensorFlow は既存の深層学習ツールより遅いらしい。これはリリースから日が浅いせいかもしれないし、世間のツールの方が良く出来てるだけの話かもしれない。でも分散化、スケールアウトのためのオーバーヘッドが足を引っ張っている可能性もあろう。このトレードオフが割に合うものなのか、それとも深層学習は高くて速いマシンを回すほうがいいのか。素人過ぎてまったく見当もつかない。でも Jeff Dean ファンとして TensorFlow を応援したい。分散パートもはやくオープンソースにしないかな。

分散はさておき、GPGPU のプログラミングモデルとして TensorFlow 的なデータフロー処理系は悪くない気がする。以前 OpenCL の API を見たとき、これでちゃんと速いものを書くのは大変そうだと辛い気持ちになった。でもスケジューラをアプリのレイヤと切り離せれば手に負えるかもしれない。といっても自分でそんなのを作るのはだいぶ無理そう。GPGPU フレームワークとしての TensorFlow にもちょっとだけ期待。やる気あるのかしらんけど。