亂彈 LLM 的工程化
@(Thoughts)
僅為個人觀點骄恶，亂彈而已僧鲁。
這一波 LLM 狂熱很有意思象泵，從現(xiàn)象上來看跟智能手機 + 移動互聯(lián)網(wǎng)那一撥有點相像。首先是 OpenAI 扮演了當年 Apple 的角色春寿，以 ChatGPT 這一殺手級產(chǎn)品攪動了一池春水绑改，此時整個學術界兄一、工業(yè)界及 AI 社區(qū)對 AI 表現(xiàn)出的那種食之無味瘾腰、棄之可惜的有限智能及其帶來的落地難，落地貴問題正束手無策费薄、踟躕不前栖雾，很多當年從學術界出山的臥龍鳳雛們也重新歸隱了學術界析藕，因此 ChatGPT 的出現(xiàn)確實也如明燈，點燃了士氣（當然也拯救了大家的職業(yè)生涯）竞慢。從這個角度看筹煮， 這是名副其實的 iPhone Moment。一炮打響之后就是考慮構建應用生態(tài)了本冲，圍繞 GPT 這一賦能型技術(enabling technology)檬洞，先是以 Microsoft 的 bing 為標桿試驗應用如何接入落地添怔，繼而開放 plugins 更大范圍地試驗 app store闷板。當然遮晚，無意外地拦止，出于能說得出來的和不能說得出來的各種原因，這一切到目前為止都是閉源萧求、基于 API 發(fā)展的夸政。但蛋糕大家都已經(jīng)看到了榴徐，你端出來讓大家看一眼坑资，然后說大家不要眼饞再拿回去，于情于理都是斷不可能的仿便。既然看見了嗽仪，肯定想得慌。那后面就是 iPhone 有 iPhone 的路枕屉，Android 有 Android 的路了搀擂。
在 iPhone 那條路上的還有當年 Windows Phone哨颂，不要忘了相种，:)寝并。在 LLM 的隱喻里，這條路上現(xiàn)在有很多無畏的創(chuàng)業(yè)者斤蔓。他(她)們有的是被這股熱浪卷到這條道路上的弦牡，只聽別人說這邊發(fā)雞蛋驾锰，不由自主地就排到這個隊里了走越；有的是堅信憑借自己現(xiàn)有的用戶基礎旨指、技術基礎、經(jīng)濟基礎等等可以拼一拼今缚，問鼎也未嘗不可姓言；也有的是深懷家國情懷，相信我們值得擁有一個自己的......不一而足何荚。這條路是艱險之路餐塘。對第二類踏上此路的英雄，我想說的是用戶基礎這種其實并不算什么護城河税手，消費主義的本質特征是其時間性和短暫性芦倒，誰帶來新的刺激兵扬，誰就帶走用戶口蝠，你們以此起家妙蔗，但此時可能忘了。
我們現(xiàn)在回到 Android 之路上狞谱，這條路可以容納的人會多一些禁漓。如果我們把 LLM 賦能的整個產(chǎn)業(yè)看成一個人的話：硬件可為其骨播歼，基礎軟件可為其肉秘狞，模型可為其魂烁试，而應用軟件即為其衣冠拢肆。我們由內及外展開。
硬件
硬件這條路支示，短期的贏家肯定是 NV颂鸿。長期來看嘴纺，如果我們認為這一塊長期仍會以單一 transformer 架構主導的話栽渴，如果我是 NV糖驴，我會覺得是壞事佛致。我會認為 AI workload 的 diversity 是 NV 當前市場地位的一個重要原因感昼。正是因為 AI workload 的 diversity定嗓，使得必須在通用性和性能之間取得最好的折衷宵溅。而目前CPU 夠通用但性能尚不足恃逻；ASIC 方案性能可以但不夠通用寇损，corner case 太多裳食，以至于客戶一聽新硬件的名字脫口而出 "CUDA 兼容嗎"，就是因為內部一堆 application 代碼里面手寫的 CUDA浊吏，定制的函數(shù)堆起來危如累卵，一動就散了配紫。但現(xiàn)在事情變了午阵，如果我們認為 LLM 是個非常有前途的單一 workload 的話底桂，完全可以出現(xiàn)為它服務的新硬件于个，只專心加速各種配置下的 transformer block 就行了暮顺，萬里長城修下了，沒想到敵人從海上登陸了羽氮，:(惫恼。只要模塊足夠標準化祈纯，就可以復刻當年 video codec 以及礦機芯片的故事腕窥。更長期來講，如果 ASIC 路線發(fā)展得好革娄，當前的霸主也會逐漸失去 hardware lottery 以及可以支持后續(xù)創(chuàng)新的 installation base，最終有可能導致循環(huán)不足而出現(xiàn)問題
匆浙。所以首尼，從硬件上來講言秸，個人認為這是一個好的窗口举畸，最大單一 workload 還是很誘人的抄沮。
基礎軟件
軟件需要承擔 LLM 的訓練叛买、微調和推理工作蹋订。目前露戒，基本軟件棧如下圖所示智什。我們可以看到，主要基礎軟件為 2+1谦炬，主干軟件為 Compute Engine 和 Parallelism Engine键思，支撐軟件為 Scheduler & Orchestration Engine吼鳞。
當然可以不需要支撐軟件直接在 OS 上裸跑叫搁，這也是傳統(tǒng) HPC 情境下的常見方式。但傳統(tǒng) HPC 情境的假設是“HPC 集群可視為一個魯棒的超級計算機疾党，多機如多核般魯棒”雪位，這個假設在 GPU 等加速器進入后被破壞掉了雹洗，OPT 和 BLOOM 的訓練都表明了這一點。
前期用 mpirun 和 手工+ specific 腳本恢復 沒有問題庇茫，因為前期的目的是證明 LLM 本身的可行性螃成。一旦證明可行性后，進入工程化階段后顷霹，仍使用這種方式肯定是不適應生產(chǎn)力發(fā)展的要求的淋淀。如何進行系統(tǒng)化的資源的自動發(fā)現(xiàn)朵纷、納管以及故障恢復袍辞，甚至如何進行云原生的部署常摧，這些都是需要考慮的問題落午，其中有些我們可以使用之前的經(jīng)驗溃斋，有些是 LLM 帶來的新問題，需要解決享甸。舉個例子蛉威，在訓練時猫妙，因為 LLM 訓練數(shù)據(jù)多割坠、訓練 epoch 少（BLOOM 只訓練了一個 epoch）彼哼，原本以 epoch 為粒度的 checkpoint resume 機制需要如何改進適應以 step 為粒度的 checkpoint resume 機制敢朱，這里引入的新問題因為 resume 以 step 為粒度了，我們需要考慮如何保持數(shù)據(jù)讀取狀態(tài)孝常，使得整個數(shù)據(jù)集的讀取不會再從頭開始构灸。當然還有其他的問題喜颁，比如資源的發(fā)現(xiàn)和納管如何支持新的加速器半开，一個例子是目前 Ray 再這一塊的實現(xiàn)是 overfit 到 NV GPU 的赃份，那新硬件怎么辦抓韩？大數(shù)據(jù)的大規(guī)模應用是以 Hadoop 為基礎的园蝠，那么 LLM 的大規(guī)模應用是以什么為基礎彪薛，如果我們認為是 Ray 的話善延，Ray 還需要哪些增強...... 我們聽到很多：Google 用 Ray易遣，OpenAI 用 Ray 訓練 GPT，Stability AI 用 Ray 訓練 Stable Diffusion 等等屋摇，但除此以外還沒有更多的工程層面的信息，對于上面提出的幾個問題目前也還沒看到公開的信息炮温，這些需要而且會一步步明朗柒啤。
再看 Parallelism Engine担巩，Alpa 和 DeepSpeed 都在其列涛癌，但都不能算是比較完善的軟件框架窥浪。以 DeepSpeed 為例祖很，這是一個深度耦合 NV GPU 的框架，對于其他加速器的 plugin 的接口設計仍然在推進中漾脂，更不消說新硬件的集成及其集成過程中可能遇到的問題了假颇。而從運行機制上來講，DeepSpeed 一開始以支持 kernel injection 為主骨稿，因為相應的 CUDA kernel 已經(jīng) ready笨鸡，這對新硬件非常不友好，最近已經(jīng)開始 enable auto TP 模式坦冠，但也需要時間來完善形耗。而 Alpa 目前對 PyTorch 的支持有限。
再看 Compute Engine辙浑，這一塊算是最 ready 的倦踢，以 PyTorch 為主，還有 JAX 和 TensorFlow褂微。但也不是完全風平浪靜，與硬件的想法一樣端衰，如果我們認為 transformer 的份額會大到足以有一個專用的硬件的話灭抑，那軟件也同理啊荤牍。是不是有可能不需要一個那么大而全且重的框架，ggml 是不是也可以？而且它可以橫跨端旱函、邊含长、云。
至此，我們對基礎軟件棧作了一個不完全的清點燕刻，即使是通過這個不完全的清點，我們也能感覺到在這個熱潮中，軟件是比較脆弱的部分，不深的軟件棧上有不少的洞脆诉，如果我們真的認同 LLM 是 industry 的下一個 Mr Right 的話，可能需要更多的軟件上的工作才能支撐它。
基礎軟件棧明晰化和系統(tǒng)化是重要的必要條件，不然就好像草臺班子很難支撐后續(xù)的scale out。但這不是充要條件，后續(xù)還需要基于基礎軟件棧的應用軟件棧把應用創(chuàng)新的門檻砍平汁胆。
模型
模型這個賽道可謂是擠滿了淘金者铸题。但我們真的靜下來想想的話，這條賽道的護城河其實是智力密度，也就是像 OpenAI 那樣的智力密度，為天下之先捉捅。這樣想想，可能能讓很多人冷靜下來，我們有沒有這個智力密度。如果只是拿著 Red Pajama 再加點很少的自己的數(shù)據(jù)，follow 或者集成別人的 best recipes 訓一個自己的模型损搬，感覺構不成任何核心價值弄匕，張三能做，李四也可以。因此，從這個角度看，在沒有智力優(yōu)勢的情況下赊舶，模型可能更多地起到錦上添花的作用。所以我們這里把模型比作魂夺英，無肉體的魂是鬼驯耻，不是人帘靡；而無魂的肉體是行尸走肉筒扒。也許最好的方式是 Meta 的方式：把小規(guī)格的模型及其權重以非商用的許可證的形式開源給社區(qū)村缸，借助社區(qū)的智力密度進行創(chuàng)新，然后獲得商用的原生性和獨家性垒拢；同時也獲得對大規(guī)格模型的集智寿弱。這其實比較好地結合了社區(qū)的智力密度和自身商用訴求鸯旁，也是 所說的
Owning the Ecosystem: Letting Open Source Work for Us 的題中之意。
再說直白一點鸠删，可能更好的方式可能是 infrastructure 廠商以 infrastructure 軟硬件為錦桨踪，以模型為花虱朵，最后形成 1+1>2 的局面蚯涮。僅憑模型有可能會成為無本之木。
應用
應用是最終繁榮的根本保證台猴，沒有應用的繁榮就沒有最終的繁榮俊柔。應用和模型在時間和空間上有兩重可能的阻隔。
第一重阻隔是時間上的憨闰，模型的訓練數(shù)據(jù)總是有起止時間的鹉动，超過這個起止時間的事實性信息并不為模型所捕獲，因此如何處理這種情況，避免輸出錯誤的時效性的事實信息呢闯狱？一種方法是重新訓練基礎模型媒抠，這個顯然是不經(jīng)濟同時也是不現(xiàn)實的，不經(jīng)濟是訓練成本貴统求，不現(xiàn)實是信息更新快模型重訓基本不可能趕上检碗。這個時候就要訴諸常識，人類如何處理這一情況呢码邻？答案是：人類主要通過查閱資料折剃，然后再組織答案的方法來完成。那我們依此行之就可以了像屋。此即 RAG（Retrieval Augmented Generator）架構怕犁，如下圖所示。
第二重阻隔是空間上的。我們知道應用大致可分成兩類：垂類應用和通用應用奏甫。而對于很多垂類應用戈轿，由于有較大一部分的行業(yè)或公司處于保護自身商業(yè)利益的考量有數(shù)據(jù)不出域的訴求，這就是空間上的阻隔扶檐。而 私域信息=私域語言信息 + 私域知識信息凶杖，舉個例子對法律領域而言，其私域語言信息是其獨特嚴謹?shù)恼Z言組織方式款筑，與我們日常的語言組織方式是不相同的智蝠；而其私域知識信息就是其專業(yè)術語體系。在垂類應用中奈梳，不僅數(shù)據(jù)不能出域杈湾，所以部署方式可能是 on-prem 為多，而且因為其語言信息和知識信息都具有其特點攘须，因此不僅需要前述的 RAG漆撞，而且需要對 LLM 進行微調以將模型牽引至相應領域的語言信息。因為是垂類于宙，對通用性的要求就比較低浮驳；因為是 on-prem 部署，可能就不能承擔超大模型的成本捞魁。因此至会，不需要也沒必要使用超大模型，幾 B 到幾十 B 的模型可能是最適合的谱俭。
以上從設計上解決了通用生成類任務以及單事項指令性任務奉件。但如果遇到多事項指令性任務怎么辦呢？HuggingGPT 指出了一條可能的路徑昆著。即用大規(guī)格的通用模型進行意圖識別和任務規(guī)劃县貌，然后將切分后的任務分發(fā)給垂類小規(guī)格模型來完成，最后再用通用模型進行結果綜合凑懂。
這種就比較復雜了煤痕，但可能這是最終的實際場景需求。如果走到最終場景時接谨，我們如何對域內/域外的能力進行整合杭攻，能做到數(shù)據(jù)不出域的情況下用好域外的能力。HuggingGPT 本質上是個 divide-execution-aggregation 模型疤坝，divide 部分應該不會涉及什么機密信息，所以可以域外進行馆铁，后面的垂類模型的 execution 部分在域內進行跑揉，各自做完后的 aggregation 因為所整合的信息基本都是域內信息，所以原方案中使用通用大規(guī)格模型的方法可能就行不通了，這里可能需要一個新的語言整合小規(guī)格模型幫助在域內完成最終的結果整合历谍，這個可能是 HuggingGPT 最終在垂類應用上的部署形態(tài)现拒。
要支撐這些應用，需要一套好用的“應用開發(fā)套件”望侈，應用開發(fā)者可以在這之上很輕松地開發(fā)應用印蔬，而不需要管 DeepSpeed, PyTorch 這種底層開發(fā)者的語言，從而分離各自的關注點脱衙。就像 Android 有 Android SDK 一樣侥猬，LLM 開發(fā)也需要有一個這樣的 LLM SDK，用于支持傻瓜式的模型 training, finetune 和 inference捐韩。
最后
如果我們相信 LLM 會像當年的智能手機一樣賦能一波新的繁榮退唠，那么可能我們希望它更像 Android 而不是 iPhone，這給了我們方向荤胁，但通往這個方向的路徑如何瞧预，還需要時間去澄清。
