GPGPU 讓 GPU 變成通用算力引擎
GPGPU 讓 GPU 跑起非繪圖工作，CUDA、OpenCL 與 ROCm 讓這件事變成主流工具鏈。
GPGPU 讓 GPU 從繪圖晶片，變成能跑通用運算的算力引擎。
這條路不是偶然。2006 年 CUDA 上線，OpenCL 走開放標準，ROCm 則補上 AMD 的開源路線。到今天，很多超級電腦都靠 GPU 跑核心工作，某些高度最佳化的程式，速度甚至比 CPU-only 版本快上數百倍。
這篇文章要談的，就是 GPU 怎麼從畫圖，走到一般運算。重點很直接：當工作量夠平行，GPU 會比 CPU 更划算。問題只在於，你得先把程式寫對。
| Milestone | Year | Why it mattered |
|---|---|---|
| Conway's Game of Life on a blitter | 1987 | 早期證明非繪圖運算可在圖形硬體上執行 |
| GPU compute becomes practical | 2001 | 可程式化 shader 與浮點支援讓通用運算更可行 |
| GPU linear algebra breakthroughs | 2003 | 研究團隊證明 GPU 可在部分矩陣問題上超越 CPU |
| CUDA launch | 2006 | 讓 GPU 程式設計脫離純圖形概念 |
| ROCm launch | 2016 | AMD 的開源替代方案正式登場 |
GPU 為什麼能跑通用運算
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
GPU 的設計邏輯很簡單。它把晶片面積，更多拿去放運算單元。CPU 則把資源放在快取、分支預測、低延遲控制流。兩者目標不同，所以適合的工作也不同。
圖形運算本來就很像平行計算。每個像素、每個頂點、每個矩陣格子，都能同時處理。這種模式一旦搬到科學計算、影像處理、機器學習，效果就很明顯。
早期 GPGPU 很麻煩。開發者得把數學問題硬翻成圖形 API 的語言，像 OpenGL 和 Direct3D。這種做法能跑，但很卡。你不是在寫運算程式，你是在繞路。
- GPU 擅長大量相同操作。
- CPU 擅長分支多、邏輯雜的程式。
- 資料搬移成本常決定成敗。
- 科學計算和影像工作最吃香。
軟體堆疊才是關鍵
硬體夠強只是起點。真正讓 GPGPU 變實用的，是軟體工具鏈成熟了。OpenCL 提供跨平台 API，CUDA 則把 Nvidia 的生態系做得很完整。文件、編譯器、函式庫、除錯工具，全都一起到位。
這個差異到今天還很現實。CUDA 仍是很多 AI 與科學計算團隊的預設選項。原因很俗氣，也很真實：好用。你不一定愛它，但你很難忽略它。
AMD 的 ROCm 提供開源路線，對研究與伺服器部署很有吸引力。只是生態完整度仍常被拿來跟 CUDA 比。這也是為什麼很多團隊選 GPU 時，先看軟體，再看晶片規格。
“CUDA is a general purpose parallel computing language and programming model that leverages the parallel compute engine in Nvidia GPUs to solve many complex computational problems in a more efficient way than on a CPU.” — Nvidia
這句話講得很直白。CUDA 的核心賣點，不是畫圖更快，而是把 GPU 變成通用平行運算平台。這也是它能吃下大批 HPC 和 AI 工作的原因。
其他平台也各有路線。DirectCompute 跟著 Direct3D 11 來，Metal 把 Apple 生態系的 GPU 計算整合進去，Android 也曾試過 RenderScript，後來逐步轉向 compute shader 與 Vulkan Compute。路線很多，但方向一致。
哪些工作適合丟給 GPU
GPU 不是萬能。它只是在某些工作上很猛。只要問題能拆成很多相似的小任務，GPU 就很有機會贏。像矩陣運算、影像濾鏡、模擬、基因比對，都是典型案例。
相反地，分支很多、流程很亂、資料很小的工作，CPU 通常更省事。因為 GPU 的強項是吞吐量，不是單一任務延遲。你把一個小程式硬塞進 GPU，常常只是浪費搬資料的時間。
所以實務上，GPGPU 的判斷很像選工具。不是看到 GPU 就上，也不是看到 CPU 就保守。你要先算資料量，再算平行度，最後才看傳輸成本。
- 適合：矩陣乘法、影像處理、AI 訓練、物理模擬。
- 不太適合：大量分支、短任務、低延遲控制流程。
- 常見瓶頸：CPU 與 GPU 之間的資料搬移。
- 實戰重點：把工作拆成可平行的批次。
很多人第一次碰 GPU 加速，都會犯同一個錯。只看算力，不看資料路徑。結果就是理論很漂亮，實測很慘。這也是為什麼 profiling 比想像力重要。
數字比較才看得出差距
GPGPU 的變化，最好用數字看。2006 年 CUDA 出現後，開發者不必再一直繞著圖形 API 寫怪程式。2016 年 ROCm 登場，AMD 才有比較完整的開源替代方案。這些年份本身，就能看出產業節奏。
更重要的是效能落差。文章提到，有些最佳化工作在 GPU 上可達到 CPU-only 版本的數百倍速度。這種差距通常出現在高度平行、資料密集、而且能把記憶體存取安排好的場景。
但別把這個數字當萬用答案。GPU 的優勢很吃工作型態。你如果只是跑一般網站後端，硬上 GPU 通常不會比較省。你如果在做大規模矩陣、影像或模型訓練，GPU 才像正確解法。
- 1987：早期就有人把非繪圖運算塞進圖形硬體。
- 2001：可程式化 shader 讓通用運算更容易。
- 2003：部分矩陣問題已能看到 GPU 優勢。
- 2006：CUDA 讓 GPU 程式化門檻下降。
- 2016：ROCm 讓 AMD 生態開始補位。
這些節點串起來，就會看到一件事。GPGPU 不是某個神奇理論突然出現，而是硬體、API、編譯器、函式庫，一起慢慢成熟。每一層都到位，才輪得到開發者真的拿來用。
台灣開發者該怎麼看這件事
如果你在台灣做軟體，GPGPU 不該只存在於 AI 新聞裡。它跟資料處理、影像服務、工業視覺、醫療分析都有關。很多公司現在買 GPU，不是為了遊戲，而是為了伺服器吞吐量。
產業上也很現實。Nvidia 的 資料中心產品、AMD 的 Instinct，再加上 SYCL 這類高階抽象，正在把 GPU 計算推進更多工作流程。你不用每天寫 CUDA，但你很可能會碰到 GPU 加速過的服務。
我的看法很直接。未來幾年，懂得判斷「這個工作該不該上 GPU」的人，會比只會喊 AI 的人更有價值。因為真正的成本，不在模型名稱，而在算力配置和資料流設計。
如果你現在要開始評估，先問三個問題。資料夠不夠大。任務夠不夠平行。搬資料的成本高不高。這三題答完，八成就知道要不要碰 GPU。
結論很簡單：先算資料，再選算力
GPGPU 已經不是冷門技巧。它是現代高效能運算的一部分，也是 AI、模擬、影像處理常見的底層做法。真正的差別，不在於 GPU 能不能算，而在於你有沒有把問題寫成它擅長的樣子。
如果你手上的工作是大量平行、資料密集、流程固定，GPU 幾乎一定值得試。反過來，如果你的瓶頸在分支、延遲，或資料太小，CPU 反而更乾淨。下一次做架構決策時，先把 profiling 跑完，再決定要不要上 GPU。