對於機器學習，樂觀的人認爲其可能完成人類級別的任務，比如開車、接電話、預約會議、回覆郵件等。但現實是機器學習只不過解決了狹窄範圍內的問題，比如視頻推薦、商品推薦和估算到達時間。然而，當 OpenAI 發佈 GPT-2 時，這一差距開始縮小。
本文最初發布在 TowardsDataScience 博客，經原作者 Caleb Kaise r授權，InfoQ 中文站翻譯並分享。
對於OpenAI 構建的通用語言模型GPT-2，該領域的開發者都不陌生。通過簡單增加模型大小，GPT-2有15 億個參數，是 ELMo 的 10 倍以上，而以前最好的 Transformer模型只有9360萬個參數。
在這之後，模型是越來越大，各大公司就好像達成了共識一般，以致於開發者很難部署。
在GPT-2發佈後不久，Salesforce 即發佈了 CTRL，這是一個擁有 16 億參數的語言模型。
NVIDIA 也打造了一個擁有 80 億參數的Transformer 模型Megatron。
最近，谷歌發佈了新的會話模型 Meena，它擁有 26 億個參數。
即使在計算機視覺領域，要獲得更好性能的途徑也是通過更大的模型來實現的。此前，谷歌發佈了NASNet，這是一個打破紀錄的圖像分類模型，擁有 8890 萬個參數，比當時其他任何主要的圖像分類模型都要大，能夠識別圖像中的物體。
趨勢很明顯。爲了實現人類對機器學習驅動未來的美好願景，這些“超級模型”將會變得越來越大。如此一來，只有一個問題：
模型實在太大，無法在生產環境中使用。
模型太大，部署困難
隨着模型規模不斷擴大，將其部署到生產中變得越來越棘手。以 GPT-2 爲例：
- GPT-2 大小超過 5GB。在這種規模的情況下，根本無法將模型以本地形式嵌入到應用程序中（而這是移動軟件通常使用機器學習的方式）。
- GPT-2 需要大量算力。爲了服務於單個預測，GPT-2 會以 100% 的利用率佔用 CPU 長達數分鐘。就算有 GPU 的加持，單個預測仍然也需要數秒鐘的時間。與此相比，Web 應用可以在一個 GPU 上爲數百個併發用戶提供服務。
- GPT-2 需要大量內存。除了可觀的磁盤空間和算力需求之外，GPT-2 還需要大量內存才能在不崩潰的情況下運行。
換言之，GPT-2 就是一個龐大的、資源密集型的、速度緩慢的系統。將它投入生產就已經是一個挑戰了，再對其進行擴展就更加困難了。這些問題還不是 GPT-2 獨有的，所有超級模型都存在這些問題。而且，隨着模型變得更大，情況只會變得更糟，不會變得更好。幸運的是，在機器學習生態系統中，有一些項目正在努力克服這一障礙。
解決超級模型部署難題
雖說目前尚處起步階段，但還是爲解決問題提供了可行的思路。
1. 縮小模型
如果模型太大，爲什麼不壓縮它們？要做到這一點，一種方法是通過“知識蒸餾”（knowledge distillation）。這一想法是，一個小型模型可以通過學習來模仿大型模型（即父模型）的性能。
譯註：知識蒸餾（knowledge distillation）是一種模型壓縮常見方法，用於模型壓縮指的是在 teacher-student 框架中，將複雜、學習能力強的網絡學到的特徵表示“知識”蒸餾出來，傳遞給參數量小、學習能力弱的網絡。
換句話說，訓練 GPT-2 需要向其饋入高達 40GB 的文本，這相當於大約 27118520 頁的文本文件。然而，訓練一個蒸餾過的 GPT-2 模型只需向其饋入 GPT-2 的輸出即可。
著名的 Transformer NLP 庫背後的 HuggingFace 公司就是這樣做的，創建了 DistilGPT2。雖然與完整的 GPT-2 模型相比，DistilGPT2 在一些質量基準上的得分要低一些，但它比完整的 GPT-2 模型小了 33%，速度快了一倍。
速度能提高兩倍，可不是一件小事。對自動駕駛汽車來說，安全剎車和輕微碰撞之間的區別就在於此。對於一個會話智能體來說，這就是自然談話和令人惱火的機器人電話之間的區別。
2. 將模型部署到雲端
就算用了知識蒸餾，模型仍然可能很龐大。超過 25GB 的模型（NVIDIA 的 Megatron 是 GPT-2 的 5.6 倍）儘管縮小了 33%，但仍然很龐大。
在這種規模下，我們用來消費機器學習生成內容的設備，我們的手機、電視，甚至電腦，都無法承載這些模型，它們根本就不合適。
一種解決方案是將模型作爲微服務部署到雲端，我們的設備就可以根據需要進行查詢。這稱爲“實時推理”（Realtime inference），是在生產中部署大型模型的標準方法。
然而，在雲端部署也有自身的問題，尤其是在規模方面。舉個例子，我們可以看看AI Dungeon，這是一款流行的基於 GPT-2 的冒險遊戲。
由於 GPT-2 的大小和算力需求所限，AI Dungeon 只能爲單個部署模型中的幾個用戶提供服務。爲了應對流量的增加，AI Dungeon 需要具備自動擴展的能力。
水平擴展 GPT-2 部署是一件非常棘手的事。它需要：
- 確保每個部署都是相同的。例如，使用 Docker 對模型進行容器化，並使用 Kubernetes 對容器進行編排。
- 自動擴展部署。例如，通過配置雲供應商的自動擴展程序，根據流量自動向上或向下旋轉實例。
- 優化資源。這意味着需要在不犧牲性能的情況下，找到並運行最便宜的實例類型和資源分配。
如果做錯了，你可能很容易會得到一筆巨大的雲計算賬單：部署 200 個 g4dn.2xlarge 的成本每小時高達 150.40 美元，或者你發現自己的預測服務 API 經常崩潰。
換句話說，要爲大型模型提供服務，目前需要對 DevOps 有相當多的瞭解，而且還要求大多數數據科學家不能同時是基礎設施工程師。
幸運的是，有一些項目正在努力消除這一瓶頸，類似Cortex 這樣的開源項目，即 AI Dungeon 基礎設施背後的項目，作爲自動化部署大型模型所需的 DevOps 工作的工具，已經吸引了開發者的關注：
3. 加速硬件服務模式
最後一項使大型模型變得更容易的努力，與模型本身並沒有任何關係。相反，它必須與改進硬件有關。
更大的模型在更好的硬件上，性能更優。事實上，GPU 對模型服務很重要，爲 GPT-2 提供自動更正低延遲服務的唯一方法是使用 GPU：
如果你在 CPU 上運行，每次請求耗時 925 毫秒。如果使用 GPU，在每次請求 199 毫秒的情況下，可以在大約 100 毫秒的空間時間內預測消息的其餘部分，當你考慮到他們的瀏覽器仍然需要呈現你的預測時，這就非常有用了。
然而，隨着模型變得越來越大，我們需要更多的處理能力。
解決該問題的一些努力涉及構建全新的硬件。例如，谷歌發佈了 TPU，這是專門爲與 TensorFlow 接口而設計的 ASIC，最新的 TPU 打破了模型服務基準的可擴展性和性能的記錄。
其他努力還包括加速和優化現有硬件。NVIDIA 發佈了 TensorRT，這是一個用於優化 NVIDIA GPU 在推理服務中利用率的 SDK。NVIDIA 已經證明，與在 GPU 上使用 TensorRT，比只使用 CPU 推理相比，性能提高了 40 倍。
結束語
在許多方面，機器學習給公衆的感覺就像是荒野西部。類似GPT-2 這樣的超級模型纔剛出現不久，機器學習剛剛被工程師廣泛使用，而不僅僅侷限在大公司。而且，模型架構方面的新突破也指日可待。
我們已經目睹了機器學習與每一個垂直領域的結合，包括媒體、金融、零售等。隨着機器學習成爲軟件的標準組成部分，在生產中部署大型模型將不再是挑戰。
作者介紹：
Caleb Kaiser，Cortex Lab 創始團隊成員，曾在 AngelList 工作，最初在 Cadillac 供職。
原文鏈接：
https://towardsdatascience.com/too-big-to-deploy-how-gpt-2-is-breaking-production-63ab29f0897c