科技史一再證明，我們常低估未來的發(fā)展速度。正如第一臺重達(dá)30噸的計(jì)算機(jī)ENIAC，或“640K內(nèi)存足夠”的論斷，都無法預(yù)見如今遠(yuǎn)超其億萬倍算力的設(shè)備已普及到個人。

今天，我們可能正處在新的“ENIAC時(shí)刻”。訓(xùn)練類似GPT-4的頂尖大語言模型，因其對海量數(shù)據(jù)、龐大算力集群和巨額資金的極端要求，已成為少數(shù)科技巨頭的“權(quán)力的游戲”。

然而，這或許也是一個新的“640K時(shí)刻”。未來若出現(xiàn)量子計(jì)算或基于多值邏輯、新材料的芯片，可能會帶來計(jì)算效率的指數(shù)級提升，瓦解今天的算力與成本壁壘。

屆時(shí)，大模型的訓(xùn)練門檻將急劇降低，個人與小團(tuán)隊(duì)也能負(fù)擔(dān)。眾多開發(fā)者將不再局限是調(diào)用模型API的應(yīng)用開發(fā)，而是能利用自有數(shù)據(jù)，從零開始創(chuàng)造真正屬于自己的“垂域大模型”。

這種轉(zhuǎn)變將使開發(fā)者的焦點(diǎn)從“使用模型”回歸到“創(chuàng)造模型”，并開始思考一套圍繞大模型敏捷開發(fā)、版本控制和持續(xù)集成的自動化流程，從而開啟大模型開發(fā)的成熟階段。

DevOps

如果問10個工程師DevOps是什么，可能會得到11個不同的答案，說它是一套工具，是一種流程，是一種職位等等。

DevOps是一種文化哲學(xué)與方法論，其核心目標(biāo)是打破開發(fā)與運(yùn)維團(tuán)隊(duì)間的“部門墻”，實(shí)現(xiàn)緊密協(xié)作，從而更快、更可靠地交付高質(zhì)量軟件。它是理解一個軟件團(tuán)隊(duì)如何從代碼開發(fā)到產(chǎn)品穩(wěn)定運(yùn)行全過程的最佳切入點(diǎn)。

DevOps為何誕生

在沒有DevOps的時(shí)代，開發(fā)與運(yùn)維的目標(biāo)天然對立：

• 開發(fā) (Dev): 追求“快”，希望快速上線新功能。
• 運(yùn)維 (Ops): 追求“穩(wěn)”，希望線上服務(wù)7x24小時(shí)不宕機(jī)，抵觸變更。

這種對立導(dǎo)致了“部門墻”，帶來了交付周期長、部署頻繁出錯、以及開發(fā)和運(yùn)維互相推諉等問題，嚴(yán)重阻礙了效率和創(chuàng)新。DevOps的誕生就是為了推倒這堵墻。

DevOps的核心實(shí)踐與術(shù)語

如果說DevOps是一種文化目標(biāo)，那么以下術(shù)語是實(shí)現(xiàn)該目標(biāo)的關(guān)鍵技術(shù)實(shí)踐：

• CI/CD(持續(xù)集成/持續(xù)交付與部署)：一條自動化的代碼“高速公路”，是實(shí)現(xiàn)DevOps自動化理念的核心技術(shù)實(shí)踐。
• IaC(基礎(chǔ)設(shè)施即代碼)：用代碼來定義和管理服務(wù)器、網(wǎng)絡(luò)等基礎(chǔ)設(shè)施，極大地提升了環(huán)境一致性與自動化水平。
• 可觀測性：通過統(tǒng)一的日志、指標(biāo)和追蹤數(shù)據(jù)，為團(tuán)隊(duì)提供透明的系統(tǒng)健康視圖，是實(shí)現(xiàn)DevOps中共享與度量的關(guān)鍵基礎(chǔ)。

從應(yīng)用到智能的DevOps范式變遷

DevOps的演進(jìn)與軟件架構(gòu)的變革緊密相連，可劃分為三個相互關(guān)聯(lián)的核心領(lǐng)域：Application DevOps、DataOps 和 ModelOps。它們的演進(jìn)有兩大核心動力驅(qū)動：

