摘要：它使用機(jī)器學(xué)習(xí)來(lái)解釋用戶提出的問題，并用相應(yīng)的知識(shí)庫(kù)文章來(lái)回應(yīng)。使用一類目前較先進(jìn)的機(jī)器學(xué)習(xí)算法來(lái)識(shí)別相關(guān)文章，也就是深度學(xué)習(xí)。接下來(lái)介紹一下我們?cè)谏a(chǎn)環(huán)境中配置模型的一些經(jīng)驗(yàn)。

我們?nèi)绾伍_始使用TensorFlow ?

在Zendesk，我們開發(fā)了一系列機(jī)器學(xué)習(xí)產(chǎn)品，比如的自動(dòng)答案（Automatic Answers）。它使用機(jī)器學(xué)習(xí)來(lái)解釋用戶提出的問題，并用相應(yīng)的知識(shí)庫(kù)文章來(lái)回應(yīng)。當(dāng)用戶有問題、投訴或者查詢時(shí)，他們可以在線提交請(qǐng)求。收到他們的請(qǐng)求后，Automatic Answers將分析請(qǐng)求，并且通過郵件建議客戶閱讀相關(guān)的可能最有幫助的文章。

Automatic Answers使用一類目前較先進(jìn)的機(jī)器學(xué)習(xí)算法來(lái)識(shí)別相關(guān)文章，也就是深度學(xué)習(xí)。 我們使用Google的開源深度學(xué)習(xí)庫(kù)TensorFlow來(lái)構(gòu)建這些模型，利用圖形處理單元（GPU）來(lái)加速這個(gè)過程。Automatic Answers是我們?cè)赯endesk使用Tensorflow完成的第一個(gè)數(shù)據(jù)產(chǎn)品。在我們的數(shù)據(jù)科學(xué)家付出無(wú)數(shù)汗水和心血之后，我們才有了在Automatic Answers上效果非常好的Tensorflow模型。

但是構(gòu)建模型只是問題的一部分，我們的下一個(gè)挑戰(zhàn)是要找到一種方法，使得模型可以在生產(chǎn)環(huán)境下服務(wù)。模型服務(wù)系統(tǒng)將經(jīng)受大量的業(yè)務(wù)。所以需要確保為這些模型提供的軟件和硬件基礎(chǔ)架構(gòu)是可擴(kuò)展的、可靠的和容錯(cuò)的，這對(duì)我們來(lái)說(shuō)是非常重要的。接下來(lái)介紹一下我們?cè)谏a(chǎn)環(huán)境中配置TensorFlow模型的一些經(jīng)驗(yàn)。

順便說(shuō)一下我們的團(tuán)隊(duì)——Zendesk的機(jī)器學(xué)習(xí)數(shù)據(jù)團(tuán)隊(duì)。我們團(tuán)隊(duì)包括一群數(shù)據(jù)科學(xué)家、數(shù)據(jù)工程師、一位產(chǎn)品經(jīng)理、UX /產(chǎn)品設(shè)計(jì)師以及一名測(cè)試工程師。

Data Team At Zendesk Melbourne

TensorFlow模型服務(wù) ?

經(jīng)過數(shù)據(jù)科學(xué)家和數(shù)據(jù)工程師之間一系列的討論，我們明確了一些核心需求：

預(yù)測(cè)時(shí)的低延遲

橫向可擴(kuò)展

適合我們的微服務(wù)架構(gòu)

可以使用A/B測(cè)試不同版本的模型

可以與更新版本的TensorFlow兼容

支持其他TensorFlow模型，以支持未來(lái)的數(shù)據(jù)產(chǎn)品

TensorFlow Serving ?

經(jīng)過網(wǎng)上的調(diào)研之后，Google的TensorFlow Serving成為我們推薦的模型服務(wù)。TensorFlow Serving用C++編寫，支持機(jī)器學(xué)習(xí)模型服務(wù)。開箱即用的TensorFlow Serving安裝支持：

TensorFlow模型的服務(wù)

從本地文件系統(tǒng)掃描和加載TensorFlow模型

（小編注：TensorFlow和TensorFlow Serving的區(qū)別：TensorFlow項(xiàng)目主要是基于各種機(jī)器學(xué)習(xí)算法構(gòu)建模型，并為某些特定類型的數(shù)據(jù)輸入做適應(yīng)學(xué)習(xí)，而TensorFlow Serving則專注于讓這些模型能夠加入到產(chǎn)品環(huán)境中。開發(fā)者使用TensorFlow構(gòu)建模型，然后TensorFlow Serving基于客戶端輸入的數(shù)據(jù)使用前面TensorFlow訓(xùn)練好的模型進(jìn)行預(yù)測(cè)。）

