Gaze Guard 耗電量實測:Chrome 擴充功能跑 MediaPipe 到底多耗電?

MediaPipe 在 Chrome Extension 背景持續跑人臉偵測到底多耗電?實測 SoC 層級數據,拆解 GPU/ANE 開銷。

分享
Gaze Guard 耗電量實測:Chrome 擴充功能跑 MediaPipe 到底多耗電?
Photo by Panos Sakalakis on Unsplash

背景

Gaze Guard 是一個 Chrome Extension,透過攝影機偵測是否有人從遠處偷看你的螢幕,所有運算完全在本機完成。

核心技術:MediaPipe FaceLandmarker(WASM)在 offscreen document 背景以約 10 FPS 持續跑人臉偵測,估算距離與頭部朝向,判斷是否觸發提醒。

一直好奇:這樣的背景推論到底有多耗電?最直接的問法就是——開啟監控 vs 關閉監控,差多少?

結論先講:開啟監控比關閉約多耗 277 mW(SoC 層級),主要來自 GPU 與 ANE。換算 MacBook Pro M4 電池續航大約少 12–17 分鐘(約 2.8%)

怎麼測的?

sudo powermetrics --samplers cpu_power,battery -i 5000 -n 1

分別在以下兩個狀態各取一次 snapshot:

  • 未啟動:Extension 已安裝,但監控功能未開啟(無攝影機串流、無推論)
  • 監控中:正常使用狀態,10 FPS 持續偵測

測試機器:MacBook Pro M4 Pro / macOS 15

⚠️ 每個條件只取一次 snapshot,單次測量有雜訊,僅供參考趨勢。

開、關監控差多少?(SoC 層級)

狀態 CPU GPU ANE SoC 合計
未啟動監控 110 mW 78 mW 0 mW 188 mW
監控中 165 mW 259 mW 41 mW 465 mW
差額 +55 mW +181 mW +41 mW +277 mW

開啟監控後,整體 SoC 耗電從 188 mW 上升到 465 mW,多出約 277 mW


哪個元件最耗電?

1. GPU 才是主要耗電點

開始監控後,GPU 從 78 mW 跳到 259 mW(+232%),是三個區塊裡增幅最大的。原因有兩層:

  • Chrome webcam pipeline:video stream 由 Chrome 處理、常駐運作,是 GPU 上升的大頭
  • MediaPipe detectForVideo() 推論:每幀人臉偵測的額外 GPU 成本

2. ANE 模型常駐 +41 mW

只要監控啟動,Apple Neural Engine 就維持 41 mW。這是 MediaPipe WASM 初始化後的常駐開銷,未啟動時為 0。

3. CPU 增幅最小

CPU 只從 110 mW 上升到 165 mW(+55 mW)。推論與影像處理主要落在 GPU 與 ANE,CPU 不是瓶頸。


對電池續航影響多大?

假設輕度作業情境總系統耗電 10 W(含螢幕、Wi-Fi、SSD 等):

機型 電池 未啟動 監控中 損失
MBP M4 Pro 14" 72.0 Wh 7 h 12 min 7 h 00 min -12 min
MBP M4 Pro 16" 99.6 Wh 9 h 58 min 9 h 41 min -17 min

監控功能對電池續航影響約 2.8%,換算約 12–17 分鐘。


結論

數據
開啟監控額外耗電 +277 mW SoC(vs 未啟動)
主要來源 GPU +181 mW、ANE +41 mW、CPU +55 mW
電池續航差異 MBP M4 Pro 約 12–17 分鐘(2.8%)

對於一個需要持續本機推論的隱私保護工具來說,277 mW 的額外開銷在可接受範圍內。要省電的話,比起壓低偵測頻率,更有效的方向是在「長時間沒有外來人臉」時暫停推論——但那是另一個功能了。


常見問題

Gaze Guard 很耗電嗎? 開啟監控比關閉約多耗 277 mW,日常輕度使用下,筆電電池續航約少 12–17 分鐘(約 2.8%),屬於可接受範圍。

調低偵測 FPS 能省電嗎? 效益極低。耗電大頭是 Chrome 的 webcam pipeline 與 GPU,這部分成本與 FPS 無關,所以把 FPS 調低省不了多少電。

哪個元件最耗電? GPU 增幅最大(+181 mW),其次是 Apple Neural Engine(+41 mW),CPU 只多 55 mW。


English version: Gaze Guard Power Draw Measured 測試日期:2026-06-17 / Extension 版本:v1.0.3 GitHub:steepinglogic/gaze-guard

Read more

Gaze Guard 短影片旁白的 TTS 成本與隱私防護示意圖

短影片旁白的成本,其實比我想像低

我最近在做一支 Gaze Guard 的 20 秒產品介紹影片。 原本想說簡單做個動畫就好。 後來想說如果有配音,會感覺比較生動也比較能夠描述使用的情境和達成的效果。 這次我測了什麼 我測的是產品介紹影片用的英文旁白。 工具底層使用的是 Edge TTS,也就是 Microsoft Edge 的線上 Text-to-Speech 服務。常見的底層工具是 edge-tts。 這不是正式 Azure Speech API 的計費路徑。 在我這次的環境裡,它沒有要求 API key,也沒有回傳可見的 per-use billing。 所以這次測試本身,比較像是快速 prototype。 如果未來要正式商用、穩定大量產出,就要回頭看 Azure Speech、OpenAI TTS、ElevenLabs 這類正式付費方案。

By SteepingLogic
用 Cloudflare Tunnel,從外面連回本機 Hermes Dashboard

用 Cloudflare Tunnel,從外面連回本機 Hermes Dashboard

# 用 Cloudflare Tunnel,從外面連回本機 Hermes Dashboard 我有一台 local Hermes。 平常它就在自己的機器上跑。 可能是家裡的桌機。 可能是 NAS。 可能是一台一直開著的 Linux box。 也可能只是我自己的筆電。 問題是,人一離開那個網路,Hermes dashboard 就變成一個只存在於 localhost 的東西。 我想在外面打開它。 但我沒有 static IP。 沒有買網域。 也不想進路由器開 port forwarding。 因為那條路通常長這樣: * 找 public IP * 設定 NAT * 開 port * 處理防火牆 * 補 HTTPS * 設定憑證 * 再擔心 origin IP 被掃 非常友善。 所以這篇先走另一條路:

By SteepingLogic
Invoshot 開發日記|正向回饋

Invoshot 開發日記|正向回饋

想信很多人在開發的時候都常常會做一件事,那就是: 不斷地反覆思考,在腦袋內把流程跑過很多次,然後思考哪裡可以做得更好 不限坐在電腦前的時後,可能是在捷運上,在人行道上, 在馬桶上或是在洗澡的時候 🤪 我不斷地在想:AI 辨識完一張發票後,使用者接下來最需要的是什麼? 每個欄位都要核對嗎? 這麼多欄位真的不會漏看嗎? 所以我在 Invoshot 裡加了提醒功能。 辨識結果出來後,系統會把比較需要注意的地方標出來。 不是把所有不確定都丟給使用者,而是把他真正需要介入的那幾秒鐘留出來。 今天收到一則訊息: 今天用了有新增提醒功能很棒! 真的有變輕鬆 😎 看到這句的時候,我第一個想到的是: 原來那些只是我腦內風暴的優化項目,使用者是真的可以感受到差異的! 感覺又有動力了!

By SteepingLogic