我们的理念

科研

Deeplearning4j不是一个科研框架。虽然它可以用于研究,而且我们也鼓励人们这样做(Apache许可协议),但我们很注重具体的用例。大多数研究的成果无法直接用于行业生产。目前发表的许多研究论文(确实提出了不少好构想)也无法直接应用,因为其中的构想尚不成熟。

人们经常问我们:“为什么不把上周的那篇论文实现一下?”因为我们把时间花在了 DataVec等帮助人们创造实际产品的工具上。

我们也知道需要有一定的灵活度,否则就不会加入计算图Keras模型导入功能。

不要重写数据加工管道的粘合代码

数据加工正是DataVec的功能。许多人习惯为数据加工管道编写一次性代码。如果您还是打算自己做这些工作,那何不借此机会来为这个库作贡献呢?

Spark

另一方面,我们也会收到来自Spark社区的问题。人们经常问我们为什么不和Spark集成得更紧密一些。原因很清楚:Spark是一种数据访问层,而非计算引擎。Spark有可能永远不会支持或者没有意向马上支持深度学习所需的某些元素。主要的因素是硬件加速。我们还支持移动系统。尽管如此,我们也已经推出了一流的Spark集成。许多工具都可以用bash脚本来添加支持,只需要通过与YARN互动即可实现。如果您有GPU,作为一项Spark任务运行的DL4J知道该如何访问它。

我们的线性代数库可以检测出工作节点所在的硬件并使用该位置上的任何资源。它让您可以在需要时通过CudaEnvironment单例方法来实现GPU和计算环境的细粒度 控制。

另一个原因则是可以同时支持二进制和纵列数据的工具。机器学习的专用数据加工管道工具(Spark上尤其如此)本质上是面向学术研究的,而非针对实际的问题。而在DataVec和其他常用工具的帮助下,我们让您能同时在本地和Spark上运行,可以将一个数据加工管道API同时用于纵列数据和二进制数据(例如图像和视频)

头等JVM

另外还有头等JVM的概念。大多数学习框架需要通过Python来与Spark进行互动。与Spark的互动让您可以实现分布式网格搜索和其他一些比较强大的功能。

问题在于Python的速度和数据瓶颈。但是,JNI速度的并不慢,主要是因为JavaCPP的缘故。

总而言之: 我们的学习框架对数据工程师和运维人员很友好。中央IT部门不会介意部署一个jar文件。我们会继续为企业用户打造工具。人们懂得如何使用Spark。人们会继续用基于Python的其他工具来开展研究(这些工具已经具备相应的用户心理占有率和工具)。我们将继续提供可以在任何地方运行(包括企业内部部署)的中立学习框架(背后没有与之相锁定的云计算服务商支持),而这正是目前整个生态系统中所缺失的部分。

与我们在Gitter聊天