ELF OpenGo发布，据说比leelazero还强

lu01

这份档案包含了2018年4月与四位KBA相关专业人员一起参加的14场比赛中的12场比赛（见本文）。 ELF OpenGo通过辞职赢得了所有比赛。  我们尊重玩家不要发布其中两款游戏的要求，并且我们也对游戏进行了匿名处理。 每个玩家至少在这个档案中包含两个游戏。  前两场比赛是使用ELF OpenGo模型权重较弱的预发布版本进行的。 对于每一次移动，ELF OpenGo都使用2个线程，每个线程10000次展开（分为4个批次）。  所有其他游戏都使用v0 pretrained模型（公开可供下载）播放。 对于每一次移动，ELF OpenGo使用2个线程，每个线程有40000个卷展栏（分为16个批次）。 这在V100 GPU上每移动大约需要50秒。  对于所有的游戏，没有对人类思维时间施加约束。  没有与此版本相关的源代码。

lu01

lu01

gcp转化的elf权重
http://zero.sjeng.org/networks/6 ... d02c9852097df4b9.gz

修改后的leelaz能使用上述权重
https://github.com/gcp/leela-zero/files/1972910/leelaz_elf.zip

lu01

elf vs leelaz 的998局
https://github.com/pytorch/ELF/r ... 9-2018-05-03.tar.gz

lu01

也有征子问题

yuandong-tian评论4小时前•

@croosn是的。我们有梯子的问题，但只要机器人发挥了第一个不好的举动，它会意识到并且不会被困住（尽管估计值会大大下降）。非常强大的机器人可能会利用这种弱点并赢得比赛，但似乎人类还不能。

有趣的是，在培训期间，我们发现阶梯问题的几个阶段，展示机器人如何学习它。

添加手动梯形检查（已经存在于旧的DarkForest代码中）将违反我们最初的动机：重新实现AlphaGoZero / AlphaZero，这意味着应用于游戏的零人类知识。所以我们只保留没有它的训练。

我们不打算构建最强大的机器人，而是探索AGZ / AZ算法的优缺点。这种算法似乎非常普遍，但可能存在DeepMind在本文中未提及的自己的问题。作为科学家，我们有责任找出问题并系统性地解决问题（使用更好的算法），而不是用短期的努力来解决问题。

lu01

Opengo权重测试（内有福利）        只看楼主[url=]收藏[/url]回复   
                                                                 
               
            

•                                                                                         
  
•                                         姜_锴
•                                             一瞥千着
  9
                      
  
  

                                                            
            
                                    测试双方：
黑方：Opengov0 pretrained（20B224F）
白方：Leelazero18e6(15B192F)
贴目：7.5
用时：每步30秒
硬件：1060 3G
引擎：Leelaz引擎


测试情况：
因为用的都是Leelaz引擎，所以并没有Opengo原来对于N卡的优化效果。同时间的输出，20B224F的Opengo大约是15B192F的Leelaz的70%。
本局Opengo表现出厚重的棋风，先为不可胜，待敌有可乘之机，则雷霆一击，然后获些小利就毅然收手，绝不勉强攻击，牢牢把控局面，最后积少成多。
而Leelaz超爱耍大龙，每每逢凶化吉、起死回生，让人看得心惊肉跳，又大呼过瘾。总的来说，Opengo确实更胜一筹。

lu01

一个能读取elf权重的修改版客户端
leela_lizzie_elf
C:\leela_lizzie_elf>leelaz -w elf_converted_weights.txt
Using 2 thread(s).
RNG seed: 6481656193536936341
Leela Zero 0.13  Copyright (C) 2017-2018  Gian-Carlo Pascutto and contributors
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; see the COPYING file for details.

Detecting residual layers...v2...224 channels...20 blocks.
Initializing OpenCL.
Detected 1 OpenCL platforms.
Platform version: OpenCL 1.2 CUDA 8.0.0
Platform profile: FULL_PROFILE
Platform name:    NVIDIA CUDA
Platform vendor:  NVIDIA Corporation
Device ID:     0
Device name:   GeForce GT 730
Device type:   GPU
Device vendor: NVIDIA Corporation
Device driver: 376.62
Device speed:  901 MHz
Device cores:  2 CU
Device score:  1112
Selected platform: NVIDIA CUDA
Selected device: GeForce GT 730
with OpenCL 1.2 capability and FP16 precision.

