Dive into TensorFlow系列（1）-靜態圖執行原理

京東雲發表於2022-11-11

接觸過TensorFlow v1的朋友都知道，訓練一個TF模型有三個步驟：定義輸入和模型結構，建立tf.Session例項sess，執行sess.run()啟動訓練。不管是因為歷史遺留程式碼或是團隊保守的建模規範，其實很多演算法團隊仍在大量使用TF v1進行日常建模。我相信很多演算法工程師執行sess.run()不下100遍，但背後的執行原理大家是否清楚呢？不管你的回答是yes or no，今天讓我們一起來探個究竟。

學習靜態圖執行原理能幹什麼？掌握它對我們TF實踐中的錯誤排查、程式定製、效能最佳化至關重要，是必備的前置知識。

一、何為靜態圖？

眾所周知，TensorFlow程式有兩種執行選擇，即靜態圖模式與動態圖模式。

1.1 靜態圖

靜態圖採用宣告式程式設計正規化（先編譯後執行），根據前端語言（如python）描述的神經網路結構和引數資訊構建固定的靜成計算圖，靜態圖在執行期間不依賴前端語言，而是由TF框架負責排程執行，因此非常適合做神經網路模型的部署。使用者定義的靜態圖經序列化後用GraphDef表達，其包含的資訊有：網路連線、引數設定、損失函式、最佳化器等。

有了完整的靜態圖定義後，TF編譯器將計算圖轉化成IR（中間表示）。初始IR會經TF編譯器一系列的轉換和最佳化策略生成等價的計算圖。編譯器前端轉換和最佳化包括：自動微分、常量摺疊、公共子表示式消除；編譯器後端與硬體相關，其轉換和最佳化包括：程式碼指令生成和編譯、運算元選擇、記憶體分配、記憶體複用等。

綜上所述，靜態圖的生成過程可用下圖簡要概適：

1.2 動態圖

動態圖採用指令式程式設計正規化，即編譯與執行同時發生。動態圖採用前端語言的直譯器對使用者程式碼進行解析，然後利用TF框架的運算元分發功能，使得運算元立即執行並向前端返回計算結果。當模型接收輸入資料後，TF開始動態生成圖拓撲結構，新增輸入節點並將資料傳輸給後續節點。如果動態圖中含有條件控制邏輯，會立即計算邏輯判斷結果並確定後續資料流向，因此動態圖完整的拓撲結構在執行前是未知的。另外，當模型根據新的batch訓練時，原有的圖結構則失效，必須根據輸入和控制條件重新生成圖結構。

綜上所述，動態圖生成過程可用下圖簡要概括：

1.3 比較

為了方便大家深入理解動/靜態圖原理及異同點，梳理相關資訊如下表：

	靜態圖	動態圖
即時獲取中間結果	否	是
程式碼除錯難度	難	易
控制流實現方式	TF特定語法	可採用前端語言語法
效能	多種最佳化策略，效能好	最佳化受限，效能差
記憶體佔用	記憶體佔用少	記憶體佔用多
部署情況	可直接部署	不可直接部署

二、Session是幹啥的？

2.1 Session定義

tf.Session代表使用者程式和C++執行時之間的連線。一個Session類物件session可以用來訪問本機計算裝置，也可訪問TF分散式執行時環境中的遠端裝置。session也能快取tf.Graph資訊，使得相同計算邏輯的多次執行得以高效實現。

tf.Session的構造方法定義如下：

  def __init__(self, target='', graph=None, config=None):
    """Creates a new TensorFlow session.
    If no `graph` argument is specified when constructing the session,
    the default graph will be launched in the session. If you are
    using more than one graph (created with `tf.Graph()` in the same
    process, you will have to use different sessions for each graph,
    but each graph can be used in multiple sessions. In this case, it
    is often clearer to pass the graph to be launched explicitly to
    the session constructor.
    Args:
      target: (Optional.) The execution engine to connect to.
        Defaults to using an in-process engine. See
        @{$distributed$Distributed TensorFlow}
        for more examples.
      graph: (Optional.) The `Graph` to be launched (described above).
      config: (Optional.) A [`ConfigProto`](https://www.tensorflow.org/code/tensorflow/core/protobuf/config.proto)
        protocol buffer with configuration options for the session.
    """
    super(Session, self).__init__(target, graph, config=config)
    # NOTE(mrry): Create these on first `__enter__` to avoid a reference cycle.
    self._default_graph_context_manager = None
    self._default_session_context_manager = None

我們來看一下__init__()方法的三個引數：

•target：預設為空，代表session僅可訪問本機上的計算裝置。如果設定grpc://樣式的URL，則可以訪問TF server對應機器的計算裝置。

