顯示卡剪片／渲染／AI 運算成日崩？創作負載同打機唔同嘅排查邏輯
重點摘要
打機同渲染用嘅係同一塊卡，但負載形狀完全唔同，崩潰機制同排查邏輯自然唔一樣；先讀字、再分類、最後先懷疑硬件。
點解打機冇事，渲染先崩：負載形狀係關鍵
一開波先講一個反直覺嘅事實：遊戲同創作渲染，用嘅係同一粒 GPU、同一套 CUDA 架構、同一個 NVENC 編碼器。市面上冇所謂「渲染專用硬件」呢回事——差異唔喺硬件，喺負載形狀（workload shape）。
遊戲嘅負載形狀係咁：逐幀運算，每幀幾十毫秒就要交功課。GPU 係可搶佔（preemptible）嘅，行行下要定時讓返控制權畀作業系統；負載高高低低起伏好大，而 VRAM 用量通常穩定喺一個範圍，唔會突然爆煲。
創作渲染就係另一個世界：長時間、非搶佔式（non-preemptive）嘅 compute kernel，一個 kernel 可以霸住成粒 GPU 幾秒甚至更耐，期間作業系統叫唔醒佢。VRAM 嘅用法更加係「成個場景一次過載入」——夠就夠，唔夠就斷崖式失敗，唔會優雅降速畀你。
呢個形狀差異，就係後面六個崩潰機制嘅共同根源。搞清楚呢點，後面所有排查邏輯先至講得通。
Studio vs Game Ready：驅動分支嘅真相
最多人誤解嘅，就係 NVIDIA 兩個驅動分支。先講結論：Studio driver 同 Game Ready driver 係同一底層代碼，支援同一批 GPU，同一套硬件功能——CUDA、NVENC／NVDEC、OptiX、DirectX、Vulkan、光追，兩邊一模一樣。唔存在「裝咗 Studio driver 就解鎖創作性能」呢回事，呢個係流傳已久嘅誤解。
真正嘅差別有三點。第一係驗證對象：Studio driver 針對創作軟件（Adobe、Autodesk、Blender 等）做多應用測試；Game Ready 針對新遊戲首日（day-one）優化同 profile。第二係發佈節奏：Game Ready 出得密，有時一個月幾次，跟遊戲發佈走；Studio 出得疏，跟創作軟件大版本週期走。第三係官方定位：Game Ready 畀「遊戲首日支援優先」嘅玩家，Studio 畀「創作流程可靠性優先」嘅創作者——但兩邊都跑到對方嘅軟件，唔係互斥。
排查上嘅意義好實際：驅動分支互換係一個低成本嘅隔離測試。渲染成日崩，試吓由 Game Ready 轉去 Studio（或者反方向），clean install，唔好直接覆蓋，然後睇問題跟唔跟住個分支走。
但有一句一定要寫明：唔好將「Studio＝永遠更穩定」當成定律。同一個 Studio 版本都可以帶 regression，穩定與否要逐個 build 睇，唔可以靠個名嚟判斷。
VRAM 斷崖：成個場景一次過載入
渲染崩潰最常見嘅兇手，就係 VRAM 耗盡。Blender Cycles 最終渲染要將成個場景載入 VRAM，而 viewport 預覽唔需要——所以會出現一個經典現象：viewport 睇落好順，一撳 F12 就爆。唔係張卡突然壞咗，係最終渲染嗰下先至要成個場景一次過塞入顯存。
認住幾個典型報錯字串，佢哋本身已經幫你分類：
- `CUDA error: out of memory`——最直接，唔使估。
- `CUDA Error: Invalid value in cuMemcpy2DUnaligned`——常同 VRAM 唔夠有關；曾有案例指喺 CUDA 同 OptiX 後端之間互換，可以迫 Blender 重建 GPU 數據而繞過。
- DaVinci Resolve 嘅「Your GPU memory is full」／「GPU Memory Full」——常出現喺 4K／8K timeline 加重度 spatial noise reduction、optical flow、或者複雜 Fusion node 嗰陣。
想親眼睇住 VRAM 頂唔頂到上限，有幾個工具：Windows 工作管理員 → 效能 → GPU → 專用 GPU 記憶體；GPU-Z；同埋渲染軟件本身嘅 log。
緩解方向全部喺應用層，唔使郁硬件：開 Simplify 限制紋理尺寸、降低 subdivision、關閉 Persistent Data、調高 adaptive displacement 嘅 Dicing Scale、清理唔用嘅 view layer 同 collection。DaVinci Resolve 仲有一個官方認可嘅手段：Deliver page → Advanced Settings → Render Speed，由 Maximum 調低（例如一半），意思係「畀慢啲，唔好塞爆 VRAM」。
順帶一提 AI：PyTorch 嘅 `CUDA out of memory` 係同一個斷崖邏輯——模型同 batch 一次過載入顯存，頂唔順就爆。但 AI 工具鏈同 3D 渲染差好遠，今篇聚焦渲染同剪片，AI 只輕輕帶過，唔展開。
NVENC 卡死：進度條停咗，但冇錯誤碼
Premiere Pro 官方疑難排解文件描述過一個好典型嘅症狀：渲染／輸出嗰陣 hang、freeze、無回應——重點係，佢唔會畀你一個華麗嘅錯誤碼，淨係個進度條停咗喺度。官方建議嘅隔離步驟，本身就係診斷線索：
- 關閉「啟用硬件加速編碼和解碼」，再 export（H.264／HEVC）；
- 將 Mercury Playback Engine 轉做 Software Only；
- 轉用內建 preset、經 Media Encoder queue、移除第三方 plugin。
背後機制係咁：NVENC 係一粒獨立嘅固定功能編碼器。當佢同驅動／解碼路徑嘅狀態唔一致嗰陣，成條 encode pipeline 可以靜默卡死，軟件層面只見到進度條停咗。所以個二分法好有用：轉做軟件編碼之後成功，就等於鎖定咗問題喺 GPU 硬件加速路徑——呢個係 NVENC 排查上最有用嘅一步。
但都要提防誤判：唔係每次 export 失敗都係 GPU 嘅事。檔名同路徑陷阱都試過搞事——非 ASCII 路徑曾經導致 H.264／HEVC export 失敗；如果 log 講嘅係「file importer inconsistency」，就唔好走去重裝驅動，方向錯咗。
TDR：Windows 殺驅動機制
如果話創作崩潰有個「頭號系統級兇手」，就係 Windows 嘅 Timeout Detection and Recovery（TDR）。機制好簡單：Windows 監察住 GPU 嘅回應，如果 GPU 喺預設 2 秒之內冇回應作業系統，Windows 就會重置顯示驅動。用戶見到嘅，就係「顯示驅動程式停止回應並已恢復」嘅通知，跟住渲染失敗或者輸出損毀。
點解渲染特別易中？因為長 compute kernel 霸住 GPU 唔讓控制權，複雜光追幀好容易超過 2 秒；遊戲因為每幀都要交功課、定時讓權，好少觸發。仲有一個反直覺嘅推論：慢卡跑同一個場景更易超時——所以「換張慢卡反而多咗崩」唔係卡壞，係超時。
調校位喺 registry：`HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers` 底下嘅 `TdrDelay` 同 `TdrDdiDelay`（DWORD，單位係秒）。Intel 官方指引建議調高至 20 秒或以上；Adobe Substance 3D Painter 官方文件建議 60 秒，仲註明低過 10 秒會彈警告。
但係有幾個重要但書，一定要寫明。第一，改之前備份 registry，風險自負。第二，Microsoft 指明呢啲 key 係畀驅動開發、測試、除錯用，終端用戶唔應該亂改。第三，Adobe 亦註明 Windows 更新或者驅動更新有可能將個 key 重置返預設值——所以崩潰「無端端返嚟」嗰陣，記得問返呢個位。
認住 TDR 嘅指紋：渲染中途畫面閃黑／短暫黑屏 → 驅動恢復通知 → 軟件崩或者爛輸出。呢個指紋同 VRAM 爆（即時報錯）、PSU 跳（成部機熄）好唔同，識分呢三樣，排查已經贏咗一半。
仲有一個免費嘅隔離線索：Linux 係冇 TDR 嘅。同一張卡、同一個 workload，喺 Linux render farm 唔會有呢個問題——dual-boot 或者 live 環境對比，崩唔崩已經話到畀你聽係咪 TDR 作怪。另外 Windows 事件檢視器入面 `nvlddmkm` 相關錯誤，就係驅動重置嘅指紋。
瞬態尖峰跳 PSU：火數夠都照熄
去到呢個機制，症狀已經唔同晒：唔係軟件報錯，唔係驅動重置，而係成部機突然熄機或者重啟。現代高階顯示卡（RTX 30 系最典型，社群普遍認為 3090／3080 Ti 比 40 系更惡）會喺微秒級嘅時間尺度，出現遠超標稱 TDP 嘅電流尖峰。PSU 嘅過流保護（OCP）或者過功率保護（OPP）一被觸發，成部機即刻斷電。同 TDR（淨係重置驅動，部機仲著住）係兩個世界嘅症狀，唔好撈亂。
最多人問嘅問題係：「火數明明夠，點解都照熄？」答案係：睇名牌瓦數冇用。關鍵係隻 PSU 對瞬態嘅反應速度同保護閾值設定；舊、平價、或者老化咗嘅 PSU 最易中招。
仲有一個成日被忽略嘅變量：multi-rail 同 single-rail。Multi-rail 將 12V 拆成多組，每組各自有 OCP——保護性好，但單組閾值低，線插錯組或者分配唔勻，就會無端端觸發 OCP。Single-rail 得一個大 OCP，高階卡接線簡單直接。有啲高階 PSU 仲有 single／multi 切換掣，呢個都係排查變量之一。
ATX 3.x 規範正正係為咗應付 GPU 瞬態 excursion 而嚟，買新 PSU 可以睇呢個認證——但唔好當成根治保證，唔同卡加唔同 PSU 嘅組合實測數據唔齊，冇人敢包。
最後係排查意義：渲染係長時間滿載，撞到保護閾值嘅機會比打機（負載起伏大）高得多。同一個「打機冇事、渲染熄機」嘅情況，PSU 嘅嫌疑順位要大幅提前。
記憶體溫度牆：核心涼、結溫熱
GDDR6X（RTX 3080／3090 等）有個特性：記憶體結溫（memory junction temperature）遠高過核心溫度，係正常現象。社群量測常見嘅情況係核心得六十幾度嗰陣，記憶體結溫已經去到九十幾至一百一十度左右。持續嘅 compute 負載（渲染、AI 運算）將記憶體頻寬食到盡，同打機嗰陣時高時低完全唔同，所以創作機特別易撞記憶體溫度牆。症狀係降速、卡頓、偶發崩潰——而核心溫度睇落「好靚」。淨係睇核心溫度，會完全 miss 呢個兇手。
監察要用啱工具：HWiNFO64 入面「GPU Memory Junction Temperature」呢個讀數。注意，MSI Afterburner 等傳統工具係唔顯示呢個讀數嘅，用錯工具等於冇睇。硬件成因方面，老化嘅導熱墊（thermal pad）乾裂係常見兇手之一。
但書要寫明：確切嘅節流／保護觸發溫度，喺社群講法混亂，第一手規格文件又冇公開版本，所以呢篇唔會畀你一個紅線數字。重點只有一句：核心同結溫係兩個溫度，一定要獨立監察。
迷思破解：四句成日聽錯嘅說話
| 迷思 | 真相 |
|---|---|
| 渲染用嘅硬件同打機唔同 | 錯。同一粒 die、同一組 CUDA core、同一個 NVENC。唔同嘅係 workload 形狀，唔係硬件 |
| Studio driver 永遠更穩定 | 錯。兩分支同一底層代碼，差在驗證對象同發佈節奏；個別 Studio build 都可以有 regression，出事要做分支互換測試，逐個 build 驗證 |
| 火數愈大愈穩 | 錯。瞬態反應、保護閾值、rail 設計、電容老化先係關鍵，唔係名牌瓦數 |
| render 崩就等於張卡死咗 | 錯。大多數渲染崩潰係 VRAM 唔夠、TDR、驅動、PSU 四樣嘢，真正核心／顯存物理損壞係少數，行晒隔離流程先好判死刑 |
症狀速查：由現象對返兇手
| 症狀 | 可能原因 | 驗證方法 |
|---|---|---|
| 渲染即時彈錯，字串含 out of memory／GPU Memory Full | VRAM 斷崖：成個場景一次過載入，頂到上限 | 工作管理員睇「專用 GPU 記憶體」；降分辨率或淨 render 單幀 test frame |
| 渲染中途閃黑，彈「顯示驅動程式停止回應並已恢復」 | TDR 超時：長 compute kernel 超過 2 秒限期 | 事件檢視器查 nvlddmkm；dual-boot Linux 跑同一 render 對比 |
| 成部機突然熄機／重啟，淨係渲染先發生 | PSU 瞬態尖峰觸發 OCP／OPP 保護 | 換已知良好 PSU 交叉試；查 PSU 年齡、rail 設計、有冇 single／multi 切換掣 |
| Premiere export 進度條停咗、無回應、冇錯誤碼 | NVENC 編碼管線靜默卡死 | 關硬件加速編碼再 export；Mercury Playback Engine 轉 Software Only——軟件編碼成功即鎖定 GPU 加速路徑 |
| 核心溫度靚，但降速、卡頓、偶發崩潰 | 記憶體結溫牆 | HWiNFO64 睇「GPU Memory Junction Temperature」，唔好淨係睇核心 |
| viewport 好順，一撳 F12 就爆 | Blender 最終渲染先將成個場景載入 VRAM | 降 subdivision、關 Persistent Data、Simplify 限紋理尺寸後再試 |
六步隔離排查流程
心法先行：先讀字（報錯字串／log）→ 再分類型（OOM／TDR／PSU 跳／encoder hang／過熱）→ 再做二分隔離（軟件編碼？低分辨率？另一分支驅動？）→ 最後先懷疑硬件死。跟住呢個次序，每步都係二分法：
第一步：縮小重現。 降分辨率，或者淨係 render 單幀做 test frame。一幀都過唔到，指向場景／設定問題；頭幾幀過到、中途先崩，就向 VRAM 漸增、溫度、TDR 三個方向查。
第二步：先睇應用 log，唔好一嚟就重裝驅動。 Blender 崩潰會喺 Windows temp 目錄產生 `<檔名>.crash.txt`；安裝目錄有 `blender_debug_log.cmd`、`blender_debug_gpu.cmd`、`blender_debug_gpu_workaround.cmd` 可以拎 GPU 相關 log。DaVinci Resolve 就去 Help → Create Diagnostics Log on Desktop，開唔到嘅話用 Blackmagic 嘅 CaptureLogs 工具。Premiere 就留意係咪「Error compiling movie」，加埋邊個 codec、邊個時間點停。Windows 事件檢視器就睇 `nvlddmkm` 相關錯誤。
第三步：驅動分支互換測試。 Studio ↔ Game Ready，clean install，唔好直接覆蓋。記低邊個 build 得、邊個 build 唔得，呢個紀錄跟進嗰陣好有用。
第四步：VRAM 壓力二分。 降顯存時脈（memory underclock）做診斷用——如果降頻之後穩定咗，就指向顯存子系統（溫度／時序／本體），而唔係核心。注意，呢個係診斷手法，唔係長期解法，唔好當調好咗。
第五步：PSU 餘量檢查。 最直接係換已知良好嘅 PSU 交叉試；或者用牆插功耗計睇實際整機功耗——但注意，牆插計睇唔到微秒級尖峰，只能夠做參考下限。重點要問：隻 PSU 幾多年？咩 rail 設計？係咪轉過驅動或者 Windows 更新之後先出事？
第六步：跨機交叉測試。 將張卡拎去另一部機，跑同一個 render。問題跟住張卡走，先至係硬件；唔跟，就係原機環境（驅動／PSU／系統）嘅事。
仲有幾個陷阱要順手清：Chrome（開咗硬件加速）、Discord、Xbox Game Bar、ShadowPlay overlay 會靜默食 GPU 資源；Windows Defender 即時掃描掃緊 cache folder，都試過 freeze 住 Resolve——渲染前清後台係合理步驟。雙卡系統都要留意：Blender 喺雙卡系統可能將數據送錯卡，`cuMemcpy2DUnaligned` 類錯誤有案例係關掉其中一張卡解決，排查嗰陣可以試單卡。
幾時先係真硬件問題
講到尾，大多數渲染崩潰都係 VRAM 唔夠、TDR、驅動、PSU 四樣嘢，真正核心或者顯存物理損壞係少數。以下訊號先至指向硬件：跨機交叉測試，問題跟住張卡走；降顯存時脈之後明顯穩定（指向顯存子系統）；除咗崩潰，仲出現花屏、雜訊等物理性徵兆。
行晒上面六步都仲係鎖定唔到，或者已經確定係硬件層面，先至係考慮維修嘅時候。懷疑硬件問題，可以帶機到店檢測：石門達利廣場1209室（Dali Plaza）；電話 2186 8010；WhatsApp 6558 6806。
常見問題
問：Studio driver 係咪一定比 Game Ready 穩？創作者係咪一定要裝 Studio？
答：唔係定律。兩個分支係同一底層代碼、支援同一 GPU 同同一套硬件功能，差別只在驗證對象同發佈節奏；個別 Studio build 都可以有 regression。正確做法係創作優先就先試 Studio，出事就做分支互換測試，逐個 build 驗證，唔好靠個名嚟判斷穩定。
問：打機冇事、渲染先崩，係咪代表張卡壞咗？
答：多數唔係。遊戲同渲染用嘅係同一粒 GPU，唔同嘅係負載形狀：遊戲可搶佔、定時讓權畀 OS；渲染係長時間非搶佔 kernel，加埋 VRAM 斷崖式載入。絕大多數渲染崩潰嚟自 VRAM 唔夠、TDR 超時、驅動、PSU 呢四樣，行晒隔離流程先好判張卡死刑。
問：改 TdrDelay 有冇風險？
答：有，風險自負。改之前先備份 registry；Microsoft 指明呢啲 key 係畀驅動開發、測試、除錯用，終端用戶唔應該亂改。仲有一個跟進陷阱：Windows 更新或者驅動更新有可能將個 key 重置返預設值，令崩潰「無端端返嚟」。
問：火數明明夠，點解渲染仲會成部機熄？
答：因為問題唔喺平均瓦數，而喺微秒級瞬態尖峰觸發咗 PSU 嘅 OCP／OPP 保護。舊、平價、或者老化咗嘅 PSU 最易中；multi-rail 線插錯組亦會無端端觸發。要問嘅係隻 PSU 幾多年、咩 rail 設計，而唔係名牌寫住幾多 W。
問：點樣知崩潰係 VRAM 唔夠？
答：睇三樣。第一係報錯字串：`CUDA error: out of memory`、Resolve 嘅「GPU Memory Full」。第二係工作管理員 → 效能 → GPU → 專用 GPU 記憶體，睇渲染嗰陣係咪頂到上限。第三係降分辨率或者淨 render 單幀 test frame——一幀過到、成段爆，好大機會就係 VRAM 斷崖。
問：記憶體結溫幾多度先算過熱？
答：呢個問題冇可靠答案可以畀。社群講法互相矛盾，第一手規格文件又冇公開版本，所以唔會喺呢度寫死一個紅線數字。可以肯定嘅只有兩點：GDDR6X 結溫遠高過核心係正常現象，而且一定要用 HWiNFO64 獨立監察，唔好淨係睇核心溫度。
問：換咗張慢啲嘅卡反而多咗崩，係咪兩張卡都有問題？
答：唔一定。呢個係 TDR 悖論：慢卡跑同一個長 compute kernel，更易超過 Windows 預設 2 秒回應限期，觸發驅動重置。崩得多咗可能只係超時問題，而唔係兩張卡都壞——先懷疑 TDR，唔好即刻判兩張卡死刑。
*如果你嘅顯示卡喺剪片、渲染或者運算嗰陣成日崩潰，歡迎 WhatsApp 6558 6806 或者致電 2186 8010 查詢，門市喺石門達利廣場1209室（Dali Plaza）。*