深度學習調用TensorFlow、PyTorch等框架

一．開發目標目標

提供統一接口的庫，它可以從C++和Python中的多個框架中運行深度學習模型。歐米諾使研究人員能夠在自己選擇的框架內輕松建立模型，同時也簡化了這些模型的產品離子化。

支持TensorFlow、PyTorch、TorchScript和Keras等深度學習框架。

使用一個API從任何支持的框架運行模型，運行TensorFlow模型看起來就像運行PyTorch模型。

x = np.array([1, 2, 3, 4])

y = np.array([5, 6, 7, 8])

for model_path in [TF_ADDITION_MODEL_PATH, PYTORCH_ADDITION_MODEL_PATH]:

# Load the modelneuropod = load_neuropod(model_path)# Run inferenceresults = neuropod.infer({"x": x, "y": y})# array([6, 8, 10, 12])

print results[“out”]

這樣做的一些好處包括：

所有的推理代碼都是框架不可知的。

如果有必要，可以輕松地在深度學習框架之間切換，而無需更改運行時代碼。
避免使用C++ libtorch庫API和C/C++
TFAPI的學習曲線。任何神經網絡模型都可以從C++和Python（甚至是尚未轉化為TrCHcript腳本的PyTrac模型）運行。

定義問題API

這讓更關注正在解決的問題，而不是用來解決它的框架。

例如，如果為2d對象檢測定義了問題API，則實現該API的任何模型都可以重用該問題的所有現有推理代碼和基礎結構。INPUT_SPEC = [

# BGR image{"name": "image", "dtype": "uint8", "shape": (1200, 1920, 3)},

]

OUTPUT_SPEC = [

# shape: (num_detections, 4): (xmin, ymin, xmax, ymax)# These values are in units of pixels. The origin is the top left corner# with positive X to the right and positive Y towards the bottom of the

image

{"name": "boxes", "dtype": "float32", "shape": ("num_detections", 4)},# The list of classes that the network can output# This must be some subset of ['vehicle', 'person', 'motorcycle',

‘bicycle’]

{"name": "supported_object_classes", "dtype": "string", "shape": ("num_classes",)},# The probability of each class for each detection# These should all be floats between 0 and 1

{

“name”: “object_class_probability”, “dtype”: “float32”, “shape”: (“num_detections”, “num_classes”)},

]

為問題構建單個度量管道。

輕松比較解決同一問題的模型（即使它們位于不同的框架中）。

構建優化的推理代碼，可以運行解決特定問題的任何模型。

在運行時無需更改代碼即可解決相同問題的替換模型（即使模型來自不同的框架）
快速實驗。

建立通用工具和管道。

如果有幾個模型接受相似的輸入集，則可以構建和優化一個與框架無關的輸入生成管道，并在模型之間共享它。

其他好處

完全獨立的模型（包括自定義操作）

高效的零拷貝操作

在平臺上測試，包括Mac、Linux、Linux（GPU）

每個受支持框架的四個或五個版本，Python的五個版本

帶有進程外執行的模型隔離

在同一個應用程序中使用多個不同版本的框架

示例：每晚使用Torch的實驗模型和使用Torch1.1.0的模型

用一行代碼從進程內運行切換到進程外運行

二．技術，功能和性能

隨著自動駕駛軟件的發展，一直在尋找新的方法來改進模型。有時候，這意味著要試驗不同的深度學習框架。隨著新的深度學習框架的發布，以及 TensorFlow 和 PyTorch 等現有框架取得的進步，希望確保工程師和科學家能夠靈活地使用最適合正在研究的問題的工具。

然而不幸的是，要在整個機器學習棧中添加對一個新的深度學習框架的支持，既費資源，又費時間。已經花了大量時間來簡化這個過程。將現有深度學習框架之上的一個抽象層，提供一個統一的接口來運行深度學習模型。讓研究人員可以輕松地在自己選擇的框架中構建模型，簡化這些模型的生產化過程。

使用多種深度學習框架

深度學習的發展非常迅速，不同的深度學習框架在不同的任務上有效。因此，在過去的幾年里，使用過多種深度學習框架。2016 年，Caffe2 是主要的深度學習框架；2017 年集成 TensorFlow。這涉及到與 CUDA 和 cuDNN 的主要集成障礙、Caffe2 和 TensorFlow 的依賴沖突、庫加載問題等。2017 年，在 PyTorch 上開發更多的模型。這些模型本身需要大量的工作，而在與 TensorFlow 同時運行時，還發現內存損壞問題，以及幾個非常難以調試的問題。

