火山引擎云上實戰： DeepSeek R1 大模型（全尺寸）

本文將介紹兩種在火山引擎云上部署 DeepSeek-R1 全尺寸模型服務的方案，涵蓋大模型推理服務的 Terraform 一鍵部署、容器化部署、資源彈性伸縮和模型可觀測。

來源 | 火山引擎云基礎

在 AI 大模型日新月異的當下，企業在使用大模型時往往面臨著數據隱私保護和性能優化的挑戰。為了解決這些問題，企業 AI 大模型在云端進行私有化部署成為一種理想的解決方案。私有化部署允許企業在自己的服務器上運行 AI 模型推理服務，保護敏感數據隱私并借助云上的基礎設施提高模型推理性能，實現安全和效率的雙贏。

上周，我們在《火山引擎云上實戰：一鍵部署 DeepSeek 大模型（蒸餾版）》一文中介紹了三種在火山引擎云上快速部署 DeepSeek-R1-Distill 模型服務的方案。相比 DeepSeek-R1-Distill，同樣由深度求索開源的全尺寸模型 DeepSeek-R1 由于具有如下特性，可以滿足企業級用戶的更多業務訴求：

性能與精度：?企業級應用（如金融分析、醫療診斷、智能客服等）通常需要處理復雜任務，對模型的精度和性能要求極高，DeepSeek-R1 作為更大的模型，參數量更多，能夠捕捉更復雜的模式和特征，因此在處理高難度任務時表現更優；
處理復雜任務：?企業級場景通常涉及更復雜的推理任務（如語義理解、決策支持等），DeepSeek-R1 的強大計算能力和更大的容量使其更適合處理這些任務；
資源環境支持：?企業級用戶通常擁有強大的計算資源（如高性能服務器、GPU 集群等），能夠支持更大模型的部署和運行，DeepSeek-R1 雖然計算開銷大，但在企業級環境中，資源通常不是瓶頸；
模型的可擴展性：?企業級用戶可能需要根據業務需求對模型進行微調或擴展，DeepSeek-R1 的更大容量和更強的表達能力使其更容易適應新的任務或領域。

本文將介紹兩種在火山引擎云上部署 DeepSeek-R1 模型推理服務的方案：

方案一：基于 Terraform 實現在 GPU 云服務器上的大模型一鍵部署，優勢是簡單、易操作；
方案二：基于 GPU 云服務器、容器服務 VKE 的多機分布式推理方案，通過優化云上架構設計支持大規模模型的推理，提高吞吐量和性能，大幅提升模型加載速度，使更大化資源利用率、提高可用性和容錯性成為可能。

方案一：Terraform 雙機一鍵部署

Terraform 是一款開源基礎設施即代碼（ IaC ）工具，專注于幫助用戶通過聲明式配置文件自動化創建、管理和版本化云基礎設施資源。火山引擎通過多年積極擁抱開源生態，已與 Terraform 做了大量集成，支持用戶通過 Terraform 編排火山引擎上的多種云資源，因此我們可以通過 Terraform 實現 DeepSeek-R1 大模型在 GPU ECS 上的一鍵部署。這種方案的優勢是：

易用性：?基于開源 Terraform 的方案，腳本內置了常用參數，用戶只需下載 Terraform 腳本代碼并執行，即可安全、高效地完成基于 GPU 云服務器的部署，避免手工操作的繁瑣；
模型下載快速、穩定、低成本：同一 Region 的機器走內網快速拉取模型，帶寬穩定在 300MB/s 以上，并且避免了公網流量費用。

資源配置推薦

由于 DeepSeek-R1 參數量高達 671B，在 FP8 精度下，僅存儲模型參數就需要約 625GB 顯存，加上 KV Cache 緩存（128K 上下文長度需要 448GB 顯存）和其他運行時開銷，超過了絕大多數單機的顯存上限，因此在這個方案中，我們需要用到 2 臺 8 卡的 GPU 主機才能完整運行全尺寸模型，推薦使用如下資源配置：

注：?ecs.hpcpni3ln?機型目前處于邀測階段，歡迎聯系客戶經理申請

Step1：Terraform 環境準備

首先，我們需要完成 Terraform 的安裝并初始化使用環境，為后續通過 Terraform 一鍵部署 DeepSeek-R1 做好準備。Terraform 是以二進制可執行文件發布，我們只需下載官方 Terraform，并將 Terraform 可執行文件所在目錄添加到系統環境變量 PATH 中即可，具體步驟可參考：安裝Terraform--Terraform-火山引擎。

