GLB 檔太大，先看貼圖，再看幾何。開發團隊在 3D 配置器專案遇到的大檔，多半卡在貼圖。另一個常被漏掉的前提是：檔案大小與 GPU 佔用是兩個不同的數字。看檔案大小的稽核，抓不到壓縮後只剩幾 KB、解碼後卻佔滿整張解析度的貼圖。
glTF 是 Khronos Group 訂定的開放、可互通的 3D 資產傳輸格式（Khronos Group，2021）。GLB 檔屬於這套格式，下文談的貼圖壓縮與幾何壓縮，也都是這套格式的擴充規格。
先看貼圖的原因
貼圖的份量來自像素量。邊長從 4096 降到 1024，像素變成十六分之一，GPU 記憶體也照這個比例縮。一批 14 張的主體顏色貼圖，降到 1024 之後，GPU 佔用從約 160 MB 降到約 10 MB。這 14 張裡有 12 張本來就是純色，另外 2 張是雙色，降階再升回全解析度，與原圖的差為 0，畫面沒有損失。
純色貼圖降階不損畫質，所以3D 模型瘦身先從貼圖下手，順序如下。
- 把每張貼圖解碼成全解析度，逐通道計算標準差，找出純色貼圖。
- 純色貼圖縮成 4×4，其餘貼圖轉成 KTX2。
- 壓完把檔案解碼回來，與原值全量比對。
- 最後才看幾何，也就是壓縮格式的選擇。
- 原始貼圖約 160 MB14 張 4096，其中 12 張是純色
- 降階時丟掉的像素約 150 MB畫面沒有損失
- 降到 1024約 10 MB雙色貼圖升回全解析度，與原圖的差為 0
- 解碼回來全量比對約 10 MB14 張逐張驗，不抽樣
同一批 14 張主體顏色貼圖，數字為約略值。
檔案大小與 GPU 佔用是兩件事
貼圖壓縮後的檔案大小，取決於圖的內容與壓縮方式；貼圖在 GPU 上佔多少記憶體，取決於解析度。兩者互不牽動，所以一張純色貼圖可以同時是最小的檔案，與最大的浪費。
曾處理過一批模型：匯出時，純色材質也被輸出成 2048² 的貼圖，同一張圖重複放在 8 支 GLB 裡。這張圖壓縮後只剩約 1 KB，任何看檔案大小的稽核都不會標記；8 支 GLB 合計卻白佔約 43 MB 的 GPU。
- 約 1 KB純色貼圖，原為 2048²白佔 GPU約 43 MB
- 檔案大小不變同一張縮成 4×4 之後畫面不變近乎零
同一張 2048² 純色貼圖放進 8 支 GLB，GPU 佔用為 8 支合計。縮成 4×4 是就地改寫，每支 GLB 的檔案大小不變。
判定量因此不能是檔案大小，要用解碼後的標準差。做法是把貼圖解碼成全解析度，逐通道（含 alpha）計算標準差。標準差為 0 就是純色，縮成 4×4，畫面不變。反過來，檔案小也不代表可以縮：一張貼花貼圖的檔案只有約 110 KB，標準差卻有幾十，是有內容的真圖，不能動。
解碼這一步有個容易踩的地方：只能讀 basisu 轉出的 RGBA32 版本。RGBA4444 那一份會把 18 量化成 17，純色整片差一階。
就地改貼圖時，不能讓幾何被碰到。做法是在位元組層級修改：新圖寫回原本的 bufferView，只改長度，檔案大小不變，其餘位元組不動。改用圖形庫整檔讀寫，幾何會被重新編碼；三支 GLB 這樣處理後，檔案大小變成原本的約 1.4 至 2.9 倍。
LIDROP 的 3D 配置器把這一道判定放進上架流程：確認為純色的貼圖縮成 4×4，畫面不變，每台車的首屏少了約 16 MB 的 GPU 佔用。
貼圖要壓成什麼
有內容的貼圖，壓成 KTX2 搭配 Basis Universal。KTX v2 容器搭配 Basis Universal 超壓縮，檔案以通用格式傳輸，引擎再轉碼成平台支援的區塊壓縮格式（Callow 等，2020）。轉碼之後，GPU 佔用仍由解析度決定，所以下載量與 GPU 佔用要分開量。
MDN 文件的建議把貼圖記憶體列為獨立的一類，內容包括只配置需要的 mipmap，以及使用 GPU 壓縮格式（MDN Web Docs，2026）。
Basis Universal 有低位元率的 ETC1S 與高品質的 UASTC 兩種編碼。ETC1S 檔案小，但個別貼圖的顏色可能被壓向灰；同一份來源改用 UASTC 重編就能還原，每張只多約 27 至 29 KB。含透明的貼圖一律走 UASTC，因為 ETC1S 把 alpha 編成另一張切片，鏤空邊緣會破碎。
- 解碼成全解析度讀 RGBA32，逐通道含 alpha
- 計算標準差
- 標準差為 0縮成 4×4純色，畫面不變
- 標準差大，含透明高品質 UASTC鏤空邊緣才不會破碎
- 標準差大，不含透明低位元率 ETC1S解碼比對，發灰的改 UASTC 重編
幾何：一句話帶過
幾何另有兩套壓縮規格：Draco（Zhang 等，2013–2017），以及以快速解碼為重點的 meshopt（Kapoulkine 等，EXT_meshopt_compression）。
兩者的選擇隨網速反轉：約 46 Mbps 以下 draco 較快，以上 meshopt 較快。完整比較已寫在3D 網頁效能工程，這裡不重複。
不能壓的件：蒙皮件
蒙皮件，也就是跟著骨架變形的網格，不能硬壓。量化是把頂點屬性從原本常用的 32 位元浮點數，改用較小的元件型別，以較低精度換取記憶體與頻寬（Kapoulkine 等，2018–2020）。建模端交付的檔案若已經壓縮過，管線再用預設位元數壓一次，就是二次量化：法線被推到另一組格點上，蒙皮件出現可見的變形，看起來像是沒有綁骨架。
處理方式是蒙皮件永不做二次量化，直接提供原檔，壓縮腳本把這類件排除。驗證蒙皮件也不能看網格的包圍盒，那是攤平的綁定姿勢，要量骨頭的世界座標。
壓完一定要驗
轉檔的驗證，是把壓縮後的檔案解碼回來，與原值比對，而且要全量。壓縮後顏色發灰時，先比來源與解碼值，不要先怪素材。
常見的例子：主體顏色貼圖改成 GPU 壓縮格式後看起來發灰，直覺會判斷是資產壞了，打算請建模師重出。全解析度解碼來源圖與壓縮檔、比平均色之後，會發現是 ETC1S 把個別貼圖的端點壓向灰；換成 UASTC、同一份來源重編就還原。同批其餘顏色用 ETC1S 完全正常，所以這是逐張的現象。
- 解碼要在乾淨、獨立的資料夾做，並取最大的 mip 層級。用檔名 glob 抓檔，會抓到錯的層級，得到假數字。
- 解壓指令會吐出多個變體。餵成 alpha 那一份，整批顏色會全驗成白灰。
不要抽樣：只抽驗少數幾張，剛好會漏掉出問題的那一張。全量比對只是一支迴圈，不需要抽樣。
規格驗證是另一道檢查。glTF-Validator 依 glTF 2.0 規格檢查 JSON、GLB、緩衝區與貼圖，提供瀏覽器版、命令列與 npm 套件（Khronos Group，glTF-Validator）。驗證工具回答的是檔案合不合規格；顏色有沒有走樣，要拿來源圖對照。
上架檔還要能從來源重現：每支檔案記錄來源、產出與參數，不直接複製上架。重壓前先比對線上版與原始檔的材質旗標，從原檔重壓會洗掉手動修好的材質混合模式。進件階段的逐項排除，見3D 模型進件驗收。
解碼器自架，不依賴境外 CDN
Draco 與 Basis 的解碼器，預設從公開 CDN 載入。在受限網路或封鎖地區，解碼器載不到，3D 就整個載入不了。有兩個專案採用自架解碼器，放在自己的伺服器，不再依賴境外 CDN。
不適合的情況
- 貼圖本身是有內容的真圖：標準差大，不能縮成 4×4，只剩壓縮格式與解析度的取捨，要逐張看畫面決定。
- 只有壓縮過的檔、沒有建模端的原始檔：蒙皮件再壓一次就會變形，先取回原始檔。
- 量過之後貼圖的佔比不高：問題在幾何，改看3D 網頁效能工程的流程與壓縮格式選擇。
- 檔案大小與 GPU 佔用都已在目標裝置的預算內：不需要為了縮小而處理，每多一道處理，就多一道要驗證的風險。
下一步：先準備什麼
要判斷這份 GLB 該從哪裡下手，先準備三樣資料：要上架的 GLB 與建模端的原始檔，目標裝置與網路條件，以及目前較在意的是首屏下載量還是手機記憶體。與建模廠商對齊規格時，可參考 Khronos 為電商產品 3D 內容訂定的資產製作規範（Khronos Group 3D Commerce，2025），本文沒有引用其中的建模細則。資料備齊後，可以聯絡開發團隊討論。
