選型的真正軸線：整合度 vs 組裝自由度

桌面環境的選擇，核心不是「輕或重」，是別人幫你整合好多少、你保留多少自己組裝的自由。這條軸線的一端是 GNOME 這種高整合方案：面板、設定、通知、檔案管理全部設計成一致的整體，你開機就有一台能用的機器，代價是想改動它預設的行為要對抗它的設計哲學。另一端是 Hyprland 這種 compositor：它只負責畫面與視窗，面板、啟動器、鎖屏、通知你全部自己挑自己接，代價是要花時間組裝、每個元件都要自己維護。

「輕/重」只是這條軸線的副產品。高整合方案因為要保證所有元件協同，通常帶較多常駐服務、吃較多記憶體；自己組裝的方案可以只裝你要的，所以輕——但如果你把面板、啟動器、通知、鎖屏一個個補齊，最後的資源佔用未必比一個現成 DE 省多少。所以判選型別問「哪個輕」，要問「我想花多少時間在組裝與維護、換到多少客製自由」。

五個主流選項的定位

下表是常見選項在「整合度」這條軸線上的位置與代價。每個選項底下有延伸說明，因為同樣一句「適合客製」在不同方案裡的實際體驗差很多：

GNOME：把選擇替你做完的現代桌面

GNOME 的定位是「一套有明確設計主張的完整桌面」——它預設一個不同於 Windows/macOS 的工作流（頂欄 + Activities 總覽 + 動態工作區），並且刻意收斂可調選項，讓多數人不用設定就有一致體驗。從 Windows/macOS 轉來、想要「裝好就能用、不想折騰」的人，GNOME 是穩妥選擇：它的整合度最高，通知、設定、線上帳號、檔案管理彼此協調。

代價在客製。GNOME 把很多設定收進 extension 或需要另裝 gnome-tweaks（Arch：pacman -S gnome-tweaks）才改得動的角落，想把它調成傳統工作列風格是在對抗它的設計方向，而 extension 又會隨 GNOME 大版本更新而失效。所以 GNOME 適合「接受它的工作流」的人，不適合「想按自己習慣重排一切」的人。資源上它是這幾個裡偏吃的，老硬體上會感覺得到。

KDE Plasma：整合度高、但幾乎每個角落都能調

KDE Plasma 少見地同時做到高整合與高可調：它像 GNOME 一樣開箱即用、元件協調，但幾乎每個行為都攤在設定介面裡讓你改——面板可以拆解重組、視窗規則、快捷鍵、視覺效果都有深度選項。從 Windows 轉來的人會覺得它的預設隱喻（底部工作列 + 開始選單）親切，又保留了往下鑽的空間。

它的代價不在資源（現代 Plasma 已相當精實，中階機器順暢），在「選項多到需要自己收斂」——設定深意味著你可能花很多時間在調整上。想要「高整合又想保留大量客製、但不想從零組裝」的人，Plasma 通常是比 GNOME 和 Hyprland 都平衡的落點。它的 Wayland session 近年已是預設且成熟。

XFCE：老硬體與「要傳統、要穩、要輕」的預設

XFCE 的定位是輕量而傳統：它給你熟悉的桌面隱喻（工作列、選單、系統匣），資源佔用在這幾個裡最低，且以穩定少變著稱——它不追新，多年來介面與行為變動小。老硬體、低階 VM、或「我只要一個不吵不鬧、能穩定工作的桌面」的場景，XFCE 是可靠預設。

它的取捨是現代感與顯示協定：XFCE 目前仍以 X11 為主，Wayland 化在進行但尚未是預設，所以想要 Wayland 的分數效益（見下節）目前要往別的方案找。客製自由度中等——比 GNOME 開放、但沒有 KDE 那種深度設定，也沒有 Hyprland 那種完全重組的自由。

Cinnamon：給「要 Windows 式熟悉感」的轉移者

Cinnamon 出身 Linux Mint，定位是把傳統桌面隱喻做得順手好上手——底部工作列、開始選單式的應用選單、系統匣，對從 Windows 轉來的人幾乎零學習曲線。它比 XFCE 現代一點、視覺完整度高一些，整合度也高（自帶檔案管理員 Nemo、設定中心、特效）。