Started OpenCL SGEMM tuner.
Will try 290 valid configurations.
(1/290) KWG=16 KWI=2 MDIMA=8 MDIMC=8 MWG=16 NDIMB=8 NDIMC=8 NWG=16 SA=1 SB=1 STRM=0 STRN=0 VWM=2 VWN=2 2.3005 ms (69.8 G
FLOPS)
(2/290) KWG=16 KWI=2 MDIMA=8 MDIMC=8 MWG=32 NDIMB=8 NDIMC=8 NWG=16 SA=1 SB=1 STRM=0 STRN=0 VWM=2 VWN=2 1.7344 ms (92.6 G
FLOPS)
(5/290) KWG=16 KWI=2 MDIMA=8 MDIMC=8 MWG=32 NDIMB=8 NDIMC=8 NWG=32 SA=1 SB=1 STRM=0 STRN=0 VWM=2 VWN=2 1.5460 ms (103.9
GFLOPS)
(8/290) KWG=16 KWI=2 MDIMA=8 MDIMC=8 MWG=32 NDIMB=8 NDIMC=8 NWG=64 SA=1 SB=1 STRM=0 STRN=0 VWM=2 VWN=2 1.3205 ms (121.6
GFLOPS)
(69/290) KWG=16 KWI=8 MDIMA=8 MDIMC=8 MWG=32 NDIMB=8 NDIMC=8 NWG=64 SA=1 SB=1 STRM=0 STRN=0 VWM=2 VWN=2 1.1971 ms (134.1
GFLOPS)
(160/290) KWG=16 KWI=8 MDIMA=8 MDIMC=8 MWG=32 NDIMB=8 NDIMC=8 NWG=64 SA=1 SB=1 STRM=0 STRN=0 VWM=4 VWN=2 1.1265 ms (142.
5 GFLOPS)
(226/290) KWG=16 KWI=8 MDIMA=8 MDIMC=8 MWG=32 NDIMB=8 NDIMC=8 NWG=64 SA=1 SB=1 STRM=0 STRN=0 VWM=2 VWN=4 1.1059 ms (145.
2 GFLOPS)
Wavefront/Warp size: 32
Max workgroup size: 1024
Max workgroup dimensions: 1024 1024 64
BLAS Core: Prescott

Passes: 0            Black (X) Prisoners: 0
Black (X) to move    White (O) Prisoners: 0

   a b c d e f g h j k l m n o p q r s t
19 . . . . . . . . . . . . . . . . . . . 19
18 . . . . . . . . . . . . . . . . . . . 18
17 . . . . . . . . . . . . . . . . . . . 17
16 . . . + . . . . . + . . . . . + . . . 16
15 . . . . . . . . . . . . . . . . . . . 15
14 . . . . . . . . . . . . . . . . . . . 14
13 . . . . . . . . . . . . . . . . . . . 13
12 . . . . . . . . . . . . . . . . . . . 12
11 . . . . . . . . . . . . . . . . . . . 11
10 . . . + . . . . . + . . . . . + . . . 10
9 . . . . . . . . . . . . . . . . . . .  9
8 . . . . . . . . . . . . . . . . . . .  8
7 . . . . . . . . . . . . . . . . . . .  7
6 . . . . . . . . . . . . . . . . . . .  6
5 . . . . . . . . . . . . . . . . . . .  5
4 . . . + . . . . . + . . . . . + . . .  4
3 . . . . . . . . . . . . . . . . . . .  3
2 . . . . . . . . . . . . . . . . . . .  2
1 . . . . . . . . . . . . . . . . . . .  1
   a b c d e f g h j k l m n o p q r s t

Hash: 9A930BE1616C538E Ko-Hash: A14C933E7669946D

Black time: 01:00:00
White time: 01:00:00

Leela:

lu01

lu01 发表于 2018-5-4 13:32
一个能读取elf权重的修改版客户端
leela_lizzie_elf
C:\leela_lizzie_elf>leelaz -w elf_converted_weigh ...

https://github.com/Ka-zam/leela-zero/releases

lu01

https://github.com/gcp/leela-zero/files/1972910/leelaz_elf.zip 也可以用elf权重

lu01

gtp命令用法

play b c1把黑子下在c1
genmove w给出白子选点

Leela: play b c3
=


Passes: 0            Black (X) Prisoners: 0
White (O) to move    White (O) Prisoners: 0

   a b c d e f g h j k l m n o p q r s t
