Modelpublic

Arm/qwen3-1-7b-base-q4-k-m-llamacpp-vivo-x300

sourceHugging Faceapache-2.0updated 13d agoView on Hugging Face

0likes737downloads

Model Card

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

Qwen3-1.7B-Base, a text generation model, optimized to GGUF (Q4KM) via llama.cpp for Arm-based mobile CPUs with SME2.

Summary

This repository contains an Arm-optimized version of Qwen3-1.7B-Base for text generation. The model is provided as a GGUF file for the llama.cpp runtime, targeting Mobile CPU systems.

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.

The optimized weights use llama.cpp's Q4KM k-quant recipe: a mixed per-component precision rather than a single uniform width. Most attention and feed-forward projections are stored at 4-bit (Q4K), the value projection and FFN-down projection on half of the transformer blocks are stored at 6-bit (Q6K), the tied token-embedding table is stored at 8-bit (Q8_0), and all RMSNorm weights stay at F32. Activations remain in float at runtime — this is weight-only quantization, with no activation calibration step.

Key results

Area	Result
Model format	GGUF (llama.cpp)
Target device class	Mobile CPU
Reference device	vivo X300 (C1-Ultra, C1-Premium, C1-Pro, Android 16 / OriginOS 6)
Primary performance result	34.11 tok/s decode (TTFT 809.12 ms)
Accuracy result	MMLU 61.05% (vs 61.23% baseline)
Size / memory result	1127.98 MB (2.91x smaller than the bf16 baseline)

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
`Qwen__Qwen3-1.7B-Base_llamacpp_optimized.gguf`	Arm-optimized model for deployment
`example.py`	Minimal inference example
`pyproject.toml`	Python dependency spec
`uv.lock`	Locked dependency versions
`.python-version`	Pinned Python release used by uv
`config.yaml`	Model I/O contract used by the example
`benchmarks/`	Benchmark scripts and configuration

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, CPU backend
OS	Android 16 / OriginOS 6
Runtime	llama.cpp
Backend / delegate	ggml CPU_REPACK, compiled with -march=armv8.6-a+dotprod+i8mm
Batch size	1
Precision	Mixed k-quant weights (Q4K / Q6K / Q80 / F32, Q4K_M overall recipe), float activations
Prompt / generation length	128 prompt tokens, 128 generated tokens
Threads	4 CPU threads
Runs	5 warm-up runs, 20 measured runs

Measurement conditions. Each measured run consumes a 128-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 (128-token prompt + 128 generated)	80551.18 ms	4564.02 ms	17.65x faster
TTFT	34330.38 ms	809.12 ms	42.43x faster
Decode throughput	2.77 tok/s	34.11 tok/s	12.31x faster
Model size	3287.65 MB	1127.98 MB	2.91x smaller
Peak memory	3377.73 MB	2311.20 MB	1.46x 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 (0-shot)
Number of samples	13508
Metric(s)	MMLU accuracy (micro)
Evaluation runtime	llama.cpp (via lm-eval harness)

Accuracy results

Metric	Original / baseline	Arm-optimized	Change
MMLU Accuracy (micro)	61.23%	61.05%	-0.18 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 the Hugging Face checkpoint to bf16 reference GGUF via converthftogguf.py, then produced the Q4K_M deliverable via llama-quantize
Quantization	Yes	K-quant Q4KM recipe, weight-only (activations kept in float), guided by an llama-imatrix importance matrix computed over a WikiText-2 calibration corpus; mixed per-component precision (Q4K for most projections, Q6K for some value/FFN-down projections, Q8_0 for the tied embedding table, F32 for RMSNorm weights)
Runtime/backend selection	Yes	llama.cpp / ggml CPU_REPACK kernels, compiled with -march=armv8.6-a+dotprod+i8mm
Graph/runtime compatibility updates	Yes	Performed as part of the llama.cpp GGUF conversion and quantization pipeline (converthfto_gguf.py + llama-quantize)
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

A representative evaluation target (vivo X300, Android) cannot run Python or uv, so example.py is validated on a realistic Linux development host instead: aarch64 Ubuntu 24.04 (glibc 2.39), Python 3.12. llama-cpp-python only ships as a source distribution, so uv sync compiles it locally with CMake, Ninja, and a C/C++ toolchain (cmake, ninja-build, build-essential on Debian/Ubuntu-family hosts); no target-specific compile flags such as -march=armv8.6-a+dotprod+i8mm are applied on this host, so it is a functional check of the inference flow rather than a reproduction of the vivo X300 benchmark numbers above.

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.

Install dependencies

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

bash

uv python install
uv sync --frozen

Run the example

bash

uv run example.py

Expected input

Property	Value
Input shape	[1, 2048]
Input type	int32
Input range	Token ids over a vocabulary of 151936
Preprocessing	Byte-pair-encoding tokenization (qwen2 pre-tokenizer, embedded in the GGUF), truncated to a max length of 2048 (trained context length is 32768); no chat template is applied, since this is a base (non-instruct) model and the prompt is fed as plain text continuation

Expected output

Property	Value
Output shape	[1, seq_len, 151936]
Output type	Per-token logits over the vocabulary (last-position logits by default)
Postprocessing	Greedy (argmax) decoding by default, with the KV cache kept internal to llama.cpp and the sampled token fed back one at a time; generation stops at eostokenid 151643 or when maxnewtokens is reached; detokenization uses the byte-pair-encoding tokenizer embedded in the GGUF

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 (13508 items, 0-shot) and may not generalize to all domains; this is not the full 14042-item test set and not the published 5-shot protocol, so the figures are not directly comparable to Qwen's published MMLU score.
—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 is a base, non-instruction-tuned checkpoint — it is not suited to chat or instruction-following use without further tuning.
—Greedy decoding (temperature=0.0) is only deterministic within a given host and thread count: llama.cpp's multi-threaded matrix-multiply kernels sum in a different order on different CPUs/thread counts, so floating-point rounding differs and can flip the top logit late in a long completion. predictions.json was captured on a single reference run; a run on another host (including the development host above) may diverge from it after the first several tokens while remaining a fluent, on-topic continuation.
—The Python/uv example targets AWS Graviton on Ubuntu arm64. It establishes runtime compatibility only; no Graviton latency or memory benchmark is reported here.
—This repository is not a replacement for the original model documentation.

Additional notes

The importance matrix used to guide quantization was computed over 398 chunks of plain text decoded from the WikiText-2 calibration set (196 imatrix entries recorded in the GGUF). The Q4K/Q6K/Q80/F32 tensor mix (168 tensors in Q4K, 28 in Q6K, 1 in Q80, 113 in F32) is llama.cpp's stock Q4KM allocation, not a custom per-layer override — no layers were selectively skipped from quantization. Latency and memory were measured with a single synthetic fixed-length workload (128-token prompt, 128 generated tokens, 4 threads, 5 warm-up plus 20 measured repetitions), not a distribution of real prompts. The bf16 baseline GGUF has no fast ARM kernel path on this CPU, so the ratio between the baseline and optimized throughput columns is not a realistic float-to-int speedup on its own — treat the Q4KM absolutes as the meaningful numbers.

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.