终于，Keras计划从TensorFlow代码库中分离

(由于下周搬家回西城，可能会停更一次哈)

Keras计划从TensorFlow中分离了？

Google曾大力推广的TensorFlow 2.0，其一大卖点就是易用性，甚至强调易用性的声音压过了性能需求。一是支持Eager模式，即非静态图模式，便于调试；二是主推Keras，以试图通过Keras约束用户模型的写法，达到梳理TensorFlow 1.0中臭名昭著的API混乱问题。那么如今Keras从TensorFlow中分离，会对TensorFlow 2.0产生什么影响？Keras还会为作为TensorFlow 2.0主要推广的API吗？

本人认为——对开发者简化了Contribute的负担。对用户层无感知，完全不影响。对以后TF API的发展，这不好说。

先谈谈对开发者的影响。从作者的解释上看，对此次Keras分离的初衷，完全是软件架构上的一次解耦。目的也是为了解放Keras开发者的负担。自从Keras宣布成为TensorFlow 2.0官方高级API之后，TensorFlow代码库中就多了tf.keras模块。别看只是Python代码，设计中运用了大量的Python特殊的语法特性才构成这样一个链式编程的目的。不仅如此，tf.keras模块的Python源码还十分难读，虽然结构比较清晰，但代码量非常大，开发者需要编写很多单元测试才能保证其正确性。

但是，tf.keras依赖与TensorFlow的一些Python op，而这些Python op又依赖于TensorFlow较重的底层Runtime。假设我是开发者，为tf.keras模块做了个bug fix，在我触发UT时，将迫不得已触发TensorFlow的编译，这就十分heavy了。开发五分钟，编译一小时，很多开发者并不买账。所以将Keras模块和TensorFlow解耦，主要是开发者的诉求，也是软件快速迭代的诉求。

然而解耦并非容易之事，一些模块需要改写。在TensorFlow和Keras缔结婚姻之后，一些开发者在开发tf.keras的模块时，使用了非公开的TensorFlow API构建。

这样做的结果，就是能让Keras模块的构建和测试的时间成本大大降低，对开发者十分友好。

再谈谈对用户的影响。如果分离的十分干净，那么对用户层面将完全无感知。所以那些觉得Keras这个太子被立了又废的用户，可以不用担心了。经过PyTorch的侵蚀，TensorFlow社区应该十分忌讳这种事情了。

最后谈谈API层面的问题。时至今日，大部分TensorFlow的用户还是被1.0的coding style影响了，工业界存量模型（尤其是搜广推模型）依然不敢迁移到2.0的写法上。可是从理论上讲，对于一个完全从0开始学习TensorFlow的用户来说，明明是TF 2.0的coding style更加容易。因此从这个角度讲，不如说TensorFlow 1.0已经培养了一批用户，让他们习惯于Graph模式的编写，并且认识到2.0的coding style不一定会带来明显的性能优势以及可扩展性优势。不仅如此，喜欢eager模式的用户可能更喜欢PyTorch的coding style，这是完全挡不住的。

所以Keras到底能不能约束用户API，对用户已经不重要了，但对系统开发和性能优化十分重要。用户奇怪的写法，各种诡异繁多的计算Pattern，都对编译层面上的优化工作挑高了复杂度。TensorFlow 2.0要想翻盘，不如做些减法。比如认真做好自己的Runtime，将其性能和生态都具的优势逐渐扩大，这可能会比火拼API层面更具有产品吸引力。