【2026 最新】本機 LLM 熱降頻怎麼查？RTX 3090 新手必學六步排查與功耗復原

本機 LLM 熱降頻怎麼查？你用 RTX 3090 跑模型，剛開始回答很順，過一陣子卻越來越慢。模型明明裝得下，風扇也在轉，究竟是顯卡過熱、功耗限制，還是對話越聊越長？先別急著換模型，讓速度和硬體紀錄在同一條時間軸上對帳。

這篇專為已有 NVIDIA 本機推論環境、第一次做效能排查的讀者寫。你會從只讀監測開始，分清核心與顯存感測、讀懂限速原因，再安排原設定與兩組較低功耗上限的對照，最後還原並驗收。指令以 Linux 的 Bash 終端機為操作路線，使用你已安裝的驅動、推論程式與模型。

查核截至 2026 年 10 月 14 日。本文提供依官方文件整理的測量方法與空白紀錄設計；AlphaLab 此次環境沒有 RTX 3090 可執行推論，所以下文不提供自測溫度、速度或最佳瓦數。

先說結論：本機 LLM 熱降頻，要用三張紀錄對帳

熱降頻證據＝同負載的速度變化＋同步感測＋熱限制訊號。像長跑時變慢：體溫、配速和身體的警報要一起看。只看一張溫度截圖，還不足以把掉速原因定案。

• 先固定模型、輸入與輸出長度，讓冷機和熱機跑同一份工作。
• 分開記核心溫度、可取得的顯存溫度、實際功耗與時脈；缺資料填 N/A。
• 讀限速原因，分清熱限制、功耗限制和閒置；先做原設定基準，再一次只改功耗上限。
• 完成三組後還原原上限，重跑確認設定及行為可復原。

原理：核心、顯存與功耗，是三個不同的儀表

GPU 核心像工作室裡的工人，顯存像放材料的倉庫。核心溫度和倉庫溫度來自不同讀值；顯存容量則是倉庫放了多少材料，和溫度又是另一件事。NVIDIA nvidia-smi 官方文件把 GPU Current Temp 與 Memory Current Temp 分別列出，顯存溫度限於支援的裝置；不要拿核心溫度當顯存溫度。

熱降頻是顯卡因熱條件調整時脈的行為。時脈可以理解成工作節奏；每秒 tokens 是交出的份量，兩者相關但不相同。同樣的模型也可能因上下文、批次、CPU 分工或其他程式搶資源而改變速度。需要先核對容量與載入位置，可接著讀本機 LLM 顯存指南。

功耗上限則像「這間工作室最多能用多少電」。設定的上限與實際消耗分開記：設得較低不代表每一秒都剛好用滿；讀到的 GPU／板卡功率也不等於整台主機插座的功率。熱問題先看同次負載的感測，電費另看本機 LLM 主機成本的完整系統帳。

本機 LLM 熱降頻排查：六步從只讀監測走到復原

①「先點名」：固定顯卡、版本與工作

機器上有幾張卡？先在 NVIDIA 主機的終端機執行下面兩行。-L 列出顯卡及 UUID；UUID 是卡的識別碼，比重開機後可能重新排序的編號適合長期紀錄。下一段指令的 GPU_ID，請填剛才確認的那張卡。

nvidia-smi -L
nvidia-smi --version

# 把這一行換成剛才列出的完整 UUID
GPU_ID="GPU-你的完整UUID"
nvidia-smi -i "$GPU_ID" -q -f baseline-before.txt

把作業系統、驅動版本、RTX 3090 的確切廠牌型號、推論引擎版本或 commit、模型檔與量化、GPU 載入層數、Context 長度、批次和平行請求數記下來。室溫、機殼位置與風扇模式也寫進筆記；測試期間先固定它們。

用同一份本機模型檔，先跑能完成的小任務，確認載入成功與 GPU 分工。如果基準就出錯，先處理載入問題。LLM 推論引擎教學可幫你分清模型和執行它的程式；本機 LLM 跑分成績單則補足品質與端到端驗收。

②「先裝儀表」：連續留下溫度、功耗與時脈

只截開始的一秒，會漏掉後半段。開第二個終端機，重新填入相同 GPU_ID，先保留完整查詢，再每兩秒記錄一次。-f 的檔案會被覆寫，所以各組用不同檔名；Ctrl+C 停止監測。

GPU_ID="GPU-你的完整UUID"
nvidia-smi -i "$GPU_ID" -q -l 2 -f telemetry-A.txt

完整 -q 方便同時保留時間、Temperature、Power Readings、Clocks 與 Performance 的原因欄位。官方文件明示，部分裝置或環境支援的資料不同，未支援讀值會顯示 N/A。看到顯存溫度 N/A，就在紀錄寫「此查詢未取得」；不要換算成 0°C，也不要猜一個數字。