TensorFlow Serving將每個(gè)模型視為可服務(wù)對(duì)象。它定期掃描本地文件系統(tǒng)，根據(jù)文件系統(tǒng)的狀態(tài)和模型版本控制策略來(lái)加載和卸載模型。這使得可以在TensorFlow Serving繼續(xù)運(yùn)行的情況下，通過將導(dǎo)出的模型復(fù)制到指定的文件路徑，而輕松地?zé)岵渴鸾?jīng)過訓(xùn)練的模型。

? ?

TensorFlow Serving Architecture

根據(jù)這篇Google博客中報(bào)告的基準(zhǔn)測(cè)試結(jié)果，他們每秒記錄大約100000個(gè)查詢，其中不包括TensorFlow預(yù)測(cè)處理時(shí)間和網(wǎng)絡(luò)請(qǐng)求時(shí)間。

有關(guān)TensorFlow Serving架構(gòu)的更多信息，請(qǐng)參閱TensorFlow Serving文檔。

通信協(xié)議（gRPC） ?

TensorFlow Serving提供了用于從模型調(diào)用預(yù)測(cè)的gRPC接口。gRPC是一個(gè)開源的高性能遠(yuǎn)程過程調(diào)用（remote procedure call，RPC）框架，它在HTTP/2上運(yùn)行。與HTTP/1.1相比，HTTP/2包含一些有趣的增強(qiáng)，比如它對(duì)請(qǐng)求復(fù)用、雙向流和通過二進(jìn)制傳輸?shù)闹С?，而不是文本?/p>

默認(rèn)情況下，gRPC使用Protocol Buffers (Protobuf)作為其信息交換格式。Protocol Buffers是Google的開源項(xiàng)目，用于在高效的二進(jìn)制格式下序列化結(jié)構(gòu)化數(shù)據(jù)。它是強(qiáng)類型，這使它不容易出錯(cuò)。數(shù)據(jù)結(jié)構(gòu)在.proto文件中指定，然后可以以各種語(yǔ)言（包括Python，Java和C ++）將其編譯為gRPC請(qǐng)求類。 這是我第一次使用gRPC，我很想知道它與其他API架構(gòu)（如REST）相比誰(shuí)性能更好。

模型訓(xùn)練和服務(wù)架構(gòu) ?

我們決定將深度學(xué)習(xí)模型的訓(xùn)練和服務(wù)分為兩個(gè)管道。下圖是我們的模型訓(xùn)練和服務(wù)架構(gòu)的概述：

Model Training and Serving Architecture

模型訓(xùn)練管道

模型訓(xùn)練步驟：

我們的訓(xùn)練特征是從Hadoop中提供的數(shù)據(jù)生成的。

生成的訓(xùn)練特征保存在AWS S3中。

然后使用AWS中的GPU實(shí)例和S3中的批量訓(xùn)練樣本訓(xùn)練TensorFlow模型。

一旦模型被構(gòu)建并驗(yàn)證通過，它將被發(fā)布到S3中的模型存儲(chǔ)庫(kù)。

模型服務(wù)管道

驗(yàn)證的模型在生產(chǎn)中通過將模型從模型庫(kù)傳送到TensorFlow Serving實(shí)例來(lái)提供。

基礎(chǔ)結(jié)構(gòu) ?

我們?cè)贏WS EC2實(shí)例上運(yùn)行TensorFlow Serving。Consul在實(shí)例之前設(shè)置，用于服務(wù)發(fā)現(xiàn)和分發(fā)流量。客戶端連接從DNS查找返回的第一個(gè)可用IP?；蛘邚椥载?fù)載平衡可用于更高級(jí)的負(fù)載平衡。由于TensorFlow模型的預(yù)測(cè)本質(zhì)上是無(wú)狀態(tài)操作，所以我們可以通過旋轉(zhuǎn)加速更多的EC2實(shí)例 來(lái)實(shí)現(xiàn)橫向可擴(kuò)展性。

