關於ELF OpenGo一些問題的回復

來自專欄 遠東軼事

最近網上很多討論我們剛發布的ELF OpenGo的熱帖，沒有時間一一回復了。我把一些問題統一起來在這裡回復一下。

首先非常感謝LeelaZero團隊以最快的速度把我們的權重轉成了LeelaZero可以用的格式，這樣大家可以在第一時間看到我們這個AI的水平，並且能親手驗證。這個充分說明了我們的工作是可重複的，並且可以造福大家。我們感到非常高興。

大家可能會覺得這個版本在較少搜索次數（rollouts），比如說每步800或者1600的時候效果沒有那麼好。這個是因為我們在蒙特卡羅搜索（MCTS）裡面用了batching，比如說每8次或者16次搜索（rollout）放一起送給神經網路，這樣GPU的效率會高很多。內部測過加和不加batching，在同樣搜索次數下，可能要差幾倍的速度。但是副作用就是會影響棋力。這個是因為MCTS本來就是個串列演算法，理想情況下應該是每一步新的搜索都依賴之前所有搜索的勝率估計；現在每8次或者16次搜索統一處理，那就不是理想情況了。這個問題在較少搜索次數時尤為嚴重，因為每一次搜索都尤其寶貴。解決的辦法當然是減少batch的大小，像800或者1.6k這樣的，batchsize選4會比較好（對應的開關是--mcts_rollout_per_batch 和 --batchsize），但是這樣速度確實會慢一點。batchsize選16隻適合於總搜索次數多（比如說每步80k）的情況，當然更大的batchsize就沒有什麼好處了。

接下來大家可能會問在自對弈的時候這個要怎麼辦。自對弈的時候每步只有1.6k的搜索次數，不batch速度慢，batch了棋力變差，兩難啊。這裡就要提到ELF的好處了。我們自對弈的時候是每個GPU上同時跑32個棋局，開32個獨立的MCTS搜索，然後總的batchsize是128。每個棋局上完全沒有batch，就把當前搜索的單個局面送給ELF，讓ELF去動態batch不同棋局的局面，然後綁一起送給神經網路，這樣就兼顧了效率和棋力。在這種設置下，batchsize不再是個常數，基本上平均batchsize在90左右，已經是很好的了。當然副作用是一開始自對弈會出來得慢些。

英文版見：Answer some questions about batchsize. · Issue #25 · pytorch/ELF

推薦閱讀：