AIBR プレミアム
拓海先生、最近現場で「クラウドの安いサーバーを混ぜて学習させる」と話が出ているのですが、遅いサーバーが混じると何がまずいんでしょうか。
素晴らしい着眼点ですね！分散学習では全員の仕事がそろうまで次のステップに進めない仕組みが多く、遅いサーバーがあると全体が遅くなってしまうんですよ。
なるほど。で、安いインスタンスを使うのはコストが下がるはずで、どう折り合いをつけるかが問題ということでしょうか。
その通りです。要するにトレードオフはコスト対速度です。今回の研究は、そのトレードオフを改善するために”動的バッチ”を使って各サーバーに合った仕事量を割り当てる方法を示していますよ。
これって要するに、仕事の割り振りを遅い人に合わせて減らし、速い人に増やすということですか？
そうですよ。素晴らしい着眼点ですね！具体的には各作業単位の”ミニバッチ”のサイズを動的に変え、各ワーカーの反応速度（スループット）に応じて調整します。これで全員の1周時間を揃え、待ち時間を減らすのです。
なるほど、でも現場ではサーバーの数や性能が刻々と変わります。その変化にどう対応するのですか。
大丈夫、一緒にやれば必ずできますよ。ここは制御理論の考えを借ります。比例制御（proportional control）のように、現在の遅れ具合を見て即座にバッチサイズを調整するのです。シンプルにして即応性がある方法ですよ。
現実にはGPUとCPUが混在しているのですが、両方を同時に使えるのですか。通信や精度の問題は出ませんか。
素晴らしい着眼点ですね！この手法は通信の同期方式（Bulk Synchronous Parallel、BSP）を前提に、各ワーカーの処理時間を揃えることで通信待ちを減らします。正確性（モデルの学習品質）を損なわないように、バッチ調整は安定に収束するよう設計されています。
導入コストや設定の手間はどうでしょうか。我々はExcelの数式を直すのがやっとですから、複雑なチューニングが必要だと困ります。
大丈夫、できないことはない、まだ知らないだけです。論文の提案は”ゼロ設定（zero-configuration）”を意図しており、多くのモデルでそのまま動くようTensorFlowに組み込まれています。現場では設定を最小限にして使い始められるのが強みです。
要点を3つにまとめていただけますか。会議で短く説明したいのです。
大丈夫、一緒にやれば必ずできますよ。要点は三つです。一つ、ワーカーごとにミニバッチを動的に調整して全体の待ち時間を減らすこと。二つ、CPUとGPU混在など資源の異種性（heterogeneity）を許容すること。三つ、既存のTensorFlow環境で比較的簡単に試せることです。
よく分かりました。自分の言葉で言い直すと、遅いサーバーに合わせて全員が待つのではなく、仕事量を調整して全体の作業時間を均すことで学習を速くする、ということですね。これならコストを下げつつ実用に耐えそうです。
