40MB模型在瀏覽器本地去背：掘金文章記錄的純前端摳圖方案與可核實數據

一篇標題為「網頁端，40mb離線模型，自動摳圖，不用 Python，不用伺服器，不用 API Key，不用顯示卡」的文章，於2026年9月17日刊於掘金平臺，作者署名「半刻維度」。文章介紹以 @imgly/background-removal 套件在瀏覽器內完成人像與物品去背的作法，全程不依賴後端、不經手第三方伺服器。本臺綜合該文內容與套件公開文件，整理這項方案的技術輪廓、效能數據與訊源邊界。

文章主張：一張照片，點一下，摳完

根據原文描述，整個流程是使用者選取一張照片，呼叫 removeBackground 函式後，數秒內取得一張背景透明的 PNG 圖檔。圖片不上傳，運算全部在本機瀏覽器內完成。

作者提供的實測環境是一臺自述為「老古董」的機器，處理器為 AMD 5500。在這樣的硬體條件下，使用約 40MB 的量化模型，單張去背耗時約 8 秒。原文未交代測試圖片的解析度、瀏覽器版本與實際走的推理後端，這幾項變數都會影響耗時，8 秒這個數字宜視為單一環境下的參考值。

文章列出的核心程式碼相當短：透過 jsDelivr CDN 以 ESM 方式引入 @imgly/background-removal 1.7.0 版，取得檔案後呼叫 removeBackground，再以 URL.createObjectURL 產生可預覽、可下載的 Blob。開發者不需要 npm 安裝，也不需要設定 publicPath，模型檔由套件自行從 CDN 拉取。

套件輪廓與模型選項

@imgly/background-removal 是 IMG.LY 開源的 JavaScript 套件。原文引述其在 GitHub 上約有 6.8 千顆星，底層採用 ONNX Runtime Web 做推理，分割模型為 ISNet，一款專為圖像分割設計的神經網路。

套件提供兩個主要的模型檔案。一是 isnet_fp16，約 80MB，為預設推薦版本，精度較高；二是 isnet_quint8，約 40MB，為量化版本，速度約快一倍，精度略有損失。作者的實用建議是：人像去背若在意髮絲細節選 FP16，一般物品去背選 QuInt8，肉眼看不出明顯差別。

推理後端的選擇由套件自動判斷：優先使用 WebGPU，其次降級到 WebGL，最後以 WASM 在純 CPU 上執行。原文強調整個判斷過程不需要開發者撰寫相容程式碼，有顯示卡就用顯示卡，沒有就用 CPU。

這類在瀏覽器內完成運算的做法，與近年端側 AI 工具的走向一致。先前本臺整理過的2026年可從專案刪掉五個npm包的論點一文，同樣記錄了瀏覽器原生能力逐步取代外部依賴的趨勢，兩者可互為對照。

原文列舉的痛點：隱私與成本

文章以電商情境切入。作者描述做電商的人天天需要去背，一張一張用 Photoshop 處理，摳頭髮、摳花邊，半小時一張。而線上去背工具多數將圖片傳到對方伺服器處理，隱私上有疑慮，還需要付費。

純前端方案的對照優勢由此而來：圖不離開本機，沒有上傳環節，沒有 API 費用，也沒有伺服器維運成本。對處理量大但單張利潤薄的電商用途，這些條件構成實際的成本差異。需要留意的是，隱私優勢的前提是 CDN 載入的程式碼與模型檔本身可信，模型檔首次載入後可被瀏覽器快取，後續操作不再依賴網路。

進度回調、輸出格式與輸出類型

套件提供進度回調介面，開發者可透過 progress 函式取得 key、current、total 三個參數。key 標示當前階段，分為 download（下載模型）、load（載入模型）、run（前向推理）、postprocess（後處理）四段；current 與 total 用於計算百分比，當 total 為 0 時表示該階段無進度資訊，可直接忽略。

輸出格式支援三種。PNG 支援透明背景但檔案最大；JPEG 檔案最小但無透明，可設定 quality 參數；WebP 介於兩者之間，支援透明且體積中等，同樣可調品質。預設輸出為 PNG。輸出類型亦可選擇 foreground（主體，預設）或背景，原文在物品去背段落示範了取得背景圖的設定方式。

訊源邊界與後續

本案的訊源主體是掘金作者的單篇實測文章，輔以套件在 GitHub 的公開文件與 jsDelivr CDN 的發布紀錄。8 秒的耗時數據僅來自作者一臺 AMD 5500 機器的實測，未附測試圖檔規格與瀏覽器條件，不同硬體與後端組合下的表現有待更多獨立實測補充。6.8 千顆星為文章刊出時的引述數字，實際數量隨時間變動。

至於模型精度，原文的 FP16 與 QuInt8 差異描述屬作者使用體感，IMG.LY 官方文件並未在文中被引用具體的分割精度指標。人像與物品兩類題材的適用性建議，同樣以作者的實際使用經驗為依據。

對照來看，瀏覽器端推理近來已有多個案例：從本臺先前整理的V2EX 用戶以太陽儀專案測試 Astra 模型，到各類以 WASM 與 WebGPU 為基礎的端側工具，運算下沉到使用者裝置的作法正在多個場景出現。40MB 模型能否在更舊的硬體上維持可用速度，以及 WebGPU 普及後耗時能壓到什麼程度，是這類方案後續可觀察的兩個變數。

文章刊出後，這類零後端去背方案的討論重心預期會落在三個面向：模型檔首次載入的等待時間、無 WebGPU 環境下的速度底線，以及量化模型在細微邊緣上的精度損失是否可被商用情境接受。這些問題的答案，需要更多不同機器的實測數據才能收斂。