• 橫軸 - 數(shù)據(jù)價(jià)值鏈：從左至右，價(jià)值密度不斷提升。Application產(chǎn)生原始數(shù)據(jù)，Data將其提煉為信息，Model最終將其升華為智能。
• 縱軸 - 技術(shù)成熟度：在各自領(lǐng)域內(nèi)，為突破瓶頸而發(fā)生的技術(shù)迭代。
• 這是一個閉環(huán)的價(jià)值飛輪：Application DevOps產(chǎn)生原始數(shù)據(jù)，DataOps將其提煉為高質(zhì)量的訓(xùn)練數(shù)據(jù)，ModelOps則利用這些數(shù)據(jù)創(chuàng)造出智能并通過API反哺應(yīng)用，最終驅(qū)動整個系統(tǒng)完成自我優(yōu)化的閉環(huán)。

三大領(lǐng)域的演進(jìn)路徑

• Application DevOps 通過從單體架構(gòu)演進(jìn)到微服務(wù)，按業(yè)務(wù)能力拆分服務(wù)，解決了組織規(guī)?；钠款i。
• DataOps 則借鑒了類似的“按領(lǐng)域劃分”思想，從中央數(shù)據(jù)倉庫演進(jìn)到數(shù)據(jù)網(wǎng)格，將數(shù)據(jù)所有權(quán)下放給業(yè)務(wù)團(tuán)隊(duì)，解決了數(shù)據(jù)服務(wù)的瓶頸。數(shù)據(jù)網(wǎng)格的領(lǐng)域劃分理念，與 Application 開發(fā)中的DDD方法論高度契合，共同指向了“按照領(lǐng)域劃分責(zé)任”的核心原則。
• ModelOps 的演進(jìn)是由技術(shù)本身的范式躍遷驅(qū)動的，隨著大語言模型的出現(xiàn)，它從服務(wù)于“預(yù)測器”的MLOps，發(fā)展出專為應(yīng)對“推理引擎”獨(dú)特挑戰(zhàn)的LLMOps。

中心化與去中心化的逆轉(zhuǎn)

一個值得注意的趨勢是，當(dāng)應(yīng)用和數(shù)據(jù)領(lǐng)域都從中心化走向去中心化時(shí)，模型領(lǐng)域卻恰恰相反。MLOps時(shí)代傾向于有多個分散的專用小模型，而LLMOps時(shí)代則呈現(xiàn)出明顯的“再中心化”趨勢，即依賴于一個或幾個巨大的、中心化的基礎(chǔ)模型（如GPT-4）。

Application DevOps

現(xiàn)代應(yīng)用開發(fā)已進(jìn)入云原生微服務(wù)時(shí)代，其核心實(shí)踐是解決微服務(wù)架構(gòu)帶來的運(yùn)維復(fù)雜性。

從微服務(wù)到云原生：解決不同階段的問題

• 微服務(wù) (Microservices)：作為一種架構(gòu)風(fēng)格，它通過將單體應(yīng)用拆分為小服務(wù)，解決了開發(fā)瓶頸，提升了團(tuán)隊(duì)敏捷性。但它也帶來了巨大的運(yùn)維噩夢。
• 云原生 (Cloud-Native)：作為一套技術(shù)和方法論，它通過自動化、彈性和可擴(kuò)展的方式，提供了管理這支龐大微服務(wù)“艦隊(duì)”的“指揮中心”，從而解決了微服務(wù)的運(yùn)維難題。

云原生微服務(wù)DevOps流程

最先進(jìn)的云原生DevOps范式是GitOps，其核心思想是：以Git倉庫作為管理基礎(chǔ)設(shè)施和應(yīng)用的唯一可信源。開發(fā)者通過“聲明”期望狀態(tài)，而非執(zhí)行命令來驅(qū)動部署。

以下是GitOps流程的四個關(guān)鍵階段：

• 開發(fā)與CI（持續(xù)集成）。開發(fā)者提交代碼后，CI/CD流水線自動將其構(gòu)建、測試并打包成一個標(biāo)準(zhǔn)化的容器鏡像，然后推送到鏡像倉庫。構(gòu)建產(chǎn)物從模糊的軟件包轉(zhuǎn)變?yōu)榘姹久鞔_、環(huán)境一致的容器。
• 部署與CD（持續(xù)部署）。開發(fā)者通過修改一個專門的Git部署配置倉庫中的YAML文件來“聲明”應(yīng)用的目標(biāo)狀態(tài)。這一變更通過代碼審查后合并。這是從“命令式”部署到“聲明式”部署的革命性轉(zhuǎn)變。

