iT邦幫忙

2026 iThome 鐵人賽

DAY 28
0
AI Engineering

從零訓練到瀏覽器部署:30 天打造 Atari Breakout 強化學習 AI系列 第 28

Day 28|GPU 一定比 CPU 快嗎?實測 WebGPU 之後,答案是:不一定

  • 分享至 

  • xImage
  •  

Day 27 已經確認,同一個 Breakout 模型可以直接在瀏覽器裡執行,而且用 WASM 跑 60 個固定畫面時,最後選到的動作和 Python 全部一致。

接下來自然會有一個問題:

既然電腦有 GPU,把瀏覽器改成用 GPU 跑模型,應該會更快吧?

這就是 Day 28 要實際驗證的事情。

瀏覽器裡可以透過 WebGPU 使用 GPU 做運算。它不是另一個模型,而是換一種方式執行同一份 ONNX 模型。

所以今天要回答兩個問題:

  1. 換成 WebGPU 之後,模型的答案有沒有跑掉?
  2. 如果答案沒問題,它到底有沒有比 WASM 快?

先確認 WebGPU 沒有把模型算壞

在比較速度之前,第一件事情還是先確認結果正不正確。

我沿用 Day 27 的同一批 60 個 Breakout 畫面,把它們分別交給:

WASM
WebGPU

兩邊使用的是同一份模型,也都要替四個動作打分:

NOOP   什麼都不做
FIRE   發球
RIGHT  往右
LEFT   往左

這四個分數就是前面提過的 Q-value,可以先理解成模型對四個動作的評分;最後會選分數最高的動作。

正式測試是在 Cloudflare Pages 上的 Chrome 裡執行,而且頁面會同時顯示「要求使用哪一種方式」以及「實際使用哪一種方式」。

Cloudflare Pages 上的 WebGPU 驗證結果

這次 WebGPU 的結果是:

比較項目 結果
測試畫面 60
最大分數差異 0.0001619
平均分數差異 0.0000369
最後選到相同動作 60 / 60
動作不同 0

也就是說,這 60 個相同畫面交給 WebGPU 後,最後選到的動作全部和原本結果一致。

WASM 也重新跑了一次,同樣是 60 / 60

所以至少在這批固定畫面上,可以先確認:

WebGPU 能正確執行這個模型,沒有看到明顯的決策錯誤。

這仍然不是完整遊戲測試。真正打一整局之後表現如何,要等 Breakout 遊戲本身接進瀏覽器後再看。


接著才是今天真正有趣的問題:GPU 有比較快嗎?

為了公平比較,我讓 WASM 和 WebGPU 都先跑幾次暖身,再各自正式測量 100 次。

而且這次只量「模型開始計算,到四個動作分數可以拿到」所花的時間,不把第一次載入模型的時間算進去。

每次只處理一個遊戲狀態,這也最接近之後玩 Breakout 時的情況:

看到現在畫面
→ 模型算一次
→ 選一個動作

這次主要看兩個數字:

  • P50:可以理解成平常大多數情況下的一次計算時間。
  • P95:看比較慢的那一小部分會拖到多久。

實際結果如下:

WASM 與 WebGPU 的延遲比較

執行方式 P50 P95 平均
WASM 0.995 ms 1.385 ms 1.043 ms
WebGPU 3.985 ms 5.101 ms 4.011 ms

結果和直覺完全相反。

這次 WASM 反而明顯比 WebGPU 快。

以中間值來看,WebGPU 大約需要 WASM 的 4 倍時間;就連比較慢的 P95,WebGPU 也大約是 WASM 的 3.7 倍


為什麼 GPU 反而比較慢?

GPU 很擅長同時處理大量運算,但「有 GPU」不代表每一個工作都值得交給 GPU。

這次的 Breakout DQN 並不算大,而且每次只處理一個 84 × 84 的遊戲狀態。

可以把它想成:

工作本身很小
+
每次都要叫 GPU 開始工作
+
等 GPU 算完再把結果拿回來

如果真正需要計算的東西不夠多,叫 GPU 工作、等待結果的額外成本,反而可能比 GPU 幫你省下來的計算時間還大。

因此這次結果最合理的解讀是:

對這個小模型、一次只算一個畫面的情況,GPU 的額外成本太高,沒有發揮出平行運算的優勢。

但這不能推論成「WebGPU 都比較慢」。

如果換成更大的模型、一次處理更多資料,或不同瀏覽器與硬體,結果都有可能改變。

所以真正值得記住的是:

不要因為看到 GPU 就先假設一定更快,部署前還是要實測。


那 Day 28 為什麼還要保留 WebGPU?

雖然今天 WASM 比較快,但 WebGPU 仍然有保留的價值。

因為目前只量了「模型自己計算一次」的時間,真正的 Breakout 網頁之後還會多出:

取得遊戲畫面
→ 整理成模型需要的輸入
→ 模型計算
→ 選動作
→ 遊戲更新
→ 畫面重新顯示

到了完整遊戲裡,最後影響體感的會是整個流程,而不只是單獨的一次模型計算。

另外,速度也不是唯一條件。最後真正要選哪一種方式,還要看:

  • 玩很多局後,Agent 的分數是否正常;
  • 執行是否穩定;
  • 瀏覽器支援情況;
  • 完整遊戲流程的速度。

這也是為什麼現在還不急著宣布「最終一定使用 WASM」。


Day 28 的答案

今天得到兩個很明確的結果。

第一,WebGPU 可以正確執行同一個 Breakout 模型:

60 個固定畫面
→ 60 / 60 最後動作一致

第二,在這次 Chrome、這台電腦、這個 DQN,而且每次只處理一個畫面的條件下:

WASM
P50 約 1.0 ms

WebGPU
P50 約 4.0 ms

所以這次的答案是:

WebGPU 沒有算錯,但它也沒有比較快;反而是 WASM 明顯更快。

這個結果也提醒我一件很實際的事:GPU 是工具,不是「一定更快」的保證。

下一步真正重要的,就是把 Atari Breakout 接進目前這個網頁,讓左邊的玩家和右邊的 Agent 都真的開始玩。到那時候,才可以進一步用完整遊戲與多局分數決定瀏覽器最後應該使用哪一種執行方式。


上一篇
Day 27|把 Breakout 模型真的搬進瀏覽器
下一篇
Day 29|讓 RL Agent 真的在瀏覽器裡玩 Breakout
系列文
從零訓練到瀏覽器部署:30 天打造 Atari Breakout 強化學習 AI30
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言