Step2：下載并執行 Terraform 腳本

1.下載 Terraform 腳本：

wget https://public-terraform-cn-beijing.tos-cn-beijing.volces.com/models/deepseek/DeepSeek-R1/main.tf

火山引擎已經為用戶準備好了不同版本的 deepseek-terraform 一鍵部署腳本，腳本內置地域信息、模型下載地址和機型選擇，可以按照需求自行下載。這里我們選擇 DeepSeek-R1 北京地區的鏈接。

重要參數說明：

火山引擎高性能計算集群（HPC）是一種用于處理大規模計算任務的集群計算環境，通常由大量的計算節點組成，這些節點通過 RDMA 高速網絡互聯，并協同工作以處理復雜的計算任務。

高性能計算集群創建方法：登錄火山引擎 ECS 工作臺：賬號登錄-火山引擎，進入【高性能計算集群】菜單，點擊【創建高性能計算集群】，按照提示創建成功之后，可在詳情頁查看 ID。

2.通過運行以下命令來初始化 Terraform：

terraform init

等待系統顯示以下消息：

Terraform has been successfully initialized!

3.查看配置中定義的資源：

terraform plan

terraform plan?命令的輸出是在應用配置時 Terraform 預配的資源列表。

4.應用 Terraform 配置：如果 Terraform 配置中不需要進一步更改，請部署資源。

terraform apply

Terraform 會顯示將創建的資源列表，并且執行內置的執行腳本。

由于模型本身體積較大，DeepSeek R1/V3 部署時間約為 30-40 分鐘，請耐心等待

Step3：測試驗證

登錄 node0 實例，查看/home/result 文件，直到輸出 “Script execution completed” ，表示安裝&啟動容器命令執行完成。此時可以 docker logs?CONTAINER_ID?查看容器是否拉取到模型和權重，當 docker logs 顯示如下內容時表示服務已成功啟動（全尺寸模型和權重拉取時間較長，請耐心等待）。

此時，可以執行如下命令進行測試：

若看到如下輸出，則表示部署成功：

提醒：執行 curl 命令可能會返回拒絕連接的提示，如下圖，可能是權重文件沒有下載和加載完畢，可以稍后再重試。

方案二：云原生多機分布式推理 @楊欣然

如前文所述，DeepSeek-R1 是一個參數量巨大的模型，單機 GPU 無法支持完全加載或高效運行，因此除了雙機部署，我們也推薦基于容器的多機分布式推理方案，更好地支持大規模模型的推理、吞吐量提升和性能保障。部署方案如下圖所示：

可以發現，在多機推理架構中需要多個 Pod 共同組成一個推理服務，同時不同 Pod 還具有不同的主從角色（在 sglang 和 vllm 中稱為head 和 worker 節點）。Kubernetes 原生提供了如 Deployments、StatefulSet 等資源管理對象，能夠很好管理單個 Pod 的生命周期和擴縮容。但是對于多機分布式推理需要跨多個 Pod 部署資源并對多個 Pod 進行擴縮容的場景，就無法使用 Deployments 或 StatefulSet 。

為了應對這個挑戰，Kubernetes 社區在 StatefulSet 的基礎上提出了 Leader-Worker Set （LWS） API ，LWS API 提供了一種原生的方式來管理分布式推理任務中常見的 Leader-Worker 模式，其中 Leader Pods 通常負責協調任務、Worker Pods 則負責執行實際的推理任務或計算工作。LWS API 能夠確保 Leader Pods 在完全就緒之前，不會啟動 Worker Pods。同時可以單獨定義 Leader 和 Worker 所需的 Pod 數量：

使用 LWS API 的主要優勢包括：

簡化分布式推理的部署：通過 LWS API，提供了一個聲明式的 API，用戶只需定義 Leader 和 Worker 的配置，Kubernetes 控制器會自動處理其生命周期管理。用戶可以更輕松地部署復雜的分布式推理工作負載，而無需手動管理 Leader 和 Worker 的依賴關系和副本數量。
無縫水平擴容：上文中提到分布式推理的服務需要多個POD 共同提供服務，在進行擴容時也需要以多個Pod 一組為原子單位進行擴展， LWS 可以與 k8s HPA 無縫對接，將 LWS 作為HPA 擴容的Target，實現推理服務整組擴容
拓撲感知調度：在分布式推理中，不同 Pod 需要進行大量數據交互。為了減少通信延時 LWS API 結合了拓撲感知調度，保證能夠保證 Leader 和 Worker Pod 能夠調度到 RDMA 網絡中拓撲距離盡可能接近的節點上。

