Arm/qwen3-1-7b-base-onnx-genai-int4-kquantlast-vivo-x300

Qwen3-1.7B-Base optimized for Arm-based mobile CPUs with SME2

Qwen3-1.7B-Base text generation optimized as a GPTQ INT4-weight ONNX model for Arm-based mobile CPUs with SME2.

Summary

This repository contains an Arm-optimized version of Qwen/Qwen3-1.7B-Base for text generation. The model is provided in ONNX (ONNX Runtime), targeting Mobile CPU systems.

The transformer body carries GPTQ INT4 weights (group 32, asymmetric), while the LM head and the tied token-embedding table are kept at INT8 (group 32). Activations are quantized per token dynamically to INT8 at kernel time, so no offline activation calibration is required.

This version is intended to demonstrate efficient inference on Arm-based platforms while preserving the original model's intended behavior. Arm has evaluated this model on MMLU and measured performance on a representative evaluation target.

Key results

Area	Result
Model format	ONNX
Target device class	Mobile CPU
Reference device	vivo X300 (C1-Ultra, C1-Premium, C1-Pro, Android 16 / OriginOS 6)
Primary performance result	21.66 tokens/sec (937.14 ms TTFT)
Accuracy result	MMLU 60.14% (5-shot)
Size / memory result	1221.01 MB, 5.39x smaller than FP32; 1941.80 MB peak memory
Precision	INT4 weights (transformer body), INT8 LM head and tied token embeddings, dynamic INT8 activations

Original model

Field	Value
Original model	Qwen/Qwen3-1.7B-Base
Original source	Hugging Face
Original developer	Alibaba Cloud (Qwen team)
Original model card	Qwen/Qwen3-1.7B-Base
Original license	Apache-2.0

Model files

File	Description
model.onnx	Arm-optimized model graph for deployment
model.onnx.data	External weight data for model.onnx; both files must sit in the same directory
example.py	Minimal inference example
pyproject.toml	Pinned runtime dependencies for example.py, resolved with uv
uv.lock	Locked dependency resolution for pyproject.toml
.python-version	Python release the example was tested with
config.yaml	Model I/O contract used by the example
genai_config.json	ONNX Runtime GenAI generation configuration
tokenizer.json	Tokenizer vocabulary and merges
tokenizer_config.json	Tokenizer configuration
sample_input.txt	Example input
predictions.json	Example output produced by the optimized model
benchmarks/	FP32 baseline and Arm-optimized benchmark records

Performance

Performance was measured on the reference configuration below. Results are intended to make the optimization reproducible but do not guarantee identical performance on every Arm-based system.

Reference configuration

Field	Value
Device / platform	vivo X300
CPU / accelerator	C1-Ultra, C1-Premium, C1-Pro, aarch64, CPU
OS	android — Android 16 / OriginOS 6
Runtime	onnxruntime 1.26.0
Backend / delegate	MLAS, KleidiAI
Batch size	1
Precision	GPTQ INT4 weights (group 32, asymmetric) on the transformer body; INT8 group 32 LM head; tied INT8 token embeddings; per-token dynamic INT8 activations
Runs	5 warmup + 20 measured

Measurement conditions. Each measured run consumes a 127-token prompt and generates 128 tokens, using 4 CPU threads, 5 warm-up runs and 20 measured runs. Each run starts only once Android reports thermal status 0 (NONE), after a 30 s settle. The device is set to fixed performance mode, which is the official recommendation.

Performance results

Metric	Original / baseline	Arm-optimized	Improvement
p50 latency	27164.53 ms	6858.63 ms	3.96x
p90 latency	27344.85 ms	7151.49 ms	3.82x
p99 latency	27498.80 ms	7428.93 ms	3.70x
Time to first token	1253.34 ms	937.14 ms	1.34x
Throughput	4.92 tokens/sec	21.66 tokens/sec	4.40x
Model load time	15515.55 ms	2602.59 ms	5.96x
Model size	6579.74 MB	1221.01 MB	5.39x smaller
Peak memory	6843.79 MB	1941.80 MB	3.52x less
Average memory	6761.51 MB	1863.09 MB	3.63x less