• 自動化同步與編排GitOps控制器持續(xù)監(jiān)控部署倉庫。一旦發(fā)現(xiàn)Git中聲明的“期望狀態(tài)”與Kubernetes集群的“實(shí)際狀態(tài)”不符，它會自動觸發(fā)部署，使集群狀態(tài)與Git中的聲明保持一致。
• 運(yùn)行與可觀測性新版本上線后，通過可觀測性平臺對服務(wù)的Metrics、Logs和Traces進(jìn)行全面監(jiān)控。這使得團(tuán)隊(duì)能深入理解復(fù)雜系統(tǒng)的內(nèi)部狀態(tài)，從被動監(jiān)控轉(zhuǎn)變?yōu)橹鲃佑^測，從而快速定位和解決未知問題。

DataOps

隨著應(yīng)用時(shí)代的繁榮，人類積累數(shù)據(jù)的速度倍速提升，這倒逼了大數(shù)據(jù)技術(shù)的進(jìn)步。

數(shù)據(jù)倉庫時(shí)代

大數(shù)據(jù)時(shí)代催生了DataOps。其早期形態(tài)是數(shù)據(jù)倉庫（Data Warehousing）時(shí)代，核心精神是中心化和控制。其目標(biāo)是構(gòu)建一個由中央數(shù)據(jù)團(tuán)隊(duì)統(tǒng)一管理的強(qiáng)大數(shù)據(jù)平臺（如數(shù)據(jù)倉庫、數(shù)據(jù)中臺），作為全公司唯一的、可信的數(shù)據(jù)來源。

傳統(tǒng)數(shù)倉的DevOps流程

該流程的核心是將數(shù)據(jù)處理任務(wù)（Job）作為交付單元，實(shí)現(xiàn)自動化。

• 開發(fā)與CI（持續(xù)集成）工程師根據(jù)業(yè)務(wù)需求編寫數(shù)據(jù)處理作業(yè)（如SQL、Spark代碼）。提交后，CI服務(wù)器會自動編譯、打包并運(yùn)行單元測試，最終生成軟件包。
• 測試與CD（持續(xù)部署）與應(yīng)用CD不同，數(shù)據(jù)CD的關(guān)鍵在于數(shù)據(jù)驗(yàn)證。

1.軟件包首先被部署到測試環(huán)境。

2.在測試環(huán)境中運(yùn)行作業(yè)，并自動驗(yàn)證產(chǎn)出數(shù)據(jù)的格式、質(zhì)量和核心指標(biāo)是否符合預(yù)期。

3.只有通過驗(yàn)證，CD流水線才會更新生產(chǎn)環(huán)境的調(diào)度系統(tǒng)中的作業(yè)版本。

• 作業(yè)調(diào)度生產(chǎn)環(huán)境的調(diào)度系統(tǒng)按計(jì)劃執(zhí)行批處理或?qū)崟r(shí)作業(yè)，在數(shù)據(jù)湖/倉平臺上對數(shù)據(jù)進(jìn)行分層處理，最終將清洗、加工后的數(shù)據(jù)寫入數(shù)據(jù)倉庫。
• 消費(fèi)與運(yùn)維

1.消費(fèi)：最終的數(shù)據(jù)被用于生成BI報(bào)表或通過API提供服務(wù)。

2.運(yùn)維：此階段DevOps的核心是保障成千上萬個數(shù)據(jù)作業(yè)（Task/Job）的成功運(yùn)行和時(shí)效性。當(dāng)作業(yè)失敗或數(shù)據(jù)延遲時(shí)，On-Call工程師會介入排查日志，定位問題。

現(xiàn)代數(shù)據(jù)棧與數(shù)據(jù)網(wǎng)格時(shí)代

此階段的精神內(nèi)核是去中心化、自動化和產(chǎn)品化。它旨在打破中央數(shù)據(jù)團(tuán)隊(duì)的瓶頸，通過賦能離業(yè)務(wù)最近的領(lǐng)域團(tuán)隊(duì)，讓他們能夠快速、可靠地開發(fā)和交付可信賴的數(shù)據(jù)產(chǎn)品。這一理念被稱為數(shù)據(jù)網(wǎng)格 (Data Mesh)，其技術(shù)基石是現(xiàn)代數(shù)據(jù)棧 (Modern Data Stack)。

現(xiàn)代數(shù)據(jù)棧與數(shù)據(jù)網(wǎng)格時(shí)代的DevOps流程