下面我們正式開始介紹如何通過火山引擎 GPU 云服務器和容器服務 VKE 部署 DeepSeek-R1，首先是一些前置準備和環境配置建議。

環境配置推薦

GPU 資源配置

和 Terraform 一鍵部署方案一樣，多機分布式推理方案同樣推薦使用如下資源配置：

注：ecs.hpcpni3ln 機型目前處于邀測階段，歡迎聯系客戶經理申請

RDMA 組網

多機推理過程中需要頻繁地相互交換參數，為了保障網絡通訊不成為性能瓶頸，通常使用 RDMA 網絡在 GPU 之間直接傳輸數據。而在數據中心當中，一臺交換機可以連接的 RDMA 網絡設備有限，通常需要 S0 S1 兩級交換機連接一個 miniPod 中的所有服務器。這樣的網絡拓撲結構，會導致不同 RDMA 網卡之間的通訊距離不一樣，因此不同的 GPU 設備之間的通訊性能也會有差異。

針對上述情況，火山引擎容器服務提供 RDMA 拓撲感知調度能力，通過對 GPU 卡和 RDMA 設備的網絡拓撲信息的感知，調度器能夠將同一個 Job 中的所有 Pod 調度到 RDMA 網絡中拓撲距離盡可能接近的節點和 RDMA 網卡上，充分發揮 RDMA 網絡的通信能力

分布式推理引擎

這里同樣選擇了 SGLang 作為分布式推理引擎。SGLang 是 DeepSeek 官方團隊推薦的推理引擎，支持多節點張量并行，同時針對 DeepSeek 的多頭潛注意力（MLA）機制做了諸多優化：權重吸收、分組解碼內核、FP8 矩陣乘法和 KV 緩存量化，使得 SGLang 成為了運行 DeepSeek 模型的最佳開源 LLM 引擎之一。

對比其他主流的推理引擎實現、如 VLLM，根據火山引擎團隊的測試數據，在 DeepSeek-R1 模型 SGLang 的吞吐量是 VLLM 2 倍以上，有顯著的性能優勢。

Step1：模型拉取

火山引擎為用戶準備好的不同版本 DeepSeek 模型的 TOS 地址，這里我們使用 DeepSeek-R1 北京地區的鏈接：tos:// ai-public-models-cn-beijing/models/DeepSeek-R1/。用戶可以通過 tosutil 命令行工具，將模型快速復制到到用戶自身的 TOS 桶中，作為后續模型推理服務的基礎模型，具體操作步驟如下：

1.完成 tosutil 信息配置：

tosutil config -e=tos-cn-beijing.volces.com -i=${AK} -k=${SK} -re=cn-beijing

其中，AK/SK 為用戶的 API 訪問秘鑰，密鑰管理方式可以參考：https://www.volcengine.com/docs/6257/64983。

2.執行復制命令。在本地執行命令，完成將預置模型復制到用戶 TOS 桶中的操作：

tosutil cp -r -j 6 -p 6 ${SOURCE_MODEL_TOS_PATH} tos://${TOS_BUCKET}

SOURCE_MODEL_TOS_PATH 為預置模型的 TOS 路徑。以 DeepSeek-R1 模型為例，SOURCE_MODEL_TOS_PATH 即為：tos:// ai-public-models-cn-beijing/models/DeepSeek-R1/
TOS_BUCKET 為用戶創建的 TOS 桶的名稱，具體可以在桶概覽頁查看

Step2：模型部署

創建高性能計算集群

為了后續在 VKE 集群中創建的 RDMA 節點的RMDA 網絡能夠互聯互通，我們需要先初始化高性能計算集群，并在后續新建 VKE 節點時選擇預先初始化好的高性能計算集群。

登錄火山引擎 ECS 工作臺：賬號登錄-火山引擎，進入【高性能計算集群】菜單，點擊【創建高性能計算集群】，按照提示創建成功之后，可在詳情頁查看 ID。需要注意，高性能集群集群所在的可用區需要與VKE 節點的可用區一致。