代價與 XFCE 類似：以 X11 為主，資源比 XFCE 略高。它適合「要一台立刻上手、像 Windows 但是 Linux」的工作機，不適合追求 Wayland 或極致輕量的場景。附帶一提，Cinnamon 的檔案管理員 Nemo 假設 Cinnamon 桌面服務在旁邊，把它單獨裝進裸 window manager 會拖進整套 Cinnamon 元件——這正是加圖形檔案管理員那篇講的桌面環境耦合。

Hyprland：不是 DE，是你自己組一個桌面

Hyprland 嚴格說不是桌面環境，是一個平鋪式（tiling）Wayland compositor——它只負責畫面合成與視窗排列，面板、啟動器、鎖屏、通知、桌布、音量控制全部不含，要你自己挑元件接上去。選它意味著你接受「從零組裝一個桌面」這件事，換來的是最高的客製自由（每個元件都你選、佈局規則完全你定）和最低的裸資源佔用。

它適合「把配置桌面當成一種投入、想要一套完全長成自己樣子的環境」的人，不適合「只想裝好開始工作」的人。組裝過程本身有相當的學習曲線與維護成本——這也是為什麼本系列用一整個 Rice 設計模組談「選了 Hyprland 之後怎麼把它組起來」。如果你還在「要不要走這條路」的階段，這篇就是那個模組的上游：先確認你要的是組裝自由、而不是開箱即用。

Wayland vs X11：選型時避不開的底層判斷

顯示協定是選型時的一條隱形軸線，因為它決定了一部分未來相容性。Wayland 是較新的顯示協定，設計上更安全、對高 DPI 與多螢幕不同刷新率支援更好，是 Linux 桌面的方向；X11 是沿用數十年的舊協定，相容性最廣但架構老舊、社群維護逐漸收斂到維持模式。GNOME、KDE Plasma、Hyprland 都已預設或原生 Wayland；XFCE、Cinnamon 目前仍以 X11 為主。

實務判讀：如果你用 NVIDIA 專有驅動、或依賴某些只支援 X11 的老工具（部分螢幕錄製、遠端桌面、自動化工具），X11 方案目前可能更少驚喜；如果你要高 DPI 筆電、多螢幕混合刷新率、或想跟上長期方向，優先選 Wayland 方案。這不是非此即彼的道德選擇，是看你的硬體與工具鏈落在哪邊。

依情境選：從你的處境倒推

選型的最後一步是把上面的定位對回你自己的處境，不是背「哪個最好」：

• 剛從 Windows/macOS 轉來、只想要能用：KDE Plasma（熟悉隱喻 + 之後可深調）或 GNOME（接受新工作流、要最省心）。要極致熟悉感就 Cinnamon。
• 老硬體 / 低階 VM / 要穩定不折騰的工作機：XFCE。資源最低、變動最少。
• 想把桌面調成完全自己的樣子、願意投入組裝：Hyprland（或其他 WM）。先讀 Rice 設計模組 確認你要的是這條路。
• 要高整合又要大量客製、不想從零組裝：KDE Plasma，是這兩個需求的平衡點。
• 硬體是 NVIDIA 或依賴 X11 工具：優先 X11 成熟的方案（XFCE / Cinnamon），或確認你的 Wayland 方案在該硬體上的狀況再決定。

判準是把「我願意花多少時間在桌面本身、我對客製的需求有多強、我的硬體與工具落在 Wayland 還是 X11」三個問題答清楚，選項自然收斂。沒有一個 DE 對所有人最好——選錯最常見的原因是拿別人的推薦套自己不同的處境。

桌面環境的擴充生態

選好 DE 之後，各方案還有自己的擴充路徑，這是「選項之下還有選項」的一層：