下圖是從“分析市場活動對銷售額的影響”這個需求為牽引，來展示在數(shù)據(jù)網(wǎng)格時(shí)代DevOps的流程。

在此模式下，組織結(jié)構(gòu)和工作流程發(fā)生根本性轉(zhuǎn)變：

1.自助式數(shù)據(jù)平臺（賦能者）中央團(tuán)隊(duì)的角色從“數(shù)據(jù)報(bào)表工廠”轉(zhuǎn)變?yōu)槠脚_構(gòu)建者。他們不再直接處理業(yè)務(wù)需求，而是提供一個強(qiáng)大的自助式數(shù)據(jù)平臺，其核心產(chǎn)出是能力和模板，包括：

• CI/CD模板：提供標(biāo)準(zhǔn)化的自動化測試、代碼檢查和部署規(guī)則，使數(shù)據(jù)管道即代碼(Pipelines as Code) 成為可能。
• 統(tǒng)一的數(shù)據(jù)編排與治理：提供統(tǒng)一的數(shù)據(jù)管道編排器和聯(lián)邦查詢引擎，確保所有數(shù)據(jù)產(chǎn)品能夠互聯(lián)互通。
• 數(shù)據(jù)可觀測性服務(wù)：監(jiān)控焦點(diǎn)從“任務(wù)是否成功”轉(zhuǎn)變?yōu)椤皵?shù)據(jù)本身是否可信”，主動監(jiān)控?cái)?shù)據(jù)的新鮮度、分布和模式等健康狀況。

2.領(lǐng)域團(tuán)隊(duì)（生產(chǎn)者）
領(lǐng)域團(tuán)隊(duì)（如銷售、市場團(tuán)隊(duì)）擁有自己領(lǐng)域內(nèi)的數(shù)據(jù)，并利用中央平臺提供的工具和模板，自主地開發(fā)、測試和運(yùn)維自己的“數(shù)據(jù)產(chǎn)品”。他們對自己的數(shù)據(jù)產(chǎn)品質(zhì)量和交付負(fù)全責(zé)。

3.跨域消費(fèi)（消費(fèi)者）當(dāng)需要進(jìn)行跨領(lǐng)域分析時(shí)，消費(fèi)者可以通過兩種主要方式實(shí)現(xiàn)：

• 聯(lián)邦查詢：使用平臺提供的查詢引擎，直接用一條SQL語句跨域聯(lián)合查詢多個數(shù)據(jù)產(chǎn)品。
• 創(chuàng)建聚合數(shù)據(jù)產(chǎn)品：消費(fèi)多個底層數(shù)據(jù)產(chǎn)品，并將它們組合成一個新的、更高階的數(shù)據(jù)產(chǎn)品。

ModelOps

ModelOps的出現(xiàn)，旨在解決將機(jī)器學(xué)習(xí)模型從實(shí)驗(yàn)環(huán)境成功部署到生產(chǎn)環(huán)境并持續(xù)創(chuàng)造價(jià)值的工程化挑戰(zhàn)。

在生成式AI興起之前，其主流實(shí)踐是MLOps，主要服務(wù)于預(yù)測式AI。

MLOps借鑒了DevOps的自動化思想，旨在將模型開發(fā)從“手工作坊”轉(zhuǎn)變?yōu)闃?biāo)準(zhǔn)化的“自動化生產(chǎn)線”，以解決模型的持續(xù)訓(xùn)練 (Continuous Training)和性能漂移 (Performance Drift)等核心工程挑戰(zhàn)。

MLOps

MLOps的核心是將傳統(tǒng)的CI/CD擴(kuò)展為CI/CT/CD（持續(xù)集成/持續(xù)訓(xùn)練/持續(xù)部署）。

MLOps流程

1.實(shí)驗(yàn)與開發(fā)數(shù)據(jù)科學(xué)家進(jìn)行模型探索與選型，并與工程師共同編寫特征工程和模型訓(xùn)練代碼。

2.持續(xù)集成與訓(xùn)練 (CI/CT) - 核心創(chuàng)新這是MLOps與傳統(tǒng)DevOps最大的不同，其流水線不僅由代碼變更觸發(fā)，還增加了新的觸發(fā)機(jī)制：

