0 前言
今天我會首先解釋為什麼 LLM 的部署很難，因為許多人可能並不理解其中的複雜性。接著，我會分享七個提高 LLM 部署效果的技巧和方法。
1 為啥 LLM 部署困難？
“最近在忙啥？”
“我一直在讓 LLM 服務變得更簡單。”
“LLM 部署難嗎？不是直接呼叫 OpenAI API 就行？”
“某種程度上是這樣。”因為提到 LLM，大多數人只會想到 OpenAI，呼叫 API 確實簡單。她為什麼要談這些內容？呼叫 API 誰不會？但實際上，訪問 LLM 的方式不止一種。可用託管的API如 OpenAI、Cohere、Anthropic 和 AI21 Labs 等。他們已為你完成託管和部署，你只需調它們。雖然這確實減少你的工作量，但仍存在複雜性，如減少幻覺輸出。不過，他們已經完成很多繁重任務。很多場景，你可能更傾向自託管，如呼叫 Mistral或託管 Llama 或其他模型。這意味著你在自己的環境中託管它，無論VPC還是PC。
那為啥還自託管？
很多原因：
- 降低大規模部署成本。如只做概念驗證，基於 OpenAI API 模型成本確實低。但如大規模部署，自託管最終成本更低。因為只需解決自己的業務問題，可用更小模型，而 OpenAI 必須託管一個能解決程式設計和寫作莎士比亞問題的大模型，因此需要更大的模型。大規模部署時，自託管成本會低得多
- 效能提升。當你用特定任務的LLM或對其微調，使其專注你的任務，通常得到更好效能
- 大多數客戶選擇自託管的原因：隱私和安全。如你處受監管行業，如需遵循 GDPR 或滿足合規團隊的要求，你可能也需自託管
如果這幾點不重要，就用 API 夠了。
企業選擇開源的主要原因
包括控制權、定製化和成本。最重要的是控制權。擁有 AI 獨立性至關重要，如當 OpenAI 再次解僱 CEO，你仍可訪問自己的模型，尤其是當你構建重要的業務應用時。如果你正在考慮自託管，你絕對不是孤軍奮戰，大多數企業都在努力建立自託管能力。
對沖基金的一員說：“隱私對我的用例很重要，因此自託管是有意義的。”然後他可能會問：“自託管真的有那麼難嗎？”我經常聽到類似的話，這讓我非常惱火。答案是：確實更難。你不能忽視那些你看不到的複雜性。當你呼叫基於 API 的模型時，你受益於他們的工程師在構建推理和服務基礎設施方面所做的所有努力。實際上，像 OpenAI 這樣的公司有 50 到 100 人的團隊在管理這些基礎設施。包括模型壓縮、Kubernetes、批處理伺服器、函式呼叫、JSON 生成、執行時引擎等。當你使用 API 模型時，這些你都不需要操心，但當你自託管時，這些問題突然變成了你的責任。
他可能會說：“但我經常部署機器學習模型，比如 XGBoost 或線性迴歸模型。部署這些 LLM 會有多難？”我們的回答是：“你知道 L 代表什麼嗎？”部署這些模型要困難得多。為什麼呢？LLM 中的第一個 L 代表“大”（Large）。我記得我們剛成立公司時，認為一個擁有 1 億引數的 BERT 模型已經算大了。現在，一個擁有 70 億引數的模型被認為是小型模型，但它仍然有 14GB 的大小，這絕對不小。
第二個原因是 GPU。與 CPU 相比，GPU 更難處理，它們也更昂貴，因此高效利用 GPU 十分重要。如果你對 CPU 的利用率不高，可能問題不大，因為它們成本低得多。但對於 GPU，成本、延遲和效能之間的權衡非常明顯，這是以前可能沒有遇到過的。
第三個原因是，這個領域發展非常快。我們現在用於部署、最佳化和服務模型的技術，有一半在一年前還不存在。還有一個值得一提的問題是編排問題。通常，對於這些大語言模型應用，你需要協調多個不同的模型。例如，RAG（檢索增強生成）就是一個典型的例子。你需要協調一個嵌入模型和一個生成模型。如果是最先進的 RAG，你可能還需要多個解析模型，比如影像模型和表格模型，此外還需要一個重排序模型。最終，你可能會用到五六個不同的模型。這會讓人感到非常困惑。此外，部署應用還有其他常見難點，比如擴充套件性和可觀察性。
2 咋讓 LLM 部署更輕鬆？
分享一些讓 LLM 部署更輕鬆的技巧。雖然仍會很痛苦，但不會那麼糟糕。
1. 知道你的部署邊界
構建應用程式時，應解你的部署邊界。通常，人們在構建出一個自認為可行的應用程式後，才開始考慮部署邊界。我認為，你應該先花時間思考你的需求，這會讓後續一切變得更簡單。如考慮你的：
- 延遲需求是什麼？
- 預計負載是多少？
- 應用程式是頂多只有三個使用者，還是像 DoorDash 一樣要服務數百萬使用者？
- 有什麼硬體資源可用？
- 需要在本地部署，還是可用雲例項？如是雲例項，需要什麼型別例項？
所有這些問題都要提前規劃。你可能無法知道精確需求，所以最好列出範圍。如：“只要延遲低於 1 秒就可以接受。”或“只要高於某個值也行。”。還有一些問題如：我是否需要保證輸出是 JSON 格式？是否需要保證輸出符合特定的正規表示式規則？這些都值得提前思考。
2. 始終進行量化
提前規劃好這些需求，那後續所有決策都容易得多。始終對模型進行量化。量化本質是一種模型壓縮技術，它將LLM的權重精度降低到你想要的任何形式。4-bit 是我最喜歡的量化，從 FP32（32位浮點數）開始。因為它在準確性和壓縮比之間達到極佳平衡。你可以看到這張圖表，我們有一個準確性與模型位數的關係圖，也就是模型的大小。
假設原始模型是 FP16（16位浮點數），其實它通常是 32 位的。紅線表示它的準確性。當我們壓縮模型時，比如從 FP16 降低到 4-bit，固定資源下，使用量化模型的效能實際上要好於未量化的模型。透過這張圖表我們可以得出結論，對於固定資源，量化模型通常能夠在準確性和資源利用率之間取得更好的平衡。
我們從基礎設施開始，倒推需求。假設我們可用 L40S GPU，它有 48GB 視訊記憶體。因為我們知道可用的資源，可以根據現有的模型倒推需求。如是 Llama 13B（130億引數）模型，它需要 26GB 視訊記憶體，沒問題，可執行。但如是當前最先進 Mixtral 模型，它無法直接執行。然而，一個經 4-bit 量化的 Mixtral 模型可執行，這就很棒了。透過這種方式，就知道哪些模型可用來實驗。
那個關於 Tim Dettmers 的圖表也告訴我們，4-bit 量化模型在效能上可能更優。假設 Llama 模型和 Mixtral 模型體積一樣，4-bit 模型通常會保留原來模型的高精度，同時大大減小了模型體積。我們透過基礎設施倒推，找到能適配資源的量化模型，這很可能是當前效能最優的解決方案。
3. 花時間最佳化推理
建議只花一點時間是因為，部署這些模型時，你最初想到的策略往往是完全錯誤的。雖然你不需要花大量時間思考這個問題，但稍微投入一些時間，可以使 GPU 利用率提升幾個數量級。
舉個例子，關於批處理策略。批處理是指多個請求同時處理。部署這些模型時，GPU 利用率是最寶貴的資源。因為 GPU 很昂貴，所以最大化其利用率非常重要。
如果我不使用批處理，那麼 GPU 的利用率大概是這樣的，非常糟糕。一個常見的錯誤做法是使用動態批處理，這種方法適用於非生成式 AI 應用，比如你之前可能用過的系統。動態批處理的原理是等待一小段時間，收集在這段時間內到達的請求，然後一起處理。在生成式模型中，這種方法會導致 GPU 利用率下降。開始時利用率很高，但隨後會下降，因為使用者會因較長的生成時間被卡在佇列中。
動態批處理雖然是常見做法，但通常效果不好。如果你花點時間思考這個問題，可以採用持續批處理（Continuous Batching）。這是我們使用的一種方法，也是當前生成式模型的最先進批處理技術。它允許新到的請求中斷正在處理的請求，以保持 GPU 利用率始終處於高水平。這樣不僅減少了排隊時間，還大幅提升了資源利用效率。這張 GPU 利用率圖表是我們幾周前的狀態。相比動態批處理，持續批處理在 GPU 成本上可以帶來一個數量級的提升。這完全不影響模型準確性，但大大提高了利用率。
對於非常大的模型，單個 GPU 無法滿足推理需求。例如，Llama 70B、Mixtral 或 Jamba 等模型非常龐大。通常需要將它們分佈在多個 GPU 上進行推理。這要求你能夠設計一種多 GPU 推理的方法。最常見的方法（例如 Hugging Face 的 Accelerate 推理庫所使用的方式）是按層級劃分模型。如果模型佔用 90GB，可以分配 30GB 給每個 GPU，共使用三個 GPU。然而，這種方法的缺點是每次只有一個 GPU 處於活躍狀態，導致資源浪費，因為後續 GPU 需要等待前一個 GPU 完成任務。
這種方式存在侷限性，例如在 Hugging Face Accelerate 庫中。我們認為更優的方法是 Tensor Parallel。這種方式將模型按“長度”分割，使每個 GPU 能同時執行每一層，從而大幅提升推理速度，並支援任意大小的模型。所有 GPU 同時執行，因此避免了資源浪費。例如，在一個模型中，可以實現 GPU 利用率提升 3 倍，再加上其他最佳化，可以顯著提升資源效率。
4. 整合基礎設施
目前為止，我的建議包括：考慮部署需求、量化、推理最佳化。第四個建議是整合基礎設施。生成式 AI 的計算成本非常高，因此集中的基礎設施管理能帶來很大優勢。傳統企業的機器學習團隊往往以孤島形式存在，導致基礎設施整合效率低下。透過集中的 MLOps 團隊（如 Ian 所領導的團隊），可實現一次性部署並由單一團隊進行維護，這讓應用開發團隊專注於構建應用。
舉個例子，一箇中央計算基礎設施可以提供訪問模型（如 Llama 70、Mixtral 和 Gemma 7B）的許可權，並由中央團隊定期更新模型（例如從 Llama 2 升級到 Llama 7）。各個應用開發團隊可以個性化模型，例如新增 LoRA（輕量化介面卡）或 RAG（結合專有資料的檢索增強生成）。中央團隊負責維護基礎設施，而分散的開發團隊僅需呼叫這些模型構建應用。這種方法不僅提高了 GPU 的利用率，還為組織提供類似 OpenAI 的體驗，但使用的是私有模型。
關鍵點包括：確保推理伺服器具備可擴充套件性、支援 LoRA 介面卡以實現微調。如果做好這些工作，可以顯著提升 GPU 利用率。GPU 的利用率非常重要，甚至可以說是僅次於家人和朋友的存在。
案例研究：RNL
一個美國企業 RNL 擁有四個不同的生成式 AI 應用，每個應用使用獨立 GPU。這種方式導致了 GPU 利用率低下，因為不是所有應用始終滿負荷執行。我們幫助他們將所有應用資源整合到一個推理伺服器中，使各團隊透過共享資源構建應用。這種方式將所需 GPU 數量減少了一半，同時也能更高效地管理生成式和非生成式任務。
5. 構建時考慮模型替換週期
建議的第五點是，假設在 12 個月內需要替換模型。隨著 LLM 的快速發展，僅透過切換模型即可獲得效能提升。例如，一個客戶去年使用 Llama 1 開發了首個應用程式，在一年內更換了四次模型。
每週他們都會說，這個新模型出來了。你們支援嗎？我會說，是的，但為什麼這是第六次更改了？讓我們回想一下一年前最先進的技術是什麼。一年前，也許那時Llama已經發布了，但如果在那之前，可能是T5系列。T5模型是當時最好的開源模型。我們所見證的是開源大語言模型生態系統的驚人爆發。這一切都始於Llama，然後是Llama 2，接著許多企業在此基礎上構建。
例如，Mistral 70B實際上是用與Llama相同的架構構建的。我們有來自阿聯酋的Falcon。我們有Mistral的Mixtral。你們有很多，而且它們還在不斷湧現。實際上，如果你檢視Hugging Face，這是所有這些模型儲存的地方，如果你檢視他們的開源模型排行榜，頂級模型幾乎每週都在變化。最新和最偉大的模型不斷出現。這些模型將會不斷變得更好。這是所有模型的效能，無論是開源還是非開源，你可以看到許可證，專有的或非專有的。開源模型正在慢慢地佔據排行榜。我們開始接近開源和非開源之間的平等。現在，開源模型大約在GPT-3.5左右。那是我們所有人都為之驚歎的原始ChatGPT。
我的預期是，我們將在未來一年內達到GPT-4的質量。這意味著你真的不應該將自己與單一模型或單一供應商繫結。回到我之前向你們展示的a16z報告，大多數企業都在使用多個模型供應商。他們正在以一種可互操作的方式構建他們的推理棧，如果OpenAI出現故障，我可以輕鬆地將其替換為Llama模型。或者，如果現在Claude比GPT-4更好，我可以很容易地替換它們。以這種可互操作性為念進行構建真的很重要。我認為OpenAI給我們的最偉大的事情不一定是他們的模型，儘管它們真的很棒，但他們實際上違反直覺地民主化了AI領域，不是因為他們開源了他們的模型，因為他們真的沒有，而是因為他們為行業提供了API的統一性。如果你以OpenAI API為念進行構建，那麼你就可以捕捉到很多價值，並且能夠輕鬆地替換模型。
這對構建方式意味著什麼？以API和容器為先的開發使生活變得更輕鬆。這是相當標準的事情。抽象真的很好，所以不要花時間為你的特定模型構建自定義基礎設施。你很可能在12個月內不會使用它。如果你要構建，嘗試構建更通用的基礎設施。我們總是說，在當前階段，我們仍在許多組織中證明AI的價值，工程師應該花時間構建出色的應用體驗，而不是糾結於基礎設施。因為現在，對於大多數企業來說，我們很幸運有足夠的預算去嘗試這些生成式AI的東西。
我們需要快速證明價值。我們傾向於說，不要使用只支援Llama的框架，因為這隻會給你帶來更多麻煩。無論你選擇什麼架構或基礎設施，確保當Llama 3、4、5、Mixtral、Mistral出現時，它們將幫助你採用它。我可以回到我之前談到的案例研究。我們以這種方式構建，顯然，用Mixtral替換Llama 3非常容易，當Llama 3出現時。例如，如果出現了更好的Embedder，就像幾周前出現的非常好的Embedder，我們也可以很容易地替換它。
6. GPU看起來真的很貴，無論如何都要使用它們
GPU看起來真的很貴。無論如何都要使用它們。GPU是如此驚人。它們非常適合生成式AI和生成式AI工作負載。生成式AI涉及大量平行計算，這恰好是GPU非常擅長的事情。你可能會看價格標籤，覺得它比CPU貴100倍。是的，確實如此，但如果你正確使用它並從中獲得你需要的利用率，那麼最終處理的訂單數量將會多得多，而且每個請求的成本將會便宜得多。
7. 儘可能用小型模型
當你可以的時候，使用小型模型。GPT-4是王者，但你不會讓王者洗碗。洗碗是什麼：GPT-4是了不起的。它是一項真正卓越的技術，但使它如此出色的是它在能力上非常廣泛。我可以使用GPT-4模型寫情書，你可以用它成為一個更好的程式設計師，我們使用的是完全相同的模型。這很瘋狂。那個模型有很多能力，因此它真的非常大。它是一個巨大的模型，而且推理起來非常昂貴。我們發現，你最好使用GPT-4來處理那些開源模型還無法處理的真正困難的事情，然後使用較小的模型來處理那些更容易的事情。透過這樣做，你可以大幅降低成本和延遲。當我們談到你之前擁有的延遲預算或資源預算時，如果你只在真正需要的時候使用GPT-4，你可以最大限度地利用資源預算。
三個常見的例子是RAG Fusion。這是當你的查詢被大型語言模型編輯後，然後所有查詢都進行搜尋，然後結果進行排名以提高搜尋質量。例如，你可以透過不使用GPT-4而獲得很好的結果，只在必要時使用GPT-4。例如，使用RAG，你可以只使用一個生成模型來重新排名，所以只是在最後檢查Embedder說相關的東西是否真的相關。小型模型，特別是針對函式呼叫的微調模型非常好。函式呼叫的一個非常常見的用例是，如果需要我的模型輸出類似JSON或regex的東西，我基本上有兩種方法可以做到這一點。要麼我可以微調一個更小的模型，要麼我可以給我的小模型新增控制器。控制器真的很酷。控制器本質上是，如果我自託管模型，我可以禁止我的模型說出任何會破壞JSON模式或我不想要的regex模式的標記。像這樣的事情，實際上大多數企業用例，你不一定需要使用那些基於API的模型，你可以立即獲得成本和延遲的好處。
3 總結
確定你的部署邊界，然後反向工作。因為你知道你的部署邊界，你知道你應該選擇的模型，當你將其量化下來時，就是那個大小。花時間思考最佳化推理，這可以真正地產生多個數量級的差異。生成式AI受益於基礎設施的整合，所以儘量避免讓每個團隊負責他們的部署，因為很可能會出錯。假設你將在12個月內替換你的模型進行構建。GPU看起來很貴，但它們是你最好的選擇。當你可以的時候，你會使用小型模型。然後我們對Russell說這些，然後他說，“這太有幫助了。我非常興奮地使用你的提示部署我的關鍵任務LLM應用。”然後我們說，“沒問題，如果你有任何問題，請讓我們知道”。
4 問答
Q：你說過要為靈活性而構建。頻繁更換模型的用例是什麼？我們在自定義微調和自定義資料上花費的時間和精力將不得不重複？在頻繁更換模型的情況下，你有什麼建議嗎？
A：你什麼時候想要頻繁更換模型？一直都是。隨LLM改進速度，幾乎總是可以僅透過更換模型就獲得更好效能。你可能需要對提示進行一些調整，但通常，一對一的切換是可行的。例如，如果我的應用構建在GPT-3.5上，我將其替換為GPT-4，即使我使用相同的提示，我的模型效能可能會提高，這是一件非常低努力的事情。這與更換所需的工程努力如何協調？如果這是一個月的長過程，如果沒有顯著改進，那麼你就不應該進行那個切換。我建議嘗試以一種方式構建，使其不是一個月的長過程，實際上可以在幾天內完成，因為那樣幾乎總是值得的。
這與微調如何協調？我有一個辛辣而熱門的觀點，即對於大多數用例，你不需要微調。微調在幾年前的深度學習中非常流行。隨模型越來越好，它們也更擅長遵循你的指示。你通常不需要為許多用例進行微調，可用RAG、提示工程和函式呼叫等方法。這就是我傾向於說的。如果你正在尋找你的第一個LLM用例，談論更換模型，一個非常好的第一個LLM用例就是嘗試替換你的NLP管道。許多企業都有現成的NLP管道。如果你可以將它們替換為LLMs，通常，你會獲得多個點的準確性提升。
Q：你認為企業級硬體和消費者最大硬體在本地硬體上的區別是什麼，因為我選擇了消費者最大硬體，因為你的記憶體可以高達6000兆傳輸，PCI通道更快。
A：因為像他這樣的人已經拿走了所有的A100s，當我們進行內部開發時，我們實際上使用的是4090s，這是消費者硬體。它們更容易獲得，也比獲得資料中心硬體便宜得多。這就是我們用於開發的東西。我們實際上沒有使用消費者級硬體進行大規模推理，儘管沒有理由它不會工作。
如果它適合你的工作負載。我們也使用它。我們認為它們非常好。它們也便宜得多，因為它們作為消費者級而不是資料中心級出售。
Q：你說GPU是一個整體，也是最重要的。我有點驚訝，但也許我的問題會解釋。我用只有CPU的小虛擬機器做了一些概念驗證，我每秒幾次請求就得到了相當好的結果。我沒有問自己關於可擴充套件性的問題。我在想我們應該在多少請求時切換到GPU？
A：實際上，也許我在GPU方面有點過於強烈，因為我們也在CPU上部署過。如果延遲足夠好，這通常是人們首先抱怨的問題，是延遲，那麼CPU可能沒問題。只是當你在尋找規模經濟並且當你在尋找擴充套件時，它們幾乎總是每個請求更貴。如果你的請求數量合理地低，延遲也足夠好，那麼你可以繼續使用它。我認為我們的第一個推理伺服器的概念驗證是在CPU上完成的。你也會知道的另一件事是，你將限制你可以使用的模型的大小。例如，如果你正在做一個70億量化的，你可能也可以繼續使用CPU。我認為如果你從一張白紙開始，GPU更好。如果你的起點是你已經有一個充滿CPU的大型資料中心，而且你否則不會使用它們，那麼仍然值得嘗試是否可以利用它們。
Q：我有一個關於通常使用的API的問題，當然，OpenAI的API通常也被應用程式使用。我也知道很多人真的不喜歡OpenAI的API。你看到其他API了嗎？因為很多人只是在模仿它們，或者他們只是使用它，但沒有人真的喜歡它。
A：當你說他們不喜歡它時，是他們不喜歡API結構，還是不喜歡模型？
Q：這是關於API結構的。這是關於文件的。這是關於狀態的，關於你無法完全理解的很多事情。
A：我們也真的不喜歡它，所以我們編寫了自己的API，稱為我們的推理伺服器，然後我們有一個與OpenAI相容的層，因為大多數人使用那種結構。你可以檢視我們的文件，看看你是否更喜歡它。我認為，因為它是第一個真正爆發的，它是整個行業在API結構上匯聚的地方。
關注我，緊跟本系列專欄文章，咱們下篇再續！
作者簡介：魔都架構師，多家大廠後端一線研發經驗，在分散式系統設計、資料平臺架構和AI應用開發等領域都有豐富實踐經驗。
各大技術社群頭部專家博主。具有豐富的引領團隊經驗，深厚業務架構和解決方案的積累。
負責：
- 中央/分銷預訂系統效能最佳化
- 活動&券等營銷中臺建設
- 交易平臺及資料中臺等架構和開發設計
- 車聯網核心平臺-物聯網連線平臺、大資料平臺架構設計及最佳化
- LLM Agent應用開發
- 區塊鏈應用開發
- 大資料開發挖掘經驗
- 推薦系統專案
目前主攻市級軟體專案設計、構建服務全社會的應用系統。
參考：
- 程式設計嚴選網
本文由部落格一文多發平臺 OpenWrite 釋出！