另一個(gè)選擇是使用Google Cloud平臺(tái)提供的Cloud ML，它提供TensorFlow Serving作為完全托管服務(wù)。 但是，當(dāng)我們?cè)诖蟾?016年9月推出TensorFlow Serving時(shí)，Cloud ML服務(wù)處于alpha階段，缺少生產(chǎn)使用所需的功能。因此，我們選擇在我們自己的AWS EC2實(shí)例中托管，以實(shí)現(xiàn)更精細(xì)的粒度控制和可預(yù)測(cè)的資源容量。

模型服務(wù)的實(shí)現(xiàn) ?

下面是我們實(shí)現(xiàn)TensorFlow Serving部署和運(yùn)行所采取的步驟：

1.從源編譯TensorFlow Serving

首先，我們需要編譯源代碼來(lái)產(chǎn)生可執(zhí)行的二進(jìn)制文件。然后就可以從命令行執(zhí)行二進(jìn)制文件來(lái)啟動(dòng)服務(wù)系統(tǒng)。

假設(shè)你已經(jīng)配置好了Docker，那么一個(gè)好的開端就是使用提供的Dockerfile來(lái)編譯二進(jìn)制文件。請(qǐng)按照以下步驟：

運(yùn)行該gist中的代碼以構(gòu)建適合編譯TensorFlow Serving的docker容器。

在正在運(yùn)行的docker容器中運(yùn)行該gist中的代碼以構(gòu)建可執(zhí)行二進(jìn)制文件。

一旦編譯完成，可執(zhí)行二進(jìn)制文件將在你的docker鏡像的以下路徑中：/work/serving/bazel-bin/tensorflow_serving/model_servers/tensorflow_model_server

2.運(yùn)行模型服務(wù)系統(tǒng)

上一步生成的可執(zhí)行二進(jìn)制文件（tensorflow_model_server）可以部署到您的生產(chǎn)實(shí)例中。 如果您使用docker編排框架（如Kubernetes或Elastic Container Service），您還可以在docker容器中運(yùn)行TensorFlow Serving。

現(xiàn)在假設(shè)TensorFlow模型存儲(chǔ)在目錄/work/awesome_model_directory下的生產(chǎn)主機(jī)上。你可以在端口8999上使用以下命令來(lái)運(yùn)行TensorFlow Serving和你的TensorFlow模型：

/tensorflow_model_server — port=8999 — model_base_path=/work/awesome_model_directory

默認(rèn)情況下，TensorFlow Serving會(huì)每秒掃描模型基本路徑，并且可以自定義。此處列出了可作為命令行參數(shù)的可選配置。

3.從服務(wù)定義（Service Definitions）生成Python gRPC存根

下一步是創(chuàng)建可以在模型服務(wù)器上進(jìn)行預(yù)測(cè)的gRPC客戶端。這可以通過編譯.proto文件中的服務(wù)定義，從而生成服務(wù)器和客戶端存根來(lái)實(shí)現(xiàn)。.proto文件在TensorFlow Serving源碼中的tensorflow_serving_apis文件夾中。在docker容器中運(yùn)行以下腳本來(lái)編譯.proto文件。運(yùn)行提交版本號(hào)為46915c6的腳本的示例：

./compile_ts_serving_proto.sh 46915c6

運(yùn)行該腳本后應(yīng)該在tensorflow_serving_apis目錄下生成以下定義文件：

model_pb2.py

predict_pb2.py

prediction_service_pb2.py

你還可以使用grpc_tools Python工具包來(lái)編譯.proto文件。

4.從遠(yuǎn)程主機(jī)調(diào)用服務(wù)

可以使用編譯后的定義來(lái)創(chuàng)建一個(gè)python客戶端，用來(lái)調(diào)用服務(wù)器上的gRPC調(diào)用。比如這個(gè)例子用一個(gè)同步調(diào)用TensorFlow Serving的Python客戶端。

如果您的用例支持異步調(diào)用預(yù)測(cè)，TensorFlow Serving還支持批處理預(yù)測(cè)以達(dá)到性能優(yōu)化的目的。要啟用此功能，你應(yīng)該運(yùn)行tensorflow_model_server同時(shí)開啟flag?—enable_batching。這是一個(gè)異步客戶端的例子。

從其他存儲(chǔ)加載模型

如果你的模型沒有存儲(chǔ)在本地系統(tǒng)中應(yīng)該怎么辦？你可能希望TensorFlow Serving可以直接從外部存儲(chǔ)系統(tǒng)（比如AWS S3和Google Storage）中直接讀取。

