喜大普奔，在祖國70歲生日的這一天，TensorFlow2.0正式Release，本文主要介紹一下TensorFlow2.0的新特性。TensorFlow 1.15 官方已經宣佈該版本是1.X的最後一個版本了。
主要特點和改進
TensorFlow 2.0專注於簡單性和易用性，具有以下更新：
- 使用Keras輕鬆構建模型，渴望執行模式
- 在任何平臺上進行生產中的穩健模型部署
- 強大的研究實驗
- 通過減少重複並刪除已經標記不再使用的端點來簡化API
有關2.0最佳實踐的詳細信息，參照the Effective 2.0 guide
這裏我強調一下渴望執行模式。TensorFlow 2.0 主推的 eager execution mode 採用和解釋執行圖完全不同的深度學習計算方式。 類似 PyTorch 的做法，前向計算過程把對基本計算單元（operator）的調用記 錄在一個內存數據結構 tape 裏，隨後，反向計算過程（計算 gradients 的） 可以回溯這個 tape，以此調用 operator 對應的 gradient operator。這個 tape 提供一個操作讓用戶可以獲取每個參數的 gradient。
Highlights
- TF 2.0提供Keras作爲用於構建和訓練模型的中央高級API。 Keras提供了一些模型構建API，例如順序，功能和子類化以及急切的執行（用於立即迭代和直觀調試）以及tf.data（用於構建可擴展的輸入管道）。
- 分發策略：TF 2.0用戶將能夠使用tf.distribute.Strategy API通過最少的代碼更改來分發培訓，從而獲得出色的現成性能。它支持Keras model.fit以及自定義訓練循環的分佈式訓練。提供多GPU支持，以及對多工作人員和Cloud TPU的實驗性支持
- 功能，而不是會話。不鼓勵使用傳統的聲明式編程模型來構建圖形並通過tf.Session執行它，並通過編寫常規的Python函數來代替。使用tf.function裝飾器，這些函數可以轉換爲圖形，可以遠程執行，序列化並針對性能進行優化。
- tf.train.Optimizers和tf.keras.Optimizers的統一。對TF2.0使用tf.keras.Optimizers。作爲公共API刪除了compute_gradients，使用GradientTape計算梯度。
- AutoGraph將Python控制流轉換爲TensorFlow表達式，允許用戶在裝飾有tf.function的函數中編寫常規Python。 AutoGraph也適用於與tf.data，tf.distribute和tf.keras API一起使用的函數。
- 交換格式與SavedModel的統一。所有TensorFlow生態系統項目（TensorFlow Lite，TensorFlow JS，TensorFlow Serving，TensorFlow Hub）都接受SavedModels。模型狀態應保存到SavedModels或從SavedModels恢復。
- API更改：許多API符號已重命名或刪除，參數名稱也已更改。這些變化中的許多變化都是出於一致性和清晰性。 1.x API在compat.v1模塊中仍然可用。
- 添加環境變量TF_CUDNN_DETERMINISTIC。設置爲TRUE或“ 1”將強制選擇確定性cuDNN卷積和最大池算法。啓用此功能後，算法選擇過程本身也是確定性的。
TensorFlow 2.0與kubernetes
這兩個在各自領域最火的框架，結合的工作其實業界已經有很多嘗試了，包括谷歌的kubeflow。Distributed TensorFlow雖然提供了分佈式能力，可以利用服務器集羣加快訓練，但是還有許多缺點：
- 訓練時TensorFlow各個Task資源無法隔離，很有可能會導致任務間因資源搶佔互相影響。
- 缺乏調度能力，需要用戶手動配置和管理任務的計算資源。
- 集羣規模大時，訓練任務的管理很麻煩，要跟蹤和管理每個任務的狀態，需要在上層做大量開發。
- 用戶要查看各個Task的訓練日誌需要找出對應的服務器，並ssh過去，非常不方便。
- TensorFlow原生支持的後端文件系統只支持：標準Posix文件系統（比如NFS）、HDFS、GCS、memory-mapped-file。大多數企業中數據都是存在大數據平臺，因此以HDFS爲主。然而，HDFS的Read性能並不是很好。
而這些正是Kubernetes所擅長的地方。
當你試着去創建一個大規模TensorFlow集羣時，發現並不輕鬆；
尤其是螞蟻金服開源的ElasticDL，該項目是基於TensorFlow 2.0的Kubernetes-native 彈性分佈式深度學習系統。