Databricks UCDataset GPU 訓練免除資料表匯出步驟

Databricks 於 11 月 9 日推出 UCDataset beta，目標是解決 GPU 訓練延遲，團隊毋須先匯出資料表。Databricks UCDataset GPU 訓練將其資料管治系統 Unity Catalog 與機器學習框架 PyTorch 連接起來。該公司表示，在模擬的推薦工作負載中，涉及一個 300 GB 特徵資料表及八枚 NVIDIA H100 GPU，其訓練速度可提升 10 倍。此結果是把其載入器與匯出的 Parquet 副本比較，後者是以欄式檔案格式儲存的獨立資料集。

眼前的比較，是直接存取資料表與另一條匯出管線之間的比較。Databricks 現有的 AI Runtime 指引亦提到，應先匯出大型資料表，再透過機器學習軟件生態系統 Hugging Face 載入。這令這次公告有一個具體參照點：Databricks 自身既有的工作流程。

對機器學習工程師及平台負責人而言，實際問題是，免除匯出是否亦能簡化可靠的生產訓練。答案取決於工作負載、存取政策及復原要求。更快的輸入路徑值得關注，但團隊仍需取得可比較的模型結果，並保留可辯護的數據使用紀錄。

Databricks UCDataset GPU 訓練讓資料表成為直接輸入

這次推出改變的是受管治資料表與訓練工作之間的連接，而非模型架構。

Databricks 的 UCDataset beta 公告說明，功能支援直接讀取雲端儲存空間、自動分配至各個訓練程序，以及整合現有 PyTorch 迴圈。首個版本支援已在 Unity Catalog 註冊的 Delta 資料表；這類資料表以交易歷史來組織數據檔案。

公開公告於 11 月 9 日發布。該公司的 11 月發行說明則在 11 月 6 日列出這項 beta 功能。這些日期區分了產品更新與其後的網誌公告。兩者均不改變其 beta 狀態。

其架構意義在於移除中間數據成品。匯出工作流程會在數據團隊維護的資料表與訓練程式碼所使用的檔案之間建立界線。有人必須決定何時更新這些檔案、由哪個工作產生，以及準備工作失敗時如何處理。

直接存取資料表會改變這條界線。訓練應用程式可透過資料表識別其輸入，而非依賴另行維護的匯出位置。對合資格的工作負載而言，這提供了淘汰準備程式碼及相關營運決策的機會。

這個機會應比「訓練毋須準備」有更狹窄的解讀。特徵仍須有恰當定義，標籤仍須驗證，實驗仍須有一致的納入準則。更直接地讀取數據，並不代表數據已正確反映問題。

試想一個推薦團隊正在評估預測模型的改動。工程師希望在維持輸入群體不變的情況下比較模型表現。免除匯出可以縮短達成比較的路徑，但若同時改變群體，結果便更難解讀。

這項區分之所以重要，是因為簡化基礎設施與簡化實驗是兩種不同結果。團隊可以減輕基礎設施負擔，卻意外令實驗的控制程度下降。團隊也可以保留嚴謹的實驗控制，同時移除多餘的準備階段。

因此，對這次推出最有力的解讀是具體的：Databricks 正為常見的資料表至檔案交接方式，提供整合式替代方案。這個替代方案是否改善整個工作流程，取決於現時交接究竟完成了甚麼工作。

對那些匯出主要只是為遷就訓練讀取器的團隊而言，替代方案頗具吸引力。至於將匯出用作已核准實驗成品的團隊，採用前則需要有意識地建立替代控制。

匯出管線令平台團隊承受壓力

受影響最大的團隊，是那些僅為了讓訓練得以進行而維護第二條數據路徑的團隊。

Databricks 的 AI Runtime 數據載入文件說明了處理大型資料表的匯出方式。文件亦區分資料表輸入與儲存在 Unity Catalog volumes（其受管治檔案容器）中的檔案輸入。新的 beta 在這個既有環境中增加另一個選擇。

匯出管線的責任不僅是產生可讀取的檔案。其負責人要決定命名慣例、保留期、重新整理觸發條件、失敗處理及存取權限。即使是規模不大的工作流程，只要有多個實驗使用其輸出，便可能成為共同依賴。