• GNOME：透過 GNOME Extensions 加面板、工作流、狀態列元件，但要注意 extension 綁 GNOME 版本、大版本更新可能失效。
• KDE Plasma：內建的 widget（plasmoid）、全域主題、視窗規則系統，多數擴充不需要離開設定介面。
• XFCE / Cinnamon：panel plugin、applet、主題，擴充幅度中等但穩定。
• Hyprland：因為本來就是自己組，擴充等於換元件——換 bar（waybar/其他）、換啟動器、換通知 daemon，自由度最高也最需要自己維護。這一整套怎麼組，是 Rice 設計模組 的主題。

下一步

• 選了 Hyprland、要開始組裝：Dotfile 管理：桌面 Rice 設計 是「選了之後怎麼把它長成自己的樣子」的完整模組。
• 桌面選好、要裝檔案管理員這類 GUI app 時的相依判讀：在 Hyprland 加圖形檔案管理員。
• 純終端機環境不需要桌面環境、但需要對應的 CLI 工具：CLI 環境工具。
• 桌面裝好後遇到顯示、鎖屏、服務層的問題怎麼診斷：除錯與診斷。

這個系列講的不只是「有哪些桌面工具」，而是選它們時該看什麼：相依足跡、桌面環境耦合、功能相依（掛載 / 縮圖 / 網路這些側欄功能背後各是一個額外套件）。

文章

相關

• 純終端機下的檔案管理器（yazi / broot / ranger）是另一條路，見 CLI 環境工具 的檔案管理器段。
• 桌面環境本身（GNOME / KDE / Hyprland）怎麼選、各自的擴充生態，見 桌面環境選型；選了 Hyprland 之後怎麼組裝，見 Dotfile 管理：桌面 Rice 設計。
• 在圖形桌面上安裝這些工具前的環境與相依判讀，跟 除錯與診斷 的權威狀態紀律同源。

這篇用「圖形檔案管理員」當具體案例，但判讀方式適用於任何你想加進最小環境的桌面 app：先看它的相依樹拖進什麼，再決定值不值得。

三種實作的實測相依

同樣是「有側欄、有選單、能瀏覽掛載裝置」的圖形檔案管理員，三個主流實作在一台已有 GTK3 的 Arch ARM 機器上，各自會新裝的套件數量如下（pacman -S --needed --print 實測）：

差異的來源不是「檔案管理員本身多大」，Thunar 跟 Nemo 的主程式都在 7–10 MB 量級。差的是後面那條相依鏈。

Thunar 與 PCManFM-Qt：桌面無關的獨立程式

Thunar 與 PCManFM-Qt 都是刻意做成「不依賴完整桌面環境」的檔案管理員。Thunar 雖然出身 XFCE，但它拖進的 8 個套件是 XFCE 的基礎函式庫（設定系統 xfconf、工具庫 libxfce4util、UI 庫 libxfce4ui），不是 XFCE 桌面本身——你不會因此裝到 XFCE 的面板、視窗管理器或 session。PCManFM-Qt 走 Qt 棧，帶的 layer-shell-qt 反而是 Wayland 原生整合的加分項。這兩個裝下去，機器還是那台只有 Hyprland 的機器，只是多了一個能開的檔案管理員。

Nemo：為 Cinnamon 而生，假設 Cinnamon 在旁邊

Nemo 是 Cinnamon 桌面的檔案管理員，它的相依反映了這個出身：cinnamon-desktop 提供背景與顯示設定的整合、xapp 是 Cinnamon 系列跨桌面的整合層。即使你只想要「開一個視窗看檔案」，這些桌面元件也會一起裝上，因為 Nemo 在程式碼層面就假設它們存在。這不是 Nemo 寫得差，是它本來就不是設計給「裸 window manager」用的——它預期自己跑在 Cinnamon session 裡。

Nemo 那 36 個套件裡，還有一大塊來自它把 gvfs 列成硬相依（下一節說明 gvfs 是什麼），而 gvfs 又拖進整套磁碟管理棧（udisks2、libblockdev 的 8 個子模組、mdadm、parted、volume_key）。所以 Nemo 的相依樹是「Cinnamon 桌面元件」加「完整磁碟/檔案系統管理」兩層疊起來的結果。

gvfs：側欄那些功能不是檔案管理員自己做的

