Spark-X2.6-1.7B is the smaller model of XHToken's Spark-X2.6 series, aimed at on-device agents: tool use, coding and long context, with a thinking budget that can be set to high, low or off. This build packages the official INT4 checkpoint as ONNX for onnxruntime-web. The model runs inside a browser tab, and what you type stays on your machine.

How Spark-X2.6-1.7B compares

XHToken reports these results for Spark-X2.6-1.7B against open models of similar size, all with thinking on, with their Spark-X2.6-4B as a reference. Across 30 benchmarks it averages 49.6, ahead of MiniCPM5-2B (46.9) and well ahead of Qwen3.5-2B (22.0) and Gemma4-E2B (22.5). It leads on agent and coding work such as web browsing, MCP tool use and software engineering; MiniCPM5-2B is ahead on competition math, BFCL-V4, AA-LCR and GPQA.

All 30 benchmarks

The browser build scores the same

A different runtime and 4-bit weights can change a model's answers, so the browser build was tested against the original model in transformers: same prompts, same chat template, greedy decoding, thinking off. Every browser number comes from the actual web page, run in headless Chrome.

The browser build matches the official INT4 checkpoint on all three. On GSM8K the two disagree on 38 and 38 problems in the two directions (McNemar p = 1.00); on BFCL on 4 and 4 cases (p = 1.00). At the level of individual tokens, the build adds a mean KL divergence of 0.00085 on top of the INT4 quantization, and 30 minutes of back-to-back generation produced no errors and no slowdown.

The 4-bit weights themselves cost this model more than they cost the 4B: the official INT4 checkpoint scores 24 points lower on BFCL function calling and 3 points lower on GSM8K than the original bf16 model, mostly because it answers in text more often where the original calls a tool. The browser build reproduces the INT4 checkpoint, including that.

Speed

On a desktop GPU the model generates about 105 tokens per second and starts answering a short prompt in 49 ms. Generation keeps that pace as the conversation grows: 107 tokens per second at 16,000 tokens of context. Long prompts take longer to read before the first token: 618 ms for 2,300 tokens and 5.9 s for 16,000.

Get started

The model is a folder of static files and the loader is a few JavaScript modules, with no build step and no server code.

1. Chat in the browser

   Open the chat in desktop Chrome or Edge. The model downloads once (1.21 GB) and loads from the browser cache afterwards.

2. Run it locally

   Serve the app from a clone. It loads the model from Hugging Face unless a local build exists.

   git clone https://github.com/mohdmahmodi/Spark-X2.6-1.7B-onnx-webgpu
   cd Spark-X2.6-1.7B-onnx-webgpu
   npm install
   npm run serve

3. Use it in your own app

   Copy web/lib/ and the import map from web/index.html. generate streams text and accepts temperature, maxNewTokens, effort, tools and an abort signal.

   import { loadSpark } from "./lib/spark.js";
   
   const spark = await loadSpark({
     base: "https://huggingface.co/mohdmahmodi/Spark-X2.6-1.7B-ONNX-WebGPU/resolve/main",
   });
   
   const messages = [{ role: "user", content: "Hello!" }];
   for await (const text of spark.generate(messages, { thinking: false })) {
     output.textContent += text;
   }

4. Or use Transformers.js

   The same files load in Transformers.js 4.3 with dtype: "q4f16", with identical output. The loader above is faster at long context, since it keeps the KV cache in one preallocated buffer.

   import { pipeline } from "@huggingface/transformers";
   
   const generator = await pipeline("text-generation", "mohdmahmodi/Spark-X2.6-1.7B-ONNX-WebGPU", { device: "webgpu", dtype: "q4f16" });
   const out = await generator([{ role: "user", content: "Hello!" }], {
     max_new_tokens: 256, tokenizer_encode_kwargs: { enable_thinking: false },
   });
   console.log(out[0].generated_text.at(-1).content);

How it is built

The export writes the ONNX graph operator by operator from the checkpoint, using the fused kernels onnxruntime-web ships for WebGPU: grouped-query attention with a 512-token sliding window on 21 of the 28 layers, fused RMSNorm, and 4-bit matrix multiplies. The weights are XHToken's own INT4 codes, repacked without change, so the browser build runs the same quantized model the official checkpoint does. Input tokens are looked up in the int8 table of the output layer, which saves a 512 MB download and measures as lossless.

The KV cache stays on the GPU in one buffer per layer, and a follow-up message reuses the cached conversation instead of reading it again. The source includes the export, the loader, the chat app and the full validation suite.

Limitations

• It needs WebGPU on a desktop browser and about 1.5 GB of free GPU memory at 4k tokens of context. The default WebGPU buffer limits are enough.
• The browser's WebAssembly (CPU) backend is too slow to be useful: it runs a compatible export correctly, but at about 1.5 tokens per second, because its 4-bit matrix multiplies have no fast kernel.
• The official 4-bit weights score lower than the original model on function calling and math, and this build inherits that.
• Testing so far covers Windows with an NVIDIA RTX 3090 Ti. macOS, Android and other GPUs are untested.
• The comparison with other models is XHToken's, measured on the original model with thinking on. It was not re-run for this build. The validation report covers what was.