{"id":15173,"date":"2026-10-01T03:37:19","date_gmt":"2026-10-01T03:37:19","guid":{"rendered":"https:\/\/playgama.com\/blog\/?p=15173"},"modified":"2026-10-01T03:37:19","modified_gmt":"2026-10-01T03:37:19","slug":"what-model-file-sizes-are-practical-for-in-browser-client-si","status":"publish","type":"post","link":"https:\/\/playgama.com\/blog\/business-faqs\/what-model-file-sizes-are-practical-for-in-browser-client-si\/","title":{"rendered":"What model file sizes are practical for in-browser client-side execution?"},"content":{"rendered":"

A few hundred KB to a couple hundred MB loads acceptably in a browser game if you cache it; multi-GB checkpoints (full diffusion models, large LLMs) are impractical client-side and should run server-side instead, since mobile browsers and iframed portal pages have tight memory and load-time budgets.<\/strong><\/p>\n

At a glance<\/h2>\n\n\n\n\n\n\n\n
Fact<\/th>\nValue<\/th>\nSource<\/th>\n<\/tr>\n<\/thead>\n
LoRA adapter file size<\/td>\na couple hundred MB<\/td>\nhuggingface.co<\/a><\/td>\n<\/tr>\n
Textual inversion file size<\/td>\na few KB<\/td>\nhuggingface.co<\/a><\/td>\n<\/tr>\n
DreamBooth full checkpoint size<\/td>\na few GB<\/td>\nhuggingface.co<\/a><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

For a browser game, treat anything from a few hundred KB up to a couple hundred MB as workable client-side; treat multi-gigabyte checkpoints as a server-side job, not something you ship to a player’s browser. The size difference is real: a textual-inversion file is a few KB<\/a>, a LoRA adapter is typically a couple hundred MB<\/a>, and a full DreamBooth checkpoint runs to a few GBs<\/a> – the last one is not a browser download for a casual web game.<\/p>\n

If you build your web game using an AI coding agent like Cursor or Claude Code, you can connect it to the Playgama MCP<\/a> server to upload builds and publish a playable sandbox directly from your workspace.<\/p>\n

For small in-browser inference, Transformers.js runs ONNX models via ONNX Runtime Web<\/a>, CPU\/WASM by default, WebGPU where available (in supported browsers). Because downloads can be slow, ONNX Runtime Web’s own docs suggest caching the model in IndexedDB so it isn’t fetched on every page refresh – essential if you’re hosted in an iframe on a portal and the page reloads often. If the model generates heavier assets (3D, images), generate them server-side and have the browser fetch only the result file – Tripo3D’s API returns a GLB model URL from a generation job rather than shipping a generator model to the client.<\/p>\n

What breaks it on a real portal<\/h2>\n