失败的试验具有这种配置,这似乎在相同的大小的工作器上在tensorflow上训练得很好:
| Trial name | status | loc | combiner.bn_momentum | combiner.bn_virtual_bs | combiner.num_steps | combiner.output_size | combiner.relaxation_factor | combiner.size | combiner.sparsity | training.batch_size | training.decay_rate | training.decay_steps | training.learning_rate | iter | total time (s) | metric_score |
| trial_e6687d84 | ERROR | 172.31.10.68:26084 | 0.7 | 2048 | 4 | 8 | 1 | 32 | 0.0001 | 8192 | 0.95 | 500 | 0.025 | | | |
8条答案
按热度按时间7nbnzgx91#
堆栈转储为:
sulc1iza2#
请注意,kdd数据集需要在主分支和tf-legacy上进行修复;PRs可用。
qlckcl4x3#
问题可以通过运行以下代码来重现:
z9gpfhce4#
在3节点的ray集群上运行,所有节点都是g4dn.4xlarge https://aws.amazon.com/ec2/instance-types/g4/。
zfycwa2u5#
我能够在使用高亮参数的Torch上复现OOM问题,其批处理大小为8192。然而,我在Tensorflow上也遇到了相同的OOM错误。我在ray上的Torch和Tensorflow上尝试了几个不同的批处理大小,并使用
nvidia-smi
来监控内存使用情况。总体来看,我们可以看到在每个批处理大小下,Torch使用的内存比Tensorflow多一点。4096已经非常接近两个分支的内存最大值(15k MiB),所以8192对于任何一个分支来说都太大了,这并不令人惊讶。
@anneholler,我想知道你是否能在你的环境中复现这个发现。如果OOM问题不仅仅局限于torch,那么我认为我们可以关闭这个问题。
yvt65v4c6#
gstyhher7#
感谢提供重现脚本!这对于更深入地研究这个问题确实非常有用。
的确,在我运行的实验中,我为 master 和 tf-legacy 使用了相同的显式指定类型,而不是依赖于每个分支自动推断的类型。
看起来,类型分配差异确实是问题所在。Master 为许多列分配了比
tf-legacy
更少的text
类型,这可能与 this change 有关。以下是一些示例:master
:vs.
tf-legacy
文本特征的默认编码器是一个
parallel_cnn
,它比类别特征的默认单密集层编码器要重得多。不出所料,具有更多文本特征的配置在两个分支上都遇到了内存不足(OOM)的问题。此外,当我为torch
使用tf-legacy
的列类型时,torch 不再出现 OOM 错误。 :)这个问题现在已经解决了,我们可以看到在两个分支上使用完全相同的配置时,出现了相同的 OOM/非OOM行为,只是分支分配了不同的类型。
关于是否应该修复类型分配,以及/或将文本特征的默认编码器降级到某种不太激烈的类型(如
embed
),这仍然是一个未解决的问题。无论如何,这样做可能是有益的。nr9pn0ug8#
#1755