19 . . . . . . . . . . . . . . . . . . . 19
18 . . . . . . . . . . . . . . . . . . . 18
17 . . . . . . . . . . . . . . . . . . . 17
16 . . . + . . . . . + . . . . . + . . . 16
15 . . . . . . . . . . . . . . . . . . . 15
14 . . . . . . . . . . . . . . . . . . . 14
13 . . . . . . . . . . . . . . . . . . . 13
12 . . . . . . . . . . . . . . . . . . . 12
11 . . . . . . . . . . . . . . . . . . . 11
10 . . . + . . . . . + . . . . . + . . . 10
9 . . . . . . . . . . . . . . . . . . .  9
8 . . . . . . . . . . . . . . . . . . .  8
7 . . . . . . . . . . . . . . . . . . .  7
6 . . . . . . . . . . . . . . . . . . .  6
5 . . . . . . . . . . . . . . . . . . .  5
4 . . . + . . . . . + . . . . . + . . .  4
3 . .(X). . . . . . . . . . . . . . . .  3
2 . . . . . . . . . . . . . . . . . . .  2
1 . . . . . . . . . . . . . . . . . . .  1
   a b c d e f g h j k l m n o p q r s t

Hash: EBBE1A1739BEEC90 Ko-Hash: 7BAC2905857680BE

Black time: 01:00:00
White time: 01:00:00

Leela: play w d3
=


Passes: 0            Black (X) Prisoners: 0
Black (X) to move    White (O) Prisoners: 0

   a b c d e f g h j k l m n o p q r s t
19 . . . . . . . . . . . . . . . . . . . 19
18 . . . . . . . . . . . . . . . . . . . 18
17 . . . . . . . . . . . . . . . . . . . 17
16 . . . + . . . . . + . . . . . + . . . 16
15 . . . . . . . . . . . . . . . . . . . 15
14 . . . . . . . . . . . . . . . . . . . 14
13 . . . . . . . . . . . . . . . . . . . 13
12 . . . . . . . . . . . . . . . . . . . 12
11 . . . . . . . . . . . . . . . . . . . 11
10 . . . + . . . . . + . . . . . + . . . 10
9 . . . . . . . . . . . . . . . . . . .  9
8 . . . . . . . . . . . . . . . . . . .  8
7 . . . . . . . . . . . . . . . . . . .  7
6 . . . . . . . . . . . . . . . . . . .  6
5 . . . . . . . . . . . . . . . . . . .  5
4 . . . + . . . . . + . . . . . + . . .  4
3 . . X(O). . . . . . . . . . . . . . .  3
2 . . . . . . . . . . . . . . . . . . .  2
1 . . . . . . . . . . . . . . . . . . .  1
   a b c d e f g h j k l m n o p q r s t

lu01

Leela: genmove b
Thinking at most 90.0 seconds...
NN eval=0.650270
Playouts: 10, Win: 53.06%, PV: D4 E3 E4 C2 C4 G3 Q4 C16
Playouts: 48, Win: 62.35%, PV: D4 E3 E4 C2 C4 G3 Q4 C16 Q16 F17 G16 F16 G15
Playouts: 178, Win: 65.26%, PV: D4 E3 E4 C2 C4 G3 Q4 C16 Q16 F17 F4 H2 B2 R17 Q17 R16 R14
。。。
  E3 ->    3133 (V: 32.84%) (N: 99.27%) PV: E3 E4 C2 C4 G3 D16 Q3 R5 Q16 P4 R4 S4 Q5 Q4 R3 R6 O3 O4 N3 N4 S3 F4
17
  Q4 ->       0 (V:  0.00%) (N:  0.27%) PV: Q4
15.3 average depth, 32 max depth
2368 non leaf nodes, 1.32 average children

3134 visits, 1080243 nodes

sses: 0            Black (X) Prisoners: 0
ite (O) to move    White (O) Prisoners: 0

a b c d e f g h j k l m n o p q r s t
. . . . . . . . . . . . . . . . . . . 19
. . . . . . . . . . . . . . . . . . . 18
. . . . . . . . . . . . . . . . . . . 17
. . . + . . . . . + . . . . . + . . . 16
. . . . . . . . . . . . . . . . . . . 15
. . . . . . . . . . . . . . . . . . . 14
. . . . . . . . . . . . . . . . . . . 13
. . . . . . . . . . . . . . . . . . . 12
. . . . . . . . . . . . . . . . . . . 11
. . . + . . . . . + . . . . . + . . . 10
. . . . . . . . . . . . . . . . . . .  9
. . . . . . . . . . . . . . . . . . .  8
. . . . . . . . . . . . . . . . . . .  7
. . . . . . . . . . . . . . . . . . .  6
. . . . . . . . . . . . . . . . . . .  5
. . .(X). . . . . + . . . . . + . . .  4
. . X O . . . . . . . . . . . . . . .  3
. . . . . . . . . . . . . . . . . . .  2
. . . . . . . . . . . . . . . . . . .  1
a b c d e f g h j k l m n o p q r s t