如果是這種情況，你將需要通過Custom Source來(lái)拓展TensorFlow Serving以使其可以讀取這些源。TensorFlow Serving僅支持從文件系統(tǒng)加載模型。

一些經(jīng)驗(yàn) ?

我們?cè)诋a(chǎn)品中已經(jīng)使用TensorFlow Serving大概半年的時(shí)間，我們的使用體驗(yàn)是相當(dāng)平穩(wěn)。它具有良好的預(yù)測(cè)時(shí)間延遲。以下是我們的TensorFlow Serving實(shí)例一周內(nèi)的預(yù)測(cè)時(shí)間（以秒為單位）的第95百分位數(shù)的圖（約20毫秒）：

然而，在生產(chǎn)中使用TensorFlow Serving的過程中，我們也有一些經(jīng)驗(yàn)教訓(xùn)可以跟大家分享。

1.模型版本化

到目前為止，我們已經(jīng)在產(chǎn)品中使用了幾個(gè)不同版本的TensorFlow模型，每一個(gè)版本都有不同的特性，比如網(wǎng)絡(luò)結(jié)構(gòu)、訓(xùn)練數(shù)據(jù)等。正確處理模型的不同版本已經(jīng)是一個(gè)重要的任務(wù)。這是因?yàn)閭鬟f到TensorFlow Serving的輸入請(qǐng)求通常涉及到多個(gè)預(yù)處理步驟。這些預(yù)處理步驟在不同TensorFlow模型版本下是不同的。預(yù)處理步驟和模型版本的不匹配可能導(dǎo)致錯(cuò)誤的預(yù)測(cè)。

1a.明確說(shuō)明你想要的版本

我們發(fā)現(xiàn)了一個(gè)簡(jiǎn)單但有用的防止錯(cuò)誤預(yù)測(cè)的方法，也就是使用在model.proto定義中指定的版本屬性，它是可選的（可以編譯為model_pb2.py）。這樣可以始終保證你的請(qǐng)求有效負(fù)載與預(yù)期的版本號(hào)匹配。

當(dāng)你請(qǐng)求某個(gè)版本（比如從客戶端請(qǐng)求版本5），如果TensorFlow Serving服務(wù)器不支持該特定版本，它將返回一個(gè)錯(cuò)誤消息，提示找不到模型。

1b.服務(wù)多個(gè)模型版本

TensorFlow Serving默認(rèn)的是加載和提供模型的版本。當(dāng)我們?cè)?016年9月首次應(yīng)用TensorFlow Serving時(shí)，它不支持同時(shí)提供多個(gè)模型。這意味著在指定時(shí)間內(nèi)它只有一個(gè)版本的模型。這對(duì)于我們的用例是不夠的，因?yàn)槲覀兿Ｍ?wù)多個(gè)版本的模型以支持不同神經(jīng)網(wǎng)絡(luò)架構(gòu)的A / B測(cè)試。

其中一個(gè)選擇是在不同的主機(jī)或端口上運(yùn)行多個(gè)TensorFlow Serving進(jìn)程，以使每個(gè)進(jìn)程提供不同的模型版本。這樣的話就需要：

用戶應(yīng)用程序（gRPC客戶端）包含切換邏輯，并且需要知道對(duì)于給定的版本需要調(diào)用哪個(gè)TensorFlow Serving實(shí)例。這增加了客戶端的復(fù)雜度，所以不是推薦。

一個(gè)可以將版本號(hào)映射到TensorFlow Serving不同實(shí)例的注冊(cè)表。

更理想的解決方案是TensorFlow Serving可以支持多個(gè)版本的模型。

所以我決定使用一個(gè)“l(fā)ab day”的時(shí)間來(lái)擴(kuò)展TensorFlow Serving，使其可以服務(wù)多個(gè)版本的時(shí)間。在Zendesk，“l(fā)ab day”就是我們可以每?jī)芍苡幸惶斓臅r(shí)間來(lái)研究我們感興趣的東西，讓它成為能夠提高我們?nèi)粘Ｉa(chǎn)力的工具，或者一種我們希望學(xué)習(xí)的新技術(shù)。我已經(jīng)有8年多沒有使用C++代碼了。但是，我對(duì)TensorFlow Serving代碼庫(kù)的可讀性和整潔性印象深刻，這使其易于擴(kuò)展。支持多個(gè)版本的增強(qiáng)功能已經(jīng)提交，并且已經(jīng)合并到主代碼庫(kù)中。

