關于大模型在企業生產環境中的獨立部署問題 原創
“ 大模型產品的技術復雜度遠遠超出你的想象 ”
最近一段時間公司在搞AIGC領域的產品，雖然集成了很多第三方的大模型服務接口，但從節省成本的角度，公司也找了一部分具有相似效果的開源模型做獨立部署。
但在做模型獨立部署方面面對著各種各樣的問題，而且環境極不穩定，因此就引發了關于大模型企業級應用中的環境部署和運維的問題。
關于大模型在企業生產中的部署問題
首先拋開成本問題從技術的角度來說，小公司獨立部署大模型會很吃力，因為大模型部署是一個系統性的問題。涉及到算力，大模型，服務接口，并發問題等多個環節，設計到系統運維，鏡像，監控，系統架構等多個方面。
企業獨立部署大模型主要涉及哪些問題點？
首先最基礎的就是算力問題，對大部分企業來說根本無力建屬于自己的機房，面對著動輒幾萬甚至幾十萬的算力機，對大部分企業來說都無法承擔。
因此，購買或租用一些云端算力機是一個比較好的選擇，但云端算力機也只是一個一個獨立的機器，在應用層面并沒有提供自己集群部署和運維的能力。
當然，并不是說云計算做不到這一點，而是能做到這一點的云服務商機器的價格都比較貴；因此，對很多小微企業來說，都會選擇一臺或多臺算力能夠簡單支持業務正常運營的機器，然后做人肉運維。
比如我們公司，就是購買了幾臺云端算力機，在上面部署幾個模型，然后天天出問題，一個問題查一天。
從大模型的部署角度來看，部署大模型無非以下幾種方式：
最簡單的是一些小模型，單臺機器就能夠支撐其運算需求，這時在企業生產中只需要在多臺機器上部署多個相同的模型，然后在入口做一個負載均衡就可以了。
但如果沒有完整的運維系統，全靠人肉運維，這樣會把運維和技術人員給累死。
先說這種模式經常出現的一些問題，比如怎么檢測大模型服務的健康狀況？說白了就是怎么知道這些機器是否在正常運行？一臺機器一臺機器的看嗎？
再有，如果某臺機器出問題了，怎么快速定位到這臺機器上？ 大模型的集群部署是否有自動健康檢測系統？
我想很多企業都做不到這一點，一旦出問題只能靠技術人員慢慢排查；而這還不包括一些莫名其妙的問題。
比如說我自己，前幾天遇到一個bug，AIGC的任務無法提交到大模型，本來以為任務無法提交是因為自己的模塊有bug，然后查了一下午時間發現是因為算力機出問題導致業務端無法獲取到算力機，然后間接導致任務無法提交。
而如果是那種參數量和算力要求巨大的模型，單機部署就無法實現，只能依靠集群的并行計算能力，但換句話說能做到大模型集群并行計算的公司又有多少？
模型不同模塊之間怎么部署，怎么監控，怎么解決它們的通訊問題，某些模塊的算力瓶頸怎么解決？ 遇到高并發問題怎么解決？是使用異步通訊，還是使用消息隊列做削峰處理？ 中間引入的異步通訊模塊或消息隊列中間件怎么保證穩定性？
最重要的是，在出現生產問題時怎么做到及時的響應，并快速恢復上線，把影響降到最小？而這些靠人工來做是不可能完成的，但大部分企業又沒有能力構建完善的運維系統。
再有在大部分小微企業中，老板或者領導最看重的就是業務的開發進度，而不是系統運維的難度。業務開發時間被不斷的壓縮，各種業務bug已經讓人不厭其煩，再加上模型服務的不穩定性，真的是讓人崩潰。
還有就是很多小公司為了省錢，前期也不肯找一個有能力，有經驗的架構師做系統架構，很多小項目都是匆匆上馬，開發人員素質不齊，導致大量的設計缺陷和業務漏洞，還包括一些項目管理混亂，簡直就是群魔亂舞。
就拿作者自己的公司來說，采用的就是租用云算力服務商的算力機，把模型服務獨立部署在云端；而為了提高擴展性，就通過調用云算力服務商的接口，根據業務壓力動態進行擴容，也就是用鏡像的方式啟動多臺相同環境的機器；然后業務端通過輪訓或其它方式來進行動態選擇算力機。
然后為了解決可能存在的性能壓力，因此就采用消息隊列的方式做擴容；但由于業務時間緊，項目開發都是以完成功能為主，因此就導致整個擴容模塊沒有數據一致性處理，代碼沒注釋，業務邏輯混亂，日志不全。
隨便某個中間環節出問題，就只能從頭開始排查，無法準確定位到問題產生的時間，地點和方式。
說了這么多，其實從根吧上來說還是很多小微企業的老板對整個技術沒有一個完整的認識；大模型技術本身就極具復雜性，由于其龐大的算力需求就導致單機部署基本成為不可能。
而集群化部署的復雜性又是不可想象的，因此其運維的難度與傳統運維相比完全不可同日而語。
再加上需要把大模型與具體的業務相結合，而怎么設計大模型的服務接口，不但要保證功能性，還要保證穩定性和擴展性；而這就需要有著足夠強大的業務理解和梳理能力，以及強大的接口抽象能力。
而以上種種，任何一個都不是普通人能輕易完成的任務。
因此從各方面來看對小企業來說，獨立部署大模型都不是一個好的選擇，表面上來看好像是節約了成本；但事實上不但大大增加了運維的難度和成本，最重要的是大大提高了系統的運行風險，導致整個系統風險不可控。
其次，大量的運維問題會占用技術和開發人員大量的時間；就比如說運維方面出了一個小問題，就很可能導致整個開發進度被耽誤，開發人員會遇到各種各樣莫名其妙的問題，而無從下手。
因此，選擇一個三方模型雖然成本可能會高一點，但可以讓你完全專注于自己的核心業務，減少系統性風險以及各種亂七八糟的問題。
本文轉載自公眾號AI探索時代 作者：DFires
