微軟在稍早正式宣布，Windows Server 2025 的「原生 NVMe 儲存堆疊（Native NVMe）」功能已脫離預覽階段，正式全面推出（GA）。這項更新號稱能帶來高達 80% 的 IOPS 效能提升，並降低 45% 的 CPU 負擔。
對於長期受限於舊有 SCSI 轉換層的 Windows 儲存架構來說，這無疑是一次「砍掉重練」級別的重大升級。但官方宣示精彩數字的背後，市場實際的反應如何？企業是否該立即部署呢？ CyberQ 從技術原理到應用場域實際情況做了檢視。
告別 SCSI 舊時代的重要意義？
在之前，即使你插上了最先進的 PCIe Gen5 NVMe SSD，Windows Server 的核心儲存堆疊（Storage Stack）依然會將其視為一個「SCSI 裝置」。這意味著系統必須經過一層翻譯（Translation Layer），將現代化的 NVMe 指令轉換為老舊的 SCSI 指令。
這種做法在 HDD 時代沒問題，但在 NVMe SSD 動輒數百萬 IOPS 的今天，這層轉換就成了巨大的效能瓶頸。
微軟這次做了什麼？
終於可以繞過 SCSI 層，新的堆疊允許作業系統直接以原生 NVMe 語言與硬體溝通。
再來是進行了多佇列支援（Multi-Queue）， 傳統 SCSI 往往受限於單一佇列（或極少佇列），新架構則完全釋放了 NVMe 支援 64,000 個佇列、每個佇列 64,000 個指令的並行處理能力。
另外，微軟在這次 Windows Server 2025 更新也加入了無鎖 I/O（Lock-free I/O），如此一來，能減少核心在處理 I/O 請求時的 CPU 鎖定與同步開銷。
根據微軟官方測試，透過 DiskSpd 這個工具實測，在 4K 隨機讀取的情境下，啟用新功能後 IOPS 提升了 80%，且 CPU 週期消耗降低了 45%。這對於高頻交易的 SQL Server、密集 I/O 的 AI 模型訓練，以及高負載的 Hyper-V 虛擬化環境來說，是相當不錯的系統效能、IO 方面的重要改善。
( Figure Credit: Microsoft )
( Figure Credit: Microsoft )
還有一個重點可以關注，NVMe 2.0 協定不只是限於 SSD ，也有包括 HDD，因此提供原生 NVMe 支援，可以讓儲存裝置的協定統一，系統能更好地管理裝置，這主要是為了實現資料中心的可組合性（Composability）目標，讓儲存設備能更靈活地搭配使用來足不同應用需求。 雖然對一般 HDD 性能提升不大，畢竟 HDD 速度上限是物理限制，但 NVMe 2.0 協定能整合不同類型儲存，最佳化化資源利用。
如何啟用？（目前仍需手動）
雖然功能已 GA，但微軟採取了保守的「Opt-in（手動啟用）」策略。你需要：
安裝 Windows Server 2025 十月份累積更新（KB5066835 或更新版本）。
確認使用 Windows 內建的 StorNVMe.sys 驅動程式。
透過 PowerShell 修改 Registry 機碼或使用 Group Policy 開啟。
PowerShell 啟用指令範例（請務必先在測試環境驗證）
reg add “HKLM\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides” /v 1176759950 /t REG_DWORD /d 1 /f
( Screenshot Credit: Microsoft )
啟用成功後，裝置管理員中的 NVMe 裝置會從「磁碟機（Disk drives）」移至「儲存磁碟（Storage disks）」類別下，象徵其身分已變。
市場興奮與災情並存
CyberQ 的合作夥伴與工程師團隊觀察，這項更新除了在 IT 群組發酵，在包括 Reddit 的 r/sysadmin、r/WindowsServer 以及各大技術論壇都有引發熱烈討論：
1、正面評價，終於追上 Linux 了
資深系統管理員普遍認為，這是 Windows Server 在儲存效能上追趕 Linux 的關鍵一步。Linux 核心在多年前就已針對 NVMe 進行深度最佳化，Windows 此舉終於追上了。特別是對於採購了昂貴 PCIe Gen5 SSD 的企業來說，這項更新是解鎖硬體真實價值的免費升級。
2、實測落差出現，家用/實驗室場景「無感」？
部分在 Home Lab 環境測試的用戶表示，在一般的檔案複製或遊戲伺服器應用中，感受不到明顯差異。CyberQ 實測認為，這項技術主要針對高並發（High Concurrency）、極低延遲的企業級負載（如資料庫交易）。如果你的應用場景原本就沒吃滿 I/O Queue，啟用後自然無感。
3、災情回報指出部分外接裝置與相容性疑慮
另一方面，並非所有市場反應都是正面的。
外接 NVMe 會呈現斷線： 有用戶回報透過 Thunderbolt 或 USB 外接的 NVMe 在啟用此功能後，出現寫入錯誤甚至自動斷線的情況。這顯示新驅動對於熱插拔或非直連 PCIe 通道的穩定性仍有待觀察。
虛擬化層的困惑： 在 Proxmox 或其他 Hypervisor 上執行 Windows Server 2025 的用戶發現，若底層虛擬磁碟設定不當（如誤用 IDE 模擬），啟用此功能非但沒變快，反而可能因驅動衝突導致效能下降。
4、部分市場觀點為 AI 伺服器鋪路 ?
雖然有市場分析師認為，微軟急於在 2025 版本推出此功能，是為了迎合 AI 基礎設施的需求。AI 訓練過程中的 Checkpoint 寫入和資料集載入對儲存頻寬要求極高，若 Windows Server 無法提供原生的 NVMe 高效能，企業可能會更傾向將 AI 負載全面遷移至 Linux 環境。
但 CyberQ 認為，實際上，大部分 AI 伺服器多半是 Linux 平台居多，特別是在「AI 工作負載」與「高性能運算（HPC）」領域。雖然沒有一份單一報告能精確統計全球每一台實體 AI 伺服器的 OS，但我們可以從以下幾個關鍵資料點獲得比較清楚的作業系統比例概念，比方說根據 Linux 基金會的報告，公有雲伺服器有超過 90 % 都是 Linux 伺服器。另外在 AI 與機器學習工作負載，AI/ML 工作負載的 Linux 市占率也很高，絕大多數的 AI 模型訓練（Training）與推理（Inference）都運行在 Linux 環境上。這包括了主流的開發框架（如 PyTorch、TensorFlow）以及 NVIDIA 的驅動與生態系（CUDA），它們的原生開發環境皆以 Linux 為優先。
由於大部分 AI 算力是在雲端租用的，雲端 OS 的比例極具代表性，雲端 AI 基礎設施的 Linux 市占率超過 90%。AWS、Google Cloud 和 Azure 的 GPU 實例（如 NVIDIA H100/A100 VM），預設與推薦的 OS 映像檔幾乎全數為 Ubuntu、Rocky Linux 或 Amazon Linux。即使是微軟自家的 Azure，其高階 AI 運算核心也大量依賴 Linux。
Windows Server 在這個領域比較少，主要用於企業內部整合、與既有 Microsoft 生態系（如 Active Directory, .NET 應用）結合的邊緣 AI 推理，或是使用 Azure Stack HCI 等混合雲架構的場景。這次在 NVMe 有感的更新，是 Windows Server 不得不跟上的步伐，短期內對市占率影響不大，但對於許多系統維護者和相關廠商來說仍舊是重要的一大改進。
Windows Server 確實需要原生 NVMe
CyberQ 認為，「原生 NVMe」是 Windows Server 未來十年的儲存要務，但現在或許還不是全面部署的時候。
CyberQ 建議：
1、特定工作負載先測試，優先在 SQL Server 或高效能檔案伺服器（File Server）的測試環境中驗證，觀察部署更新後，系統中 CPU 負載降低的效果是否顯著。
2、避開非標準硬體，對於使用第三方 RAID 卡或特殊 NVMe 控制器的系統，請先保持觀望，確認廠商驅動程式與微軟原生堆疊的相容性。已經有一些合作夥伴的測試出現找不到裝置的情況，類似災情也是不少，推測是驅動程式與系統新元件本身不相容或其他 bug 導致。
3、備份是優先原則，由於涉及底層儲存堆疊的變更，啟用前請務必做好完整的備份與還原計畫。
這次的更新意味著 Windows 終於甩掉了 SCSI 的歷史包袱，但在追求 80% 讀寫效能提升的同時，穩定性仍是伺服器維運的最高指導原則，可以先部署和測試，在你的環境陸續都沒問題後，再擴大部署範圍。
Windows 11 會支援這項功能更新嗎 ?
CyberQ 認為，由於 Windows Server 2025 與 Windows 11 24H2 有不少程式碼是共用的，25H2 則是 24H2 後續的版本，理論上未來應該是可以支援的。技術上 Windows 11 24H2 與未來的 25H2 絕對包含這項技術，但目前處於隱藏或被動狀態。
根據微軟官方部落格釋出的 Group Policy 設定路徑，已經不小心洩漏了這項功能與 Windows 11 的關係，我們從資料中可以看到微軟官方路徑露餡了，在微軟官方公布的啟用步驟中，提到的 Group Policy 路徑非常耐人尋味：
Administrative Templates > KB5066835 … > Windows 11, version 24H2, 25H2
這個路徑名稱直接證實了程式碼有共用，也就是前面說的 Windows Server 2025 與 Windows 11 24H2（及未來的 25H2）共用相同的核心（Kernel）與儲存驅動（stornvme.sys）。這項「原生 NVMe」的程式碼已經存在於我們許多人在辦公室或家裡現在使用的 Windows 11 24H2 之中。版本確認的部分，微軟內部也將此功能標記為適用於 Windows 11 24H2 與 25H2。
2、為什麼 Windows 11 沒有大張旗鼓宣傳？
既然功能已經存在，為什麼微軟只對 Server 用戶喊話，卻對 Windows 11 用戶保持低調？主要原因有二：
A、工作負載的差異
伺服器場景才會優先需要這項功能，畢竟這類技術主要是為了解決高併發 I/O 情境下的軟體佇列與中介層瓶頸。在資料庫或虛擬化伺服器中，系統可能同時維持數百甚至上千筆並行 I/O 請求。此時，傳統以 SCSI 為核心的轉換層（如 StorPort）容易成為排程與鎖競爭的瓶頸，而 NVMe 原生路徑能顯著降低這類開銷。
但是在消費級場景（如 Windows 11）時，即便你是重度玩家或 Youtuber、影音創作者，你的日常操作（開機、遊戲讀取、影片剪輯）通常只有 QD=1 到 QD=4 的深度。在這種低併發的情況下，繞過 SCSI 層所節省的微秒級延遲，體感上幾乎是零。除非是 DirectStorage + 高頻小檔案串流、或特定 AI 推論快取場景，否則對一般桌機使用者而言，這類最佳化幾乎沒有可感知差異。
B、穩定性考量
儲存堆疊（Storage Stack）是作業系統最底層、最敏感的部分。在比伺服器環境呈現硬體多樣性的環境下，Windows 11 執行的硬體環境極其複雜，包括各種 DIY 主機板、廉價的外接盒、轉接卡，也因此稍早社群回報的 Windows Server 2025 外接 SSD 斷線災情證明，這項新技術在非標準環境下仍有 Bug。
故微軟自然是採取伺服器先進行升級的策略，讓專業 IT 人員在受控環境下先除錯，等到技術完全成熟，CyberQ 預估可能要等到 Windows 11 25H2 之後的版本或更新的版本，才會考慮對一般消費大眾預設開啟。
推薦閱讀
Announcing Native NVMe in Windows Server 2025: Ushering in a New Era of Storage Performance