截圖裡檔案管理員側欄常見的「Devices（掛載裝置）」「Network（瀏覽網路芳鄰）」「Trash（垃圾桶）」，多半不是檔案管理員自己實作的，是 gvfs（GNOME Virtual File System） 這個後端提供的。gvfs 用一層虛擬檔案系統把「掛載 USB 隨身碟」「連 SMB 網路分享」「把檔案丟垃圾桶」這些操作抽象成統一介面，讓檔案管理員不必自己處理每一種裝置與協定。

這帶出一個重要判讀：輕量不是免費的，當功能對等時，相依會靠攏。 Thunar 與 PCManFM-Qt 把 gvfs 列成 optional dependency——不裝也能開檔案管理員，但側欄就沒有掛載、垃圾桶、網路那些功能。要讓輕量檔案管理員有截圖裡那種完整側欄，你得自己補 gvfs，而補上 gvfs 就會連帶拖進它的相依（udisks2、polkit、fuse3、libsecret 等）。Nemo 把 gvfs 設成硬相依，只是把這個選擇替你做了。

所以公平的比較不是「Thunar 8 個 vs Nemo 36 個」，而是「Thunar + gvfs + 縮圖 vs Nemo」。補齊功能後，Thunar 這條路線仍然省下的是 Nemo 獨有的那層——cinnamon-desktop、xapp、xapp-symbolic-icons 這些桌面環境耦合元件。那層，才是「為了一個檔案管理員裝半個 Cinnamon」真正可以省掉的部分。

tumbler：縮圖也是一個額外套件

檔案管理員顯示圖片/影片縮圖，同樣不是內建的，靠的是縮圖服務。Thunar 家族用 tumbler，影片縮圖再另外需要 ffmpegthumbnailer。這是「一個功能對應一個額外套件」的又一個例子——最小環境裡，縮圖、掛載、網路瀏覽每一項都是你明確選擇要不要付相依成本的功能，而不是預設就有。

Wayland / Hyprland 下的注意事項

這些檔案管理員多數是 X11 時代的 GTK/Qt 程式，在 Wayland 下會透過 XWayland 或原生 Wayland 後端執行。PCManFM-Qt 帶的 layer-shell-qt 是 Wayland 的 layer-shell 整合；GTK 的 Thunar/Nemo 在 Wayland 下一般走 GTK 自己的 Wayland 後端。開啟/儲存檔案對話框、拖放、縮圖預覽在裸 Hyprland（沒有完整 portal 服務）下的實際行為，取決於有沒有裝 xdg-desktop-portal 與對應的後端。

[待實機驗證] 以下行為尚未在本系列的 Hyprland 實機環境確認，先標記待驗證：(1) Thunar 補上 gvfs 後，側欄的 Devices/Network/Trash 是否如預期出現並可用；(2) tumbler + ffmpegthumbnailer 的縮圖在 Wayland 下是否正常產生；(3) 三者在裸 Hyprland（無完整桌面 portal）下的檔案對話框與拖放行為；(4) Nemo 在沒有 Cinnamon session 的情況下，桌面圖示、設定整合等功能是否失效或報錯。這些是「相依裝了之後實際好不好用」的問題，相依數量本身（上表）已是實測確定值。

風險與注意事項

移除後的孤兒套件：裝了 Nemo 再反悔移除時，cinnamon-desktop、xapp 那一票被拖進來的相依會變成沒人依賴的孤兒（pacman -Qtd 可列出）。用 pacman -Rns nemo 移除時帶走遞迴相依，或定期清孤兒，否則那半個 Cinnamon 會留在系統裡。輕量檔案管理員因為拖進的東西少，這個問題也小。

桌面環境服務未跑的副作用：把為某個桌面環境寫的 app 裝進裸 window manager，它預期的那些服務不在時，部分功能可能靜默失效或在啟動時報錯。這類問題不會在相依解析階段出現——套件裝得起來，是執行時才發現某個整合功能沒作用。（Nemo 在無 Cinnamon 下的具體表現，見上方待驗證項。）

