新一輪科技革命和產(chǎn)業(yè)變革迅猛發(fā)展，人工智能等新技術(shù)方興未艾，隨著大模型等新技術(shù)被深入應(yīng)用到企業(yè)的多個(gè)業(yè)務(wù)場(chǎng)景，不僅企業(yè)的數(shù)據(jù)成為了企業(yè)發(fā)展的新型重要生產(chǎn)要素，軟件技術(shù)的創(chuàng)新應(yīng)用作為新質(zhì)生產(chǎn)力的重要組成部分，也在承擔(dān)著更為重要的歷史使命，在加速自身技術(shù)變革的同時(shí)，也賦能千行百業(yè)，為中國(guó)經(jīng)濟(jì)的新一輪發(fā)展助力。
12月13-14日，由中科軟科技股份有限公司舉辦的年度技術(shù)盛會(huì)——“2024軟件技術(shù)大會(huì)”在北京朗麗茲西山花園酒店成功召開(kāi)。作業(yè)幫基礎(chǔ)架構(gòu)負(fù)責(zé)人董曉聰受邀出席并以《云原生助力AIGC發(fā)展》為主題進(jìn)行演講。董曉聰從回顧作業(yè)幫云原生建設(shè)的全貌開(kāi)始展開(kāi)，再講到AIGC時(shí)代下，云原生如何助力時(shí)代發(fā)展，給與會(huì)者帶來(lái)了一場(chǎng)極具價(jià)值的技術(shù)盛宴。
以下是經(jīng)過(guò)整理后的演講內(nèi)容：
大家好，很高興參加本次技術(shù)峰會(huì)。先做下自我介紹，我是董曉聰，現(xiàn)在在作業(yè)幫擔(dān)任基礎(chǔ)架構(gòu)負(fù)責(zé)人，負(fù)責(zé)作業(yè)幫的架構(gòu)研發(fā)、運(yùn)維、DBA、安全相關(guān)的工作，同時(shí)也是騰訊云TVP、阿里云MVP。
今天和大家分享的主題是云原生助力AIGC的發(fā)展。本次分享會(huì)分成三個(gè)部分，第一部分來(lái)講下CPU時(shí)代的云原生建設(shè)，一方面來(lái)看下云原生建設(shè)的全貌和作業(yè)幫的建設(shè)歷程，另一方面我們?cè)谶@個(gè)過(guò)程也總結(jié)了一些經(jīng)驗(yàn)，為接下來(lái)AIGC時(shí)代的建設(shè)提供了助力。第二部分來(lái)講下云原生如何助力AIGC，從2022年底OpenAI推出ChatGPT以來(lái)，國(guó)內(nèi)外的很多公司都在AIGC這個(gè)領(lǐng)域持續(xù)發(fā)力。作業(yè)幫也不例外。這中間除了在算法上面臨一系列挑戰(zhàn)外，基礎(chǔ)設(shè)施也是一樣的�；A(chǔ)架構(gòu)在這方面進(jìn)行了一系列的建設(shè)，下面也會(huì)詳細(xì)展開(kāi)來(lái)講。最后就是對(duì)未來(lái)的展望，除了云原生有更多助力AIGC的點(diǎn)外，AIGC的發(fā)展也會(huì)反哺云原生，達(dá)成協(xié)同進(jìn)化的效果。
先來(lái)看第一部分，CPU時(shí)代的云原生建設(shè)。
作業(yè)幫成立于2015年，是一家致力于用科技手段助力普惠教育的公司。作業(yè)幫的主要技術(shù)現(xiàn)狀可以歸納為兩點(diǎn)，規(guī)�；蛷�(fù)雜化。規(guī)模化是指作業(yè)幫線上的服務(wù)數(shù)量比較多，有數(shù)千個(gè)。這么多的服務(wù)對(duì)應(yīng)了數(shù)萬(wàn)的服務(wù)實(shí)例，而這么多的服務(wù)實(shí)例又是跑在數(shù)十萬(wàn)計(jì)算核心之上，整個(gè)規(guī)模比較大。
復(fù)雜化是指作業(yè)幫的技術(shù)棧比較多元。早期業(yè)務(wù)以PHP為主，但java、C++、python在一些場(chǎng)景也有廣泛的應(yīng)用。后來(lái)隨著技術(shù)的演進(jìn)，Golang、Nodejs的使用也越來(lái)越多。當(dāng)前Golang已成為使用最多的編程語(yǔ)言。作業(yè)幫從創(chuàng)建之初就base在云計(jì)算之上，后來(lái)也由于一系列原因最終選擇了一套多云的架構(gòu)。
云原生本質(zhì)上是用基礎(chǔ)設(shè)施去接管業(yè)務(wù)當(dāng)中的大量非功能邏輯。在我看來(lái)，云原生是企業(yè)解決自身質(zhì)量、安全、成本、效率的最短路徑。
云原生架構(gòu)的全貌是怎么樣的？大的架構(gòu)可以分成資源層和應(yīng)用層。資源層，包含計(jì)算存儲(chǔ)網(wǎng)絡(luò)這些IaaS實(shí)體。計(jì)算的話就是各種各樣的CPU、GPU。存儲(chǔ)的話包含塊存儲(chǔ)、文件存儲(chǔ)、對(duì)象存儲(chǔ)等。網(wǎng)絡(luò)包含的實(shí)體就會(huì)更多。
應(yīng)用層就是各種編程語(yǔ)言寫(xiě)的服務(wù)模塊。我們前面提到的各種問(wèn)題其中很大一塊是因?yàn)橘Y源層和應(yīng)用層耦合導(dǎo)致的。以docker+k8s為代表的容器技術(shù)通過(guò)容器鏡像、作業(yè)編排、作業(yè)調(diào)度、資源管理實(shí)現(xiàn)底層資源對(duì)上層應(yīng)用的透明。上層應(yīng)用想要跑得更快，還需要一層微服務(wù)治理體系。微服務(wù)治理體系以服務(wù)的通信為基礎(chǔ)，包括服務(wù)的注冊(cè)發(fā)現(xiàn)、服務(wù)感知、流量管控等。
面對(duì)這么龐大的一個(gè)體系，19年底我們對(duì)業(yè)務(wù)進(jìn)行容器化改造，對(duì)PHP、Golang、Java、Python等語(yǔ)言制定標(biāo)準(zhǔn)的鏡像、編排模版，以及在框架層面做了一系列的功，以輔助業(yè)務(wù)的容器化改造，最終通過(guò)一年半的時(shí)間完成95%服務(wù)的容器化改造。
我們?cè)?1年開(kāi)始對(duì)作業(yè)幫APP的核心系統(tǒng)、檢索系統(tǒng)進(jìn)行容器化改造。檢索系統(tǒng)是一個(gè)有狀態(tài)的系統(tǒng)，對(duì)穩(wěn)定性和性能要求極為苛刻，我們通過(guò)使用fluid+jindoRuntime完成其容器化改造。再之后我們還對(duì)核心系統(tǒng)RTC完成了容器化改造。在改造的過(guò)程中我們發(fā)現(xiàn)k8s原生的調(diào)度器并不智能，一方面是因?yàn)槠鋽?shù)據(jù)源較為單一，僅為request和limit，無(wú)法獲取更多實(shí)時(shí)的指標(biāo)；另一方面調(diào)度策略也偏簡(jiǎn)單。所以我們基于k8s插件機(jī)制做了自定義調(diào)度策略，通過(guò)策略的完善，實(shí)現(xiàn)了整體負(fù)載的提升。
作業(yè)幫和其它互聯(lián)網(wǎng)業(yè)務(wù)一樣，也有明顯的波峰波谷。我們通過(guò)自定義調(diào)度將大數(shù)據(jù)離線任何在波谷時(shí)調(diào)度到在線集群，大大提升了集群的平均使用率。有了容器化和自定義調(diào)度器這兩個(gè)基礎(chǔ)，我們可做的事情就更多了。向下我們開(kāi)始大規(guī)模的使用serverless。其實(shí)serverless的應(yīng)用過(guò)程也不是一蹴而就的，也是一個(gè)逐步灰度的過(guò)程，我們也經(jīng)歷了從定時(shí)任務(wù)、普通web應(yīng)用，再到核心系統(tǒng)的過(guò)程。當(dāng)前作業(yè)幫的檢索系統(tǒng)和RTC系統(tǒng)有30%-90%是跑在serverless之上。
在服務(wù)治理這塊做的事情比較多，這里就挑兩個(gè)來(lái)講下。我們通過(guò)自研service mesh，大幅度優(yōu)化了性能，進(jìn)而實(shí)現(xiàn)了90%的服務(wù)覆蓋。當(dāng)前我們不僅攔截了入向流量，也攔截了出向流量，不僅攔截了RPC流量，也攔截了數(shù)據(jù)存儲(chǔ)流量，給業(yè)務(wù)帶來(lái)質(zhì)量、安全能力的大幅度提升。在服務(wù)觀測(cè)領(lǐng)域，我們自研了日志系統(tǒng)，較開(kāi)源方案有較大的成本優(yōu)化，約為ELK方案1/10-1/20的成本。然后基于這些能力之上，我們建成了一套多云的架構(gòu)。
最終取得的收益也是很明顯的，在質(zhì)量方面，服務(wù)的SLA從99.95%提升到99.99%，之所以能有這樣的提升，主要得益于觀測(cè)的覆蓋以及故障自愈能力。
觀測(cè)方面，大家都知道覆蓋度越高，對(duì)問(wèn)題分型和定位的幫助就越大，但是困擾覆蓋提升的主要因素就是成本。作業(yè)幫在這塊做了大量技術(shù)優(yōu)化，不僅是自研系統(tǒng)，trace中還使用Clickhoust替換ES，metric進(jìn)行了超時(shí)數(shù)據(jù)的降準(zhǔn)處理等等。最終使得成本在一個(gè)合理范圍，實(shí)現(xiàn)100%的覆蓋。
故障自愈方面，k8s的NPD可以自動(dòng)摘出疑似故障的機(jī)器。Readyness接口也可以實(shí)現(xiàn)應(yīng)用層面的故障摘流。以及在數(shù)據(jù)庫(kù)層面作業(yè)幫也實(shí)現(xiàn)了自動(dòng)擴(kuò)容等自愈手段。
成本方面，得益于容器技術(shù)，這幾年我們實(shí)現(xiàn)累計(jì)單價(jià)70%的下降。以及每一核的CPU有更高的利用率。
效率方面，我們通過(guò)容器、service mesh等云原生技術(shù)可以很好的落地。舉個(gè)例子，處于安全的要求，我們不希望研發(fā)知道數(shù)據(jù)庫(kù)的賬號(hào)、密碼，以及在服務(wù)中任意的訪問(wèn)外部服務(wù)�，F(xiàn)在通過(guò)service mesh的流量管控可以很好的實(shí)現(xiàn)，運(yùn)維效率也得到大幅度的提升。我記得在20年初的時(shí)候有活動(dòng)，流量每天都在增加，當(dāng)時(shí)還沒(méi)有完成容器化改造，只能每天夜里運(yùn)維初始化機(jī)器，研發(fā)部署程序，QA驗(yàn)收效果，效率比較低，以及質(zhì)量也不高。而現(xiàn)在這個(gè)操作只需要數(shù)分鐘就可以完成。再有就是機(jī)型更換的速度，我記得在21年我們更換容器的一款主力機(jī)型，從intel到AMD，僅需要兩周就完成了。云機(jī)房的遷移速度也得到大幅度提升。作業(yè)幫數(shù)千個(gè)服務(wù)及對(duì)應(yīng)的數(shù)據(jù)存儲(chǔ)，我們用三個(gè)月就可以完成遷移。以及整個(gè)過(guò)程中基本不需要業(yè)務(wù)研發(fā)參與，僅做好功能的驗(yàn)收即可。最后是安全方面，得益于云原生技術(shù)，主機(jī)、網(wǎng)絡(luò)、數(shù)據(jù)安全方面的能力也得到大幅度的提升。
下面講下第二部分，云原生助力AIGC。
進(jìn)入AIGC時(shí)代后，我們遇到的挑戰(zhàn)發(fā)生了很大的變化。首先是資源分布的問(wèn)題。之前我們可以要求云廠商在北京的機(jī)房供給充足的CPU機(jī)器，但AIGC時(shí)代則不是。尤其是在23年的時(shí)候，整個(gè)GPU資源的爭(zhēng)搶十分嚴(yán)重，進(jìn)而導(dǎo)致資源極其的分散，機(jī)房數(shù)量也大大增加。第二個(gè)是推理的成本太高了，從等同的成本來(lái)看，1000核CPU可以服務(wù)數(shù)百、數(shù)千個(gè)用戶。但是1張A800的卡只能支持個(gè)位數(shù)的QPS。需要持續(xù)的進(jìn)行技術(shù)優(yōu)化，把推理成本降下去，才能使得業(yè)務(wù)ROI合適。
大模型早期缺少相關(guān)的Devops規(guī)范，很多時(shí)候是在機(jī)器上手動(dòng)操作。這塊也繼續(xù)完善，繼續(xù)一套完備的Devops體系。大模型時(shí)代，算力、算法、數(shù)據(jù)是企業(yè)的核心資產(chǎn)，大模型文件更是這些的結(jié)晶，我們需要對(duì)模型文件做好安全加固。最后一個(gè)是一個(gè)小點(diǎn)，但對(duì)研發(fā)效率的影響很大。不同于CPU代碼，大模型文件動(dòng)輒百G起，分發(fā)耗時(shí)較長(zhǎng)。再疊加上第一個(gè)因素，全國(guó)各地的分布式機(jī)房，很有可能發(fā)布一次，需要數(shù)個(gè)小時(shí)的同步時(shí)間。面對(duì)這么多的問(wèn)題，作業(yè)幫基礎(chǔ)架構(gòu)主要進(jìn)行了這三方面的建設(shè)，統(tǒng)一資源調(diào)度、DevSecOps、異構(gòu)算力網(wǎng)絡(luò)。
先來(lái)進(jìn)行統(tǒng)一資源調(diào)度的介紹，對(duì)于業(yè)務(wù)研發(fā)而言，希望有獨(dú)立的資源池。這樣可以最大程度保障服務(wù)穩(wěn)定，避免其他業(yè)務(wù)線的干擾。但這個(gè)對(duì)企業(yè)而言卻不是最優(yōu)解，不管是資源供給還是資源利用的方面，只有把各方放到一個(gè)統(tǒng)一的資源池，才能實(shí)現(xiàn)資源利用的最大化。但這個(gè)需要有一個(gè)資源切分以及強(qiáng)隔離的技術(shù)，有了這個(gè)才能保證共享場(chǎng)景下各服務(wù)的穩(wěn)定性。對(duì)CPU而言，這個(gè)技術(shù)就是cgroup+namespace，但GPU是缺乏的。只有有了資源共享的技術(shù)，才能進(jìn)一步優(yōu)化調(diào)度策略，不管是分時(shí)復(fù)用、在離線混部、使用彈性資源等，最終實(shí)現(xiàn)資源使用率的提升。
這一切的關(guān)鍵還在于GPU共享的技術(shù)，我們先來(lái)看大模型程序是如何運(yùn)行的。最上面的是我們大模型的應(yīng)用程序，下面是我們使用的各種推理框架，如TRT、Vllm等，這些框架都是基于cuda生態(tài)的。整個(gè)cuda生態(tài)不僅包含cuda類庫(kù)，還有上層的runtime API、底層的driver API。Cuda層再之下就是內(nèi)核驅(qū)動(dòng)和硬件層。很多GPU虛擬化的技術(shù)會(huì)選擇在cuda進(jìn)行代理，通過(guò)對(duì)任務(wù)的調(diào)度實(shí)現(xiàn)類似cgroup的時(shí)間片邏輯。
舉個(gè)例子，一張卡上跑著A、B兩個(gè)服務(wù)，分別使用0.8卡和0.2卡的資源。那么A、B兩個(gè)服務(wù)在1s內(nèi)就分別被分配了800ms和200ms的任務(wù)運(yùn)行時(shí)間。如果B服務(wù)在這個(gè)周期的任務(wù)運(yùn)行時(shí)間超了，比如到210ms，那么在下一個(gè)周期就進(jìn)行懲罰，只允許運(yùn)行190ms。通過(guò)這種方式，可以在一個(gè)相對(duì)長(zhǎng)的周期內(nèi)有較好的切分效果。但cuda這一層任務(wù)的粒度偏大，有些任務(wù)運(yùn)行時(shí)間較長(zhǎng)。假設(shè)B服務(wù)有一個(gè)任務(wù)需要300ms才能運(yùn)行完。那在一秒內(nèi)就超過(guò)了限制，會(huì)選擇一些懲罰措施，如下一秒扣100ms，只讓B服務(wù)運(yùn)行100ms，毛刺效果就會(huì)特別劇烈。那么該怎么來(lái)解，讓我們?cè)偻驴聪拢瑑?nèi)核這一層任務(wù)粒度更小，一般在幾毫秒。在這塊進(jìn)行代理可以實(shí)現(xiàn)更為精準(zhǔn)的時(shí)間片邏輯。各家云廠商均實(shí)現(xiàn)了類似效果，作業(yè)幫通過(guò)和各家云廠商合作，就實(shí)現(xiàn)了精準(zhǔn)的GPU共享能力。
有了服務(wù)隔離能力后，下一個(gè)就是自定義調(diào)度能力。自定義調(diào)度有兩塊基礎(chǔ)，決策數(shù)據(jù)獲取和基礎(chǔ)調(diào)度策略。決策數(shù)據(jù)這塊，只通過(guò)request limit這些靜態(tài)指標(biāo)遠(yuǎn)遠(yuǎn)不夠，我們通過(guò)promethues做實(shí)時(shí)指標(biāo)采集，不光有node、GPU卡的各種監(jiān)控信息，還通過(guò)service mesh獲取服務(wù)運(yùn)行信息，有了這些數(shù)據(jù)就可以進(jìn)行更精準(zhǔn)地調(diào)度。調(diào)度主要有兩種策略，堆疊和平鋪。平鋪是將多個(gè)pod打散部署到多臺(tái)node多張卡上，主要適用于單個(gè)服務(wù)的多個(gè)實(shí)例部署，避免單卡故障后對(duì)服務(wù)影響過(guò)大。堆疊是將多個(gè)pod盡量部署到一臺(tái)node甚至一張卡上，主要是針對(duì)不同服務(wù)的pod實(shí)例，用于提升資源利用率。
有了這些基礎(chǔ)能力后我們來(lái)看下具體的應(yīng)用場(chǎng)景。首先是在線服務(wù)的調(diào)度，所有的業(yè)務(wù)都基于一個(gè)資源池，做各種HPA的策略。HPA策略包含手動(dòng)、auto、Cron等方式。由于GPU資源很難有像CPU那樣的Buffer池，更多是針對(duì)不同業(yè)務(wù)的使用時(shí)間來(lái)做cronHPA的策略。通過(guò)不同業(yè)務(wù)之間的復(fù)用，有千卡級(jí)別的資源節(jié)省。雖然做了不同業(yè)務(wù)的分時(shí)復(fù)用，但整個(gè)在線集群還是有明顯的波峰波谷，這時(shí)就需要在波谷時(shí)把離線任務(wù)調(diào)度到在線集群。
AIGC的離線任務(wù)主要有各種離線推理任務(wù)、多模態(tài)的訓(xùn)練任務(wù)。不同離線任務(wù)對(duì)資源的使用情況是不一樣的，比如一些訓(xùn)練任務(wù)對(duì)整臺(tái)node CPU、GPU資源使用比較機(jī)制，再調(diào)度前就需要先探測(cè)集群內(nèi)資源情況，若沒(méi)有足夠的資源，就會(huì)發(fā)起重調(diào)度，已實(shí)現(xiàn)全局最優(yōu)的堆疊效果。對(duì)于使用資源不多的離線推理任務(wù)，通過(guò)GPU共享技術(shù)和在線業(yè)務(wù)復(fù)用GPU卡資源，當(dāng)離線任務(wù)完成計(jì)算后，需要將服務(wù)從node上清退，來(lái)釋放占用的顯存、磁盤資源。
作業(yè)幫當(dāng)前有眾多GPU在離線混部。作業(yè)幫也在積極使用彈性的GPU資源。Serverless有兩種技術(shù)選型，函數(shù)計(jì)算和虛擬節(jié)點(diǎn)。從業(yè)務(wù)易用性角度出發(fā)，作業(yè)幫選擇了虛擬節(jié)點(diǎn)方案，對(duì)業(yè)務(wù)服務(wù)而言調(diào)度到普通節(jié)點(diǎn)還是虛擬節(jié)點(diǎn)，效果都是一樣的。Log Trace Metric等觀測(cè)信息也完成了對(duì)齊。當(dāng)前作業(yè)幫彈性資源剛開(kāi)始和云廠商探索，約有百卡級(jí)別的資源使用。通過(guò)這一系列操作，大大降低了GPU推理的成本。
下面我講下DevSecOps，聊這個(gè)之前首先要明確一個(gè)問(wèn)題，大模型服務(wù)的模型文件算什么？是代碼環(huán)境，還是數(shù)據(jù)。這個(gè)問(wèn)題直接決定我們選擇什么樣的分發(fā)方案。代碼環(huán)境，顧名思義，像研發(fā)用Golang、PHP等編程語(yǔ)言寫(xiě)的代碼、代碼依賴的配置、基礎(chǔ)鏡像等。走的是鏡像分發(fā)的模式；數(shù)據(jù)對(duì)應(yīng)的存儲(chǔ)方式就比較多樣，既可存在專門的數(shù)據(jù)存儲(chǔ)組件，MySQL、Redis，也可以使用共享文件系統(tǒng)NFS。作業(yè)幫檢索系統(tǒng)的容器化也是將數(shù)據(jù)卸載到JindoRuntime這樣的分布式緩存系統(tǒng)。這套方案在大模型訓(xùn)練中也廣泛應(yīng)用。那么大模型推理該選擇什么樣的方案呢，從表面上看數(shù)據(jù)文件規(guī)模一般較大，模型文件是符合這個(gè)特征的。但是從本質(zhì)來(lái)看，模型文件不會(huì)隨業(yè)務(wù)規(guī)模擴(kuò)大而擴(kuò)大，以及需要較強(qiáng)的版本管理能力，基于此我們認(rèn)定模型文件為環(huán)境的一部分，應(yīng)該選擇鏡像分發(fā)的流程。
在整個(gè)DevOps流程中我們應(yīng)該做什么呢，從代碼編寫(xiě)到編譯、測(cè)試、定版、發(fā)布以及線上運(yùn)維這個(gè)完整周期中。整個(gè)過(guò)程中CI/CD部分比較復(fù)雜，后面會(huì)詳細(xì)來(lái)說(shuō)。這里先介紹下其他部分。
編碼這塊，基礎(chǔ)架構(gòu)提供了cg平臺(tái)，可一鍵生成項(xiàng)目，其中包含基礎(chǔ)鏡像、推理框架、云原生套件。云原生套件包括標(biāo)準(zhǔn)日志輸出、readyness接口、配套的service mesh等。
測(cè)試這塊，GPU作為比較昂貴的資源，不會(huì)在測(cè)試環(huán)境預(yù)留，但生產(chǎn)環(huán)境和測(cè)試環(huán)境有網(wǎng)絡(luò)安全域隔離。這里就需要使用DMZ做授信的打通，進(jìn)而實(shí)現(xiàn)安全嚴(yán)格性和業(yè)務(wù)靈活性的平衡。
監(jiān)控這塊，大家會(huì)發(fā)現(xiàn)GPU的監(jiān)控鋸齒狀明顯，不像CPU監(jiān)控比較平滑。服務(wù)正常時(shí)和異常時(shí)差異不大，作業(yè)幫通過(guò)ServiceMesh可以更有效觀察服務(wù)的狀態(tài)。
下面來(lái)講下CI/CD的流程。在CPU時(shí)代，本地完成代碼的編寫(xiě)后提交到遠(yuǎn)端的Git Server。Git Server綁定了鉤子，提交會(huì)觸發(fā)CI Server對(duì)commit編譯為鏡像，然后再推送到權(quán)威鏡像倉(cāng)庫(kù)harbor當(dāng)中。這樣就完成CI流程。當(dāng)研發(fā)點(diǎn)擊部署按鈕時(shí)觸發(fā)k8s集群部署。K8s集群會(huì)先從docker-registry中拉取鏡像，若docker-registry中不存在，再?gòu)钠渖下?lián)的harbor中拉取，最終完成部署操作。
大模型文件納入DevOps的第一挑戰(zhàn)是文件太大，無(wú)法上傳到Git。這塊使用Git LFS，Git大文件存儲(chǔ)技術(shù)來(lái)解決。模型文件直接從源頭——訓(xùn)練機(jī)器上傳。Git提交時(shí)分成兩段提交，模型文件提交到lfs系統(tǒng)，指針文件提交到Git，兩者之間有映射關(guān)系。完成提交后也是一樣的鏡像編譯過(guò)程。部署如果再等到研發(fā)手動(dòng)點(diǎn)擊，就會(huì)將等待時(shí)間進(jìn)一步拉長(zhǎng)。所以這塊做的第一個(gè)優(yōu)化是當(dāng)鏡像上傳到harbor后k8s集群就會(huì)運(yùn)行一個(gè)job來(lái)提前拉取鏡像，做到鏡像文件的預(yù)熱。
前面提到過(guò)作業(yè)幫的推理集群分布在多個(gè)云多個(gè)region，這塊給鏡像分發(fā)帶來(lái)了挑戰(zhàn)。多集群之間分發(fā)很自然會(huì)想到P2P技術(shù)，這個(gè)可極大提升傳輸效率。但該方案有一定復(fù)雜性，問(wèn)題排查難度偏高。所以這塊集群分發(fā)我們使用的是對(duì)象存儲(chǔ)的DTS，簡(jiǎn)單可靠，也可以在較短時(shí)間內(nèi)完成傳輸。最后我們?cè)阽R像傳輸?shù)沫h(huán)節(jié)也做了切分，加速整個(gè)環(huán)境。經(jīng)過(guò)上述的優(yōu)化，百G文件的分發(fā)我們可以從6個(gè)小時(shí)，縮短80%，降低到45分鐘左右，大幅提升了研發(fā)效率。
但這一切還沒(méi)有結(jié)束，我們還要在DevOps整個(gè)過(guò)程中做到端到端的加密，實(shí)現(xiàn)真正的DevSecOps。這塊我們借鑒之前治理敏感數(shù)據(jù)的KMS方案，選擇對(duì)大模型文件也進(jìn)行加密處理。
具體做法是在訓(xùn)練機(jī)器的pre commit階段添加鉤子，提交前先對(duì)模型文件進(jìn)行切分，切分成核心文件和非核心部分，核心文件一般幾十MB，然后對(duì)核心文件遠(yuǎn)程獲取密鑰進(jìn)行加密，再將這加密的核心文件和未加密的非核心文件一起提交Git，再經(jīng)過(guò)編譯和部署這些階段，最終模型文件都落到k8s集群中。
此時(shí)大模型服務(wù)是無(wú)法讀取此類文件的，有三種解法。第一種，是對(duì)所有的大模型工程進(jìn)行修改，在代碼邏輯中實(shí)現(xiàn)解密和合并這些邏輯，但這樣的影響面過(guò)大。我們一開(kāi)始選擇的是第二個(gè)方案，在大模型程序運(yùn)行前，先執(zhí)行init程序，將加密的核心文件解密，再和非核心文件合并成原始的模型文件，這樣大模型程序就可以正常識(shí)別了。該方案雖然解決了問(wèn)題，但存在幾個(gè)弊端。一是整個(gè)流程涉及多個(gè)文件操作，耗時(shí)較長(zhǎng)，約30分鐘。另一個(gè)是這樣模型文件就會(huì)在磁盤中落地，違背了我們端到端加密的原則。所以我們優(yōu)化到第三個(gè)方案，我們hook了系統(tǒng)文件讀取函數(shù)。當(dāng)讀取到大模型文件時(shí)，我們?cè)谶@一次函數(shù)調(diào)用中先讀取加密的核心文件解密后輸出，再讀取非核心文件進(jìn)行輸出。整個(gè)操作都是內(nèi)存中，既安全可靠，耗時(shí)也縮短到11分鐘。至此完成了大模型DevSecOps的體系。
我們來(lái)看異構(gòu)算力網(wǎng)絡(luò)。在CPU時(shí)代，作業(yè)幫出于對(duì)穩(wěn)定性的極致追求，最終建成了一套多云的架構(gòu)。多云架構(gòu)有眾多技術(shù)選型，如主備多云，只把另一個(gè)云做成存儲(chǔ)的備份。又或者業(yè)務(wù)切分多云，將不同的業(yè)務(wù)單云部署到不同的云廠商。面對(duì)這么多選型，作業(yè)幫最終選擇了多活多云的方案。多活方案是穩(wěn)定性和成本的最優(yōu)解之一，但復(fù)雜性也是最高的。整套架構(gòu)的流程是用戶的流量通過(guò)DNS/DoH按照一定比例指到各個(gè)云的流量入口-網(wǎng)關(guān)，網(wǎng)關(guān)再轉(zhuǎn)發(fā)到具體的微服務(wù)，再往下就是微服務(wù)之間的相互調(diào)用。
為了能夠?qū)崿F(xiàn)單云閉環(huán)，要在每個(gè)云廠商部署所有的服務(wù)，以及服務(wù)與服務(wù)之間使用svc的調(diào)用方式。但這個(gè)仍不能100%防止墑增，且在一些特殊情況下仍需要進(jìn)行跨云通信。比如某種資源只在一個(gè)云獨(dú)有，又比如某個(gè)服務(wù)在單個(gè)云出現(xiàn)異常，需要緊急止損。所以需要一套既保證隔離的嚴(yán)格性又有一定靈活性的方案，就是如此的矛盾。
作業(yè)幫經(jīng)過(guò)設(shè)計(jì)，最終達(dá)成了這樣的效果。我們?cè)贑PE設(shè)備上設(shè)置ACL，從網(wǎng)絡(luò)層實(shí)現(xiàn)了強(qiáng)割裂，拒止不同云應(yīng)用服務(wù)的流量，做到嚴(yán)格性。但通過(guò)東西向網(wǎng)關(guān)這樣的基礎(chǔ)組件，允許授權(quán)的服務(wù)進(jìn)行跨云通信，以此就做到了靈活性。當(dāng)單邊云機(jī)房出現(xiàn)故障時(shí)，我們只要把流量切到另一邊，就可以快速止損。整套架構(gòu)是比較理想的。
但到了GPU時(shí)代就發(fā)生了變化，我們的CPU服務(wù)還是部署在北京的不同云機(jī)房，但GPU服務(wù)散落在全國(guó)各地，很多機(jī)房也沒(méi)有專線內(nèi)網(wǎng)直通。業(yè)務(wù)不得不選擇使用公網(wǎng)域名通信的方式，被迫把東西向通信變成了南北向通信。原有的注冊(cè)發(fā)現(xiàn)機(jī)制也被打破了，機(jī)房概念對(duì)業(yè)務(wù)不再透明。業(yè)務(wù)需要知道下游的GPU資源具體分布在哪個(gè)機(jī)房，有多少容量，然后進(jìn)行調(diào)用。如果下游出現(xiàn)資源的變化，GPU云機(jī)房發(fā)生變化了，上游業(yè)務(wù)還需要配合進(jìn)行調(diào)整。以及走公網(wǎng)的情況下，安全和性能等方面也往往存在問(wèn)題。安全方面，一旦業(yè)務(wù)的鑒權(quán)做的不好，就會(huì)出現(xiàn)大模型服務(wù)被刷的風(fēng)險(xiǎn)。性能方面，連接池維護(hù)不好的情況下，每次都要重新建立TCP連接、TLS連接，耗時(shí)被大幅度增加了。
基礎(chǔ)架構(gòu)發(fā)現(xiàn)這個(gè)問(wèn)題后，對(duì)東西向網(wǎng)關(guān)進(jìn)行了升級(jí)，變成了全新的集群間mesh-k8s mesh方案。要達(dá)成的目標(biāo)是重新讓部署信息對(duì)業(yè)務(wù)透明，這樣才能解除耦合。業(yè)務(wù)服務(wù)訪問(wèn)大模型服務(wù)仍使用svc域名的方式，具體實(shí)現(xiàn)方案是在集群CoreDNS這塊做文章，對(duì)缺省的服務(wù)，解析到k8s mesh。K8s mesh知道跨集群的注冊(cè)發(fā)現(xiàn)信息，然后會(huì)在不同集群間尋到最合適的流量路徑。對(duì)于有大模型服務(wù)的云機(jī)房，其入向流量也是先由k8s mesh承接。因?yàn)榱髁康膬深^都是我們可控的服務(wù)，我們可以自簽加密方式，解決了安全性。又通過(guò)自定義詞典的方式，大幅度壓縮跨集群的數(shù)據(jù)傳輸包，最多可實(shí)現(xiàn)50%的壓縮率，大大提升了傳輸性能。
整套方案的基礎(chǔ)框架就完成了，在過(guò)程中也出現(xiàn)了新的變化，比如今年云廠商在我們?cè)械谋本﹔egion又可以提供一部分L20、H20。對(duì)于大模型服務(wù)能閉環(huán)在一個(gè)機(jī)房肯定是更理想的方案。但由于大模型服務(wù)在當(dāng)前機(jī)房不再缺省，走CoreDNS的方案就走不通了。這塊我們基于service mesh攔截出向流量，在這塊重新定義了流量路由規(guī)則，優(yōu)先分發(fā)到本機(jī)房?jī)?nèi)的服務(wù)，如果無(wú)法承接再走k8s mesh的跨集群分發(fā)。
以上就是基礎(chǔ)架構(gòu)當(dāng)前做的主要建設(shè)了，關(guān)于未來(lái)展望我是這么想的。云原生能助力AIGC的方面還遠(yuǎn)遠(yuǎn)沒(méi)有挖掘透徹，隨著業(yè)務(wù)推理規(guī)模的進(jìn)行提升，會(huì)有更多新的技術(shù)。在性能優(yōu)化這個(gè)方面，前一段時(shí)間看到月之暗面的mooncake分離式架構(gòu)，以及針對(duì)kv cache的store方案。后面作業(yè)幫也會(huì)深入探索下。
另一方面，我們來(lái)聊下AIGC對(duì)云原生的反哺作用。不知道今天有多少同學(xué)是做基礎(chǔ)架構(gòu)的，有多少同學(xué)是做業(yè)務(wù)研發(fā)的。不知道大家有沒(méi)有發(fā)現(xiàn)這么一個(gè)趨勢(shì)，隨著云原生的深入，業(yè)務(wù)研發(fā)越來(lái)越聚焦到業(yè)務(wù)，越來(lái)越多的非功能邏輯由基礎(chǔ)設(shè)施來(lái)承接。分工越來(lái)越明確。但在基礎(chǔ)架構(gòu)人員不變的情況下，單個(gè)人力支撐的基礎(chǔ)服務(wù)也越來(lái)越多。這種情況下很容易觸發(fā)人力不足支撐變差的惡性循環(huán)。此前我們使用了一些偏管理偏協(xié)同的方案，為業(yè)務(wù)線的架構(gòu)師賦能等等，收效一般。而大模型的出現(xiàn)給了我們解決問(wèn)題新的思路。不管是AIops 問(wèn)題的根因分析，還是智能客服 能自動(dòng)解答一些咨詢問(wèn)題。希望能再通過(guò)半年左右的完善，達(dá)到一個(gè)更理想的狀態(tài)，也希望明年可以給大家來(lái)匯報(bào)我們新的進(jìn)展。
以上就是我今天分享的全部?jī)?nèi)容，謝謝大家。