•graph：預設執行當前default graph中的op運算元。如果使用者程式中包含多個計算圖，則在建立session時必須指定是哪個計算圖。

•config：透過指定tf.ConfigProto來控制session的行為。常見的配置選項有：裝置退化allow_soft_placement、分散式叢集配置cluster_def、圖最佳化策略graph_options.optimizer_options、GPU記憶體逐步增長gpu_options.allow_growth。

2.2 Session.run()

tf.Session.run()實際是呼叫tf.BaseSession.run()方法，其函式簽名如下：

def run(self, fetches, feed_dict=None, options=None, run_metadata=None):

run()方法的引數說明如下：

•fetches：指定要執行的tf.Operation或評估的tf.Tensor，可以是單個元素或是列表、字典。

•feed_dict：一個佔位符到填充值的對映。

•options：RunOptions的protocol buffer。

•run_metadata：RunMetadata的protocol buffer，用來收集執行過程的後設資料資訊。

當Session指定fetches後，根據要獲取的結果決定tf.Graph實際執行的subgraph（並非整個tf.Graph都要執行）。執行靜態圖還有三個要點：

•訓練階段用一個靜態圖，而預測/評估階段用另一個靜態圖。

•一個session例項只能執行一個graph例項，但一個graph可以執行在多個session中。

•session之間可透過共享graph的方式來提高執行效率。建立session時若不指定graph，則執行的是default graph。如果新建立的session也不指定graph，則只需要對default graph的引用計數加1即可；當此session close時，default graph引用計數減1。

2.3 Session類前後端設計

首先我們看一下和使用者直接打交道的前端Session，具體分為普通Session和互動式InteractiveSession。前者全稱為tf.Session，需要在啟動之前先構建完整的計算圖；後者全稱為tf.InteractiveSession，它是先構建一個session，然後再定義各種操作，適用於shell和IPython等互動式環境。這兩個類均繼承自BaseSession，這個基類實現了整個生命週期的所有會話邏輯（相關程式碼在tensorflow/python/client/session.py中）。前端Session類的繼承關係如下圖：

TensorFlow後端會根據前端tf.Session(target='', graph=None, config=None)建立時指定的target來建立不同的後端Session。target是要連線的TF後端執行引擎，預設為空字串。後端Session的建立採用抽象工廠模式，如果為空字串，則建立本地DirectionSession；如果是grpc://開頭的URL串，則建立分散式GrpcSession。DirectSession只能利用本地裝置，將任務排程到本地的CPU/GPU裝置上；GrpcSession可利用遠端裝置，將任務分發到不同機器的CPU/GPU上，然後機器之間透過gRPC進行通訊。顯而易見，DirectionSession的定義應在core/common_runtime/direction_session.h中；GrpcSession的定義在core/distributed_runtime/rpc/grpc_session.h中。後端Session的類圖關係如下所示：

三、靜態圖執行過程

3.1 執行框架

為便於大家理解，我們先給出粗粒度的靜態圖執行原理如下：

1.客戶端程式定義基於資料流的計算圖，然後建立session並初始化計算引擎。

2.分散式Master依次完成四項工作：抽取實際執行的subgraph、切分subgraph形成若干子圖片段、排程子圖片段至叢集、每個子圖片段執行前的初始化工作。

3.叢集中的Worker節點排程子圖片段中Operation的執行，與其他Worker節點透過send/recv節點對進行通訊。

3.2 若干執行細節

靜態圖的實際執行過程要比3.1節描述的複雜得多。由於本篇的初衷不是做原始碼的完整剖析，因此我們僅就Client向Master的處理過程做詳細說明，旨在讓讀者親身體會一下互動過程的複雜性。

Client建立GrpcSession，控制Client會話的生命週期；Master執行時被MasterSession控制。GrpcSession透過抽象工廠模式得到，首先得到工廠類GrpcSessionFactory的物件，並用SessionFactory控制程式碼factory儲存。然後透過factory的多型方法生成GrpcSession，如果target為grpc://的話。Master本質上是一個Server，每個Server均有一個MasterService和一個WorkerService。

Client透過GrpcSession呼叫Master節點的MasterService，這個過程需藉助MasterInterface才可完成。MasterInterface用來和MasterService進行通訊，它有兩種不同的場景實現：

•如果Client和Master在同一個程式中，則用LocalMaster實現程式內的直接通訊。

•GrpcRemoteMaster則使用gRPC來和MasterService進行通訊，此時Master和Client在兩個不同的程式中。GrpcRemoteMaster的角色是gRPC客戶端，它透過stub訪問遠端Master節點上的MasterService服務。