Accuracy

Accuracy was evaluated using the same preprocessing, input resolution, and evaluation protocol described below. Where possible, the optimized model is compared against the original model under the same evaluation conditions.

Evaluation setup

Field	Value
Dataset	MMLU
Split	test, 5-shot
Number of samples	14042
Metric(s)	MMLU accuracy
Evaluation runtime	onnxruntime

Accuracy results

Metric	Original / baseline	Arm-optimized	Change
MMLU accuracy	62.68%	60.14%	-2.54 pp

Accuracy was measured using the evaluation setup described above. Users should re-evaluate the model on their own data before production use.

Arm optimization approach

Arm optimized this model for efficient inference on Arm-based platforms using a hardware-aware conversion and validation flow.

For this release, Arm used:

Optimization area	Applied?	Notes
Model conversion	Yes	Converted to ONNX for onnxruntime
Quantization	Yes	GPTQ, INT4 weights (group 32, asymmetric) on the transformer body; INT8 group 32 LM head; tied INT8 token embeddings; per-token dynamic INT8 activations; calibrated on 512 random WikiText2 samples
Runtime/backend selection	Yes	MLAS, KleidiAI
Graph/runtime compatibility updates	Yes	Fused-attention ONNX graph with an explicit key-value cache contract
Accuracy validation	Yes	Compared against the original model or published baseline
Performance validation	Yes	Measured on the reference Arm platform

The goal of this process is to improve deployment characteristics such as latency, memory use, model size, and runtime compatibility while preserving the model's intended behavior. Detailed conversion scripts, calibration configuration, or backend-specific implementation details may be provided separately where appropriate.

Using this model

Install dependencies

Dependencies are declared in pyproject.toml, which ships with this repository. Resolve and install them into a local virtual environment with uv:

uv python install
uv sync --frozen

The example was tested with Python 3.14 and ONNX Runtime 1.26.0. ONNX Runtime is pinned to 1.26.0 — the version used for the benchmark and accuracy results above. Later ONNX Runtime releases change the INT4 MatMulNBits kernel numerics enough to shift the greedy argmax of this model, so predictions.json only reproduces exactly on 1.26.0. No native Ubuntu or Raspbian packages are required beyond Python and uv.

Both files are required, and model.onnx.data must sit next to model.onnx — ONNX Runtime resolves the external weight data by relative path when the graph is loaded.

Run the example

uv run example.py

The ordinary command prints the prompt and the generated completion and does not overwrite the committed expected results. To write new output files, pass an explicit directory:

uv run example.py --output-dir outputs

That writes sample_input.txt and predictions.json into the given directory.

Note: The Python/uv example runs on AWS Graviton (Ubuntu arm64) to confirm runtime compatibility only, and is intended as a guideline for building an equivalent run script on Mobile CPU systems.

Environment validation

A representative evaluation target for the published results is a vivo X300, an Android phone that cannot host a Python and uv environment. The example, its lock file, and the expected result were therefore validated on an AWS Graviton G4 (Neoverse-V2, aarch64, Ubuntu 24.04.4 LTS, glibc 2.39) — the same Arm aarch64 CPU family and the same ONNX Runtime CPU execution provider (MLAS with KleidiAI kernels). uv sync --frozen followed by uv run example.py reproduces the committed predictions.json exactly there. The latency, throughput, and memory figures in this card come from the vivo X300 and were not reproduced by that run.

Expected input

Property	Value
Input shape	[1, 4096]
Input type	int64
Input range	N/A
Preprocessing	Byte-pair-encoding tokenization (vocabulary size 151936) into discrete input_ids plus an attention_mask of the same shape, truncated or padded to 4096 tokens; no chat template is applied because this is a base (non-instruct) checkpoint