選型判準：最小化的 Hyprland 想要一個圖形檔案管理員，優先考慮桌面無關的 Thunar 或 PCManFM-Qt；需要截圖那種完整側欄功能時，明確補上 gvfs（掛載/垃圾桶/網路）與 tumbler（縮圖），把相依成本花在你真的要用的功能上。以 Thunar 為例，完整一套是 pacman -S thunar gvfs tumbler ffmpegthumbnailer（gvfs 給掛載/垃圾桶/網路、tumbler + ffmpegthumbnailer 給圖片與影片縮圖）。除非你本來就跑 Cinnamon，否則不建議為了單一檔案管理員把 Nemo 的整套桌面元件裝進來——那是付了桌面環境耦合的代價，卻沒用到那個桌面環境。

待實機驗證清單

這篇的相依數量與相依樹是實測確定的；以下「裝了之後實際體驗」的部分待在 Hyprland 實機補驗證：

• Thunar + gvfs + tumbler + ffmpegthumbnailer 的完整側欄與縮圖行為
• 三種檔案管理員在裸 Hyprland（XWayland vs 原生 Wayland、portal 有無）下的差異
• Nemo 脫離 Cinnamon session 的功能缺損範圍
• 加進 packages-arch.txt 後，bootstrap 一鍵安裝這條路線的實際落地結果

為什麼拿 Nemo 當「重」的代表

上表用 Nemo 當桌面環境耦合的代表，是因為它把耦合展示得最乾淨——cinnamon-desktop + xapp 那層桌面元件加上 gvfs 硬相依，剛好對照出 Thunar / PCManFM-Qt 省掉的是什麼。但它不是最重的：GNOME 的 Nautilus（nautilus）與 KDE 的 Dolphin（dolphin）是更 canonical 的「裝檔案管理員就拖進半個桌面」例子。Nautilus 深度綁 GNOME 的 GTK4 / libadwaita / tracker 索引棧，在非 GNOME 環境裝它會拉進一串 GNOME 平台庫；Dolphin 綁 KDE 的 Frameworks（KIO、Baloo 等），在非 KDE 環境同理。判讀方式跟 Nemo 一節相同：檔案管理員的相依樹反映它預期跑在哪個桌面裡。真要在裸 Hyprland 上驗，pacman -S --needed --print nautilus / dolphin 會列出各自那串平台庫——數量通常比 Nemo 更可觀（實測 Nautilus 72、Dolphin 91，約 Nemo 的 2 到 2.5 倍）。

零相依對照：純終端機檔案管理員

如果你在意的正是相依足跡，還有一條完全繞開圖形棧的路：終端機檔案管理員（yazi / lf / nnn / ranger）在終端機裡跑，不需要 GTK / Qt / gvfs / 桌面環境那一整套。yazi（Rust、內建預覽與非同步 I/O）與 lf、nnn（C、極小）在裸 Hyprland 或純 SSH 環境下都是近乎零額外相依的選擇——你已經有終端機，它們就能跑。代價是純鍵盤操作、沒有圖形檔案管理員那種拖放與縮圖牆。這是「圖形 vs 終端機」的取捨，不是同一條路上的輕重之分：要滑鼠拖放、縮圖預覽走圖形檔案管理員；要零相依、鍵盤流、SSH 下也能用走 TUI。TUI 檔案管理員的比較見 CLI 環境工具的檔案管理器 TUI。

下一步

• 這篇談的是「加桌面 app 時怎麼判讀相依成本」，套件清單本身怎麼設計、怎麼被 bootstrap 一鍵安裝，見 模組八：Bootstrap script 與套件清單。
• Hyprland 本體與配套工具的安裝，見 模組五：安裝與環境建置。
• 這台 Hyprland 是在 VM 上建起來測的，VM 能測什麼、什麼要留到實機，見 VM 環境設定與測試矩陣。

讀完本章後、你應該能在 Windows 上：選對 LM Studio 的 GPU backend、在 GUI 內設定卸載層數與 KV cache 量化、啟動 OpenAI 相容 server、接到 VS Code Continue.dev。

本章目標

