全文共3510字，預計學習時長
7分鐘
圖片來源：unsplash.com/@thoughtcatalog
本文將介紹一款基於OpenAI的新NLP文本編寫APP——GPT-2，旨在隨時隨地和用戶一起寫作。
這是一款全新的創造性文本編輯器APP。與傳統文本編輯器不同，這款APP的NLP模型可以完成用戶要求的句子，併為“用機器寫作”帶來全新的維度。該APP基於GPT-2（OpenAI的語言模型），可以生成在語法意義上準確無誤的句子和連貫的文字段落。
在GPT-2的幫助下講故事
該演示現已在https://transformer.huggingface.co上發佈。
用transformer寫作就像用計算器寫微積分。
這個模型是NLP最新趨勢的一部分，在對特定任務進行微調時，該模型用於創建大型的語言模型，從而使各項任務圓滿完成。這使得具有大量參數（GPT-2 Large或Grover的參數多達15億個）的Transformer模型由於其重量而很難處理。
APP為用戶提供兩種型號：小型GPT-2和中型GPT-2。兩種型號同時加載到計算機的RAM中共需2.4 GB內存。
當前存在的問題
注意：這裡的方法針對無法執行批量推理的模型。對於可以進行批量推理的模型，如我們使用的模型，可能不需要顯示的解決方法。
這個APP設置了一些限制，以便用戶擁有愉悅的使用感。如反應時間要儘可能短，並生成足夠長的句子。每次運行時，系統必須提供幾種可能的結果，以便用戶從中做出選擇，這會使生成的數據量增加兩倍之多。因此，該APP的目標是儘可能優化計算，利用GPU高度並行性的特點創建工作流程。
設置工作區
構建一個服務器端API，與前端APP連接。該API將負責處理生成句子所需的計算。因為大多數NLP模型都是現成的，所以使用Python來完成這項任務。其他低級語言（如C++或Rust）更適合以性能為導向的後端。
使用falcon（https://falconframework.org/）作為Web服務器（任何其他HTTP框架也可以使用），與gunicorn（https://gunicorn.org/）一起運行實例並平衡負載。GPT-2 Pytorch（https://github.com/huggingface/pytorch-pretrained-BERT）運行是該項目的支柱。如果你對類似的例子感興趣，可參見示例目錄（https://github.com/huggingface/pytorch-pretrained-BERT/tree/master/examples）中的一些示例。
Gunicorn可以設立獨立運行APP的“workers”，有效平衡不同worker的負載。可以參見官方的Gunicorn文檔（http://docs.gunicorn.org/en/stable/design.html），精確瞭解它們是如何工作的。
三種方式自動完成
在每次自動完成的請求中，我們都希望API可能生成三個不同的句子。這些句子將呈現給終端用戶，最終用戶將在三者中選擇一個。這是設計的重要部分，API必須反映這一點。這三個句子應該同時出現，每次自動完成後，最好只向服務器發送一個請求。
最簡單的方法是使用在後臺加載模型的單個worker：
Naïve API
使用這種體系結構，每個請求都將按順序處理，並且模型將被提示，在響應傳入請求之前生成三個不同的句子。
可以通過添加更多工作人員來輕鬆擴展此基礎架構，同時牢記：每個工作人員會根據GPU的使用情況在RAM或VRAM中加載模型。
Multi-worker naïve API
使用這種方法意味著加載模型並對其進行操作的過程，以請求生成三個不同的句子。如果模型能執行批量推理，就可以一次生成三個句子。但是，如果不能執行批量推理，則需要單獨生成每個句子——從而導致三次模型迭代。因為批量推斷需要一些更具設計性的方法，所以後面將考慮其無法進行的情況。
在計算自動完成的最短響應時間時，最好將這三個迭代並行化。幸運的是，Python使用戶可以訪問在場景中使用的幾個並行化選項：
· 多線程（線程）
· 多進程（子進程或多進程）
· 不同的Web服務器作為一種多處理形式
多線程
傳送門：https://docs.python.org/3/library/threading.html
Python中的多線程通常使用線程類來完成，該線程允許程序創建多個線程，每個線程都會繼續執行各自的操作。多線程的問題在於Global Interpreter Lock ( GIL ) 在Python中的工作方式。
如果一個線程訪問某個模型對象，那麼在第一個線程完成處理之前，其他線程無法訪問該對象。因為三個迭代將按順序處理，所以這種方法類似於在執行過程中根本不使用任何線程。唯一的性能差異將是開始或者連接每個線程所花費的額外時間，不利於實現目標。
如果真的想要使用線程，可以將三個不同的模型加載到RAM中，每個單獨的線程使用一個模型。但本文並沒有選擇那樣做，下面將做出進一步解釋。
多進程
多進程有兩種方式：通過啟動完全獨立的進程並連接到它們的輸入或輸出（使用子進程模塊）（https://docs.python.org/3/library/subprocess.html）或者生成可以繼承當前Python解釋器進程資源的python進程（使用多進程模塊可繞過GIL問題）（https://docs.python.org/3.4/library/multiprocessing.html）。
這裡，一個棘手的部分是如何確保模型不必每次計算推理時都加載到RAM中；大型模型需要很長時間才能加載到內存中。
可以選擇採用另一種不同的方法。
使用gunicorn負載平衡
該方法的不同之處在於使用gunicorn worker的功能來平行工作。為此，在之前的模型中需添加另一個層。先前定義的體系結構可以接收多個請求，並在幾個worker中同時處理這些請求。將此當作優勢。最終模型如下。
最終有兩個不同型號的Falcon或Gunicorn服務器
當請求從前端APP發送到API時，它將由第一個Web服務器處理。該Web服務器中會有一個運行API的工作程序。此API負責向第二個Web服務器發送三個相同的請求。API發送的請求包含當前上下文（文檔中的前一個句子）以及一些有關參數信息（小型或中型模型，特定top_k值等等）。
第二個Web服務器中有多個worker分別處理請求。三個worker將同時分別處理從API收到的各個請求。在API中使用單獨線程，以便將請求並行發送到第二個Web服務器而不是順序發送（HTTP請求 - >沒有GIL問題）。
此體系結構具有其他先前提到的方法所不具備的幾個優勢：
· 可以生成儘可能多的worker，只要模型的數量能適合人類記憶。如果有一個分佈式系統，可以將worker分佈到不同的GPU中。
· 每個worker在內存中加載一個模型。因此，與每次加載三個模型相比，可能會加載更多模型（更多的計算能力），例如線程方法。
· 作為Web服務器的worker，模型將始終保持在內存中。
· 架構中的每一步都使用了gunicorn的負載平衡。並不是要簡單地產生並行運行進程，要想辦法確保每個進程處理與其計算能力相關的負載。如果使用兩個具有不同計算能力的GPU，而擁有較低計算能力的GPU所造成的瓶頸對另一個GPU的影響不會像在純多進程程序中那樣大。
圖2顯示了在初始化期間以及向API發送兩個併發請求時，體系結構在內存管理方面的表現。
初始化和併發行為
結果
不出所料，與初始順序系統相比，使用並行系統時，響應時間方面有了很大改進。對一個需要在三個模型迭代中分解的請求進行基準測試，只需三分之一的初始響應時間，實際的本地HTTP請求只需要幾百微秒。
該系統特別適用於垂直擴展，因為它能適應系統的內存和計算能力。但是，它不能與可以執行批量推理的模型進行比較，因為這種方法將在內存中存儲三個模型，而如果使用批量推理，則只能存儲一個模型。
進一步改進
這個系統是為在機器上運行而設計的，所以沒有考慮集裝箱化或水平擴展。對於需要處理10萬用戶的完整生產系統而言，這廣受歡迎，也必不可少。
另一項改進是使用TorchScript模塊。由於在模型中使用了pytorch，所以可以看到它的torchscript版本，在任何編程語言中進行推理。因此，如果想得到最大限度優化，可以用一種非常低級的語言優化一個更好的、更合適的Web服務器。
這個系統已經證明其價值，因為它在4-GPU(K80)機器上運行時，一週之內處理了超過100,000個不同的請求。
我們一起分享AI學習與發展的乾貨
閱讀更多 讀芯術 的文章
