Kubernetes 已經能看到 GPU，不代表能像分配 CPU 或記憶體一樣，讓 Pod 申請 1GB、2GB 的 VRAM。透過 NVIDIA device plugin 暴露的 nvidia.com/gpu 屬於 extended resource，預設單位是「裝置數量」，不是顯示記憶體容量。

這個差異會直接影響排程、資源利用率與多租戶隔離，也是設計 GPU sharing 方案之前必須先理解的限制。

GPU request 申請的是裝置數量

最常見的 GPU 資源宣告如下：

apiVersion: v1
kind: Pod
metadata:
  name: inference-demo
spec:
  containers:
    - name: inference
      image: example/inference:latest
      resources:
        limits:
          nvidia.com/gpu: 1

nvidia.com/gpu: 1 表示容器需要一個 GPU 裝置。這段設定沒有表達「只需要 4GB VRAM」，也沒有告訴 Scheduler 模型實際會用掉多少顯示記憶體。

對 extended resource 而言，GPU 必須以整數申請，而且通常只設定 limits；若同時設定 requests，兩者數值必須相同。Scheduler 只會檢查節點上是否還有足夠的可分配 GPU 數量。

排程成功，不等於模型跑得動

假設節點有一張 24GB GPU：

• Pod A 申請 nvidia.com/gpu: 1，模型只使用 6GB VRAM。
• 對預設 Scheduler 來說，整張 GPU 已經分配完畢。
• Pod B 即使只需要 4GB VRAM，仍會因為沒有可分配 GPU 而保持 Pending。

另一種情況是 Pod 成功取得一張 GPU，但模型權重、KV cache 與執行時額外配置合計超過 24GB。Kubernetes 仍然會把 Pod 排到該節點，實際啟動後才因 OOM 失敗。

原因很直接：Scheduler 看得到 GPU 數量，卻不知道模型載入後的 VRAM 使用方式。

CPU、記憶體與 GPU 的資源模型不同

CPU request 可以用 millicore 表示，記憶體 request 可以用 MiB 或 GiB 表示。Scheduler 能把多個 Pod 安排到同一節點，前提是 request 總和沒有超過節點容量。

預設 GPU extended resource 沒有這種細粒度。nvidia.com/gpu: 1 不是 1GB，也不是某個百分比，而是一個可被分配的 GPU 資源單位。因此，下列設定並不成立：

resources:
  limits:
    nvidia.com/gpu: 4Gi

若需要共享一張實體 GPU，必須另外導入 sharing 機制，而不是把 VRAM 容量直接寫進 request。

常見的共享方式

Time-Slicing

多個 workload 輪流使用同一張 GPU，可以提高低負載服務的裝置利用率。缺點是缺乏硬體層級的記憶體隔離；任一程序仍可能耗盡 VRAM，效能也會受到其他 workload 影響。

NVIDIA MPS

MPS 允許多個 CUDA 程序更有效率地並行使用 GPU，適合特定計算型工作負載。不過，資源隔離、錯誤影響範圍與相容性仍需要實測，不能只把 MPS 當成免費的效能提升。

MIG

支援 MIG 的 GPU 可以切成多個具備獨立運算與記憶體資源的實例。Kubernetes 看到的是 MIG profile 對應的資源，隔離性通常優於 time-slicing，但切割規格固定，也會增加容量配置與維運複雜度。

應用程式層共享

由單一 serving engine 集中載入模型，再透過 continuous batching、queue 與併發控制服務多個使用者。這種方式往往比讓多個 Pod 各自載入模型更節省 VRAM，但隔離責任會轉移到應用程式層。

評估時不要只看 Pod 是否 Running

驗證 GPU 配置時，至少要同時記錄：

• Pod 的 request、phase 與 Pending reason。
• 實際 GPU 與 VRAM 使用量。
• 模型載入是否成功，以及是否出現 OOM。
• 不同併發數下的 TTFT、P95 latency 與 throughput。
• 同卡 workload 互相影響的程度。

Pod 進入 Running 只代表排程與啟動流程通過，不代表服務已達到效能或隔離目標。

結論

Kubernetes 預設把 GPU 當成以裝置數量計算的 extended resource。Scheduler 能決定 Pod 放在哪個節點，卻不理解模型需要多少 VRAM，也無法單靠 nvidia.com/gpu 保證服務品質。

因此，整卡 request、VRAM 容量與實際推論效能必須分開看待。下一篇將進一步處理 Label、NodeSelector 與 Affinity，讓工作負載進入符合需求的 GPU 節點。

參考資料

• Kubernetes: Schedule GPUs
• Kubernetes: Resource Management
• Kubernetes: Assigning Pods to Nodes
• NVIDIA GPU Operator Documentation