• 代碼驅(qū)動：當(dāng)模型算法或特征工程代碼更新時(shí)觸發(fā)。
• 數(shù)據(jù)驅(qū)動：當(dāng)新的訓(xùn)練數(shù)據(jù)積累到一定量時(shí)自動觸發(fā)，以保持模型“新鮮度”。
• 監(jiān)控驅(qū)動：當(dāng)線上模型的性能下降到預(yù)設(shè)閾值時(shí)，自動觸發(fā)再訓(xùn)練。

3.持續(xù)部署 (CD) 當(dāng)新模型被注冊后，CD流水線被觸發(fā)，將模型打包成API服務(wù)，并通過藍(lán)綠/金絲雀等策略安全地部署到生產(chǎn)環(huán)境。

4.監(jiān)控與反饋除了監(jiān)控常規(guī)的服務(wù)性能，MLOps的監(jiān)控焦點(diǎn)在于模型漂移：

• 數(shù)據(jù)漂移 (Data Drift)：線上實(shí)時(shí)數(shù)據(jù)的統(tǒng)計(jì)分布與訓(xùn)練數(shù)據(jù)發(fā)生顯著變化。
• 概念漂移 (Concept Drift)：數(shù)據(jù)與預(yù)測目標(biāo)之間的關(guān)系發(fā)生了改變。          

一旦檢測到嚴(yán)重漂移，系統(tǒng)將自動觸發(fā)再訓(xùn)練流程，形成一個閉環(huán)的自優(yōu)化系統(tǒng)。

LLMOps

LLMOps是MLOps的專門化演進(jìn)分支，旨在應(yīng)對生成式AI時(shí)代，以大語言模型為核心的應(yīng)用所帶來的全新工程挑戰(zhàn)。當(dāng)模型的核心任務(wù)從“預(yù)測”轉(zhuǎn)變?yōu)椤皠?chuàng)造、推理與交互”時(shí)，傳統(tǒng)的MLOps流程已不再適用。

LLM常見架構(gòu)

理解LLMOps需先了解LLM典型架構(gòu)，它圍繞一個核心，并由多個增強(qiáng)組件構(gòu)成：

• 基礎(chǔ)模型: 核心智能引擎（如GPT-4），負(fù)責(zé)理解、推理和生成。
• 上下文與提示詞工程: 管理對話歷史和系統(tǒng)指令，是與模型溝通的“指令區(qū)”。
• 檢索增強(qiáng)生成: 連接外部知識庫，解決模型知識陳舊和缺乏私有知識的問題。
• 智能體與工具調(diào)用: 賦予模型調(diào)用API、執(zhí)行代碼等與外部世界交互的“手腳”。
• 感官與安全系統(tǒng): 作為輸入/輸出的“防火墻”，負(fù)責(zé)安全審查和格式化處理。

LLMOps流程

LLMOps最大的創(chuàng)新在于，根據(jù)成本和是否需要重新訓(xùn)練模型，將CI/CD流程拆分為雙軌并行體系。

1.輕量CI/CD軌道（敏捷、低成本）

• 觸發(fā)源: 由Prompt、RAG知識庫、Agent代碼的變更觸發(fā)。
• 核心動作: 流程完全不涉及GPU訓(xùn)練，而是通過自動化評估(Evals)來快速驗(yàn)證變更效果，并更新相應(yīng)的組件（如Prompt模板、RAG索引）。

2.重型CI/CT軌道（戰(zhàn)略性、高成本）

• 觸發(fā)源: 僅當(dāng)用于微調(diào)的數(shù)據(jù)集更新時(shí)才會觸發(fā)。

結(jié)語

從應(yīng)用（Application）到數(shù)據(jù)（Data），再到模型（Model），DevOps的演進(jìn)展現(xiàn)了一條清晰的價(jià)值階梯：

• Application DevOps：將“功能”的交付從數(shù)月縮短至數(shù)小時(shí)，實(shí)現(xiàn)了業(yè)務(wù)敏捷。
• DataOps：將“洞察”的提煉從手工作坊升級為自動化工廠，實(shí)現(xiàn)了數(shù)據(jù)民主。
• ModelOps：正將“智能”的創(chuàng)造從不確定的“煉丹”轉(zhuǎn)變?yōu)榭啥攘?、可迭代的工程學(xué)科，以實(shí)現(xiàn)價(jià)值落地。

DevOps的終點(diǎn)并非某個工具或流程，而是對“更快、更可靠地創(chuàng)造價(jià)值”這一目標(biāo)的無限追求。從應(yīng)用到智能，這場變革仍在繼續(xù)。