共计 2571 个字符，预计需要花费 7 分钟才能阅读完成。
Google 开源了新一代深度学习引擎 TensorFlow。本文解释了一些 TF 里面我觉得可以从系统方面值得看的地方。
编程模型
TF 目前的编程模型是符号编程 (symbolic computation)。大致的想法就是使用符号 API 去描述计算通过计算流图的方式，以及更新逻辑，然后通过像服务器去发送计算流图的方式来进行计算。原因是所有的计算全部需要通过计算流图来描述，也就是其实通 PythonAPI 编写的主要是 Tensorflow 这一门新的语言。然后通过 session 的 run 来进行一些交互。这样子做的主要好处是计算流图的执行可以进行比较多的优化，因为用户只是指定了数据关系，以及需要什么，计算的中间变量如何分配，是否需要保留，都是可以进行优化的。这一点是相比于 Torch 和 numpy 的库相对可以更多优化的地方。不过反过来说，和原有 host 语言的交互会相对比较有限一些，会比较难利用一些 host 语言 (python) 的特性来编写如条件和更新法则之类的东西。
作为一个工程师，从优化性能的角度，很容易倾向于用 symbolic 描述所有东西，然后做尽量多的优化。而作为 researcher（Torch 来自 NYU），更容易倾向于灵活性，而选择过程计算风格的编程。
支持 Mutation
和目前的符号语言比起来，TF 最大的特点是强化了数据流图，引入了 mutation 的概念。这一点是 TF 和包括 Theano 在内的符号编程框架最大的不同。所谓 mutation，就是可以在计算的过程更改一个变量的值，而这个变量在计算的过程中会被带入到下一轮迭代里面去。Mutation 是机器学习优化算法几乎必须要引入的东西（虽然也可以通过 immutablereplacement 来代替，但是会有效率的问题）。Theano 的做法是引入了 updatestatement 来处理 mutation。TF 选择了纯符号计算的路线，并且直接把更新引入了数据流图中去。从目前的白皮书看还会支持条件和循环。这样就几乎让 TF 本身成为一门独立的语言。不过这一点会导致最后的 API 设计和使用需要特别小心，把 mutation 引入到数据流图中会带来一些新的问题，比如如何处理写与写之间的依赖。
细粒度操作优化
这一点是 Google 作为一个公司的资源带来的优势。TF 大部分的操作是细粒度操作，可以来带比较大的灵活性，不过反过来，也在工程上面需要比较多的优化开销。一个更加偷懒的做法是直接支持常见的粗粒度操作，加上比较少的细粒度操作来做辅助，这样基本上可以减低优化带来的 overhead，而对于大部分的问题也就可以比较轻松的应对了。caffe2 和 mxnet 走了粗粒度操作加细粒度这条路也是基于同样的原因。这属于是在有限资源 constraint 下面做出的更加轻量级的选择。
分布式支持
TF 目前并没有直接放出分布式的支持。从放出来的白皮书看，分布式的容错采取了 consistent checkpointrestart 策略，似乎没有更加 fancy 容错，但是又非常实用。可以看到 google 对于系统的选择还是非常现实的。同样的也可以反思现在的分布式系统，机器学习是不是真的需要像比如 lineage 这样的容错机制其实要打一个很大的问号。
Parameter Server 已经过时了？
在 TF 白皮书里面提到的一点是 PS 因为系统的 abstraction 直接成为计算流图的一部分，相对弱化了 PS 作为一个系统的地位。这一点的主要原因是 dependencytracking 在计算流图里面得到的强化，而 PS 本身的一大功能就是完成 dependencytracking。如果你仔细看 mxnet 本身的 kvstore 的实现，就会发现本地的参数整合代码几乎完全是利用依赖引擎完成的，这样的确可以大大简化 PS 的代码实现。不过 PS 本身作为一个 abstraction，在通信和数据 consistency 上面还是可以提供一些不错的 dataparallel 解决方案。未来的方向应该是各个系统更加融合，ps 本身也作为一个依赖调度中的 primitive 直接整合入深度学习引擎，而不再作为一个宿主系统存在了。
目前系统的关系
TF 在编程模型上面最相似的是 Theano，基本涵盖了 Theano 所有的功能。在最近新的编程框架上面，比较相关的两个，一个是 caffe2，另外一个是 mxnet。
caffe2 的设计风格基本和 TF 一致，走的是符号计算的路线，唯一的不同是支持粗粒度的操作，这一点在之前也有提到，是为了轻量级而做的选择。目前主要由 yangqing 一个人完成，可以认为是轻量级的 TF。
mxnet 的设计思路是符号计算和过程计算混合。在符号计算部分没有引入 mutation，而是允许把符号计算融入到过程计算中，通过 host 语言来表述更新法则，同时动态调度过程计算的和符号计算的指令。这么做对于调度引擎需要更多的一些要求，并且也可能带来一些效率的影响（过程计算是动态执行的，有动态内存开销，更少一些优化），不过如果合理地把主要的瓶颈部分放到符号计算里面去，剩下的部分用更加灵活的过程计算来做，最终的效率影响不会特别大。
这两个系统在依赖调度和系统优化上面的思想应该和 TF 基本一致，有兴趣的同学可以对比学习一下。
选择什么
我本人参与了 mxnet 的设计，因此比较难公正地回答这个问题。不过有一点是肯定的，计算流图和优化的思想，以及依赖关系的调度，和计算优化会是下一代深度学习系统的主题。
一些个人的 note
DMLC 团队从五月份开始决定联合三个项目做 mxnet，六月份设计完成，到九月份初步版本确立。我个人在参与设计 mxnet 之后七月到 G brain 实习，接触到了 TF 和内部的东西。个人的感觉，不同的项目设计是在不同的人力资源，目标（灵活度，效率）和 taste 的权衡下面做出不同优化的设计决定。mxnet,caffe2 和 TF 的设计实现差别大概就在于此。没有对错，只看每个设计者的品味和想法了。因为这一点，让我确信我们做了正确的选择，并且决定继续九月份结束实习后帮助团队 mxnet 到目前相对完整的阶段。yangqing 因为工作的缘故可能限制更多一些，不过也希往每个人也都有机会实现每心中理想的系统。
本文永久更新链接地址：http://www.linuxidc.com/Linux/2016-07/133221.htm
