專案¶
專案是平台上資源分配的主要單位。您啟動的每個工作區都會消耗專案的配額，每個設定檔或部署都屬於某個專案。
適用對象： 所有已登入的使用者。帳號建立時會自動產生一個個人專案。
專案生命週期¶
stateDiagram-v2
[*] --> 活躍 : 建立專案
活躍 --> 封存 : 管理員封存
封存 --> 活躍 : 管理員恢復
活躍 --> [*] : 管理員刪除專案頁面布局¶
圖 1：專案列表，以卡片模式顯示各專案的 GPU 使用量。
專案頁面支援兩種檢視模式：
- 卡片模式 — 顯示專案名稱、描述、成員數、GPU 使用量長條
- 列表模式 — 精簡的可排序表格
使用工具列右上角的圖示切換檢視模式。
建立專案¶
- 點擊左側選單的 專案。
- 點擊 + 新增專案（右上角按鈕）。
- 填寫專案表單：
| 欄位 | 說明 |
|---|---|
| 名稱 | 簡短的英數識別碼（可使用連字號） |
| 顯示名稱 | 介面中顯示的可讀名稱 |
| 描述 | 選填——專案用途說明 |
- 點擊 建立。專案會立即出現在您的列表中。
配額由管理員指派
新建的專案 GPU 配額從零開始。請聯繫管理員或透過 申請 提交資源申請，將資源計畫繫結到您的專案。
專案詳情標籤¶
點擊專案卡片開啟詳情頁面。核心標籤包含總覽、設定、計畫、建置、GPU Claims 與資源；映像、成員、儲存等標籤會依您的專案角色顯示。
圖 2：專案詳情頁面，包含總覽、設定、計畫、建置、GPU Claims、資源與依角色顯示的標籤。
| 標籤 | 內容 |
|---|---|
| 總覽 | 描述、配額使用圖表、當前計畫、成員列表摘要 |
| 設定 | 版本化的設定檔（Kubernetes YAML、腳本） |
| 計畫 | 綁定的資源計畫、排程窗口、允許的 GPU 型號與配額範圍 |
| 建置 | 專案容器映像建置、來源選擇、資源設定與 Kaniko log |
| GPU Claims | 以 DRA 為基礎的 ResourceClaim，可預先建立，且只在綁定 live Pod 時消耗 GPU |
| 資源 | 依成員彙整的即時 GPU/CPU/Memory 使用量與可展開的 Kubernetes 資源檢視 |
| 映像 / 成員 / 儲存 | 依角色顯示的映像管理、成員管理、個別配額或儲存權限標籤 |
建置專案映像¶
當專案需要允許清單中沒有的容器映像時，請使用 建置 標籤。專案管理者與專案管理員可在專案啟用 image build 後觸發建置；一般專案成員可以查看狀態與 log，但不能啟動或刪除建置。
來源模式¶
| 來源 | 使用時機 |
|---|---|
| 上傳 archive | 上傳 .tar.gz 或 .zip build context，Dockerfile 需放在根目錄 |
| 從 Storage | 從個人儲存或您有讀取權限的專案儲存路徑建置 |
| 只貼 Dockerfile | 直接貼上 Dockerfile，平台會建立最小 build context |
建置設定¶
| 欄位 | 說明 |
|---|---|
| 映像名稱 | 短名稱，例如 trainer-api；完整 Harbor 路徑由平台產生 |
| Tag | 選填；留空使用平台預設，也可填 v1.0.1 等版本 |
| CPU 核心 | build job 的 CPU request，不可超過專案剩餘 build 容量，也不可超過平台上限 4 |
| Memory（GB） | build job 的記憶體 request，不可超過專案剩餘 build 容量，也不可超過平台上限 16 |
| Timeout（分鐘） | 正整數，上限預設為 120；Kubernetes 也會在此 deadline 停止 job |
Kaniko cache 與暫存 layer 使用的本機磁碟由平台管理員依環境設定上限，使用者無法在建置表單中自行調整。上傳 archive build context 時，平台會在建置前檢查不安全路徑與展開大小；DockerHub base image 會透過平台設定的 Harbor proxy-cache 路徑拉取。
提交後，建置歷史會顯示狀態、來源類型、資源需求、目的映像與即時 log。成功的映像會推送到該專案群組 registry policy 指定的 Harbor namespace；GPU23 Harbor 群組會使用專用 GPU23 build lane。建置者本人或專案管理者可以從歷史中刪除 build artifact。
建置權限由專案治理控制
如果建置表單無法送出，請請平台管理員確認該專案已啟用 Image Build Permission，且已綁定有效的資源計畫。
從個人儲存建置
從 Storage 模式會先從平台資料庫解析您的個人 PVC，若資料庫尚未紀錄但叢集裡已有對應的 user-<name>-storage namespace 與 user-<name>-disk PVC，後端會回退使用該命名繼續建置。若仍出現「personal storage is not initialized」，請先開啟一次 Storage 頁面觸發初始化，或請管理員重新執行 user storage init。
GPU Claims（DRA）¶
GPU Claims 標籤列出可在部署前預先建立的 ResourceClaim。claim
在沒有 live Pod binding 時維持 pending，不會消耗 GPU 配額或
GPU-hours；只有 Kubernetes DRA 配置完成且 reservedFor 指向 live Pod
後才開始計算。每個 claim 透過 Kubernetes Dynamic Resource Allocation
API 建立；當 Pod 或 Deployment template 使用部署時 GPU claim slot
annotation 時，可在部署對話框中選取。
建立 Claim¶
| 欄位 | 說明 |
|---|---|
| Claim 名稱 | DNS-safe 名稱，供 deployment 引用。 |
| GPU 裝置類別 | 排程器要保留的型號，例如 rtx5090.gpu.nvidia.com；表單會預設選第一個具體型號，只有想接受任意 NVIDIA GPU 時才明確選 gpu.nvidia.com (Any)。 |
| GPU 數量 | 此 claim 保留的實體 GPU 張數；多 GPU claim 仍是一個 claim-scoped allocation。 |
| SM 比例 | 1% 至 100% 的計算切片；表單旁會顯示對應的有效 GPU 數量。 |
| VRAM 模式 | Elastic 與其他 claim 共享 VRAM；Hard cap 則會強制套用所選比例。 |
| VRAM 比例 | 僅在選擇 Hard cap 時有效。 |
使用可重複 claim 的 Deployment 會讓每個 replica 指向同一個
ResourceClaim。例如 2 張 rtx5090.gpu.nvidia.com claim 仍是一個共享的
2-GPU allocation；平台 labels 會保留 dra-gpu-count=2、
dra-effective-gpu=2、dra-gpu-model=rtx5090，配額與 GPU-hours 也會以
每個 claim 計算一次，而不是每個 replica 計算一次。
pending claim 的 GPU-hours 為 0，也不會降低剩餘配額。表格會顯示擁有者、配置節點、目前狀態（pending、bound 或 terminating）、DRA 回報的 reservedFor 數量，以及刪除按鈕。pending claim 可直接刪除；若已有 live Pod 正在使用，刪除會被拒絕。
Claim 擁有權
專案成員可以在自己的 namespace 下建立 claim。專案管理者另可列出與刪除其他成員建立的 claim。
計畫窗口倒數¶
當專案的資源計畫定義了排程窗口時，計畫 標籤會顯示距離下一個邊界的即時倒數：
- 窗口開啟時顯示 Window closes in HH:MM:SS。
- 下一個窗口尚未開啟時顯示 Window opens in HH:MM:SS。
- 若沒有排程限制則顯示 Always active。
相同的倒數也會出現在工作區啟動表單與個別部署上。窗口關閉後，計畫綁定佇列中的 Pod 會受到平台 plan-window reaper 的處理。
設定檔版本控制¶
設定檔使用內容定址儲存——每個版本不可變且以 SHA-256 雜湊值識別。
sequenceDiagram
participant 使用者
participant 儀表板
participant API
participant CAS as 內容儲存（SHA-256）
使用者->>儀表板: 上傳新 K8s YAML
儀表板->>API: POST /api/v1/configfiles
API->>CAS: 以 SHA-256 儲存 blob
CAS-->>API: blob_id
API-->>儀表板: config_commit_id（不可變）
儀表板-->>使用者: 版本已建立 ✓操作設定檔¶
- 前往 專案 → [您的專案] → 設定 標籤。
- 點擊 + 新增設定 上傳 YAML 檔案或在編輯器中貼上內容。
- 每次儲存都會建立新的不可變版本——舊版本絕不會被覆蓋。
- 點擊設定旁的 歷史 圖示查看所有版本。
- 要部署特定版本，點擊版本列的 部署 按鈕。
- 在彈出的部署對話框中選擇 佇列 (Queue)。若 YAML 包含 GPU claim slot，請為每個 slot 選擇本次部署要使用的已保留 GPU claim。
- 如果您使用 資源嚮導 (Resource Wizard) 建立設定，可以在容器資源設定中直接選定 GPU 型號，系統會自動在產生的 YAML 中加上對應的標籤。
DRA GPU Request 與可重複使用的 GPU Claim¶
- YAML GPU request 是容器資源需求，例如
nvidia.com/gpu-0: "1"或nvidia.com/rtx6000: "1"，可搭配 SM 百分比與 GPU 型號 metadata。平台會在部署時建立執行用的 DRA claim。 - 可重複使用的 GPU claim 是在 GPU Claims 標籤預先建立的獨立 claim。它在 live Pod 使用前保持 pending；綁定後，即使 Deployment 有多個 replica，配額與 resource-hours 也會以每個 claim 的有效 GPU 計算一次。若使用 Resource Wizard，請選 部署時選保留 claim，並填入 部署時顯示的 slot 名稱，例如
train-a；這是部署視窗中的欄位名稱，不是 claim 名稱。若手寫 YAML，請在 Pod metadata annotation 或 Deployment pod-template annotation 放入platform-go/dra-claim-name: '{{ gpuClaimName "train-a" }}'。部署者會在部署對話框中把每個 slot 對應到自己的 claim。 - 舊有的
{{gpuClaimName}}仍是預設 slot。多個 Pod 或 Deployment 可以使用同一個 slot 來刻意共用同一個 claim；不同資源也可以使用不同 slot 對應不同 claim。 - Kubernetes Deployment 的所有 replica 共用同一份 PodTemplate。若只有部分 replica 要使用 claim，請拆成多個 Deployment，例如一個有 claim 的 Deployment 與一個沒有 claim 的 Deployment。
- Service、ConfigMap 與未標註的 workload 不會被注入 GPU claim。
- 不要把
{{gpuClaimName}}放在spec.resourceClaims[].resourceClaimName或resourceClaimTemplateName；這些欄位保留給平台部署時注入。
設定檔需要專案管理者角色
只有專案中擁有 管理者 或更高角色的成員才能建立或編輯設定檔。
管理成員¶
- 開啟專案並前往 成員 標籤。
- 點擊 + 新增成員（需要 專案管理員 角色）。
- 以使用者名稱或電子郵件搜尋使用者。新增成員頁會一次載入專案、目前成員與分頁使用者清單。
- 為每位使用者選擇角色：
| 角色 | 可執行操作 |
|---|---|
| 使用者 | 啟動工作區、查看設定 |
| 管理者 | 編輯設定、管理部署 |
| 管理員 | 新增/移除成員、設定成員配額、刪除專案 |
- 點擊 確認 儲存。
Project Admin 也可以在 Members 標籤勾選多個成員，批次移除、批次變更角色，或批次設定個別 GPU/CPU/Memory 配額。Project Manager 與 Project Admin 可查看成員配額；Project User 只能查看自己的配額。個別配額中的 0 代表該資源不設個人上限，但仍受專案計畫總配額限制。
群組繼承成員的批次操作。 個別配額是儲存在專案層級,因此群組繼承的成員在 Members 表格也可以勾選並納入「批次設定配額」。一旦選取的成員中含有群組繼承的成員,「批次移除」與「批次變更角色」按鈕會自動停用 — 這兩項權限源自擁有群組,必須回到群組層級調整。Group Admin 在自己擁有的群組所屬專案上會被視為 effective Project Admin(見下方 群組繼承與 Effective Project Role),不需要先被加為直接成員,就能看到 Members 表格的勾選方塊並執行批次配額更新。
移除直接加入的成員時，平台也會清掉該成員的專案 namespace、專案儲存權限覆蓋與個別配額。透過群組繼承的成員必須從群組層級移除。
群組繼承與 Effective Project Role¶
群組擁有的專案上,平台依下列順序決定使用者的 effective project role:
- 若使用者有明確的 project member 紀錄,採用該 role(
admin/manager/user)。 - 否則,若是個人專案,personal owner 視為
admin。 - 否則,採用該使用者在擁有群組中的 role 作為 effective project role。因此 Group Admin 對該群組下的所有專案都等同於 Project Admin,即使沒有
project_members紀錄。
這也是為什麼 Group Admin(例如 G260000105 中的 u26000007)可以直接對群組擁有的專案(例如 P26000116)呼叫 PUT /api/v1/projects/{projectId}/members/quotas,並且在 Members 標籤看到批次勾選介面,不需要先被加為該專案的直接成員。
資源標籤¶
資源 標籤依專案成員彙整即時使用量：
| 欄位 | 說明 |
|---|---|
| 使用者 | 專案成員或 namespace 擁有者 |
| GPU | 目前使用中的 DRA 有效 GPU 單位 |
| CPU | CPU 核心數 |
| Memory | 記憶體 MiB |
| Pods | 該成員 namespace 中的 active pod 數 |
Project Admin、Project Manager 與平台 Admin/Manager 可以看到所有成員。一般 Project User 只會看到自己的資源列。展開列後可檢查 Pod 與 Kubernetes 資源，並依權限終止資源。
GPU 配額概覽¶
總覽標籤顯示各資源類型的配額長條：
| 資源 | 追蹤內容 |
|---|---|
| GPU | 已消耗的 DRA 有效 GPU 單位 vs. 計畫上限 |
| CPU | 運行中工作區消耗的 CPU 核心數 |
| 記憶體 | 運行中工作區消耗的 RAM |
若 GPU 長條已滿（100%），新的工作區啟動將排入佇列等待資源釋放。
常見問題¶
看不到 + 新增專案 按鈕。
所有已登入使用者都能看到該按鈕。若未顯示，請嘗試強制重新整理（Ctrl+Shift+R）。若問題持續，請聯繫管理員。
如何查看舊版設定檔？
在 設定 標籤中，點擊任何設定檔旁的時鐘圖示（歷史），即可查看所有過往版本及其時間戳記和 SHA-256 雜湊值。
我的專案 GPU 配額為 0，如何取得更多？
透過 申請 提交資源申請。管理員審核後會將資源計畫繫結到您的專案。
工作區的 GPU 與 GPU Claim 有什麼不同？
啟動工作區時系統會建立一個與 Pod 共生的 inline ResourceClaim。GPU Claim 則是獨立於部署存在的 ResourceClaim——當多個 job 需要共用同一個 fractional GPU、又想避免重新排程時很有用。
為什麼部署按鈕被停用？
可能是專案沒有綁定有效計畫，或計畫窗口目前已關閉、僅能選擇預設佇列。請查看 計畫 標籤了解下一個窗口開啟時間。