不同工具若顯示 Memory Junction、Hot Spot 或其他感測名稱，請原樣保留名稱、單位、工具版本與來源，不把它們合併成一欄「GPU 溫度」。查不到顯存感測時，仍能記核心、時脈、功耗與可取得的限速原因；結論要保留顯存狀態尚未量到這個缺口。

③「先讀警報」：熱限制與功耗限制分開判

目前文件使用 Clock Event Reasons；部分舊版驅動顯示 Clocks Throttle Reasons。在完整紀錄找這個區塊，對照掉速時間附近的 Active，別只看測完後那一刻的狀態。NVIDIA nvidia-smi 官方文件的定義可以幫你辨認三種重要情況：

• SW Thermal Slowdown／HW Thermal Slowdown：熱條件正在限制時脈，值得把同步速度和溫度讀值一起檢查。
• SW Power Cap：因功耗管理調整時脈；你主動降低上限後出現這個訊號，應先按功耗限制解讀。
• GPU Idle：GPU 處於閒置而調低節奏。若模型正在等工具或 CPU，不能把這段當成滿載熱降頻。

這些原因提供限制類型，並不直接替你定位到某一顆顯存晶片。如果速度下降和熱限制同時出現，便有進一步排查散熱的依據；若只有溫度上升，結論先停在「升溫」。若原因或感測缺欄位，就保留 N/A，接著找其他可重複的證據。

④「固定考卷」：分開量讀題、生成與長時間負載

Prefill（讀入提示）像先讀完考卷；Decode（逐個生成 token）像開始寫答案。NVIDIA 的 LLM 測量解說也把讀入和生成階段分開。你要測的是同一階段由冷到熱的變化，不能拿短提示與越聊越長的聊天互比。

如果你已有 CUDA 版本的 llama.cpp 與相容 GGUF，先看本機 llama-bench --help。以下是以 llama-bench 固定版文件核對的範例；路徑換成現有執行檔和模型，不需要為這次排查另下載大模型。

./build/bin/llama-bench --help

# 讀題：512 個 prompt tokens，生成設為 0
./build/bin/llama-bench -m /完整路徑/model.gguf -p 512 -n 0 -r 3 -o json > pp-A.json

# 生成：prompt 測試設為 0，生成 128 個 tokens
./build/bin/llama-bench -m /完整路徑/model.gguf -p 0 -n 128 -r 3 -o json > tg-A.json

這裡的 512、128 與三次重複是練習設定。官方將這兩類結果標成 pp 與 tg，並說明測量排除 tokenization 與 sampling 時間；所以它們是引擎測試，不是完整聊天等待時間。GPU 分工、KV 設定、batch 與執行檔保持一致，結果檔確認 backend 確實使用 CUDA。

長時間部分另做一輪：用現有推論程式連續送相同輸入、相同輸出上限的請求，逐次記開始／結束時間、實際 token 數和速度。每次使用新的對話或重置上下文，固定快取政策，避免歷史一直累積。若提前停止，保存實際輸出數，不硬填成指定上限。

先訂一個短觀察窗口，例如十分鐘；它只是觀察安排，不是允許高溫硬跑的保證。把開頭與後段等長窗口分開比較，若後段溫度與速度仍持續漂移，就標「尚未穩定」。重複啟動 llama-bench 的載入間隔會讓卡有空檔，這種序列測試也要記空檔，不能稱作無間斷滿載。

⑤「一次只轉一個旋鈕」：原設定與兩組較低上限

先完成 A 組原設定。從 baseline-before.txt 的 Power Readings 記下當時的上限、Min Power Limit 與 Max Power Limit；Default Power Limit 另存。原設定可能早已被其他程式調過，恢復預設不一定等於回到你開始時的狀態。

B、C 組各選一個略低、再低一點的功耗上限，全部落在本卡回報範圍內。可以把原上限的 95% 與 90% 當作候選計算起點，但這不是 RTX 3090 的最佳值或安全門檻；小於 Min 的候選就捨棄。讀不到有效範圍或還原值時，這次只做 A 組監測。

停止推論後再改上限，手動填入你已核對的 B 組瓦數。NVIDIA 文件的 -pl 以瓦特為單位、要求 root 權限，且限支援此操作的裝置。下面只改你指定的卡；收到不支援或權限錯誤，就保存錯誤，停止調整這條路線。

# 先確認 GPU_ID 仍是同一張卡；接著輸入核對過的 B 組瓦數
read -r TEST_WATTS
sudo nvidia-smi -i "$GPU_ID" -pl "$TEST_WATTS"
nvidia-smi -i "$GPU_ID" -q -d POWER

查詢確認上限已生效，再用 telemetry-B.txt、pp-B.json、tg-B.json 保存相同流程。C 組換另一個已核對瓦數，檔名換 C；每組先回到接近的初始溫度與室溫。固定風扇模式，不同時降壓、超頻、鎖時脈或拆卡換導熱材料，讓差異能追到這一個旋鈕。