創建 VKE 集群

1.進入火山引擎容器服務 VKE 工作臺：賬號登錄-火山引擎，創建托管集群（如下圖所示），

??Kubernetes版本選擇1.28

??網絡模型建議選擇 VPC-CNI：

2.安裝插件。在創建集群過程中，我們需要選擇組件配置，這里要額外選擇 nvidia-device-plugin、rdma-device-plugin 等組件進行安裝（相關文檔：https://www.volcengine.com/docs/6460/101014）：

??nvidia-device-plugin：GPU 使用依賴，使用 GPU 機器必備；

??rdma-device-plugin： RDMA 設備插件，支持 RDMA 網卡設備的管理；

??CSI-TOS：TOS 掛載依賴。

??prometheus-agent ：監控指標采集

3.創建節點池。進入集群，選擇“節點管理-節點池-創建節點池”：

4.計算規格選擇 ecs.ebmhpcpni3l 機型，數量 2 臺；數據盤規格選擇 1T 極速型 SSD；選擇上文中創建的高性能計算集群：

5.RDMA 配置。設置節點標簽GPU 和 RDMA 使用模式，vke.node.gpu.schedule:nvidia 和 vke.node.rdma.mode:exclusive，并設置 kubelet 參數 topologyManagerPolicy: best-effort

配置界面如下圖所示：

6.創建模型存儲卷。在 VKE 集群中創建對象存儲靜態存儲卷，實現基于 TOS 的 VKE 集群網絡存儲能力，參考：使用對象存儲靜態存儲卷--容器服務-火山引擎。在已創建的 VKE 集群中創建存儲卷（PV），需要注意以下列舉的參數配置：

創建存儲卷聲明（PVC），關聯上一步創建的 PV：

安裝 LeaderWorkerSet

如前文所述，我們會使用 LWS (LeaderWorkerSet) 來編排多節點的推理負載 (如 deepseek r1 需要跨兩個節點部署)，我們首先需要安裝LWS 的CRD。

獲取yaml文件?https://modeltest.tos-cn-beijing.volces.com/files/manifest.yaml
安裝CRD

kubectl apply --server-side -f manifest.yaml

通過 LeaderWorkerSet 部署模型

完成部署模型前的準備工作后，開啟正式部署 DeepSeek-R1 模型（SGLang）的步驟，

示例 YAML 文件sglang.yaml?如下所示，需要注意的是， persistentVolumeClaim.claimName 需要和之前創建模型 PV/PVC 步驟中創建的 PVC 名稱對應：

apiVersion:?http://leaderworkerset.x-k8s.io/v1

kind: LeaderWorkerSet

metadata:

spec:

replicas: 1 # pod group 數量

startupPolicy: LeaderCreated

rolloutStrategy:

type: RollingUpdate

rollingUpdateConfiguration:

maxSurge: 0

maxUnavailable: 2 # 需要開啟 MaxUnavailableStatefulSet feature gate 生效

leaderWorkerTemplate:

size: 2

restartPolicy: RecreateGroupOnPodRestart

leaderTemplate:

metadata:

labels:

role: leader

annotations:

http://k8s.volcengine.com/pod-networks:?|