Expected output

Property	Value
Output shape	[1, seq_len, 151936]
Output type	Per-token logits over the vocabulary; generation proceeds one token at a time using a key-value cache
Postprocessing	Greedy (argmax) decoding by default, stopping at eos_token_id or when max_new_tokens is reached, then byte-pair-encoding detokenization

Intended use

This model is intended for developers evaluating text-generation workloads on Arm-based platforms. It is suitable as a reference implementation for benchmarking, prototyping, and integration exploration.

Limitations

• Performance depends on the target device, runtime version, backend/delegate support, memory configuration, and system load.
• Accuracy was evaluated on MMLU test and may not generalize to all domains.
• This release preserves the original model's intended task and behavior, but users should validate it for their own application, data, and deployment environment.
• This repository is not a replacement for the original model documentation.

Additional notes

• The LM head and the tied token-embedding table were kept at a higher precision than the transformer body — that is, skipped from INT4 quantization — to keep accuracy within acceptable ranges. This is the k_quant_last recipe: the embedding table shares the LM head's scale and zero-point via GatherBlockQuantized (block size 32).
• INT4 body weights are stored in a MatMulNBits topology with accuracy_level=4. Activations are quantized per token at kernel time, so no offline activation calibration step is needed.
• The exported graph uses fused attention with an explicit key-value cache contract, so the runtime drives autoregressive decode one token at a time rather than re-running the full prompt.
• This is a base (non-instruction-tuned) checkpoint and is not intended for chat or instruction-following use.
• Accuracy was measured over the full MMLU test set; the latency and memory figures come from a single fixed prompt of roughly 127 tokens with 128 generated tokens per run.

About this version

Original Model: Qwen/Qwen3-1.7B-Base by Alibaba Cloud (Qwen team) - Repository

Optimization/conversion: Arm-Optimized version for execution on Arm-based platforms.

Converted/optimized by: Arm

License: The Original Model and the Optimized Model are subject to Apache-2.0.

This repository contains a converted or optimized version of the Original Model (the “Optimized Model”). The Original Model has been converted or optimized as described above for execution on Arm-based platforms.

No retraining or fine-tuning of the Original Model was performed as part of the conversion or optimization. The conversion or optimization was not intended to change the Original Model’s behavior or intended use.

Original Model and Documentation

For information about the Original Model, including its development, training data, intended uses, limitations and other relevant information, please refer to the Original Model repository. Information in that repository was provided by the original developer or other third parties and, unless expressly stated otherwise, has not been independently verified by Arm.

Licenses and Third-Party Terms

Use of the Original Model and the Optimized Model is subject to the applicable licenses, usage restrictions and other terms identified above and in the relevant repositories. Publication of the Optimized Model does not grant any rights beyond those provided under the applicable license terms.

You are responsible for reviewing those terms and ensuring that your use of the Original Model and the Optimized Model is permitted.

Purpose of this Release

The Optimized Model is provided as a reference implementation to demonstrate and evaluate execution and performance on Arm-based systems. It is not a production-ready or supported solution.

Arm’s publication of the Optimized Model does not constitute an endorsement or certification of the Original Model or a representation that the Optimized Model is suitable for production use or any particular purpose.

To the fullest extent permitted by applicable law (i) the Optimized Model is provided “as is.” Arm makes no representations or warranties that the Original Model, the Optimized Model or their outputs are accurate, safe, secure, non-infringing, legally compliant, suitable for production use or fit for any particular purpose; and (ii) Arm will not be liable for any loss or damage arising from or in connection with the Optimized Model, its use or its outputs.

You are responsible for independently evaluating the Optimized Model, its outputs and its suitability for your intended use, including compliance with applicable legal, regulatory, safety and security requirements.

Arm does not commit to provide ongoing support, maintenance or updates for the Optimized Model. Any use of or reliance on the Optimized Model or its outputs is at your own risk.