圖 1. 利用不同的流行深度學習框架，發展機器學習

自 2018 年以來，有許多深度學習框架已經開源，包括
Ludwig、JAX、Trax、Flax、Haiku 和 RLax，其中許多框架都是最近兩年發布的。

即便研究人員可以很容易地試驗新框架，但在所有的系統和流程中添加對新深度學習框架的生產支持，也是一項艱巨的任務。需要對基礎設施和工具的每個部分逐一進行集成和優化。

圖 2. 添加對新框架的支持很困難，因為運行模型的每個基礎設施都需要支持所有框架。這些基礎設施組件可以是度量管道、模型服務或其生產和測試環境。

在2018 年末，開始構建多種模型，嘗試用不同的方式解決同一問題。例如，利用光學雷達進行 3D 目標檢測，可以采用范圍視圖或鳥瞰視圖。這兩種方法都是有效的，但各有優缺點。不同團隊構建的模型有時也在不同的框架中實現。

為了使生產化更容易，希望能夠輕松地替換解決相同問題的模型，即使是在不同的框架中實現的。

也會遇到一些其的情況，比如新的研究將基于 PyTorch 編寫代碼，但想要快速地與 TensorFlow 中的現有模型進行比較。因為每個模型都有特定于框架的、模型級的度量管道，所以比較就很難做到了。

為了在新框架中部署模型，需要重建模型級的度量管道，在所有的系統和流程中對框架進行集成，然后進行額外的優化，以確保能在延遲預算范圍內有效地運行模型。

雖然這些步驟看上去很簡單，但諸如上述問題（如內存損壞、依賴沖突等）導致耗費大量精力來解決，而不能專注于模型開發。

需要一種方法來最大程度地提高研究過程中的靈活性，而不必在過程的其部分重復工作。

軟件方案介紹

針對這一問題的解決方案，能使所有深度學習框架在運行模型時看起來都是一樣的。該框架在所有工具和基礎設施中添加對新框架的支持，就像將其添加到軟件中一樣簡單。

圖 3.一個抽象層，提供了一個統一的接口，可以基于多個框架運行深度學習模型。

軟件框架支持的框架包括：TensorFlow、PyTorch、Keras 和 TorchScript，同時也可以輕松地添加新的框架。

自2019 年初在內部發布以來，在快速部署新模型方面發揮了重要作用。在過去的一年里，已經在AI核心業務部署了數百個模型。這些模型包括需求預測模型、預計到達時間（Estimated time of arrival，ETA）預測、 Eats 的菜單轉錄以及用于自動駕駛汽車的目標檢測模型。

概述

從問題定義的概念開始：模型要解決的“問題”的形式化描述。在這種情況下，問題可能是圖像的語義分割或文本的語言翻譯。通過形式化地定義問題，可以將其視為一個接口，并抽象出具體的實現。每個模型都實現了一個問題定義。因此，解決相同問題的任何模型都是可互換的，即使使用不同的框架。

工作原理是將現有模型包裝在包中。此包包含原始模型以及元數據、測試數據和自定義操作（如果有的話）。

任何模型都能以任何支持的語言執行。例如，如果用戶想基于 C++ 運行 PyTorch 模型，將在后臺啟動一個 Python 解釋器，并與其通信來運行模型。這么做是必要的，因為 PyTorch 模型需要 Python 解釋器才能運行。這一功能允許在將 PyTorch 模型轉換為 TorchScript 之前進行快速測試，而 TorchScript 可以在 C++ 上直接運行。

目前支持基于 Python 和 C++ 運行模型。但是，為庫編寫額外的語言綁定也很簡單。例如，機器學習平臺 Michelangelo，使用框架作為其核心深度學習模型格式，并實現了 Go 綁定來從 Go 運行其生產模型。

圖 4.提供了特定于框架的封裝 API 和與框架無關的推理 API。

推理概述

在深入探討工作原理之前，讓先看看過去用傳統方法是如何將深度學習模型集成到應用程序中的：

圖 5. 應用程序在整個推理過程中直接與深度學習框架交互。

在上圖中，應用程序在推理過程中的所有部分都是直接與 TensorFlow API 進行交互的。

應用程序只與與框架無關的 API 進行交互（下面的所有紫色部分），并且將這些與框架無關的調用轉換為對底層框架的調用。盡可能使用零拷貝操作來高效地實現這一點。更多細節請參閱下面的“優化”部分。

