【2026 最新】gputaskman 教學：模型占顯存卻沒顯示？五步分清量測、估算與漏報

模型已經開始回答，顯卡記憶體也升高，監控畫面卻叫不出模型名字。這篇 gputaskman 教學，帶你分清三件事：驅動量到多少、工具把它歸給誰，以及模型內部記憶體怎麼估。畫面少了一個標籤，還不足以判定模型沒用 GPU。

本文專為剛開始跑本機模型、願意複製幾行終端機指令的讀者寫。你會建立載入前、回答後、關閉後的紀錄，再用同一份 GGUF 改一次 Context，找出下一步該查驅動、程序還是模型辨認。這是依官方文件與程式碼整理的診斷方法，未填入 AlphaLab 的 NVIDIA 硬體測量結果。

先說結論：GPU 排錯＝計數＋歸因＋推估

把 gputaskman 當成倉庫盤點員：電表知道用了多少電，門牌知道誰在裡面，貨單則幫忙估算放了什麼。三份證據互相補足，卻不是同一張帳。看到程序占用，可以先確認計數；想指認某個模型，還要看 API、檔案映射與啟動參數。

截至 2026 年 11 月 12 日，正式發布版為 v0.4.0。工具仍標示為實驗性軟體。這次的重點是留下可比較的資料，而非從一格數字直接下「記憶體洩漏」的結論。

一、gputaskman 教學先認三層：量到、認出、算出

第一層是「計數」：作業系統、驅動提供裝置或程序的記憶體與活動資料。這是各自計數口徑下的量測，不等於讀出每個張量的內容。第二層是「歸因」：把程序連到執行器與模型檔案。第三層是「推估」：用 GGUF 中的模型結構、Context 等條件計算權重或 KV cache 的成本。

GGUF 是保存模型張量與相關資訊的檔案格式；KV cache 是生成文字時保留的注意力中間資料，像閱讀時留下的索引筆記。Context 是能一起處理的上下文容量，Token 是文字切分單位。想先補顯存的基本帳，可以接著讀 本機 LLM 顯存指南。

模型旁的證據字樣很有用：api 表示執行器的本機 API 回報已載入；mapped 表示模型檔案映射在程序中；cmdline 表示啟動參數點名該檔案；installed 是安裝目錄裡的候選。官方證據圖例把這些身分分開。即使有檔案映射，也還要另查 GPU 放置；看到 installed 更不應直接說它正在運算。

二、gputaskman 教學：五步完成第一次排錯

第 1 步：「我的顯卡在哪？」先核對平台與版本

先確認支援路徑，再開監控。v0.4.0 文件列出 Windows 的 NVIDIA／AMD WDDM 路徑、Linux／WSL 與 Apple Silicon macOS；不同後端可見的欄位不同。Windows 的圖形核心與 WDDM（Windows 顯示驅動模型） 管理 GPU 排程及記憶體，Microsoft 的計數說明也解釋了這層來源。

已有 uv 與 Python 3.11 以上的環境，可依 PyPI 發布資料執行 uv tool install gputaskman==0.4.0，再執行 gputaskman --list-gpus。已經安裝者先用 uv tool list 記下版本，避免把別版結果混入同一輪。沒有 uv 的 Windows 新手可從官方 Releases 選符合 x64／ARM64 的 ZIP，完整解壓並保留 _internal；該版文件標示 ZIP 尚未簽章，請核對官方來源及附帶雜湊檔。

以下用已安裝的 gputaskman 寫指令；Windows ZIP 使用者，把它換成 .\gputaskman.exe。在清單找到目標卡，再執行 gputaskman --gpu 0 --once；0 要換成你這台機器列出的索引。成功條件是卡名與所選裝置相符，或取得可追查的錯誤，並非一定要填滿所有欄位。

