0. 前言：為什麼一個影像解碼器值得寫三千字？
如果你問一個做過生產環境 AI pipeline 的人，最痛的不是模型 inference 慢。
最痛的是：模型跑得飛快，結果解碼階段卡住，GPU 利用率只有一小塊。
NVIDIA 在 2026 年 4 月 2 號發表了一篇滿硬核的技術文章——跟 V-Nova 合作的 VC-6 批次解碼器最佳化。核心結論就一句話：同一批資料，每張圖解碼時間砍掉 85%，4K 解析度在 batch 下解碼不到 1 毫秒，低解析度可以跑到 0.2 毫秒。
但數字只是表象。真正值得看的是他們的優化方法論：從 Nsight Systems 系統層級的瓶頸定位，到 Nsight Compute 指令級的微調，再到架構層級重新設計執行模型。這套流程對任何做 GPU 編程的人都有參考價值。
廢話不多說，直接拆。
1. 研究動機：Vision AI Pipeline 的 data-to-tensor gap
1.1 系統不平衡問題
在一個典型的視覺 AI pipeline 裡，資料從原始影像到模型推理要經歷以下流程：
$$\text{Decode} \xrightarrow{\text{Preprocess}} \text{Normalize} \xrightarrow{\text{Transfer}} \text{GPU Tensor} \xrightarrow{\text{Inference}} \text{Prediction}$$如果模型的吞吐量是每秒處理數百張影像，那解碼、前處理、GPU 排程這些前置階段必須跟上。一旦解碼跟不上，GPU 就會閒置。
NVIDIA 把這個問題叫做 data-to-tensor gap（資料到張量的落差）——模型訓練和推理的效率持續提升，但資料餵送的速度卻成了瓶頸。
1.2 為什麼是 VC-6？
SMPTE VC-6（標準編號 ST 2117-1）是 V-Nova 開發的一種新一代影像/影片編解碼器。它的核心設計思路跟傳統的 JPEG 或 H.264 不太一樣，採用的是 分層式、基於 tile（拼貼塊）的架構。
影像被編碼成多個「品質等級」（Level of Quality，簡稱 LoQ），每個 LoQ 是在上一層的基礎上遞增細節：
$$\text{LoQ}_{k+1} = \text{LoQ}_{k} + \Delta R_{k+1}$$其中 $\Delta R_{k+1}$ 代表第 $k+1$ 層的精細度殘差。這意味著你可以只解碼到某個 LoQ 就停下來，而不需要把整張圖全部解出來。
這種架構帶來了三個關鍵優勢：
- 選擇性解碼：根據模型的需求，只解碼需要的解析度。比如一個分類模型可能只需要 0.5K 的粗解析度就能做出判斷。
- 區域興趣提取：可以直接解碼影像的某個特定區塊，不需要解整張圖。
- 顏色平面隨機存取：每個 tile 獨立可解碼，支援隨機存取幀（intra-only random access）。
簡單講，讓 pipeline 只解碼模型真正需要的資料，避免不必要的計算浪費。
2. 問題定義：單一影像解碼的高效 ≠ 批量擴展的高效
VC-6 最初的 CUDA 實作針對的是單一影像解碼。也就是說，每個解碼器實例（decoder instance）負責解碼一張圖。
當你只有少量影像要處理時，這種做法沒什麼大問題。但當 batch size 往上拉——比如訓練時一次塞 64、128、甚至 256 張圖——問題就來了。
2.1 瓶頸轉移
在單影像設計中，瓶頸是單一 kernel 的執行效率：解碼器能不能把這張圖在最短時間裡解出來？優化方向是減少該 kernel 的指令數、優化記憶體存取模式。
但到了批量處理場景，瓶頸變成了workload orchestration（工作調度）：
- kernel launch 頻率高
- GPU occupancy 不均
- CPU 與 GPU 之間同步過多
這是一個很典型的問題——單點優化不等於系統優化。就像你給每個員工配了最快的打字機，但如果他們花一半的時間在排隊等审批，整體產能還是不會上去。
2.2 Math 化的瓶頸分析
讓我們把這個問題量化一下。假設有 $N$ 張影像，每個 kernel launch 的固定開銷為 $C_{\text{launch}}$，kernel 的實際計算時間為 $C_{\text{compute}}(I)$（$I$ 代表影像資料量），則總時間為：
$$T_{\text{total}} = N \cdot C_{\text{launch}} + \sum_{i=1}^{N} C_{\text{compute}}(I_i)$$開銷比為：
$$R_{\text{overhead}} = \frac{N \cdot C_{\text{launch}}}{T_{\text{total}}}$$當 $C_{\text{compute}}(I_i)$ 很小時（比如低解析度或低品質的影像），$R_{\text{overhead}}$ 會急劇上升。這就是在小 batch 中 GPU 利用率低的原因——launch overhead 吃掉了太多時間。
3. 核心創新：從 N 個解碼器到 1 個批次解碼器
3.1 執行模型重設計
解決方案的思路很直觀：把 N 張影像的解碼任務打包，讓一個解碼器一次處理整批資料。
原本的設計：
$$N \text{ 個 decoder instance} \xrightarrow{\text{各解一張}} N \text{ 個 kernel launch}$$重設計後：
$$1 \text{ 個 batch decoder} \xrightarrow{\text{解一批}} K \ll N \text{ 個 kernel launch（大幅減少）}$$從 Nsight Systems 的 profile 可以清楚看到這個轉變的影响（Figure 1）。重設計前，CUDA API 時間軸上充滿了密集的小 kernel 啟動，GPU 利用率呈斷續狀態。重設計後，只剩下幾個大型 kernel，GPU 利用率幾乎滿載。
這不僅僅是減少 API 呼叫次數的問題。這是一種思考方式的翻轉：從「一個解碼器處理一張圖」變成「一個解碼器處理一批圖」。
3.2 多維度並行化擴展
原本的 VC-6 GPU 解碼器利用兩個維度的並行化來處理工作：
- Tile（拼貼塊）維度：影像被切分為多個 tile，每個 tile 獨立解碼。
- Plane（平面）維度：YCbCr 三個顏色通道可以單獨處理。
批次化設計引入了第三個並行維度——image（影像）維度：
$$\text{BatchWorkDimension} = \text{Tiles} \times \text{Planes} \times \text{Images}$$這使得 GPU 可以利用原本被浪費的閒置算力。特別是對於 tile hierarchy 中的較窄層級（root level 和 narrow levels），原本的單一影像處理量太小，不值得放到 GPU 上跑。但當多張影像疊加後，總工作量足以讓 GPU 的 SM（Streaming Multiprocessors）維持在高佔用率。
3.3 CPU 端邏輯下沉到 GPU
原本實作中，VC-6 tile hierarchy 的 root 和 narrow level 的解碼是在 CPU 上進行的。原因很簡單：對單張圖來說，這些階段的計算量太小，不值得做 host-to-device 記憶體傳輸。
但批次設計改變了成本效益公式。當 $N$ 張影像的 narrow-level 工作被聚合在一起後，GPU 端執行的收益遠大於傳輸開銷。
此外，變長影像維度的處理邏輯也被從 host 端搬到了 GPU kernel 內部。這帶來了幾個副作用：
- 減少了 CPU-GPU 同步點的數量，設 $S$ 為同步次數，$T_{\text{sync}}$ 為每次同步的延遲，總同步延遲 $\Delta T_{\text{sync}}$ 減少為：
- 降低了 kernel submission 的延遲（submission latency）
- 提高了 pipeline 的流暢度（pipeline fluidity）
4. Minibatch Pipelining：隱藏各階段的成本
4.1 Pipeline 架構
光是把多個解碼任務打包到一個 kernel 還不夠。為了確保 GPU 持續滿載，NVIDIA 團隊設計了一個 三階段 pipeline：
- CPU 處理階段：在 host 端準備下一批資料
- PCIe 傳輸階段：將資料從 host 記憶體拷貝到 device 記憶體
- GPU 解碼階段：在 GPU 上執行解碼 kernel
關鍵設計：每個階段同時處理不同 minibatch 的資料。
用排隊論的語言來說，這是一個 pipelined queue 系統：
$$T_{\text{pipeline}} = T_{\text{CPU}} + T_{\text{PCIe}} + \max(T_{\text{GPU}} - \min(T_{\text{CPU}}, T_{\text{PCIe}}), 0) + T_{\text{download}}$$當 $T_{\text{GPU}}$ 是瓶頸時，CPU 處理和 PCIe 傳輸的時間就被 GPU 解碼期間的 waiting time 給 hide 掉了。這跟 CPU 的指令管線（instruction pipeline）原理完全一樣。
4.2 Nsight Systems 的視覺確認
從 Figure 4 可以清楚看到這個效果。CUDA API 被分派到兩個執行緒：UPLOAD（負責上傳和下載資料）和 GPU（負責觸發解碼 kernel）。在 GPU 滿載運行的同時，UPLOAD 執行緒已經在處理下一個 batch 的上傳，同時還在下載前一個 batch 的結果。
這是最乾淨的 pipeline 狀態——GPU 永遠不會在等資料，CPU 永遠不會在等 GPU。
5. Kernel 級最佳化：從 Nsight Compute 到 SASS 指令的調教
5.1 系統層剖析之後的下一步
Nsight Systems 解掉了 CPU 端和系統層級的瓶頸，但還有剩餘的效能天花板需要突破。這時候就需要 Nsight Compute，一個針對單一 kernel 的剖析工具。
被重點盯上的 kernel 叫做 terminal_decode——這是實現**範圍解碼器（range decoder）**的核心 kernel。
5.2 範圍解碼器與整數除法瓶頸
範圍解碼器（Range Decoder）是算術編碼（Arithmetic Coding）的逆運算。簡單來說就是把壓縮過的位元流還原成原始的符號序列。核心操作流程可以用以下公式表示（CABAC 類似的解碼過程）：
$$\text{range}_{i+1} = \lfloor \text{range}_i \times p \rfloor$$$$\text{low}_{i+1} = \text{low}_i + (\text{range}_i \times \text{cumulative\_prob})$$其中 $p$ 是當前符號的概率，$\text{cumulative\_prob}$ 是累積概率。
Nsight Compute 的 source heatmap 和 Warp Stall Sampling 顯示，這個 kernel 中有相當大的時間花在整數除法上（Figure 5）。GPU 的整數除法單元（DIV unit）效率遠低於浮點乘法——這在 GPU 硬體架構中是一個已知的事實。
但問題是：解碼器的精確度是不容妥協的。 你不能用 __fdividef（快速浮點除法）來替代精確整數除法，因為一個比特的誤差就可以讓整張圖的解碼崩潰。
5.3 查表優化：從二分搜尋到寄存器中的常數索引解法
另一個被 Nsight Compute 捕捉到的瓶頸是 decoder 的查表操作（table lookup）。原本的實作是在 shared memory 上做二分搜尋（binary search）。
Nsight Compute 顯示出大量的 short scoreboard stalls（Figure 6）。這些 stall 對應到 LDS（Load Shared memory）指令——warp 必須等待 shared memory 的資料載入完成才能繼續執行。
NVIDIA 團隊的解法很巧妙：
因為查表的大小是固定的，所以可以用一個展開的迴圈（unrolled loop）來替代二分搜尋。 這個 exhaustive search 的作法看似「暴力」，但有以下好處：
- 固定大小的陣列可以放到寄存器中，避免了 shared memory 和 local memory 的存取。
- 編譯器會把迴圈展開，生成固定的索引指令，讓 compiler 有最大機會做指令調度（instruction scheduling）。
兩個查表（兩個 range decoder 各一個）都經過這個改造後，該 kernel 的速度提升了約 20%。
5.4 記憶體階層的前後對比
Figure 7 用 Nsight Compute 的 memory hierarchy 圖表清晰地展示了這個變化的效果：
改動前：kernel 從 global memory、local memory、shared memory 讀取資料，L1 cache 命中率僅 9.4%。
改動後：kernel 只從 global memory 讀取，完全不使用 shared 和 local memory。L1 cache 命中率暴漲到 71.77%。
不過這個優化不是完全免費的。代價是：
$$\text{Registers per thread}: 48 \rightarrow 92$$寄存器用量幾乎翻倍。但因為這個 kernel 的 grid dimension 不大（每個 SM 只需要承載有限的 block），而且每執行緒上限是 255 個寄存器，所以 92 個寄存器並不構成問題。更重要的是，這個階段的高 block residency 不是優先考量，所以額外的 register pressure 不會影響整體吞吐量。
5.5 CUB 的引入
另外一個小而美的最佳化：把自訂的 selection routine 替換成 cub::DeviceSelect 函式。
CUB 是 NVIDIA 官方的 CUDA C++ 核心庫，專門提供針對各種 GPU 架構最佳化的基本演算法。用 CUB 的好處是：
- 程式碼更簡潔
- 未來的硬體優化由 NVIDIA 維護，不需要自己改
- CUB 的實作通常比手寫的自訂版本更高效
6. 實驗數據分析
6.1 測試環境
- 數據集：UHD-IQA dataset（可從 Hugging Face 透過 V-Nova 取得）
- GPU：NVIDIA L40s (g6e.8xlarge)、NVIDIA H100 (Hopper)、NVIDIA B200 (Blackwell)
- 品質等級：LoQ-0（~4K）、LoQ-1（~2K）、LoQ-2（~1K）、LoQ-3（~0.5K）
6.2 L40s 上的 Batch 擴展
Figure 8 展示了在 L40s 上，每張圖的解碼時間隨 batch size 的變化：
| Batch Size | LoQ-0 改善 | LoQ-2 改善 | LoQ-3 改善 |
|---|---|---|---|
| 1 | ~36% | — | — |
| 16 | — | ~70% | ~75% |
| 32 | — | ~80% | ~80% |
| 256 | ~85% | ~85% | ~85%+ |
兩個不同的擴展行為浮現：
- 最佳前的版本：在小 batch size（1-16）之後就達到 plateau。再增加影像數量也不會帶來額外的每張圖效益。
- 最佳後的版本：隨著 batch size 增加持續改善。LoQ-0 在大 batch size 下每張圖解碼時間低於 1 毫秒。
另一個有趣的觀察：相對改善幅度在較低 LoQ 時更大。這是因為每張影像的工作量更小，有更多獨立的工作可以被聚合在一起。在 high batch size 下，LoQ-2 解碼達到約 0.2 ms，LoQ-3 達到約 0.14 ms。
6.3 跨矽片驗證：H100 與 B200
Figure 9 驗證了批次解碼模式在不同 GPU 架構上的通用性。H100 和 B200 都呈現相似的擴展行為：
- Batch size 1 時最慢（因為 overhead 比例最大）
- 隨著 batch size 增加逐批加速
- 兩者 scaling curve 形狀幾乎一致
這證明了：最佳化效果不是某個特定 GPU 架構的 side effect，而是演算法層級的改進。 它透過批次模式暴露了足夠的並行工作量，足以餵飽現代的 GPU 架構。
7. 局限性評估
7.1 沒有銀彈
儘管數字很亮眼，但這個最佳化有幾個需要注意的限制：
Batch size = 1 時改善有限：~36% 的提升雖然不錯，但遠不到 85%。如果你的 workload 主要是 batch size 為 1 的場景（比如即時推理），這個最佳化的效益會大打折扣。
記憶體壓力增加：從 shared memory 轉向寄存器意味著每執行緒的記憶體佔用增加。對於更大的 kernel 或更高的 block occupancy 需求，這可能成為瓶頸。
VC-6 的採用率：VC-6 目前還不是一個主流的通用影像編解碼標準。它的好處在特定場景（Vision AI pipeline）非常顯著，但通用性不如 JPEG 或 WebP。
7.2 整數除法仍是最終的瓶頸
儘管做了各種優化，範圍解碼器中的整數除法操作仍然是不可避開的。Figure 5 的數據清楚顯示，integer division 佔用了 kernel 中相當大的時間比例。這是一個硬體層級的限制，在 GPU 的整數除法單元被大幅改善之前，無解。
7.3 未來研究方向
文章本身提到了幾個值得探索的方向：
- 利用 VC-6 的隨機存取特性，只做選擇性的 region-of-interest 解碼
- 針對訓練和 video summarization workflow 的定制化解碼策略
- 整合 color channel access 來進一步減少不必要的解碼工作
8. 產業影響
8.1 對 Vision AI 的意義
這篇文章的核心價值不在於 VC-6 本身，而在於它展示了一套完整的 GPU pipeline 最佳化方法論：
- 先用 Nsight Systems 做系統層級剖析，找到最大的性能漏斗
- 重新設計架構（N decoders → 1 batch decoder），解決 system-level 的 overhead
- 再用 Nsight Compute 做 kernel 級別的精調
- 跨硬體驗證，確保優化不是單一架構的 accident
這套流程對於任何在 GPU 上跑 AI pipeline 的團隊都適用。
8.2 對 AI 基礎設施成本的影响
想像一個部署了 1000 張 GPU 的訓練集群。如果 data preparation 階段的解碼時間降低 85%，那意味著：
- GPU 空轉時間大幅減少
- 同樣的時間內可以跑更多訓練 step
- 或者，同樣的訓練量，需要的 GPU 數量減少
後者的意義就是真金白銀。在 AI 模型的訓練成本動輒數百萬美元的今天，任何能降低 compute waste 的技術都有直接的商業價值。
8.3 對硬體採購策略的啟示
Article 最後提到，效能提升在 H100 和 B200 上的表現一致。這意味著在硬體升級的決策中，演算法層級的優化帶來的收益通常比純粹的硬體升級更可預測且更持久。
與其等新一代 GPU 上市，不如先檢視一下你现在的 pipeline 是否真的已經榨乾了現有硬體的潛力。
結語
一個影像解碼器能講這麼多，說明了現代 AI 系統的一個核心事實：性能瓶頸往往不在模型本身，而在模型周圍的那圈 infrastructure。
NVIDIA 和 V-Nova 的 VC-6 批次解碼優化，本質上是教了我們一件事情：不要假設你的硬體已經被充分利用了。用工具看，用數據說話，然後——不要害怕重新設計執行模型。
畢竟，把 N 個小 hammer 換成一個大 sledgehammer，往往比把每個小 hammer 磨得更利更管用。
