由於模型訓練完之後需要上線部署，這個過程中需要將模型整合到當前的軟體架構中，因此要根據軟體架構考慮模型的實際部署方法。目前來看主流的部署方法有以下幾種方案：

1.python服務介面

在python伺服器上部署模型檔案，給出一個http服務，後臺通過這個服務就可以呼叫模型進行輸入輸出了。

優點：演算法與後端的工作界限明顯，不需要特別多的溝通；在使用模型前還需要進行資料預處理，不需要額外再進行程式碼遷移。

缺點：需要伺服器安裝python環境，維護的成本增加，伺服器之間介面的通訊問題，獲取模型輸出所需時間可能更長。

2.java直接載入模型

目前工業界比較成熟的部署方案就是使用tensorflow的java包，然後載入訓練的模型檔案。

需要事先將模型檔案儲存成pb格式，然後在java的環境中新增依賴。最後再載入模型。

優點：不需要額外的介面，呼叫方便；不需要額外安裝python環境

缺點：需要將資料預處理這部分程式碼遷移成java，並新增到後端專案程式碼中。另外google對這種方法重視不高，沒有詳細的文件，也很少更新維護程式碼。模型預測速度和調python介面差不多。

3.docker+tf-serving部署模型

這個是google比較推薦的部署方法，部署文件比較詳細。也是廣泛使用的方法。這種方法直接將模型部署在docker容器中，然後提供兩種介面，分別是Grpc介面和http介面，前者據說是在讀取批量資料上更有優勢，例如圖片資料；服務啟動後只要可以連線，任何語言都可以呼叫。

優點：部署方便，不受伺服器限制；可以同時部署多個模型，方便模型的管理和版本控制；模型推理的速度快，經過測試比前兩種快2倍。

缺點：同樣需要編寫資料預處理程式碼，資料輸入格式需要按文件的要求。

綜上所述，目前幾種部署方案都可以使用，需要根據實際情況靈活選擇合適的方法。個人覺得如果是比較規範的平臺化部署可以用tf-serving；如果只是比較小的功能，不需要太多的後續維護的模型1和2都可以。

從蒐集的資料上看，由於對模型推理速度的效能要求越來越高，例如bert這種引數上億的模型，目前使用gpu環境部署模型的場景越來越多，Nvidia的tensorRT也有越來越多人開始嘗試，據說比tf-serving的推理速度更快。