Linux 安裝過程與記憶體配置限制

在 MSI Prestige N16 Flip AI Plus 等搭載 RTX Spark 平台的筆電上安裝 Linux 並非即插即用。測試者嘗試使用基於 Arch 的 Omarchy 發行版時，初期遇到顯示閃爍不穩定的問題；改用 Debian 則面臨 Wi-Fi、鍵盤、觸控板及 GPU 驅動缺失的情況。最終透過 Omarchy 內建的 Nvidia 開放原始碼核心驅動解決了驅動問題，但系統僅能識別 128GB 統一記憶體中的 28GB。

這是因為筆電韌體預設保留 96GB 給 GPU 使用，且該分割設定僅能在 Windows 環境下調整。測試者必須先在 Windows 中將 GPU 記憶體保留量降至 4GB，重新啟動進入 Linux 後才能識別剩餘的 120GB 記憶體。完成此步驟後，系統可正常運行 4K 120Hz 桌面環境並啟用 CUDA 加速，但在安裝過程中透過 HDMI 輸出畫面曾遭遇困難，需借助外部攝影機觀察螢幕內容以進行遠端操作。

效能測試數據：連接電源時速度暴跌

在執行 GPT-OSS-120B 模型的基準測試中，Windows 系統達到每秒 65.4 個 token，WSL 為 65.1，Nvidia DGX Spark 桌面版為 61。然而，同一台筆電上的原生 Linux 僅能達到每秒 13.9 個 token，速度約為 Windows 的五分之一。另一項使用 vLLM 處理八個並發客戶端的測試顯示，WSL 達到每秒 127 個 token，而原生 Linux 僅為 39.5。

長時間運算測試進一步證實了差異：Windows 在約 8 分鐘內完成任務，GPU 時脈維持在接近 2.2 GHz；Linux 則耗時 37 分鐘，期間 GPU 時脈始終停留在約 790 MHz。由於測試過程中溫度僅在 40 至 47°C 之間，排除了熱節流（thermal throttling）的可能性，顯示 GPU 是被強制限制在低頻運作。

值得注意的是，效能瓶頸與電源狀態呈現反直覺的關係。當筆電斷開電源使用電池時，Linux 的 GPU 時脈可達到約 1,800 MHz，推論速度回升至每秒 61 到 67 個 token，與 Windows 表現相當。一旦連接牆壁電源，效能便立即崩潰降至每秒約 15 個 token。

根本原因：Windows 獨佔的加密電源管理韌體

問題根源在於 Windows 裝置管理員中可見的「Nvidia Platform Controllers and Framework」元件。這個僅存在於 Windows 的驅動與韌體邏輯負責協調 CPU 與 GPU 之間的共享功率預算，因為筆電架構必須在兩顆晶片間平衡電力分配，不同於 DGX Spark 桌面版可獨立供電給 GPU。

測試中若在 Windows 停用該控制器，GPU 時脈同樣會從約 2 GHz 降至 786 MHz，推論速度從每秒 83 個 token 跌至 31，證實了該控制器是效能關鍵。Linux 驅動程式目前無法解密韌體提供的加密功率表，導致系統無法讀取正確的電源管理參數。測試中嘗試過的軟體修正方法均告失敗，甚至引發核心恐慌（kernel panic）。

雖然理論上可從 Windows 驅動中提取解密金鑰作為變通方案，但這僅適用於單一機型的脆弱駭客式修改，無法廣泛應用。真正的解決方案需要 Nvidia 在其 Linux 驅動程式中移植等效的電源管理邏輯，否則 Linux 用戶將持續面臨此限制。

WSL 作為目前的實用折衷方案

對於大多數開發者而言，使用 WSL（Windows Subsystem for Linux）是目前最務實的選擇。由於 WSL 建立在 Windows 驅動堆疊之上，它能繼承 Windows 完整的 GPU 加速行為，無論筆電是否連接電源都能維持高時脈運作，同時支援 vLLM、SGLang 等以 Linux 為優先的 AI 工具鏈。

使用 WSL 仍需手動調整記憶體配置，因為其預設僅保留 14GB，不足以應付 128GB 統一記憶體機器上的大型模型工作負載。調整後，WSL 的基準測試結果接近原生 Windows 效能，使其成為在 Nvidia 修復 Linux 驅動缺口之前的最佳過渡方案。