這次推出首先令負責這些依賴的平台工程師承受壓力。他們現在有理由檢視哪些部分仍然必要。當原本的相容性問題已有另一個獲文件記錄的解決方案時，保留匯出便需要更清晰的理據。

這不代表每項匯出都是浪費。刻意凍結的資料集可支援外部協作、受控審批或特定訓練技術堆疊。這些都是實質要求。若某項匯出只因為沒有人重新檢視過舊有載入器決定，則應作不同評估。

短期回應應是工作流程檢討，而非即時承諾遷移。平台負責人需要了解其準備工作在格式轉換以外提供了甚麼。否則，他們可能在移除重複工作時一併刪去有用控制。

模型開發人員亦面對相關壓力。當輸入連接變得較容易替換，埋藏在訓練程式碼中的假設便更明顯。依賴特定檔案排列方式的專案，可能需要比其負責人起初預期更多的調整。

預算負責人亦需要作出比單看加速器執行時間更廣泛的比較。匯出工作流程在訓練前後均會耗用工程資源。只要替代方案移除了有意義的維護工作並保留必要行為，即使未能達到標題所述的基準結果，仍可改善營運。

反面的結果亦有可能出現。載入器可以改善已量度的訓練階段，卻在其他環節增加遷移工作或復原複雜性。這不會否定技術改善本身，但會改變該特定團隊的採用決定。

因此，有效的評估應將持續效益與轉換成本分開。團隊應記錄哪些工作會消失、哪些責任會轉移，以及哪些檢查仍屬必要。這使營運論證可供檢討，而非依賴籠統的簡化承諾。

對正評估合資格資料表工作負載的現有 Databricks 用戶而言，這種壓力是即時的。較廣泛的平台決定則需要更多證據。單一 beta 載入器並不足以證明一個機構應搬遷其數據或取代其訓練框架。

實際轉變是，匯出管線現在需要證明其存在價值。它的價值應來自明確要求，而非歷史習慣。

其機制是更短的路徑，交接更少

技術主張是減少資料表儲存與分散式訓練之間的協調。

分散式訓練將模型工作分配至多個程序。其輸入系統必須向每個程序提供預期樣本，而不會意外重複。PyTorch 的 iterable dataset 文件警告，樸素的多程序處理可能造成數據重複，因為工作程序會接收資料集副本。

這項警告說明，載入器維護不只是讀取檔案。訓練工作可以成功執行，卻使用了非預期的樣本分布。沒有出現例外情況，並不能證明實驗已正確處理預期數據。

根據 Databricks 的說法，UCDataset 的自動分區處理了這類協調工作。其工程吸引力在於，應用程式專用的輸入邏輯可以減少。團隊因而可將檢查重點放在所得行為及平台合約上。

效益應在產品改變的邊界上評估。若工作正在等候樣本，更佳的輸入路徑便有改善空間。若模型運算已佔主導，減少輸入工作對整體訓練時間的影響會較小。

這正是基準測試工作負載為何重要。一項包含大型特徵資料表的推薦任務，描述了一個可辨識的使用情況。但它並不能證明每個模型、特徵表示方式或訓練配置都會有相同結果。

與 Ray（一個分散式應用程式框架）亦可作有用比較。其 Databricks 資料表讀取器接受 warehouse 識別碼，並使用 Databricks statement execution API。它為已圍繞 Ray 組織的應用程式提供不同整合路徑。

這項比較確立的是設計差異，而非勝負。以 warehouse 為基礎的讀取器可配合圍繞查詢執行建立的工作流程。直接資料表讀取器則可配合已準備好所選訓練數據的工作負載。

相關決定在於每個團隊希望將準備及執行責任放在哪裏。轉移責任可以減少交接，但也可能暴露先前由上游處理的假設。公平的比較會讓這些責任維持可見。

例如，假設某個訓練匯出包含決定哪些觀測值合資格的業務規則。以資料表參照取代其輸出，並不會自動保留這些規則。工程師必須確立等效的選取在何處發生，以及審核者如何檢查。

同樣地，先前接收標準化特徵表示方式的訓練程式碼，可能依賴該表示方式。新的輸入連接應按相同合約評估。否則，效能比較同時也成為未被承認的數據處理比較。

