編譯 | 星璇

出品 | 51CTO技術棧（微信號：blog51cto）

在過去的兩年里，我更多地參與了使用大型語言模型（LLMs）的生成式AI項目，而非傳統的系統。我開始懷念無服務器云計算。它們的應用范圍廣泛，從增強對話式AI到為各行各業提供復雜的分析解決方案，以及其他許多功能。許多企業將這些模型部署在云平臺上，因為公共云提供商已經提供了現成的生態系統，而且這是阻力最小的路徑。然而，這并不便宜。

云還提供了其他好處，如可擴展性、效率和高級計算能力（按需提供GPU）。在公共云平臺上部署LLM的過程有一些鮮為人知的秘密，它們可能會對成功或失敗產生重大影響。也許是因為處理LLMs的AI專家并不多，也因為我們在這方面還沒有太多經驗，我們的知識體系中存在很多空白。

讓我們探討三個在云上部署LLM時鮮為人知的“技巧”，也許你的AI工程師們也不知道。考慮到這些工程師的年薪往往超過30萬美元，也許現在是時候考考他們做這些事情的細節了。我看到每個人都像頭發著火一樣奔向生成式AI，但犯的錯誤比以往任何時候都多。

1.管理成本效益和可擴展性

使用云平臺部署LLMs的主要吸引力之一是能夠按需擴展資源。我們不必成為優秀的容量規劃師，因為云平臺擁有我們只需點擊鼠標或自動分配的資源。

但是，等等，我們即將犯下當初使用云計算時犯下的同樣錯誤。在擴展的同時管理成本是一項技能，許多人需要在這方面獲得幫助以進行有效導航。請記住，云服務通常根據消耗的計算資源收費；它們就像公共事業一樣運作。處理得越多，付費就越多。考慮到GPU的成本更高（且耗電量更大），這是使用公共云提供商的LLMs時的核心關注點。

請確保您使用成本管理工具，包括云平臺提供的工具和可靠的第三方成本治理和監控服務商（finops）提供的工具。例如，實施自動擴展和調度、選擇合適的實例類型或使用搶占式實例來優化成本。此外，請記得持續監控部署情況，根據使用情況而不是僅根據預測負載調整資源。這意味著不惜一切代價避免過度配置（明白我這里的雙關了嗎？）。

2.多租戶環境中的數據隱私

部署LLMs通常涉及處理大量數據和訓練過的知識模型，這些可能包含敏感或專有數據。使用公共云的風險在于，你的“鄰居”是以處理實例的形式存在，它們在同一物理硬件上運行。因此，公共云確實存在這樣的風險：在數據存儲和處理過程中，數據可能會被公共云數據中心中同一物理硬件上運行的其他虛擬機訪問。

如果你詢問公共云提供商有關此問題，他們會急忙拿出最新的PowerPoint演示文稿，展示這是不可能的。雖然這主要是真的，但并不完全準確。所有多租戶系統都存在這種風險；你需要加以緩解。我發現，云提供商的規模越小，比如那些僅在單一國家運營的云提供商，這種問題出現的可能性就越大。這適用于數據存儲和LLMs。

秘訣在于選擇符合嚴格安全標準并能提供證明的云提供商：靜止和傳輸中的數據加密、身份和訪問管理（IAM）以及隔離策略。當然，更好的做法是你實施自己的安全策略和安全技術棧，以確保在云上使用多租戶LLMs的風險較低。

3.處理有狀態模型部署

大型語言模型（LLMs）大多數都是有狀態的，這意味著它們會在一次交互到下一次交互之間保留信息。這個舊方法提供了新的好處：即在持續學習場景中提高效率的能力。然而，在云環境中管理這些模型的有狀態性是有挑戰性的，因為云環境中的實例可能是按設計短暫或無狀態的。

支持有狀態部署的編排工具（如 Kubernetes）是有幫助的。它們可以為大型語言模型利用持久性存儲選項，并配置為跨會話維護和操作其狀態。為了支持大型語言模型的連續性和性能，您需要這樣做。

隨著生成式人工智能的爆炸式增長，在云平臺上部署大型語言模型已成定局。對于大多數企業來說，不使用云實在是太不方便了。我對接下來這股狂熱的擔憂是，我們會錯過一些容易解決的問題，并會犯下巨大而昂貴的錯誤，而這些錯誤在最終大多是可以避免的。

本文轉載自??51CTO技術棧??，作者：星璇