Modelpublic

Arm/qwen3-5-0-8b-q4-k-m-llamacpp-vivo-x300

sourceHugging Faceapache-2.0updated 20d agoView on Hugging Face

0likes831downloads

Model Card

Qwen3.5-0.8B optimized for Arm-based mobile CPUs with SME2

Qwen3.5-0.8B text generation, quantized to Q4KM GGUF for the llama.cpp runtime on Arm-based mobile CPUs with SME2.

Summary

This repository contains an Arm-optimized version of Qwen/Qwen3.5-0.8B for text generation. The model is provided as a GGUF (.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-Redux 2.0 and measured performance on a representative evaluation target.

The upstream checkpoint is a vision-language model. The conversion produced a separate f16 multimodal projector alongside the language model; that projector is not part of this repository, and every number below describes the language model only.

Key results

Area	Result
Model format	GGUF (.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	44.79 tokens/sec, 441.95 ms TTFT
Accuracy result	MMLU 50.49%
Size / memory result	504.78 MB model size, 2.87x smaller than the baseline; 1109.05 MB peak memory

Original model

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

Model files

File	Description
`Qwen__Qwen3.5-0.8B_llamacpp_optimized.gguf`	Arm-optimized model for deployment
`example.py`	Minimal inference example
`pyproject.toml`	Python dependencies for the example
`uv.lock`	Locked dependency versions for the example
`config.yaml`	Model I/O contract used by the example
`benchmarks/`	Benchmark scripts and raw results

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 execution backend
OS	Android 16 / OriginOS 6
Runtime	llama.cpp
Backend / delegate	cpu, ggml CPU_REPACK
Batch size	1
Precision	K-quant Q4KM — predominantly Q4K weights, with 25 tensors promoted to Q6K, and norms plus SSM convolution/time-step parameters kept in FP32; static, per-group
Runs	20 measured, 5 warm-up

The runtime was built with the flags -march=armv8.6-a+dotprod+i8mm and GGMLCPUKLEIDIAI=ON.

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
Decode throughput	19.14 tokens/sec	44.79 tokens/sec	2.34x
TTFT	2143 ms	442 ms	4.85x
p50 latency	8832.11 ms	3301.18 ms	2.68x
Model size	1446.48 MB	504.78 MB	2.87x smaller
Peak memory	1557.67 MB	1109.05 MB	1.40x less

The performance baseline is the f16 GGUF of the same checkpoint, benched in the same session on the same device — f16 rather than bf16 on purpose, because ggml has no optimized bf16 CPU kernel and using it as the reference would inflate every ratio above.

Latency here is the arithmetic consequence of the two measured llama-bench throughputs at the benched shape, not a directly timed wall-clock figure. Peak memory is Android USS (private clean plus private dirty), not peak RSS.

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-Redux 2.0
Split	test, 0-shot
Number of samples	5330
Metric(s)	MMLU accuracy
Evaluation runtime	llama.cpp (llama-cpp-python binding)

The accuracy run was executed on a GPU host, not on the vivo X300 used for the performance figures above; quality was never scored on device. Quantization is deterministic, so the accuracy figure carries across hosts, but the two blocks describe the same artifact measured on two different machines. Both comparisons use the same reference file — the f16 GGUF produced by the export.

Accuracy results

Metric	Original / baseline	Arm-optimized	Change
MMLU accuracy	50.53%	50.49%	-0.04 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 GGUF (`.gguf`) for llama.cpp
Quantization	Yes	K-quant Q4KM (predominantly Q4K, with 25 tensors promoted to Q6K), static, per-group; importance-matrix calibrated on 200 randomly selected WikiText-2 samples; norms and SSM convolution/time-step parameters kept in FP32
Runtime/backend selection	Yes	llama.cpp CPU backend with ggml CPUREPACK, built with -march=armv8.6-a+dotprod+i8mm and GGMLCPU_KLEIDIAI=ON
Graph/runtime compatibility updates	Yes	The multi-token-prediction draft head was dropped during conversion; llama.cpp's Qwen3.5 conversion path counts it in block_count but emits no tensors for it
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

example.py is a Python reference for loading the GGUF and checking its output; it is not how the model runs on the vivo X300, which serves it through llama.cpp's native CPU backend without a Python runtime. The pyproject.toml/uv.lock environment below was resolved and validated on a Linux aarch64 development host (Ubuntu 24.04, glibc 2.39, Python 3.12); on-device validation on the vivo X300 target itself uses the compiled llama-cli/llama-server binaries, not this Python environment.

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

llama-cpp-python has no prebuilt wheel for this platform, so uv sync builds it from source; this requires a C/C++ toolchain and CMake and takes a few minutes the first time. The GGUF uses the qwen35 architecture, which needs a llama.cpp build new enough to know it — this project pins llama-cpp-python==0.3.35, whose vendored llama.cpp supports it. An older version will refuse to load the file.

Run the example

bash

uv run example.py

Optional flags:

bash

uv run example.py --prompt "Explain what a Kalman filter does in two sentences."
uv run example.py --max-tokens 512 --threads 4

Writes sample_input.txt and predictions.json next to example.py.

Equivalent with the compiled llama.cpp CLI instead of the Python binding:

bash

llama-cli -m Qwen__Qwen3.5-0.8B_llamacpp_optimized.gguf \
    -c 2048 -t 4 --temp 0 -n 256 -cnv \
    -p "Explain what a Kalman filter does in two sentences."

Expected input

Property	Value
Input shape	[1, T], where T is the runtime sequence length
Input type	int32
Input range	vocabulary ids, 0 to 248319
Preprocessing	Apply the chat template embedded in the .gguf, tokenize with the embedded BPE tokenizer (vocab size 248320), and truncate to the n_ctx of the runtime handle

Expected output

Property	Value
Output shape	[1, T, 248320]
Output type	Per-token logits over the vocabulary when logits_all is requested; last-position logits only by default
Postprocessing	Decode with the embedded tokenizer; sampling is done by the runtime (greedy, temperature 0, in the shipped example), the KV cache is internal to llama.cpp, and generation stops on the EOS token (id 248046) or max_tokens

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-Redux 2.0, test split, 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

—Not every tensor is 4-bit. The llama-quantize Q4KM recipe promotes 25 tensors to Q6K — the tied token embedding plus the attention-QKV and FFN-down projections of selected blocks — and leaves 133 norm and SSM parameter tensors in FP32. 162 tensors are Q4K. The importance matrix has 186 entries over 800 chunks.
—The architecture is hybrid. Qwen3.5-0.8B interleaves SSM (Mamba-style) blocks with a full-attention block every fourth layer, so its decode behavior under quantization does not necessarily match a pure-attention model of the same size.
—Peak memory is Android USS read from the process smaps_rollup, not the peak RSS that server-class evaluators report. The two are not interchangeable across targets.
—The reported accuracy is a 0-shot, no-template, MCF measurement; figures produced under a different evaluation protocol are not directly comparable.
—The GGUF declares a trained context of 262144 tokens; the served window is whatever n_ctx the runtime is started with, and the shipped recipe uses 2048.
—The multimodal projector was neither benchmarked nor evaluated. Image inputs are outside the scope of these numbers.

About this version

Original Model: Qwen/Qwen3.5-0.8B 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.