sh: 9ED3B4D3AF516C12 Ko-Hash: EC187C11399003C

ack time: 00:59:14
ite time: 01:00:00

lu01

作者：田渊栋
链接：https://zhuanlan.zhihu.com/p/36355033
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。


写完了官方报告现在写一点自己的感想。
这个项目不是为了做最好的围棋程序，不是说要打败谁。我们做这个是因为以下三个目的：
(1) AlphaGoZero/AlphaZero算法很有意思，我们想知道为什么它有效果，是怎么会有效果的，是不是如同宣传的那样是百试百灵的通用算法，是不是只要堆机器，强人工智能马上就来了？还是说其实这个算法有什么问题和弱点？DeepMind不开源也不透露细节，文章里面一些地方也没有写得很清楚。我之前写过Blog讨论过，但是没有第一手经验总不是很踏实。所以本着研究目的，我们需要复现一下，先有复现，才有创新，这个是做研究的习惯。
(2) 今年年初我重写了ELF的核心代码，另外也加了分布式训练，需要找个具体应用来测试一下。站在这个角度上，AlphaGoZero/AlphaZero是个完美的选择，再说之前也有DarkForest的代码和围棋程序的经验，所以把它们拼起来不用花太多力气。
(3) 不管是通用算法还是分布式平台，都可以用来干很多别的事情，不一定是围棋，不一定是游戏。如果我们去看ELF OpenGo的代码，会发现其实很大一部分和围棋一点关系也没有，完全适用于其它方向的工作。而围棋对我们来说，只是一个把算法和平台做好的手段。在这一点上，花点时间把围棋做好是值得的。
两年前为什么我决定停止做DarkForest，主要是因为当时科研上再做围棋价值不大了；现在继续做这个，主要是因为AGZ/AZ作为一个一般化的算法非常有趣，研究它可能会有新的感悟，能对问题有新的理解——这个是科学的最终目的。
今天ELF OpenGo终于发布，我觉得这三个目的都达到了，而且为整个研究界贡献了我们在探索中所获得的知识，非常高兴。
这个项目从今年一月开始，做了四个月不到的时间。首先写了一个AZ的版本，效果不是很好；然后写了AGZ，效果还是一般；直到我发现一个PyTorch的bug（见KLDivLoss behaves differently on CPU/GPU · Issue #5801 · pytorch/pytorch，GPU下梯度有错，CPU下正常），修掉了之后，AI水平就像野马奔腾一样往上冲，令人叹为观止。最后为了加快速度又换成了AZ。要是从一开始就没有这个bug，很可能可以提前两个月发布。大家要是做VAE，GAN或者有任何用到KL divergence的地方，要注意用最新的PyTorch，免得掉坑里面。当然有这几个转折后的好处是我们对整个系统的行为有了更深的理解，同时发布的代码里可以选择是用AGZ或者AZ，或者其它的中间方案。
整个新版ELF，分布式框架及快速蒙特卡罗搜索的代码是我搭建起来的，部署在CGOS和LeelaZero上的实验，还有半精度前馈网络的测试由龚渠成负责，各种分布式部署、调参、蒙特卡罗搜索的测试及代码重构由Jerry和Shubho还有卓远负责，Larry则提供了巨大的支持。这里感谢大家的辛勤工作！另外吴育昕在整个项目中也帮了挺多忙，还要感谢公司提供的大量资源，不然最后的模型不会有那么好的效果，更不用说能在无时限慢棋中以单卡战胜职业高手。
插个花絮：之前大家在猜测CGOS上那些以美国总统和朝代为名（除了jin_lee）的bot都是谁，其实那些都是我们各种不同版本的bot。本来是要用朝代名序列的，不过不知道是谁搞了个 jin_lee抢了先，所以切换成了美国总统序列。

hred9D

看看自己的破笔记本，哎，首先得有一台高配的电脑
低端笔记本，在参数上面动动脑筋，或可以提高一点点计算效率。
ELF open狗拿到公司服务器上面跑一跑，，，哈哈

lu01

leelaz 0.14发布了，支持elf https://github.com/gcp/leela-zero/releases

lu01

关于ELF OpenGo一些问题的回复  7 小时前 · 来自专栏 远东轶事 最近网上很多讨论我们刚发布的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