1. 在 Windows 上安裝 LM Studio、選對 GPU backend。
2. 知道 GUI 設定面板的哪幾個欄位對應 llama.cpp 的核心旗標。
3. 啟動 LM Studio 的本地 server、提供 OpenAI 相容 API。
4. 判斷你的工作流適不適合用 LM Studio 當主力。
5. 處理常見的 Windows + GPU 整合議題（driver 版本、CUDA toolkit）。

安裝

LM Studio 是 Electron 桌面 app、個人使用免費、Windows / Linux / macOS 三平台都支援。從 lmstudio.ai 官網 下載對應系統的安裝檔即可。

Windows 版的安裝步驟：

1. 下載 .exe 安裝程式、執行安裝（不需 admin 權限的情況下會裝在使用者目錄）。
2. 首次啟動時、LM Studio 會偵測 GPU 並提示選擇 backend。

事實查核註：LM Studio 是商業軟體、UI 跟功能會隨版本變化。本章描述以 2026 年 5 月的穩定版為基準、實際 UI 元素位置以當前版本為準。

GPU backend 選擇

LM Studio 在 Windows 上的 GPU compute backend 選項依 GPU 廠商不同：

backend 的切換位置：LM Studio 的設定面板（齒輪圖示）→ Hardware / Runtime 區段、會列出當前可用的 backend 與下載連結。部分 backend 在首次使用時需要下載對應的 runtime（如 CUDA runtime）。

選錯 backend 的常見徵兆：

1. 模型載入時間異常長：可能 fallback 到 CPU、確認 GPU backend 是否正確啟用。
2. 生字速度遠低於同硬體的社群回報：backend 不對、或 driver 版本不對、或 VRAM 不足而啟用了 CPU offload。
3. 載入時錯誤訊息提到 CUDA 版本不符：driver 跟 LM Studio 內建的 CUDA runtime 不對齊、需更新 driver 或選擇對應的 LM Studio build。

事實查核註：各 backend 的可用性跟下載方式依 LM Studio 版本變動、以當前版本的 Hardware / Runtime 設定面板顯示為準。

GUI 設定對應到 llama.cpp 旗標

LM Studio 在背後使用 llama.cpp、GUI 內的設定欄位通常對應到 llama.cpp 的某個旗標。對熟悉 5.3 llama.cpp 在 PC 上 旗標的讀者、這個對應表能加速 GUI 內的設定：

具體欄位名稱跟位置依 LM Studio 版本變化、以實際 UI 為準。新加入 llama.cpp 的旗標通常會在後續 LM Studio 版本被加進 GUI。

啟動 LM Studio Server

LM Studio 內建 OpenAI 相容 server、預設 port 1234。啟用步驟：

1. 載入想用的模型（GUI 左側 Chat / Local Server 切換）。
2. 切到「Local Server」分頁。
3. 設定上面對應的旗標（GPU Offload、Context、KV Quant、MoE Offload 等）。
4. 點「Start Server」、看 log 確認模型載入成功、port 顯示為 1234（或自訂）。

啟動成功後、可以用任何 OpenAI 相容 client 連接：

1curl http://localhost:1234/v1/chat/completions \
2  -H "Content-Type: application/json" \
3  -d '{
4    "model": "loaded-model-name",
5    "messages": [{"role": "user", "content": "Hi"}]
6  }'

接到 VS Code Continue.dev：

 1{
 2  "models": [
 3    {
 4      "title": "LM Studio",
 5      "provider": "openai",
 6      "model": "loaded-model-name",
 7      "apiBase": "http://localhost:1234/v1",
 8      "apiKey": "not-needed"
 9    }
10  ]
11}

model 欄位填 LM Studio 載入的模型名稱、要跟 GUI 顯示一致。

模型瀏覽器與下載

LM Studio 的內建模型瀏覽器直接連到 Hugging Face、可以搜尋 GGUF 格式的模型並一鍵下載。對「想試新模型但不想自己抓 GGUF」的使用者較友善。

下載時的選擇：

1. 量化等級：LM Studio 會列出可用的量化版本（Q4_K_M、Q5_K_M、Q8_0 等）、可依 VRAM 預算選擇。
2. 模型大小估計：LM Studio 通常會顯示「在你當前硬體上能不能跑」的提示；提示為估計、實際載入仍以 llama.cpp 啟動結果為準。
3. 下載位置：LM Studio 預設下載到使用者目錄；可在設定面板改路徑（適合把模型放到大容量 SSD）。

