Oneflow-Inc
Proposal for scalability in Libai
-
第一个认为可以扩展的地方是验证器的输入无法简单地从模型输出获得，因为在libai中，默认所有的计算是在模型中计算完毕。但我在复现Nerf时存在需要每个epoch中batch的索引，这个需求模型无法完成，经过chengpeng老师的指导，我将代码转移到了Evaluator中，并继承之。但是模型的输出需要通过libai/evaluation/evaluator.py中210行开始的检查，因此无法轻易通过，只能像NeRF项目中采用projects/NeRF/modeling/System.py中411行开始到416行结束的形式，以及projects/NeRF/evaluation/nerf_evaluator.py中38行开始到44行结束的形式通过冗余代码来实现。
-
第二个认为可以扩展的地方是可以借鉴openmmlab采用装饰器的形式，毕竟以后的项目肯定不可能都是公司的人来实现，用户也会为了自己需求进行扩展。这样的话，可以通过装饰器来将相应的模型，数据加载器，验证器加入其中并实现轻易地扩展。
- 第一个认为可以扩展的地方是验证器的输入无法简单地从模型输出获得，因为在libai中，默认所有的计算是在模型中计算完毕。但我在复现Nerf时存在需要每个epoch中batch的索引，这个需求模型无法完成，经过chengpeng老师的指导，我将代码转移到了Evaluator中，并继承之。但是模型的输出需要通过libai/evaluation/evaluator.py中210行开始的检查，因此无法轻易通过，只能像NeRF项目中采用projects/NeRF/modeling/System.py中411行开始到416行结束的形式，以及projects/NeRF/evaluation/nerf_evaluator.py中38行开始到44行结束的形式通过冗余代码来实现。
- 第二个认为可以扩展的地方是可以借鉴openmmlab采用装饰器的形式，毕竟以后的项目肯定不可能都是公司的人来实现，用户也会为了自己需求进行扩展。这样的话，可以通过装饰器来将相应的模型，数据加载器，验证器加入其中并实现轻易地扩展。
第二点我没有太get到， 用装饰器来实现轻易的扩展， 和目前在config里面使用lazycall在python层面进行自由的拼接， 看上去打成的目的是一样的。
有个issue有过对于这个详细的讨论，从使用感官和添加代码的量来看，目前config下的lazycall的调用方式应该是比较灵活的。 https://github.com/Oneflow-Inc/libai/issues/12
- 第一个认为可以扩展的地方是验证器的输入无法简单地从模型输出获得，因为在libai中，默认所有的计算是在模型中计算完毕。但我在复现Nerf时存在需要每个epoch中batch的索引，这个需求模型无法完成，经过chengpeng老师的指导，我将代码转移到了Evaluator中，并继承之。但是模型的输出需要通过libai/evaluation/evaluator.py中210行开始的检查，因此无法轻易通过，只能像NeRF项目中采用projects/NeRF/modeling/System.py中411行开始到416行结束的形式，以及projects/NeRF/evaluation/nerf_evaluator.py中38行开始到44行结束的形式通过冗余代码来实现。
- 第二个认为可以扩展的地方是可以借鉴openmmlab采用装饰器的形式，毕竟以后的项目肯定不可能都是公司的人来实现，用户也会为了自己需求进行扩展。这样的话，可以通过装饰器来将相应的模型，数据加载器，验证器加入其中并实现轻易地扩展。
第二点我没有太get到， 用装饰器来实现轻易的扩展， 和目前在config里面使用lazycall在python层面进行自由的拼接， 看上去打成的目的是一样的。
有个issue有过对于这个详细的讨论，从使用感官和添加代码的量来看，目前config下的lazycall的调用方式应该是比较灵活的。 #12
我感觉确实有道理，仔细一想确实Lazycall的方式比较灵活