GPU 當機不再是黑盒子：DirectX Dump Files 開放預覽，事後重現 GPU 崩潰狀態
Microsoft DirectX Dev Blog · 2026-06-18
微軟於 2026 年 6 月 18 日宣布 DirectX Dump Files 正式進入公開預覽，這是 Windows 平台 GPU 崩潰除錯的重大突破。開發者第一次可以在 GPU 當機的瞬間捕捉完整的硬體執行快照，事後在另一台機器上進行深度分析，無需重現原始環境。AMD、Intel、NVIDIA、Qualcomm 四大 IHV 均在 GDC 上完成了相容性展示。
原本的問題：GPU 崩潰幾乎無從追蹤
傳統的 GPU 除錯高度依賴重現崩潰——開發者必須在原機器上反覆觸發問題，再以工具攔截當下狀態。GPU 崩潰往往只留下一個裝置移除錯誤碼，既無呼叫堆疊，也無著色器執行資訊，更難以讓 ISV 跨機器共享診斷資料。對於只在特定硬體組合或特定驅動版本下發生的間歇性問題，這種限制代價極高。
現有的 DRED（Device Removed Extended Data）雖然能提供部分執行佇列資訊，但仍無法捕捉著色器波次狀態、GPU 記憶體頁面錯誤或驅動程式內部的診斷資料。整個問題的根源在於：崩潰發生當下，所有關鍵狀態都隨著裝置重置而消失。
採用的方法：.dxdmp 快照與分層式 Overhead 控制
DirectX Dump Files 的核心是一個新的預覽介面 ID3D12DevicePreview，提供五個主要方法。ConfigureDumpFile() 讓應用程式控制驅動程式資料蒐集的精細程度，從零執行期成本的 D3D12_DUMP_FILE_DRIVER_OPTIONS::NO_OVERHEAD，到可捕捉 GPU 波次暫存器狀態的 SHADER_REGISTERS，再到追蹤資源生命週期的 RESOURCES，開發者可依除錯需求分級啟用。
當裝置移除事件觸發時，執行期會將以下資料聚合進一個 .dxdmp 檔案：D3D12 執行期詮釋資料與 DRED 資料、透過 AddBlobToDumpFile() 注入的應用程式自訂診斷資料（上限 2 MB）、以及驅動程式核心模式與使用者模式的除錯 Blob，包含著色器記憶體、PSO 識別碼、命令緩衝區與圍欄值。檔案預設儲存於 C:\Users\UserName\AppData\Local\CrashDumps，命名格式為 ExeName-yyyy-mm-dd-hh-mm-ss.dxdmp。
應用程式可透過 SetDumpFileCallbacks() 註冊 Begin 與 End 兩個回呼：Begin 回呼可決定是否繼續建立 Dump，End 回呼則在 Dump 完成後收到檔案路徑，讓開發者能將其整合進現有的崩潰蒐集系統。此外，HLSL 新增了 DebugBreak() 內建函式，讓著色器在遇到非預期條件時主動觸發 Dump，無需等待裝置移除事件。
實際效果：PIX 多視角分析，跨機器事後重現
配合 PIX 2606.18-preview 版本，.dxdmp 檔案可在完全不同的機器上離線分析。PIX 提供四個主要視圖：Summary View 可自動偵測崩潰原因；Events View 顯示 D3D12 呼叫序列、驅動程式事件與 PIX 標記；Shader Waves View 列出崩潰當下正在執行的著色器波次資訊；Page Faults View 呈現 GPU 記憶體頁面錯誤；Resources View 則羅列已捕捉的 GPU 資源。
硬體支援方面，AMD 需要 Radeon RX 7000/9000 系列搭配驅動 26.10.07.02；作業系統需為 Windows 24H2、25H2 或 26H1，並安裝對應的 KB 更新（KB5089573 或 KB5089570）；SDK 端則需要 Agility SDK 1.721.1-preview 並開啟開發者模式。正式零售支援預計於 2026 年秋季推出，現階段的預覽版本不適合部署至正式遊戲環境。
- 驅動程式能力分級：Tier 1 僅支援 Overhead 選項；Tier 2 支援含
NO_OVERHEAD在內的所有細粒度選項 - Dump 檔案會自動上傳至 Watson，ISV 可透過雲端服務存取
- 社群支援管道：DirectX Discord 的
#dxdmp頻道，或直接寄信至dxdmpsupport@microsoft.com
原始來源：Microsoft DirectX Dev Blog — DirectX Dump Files Preview Now Available!、D3D12 GPU Dumps 技術規格
不只是呼叫 API：微軟 Foundry 與 OpenEnv 打造企業級強化學習閉環系統
Microsoft Azure AI Foundry Dev Blog · 2026-06-18
微軟 Applied AI 首席研究工程師 Govind Kamtamneni 於 2026 年 6 月 18 日發表深度技術文章，闡述如何用強化學習（RL）建構真正能隨時間改進的 AI 系統。文章的核心主張是：「持久的資產不是你租用的模型，而是你擁有的學習迴路。」微軟同時宣布加入 OpenEnv 社群，並貢獻兩項企業級核心元件。
原本的問題：一次性推論無法累積改進
大多數企業 AI 部署的模式是：送出 Prompt、取得回應、結束。這種模式讓模型成為靜態消耗品，無法從業務結果的回饋中自我改進。以一個客服支援智能體為例，即使它每天處理數千筆工單，如果沒有學習迴路，六個月後的表現和第一天相同。
傳統 RL 訓練的另一個痛點是環境隔離不足：在企業網路中執行的 RL 智能體可能因為 egress 未受限，導致 token 或憑證外洩。此外，標準 RL 訓練中，智能體與環境互動產生的軌跡裡，高達 89% 的觀測 token 被直接丟棄，未充分利用這些環境反饋訊號。
採用的方法：兩種學習模式與 ECHO 世界模型
文章提出兩種學習模式的分工。非參數式學習（權重凍結）透過最佳化 Prompt、技能描述、工具說明與模型選擇來提升表現；文章舉例說明一個支援智能體在不重新訓練模型的情況下，準確率從 0.60 提升到 0.92。參數式學習則透過後訓練（post-training）直接微調模型權重，目標是獲得更快、更低成本的推論並取得完整所有權。
ECHO（Terminal Agents Learn World Models for Free）是文章中最具技術份量的創新，出自微軟研究院。其核心概念是在單一最佳化步驟中合併兩種損失函數：對動作 token 執行標準 RL 損失，同時對環境觀測 token 執行交叉熵損失（即世界模型損失）。這讓先前被丟棄的 89% 觀測 token 轉化為有效的學習訊號。
實驗結果顯示，ECHO 使得 held-out pass@1 指標提升約兩倍，RL 訓練到達目標的速度則快了約 2.3×。微軟對 OpenEnv 的兩項貢獻分別是：Azure Container Apps 沙盒提供者（預設拒絕 egress，防止 token 外洩）；以及 ECHO 世界模型的 RFC 010 提案，將其納入 OpenEnv 的開放協定標準。
實際效果：Foundry 堆疊的各層元件
Azure AI Foundry 將上述概念整合為一套完整的企業 RL 堆疊。Agent Optimizer 負責協調非參數式學習迴路；SkillOpt 專注於技能文件最佳化；Foundry IQ 作為知識層；Toolboxes 提供受治理的工具集；Managed Compute 則為訓練與推論提供算力。
- OpenEnv 協定：基於 Gymnasium 風格的 API（
reset()、step()、state()），以 WebSocket 進行非同步通訊，支援 Docker、Kubernetes 等容器執行環境，目前版本為v0.3.1 - ECHO RFC 010：利用環境反饋的觀測 token 作為世界模型訓練訊號，與標準 RL 損失同步計算
- ACA 沙盒提供者：企業級隔離，預設封鎖所有對外網路連線，確保 RL 訓練期間的憑證安全
原始來源：Microsoft Azure AI Foundry Dev Blog — Outcome-driven learning systems、arXiv 2605.24517 — Terminal Agents Learn World Models for Free、OpenEnv GitHub Repository
自帶 API 金鑰入場：VS Code 正式支援 BYOK，七大供應商模型直通 Chat
VS Code Blog · 2026-06-18
VS Code 團隊的 Kayla Cinnamon 於 2026 年 6 月 18 日宣布，Bring Your Own Key（BYOK）功能已在 VS Code 中正式落地，讓開發者無需 GitHub Copilot 訂閱，即可將 Azure、Anthropic、Gemini、OpenAI、Hugging Face、OpenRouter 以及本機模型（Ollama、Foundry Local）直接接入編輯器的 Chat 介面。這項功能延伸了去年 10 月預覽期的範疇，現已成為 VS Code 核心功能的一部分。
原本的問題：換個模型要換整套工具鏈
在 BYOK 推出之前，VS Code 的 AI 功能深度綁定 GitHub Copilot 訂閱體系。想要測試某個特定版本的模型，或使用公司已和特定供應商簽訂合約的 API，開發者往往只能另開終端機或切換至其他工具。模型碎片化問題——不同任務最適合不同模型——在強制單一供應商的情境下更加突出。
對於企業環境而言，問題更為複雜：IT 部門可能已和 Azure OpenAI 或 Anthropic 簽署企業合約，但如果員工的 VS Code 只認 GitHub Copilot 額度，這些合約資源就無法被充分利用。管理員對員工可使用哪些外部 AI 服務的掌控力也相當有限。
採用的方法：Language Models 編輯器與分層授權
設定入口位於 Chat 的模型選擇器或命令列（Chat: Manage Language Models），開啟後即可看到 Language Models 編輯器。內建供應商（Azure、Anthropic、Gemini、OpenAI、Hugging Face）只需填入 API 金鑰與模型識別碼即可啟用；擴充功能型供應商則以帶有 language-models 標籤的 VS Code 擴充功能形式安裝，安裝後模型自動出現在選擇器中。
本機模型方面，Ollama 與 Foundry Local 均受支援，適合在離線或受限網路環境中使用。設定示例中展示了一個 Mistral 的配置欄位，包含 Endpoint URL、API 類型、以及模型能力聲明（toolCalling、vision、token 上限）。對於沒有 GitHub 認證的用戶，VS Code 設定中的 chat.utilityModel 與 chat.utilitySmallModel 可指定輕量背景模型，處理生成 Chat 標題、提交訊息建議、重新命名建議等輔助任務。
實際效果：Chat 任務可用，程式碼補全另計
BYOK 目前覆蓋 Chat 介面與工具性任務（Utility tasks），不涵蓋行內程式碼補全（inline completions）。語意搜尋、行內建議與嵌入式功能仍需 GitHub 認證，費用由各供應商直接計費，不走 GitHub Copilot 額度。
| 功能 | BYOK 可用 | 需 GitHub 認證 |
|---|---|---|
| Chat 對話 | 是 | 否 |
| 工具性任務（提交訊息等） | 是（需設定 utilityModel） | 否 |
| 行內程式碼補全 | 否 | 是 |
| 語意搜尋 / 嵌入 | 否 | 是 |
對於使用 Copilot Business 或 Copilot Enterprise 的組織，管理員可在組織層級控制 BYOK 的可用性，決定是否允許員工自行接入外部模型。這為企業提供了在靈活性與合規管控之間取得平衡的機制。
原始來源：VS Code Blog — Use your own language model key in VS Code