AI-LECTURER 速報課|2026-11-05|約 25 分鐘

同一顆晶片,Linux 上只剩三成力氣:被加密的電源韌體如何拖慢 AI 推論

📍 真實場景
阿凱,32 歲,獨立接案的 AI 應用工程師,剛買了一台 MSI Prestige 這類 RTX Spark 筆電

他習慣用 Linux 開發,所以把筆電切到 Linux,想在本機跑 1200 億參數的 GPT-OSS-120B 模型,替客戶做離線的文件問答 demo

😖 卡住的地方:接上電源後,模型吐字慢得離譜,只有約 14 tokens/秒。同一台機器在 Windows 上卻有 65 tokens/秒。他把驅動、CUDA 都檢查過一輪,找不到設定錯誤
💡 這課會帶他看懂:問題不在他的設定,而在一份只有 Windows 驅動讀得懂的加密電源韌體。他也會學到遇到這種卡關時,工程師怎麼判斷該等廠商修、還是先繞路

🧭 這到底是什麼(白話版)

RTX Spark 是一個筆電平台,微星 MSI Prestige、華碩 ProArt、戴爾 XPS 等機型都在用。它的 GPU 設計和 Nvidia 的 DGX Spark 桌上型小主機相同,還支援最高 128GB 的 統一記憶體CPU 和 GPU 共用同一大塊記憶體,不用把資料在兩邊搬來搬去。但 DGX Spark 出廠就附 Nvidia 自家的 Linux,這些筆電卻全都出廠搭配 Windows on ARM。

素材裡的主角是一個藏在 Windows 裡的元件,叫 Nvidia Platform Controllers and Framework。它負責管理 CPU 和 GPU 之間的電力分配。這套電源管理的 韌體燒在硬體裡、負責控制硬體底層行為的小程式 內含一張電源表,這張表是加密的,只有 Windows 的 驅動程式讓作業系統知道怎麼指揮某個硬體的軟體 能解開。Linux 上沒有對應的元件,所以讀不到。

結果是:在 Linux 插上牆壁電源後,GPU 的 時脈晶片每秒運轉的節拍數,單位 MHz,數字越高通常算得越快 被鎖在約 780 MHz。在 Windows 上同樣情況可以拉到 2 GHz 以上,素材中寫約 2.2 GHz。拿 GPT-OSS-120B 做 推論已經訓練好的模型,實際接收問題並產生答案的過程 測試,Windows 是 65.4 tokens/秒,Linux 只有 13.9。這裡的 token模型處理文字的最小單位,大約是一個字或半個字 每秒能吐幾個,就是衡量速度的指標。

目前實用的折衷方案是 WSLWindows Subsystem for Linux,在 Windows 裡面跑一個 Linux 環境。它借用 Windows 的驅動堆疊,所以不論插電或用電池都能維持完整的 GPU 加速。素材中的 WSL 測試是 65.1 tokens/秒,幾乎和原生 Windows 一樣,同時還能跑 vLLM 這類以 Linux 為主的 AI 工具。

🎯 為什麼值得你花時間

硬體規格不等於實際效能同一顆晶片,在 Linux 上插電時時脈只有 Windows 的三分之一左右(約 780 MHz 對 2.2 GHz)。買硬體時只看規格表,不看作業系統與驅動支援,可能花了錢卻拿不到該有的速度。
開源驅動也有『看不見的黑盒子』這台筆電在 Linux 上可以用 Nvidia 的開源核心驅動做 GPU 加速,4K 120Hz 輸出、音效、鍵盤、觸控板設定好後也都正常。但電源表加密,只有 Windows 驅動解得開,導致『看起來全部能用,唯獨最重要的效能被卡住』。
本機跑大模型的成本評估要重算素材指出 DGX Spark 跑同一個模型約 61 tokens/秒。這台筆電在 Windows 或 WSL 下能追到 65 左右,但原生 Linux 只有 13.9。要在本機部署 AI,平台與作業系統的選擇直接決定可用性。

⚙️ 它是怎麼運作的

1
筆電插上牆壁電源電源狀態改變,系統需要重新決定 CPU 與 GPU 各能分到多少電力,這就是 Platform Controllers and Framework 要處理的事。
▼
2
電源管理韌體查表韌體裡有一張決定各種情境下能跑多快的電源表,但這張表是加密的。
▼
3
只有 Windows 驅動能解密Windows 驅動有解密能力,可以讀出電源表,於是 GPU 時脈能拉到 2 GHz 以上。Linux 驅動沒有這個元件,讀不到內容。
▼
4
Linux 退回保守時脈素材描述 Linux 上插電後 GPU 被鎖在約 780 MHz。時脈低,單位時間算的次數少,大模型每秒吐出的 token 就大幅下降。
▼
5
WSL 繞過問題WSL 借用 Windows 的驅動堆疊,所以 GPU 能維持完整加速,不論插電或用電池都一樣。
GPT-OSS-120B 推論速度比較(素材中的 benchmark)
環境tokens/秒
Windows(RTX Spark 筆電)65.4
WSL(同一台筆電)65.1
Nvidia DGX Spark61
原生 Linux(同一台筆電)13.9

