前回は、言語モデルと翻訳モデルのバイナリ化に関するお話をしました。今回は、分散処理によって処理時間を減らせるかというお話です。
再び課題をまとめると
前回の繰り返しになりますが、当時の課題は実にシンプルで、次の2つに集約されていました。
- メモリの消費量が多い。
- 処理に時間がかかる。
1つめのメモリの消費量に関しては、当初の思惑とは異なる結果になってしまったものの、当面はしのげる程度に減らすことができたというのが、前回のお話でした。
2つめの処理時間ですが、当時は翻訳モデルの作成やチューニングを行なう頻度が高かったということもあり、何をするにも半日単位という印象が強く残っています。例えば、午前に処理を始めれば、終わるのは夕方になるので、その結果を使って何かするのは翌日以降になってしまいます。また、午後から処理を始めれば、終わるのは夜中になるので、翌朝にならないとその結果を確認することができません。
もし、処理時間が半分になれば、午前に始めた処理は午後の早い時間帯には終わりますし、午後に始めた処理も夕方には終わります。その日のうちに結果を確認でき、次の行動に移れるので、全体の作業日数を大幅に減らすことができるわけです。
速いPCを買ってしまえば解決かもしれませんが、そのためには投資が必要ですし、投資するなら投資対効果も考えなければいけません。それに、まずは、手持ちのものを組み合わせることで、改善を図りたいものです。
無限ループ
まずは、どういう手段があるのか、手当たり次第に調べてみました。基本的にはどうやって分散処理させるかという話で、マルチプロセス、マルチスレッド、マルチコア、GPU、OpenCL、CUDA、Hadoopという辺りがキーワードになりそうだというところまではわかりました。
これらのキーワードを組み合わせて調べているうちに、スタンフォード大学のある論文(Inclusion of large input corpora in Statistical Machine Translation)に遭遇しました。コーパスが大量になった場合、以下の3つの方法で処理時間がどのように変化していくかという内容です。
劇的な効果という意味では、GPUの利用が魅力的で、OpenCLやCUDAに関する他の文献を読む限り、軽く10倍は速くなるようなのです。でも、OpenCLやCUDAに対応したMosesは見付からないので、自分たちでMosesのソースコードを解析して、OpenCLかCUDAに対応させる必要があります。んー、ちょっとパス。。
ならば、Hadoopを使って複数台で分散処理というのが、古めの在庫PCを活用できる点でもよさそうですが、やはりHadoopに対応したMosesはないので、自分たちでMosesのソースコードを解析して、Hadoopに対応させる必要があるようです。んー、これもパス。。
となると、CPUのマルチコアの利用になるわけですが、これは既存のMosesで既に対応済みです。今は2コアのPCでMosesを稼動させているので、これを4コアとか6コアのPCにするという話になりますが、社内の在庫PCにそんな高性能なものはないので、新規に購入する必要があります。でも、いきなり投資はできませんから、我々の欲しい解決策じゃありません。
また、一般的に言われているとおり、コア数を2倍にしたから処理量が2倍に増えるわけじゃないので、そこも悩ましいところ。GPUを利用すれば、軽く10倍は速くなりそうなのに。あぁ、でも、GPUの利用はハードルが高くて、手を出せないんだった。じゃあ、Hadoopで分散処理すれば、在庫PCも活用できるけど、そうだ、これもハードルが高いんだった。。
と、完全に無限ループに陥ってしまいました。結局、何をどうすればよいのか、わからなくなってきたぞ。。
整理すると
おそらく、Mosesの処理に時間がかかるというのは、世界共通の悩みのはず。なのに、GPUやHadoopを利用できるようになっていないということは、そもそも、Mosesで行なっている処理自体が、これらの分散処理に当てはまらない類のものなのかもしれません。
というわけで、分散処理の学習からやり直しました。えらく技術的な話になるので、ここでは触れませんが、あやふやだった知識が少しずつ確かなものになり、頭が整理されてきました。結局、当時は以下のような結論を出していました。
- 既存のMosesを使うのが、最も現実的。
- PCを購入する際は、4コアCPUもしくは6コアCPUが経済的で、かつ、効果的と思われる。
- 翻訳モデル作成の処理時間は、新PCで現実的な時間まで短縮できそう。
- Mosesの処理時間は、単なるデコードは文章の場合、2,000センテンス/1時間くらいが限界ではないかと推測。
- ただし、チューニングはMosesでのデコードを10回程度繰り返すため、最も時間がかかる。新PCでも1,000センテンスで5時間超と予想。何度もチューニングするわけでなければ、許容範囲か。
実は、未だに当時のPCをそのまま使い続けています。しかも、メモリは8GBから4GBに減らして。処理時間に変化はないのですが、当時ほど翻訳モデルの作成やチューニングを頻繁に行なわなくなったことと、メモリは4GBでも問題なく動く環境を用意できたためです。メモリの消費量に関しては、いずれお話したいと思います。
次回は品詞情報を活かせるかです。
[注] この回顧録は、かつて勤めていた会社で書いた連載を復元したもので、某I社の現在の状況を反映している訳ではありません。