HAMi 拆分出 HAMi-DRA：GPU 排程改走 Kubernetes 原生 DRA，libvgpu.so 仍留任隔離層
project-hami.io 官方文件 · 2026-08-07
CNCF 於 2026-08-07 發布的部落格文章釐清了一個社群持續在問的問題：Kubernetes 的 Dynamic Resource Allocation（DRA）是否會取代 GPU 共享排程專案 HAMi。答案並非全有或全無——HAMi 專案將原本單體的排程與隔離邏輯拆成兩個獨立元件：負責與 DRA 對接的 HAMi-DRA，以及繼續透過 libvgpu.so 做顯存與算力攔截的 HAMi-core。這個拆分讓 HAMi 得以站上 Kubernetes 官方的資源排程機制，而不必放棄既有的容器級限流能力。
核心改動
HAMi-DRA 的本質是一個 Mutating Webhook，會把使用者在 Pod 規格中以傳統 Device Plugin 語法（例如 nvidia.com/gpu、nvidia.com/gpumem、nvidia.com/gpucores）宣告的 GPU 資源請求，自動轉換成 Kubernetes DRA 的 ResourceClaim 物件。這個轉換動作被官方文件稱為「DevicePlugin-compatible mode」，目的是讓既有的 HAMi 使用者不必重寫工作負載 YAML 就能遷移到 DRA。除了 Webhook 之外，架構還包含負責實際裝置配置的 kubelet 外掛 hami-dra-driver-kubelet-plugin，以及一個透過 Prometheus 對外暴露 GPU 指標、可選安裝的監控元件（NodePort 31995）。
要理解這次改動為什麼重要，得先弄清楚 DRA 跟舊有 Device Plugin 機制的差異。傳統 Device Plugin 模式下，kubelet 只會把裝置數量以 extended resource 標籤方式回報給排程器，排程器對硬體細節一無所知，配置邏輯完全黑箱在 Device Plugin 內部。DRA 則引入 ResourceClaim 與 ResourceSlice 兩個 API：資源驅動程式（resource driver）透過 ResourceSlice 向叢集發布硬體的完整屬性描述，排程器再依據 Pod 引用的 ResourceClaim 篩選條件，動態比對出符合的裝置。這讓資源篩選、拓樸感知配置等邏輯可以標準化在 Kubernetes API 層，而不必每個廠商各自實作一套 Device Plugin。
規格細節
使用 HAMi-DRA 有明確的版本門檻：叢集需為 Kubernetes 1.34 以上，並開啟 DRA 的 Consumable Capacity 這個 feature gate；NVIDIA GPU 驅動則需 440 版以上。安裝流程分三步：先透過 Helm 部署 cert-manager 處理 Webhook 所需的 TLS 憑證，接著加入 HAMi-DRA 的 Helm repo（https://project-hami.github.io/HAMi-DRA），最後安裝 chart，並可針對已預先安裝 GPU 驅動的節點調整參數。容器執行環境需支援 CDI（Container Device Interface），這也是 DRA 生態系與底層 runtime 對接裝置的標準介面。
官方文件同時說明 HAMi-DRA 支援兩種操作模式並存：一種是原生 DRA 模式，使用者直接寫 ResourceClaim 物件；另一種就是前面提到的 DevicePlugin 相容模式，Webhook 在背後自動代為轉換。這個雙軌設計是漸進式遷移策略的關鍵，讓叢集管理者可以先在測試環境驗證 DRA 路徑，再逐步把生產工作負載切換過去，不需要一次性的破壞式升級。
影響範圍
對已經在用 HAMi 做 GPU 共享排程的團隊而言，這次拆分意味著排程邏輯與隔離邏輯的關注點分離：DRA 負責「誰能拿到哪塊 GPU」的排程決策，HAMi-core 的 libvgpu.so 攔截層則繼續負責「拿到之後不能超用多少顯存與算力」的執行期限制。這與 CNCF 稍早（2026-07-15）宣布 HAMi 晉升為 Incubating 專案的時間點相呼應，顯示專案治理與技術路線正同步往 Kubernetes 原生生態靠攏。對於尚未導入 GPU 共享方案、且叢集版本已在 1.34 以上的團隊，這代表可以直接評估 DRA 原生路徑，而不必再繞經舊式 Device Plugin。
原始來源：HAMi 官方文件：How to use HAMi DRA、Project-HAMi/HAMi-DRA (GitHub)、CNCF Blog
GitHub Copilot SDK 推出 Java 支援，v1.0.10-preview.0 補上跨語言的 history.clearContext 與 Tool.isTerminal
github.blog · 2026-08-10
GitHub 官方工程部落格於 2026-08-10 發布文章，說明 Copilot SDK 新增的 Java 語言支援如何讓企業開發者用 annotation 與虛擬執行緒等慣用寫法，在 Java 應用中程式化驅動 Copilot CLI 的代理能力。這篇文章緊接在 SDK 上游倉庫 github/copilot-sdk 於 2026-08-07 發布跨語言版本 v1.0.10-preview.0 之後，Java SDK 隨此版本一併發布，目前對外的穩定套件版本為 1.0.10-preview.0（快照版為 1.0.11-preview.0-SNAPSHOT）。
核心改動
Java SDK 採用 Multi-release JAR 打包，在 JDK 25 以上執行時會自動改用虛擬執行緒（virtual threads）作為預設的內部執行緒池，官方文件原文寫道：「when run on JDK 25 and later, the SDK automatically uses virtual threads for its default internal executor」。這代表同一份 JAR 在 JDK 17（最低需求版本）與 JDK 25 上會有不同的併發行為，開發者不需要額外設定就能在新版 JDK 上獲得虛擬執行緒帶來的高並發優勢，這對需要同時維護大量 Copilot session 的企業應用尤其實用。
工具定義（tool definition）是 SDK 的核心互動模式，Java 版透過四個 annotation 組成完整語意：@CopilotTool 用於宣告一個可供模型呼叫的工具，@CopilotToolParam 標註工具參數，@CopilotExperimental 標記尚不穩定的 API，必須搭配 @AllowCopilotExperimental 才能在呼叫端啟用。這套機制讓實驗性功能可以提前釋出，同時透過編譯期檢查避免使用者在不知情下依賴未穩定的介面。
規格細節
此次同步發布的 v1.0.10-preview.0 是橫跨 Node.js、Rust、Java 等所有 SDK 語言的統一版本，release note 列出的兩項核心能力同樣適用於 Java 版：history.clearContext() 可以清空對話上下文（但保留 system 與 developer 訊息），並要求立即補上一則新的使用者訊息重新開始上下文視窗，這個方法只能在工具處理函式（tool handler）內、且有工具呼叫正在進行時呼叫，對應 PR #2129；另一項 Tool.isTerminal 則讓工具宣告自己是「終止型」——呼叫成功後直接結束該輪代理任務，而不是把結果丟回模型做下一輪推論，呼叫失敗時仍會回到迴圈讓模型讀取錯誤訊息。
- Maven 依賴：
<groupId>com.github</groupId><artifactId>copilot-sdk-java</artifactId><version>1.0.10-preview.0</version> - Gradle 依賴：
implementation 'com.github:copilot-sdk-java:1.0.10-preview.0' - 執行環境需求：Java 17 以上，官方建議搭配 JDK 25 以取得虛擬執行緒優化
- 需搭配 GitHub Copilot CLI
1.0.55-5以上版本
影響範圍
由於 SDK 標榜框架無關（framework-agnostic）且支援自帶金鑰（BYOK）串接多家 AI 供應商，文章特別提到可與 Jakarta EE 應用整合，並附上在 Azure 上部署 Jakarta EE 的官方指引連結。對長期使用 Java 生態系、且已有 Copilot 企業授權的團隊來說，這代表可以把既有的 session 管理、權限控管邏輯，用原生 annotation 與 Maven/Gradle 依賴的方式接進現有服務，而不必透過額外的 CLI 包裝層或跨語言橋接。GitHub 同時提供了一個範例應用倉庫，示範如何用同一份 Copilot SDK 邏輯支援多用戶端、多裝置的代理情境。
原始來源：GitHub Blog：Using the GitHub Copilot SDK for Java、copilot-sdk v1.0.10-preview.0 Release Notes