🛠️ 動手做:拖動時脈,看速度怎麼掉

  1. 先把滑桿拖到 2200 MHz,這是 Windows 上的時脈,你會看到線性估算約等於 Windows 實測的 65.4 tokens/秒。
  2. 再把滑桿拖到 780 MHz,這是 Linux 插電時被鎖住的時脈,記下估算值。
  3. 把估算值和素材中 Linux 的實測 13.9 比一比,思考:為什麼只靠『時脈比例』算出來的數字,和實測還有落差?
👇 下面是活的,直接操作

🧠 工程思維透鏡(資深工程師看到的是什麼)

🔭 為什麼廠商要把電源表加密,而不是公開?
素材只說明電源表加密、只有 Windows 驅動讀得懂,並未交代廠商的動機,所以這裡只能分析權衡,不能斷言原因。一般來說,電源與散熱參數牽涉硬體安全邊界,廠商可能想避免使用者或第三方驅動誤設而損壞硬體。代價是開源社群無法自行實作,使用者只能等廠商出手。素材明確提到,真正的解法取決於 Nvidia 把平台控制器的電源管理邏輯移植進 Linux 驅動。
🔭 『時脈剩 35%』為什麼不等於『速度剩 35%』?
780 對 2200 MHz 約 35%,但 13.9 對 65.4 tokens/秒約 21%。素材沒有解釋這個落差,所以我們只能提出合理推測:推論速度不只受時脈影響,也可能同時受電力分配、記憶體頻寬等因素牽動。工程思維是:不要拿單一指標當唯一解釋,標題上的 35% 只是時脈比例,實測的速度損失更嚴重。
🔭 遇到這種問題,該等修復還是先繞路?
權衡在於時間與環境一致性。等 Nvidia 移植邏輯,時程不受你控制;用 WSL,則在 Windows 驅動堆疊上跑 Linux 工具,速度接近原生 Windows(65.1 對 65.4),代價是你得保留 Windows 作為底層。若你的工作流程只需要 Linux 工具而非原生 Linux 核心,WSL 是低風險的務實選擇。

📝 隨堂考(點選答案,立即回饋)

Q1. 根據素材,Linux 上插電後 GPU 變慢的根本原因是什麼?
✅ 素材指出 Linux 能用開源核心驅動做 GPU 加速,但電源表加密、Linux 讀不到,導致時脈被鎖在約 780 MHz。
Q2. 在 GPT-OSS-120B 的 benchmark 中,哪個環境最接近原生 Windows 的速度?
✅ Windows 是 65.4,WSL 是 65.1,原生 Linux 只有 13.9。WSL 借用 Windows 驅動堆疊,所以速度幾乎相同。
Q3. Linux 的實測速度(13.9)約是 Windows(65.4)的幾成?和時脈比例(約 35%)相比如何?
✅ 13.9 除以 65.4 約等於 0.21。比 35% 更低,所以不能只拿時脈比例當作速度損失的完整解釋。
Q4. 素材認為要真正解決這個問題,關鍵在誰?
✅ 素材結論是真正的修復取決於 Nvidia,若移植成功,這台筆電就等於可攜版的 DGX Spark。

🃏 翻牌記憶卡(先想答案,再點開對答)

RTX Spark 筆電在 Linux 插電後,GPU 時脈約多少?Windows 呢?點我翻面
Linux 約 780 MHz;Windows 約 2.2 GHz。
Nvidia Platform Controllers and Framework 負責什麼?點我翻面
管理 CPU 與 GPU 之間的電力分配。它是只存在於 Windows 的隱藏元件,Linux 沒有對應物。
GPT-OSS-120B 四種環境的 tokens/秒點我翻面
Windows 65.4、WSL 65.1、DGX Spark 61、原生 Linux 13.9。
為什麼 WSL 是目前的務實折衷?點我翻面
它借用 Windows 驅動堆疊,不論插電或用電池都維持完整 GPU 加速,同時能跑 vLLM 等 Linux 優先的 AI 工具。
這台筆電的記憶體配置有什麼額外麻煩?點我翻面
預設把 96GB 統一記憶體保留給 GPU,只有 Windows 提供調整這個切分的設定,而 Linux 要看到更多記憶體前必須先調整。

✅ 離開前自測(全勾=這課真的學會了)

0%