Apple Silicon 使用統一記憶體；官方 macOS 後端從 footprint 等來源取得圖形用量，不能直接拿同名 VRAM 欄位與獨立顯卡逐格對照。WSL 的部分程序用量則來自主機計數配對，*／? 是歸因線索。先讀該後端的說明，再解釋數字。

第 2 步：「載入後多了什麼？」保留三個時間點

建立三張同卡快照。先關閉你準備測試的模型工作負載，在獨立資料夾執行 gputaskman --gpu 0 --json > before.json。接著用原本的執行器載入既有模型，送出一個固定問題，等回答結束，再執行 gputaskman --gpu 0 --json > loaded.json。最後正常關閉該測試伺服器或卸載模型，記下等待多久，再執行 gputaskman --gpu 0 --json > closed.json。

用 gputaskman diff before.json loaded.json 看載入變化，再用 gputaskman diff loaded.json closed.json 看關閉變化。diff 的實作把量測計數、日誌分段與估算分開；別再把下面的權重／KV 數字加回上面的程序總量，否則可能重複記帳。

為什麼要先問一題？執行器可能延後配置部分資源。為什麼關閉後要記等待時間？配置器可能保留快取，卸載也不一定等於整個程序結束。三張快照的任務，是辨認變化發生在哪一層；若要懷疑洩漏，還得在相同條件下重複載入與卸載，檢查是否持續累積。

第 3 步：「Context 改大，長的是哪筆帳？」一次換一個旋鈕

固定 GGUF，只調 Context。保留模型完整檔名、量化、執行器版本、GPU offload、KV 資料型別與並行設定。先用能正常運行的小 Context，例如 4096，完成同一個問題並保存 ctx4096.json；停止測試伺服器後，只把 Context 改為設備容得下的另一個值，再保存另一張快照。8192 可作下一個練習值，並非每台機器都應採用。

若已經使用 llama.cpp，llama-server 參數文件將 -c 定義為 Context 大小。請先以自己的 llama-server --help 核對版本，修改既有啟動命令中的 -c 4096，下一輪改為 -c 8192；保留其他旗標，並從啟動日誌確認實際生效值與 GPU 放置。這一步不用為了監控另下載大模型。

KV 像筆記索引，容量與保存方式會影響成本；模型架構、滑動視窗、KV 量化、部分 offload 與多模型共用程序，也會改變拆帳。GGUF 估算程式提供的是有假設的計算。因此兩倍 Context 不保證程序顯存正好翻倍；把估算差額與量測差額各自記下，差距本身就是要追的線索。

第 4 步：「程序有數字，模型卻空白？」追辨認證據

先追程序，再追模型。記下程序名稱、PID、啟動時間與監控版本，對照執行器自己的啟動紀錄：模型檔案是否真的載入、分到哪張 GPU、哪些層 offload。若程序會重啟，PID 改變時也要核對名稱與埠，別把新程序當成原本那一個。

2026 年 11 月 11 日的 Issue #48有個具體例子：回報者用 v0.4.0 與非內建辨認的本機伺服器，模型路徑放在自訂 --native 旗標後，畫面有程序用量卻缺模型資訊。這是單一使用者回報；但 該版參數解析原始碼也可核對，它辨認的是列出的模型旗標，例如 -m、--model，並非所有看似檔案路徑的參數。

所以先檢查自己的旗標與執行器路徑，別替陌生伺服器硬加它不認識的 --model。有相容的 llama.cpp 日誌時，可依監控工具說明，在既有命令加入 --log-file server.log -lv 4，最好使用自己的絕對日誌路徑；重啟並送出固定問題後，查看權重、KV 與計算緩衝區紀錄。日誌提供的是執行器回報的配置，仍應與當下程序計數分開。

遇到本機 API 拒絕存取，也先保留錯誤。本機 API 探測程式有認證與探測範圍；不要為了補一個模型名稱，就把伺服器的驗證關掉或對外開放。看得見用量、認不出模型，是有邊界的結果。