TensorFlow Serving維護(hù)人員對(duì)補(bǔ)丁和功能增強(qiáng)的反饋非常迅速。從的主分支，你可以啟動(dòng)TensorFlow Serving，用model_version_policy中附加的flag來(lái)服務(wù)多個(gè)模型版本：

/work/serving/bazel-bin/tensorflow_serving/model_servers/tensorflow_model_server — port=8999 — model_base_path=/work/awesome_model_directory — model_version_policy=ALL_VERSIONS

一個(gè)值得注意的要點(diǎn)是，服務(wù)多個(gè)模型版本，需要權(quán)衡的是更高的內(nèi)存占用。所以上述的flag運(yùn)行時(shí)，記住刪除模型基本路徑中的過時(shí)模型版本。

2.活用壓縮

當(dāng)你部署一個(gè)新的模型版本的時(shí)候，建議在復(fù)制到model_base_path之前，首先將導(dǎo)出的TensorFlow模型文件壓縮成單個(gè)的壓縮文件。Tensorflow Serving教程中包含了導(dǎo)出訓(xùn)練好的Tensorflow模型的步驟。導(dǎo)出的檢查點(diǎn)TensorFlow模型目錄通常具有以下文件夾結(jié)構(gòu)：

一個(gè)包含版本號(hào)（比如0000001）和以下文件的父目錄：

saved_model.pb：序列化模型，包括模型的圖形定義，以及模型的元數(shù)據(jù)（比如簽名）。

variables：保存圖形的序列化變量的文件。壓縮導(dǎo)出的模型：

tar -cvzf modelv1.tar.gz 0000001

為什么需要壓縮？

壓縮后轉(zhuǎn)移和復(fù)制更快

如果你將導(dǎo)出的模型文件夾直接復(fù)制到model_base_path中，復(fù)制過程可能需要一段時(shí)間，這可能導(dǎo)致導(dǎo)出的模型文件已復(fù)制，但相應(yīng)的元文件尚未復(fù)制。如果TensorFlow Serving開始加載你的模型，并且無(wú)法檢測(cè)到源文件，那么服務(wù)器將無(wú)法加載模型，并且會(huì)停止嘗試再次加載該特定版本。

3.模型大小很重要

我們使用的TensorFlow模型相當(dāng)大，在300Mb到1.2Gb之間。我們注意到，在模型大小超過64Mb時(shí)，嘗試提供模型時(shí)將出現(xiàn)錯(cuò)誤。這是由于protobuf消息大小的硬編碼64Mb限制，如這個(gè)TensorFlow Serving在Github上的問題所述。

最后，我們采用Github問題中描述的補(bǔ)丁來(lái)更改硬編碼的常量值。（這對(duì)我們來(lái)說(shuō)還是一個(gè)問題。如果你可以找到在不改變硬編碼的情況下，允許服務(wù)大于64Mb的模型的替代方案，請(qǐng)聯(lián)系我們。）

4.避免將源移動(dòng)到你自己的分支下

從實(shí)現(xiàn)時(shí)開始，我們一直從主分支構(gòu)建TensorFlow Serving源，的版本分支（v0.4）在功能和錯(cuò)誤修復(fù)方面落后于主分支。因此，如果你只通過檢查主分支來(lái)創(chuàng)建源，一旦新的更改被合并到主分支，你的源也可能改變。為了確保人工制品的可重復(fù)構(gòu)建，我們發(fā)現(xiàn)檢查特定的提交修訂很重要：

TensorFlow Serving

TensorFlow（TensorFlow Serving里的Git子模塊）

期待未來(lái)加入的一些功能增強(qiáng)清單 ?

這里是一些我們比較感興趣的希望以后TensorFlow Serving會(huì)提供的功能：

健康檢查服務(wù)方法

一個(gè)TensorFlow Serving實(shí)例可以支持多種模型類型

直接可用的分布式存儲(chǔ)（如AWS S3和Google存儲(chǔ)）中的模型加載

直接支持大于64Mb的模型

不依賴于TensorFlow的Python客戶端示例

商業(yè)智能與數(shù)據(jù)分析群

興趣范圍包括各種讓數(shù)據(jù)產(chǎn)生價(jià)值的辦法，實(shí)際應(yīng)用案例分享與討論，分析工具，ETL工具，數(shù)據(jù)倉(cāng)庫(kù)，數(shù)據(jù)挖掘工具，報(bào)表系統(tǒng)等全方位知識(shí)

QQ群：81035754