[

{

"cniConf":{

"name":"rdma"

}

{

"cniConf":{

"name":"rdma"

}

{

"cniConf":{

"name":"rdma"

}

{

"cniConf":{

"name":"rdma"

}

]

spec:

containers:

- name: sglang-head

image:?http://ai-containers-cn-beijing.cr.volces.com/deeplearning/sglang:v0.4.2.post2-cu124

imagePullPolicy: IfNotPresent

workingDir: /sgl-workspace

command:

- bash

- -c

- 'cd /sgl-workspace && GLOO_SOCKET_IFNAME=eth0 NCCL_SOCKET_IFNAME=eth0 NCCL_IB_DISABLE=0 NCCL_IB_HCA=mlx5_ python3 -m sglang.launch_server --model-path /models/deepseek --tp 16 --dist-init-addr $LWS_LEADER_ADDRESS:20000 --nnodes $LWS_GROUP_SIZE --node-rank 0 --trust-remote-code --context-length 131072 --mem-fraction-static 0.7 --enable-metrics --host 0.0.0.0 --port 8080'

ports:

- containerPort: 8080

protocol: TCP

- containerPort: 20000

protocol: TCP

resources:

limits:

http://nvidia.com/gpu:?"8"

http://vke.volcengine.com/rdma:?"4"

requests:

http://nvidia.com/gpu:?"8"

http://vke.volcengine.com/rdma:?"4"

securityContext:

capabilities:

add:

- IPC_LOCK

terminationMessagePath: /dev/termination-log

terminationMessagePolicy: File

volumeMounts:

- mountPath: /models/deepseek

- mountPath: /dev/shm

readinessProbe:

tcpSocket:

port: 8080

initialDelaySeconds: 15

periodSeconds: 10

volumes:

- name: models

persistentVolumeClaim:

claimName: deepseekr1

- emptyDir:

medium: Memory

dnsPolicy: ClusterFirst

workerTemplate:

metadata:

annotations:

http://k8s.volcengine.com/pod-networks:?|

[

{

"cniConf":{

"name":"rdma"

}

{

"cniConf":{

"name":"rdma"

}

{

"cniConf":{

"name":"rdma"

}

{

"cniConf":{

"name":"rdma"

}

]

spec:

containers:

- name: sglang-worker

image:?http://ai-containers-cn-beijing.cr.volces.com/deeplearning/sglang:v0.4.2.post2-cu124

imagePullPolicy: IfNotPresent

workingDir: /sgl-workspace

command:

- bash

- -c

- 'cd /sgl-workspace && GLOO_SOCKET_IFNAME=eth0 NCCL_SOCKET_IFNAME=eth0 NCCL_IB_DISABLE=0 NCCL_IB_HCA=mlx5_ python3 -m sglang.launch_server --model-path /models/deepseek --tp 16 --dist-init-addr $LWS_LEADER_ADDRESS:20000 --nnodes $LWS_GROUP_SIZE --node-rank $LWS_WORKER_INDEX --trust-remote-code --context-length 131072 --enable-metrics --host 0.0.0.0 --port 8080'

env:

- name: LWS_WORKER_INDEX

valueFrom:

fieldRef:

fieldPath: metadata.labels['http://leaderworkerset.sigs.k8s.io/worker-index']

ports:

- containerPort: 8080

protocol: TCP

- containerPort: 20000

protocol: TCP

resources:

limits:

http://nvidia.com/gpu:?"8"

http://vke.volcengine.com/rdma:?"4"

requests:

http://nvidia.com/gpu:?"8"

http://vke.volcengine.com/rdma:?"4"

securityContext:

capabilities:

add:

- IPC_LOCK

terminationMessagePath: /dev/termination-log

terminationMessagePolicy: File

volumeMounts:

- mountPath: /models/deepseek

- mountPath: /dev/shm

dnsPolicy: ClusterFirst

volumes:

- name: models

persistentVolumeClaim:

claimName: deepseekr1

- emptyDir:

medium: Memory

kubectl apply -f sglang.yaml

Step3：對外訪問

火山引擎負載均衡 CLB 是一種將訪問流量按策略分發給多臺后端服務器的服務，可以擴展系統對外服務能力，消除單點故障，從而提高系統的整體可用性。這里我們使用負載均衡 CLB 來對外暴露服務。

kubectl apply -f sglang-api-svc.yaml

配置完成后，我們可以在控制臺界面中查看配置結果：

到這里，我們就完成了 DeepSeek R1 大模型的部署和服務對外暴露。我們可以通過本地 curl 命令調用 API 來測試部署效果，這里的 IP 為你之前創建的負載均衡的 IP：

進階：可觀測、彈性及模型加速

模型可觀測

為保障大模型服務在生產環境中的質量和穩定性，我們通常需要對模型的性能進行持續監控、評估和優化，以及對模型的運行環境進行管理和維護。在火山引擎云環境中，用戶可以通過結合容器服務 VKE 和托管 Prometheus VMP，來實時跟蹤 GPU 利用率、推理引擎的延時、吞吐量等關鍵指標。

在 VKE 集群控制臺側邊欄找到云原生觀測，如下圖指示，進入概覽按照頁面指引開啟云原生觀測和容器監控。

在觀測配置中啟用 AI 資源

創建 service monitor

kubectl apply -f sglang-api-svc-discover.yaml

完成觀測配置后，就可以通過Grafana 查看到Sglang 的監控信息，Sglang 監控Grafana 面板配置請下載?https://modeltest.tos-cn-beijing.volces.com/files/sglang-dashboard.json?并導入到Grafana 中

Grafana 的部署和配置可參考?在容器服務集群中部署 Grafana 并接入工作區

HPA 彈性擴展

通過 LWS 部署分布式推理服務后還可以與 k8s HPA 無縫對接，將 LWS 作為HPA 擴容的Target，實現推理服務整組擴容。同時對于GPU 負載的 HPA 還需要能夠更為準確的反映 GPU 繁忙程度的指標進行反饋，目前推薦的指標是DCGM_FI_PROF_SM_ACTIVE，DCGM_FI_PROF_SM_ACTIVE 表示在一個時間間隔內，至少一個線程束在一個SM(StreamingMultiprocessor)上處于Active的時間占比。該值表示所有SM的平均值相對GPU 使用率更能準確表達GPU多核利用情況

確表達GPU多核利用情況

apiVersion: autoscaling/v2

kind: HorizontalPodAutoscaler

metadata:

spec:

minReplicas: 1

maxReplicas: 5

metrics:

- pods:

metric:

target:

type: AverageValue

averageValue: "0.3" # 根據實際使用情況配置

type: Pods

scaleTargetRef:

apiVersion:?http://leaderworkerset.x-k8s.io/v1

kind: LeaderWorkerSet

behavior:

scaleDown:

policies:

- periodSeconds: 300

type: Pods

value: 2

- periodSeconds: 300

type: Percent

value: 5

selectPolicy: Max

stabilizationWindowSeconds: 300

scaleUp:

policies:

- periodSeconds: 15

type: Pods

value: 2

- periodSeconds: 15

type: Percent

value: 15

selectPolicy: Max

stabilizationWindowSeconds: 0

kubectl apply -f sglang-hpa.yaml

模型加速

DeepSeek R1 模型的參數量高達 671B，模型參數文件需要 700GB（FP8），即使是蒸餾后的模型，參數文件也有數十 GB，存在模型下載時間過長的問題。對此，火山引擎容器服務 VKE 提供了存儲訪問加速能力，依托開源項目 Fluid ，可以為用戶提供更好的存儲訪問效果。

存儲訪問加速功能核心原理是通過緩存的方式來突破大數據量場景下的訪問速度瓶頸。比如有 10 個推理服務實例同時啟動，需要從對象存儲中拉取數據，這時由于總的可用帶寬是固定的，每個實例只能分到總帶寬的十分之一，這就會導致數據拉取的延時顯著增加，進而影響性能。為了彈性伸縮計算側的分布式緩存，我們可以將底層存儲系統的有限帶寬擴展到 Kubernetes 集群內，讓集群內的可用帶寬取決于分布式緩存節點數，這樣我們就能根據業務需求靈活伸縮，大幅縮短模型加載時長。

我們基于 Deepseek R1 全尺寸版本模型拉取的測試，證實 Fluid+CFS Runtime 確實可以有效減少模型拉取時間，相對于直接從對象存儲上拉取能夠縮短30% 的模型拉取時間。

前置準備

1.在 VKE 集群中通過【組件管理】模塊安裝 csi-cloudfs 組件，該組件承擔了在 Kubernetes 中使用火山引擎大數據文件存儲的集成能力：

2.在【云原生 AI 套件-數據加速】模塊中一鍵安裝部署 Fluid 應用，并確保 Fliud 中的 dataset-controller 和 cfsruntime-controller 等工作負載處于正常運行狀態。VKE 提供的 Fliud 與開源社區同源，還額外支持了對接火山引擎大數據文件存儲 CloudFS 的能力，并且通過應用中心提供開箱即用的能力：

3.在大數據文件存儲產品內，創建文件存儲并選擇應用場景為【數據湖場景】（應用場景存在可用區級別差異，請選擇可支持數據湖場景的可用區），保證文件存儲實例與 VKE 集群處于相同的私有網絡 VPC 內，并且在【子網】處勾選“支持該私有網絡下的所有子網訪問”，以便于后續相同 VPC 內均可訪問當前 CloudFS 實例：

操作步驟

1.創建數據集。在 VKE 集群中的【云原生 AI 套件-數據加速】模塊中創建 Fluid 數據集，在基本信息模塊配置數據集名稱、歸屬命名空間等信息（后續僅處于與數據集相同命名空間的工作負載才能使用數據集），配置數據集目的端（前置準備階段所創建的 CloudFS 實例）、數據源端（一般是 TOS 等）：