Databricks UCDataset GPU 訓練最適合理解為針對性的輸入路徑改動。它讓團隊有理由質疑不必要的交接，同時保留令訓練結果值得信賴的檢查。

更廣泛的教訓屬於架構層面：每個移除的階段都應交代其責任。一條更短的管線，只有在餘下元件仍涵蓋重要工作時才有價值。

基準測試需要按工作負載層面解讀

所報告的加速結果支持進一步調查，但投入生產仍需要目標工作負載的證據。

Databricks 將這項重點結果列為公司針對模擬生產工作負載所作的基準測試。公告沒有提供獨立驗證。在內部討論結果或比較可能的基礎設施改動時，讀者應保留這項區分。

基準測試回答的是特定設定下的有限問題。採用決定所問的是，同一方法是否能改善另一個營運環境。這些問題有所重疊，但不能互相替代。

有意義的評估應保持模型、輸入樣本群體及品質標準一致。否則，表面上的改善可能只是來自工作內容改變。當實驗使用不同範例，或以不同標準評定結果時，執行更快所提供的資訊便較有限。

比較亦需要明確界定起點。由訓練開始計算，回答的是一類問題；由可用原始資料到完成並評估模型的過程計算，回答的則是另一類問題。

兩種量度都可以有用。前者可隔離訓練行為，後者則反映用戶實際經歷的工作流程。分開報告可避免把局部改善誤當成同樣幅度的營運改善。

基準品質同樣重要。團隊應與可在生產環境中合理維護的匯出流程作比較。過於薄弱的基準會令新的 loader 看似更好，卻無法釐清工程師實際面對的決策。

重複執行亦很重要，因為運行條件會有所變化。一次成功運行可以指出有前景的方向，但對日常表現提供的證據有限。評估應納入足夠觀察值，以區分可靠的改善與一次異常有利的執行結果。

模型品質亦應納入評估。loader 是訓練系統的一部分，因此資料排序或讀取方式的變更值得關注。只有在確信所得實驗仍具意義的前提下，相近的耗時才有參考價值。

這些是評估原則，並非聲稱 beta 未能符合它們。現有公告提供了測試的理由，但不代表可以免除在測試開始前界定成功標準的需要。

買家亦不應把訓練速度比例直接換算成預算預測。實際支出取決於資源配置、周邊服務，以及營運 pipeline 所需的工作。這種關係需要在組織自身的環境內量度。

即使未能重現宣傳中的數字，商業價值仍可能具說服力。淘汰脆弱的準備工作，或令實驗輸入更易審閱，都可能帶來實際價值。這些成果應明確記錄，而非隱藏在效能口號背後。

對 Databricks UCDataset GPU training 而言，可信的採用理據會結合耗時、可比較的模型結果，以及減少的營運工作。這種組合比單獨考慮速度數字更有用。

Beta 限制塑造生產環境決策

在效能測試開始前，相容性和實驗控制可能已決定是否符合採用資格。

UCDataset 文件列出具體限制。設有 row filters 或 column masks 的資料表不受支援。Views、materialized views、streaming tables、shallow clones，以及包含 VARIANT 欄位的資料表亦被排除。

這些限制令預期使用的輸入物件成為實際起點。團隊應先確認已核准的訓練資料是否可透過受支援的資料表取得。在確認這項條件前評估速度，可能徒勞無功。

政策限制尤其值得注意。Row filters 限制某個身分可檢視的記錄，而 column masks 則會隱藏或轉換受保護數值。依賴這些控制措施的組織，在考慮 beta 前需要一套獲批准且相容的方案。

這是治理決策，而不是效能調整。基準測試結果並不能證明削弱存取政策是合理的。相關持份者須就訓練身分獲准讀取哪些資料達成共識。

實驗控制則帶來另一項問題。文件支援選取數值型資料表版本，讓團隊可識別特定輸入狀態，而無須為每項實驗建立專用匯出檔。

不過，記錄該狀態仍是團隊的責任。模型研究需要在結果與輸入之間建立可辯護的關聯。若資料表在兩次執行之間改變，單純記錄資料表名稱並不足夠。

清晰的紀錄應把所選輸入狀態與模型設定及評估決定連結起來。這不代表要把每項實驗變成文件專案，而是要保留足夠背景，讓另一位工程師理解結果。