如果驅動錯誤、畫面異常、工作失敗，或讀值已到本卡可取得的熱限制門檻，就停止負載並保留紀錄；不要靠延長時間追求一個漂亮穩態。此時重點是故障排查，別把錯誤那組列成節能方案。

⑥「走回原路」：還原並確認可以復原

停止 C 組負載，從開始前的紀錄抄回原上限。輸入原瓦數後執行下列指令，再讀回 Power Readings。保持相同 GPU_ID，別把其他卡的值寫進來。

# 輸入 baseline-before.txt 記下的原上限瓦數
read -r ORIGINAL_WATTS
sudo nvidia-smi -i "$GPU_ID" -pl "$ORIGINAL_WATTS"
nvidia-smi -i "$GPU_ID" -q -f baseline-restored.txt

等初始溫度回到接近 A 組，再跑一次相同工作，稱為 A′。先驗上限恢復，再看速度與限制訊號是否回到先前範圍。若差很大，就查室溫、背景工作、快取及實際載入位置；A′ 沒對回來前，先別把 A、B、C 的差異寫成因果結論。

怎麼選設定？用一份完整工作決定取捨

把每組的設定上限、同窗口實際功耗、核心／顯存溫度、pp／tg、長跑開頭與後段速度、限速原因、工作是否完成並排記下來。感測缺項填 N/A，升溫未穩定也如實記下。這些欄位比「我覺得快了一點」更容易回查。

跟著一輪流程看：A 先留下原上限與後段掉速位置；B 只降低上限後，檢查同階段速度與熱限制是否改變；C 再往下試；最後 A′ 還原重跑。這是你要執行的判讀順序，每格結果都留白。較低功耗即使換來較慢生成，仍可能符合你的噪音或能耗目標；若工作時間長很多，就需要另算整件工作的用電。

有牆上功率計時，可量同一次工作的整機能量；只用板卡 telemetry 做估算時，請標成板卡範圍。最終選擇應同時滿足工作完成、速度可接受、限制訊號可解釋與設定可復原。將來接 Agent，還要把工具等待與重試算進整個工作，Agent Harness 實作能幫你找出這些等待落在哪一步。

常見坑：不要把單卡經驗變成通用門檻

選題的社群線索來自一位 RTX 3090 Founders Edition 使用者的長時間推論排查分享。它能提醒你檢查顯存感測，但本文沒有採用其瓦數、溫度界線或掉速比例。單卡、模型、風扇和執行設定的觀察，不能直接替你的卡下診斷。

另一個常見誤判，是把越來越長的對話當成固定負載。先確認輸入長度、輸出數量、並行與快取相同，再追硬體紀錄。GPU utilization 高表示一段時間內 GPU 有工作，並不是熱狀態或工作品質的完整證明；風扇百分比也不是顯存溫度。

FAQ：本機 LLM 熱降頻的八個直接答案

1. 跑久變慢，就一定是熱降頻嗎？

不一定。先固定工作，再看掉速時間有沒有對上熱限制訊號；上下文變長、CPU 分工與背景工作也要查。

2. 核心溫度看起來正常，可以略過顯存嗎？

先分開看。核心和顯存是不同讀值；顯存感測未取得時，就保留這個缺口，不從核心數字推算。

3. 顯存溫度是 N/A，代表卡壞了嗎？

不能由 N/A 判定。官方查詢會以 N/A 表示未支援資料；它表示這項讀值沒有取得。

4. SW Power Cap Active 就是過熱嗎？

不是這個訊號的定義。它表示功耗管理正在限制時脈，與熱限制項目分開判讀。

5. 每張 RTX 3090 都照同一個瓦數嗎？

不要。先讀本卡上限與允許範圍，再做可復原的對照；廠牌、散熱與原設定需要各自記錄。

6. 降低上限，一定更省整台主機的電嗎？

不能只看上限決定。要把同一份工作完成時間與整機用電一起量；板卡瓦數只涵蓋它的測量範圍。

7. llama-bench 的 tg 就是聊天速度嗎？

是生成階段的測量，完整聊天等待還有其他部分。官方測試排除 tokenization 與 sampling，不能直接代替端到端時間。

8. 調整失敗或讀不到範圍，今天能做什麼？

先完成只讀基準。留下版本、同負載速度與同步 telemetry，不再繼續試寫功耗；有完整紀錄再排查支援條件。

給新手的三個重點

• 溫度、速度與限制訊號對同一段時間；單張截圖不替代同步紀錄。
• 每次只改功耗上限，模型與工作固定；N/A 和尚未穩定都保留。
• A′ 還原驗收是測試的一部分；可復原、可完成工作，才有資格比較取捨。