事實查核註：LM Studio 對「能否在當前硬體跑」的判讀是基於 VRAM + RAM 容量的估算、不考慮 MoE 卸載、KV cache 量化等進階設定；提示僅供參考、實際以實測為準。

跟 Ollama / llama.cpp 並存

LM Studio、Ollama、llama-server 可以同時跑、用不同 port：

實務上同時跑多個的場景是調參階段比較不同 backend 或設定；常態使用通常一個就夠。

切換主力的判讀：

Windows + GPU 整合常見議題

Windows 上跑本地 LLM 的常見議題：

1. NVIDIA driver 版本：driver 太舊可能不支援 LM Studio 內建的 CUDA runtime；過新 driver 偶爾出現相容性問題。建議用 NVIDIA Studio Driver（相對 Game Ready Driver 更穩）、或 NVIDIA 官方建議的當前長期支援版本。
2. WSL2 vs 原生 Windows：LM Studio 在原生 Windows 跟 WSL2 都能跑；WSL2 可以更接近 Linux 環境（適合熟悉 Linux 工具的使用者）、但 GPU 透傳的配置略多。
3. windows defender / 防毒軟體掃描：模型檔案常為 10+ GB、安全軟體的即時掃描可能拖慢載入速度；建議把模型目錄加入排除清單。
4. 電源計劃：Windows 的「省電」電源計劃可能讓 CPU 在閒置時降頻、影響 prefill 速度；建議使用「高效能」或自訂「卓越效能」計劃。
5. VRAM 被其他應用佔用：Chrome、Discord、遊戲都可能佔用 VRAM；觀察「工作管理員 → 效能 → GPU」確認 VRAM 餘量。

事實查核註：上面的議題以 Windows 10 / 11 為背景、具體現象跟解法依 Windows 版本、driver 版本變化。引用前以自己版本的官方文件為準。

給多數讀者的建議

LM Studio 在 Windows + 獨立 GPU 場景的核心價值是「降低 MoE 卸載與 KV cache 量化的學習成本」。對下面類型的使用者特別合適：

1. 剛接觸本地 LLM、不熟悉 CLI 旗標。
2. 主力工作是探索新模型、不是調穩定 production-like 設定。
3. 想視覺化看「卸載層數 vs VRAM 用量」的關係、再決定要不要轉到 CLI。

對下面類型的使用者、Ollama 或直接 llama-server 通常更適合：

1. 熟悉 CLI、想最完整地控制旗標。
2. 主力是穩定日常寫 code、模型不常換。
3. 想用 llama-bench 做精確校準。
4. 部署到團隊或多人共用的 server 環境（GUI app 不適合 headless 部署）。

下一章

下一章：5.5 PC 場景的模型選型優先順序、用前面四章建好的工程選項回答「具體裝哪個模型」。

拆包生態：裝了本體不等於裝了功能

發行版為了控制依賴體積，會把一個應用的核心跟功能模組拆成多個套件，預設只裝核心。這個設計讓「安裝成功」跟「功能可用」變成兩件事，而缺件的症狀往往是靜默的：

• VLC 的解碼器是獨立 plugin：Arch 的 vlc 本體開得起來、UI 完整，播 H.264 影片卻回報 Codec 'h264' is not supported——解碼能力在 vlc-plugin-ffmpeg（或整組 vlc-plugins-all）。judgment 訊號是「應用正常啟動、特定格式失敗」，權威來源是應用自己的 log（vlc --verbose=2）。
• pipewire 的 session manager 是獨立套件：pipewire 常被依賴鏈拉進來，但沒有 wireplumber 就沒有人建立音訊 graph——daemon 在跑、wpctl status 的 Sinks 段是空的、所有應用無聲且不報錯。補 wireplumber + pipewire-pulse（多數 GUI 應用走 PulseAudio API）後輸出裝置立即出現。
• optional dependency 不會自動安裝：套件宣告的 optdepends 是「裝了會多什麼功能」的提示、不是安裝動作。影片縮圖、壓縮格式支援、硬體加速常落在這層，pacman -Qi <pkg> 的 Optional Deps 段列出哪些沒裝。

