All stories
webyIQ Ecosystem Community reports

620 tokens a second in Chrome? webyIQ puts a tiny Qwen model on your GPU

The author's model-specific WebGPU engine pairs a browser chat arena with a local DOM agent, while its headline speed remains a hardware-specific claim.

By AITrending2 min read
Sources (4)

Why now November 2 commits added hosted weights and comparison demos; the author introduced the project in an English LocalLLaMA post on November 3 at 14:56 UTC.
Author-published webyIQ chat arena screenshot showing two engines answering a coffee-shop naming prompt, with displayed generation rates of 506.7 and 27.0 tokens per second.
Author-published chat-arena session. Its displayed 506.7 tok/s result is a separate demonstration, not the headline 620 tok/s run or an AITrending reproduction. Source: webyIQ / rtx527896828

A small language model that chats inside your browser and can drive a web page is webyIQ’s pitch. Its author reports Qwen3.5-2B generation at 620 tokens per second on an RTX 5080 in Chrome 156, using speculative decoding. The same headline table lists 417 tokens per second without speculation.

That is an author-run measurement, not an AITrending benchmark or a universal browser speed. The project takes a deliberately narrow route: Rust compiled to WebAssembly, hand-written WebGPU kernels and model-specific execution for Qwen3.5-2B and MiniCPM5-2B.

Try the chat, then examine the agent

The hosted demo downloads converted weights from Hugging Face and runs inference on the user’s GPU. The Qwen model card describes about 1.10 GiB of weights in a custom format; these are not drop-in transformers or llama.cpp checkpoints. No paid inference API credential is documented for the hosted-weight route.

The chat arena runs the two engines sequentially to avoid sharing the GPU. A separate DOM-agent demonstration reads page text and numbered controls, then generates actions such as search, click and type. Its framed-page version needs the project’s local proxy; a Chrome or Edge side-panel extension operates the active tab through browser scripting instead.

Building the unpacked extension requires the documented Rust/WebAssembly and Node tooling. It requests side-panel, scripting and storage permissions plus host access to all sites so it can read and operate pages. This is a standalone prototype, rather than a plugin for an existing coding harness.

The comparison needs its context

The author’s headline table compares webyIQ with WebLLM 0.2.87 and transformers.js 4.3 using different runtime-specific quantized formats. A Reddit commenter questions benchmark fairness and the very low first-token latency. That objection is a community challenge, not proof that the measurement is false.

The README also contains separate protocol-specific results, including a Qwen speculative-decoding run around 581 tokens per second. Those figures should not be treated as interchangeable runs. The published screenshot illustrates another author-run chat session, rather than independently validating the headline number.

The practical hook is a testable browser inference and agent workflow. The author calls it a research prototype tested on Windows with Chrome and Edge 156; Safari and mobile are untested, and documented agent failures include choosing the wrong Hacker News comments link.

Related reading