維護這類背景資料的團隊，可從用於技術文件及實驗討論的可搜尋知識庫中受益。這類文件可配合訓練系統自身紀錄，支援審閱工作。

beta 在各個 epoch 使用相同的隨機檔案順序，即完整遍歷資料集。它不提供可設定的 shuffle seed。因此，對資料排序有特定要求的團隊，需要評估這種行為是否適合其實驗。

復原是另一項明確界線：loader 無法 checkpoint 其讀取位置，因此不能在一個 epoch 的中途續跑。儲存訓練狀態的模型 checkpoint，並不能獨立解決這項輸入位置限制。

其營運影響取決於工作負載。對某些應用而言，重新開始讀取輸入或可接受；對另一些應用則可能成本高昂。若復原行為會實質影響交付，團隊應在評估中納入被中斷的執行。

Array 欄位會以 Python lists 形式傳入，文件亦指出其速度較數值欄位慢。因此，在測試效能時，具代表性的特徵資料相當重要。方便使用的測試資料表未必反映目標模型採用的表示方式。

綜合而言，這些限制界定了採用範圍。它們為工程師及治理負責人提供具體問題，毋須推測產品是否已適用於每個企業工作流程。

合適的決定可以是採用、有限度試點，或繼續使用現有路徑。只要與明確的工作負載要求掛鈎，每一種決定都站得住腳。

2027 年初前應留意甚麼

下一批有用證據將涉及可重現結果、相容的治理機制，以及可靠的復原能力。

第一個訊號是其他團隊可評估的詳細工作負載比較。強而有力的證據應說明基準、輸入特性、訓練設定及品質標準，亦應交代耗時由何處開始量度。

這類報告會加強進一步廣泛評估的理據。它有助工程師辨識與自身相似的工作負載，並避免由不相關的範例作出推論。現有生產用戶的結果，亦可在模擬工作負載以外提供背景。

即使證據顯示改善集中於特定設定，仍然很有價值。這可收窄產品最強的適用場景，並令採用決策更精確。受明確界定的結果比無限制的聲稱更具可操作性。

第二個訊號是支援受政策控制資料表方面的進展。支援組織現有依賴的控制措施，將擴大合資格工作負載的範圍。就獲批准替代方案提供詳細指引，亦有助團隊評估可行路徑。

這項訊號重要，因為資料存取要求先於 loader 選擇。組織不能在批准遷移後，才把政策相容性當成次要考慮。若合資格範圍仍然狹窄，採用將繼續集中於相容資料集。

第三個訊號是復原及資料排序控制的進展。恢復執行能力或可設定排序方面的文件化改善，將回應 beta 中可見的具體疑慮。詳細的營運例子，亦可釐清團隊目前如何處理這些要求。

這些發展將加強以下訓練工作的採用理據：中斷處理或實驗可重複性會主導基礎設施選擇的情況。若它們維持不變，團隊便應繼續在這些界線內評估 beta。

觀察期是未來數月，而非已承諾的發布時間表。Databricks 尚未確立本文討論的未來交付日期。這些是值得監察的具體訊號，而非歸因於該公司的承諾。

更廣泛的採用問題是，直接讀取資料表會否成為一般的平台選項。這需要可重複的營運理據：相容的存取方式、可理解的輸入、可靠的執行，以及有用的效能。任何單一基準測試都無法確立所有這些條件。

對現有用戶而言，這次發布已帶來實際決策。他們可以找出主要為了訓練相容性而維護的匯出項目，並檢視 beta 是否取消了這項需要。結果應為特定工作流程提供依據，而不是形成一般的平台結論。

先從一項合資格、且現有匯出流程已充分理解的訓練工作負載開始。在改變輸入路徑前界定比較方式，包括資料身分、模型品質、耗時及中斷行為。在審閱結果期間保留現有工作流程。向平台負責人詢問哪些維護責任可以消失，並向模型負責人確認實驗是否仍具可比性。Databricks UCDataset GPU training 提供了簡化以資料表為基礎的訓練的具體機會，但其價值會在這些有記錄的決策中最為清晰。你現有 pipeline 中哪一項匯出是因訓練 reader 的要求而存在，而甚麼證據足以支持淘汰它？