Function Compute：GPU執行個體模型儲存最佳實務

背景資訊

函數的儲存類型請參見函數儲存選型。其中，適合用作GPU儲存模型的包括以下兩種。

• 檔案系統NAS

• Object Storage Service

除此之外，GPU函數使用自訂容器鏡像部署業務，因此還可以將模型檔案直接放置到容器鏡像中。

每種方法都有其獨特的應用情境和技術特點，選擇模型儲存方式時應當考慮具體需求、執行環境以及團隊的工作流程，以達到模型儲存在效率和成本上的平衡。

模型隨容器鏡像分發

將訓練好的模型和相關應用代碼一起打包在容器鏡像中，模型檔案隨容器鏡像分發，這是最直接的方法之一。

優缺點

優點：

• 便利性：建立好鏡像後，可以直接運行它進行推理而無需額外配置。

• 一致性：確保每個環境中的模型版本都是一致的，減少了由於不同環境中模型版本差異導致的問題。

缺點：

• 鏡像體積：鏡像可能會非常大，特別是對於大尺寸模型。

• 更新耗時：每次模型更新時都需要重新構建和分發鏡像，這可能是一個耗時的過程。

說明

為了提升函數執行個體的冷啟動速度，平台會對容器鏡像進行預先處理。如果鏡像尺寸過大，一方面可能會超出平台對鏡像大小的限制，另一方面也會導致鏡像加速預先處理所需時間的延長。

• 關於平台鏡像大小限制，請參見GPU鏡像大小限制是多少？

• 關於鏡像預先處理和函數狀態的資訊，請參見自訂鏡像函數狀態及調用。

使用情境

• 模型尺寸相對較小，例如百MB左右。

• 模型變更頻率較低，可以考慮將模型打包在容器鏡像中。

如果您的模型檔案較大、迭代頻繁或隨鏡像發布時超過平台鏡像大小限制，建議模型與鏡像分離。

模型放在NAS檔案儲存體

Function Compute平台支援將NAS檔案系統掛載到函數執行個體的指定目錄，將模型儲存在NAS檔案系統，應用程式通過訪問NAS掛載點目錄實現模型檔案的載入。

優缺點

優點：

• 相容性：相比FUSE類檔案系統，NAS提供的POSIX檔案介面較為完整和成熟，因此在應用相容性方面表現較好。

• 容量：NAS能夠提供PiB級的儲存容量。

缺點：

• 依賴VPC網路：一方面，需要為函數配置VPC訪問通道才能訪問NAS掛載點，在配置時涉及的雲產品許可權點相對較多；另一方面，函數執行個體冷啟動時，平台為執行個體建立VPC訪問通道會產生秒級的耗時。

• 內容管理方式比較單一：NAS檔案系統需要掛載才能使用，相對單一，需要建立相應的商務程序將模型檔案分發到NAS執行個體上。

• 不支援雙活和多AZ，詳情請參見NAS常見問題。

說明

在大量容器同時啟動載入模型的情境下，容易觸及NAS的頻寬瓶頸，導致執行個體啟動耗時增加，甚至因逾時而失敗。例如，定時HPA大量設定GPU快照、突發流量觸發大量彈性GPU執行個體的建立。

• 可以從控制台查看NAS效能監控（讀吞吐）。

• 可以通過向NAS增加資料量的方式來提升NAS讀寫輸送量。

採用NAS來儲存模型檔案，建議選用通用型NAS中的“效能型”，其主要原因在於該類型NAS可以提供較高的初始讀頻寬，約600MB/s，詳情請參見通用型NAS。

使用情境

在Function Compute彈性GPU執行個體時，需要快速的啟動效能。

模型放在OSSObject Storage Service

Function Compute平台支援將Object Storage Service Bucket掛載到函數執行個體的指定目錄，應用程式可以直接從OSS掛載點載入模型。

優點

• 頻寬：OSS的頻寬上限較高，相比NAS不易出現函數執行個體間頻寬爭搶現象，詳情請見OSS使用限制及效能指標。與此同時，還可以通過開通OSS加速器獲得更高的吞吐能力。

• 管理方法多樣：

  • 提供控制台、開放API等訪問通道。

  • 提供多種本地可用的Object Storage Service管理工具，請參見OSS常用工具。

  • 可使用OSS跨地區複製功能進行模型同步與管理。

• 配置簡單：相比NAS檔案系統，函數執行個體掛載OSS Bucket無需打通VPC，即配即用。

• 成本：若僅比較容量和吞吐速率，相比NAS，一般來說OSS的成本更優。

說明

從實現原理上，OSS掛載使用FUSE使用者態檔案系統機制實現。應用訪問OSS掛載點上的檔案時，平台最終將其轉換為OSS API調用實現對資料的訪問。因此OSS掛載還有以下特徵：

• 其工作在使用者態，會佔用函數執行個體的資源配額，如CPU、記憶體、臨時儲存等，因此建議在較大規格的GPU執行個體上使用。

• 資料的訪問使用OSS API，其輸送量和時延最終受限於OSS API服務，因此更適合訪問數量較少的大檔案（如模型載入情境），不宜用於訪問大量小檔案。

• 相比隨機讀寫，OSS掛載對順序讀寫更友好。特別地，在載入大檔案時，順序讀將能夠充分利用檔案系統的預讀機制，從而達到更優的網路吞吐速率和載入時延。

  • 以safetensors檔案為例，使用針對順序讀取最佳化過的版本將大幅縮短從OSS掛載點載入模型檔案的耗時：load_file: load tensors ordered by their offsets。

  • 若無法調整應用的IO模式，則可以考慮在負載檔案前，先順序讀取一遍檔案，將內容預熱到系統PageCache，應用後續將從PageCache負載檔案。

使用情境

• 大量執行個體並行載入模型，需要更高的儲存吞吐能力，以避免執行個體間頻寬不足的情況。

• 需要本地冗餘，或者多地區部署的情境。

• 訪問數量較少的大檔案（比如模型載入情境），並且IO模式為順序讀取。

總結對比

基於以上對比，根據FC GPU不同使用模式、不同容器並發啟動數量、不同模型管理需求等維度，FC GPU模型託管的最佳實務如下：

• 如果對檔案系統API相容性有較高要求，或者應用使用隨機讀且無法轉換為對記憶體PageCache的訪問，推薦使用通用效能型NAS。

• 在大並發GPU容器同時啟動使用情境下，為了避免NAS的單點頻寬瓶頸，推薦OSS ACCL。

• 在多地區單元化部署使用情境下，為了減少模型管理複雜度與跨域同步難度，推薦OSS和OSS ACCL。

測試資料

本文介紹以下兩種方式，通過對比不同情境下不同儲存介質負載檔案的耗時，來分析其效能差異，耗時越低，代表格儲存體效能越高。