判讀原則：GUI 應用「開得起來但某個功能不動」時，先查發行版有沒有把那個功能拆成獨立套件，再懷疑設定或相容性。

首跑同意對話框：程式在等使用者決策

不少 GUI 應用第一次啟動會彈出需要使用者決策的對話框，最典型的是 VLC 的「Privacy and Network Access Policy」：

VLC 聲明自己不蒐集、不傳輸任何個人資料，但它能自動向第三方網路服務抓取播放清單裡媒體的中繼資料（封面圖、曲名、演出者）——這個行為等於把「你在播哪些檔案」暴露給第三方服務，所以 VLC 開發者要求使用者明示同意（Allow metadata network access 勾選框、預設勾選）後才允許自動連網。

這個對話框的判讀是用途導向：拿 VLC 播本機影片、看下載的影片檔，中繼資料抓取沒有用處、取消勾選讓播放器完全離線工作；拿它管理音樂庫、想要自動補封面跟曲目資訊，才需要同意。同意與否都能在偏好設定（Privacy / Network Interaction）事後改。

首跑對話框對自動化流程有一層額外影響：無人值守安裝驗證時，應用會停在對話框等輸入、腳本側只看到「程式起了但沒繼續」。VLC 把這兩個決策記在 ~/.config/vlc/vlcrc 的 qt-privacy-ask 與 metadata-network-access 兩個鍵——首跑後檔案才生成，而且 VLC 退出時會整檔重寫（幾千行的完整設定 dump），把它納入 dotfile 版控會持續產生無意義的 diff，比較合理的處理是讓首跑對話框留給人、或在自動化腳本裡預先寫入只含這兩鍵的最小 vlcrc。

同型的首跑決策也出現在瀏覽器（預設瀏覽器詢問、錯誤回報同意）跟大型 GUI 應用（遙測同意）。它們的共通判讀：對話框問的是「要不要讓程式自動連外 / 回傳資料」，答案取決於這台機器的用途與隱私要求，安裝驗證流程要把「首跑會有互動」納入預期、不是當成故障。

播放驗證鏈：三個權威位置

「有沒有真的在播」的驗證不靠肉眼跟喇叭，三個權威位置各管一段：

把「管線通不通」跟「應用會不會播」拆開驗證能大幅縮短歸因：先用本機音檔 pw-play <file> 打通音訊路徑（stream 出現 [active] 代表 guest 側無誤），再測應用層；應用層失敗就跟管線無關，往解碼器、DRM、應用 log 查。串流再多拆一層：先用無 DRM 的串流（一般影音網站）確立網路串流基線，DRM 內容（Spotify、Netflix 類）的失敗才能歸因到 DRM 層——DRM 在非 x86_64 架構的可用性判讀見 平台與發行版差異的判讀地圖 的套件存在性段。

VM 特有：硬體解碼回退

在 VM 裡播放影片，第一次開檔常會閃一個錯誤對話框（failed to create video output）然後正常播放——這是硬體解碼回退的痕跡：播放器預設先嘗試硬體加速解碼（VDPAU / VAAPI），虛擬 GPU（如 virtio-gpu）沒有視訊解碼能力，嘗試失敗後回退軟體解碼重建輸出。log 上的特徵是一次性的 decoder error 加上之後穩定的 avcodec decoder 軟體解碼行；實體機器有 GPU 解碼時不會出現。VM 裡想要乾淨啟動，在播放器偏好設定停用 hardware-accelerated decoding 即可——這是機器特性設定，適合留在該機器本機、不進共用 dotfile。

下一步路由

• 套件在這個平台 / 架構存不存在、名字叫什麼：平台與發行版差異的判讀地圖
• 音訊、行程、服務狀態的權威判讀：Linux 除錯與診斷
• GUI 應用清單怎麼進 bootstrap：模組八：Bootstrap script 設計