第 5 步：「整張卡不見了？」回到驅動與後端

卡的可見性，先於模型辨認。NVIDIA 使用者可先執行 nvidia-smi，在 Windows 再用 nvidia-smi --query-gpu=index,name,driver_model.current --format=csv 核對驅動模式。這些索引屬 NVIDIA 工具；與 gputaskman 的索引要按卡名及裝置身分重新對照，別假設相同數字必指同一張卡。

Issue #14 回報的是 v0.3.3、Windows 11 Pro 與特定 TCC 卡漏列。到 2026 年 11 月 12 日，對應 PR #37仍為未合併的草稿：它提出用 NVML 補列 TCC 裝置；PR 說明仍待真正 TCC 硬體驗證。這是正在處理的版本問題，不宜寫成「所有 NVIDIA 都失效」，也不應把分支當成正式版已修好。新手先保存環境與對照輸出，繼續使用能看到該卡的工具，不必為了畫面切換驅動模式。

NVIDIA 的 nvidia-smi 文件則明確指出，Windows WDDM 下的逐程序 GPU 記憶體欄位不可用，因記憶體由 Windows 核心驅動管理。這能解釋另一種情況：卡有出現，逐程序卻是 N/A。N/A、JSON 的 null 與程序未列出，都應保留原意；它們不是量到零。

三、怎麼走決策樹？依第一個缺口處理

• 整張卡缺席：先對照驅動工具、作業系統、驅動模式與版本。此時改模型旗標通常不是第一步。
• 卡在，程序缺席：核對所選卡、程序生命週期、權限與 WSL／容器邊界，保存後端給的理由。
• 程序在，模型空白：查模型旗標、檔案映射、本機 API 與相容日誌，先處理歸因。
• 模型在，KV 拆帳不同：核對 Context、offload、KV 類型與架構，再比較日誌及估算。

準備貼 Issue 時，先刪除 JSON、截圖與日誌中的私人路徑、帳號名稱、命令列秘密及不宜公開的模型名稱；官方隱私說明提醒輸出可能包含路徑、旗標與本機埠。留下版本、卡型、驅動、可公開的最小啟動方式與三個時間點，會比只貼「占用很多」更有助於定位。

四、常見問題：八個先講答案的判斷

1. 模型欄空白，代表沒跑 GPU 嗎？

不代表。先看程序與裝置計數，再用執行器日誌確認 GPU 放置；標籤缺失是歸因問題的線索。

2. installed 就是已載入嗎？

不是。它表示找到安裝候選；需另外追 API、映射、啟動與日誌證據。

3. Context 翻倍，顯存一定翻倍嗎？

不一定。權重、KV、計算緩衝區與快取各有配置方式，先固定其他條件再比較。

4. N/A 可以當作零嗎？

不可以。它代表該來源沒有可用值，計算差額時應保留未知，而非自行補零。

5. Windows 的 nvidia-smi 看不到逐程序用量，是模型壞了嗎？

不一定。WDDM 的逐程序記憶體有官方列明的可見性限制，應對照 Windows 計數與執行器。

6. TCC 卡漏列，要立刻切成 WDDM 嗎？

先不要因監控畫面改驅動模式。先核對版本、卡型與 PR 狀態，保留現有可工作的計數路徑。

7. 模型關閉後沒有立刻降回去，就是洩漏嗎？

證據不足。先確認是卸載模型還是結束程序、等了多久，並重複相同流程觀察是否持續累積。

8. 還沒有 GGUF，也能先學嗎？

可以。先用 –list-gpus 與 –once 認清裝置和欄位；等有既有模型工作負載，再做三張快照。

給新手的三個重點

• 先問「這是哪個來源、哪個時間點的數字」，再問模型是誰。
• 保留同卡的 before、loaded、closed；改 Context 時一次只變一項。
• 把未知值與估算留在各自欄位，用第一個缺口決定下一步。