Vivek Bharti — WebGPU: Unleashing Graphics Power in the Browser / HolyJS26AU

Main topic

• WebGPU as a browser-exposed GPU API: After 2023, WebGPU is presented as a newer alternative to WebGL for graphics-intensive work, enabling access to GPU compute from the browser.
• Why it matters for AI in the browser: The speaker argues that you can run AI models locally in the browser (without third-party/cloud inference calls like ChatGPT) by leveraging WebGPU.

Technical comparison: WebGL vs WebGPU

WebGL approach (conceptually)

• Data is converted into textures
• Computation happens via shaders (e.g., fragment shaders)
• Pixel/numeric results are converted back into an output image or raw data

WebGPU approach

• Instead of a texture-based pipeline, WebGPU can use storage buffers
• Compute shaders perform math directly on numeric data in buffers
• Results are then read back from buffers to obtain answers

Core claimed improvement

• Direct buffer computation in WebGPU is positioned as more suitable for heavy computation than WebGL’s texture/shader workflow.

Demo / tutorial focus (AI in-browser, no external inference calls)

What the demo does

• An in-browser application loads an AI model and classifies an input image.

Network behavior emphasized

• The speaker opens the browser Network tab to verify that the app does not send images to a third-party server.
• The browser performs only model download (example mentioned: ~88 MB), then runs inference locally.

Model delivery detail

• The demo downloads a WebAssembly/binary component (subtitles describe it as “looks like a binary file”) tied to using a Hugging Face model.
• Mentioned model/version: DataFormer 3.8.1 (as stated in subtitles).

Production relevance (next use case under work)

• The current demo is described as a proof/example of “AI model in browser.”
• The speaker is working on a heavier use case: a plugin that translates website content locally using an AI model without calling external translation APIs.
• Motivation: tools like Google Translate may not translate certain model/text content embedded on websites, and the goal is local translation that works within the site context.

Practical limitations discussed

• First-run latency: Loading the model into the browser takes significant time initially; subsequent runs are faster because the model/task is reused.
• Model size / feasibility:
  • For image generation, the speaker claims a much larger model size is required (~2–3 GB) and implies that this is not feasible for the demo/talk.
• Overall constraint theme: local browser inference is limited by compute/memory constraints and model size.

Candidate AI tasks mentioned as possible with this approach

• Image classification (the demo)
• Website translation (in-progress plugin concept)
• Potential accessibility/personalization features:
  • Describing content (e.g., for visually impaired users)
  • Intent detection from user text, including classifying emotional state (e.g., happy/sad/mindset)
• Image generation was discussed as possible, but limited by model size.

Emphasis from the Q&A / conference strategy

• The speaker’s goal is framed as raising awareness of WebGPU and demonstrating that it enables GPU/compute-based AI in browsers.
• The program committee prefers real production cases (already shipped and in use), not just inspirational prototypes.
• The committee expresses skepticism that “AI in browser” is truly production-ready at scale versus server-based large models.

Key points about production readiness (as raised in Q&A)

• The speaker admits he does not yet have a fully production-ready AI-in-browser use case at the time.
• The committee requests:
  • Evidence of an already shipped/live project using WebGPU for AI (or at least a concrete deployed production example).
• A related question: whether AI-in-browser must be combined with known WebGPU production usages (e.g., Figma or Google Sheets use WebGPU but not necessarily for AI).

Summary of the outcome: the demo demonstrates feasibility and sparks interest, but the Q&A highlights the gap between demos and scalable, production-ready deployments.

Main speakers / sources

• Speaker: Vivek Bharti
  • SD3 Software Developer at Expedia
  • Works on the hotel detail page front/back end
  • Also learning iOS
• Model source mentioned: Hugging Face (models downloaded for local inference)
• Technical components mentioned: WebGPU and WebAssembly (no additional named creators beyond the Hugging Face reference and browser GPU API context)