今年是AI大爆發的一年，大語言模型的誕生推動了席捲整個行業的大模型熱潮，許多人認爲“AI的iPhone時代”到來了。訓練大模型其實不簡單，因爲模型參數量的增加意味着需要更好的算力、更多的數據去錘鍊，並且需要合適的工具讓開發者快速迭代模型，只有這樣才能更快地提高模型精度。這幾年來阿里雲一直在宣傳AI工程化和規模化，其實是這輪AI爆發的主要推手。
我們看一個典型的模型開發過程，包括數據預訓練、模型訓練到模型部署。我們往往會非常關注訓練，而忽視了整個生產流程。但是要訓練出好的模型，數據越來越重要。包括數據採集、數據清理、特徵提取、數據管理，再到訓練過程中，需要分發哪些數據參與訓練、哪些數據用來評測模型質量。所有數據都需要有驗證部分，用於驗證質量，這一步非常關鍵。低質量數據對模型的傷害力是超出想象的。這也是爲什麼吳達恩一直宣傳了一個觀點，就是更好的機器學習是80%的數據處理+20%的模型。
“以模型爲中心”和“以數據爲中心”的模型開發方式演進
這也體現了模型開發方式的演進。過去我們常常說以模型爲中心的模型開發，算法工程師花大量的時間調模型結構，希望通過模型結構來去提高模型泛化能力，解決各類噪聲問題。如果大家看5年前的Paper，會發現大量的研究都是圍繞模型結構展開的，當時的數據、算力都還不足夠支撐今天這樣的大模型時代。那時候的模型訓練更多是“有監督的學習”，用的都是標註數據，這些數據是非常昂貴的，這也決定了在訓練過程中，數據上沒有太多騰挪的空間，我們更多在考慮模型結構的變化。
今天的大模型訓練有非常多的無監督的學習。模型結構反而是沒有那麼多變化的，大家好像趨同的，都採用Transformer結構。這個時候我們就慢慢演進到了以數據爲中心的模型開發範式裏面。這個開發範式是什麼？就是需要用大量數據去做無監督的訓練，通過大的算力、大的數據引擎，結合相對固定的模型結構去萃取出一些有趣的智能的東西。
因此，訓練使用到的數據量會暴漲，也需要用到各種方法清洗和評測數據。我們可以看到許多大模型研究的團隊都會花費大量的精力去處理數據，在各種環境裏面反覆地、多角度地驗證數據質量。通過各種各樣的維度，甚至有時候還會把模型產生出來去評測，通過模型結果反饋數據的質量。在這個過程中，就需要積累非常多的數據處理工具，只有這樣纔能有效地支撐以數據爲中心的模型開發工作對於數據質量的要求。這也是大家說到以數據爲中心的模型開發的範式的核心的一個想法。
正是在這種趨勢下面，我們一直認爲大數據和AI是一體兩面，需要實現大數據和AI的一體化，這樣才能順應當下模型開發範式的演進。
在阿里雲，我們一直努力將數據和AI兩個系統緊密地聯合在一起。我們在計算基礎設施層，提供適應各種場景的計算集羣，包括適合大數據的以CPU爲主的集羣，以及適合大模型訓練的需要RDMA網絡的異構計算集羣。在此之上，打造了大數據和AI一體化平臺，覆蓋模型開發全過程的能力，包括數據採集和集成，再通過大數據平臺，做大規模的離線分析，去驗證數據質量。此外還有流式的計算能力。數據在大數據平臺上處理好之後，就會被“投餵”到PAI這個負責人工智能開發的平臺，去做訓練和迭代。最後，在模型應用孵化上，依賴向量引擎的數據庫，例如Hologres等，一起去構造場景化的應用。
大數據AI一體化的應用場景
在正式展開大數據AI一體化的技術點之前，先舉兩個應用的例子。
第一個例子是知識庫檢索增強的大模型問答系統。大家可以看到最近很多做大模型的通行，都會提到這個場景，通過一個大模型，可以獲得特定行業的垂直知識庫。這是怎麼做到的呢？首先，需要把這個知識庫的數據進行清理後分片，通過大模型把它轉成一個向量，再把這些向量存在一個數據系統裏面，這是向量檢索的數據系統。當有真實請求過來的時候，會先把query對應的向量找出來，轉譯成知識，再用這個知識去約束大模型，控制大模型“胡說八道”的衝動，這樣反饋的結果會更加準確。
這個場景裏面用到了很多大模型能力，包括大規模分佈式的批處理，因爲在創建embedding的時候，其實是一個非常大的數據。同時，也會用到向量數據庫這樣的服務能力，真實業務場景對於查詢時延的敏感度很高，需要非常快的給一個向量。當然也用到了大模型訓練的能力，就需要一個很好的AI系統。
第二個例子是個性化推薦系統。在做實時推薦的過程中，所有推薦對象的興趣是動態變化的，往往這樣的系統它的模型是時時刻刻更新的，需要根據最新的行爲數據來更新模型。我們往往會把所收集到的日誌經過實時或者離線處理，離線數據用來生產一個比較好的基礎模型，實時數據也會去提取這個特徵，經過模型訓練產生一個模型的delta，然後再把這個delta應用到線上的系統進行每天更新。在這裏面我們可以看到有非常多的數據系統，有實時的像流計算的系統、有AI的系統、有批處理系統。
大數據AI一體化的技術實現
統一的數據和AI工作空間管理
首先，我們在模型構造最外層，把AI和大數據的流程串聯在一起，這也是我們在PAI產品裏構建工作空間的最初始的想法，這樣就可以把多種資源統一在一個開發平臺上管理。現在阿里雲人工智能平臺PAI已經可以支撐多種計算資源，包括ECS資源、流計算平臺，還有PAI靈駿智算用於大模型訓練的集羣，還有這次雲棲已經發布的容器計算服務ACS等等。
僅僅接入這些資源是不夠的，用戶需要的是把接入的資源有機串聯到一起。所以我們推出了一個Flow框架，把這些流程串聯起來，把模型訓練和數據處理的各個步驟連接起來。這裏面我們提供了多種構建連接的方式，包括靜態構圖、SDK、圖形交互式等，用來去構建複雜的大數據和AI交互的流程圖。
Serverless雲原生服務
如果想進一步地去把大數據和AI融合好，用戶希望能夠在一份資源裏面提供大數據和AI的服務。這時候就離不開Serverless雲原生服務技術。我們一直在說雲原生，但是雲原生其實是有很多維度的，雲原生更多的是資源是共享的，但是這個資源是什麼？其實也是需要定義的。
這個定義也分很多層次。你可以說你是硬件層面的共享，那你共享的是服務器、虛擬服務器；你也可以共享更高層次的虛擬資源，比如容器和服務本身。在不同的層次，共享層次越高，單位計算成本就會越低，當然技術的複雜度也會越高。這也是爲什麼做雲計算的團隊一直在提高自己服務的雲原生化，或者是去實現更高技術複雜度的能力，這樣就能以更加經濟實惠的方式去提供更高層次的計算資源共享的目的，更加經濟高效地提供大數據和AI的服務。
也是因爲此，我們所有的大數據產品都是在第六個維度，也就是Share Everything上的一個產品。但是我們都是架在了第五個維度，也就是Shared container，就是在容器計算服務這一層，這樣我們就可以把大數據和AI的系統有機地連在一個資源上面。
統一調度：多負載、差異化SLO增強的調度
爲了能夠達到這樣的能力其實並不是那麼容易的，因爲容器計算服務最開始的產生是爲了支持微服務的。微服務在並行調度的力度上面，和大數據以及AI智算的場景有很大不同。爲了能夠讓不同的大數據和AI的任務和服務，能夠跑在一個資源池上，其實我們要做大量工作。比如說，大數據場景裏面有些很多高併發、短時長的任務，需要大大增強K8S本身的吞吐能力，解決它各個層次上的性能問題，包括延時和規模。
同時我們有多元化的任務，它不僅僅有在線服務，還有計算任務，我們要在調度上增強資源的豐富度和多場景的能力。比如在複雜的AI場景，需要做網絡拓撲感知，因爲AI大模型訓練對網絡要求非常高。這時候我們怎麼樣在這層的容器服務上、計算服務上感知這個拓撲結構，有效做調度，我們怎麼樣讓大數據和AI的Workload在上面存儲資源，需要有非常多的負載感知、QS感知的調度。
多租安全隔離
對雲服務來說，最重要的就是多租安全的隔離。我們需要加強雲原生的K8S在這個方向上的能力，這樣我們才能安心地把大數據和AI複用在一個資源上。我們在存儲層、網絡層都用了非常多的安全隔離的技術。這樣才能把大數據和AI的多款產品，甚至是用戶自己的在線服務，能夠集成在一個資源池裏面，來給雲上提供企業化的使用。
容器計算服務ACS
這次雲棲大會發布了容器計算服務ACS，PAI也是第一批容器計算服務支持的首批產品之一。在容器計算服務ACS平臺上，用戶可以很好地調配自己在大數據和AI的資源配比，然後在統一的資源底座上、在網絡上、在存儲IO上，就能夠更加自然地聯在一起。
多級Quota
我們都知道大模型的計算，計算資源是非常昂貴的。我們還要持續地加強這個底座上的一些精細化的資源管理的能力，所以我們也即將發佈多級Quota能力，使集羣的管理員可以更好地管理資源，平時讓各個團隊管理自己的資源，但是到了關鍵時刻。比如到了需要衝刺的階段，管理員可以把所有的資源集中起來，然後去訓練一些比較大的模型。這是我們的多級Quota。
自動拓撲感知調度
對於超大模型的模型訓練，我們要加強容器服務的調度能力。舉一個例子，我們可以看到在模型訓練裏面我們常常有一個步驟叫All-Reduce的環節，如果不加以調度的控制，稍微亂一個順序，去構成reduce的ring，就會發現會帶來一些cross的交換機的流量。最後我們經過拓撲感知的調度和非拓撲感知的調度，前後性能提升的增幅能有30-40%，這是非常可觀的。
MaxCompute 4.0 Data+AI
大模型訓練往往需要海量的數據，就跟我們前面說的我們不僅僅要把數據存下來，更多的是我們要進行批處理進行清洗、反覆評估數據質量、並根據反饋來調整數據。這時候我們就需要大數據平臺，以及湖倉一體的能力在背後支撐。阿里雲數倉產品MaxCompute上推出了MaxFrame的開放的數據格式，可以把強大的數據管理、數據計算的能力，和AI系統進行有機和開放的連接。此外還有Flink-Paimon，在流計算的場景裏，可以把流計算和online machine learning結合起來，把數據和訓練的這條通路打通。
數據集加速 DataSetAcc
在PAI靈駿集羣的AI智算場景裏面，不僅僅是高密的機器學習任務，還有數據處理的任務，但是高密計算的資源是非常寶貴的，這個時候可以去連接遠端的大數倉來解決。但這裏又會出現一個矛盾，就是遠端的數據I/O不能匹配高密度的計算。爲了解決這個問題，我們提供了一個數據集加速的DatasetAcc能力，就是利用PAI靈駿集羣本地的SD和本地的儲存來做一個近端的cache，異步地把遠端數倉的數據拉到近端。這樣就能很好地解決大數據和AI智算集羣在訓練場景上的結合，提升訓練效率。
正是因爲具備了這樣的有效連接大數據和AI智算集羣的能力，我們才能在大規模的LLM訓練過程中更好地使用大數據分析的能力。舉個例子，我們在訓練通義千問的過程中，獲取了大量重複的文本信息，去重是非常關鍵的步驟，不然整個訓練數據集會被這些數據拉偏，導致有一些過擬合的情況產生。我們利用我們構造的FlinkML的library構建了一個高效的文本去重算法，算法的同學就可以快速地進行多次文本去重，提高整個模型開發的效率。
我們前面說的都是大數據怎麼能夠助力於AI訓練的部分，也就是我們經常聽到的 Data for AI，但其實反方向，AI技術的成長也能夠幫助數據系統，去提高它的服務質量和效率，現在的數據分析也從BI走向了BI+AI。
DataWorks Copilot
過去的數據分析做的更多的是 business intelligence，如今有更多AI技術可以去推動數據分析能力的提升。我們在這方面做了一些工作，比如說在數據開發和治理平臺DataWorks，我們推出了 DatawWorks Copilot，也就是代碼助手。代碼助手可以幫助用戶用自然語言的方式，去找到感興趣的表格，然後再幫助用戶構建SQL query，最後再去執行query。
當然，真正要做出一個好用的代碼助手，只用基礎模型是不夠的。DataWorks平臺基於大量的公開query，然後我們用本身的語言，就是MaxCompute的或者是Flink的語言，作爲一個數據集，我們拿基礎模型和這個數據集做了finetune，產生一個垂類模型，然後再在這個垂類模型做推理，產生了這個特定場景裏的更有效的代碼輔助工具。通過這種方式，我們能夠提效30%的代碼的開發。
DataWorks AI 增強分析
不僅僅是輔助代碼生成，我們今年也發佈了DataWorks數據洞察功能。我們可以通過AI的方式、AI的能力，自動地根據已有數據，提供一些智能的數據洞察。通過這種方式，我們可以讓用戶更快速地掌握數據的特性，從而加快用戶對於數據的理解和分析能力。
以上的分享是希望通過剛纔說的一些技術點和案例闡述現在AI和大數據的一體化的演進過程。我們堅信大數據和AI是相輔相成的，也希望推動數據智能更快的落地和實現。
本文爲阿里雲原創內容，未經允許不得轉載。