圖 6.應用程序可以與框架無關的 API 進行交互，而與底層框架進行交互。

有一個可插拔的后端層，每個支持的框架都有自己的實現。這使得向添加新框架變得非常簡單。

進行深度學習

整個深度學習過程，以了解是如何幫助簡化實驗、部署和迭代的。

問題定義

要封裝，必須首先創建一個問題定義。如上所述，這是對試圖解決的問題的輸入和輸出的規范描述。這個定義包括所有輸入和輸出張量的名稱、數據類型和形狀。例如，2D 目標檢測的問題定義可能是類似下面這樣的：

上面的定義在形狀定義中使用了“符號”（num_classes 和 num_detections）。符號的每個實例都必須在運行時解析為相同的值。與僅將形狀元素設置為
None 相比，這提供了一種更可靠的約束形狀的方式。在上面的例子中，num_detections
跨 boxes 和object_class_probability
必須是相同的。

為簡單起見，將在本文中使用一個更簡單的問題：加法。

上面的代碼段還定義了測試輸入和輸出數據，將在下面討論。

生成占位符模型

一旦定義了問題，就可以自動生成一個占位符模型來實現問題規范。這允許在沒有實際模型的情況下開始集成。

生成的模型接受問題規范中描述的輸入，并返回與輸出規范匹配的隨機數據。

構建模型

在建立了問題定義（并可選地生成占位符模型）之后，就可以構建模型了。完成了構建和訓練模型的所有正常步驟，但現在在該過程的最后添加了一個導出步驟：

在上面的代碼段中，將模型導出，同時還提供了可選的測試數據。如果提供了測試數據，庫將在導出后立即對模型進行自檢。

Create_TensorFlow_Neuropod和所有其封裝程序的選項都有很好的文檔說明。

構建度量管道

現在有了自己的模型，就可以用 Python 為這個問題構建度量管道。與沒有框架的情況下做這件事的唯一區別是，使用Python
庫來運行模型，而不是使用特定于框架的 API。

文檔 包含有關 load_neuropod 和 infer 的更多詳細信息。

集成

現在，可以將模型集成到生產 C++ 系統中。下面的示例顯示了C++ API 的使用非常簡單，但該庫也支持更復雜的使用，支持高效的零拷貝操作和包裝現有內存。更多細節，請參考文檔。

與沒有 框架的集成過程不同的是，這個步驟對于每個問題只需執行一次，而不是每個框架執行一次。用戶無需理解 TensorFlow 或者 Torch C++ API 的復雜性，但當研究人員決定要使用哪種框架時，仍然可以提供很大的靈活性。

此外，由于核心 框架庫是用 C++ 編寫的，因此，可以為其各種編程語言（包括 Go、Java 等）編寫綁定。

優化

對延遲的要求相當嚴格，因此對許多關鍵操作都有零拷貝路徑。在分析和優化方面投入了大量工作，可以成為實現適用于所有模型的推理優化的核心位置。

作為這項工作的一部分，每個提交都在持續集成（CI）管道中的以下平臺上進行測試：

· Mac、Linux、Linux（GPU）

· Python 的五個版本

· 每個支持的深度學習框架的五個版本

要了解支持的平臺和框架的最新列表，請查看 文檔。

還提供了一種使用高性能共享內存橋在工作進程中運行模型的方法，這使得可以在不引入顯著延遲損失的情況下，將模型彼此隔離開來。將在本文末尾更詳細地討論這一點。

迭代

一旦構建并集成了模型的第一個版本，就可以迭代并改進解決方案。

作為這個過程的一部分，如果想嘗試用 TorchScript 模型來代替上面創建的 TensorFlow 模型，那就可以直接替換。

如果沒有集成框架，就將需要重新執行之前的許多步驟。有了集成框架，任何實現相同問題規范的模型都是可互換的。可以重用前面創建的度量管道以及之前做的所有集成工作。

所有運行模型的系統和流程都與框架無關，從而在構建模型時提供了更多的靈活性。讓用戶專注于試圖解決的問題，而不是用來解決問題的技術。

與問題無關的工具

盡管
Neuropod 是從關注一個“問題”開始的，比如給定圖像的 2D 目標檢測，文本的情感分析等等，但可以在 Neuropod 的基礎上構建一個與框架和問題均無關的工具。這讓能夠構建通用的基礎設施，可以用于任何模型。

規范輸入構建管道

