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