はじめてのにき

_ define-and-run vs define-by-run

• 前者は TF や Caffe などとされている
• 後者は Pytorch や Chainer や DyNet などとされている

https://twitter.com/taku910/status/1010082944629727234 などを見てもそうだけど、この用語法が良いかどうかは議論の余地があると思う。

define-by-run が研究時に有利なアプローチなのは間違いないという合意は形成されつつあるようにあると思う。プロダクショナイズ時の整合性の保証と、トレーニング速度の心配が define-by-run で気になることかと思う

プロダクショナイズ

define-and-run はデプロイ時に Python のランタイムが必須でなくなり、また、トレーニング時に使ったモデルが正しく使われている保証が取りやすい。ただし

• define-by-run であっても、モデルを適切にエクポートする手段があれば、問題なく Python を分離できる。最も強いエクスポートの標準化は ONNX
• define-and-run であっても、モバイルデバイスや、もっとエッジなところで動かしたい場合、例えば TF の C++ ランタイムですら邪魔なので、いずれにせよエクスポートしないといけない。 tf.Estimator の saved_model から TF lite の流れなど

トレーニング速度

原始的な define-by-run はホスト言語に処理が戻ってくるので、速度が出しにくい。ただ、最適化の余地があって

• 遅延評価する。 DyNet がこれプラス auto-batching もしてくれるらしい。というか TF の non-XLA なアクセラレータ向けコードパスはそんな感じだと思う
• モデルを一回走らせた結果を最適化して、何度も実行する。 Pytorch の jit.tracing がそれ
• 実例無いと思うけど、投機的に次の計算やるって方法もありえるんじゃないかと思っている

model-as-data vs model-as-code

そもそも、速度が出ないのなら、 Python をコンパイルしちゃえばいいという発想もありえる。これは単に Python を C なりアセンブリに変換するという話ではなくて、 Python 内で記述されたハイレベルなオペレーション群をくっつけていって、アクセラレータ内で完結した実行をしてもらう、という話

「Python をコンパイルする」て語感と実体がだいぶ違うアプローチで、感覚としては CUDA に近いものだと説明している。 CUDA だと、 __global__ てついてる関数はデバイスで実行して、ホスト側に main があってそのデバイスの関数を呼んだりする。同じような感じで、 Python の一部の matmul+activation みたいなところを Python じゃないコードでまとめて実行すれば良い

実際やってるのが Pytorch の @script や、そもそも言語まで変えてしまったのが Swift for TensorFlow 。アクセラレータに投げる部分の抽出と、計算グラフの微分をしたいので、 AST なりなんなり、言語処理系にまあまあ手を入れる必要があると思う。

このへんのアプローチは、気持ちとしては define-by-run のまんまだけど、なんか明らかに事前コンパイルしてる以上、 define-and-run の方が適切な呼び名な気がしてしまうので…… Swift for TensorFlow などは model-as-code と言ってるのだと思う

個人的には model-as-code が正しい方向性に思える

機械学習向け言語

話がそれていく。 Swift for TensorFlow みたいな方向性が正しいとして、欲しい/必要と思う機能として

• 計算グラフの分離
• 自動微分
• 静的型チェック(最低でもランク、できれば次元も含めて)
• Jupytor 的なもの
• Python の呼び出し

あたりを考えてると、 mypy と tangent で(どちらもよく知らないが)、一応 Python をコンパイルして使う、てのは要件を満たしそうな気もする

「TPU のようなもの」

もっとそれていくけど、なんか雑談してると、 XX が作ってる深層学習向けプロセッサー、みたいなことを言うと、「TPUみたいなやつ？」と聞いてくる人がいたりする。深層学習向けに独自に作る価値がある計算装置として

• 学習時に使うやつ。 TPUv2 のようなもの。たぶん、メモリが多く必要、レイテンシよりスループット重視、除算などの命令が必要、 GPU がライバル、などの特徴があると思う
• 推論時にクラウド内で使うやつ。 TPUv1 のようなもの。量子化とかして良いかもしれない。レイテンシ重視。 GPU がライバルになる場合もあるかもしれないけど、むしろ CPU で十分じゃない？的な話が多そう
• 推論時にモバイルデバイスだのもっと小さいもので使うやつ。 distilation pruning quantization あたりでメモリサイズを限界まで落としたいと思う。これは千差万別だと思うけど、行列のかけ算だけをアクセラレートします、みたいな DSP みたいなやつと、特定用途専用の FPGA/ASIC の回路にしちゃう、って話の2つがおおまかに言うとありそうかなあ

XLA あるいは NNVM

トレーニング中は数日とかかけて、何回も同じ計算をするわけで、その計算は、例えば10分とかじっくり時間をかけて最適化しても割にあう。本質的に Python のオーバヘッドからは既にほぼ無縁な TF のグラフだけど、ターゲット向けにゆっくりコンパイルしてさらに速くする方がより良いでしょ、というのが XLA 。 ONNX を入力としてわいわいやってるのが NNVM

いろいろ話はあるけど、トレーニング向けは益がそんなに大きくないのかなあ、という気はしている。けどある程度の命令数を GPU でないアクセラレータでやるのであれば、なんかしらこういうレイヤのものは必要になるだろうしな

(20:55)