Neuropod 的一個有趣的、與問題無關的用例是規范輸入構建管道。在 ATG，有一個已定義的格式 / 規范，用于說明如何以張量表示輸入數據。這涵蓋了傳感器數據，包括光學雷達、雷達、相機圖像以及其信息，如高分辨率地圖等。定義這種標準格式，使得在訓練方面管理超大型數據集變得輕松容易。這也使能夠快速構建新模型，因為許多模型都使用這些輸入數據的子集（例如，只對相機和光學雷達進行操作的模型）。

通過將這種通用輸入格式與 集成框架結合起來，可以構建一個單一的優化輸入構建管道，供所有的模型使用，而不管是在什么框架中實現的。

只要每個模型都使用同一組特性的子集，輸入構建器就與問題無關。輸入構建器中的任何優化都有助于改進所有的模型。

圖 7.允許構建單一的、優化的輸入構建管道，該管道可以與許多模型一起工作，而不必為每個模型或每個框架構建一個單獨的管道。

模型服務

另一個與問題無關的基礎設施是模型服務。有一些模型需要大量的輸入，而且模型本身也很大。對于部分模型，在諸如離線模擬之類的任務中在 CPU 上運行是不可行的。從資源效率的角度來看，在所有集群機器中包含 GPU 是沒有意義的，因此，提供了一種服務，可以讓用戶在遠程 GPU 上運行模型。這與基于 gRPC 的模型服務非常相似。

如果沒有集成框架，那么模型服務平臺就需要擅長遠程運行 Keras、遠程運行 TensorFlow、遠程運行 PyTorch、遠程運行 TorchScript 等。可能需要實現序列化、反序列化、與 C++ API 的交互，以及對每個框架的優化。所有的應用還需要擅長在本地運行所有這些框架的模型。

因為在本地和遠程運行有不同的實現，所以整個系統需要關注
2 * # of frameworks 情況。

通過使用集成框架，模型服務可以很好地遠程運行，可以很好地在多個框架中運行模型。

通過將關注點分開，系統必須關注的案例數量以相機啊的方式
(2 + # framworks)，而不是以乘積的方式增加。隨著越來越多的框架得到支持，這種差異就變得更加明顯。

不過，可以讓變得更強大。如果添加模型服務作為后端，任何基礎設施都可以輕松地遠程運行模型。

圖 8. 添加模型服務作為
后端，允許任何使用遠程運行模型的應用程序，而無需進行重大更改。

在后臺，可能看起來像這樣：

圖 9. 應用程序可以將模型執行代理到遠程機器。

這個解決方案不是特定于問題或特定于框架的，而是為使用應用程序提供了更大的靈活性。

進程外執行

圖 10.支持使用低延遲共享內存橋在獨立的工作進程中運行模型。

輸入通常很大，對延遲非常敏感，所以本地的 gRPC 并不是分離模型的理想方法。相反，可以使用優化的基于進程外執行（Out-of-process
Execution，OPE）的共享內存實現來避免復制數據。這讓可以將模型彼此隔離開來，而不會造成嚴重的延遲損失。

這種隔離很重要，已經看到過在統一進程中運行的框架之間存在沖突，包括微妙的 CUDA 錯誤和內存損壞。這些問題都很難追查。

在運行
Python 模型時，這種隔離也有助于提高性能，因為能讓用戶避免在所有模型之間共享 GIL。

在單獨的工作進程中運行每個模型還可以啟用“下一步”章節中提到的一些附加功能。

下一步

能夠快速構建和部署新的深度學習模型，但這僅僅是開始。

優化工作包括：

1. 版本選擇：該功能使用戶能夠在導出模型時，指定框架所需的版本范圍。例如，一個模型可能需要 TensorFlow 1.13.1，將使用正確版本的框架的 OPE 自動運行該模型。這使得用戶能夠在一個應用程序中使用多個框架和每個框架的多個版本。

2. 封裝操作：這個功能使應用程序能夠指定使用張量“完成”的時間。一旦張量被密封，可以在推理運行之前將數據異步傳輸到正確的目的地（例如本地的 GPU 或輔助進程等）。這有助于用戶并行化數據傳輸和計算。

3. Dockerized 工作進程：這樣可以在模型之間提供更多的隔離。例如，使用此功能，即使需要不同 CUDA 版本的模型也可以在同一應用程序中運行。

隨著繼續通過增強當前功能并引入新功能來擴展。

總結

以上是生活随笔為你收集整理的深度学习调用TensorFlow、PyTorch等框架的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。