瀏覽器生圖技術內幕：1-bit diffusion 點樣將 3GB 模型塞入 WebGPU？

一個 4B parameters 嘅 diffusion transformer，full-precision 要 7.75 GB。PrismML 上星期 release 嘅 Bonsai Image 4B，將同一條 pipeline 壓到 0.93 GB——唔係 quantize 到 8-bit 或者 4-bit，而係直接落到 1-bit。Binary weight：每個參數只剩 +1 或者 -1，成個 transformer 細過一隻 WhatsApp backup。仲要行到出 iPhone、行到出 WebGPU 瀏覽器。唔係 research prototype，係 Apache 2.0 open source，今日已經用得。

1-bit 嘅數學：點解唔爆鑊？

量化嘅核心問題好直接：你拎走咁多資訊，點解個 model 仲識畫圖？傳統 int8 quantization 已經會跌 accuracy，1-bit 理論上應該乜都認唔到先啱。

Bonsai 嘅關鍵在於佢唔係單純地「將 FP16 四捨五入做 +1/-1」。每個 weight 係 binary，但每個 group 嘅 weight 共享一個 FP16 scaling factor。BitNet 同 BitNet b1.58 嘅 research 證實咗一件事：neural network 嘅 weight 分佈其實好集中在零附近，你根本唔需要用 16-bit 去記住每個 weight 嘅準確位置，只要知道佢係正定負，再俾個 group-level 嘅尺度就得。

數學上，1-bit Bonsai 每個 weight 嘅有效 bit 寬度係 1.125 bits——因為個 scaling factor 攤分落一個 group 嘅 weight 度。Ternary 版本再加多一個 0 嘅狀態，變成 {−1, 0, +1}，有效位寬 1.71 bits，representational power 大咗，所以 quality 更好（GenEval 0.723 vs binary 嘅 0.671）。

等等，咁點解唔個個都用 ternary？因為 memory 同 bandwidth。Binary 嘅 transformer 係 0.93 GB，ternary 係 1.21 GB——分別只係 300 MB，但喺 iPhone 上面，呢 300 MB 可能就係 fit 唔 fit 嘅界線。仲有 compute：binary GEMM 可以用 XOR + popcount 實現，ternary 雖然都快過 FP16 好多，但 logic 複雜少少。

條 pipeline 點樣塞入 3GB？

呢度係最多人誤解嘅地方。Bonsai 嘅宣稱「0.93 GB」係指 diffusion transformer 部份，唔係成條 pipeline。實際部署仲包括 text encoder（T5 或者 CLIP）同 VAE decoder。成個 Apple Silicon deployment payload 係 3.42 GB（binary）/ 3.88 GB（ternary）。

PrismML 做咗一個好聰明嘅設計決策：text encoder 只喺 prompt encoding 嘅時候用，encode 完就可以 offload 走。所以 mean active memory 細過 total payload 好多。Generate 512x512 嘅時候，binary Bonsai 嘅 mean active memory 係 1.5 GB，ternary 係 1.96 GB。同原版 FLUX.2 Klein 嘅 11.74 GB 比，係 7.8x 同 6x 嘅 reduction。

呢個數字直接解釋咗點解佢行到上 iPhone。iPhone 17 Pro Max 有 8 GB RAM，OS 同其他 app 用咗一半之後，你仲有 3-4 GB 可以用。Ternary Bonsai 嘅 peak memory ~2.4 GB（1024x1024 generation），完全喺 budget 以內。

WebGPU 版本嘅實現又係另一個故事。瀏覽器唔似得 native app 可以自由 control memory，WebGPU 嘅 buffer allocation 有限制，GPU 同 CPU 之間嘅 data transfer 要經 JS bridge。所以 Hugging Face 上嘅 webml-community/bonsai-image-webgpu 用咗 streaming model loading，逐層逐層 download 同 cache 去 GPU，唔係一次過 load 晒成個 model。呢種做法喺 native 開發者眼中好似好浪費 bandwidth，但係喺 browser 嘅 constraints 之下，呢個係唯一可行嘅 path。

Benchmark：犧牲幾多 quality？

Quantization 最怕嘅係「壓完細咗好多但畫出嚟嘅野唔見得人」。Bonsai 嘅 benchmark 數字值得逐個睇。

GenEval（物件組合同 attribute binding）：FLUX.2 Klein 係 0.819，Ternary Bonsai 係 0.723（-12%），Binary Bonsai 係 0.671（-18%）。跌幅明顯，留意到 binary 喺 binding task 上面 drop 得比較多，因為「物件 A 喺物件 B 嘅左邊」呢類 spatial reasoning 對 weight precision 敏感。

但 HPSv3（人類偏好）嘅差距細好多：FLUX.2 Klein 12.84，Ternary 12.22（-5%），Binary 11.15（-13%）。即係一般人望落去，ternary 同 full precision 嘅分別唔明顯。DPG-Bench（prompt following）Ternary 仲做到 0.851 對 0.853，幾乎無分別。

重點係：Bonsai 唔係同 SDXL 或者 SD 1.5 比——佢係同 FLUX.2 Klein 同級嘅 model 比。壓咗 6-8 倍之後，仲保住 88-95% 嘅 performance。相同 memory footprint 嘅 BK-SDM-Small（0.98 GB）只做到 GenEval 0.297、HPSv3 3.05，完全係另一個層次。

呢個 Pareto shift 先係真正嘅 breakthrough。以前你 trade memory 換 quality 嘅 curve 係平滑嘅，而家 PrismML 將條 curve 成個向左推咗一格。你唔使揀「要細 model 定要好 quality」，你可以兩個都要。

對本地 AI 部署意味住乜？

Bonsai Image 4B 唔係第一個 browser-based image gen。之前已經有 Stable Diffusion via WebGPU 嘅 demo，但佢哋全部行 SD 1.5 呢類細 model，quality 有限。Bonsai 做到嘅係將 4B-class diffusion transformer 塞入 browser，而 quality 仲係 SOTA 級數。

對香港開發者嚟講，有幾個好實際嘅 implication。

第一，你嘅 product 可以完全唔使 backend GPU。用戶個 browser 就係 inference server。無需 managing GPU instances，無需 worrying about inference cost per image。每個 generation 嘅 marginal cost 接近零。

第二，privacy 變成 default。用戶嘅 prompt 同生成嘅圖片由頭到尾唔離開佢部機。呢點喺醫療、教育、企業應用上好重要——你唔使再解釋「我哋唔會睇你嘅 data」，因為 technical 上真係睇唔到。

第三，product 設計邏輯要反轉。之前 image gen product 嘅 bottleneck 係 API cost 同 latency，所以你會 design 到用戶 generate 好少次、每張相都珍而重之。如果 generation 係 local、free、近乎 instantaneous，你應該 design 畀用戶不停 generate、不停 iterate，好似用 filter 咁 natural。

具體行動？如果你做緊 AI product，今個星期值得做嘅：去 prismml.com download Bonsai Image Demo（GitHub），睇下部 MacBook 或者 Linux machine 跑到幾快。然後去 Hugging Face 個 WebGPU space 試 browser version。感受一下個 latency 同 quality，再諗下你個 product 有邊啲 flow 可以 localize。另外，留意 PrismML 之前 release 嘅 1-bit Bonsai LLM（8B model 壓到 2.5 GB），好快都會有 WebGPU 版本。

本地 AI 嘅臨界點就快到了。最先感覺到嗰批開發者，會係最快改寫 product 規則嘅人。