Modelpublic

Arm/deepseek-r1-distill-qwen-1-5b-q4-k-m-llamacpp-vivo-x300

sourceHugging Facemitupdated 20d agoView on Hugging Face

0likes531downloads

Model Card

DeepSeek-R1-Distill-Qwen-1.5B optimized for Arm-based mobile CPUs with SME2

DeepSeek-R1-Distill-Qwen-1.5B text generation, quantized to a Q4KM GGUF for the llama.cpp runtime and optimized for Arm-based mobile CPUs with SME2.

Summary

This repository contains an Arm-optimized version of deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B for text generation. The model is provided as a GGUF .gguf file for the llama.cpp runtime, targeting Mobile CPU systems.

The recipe is a mixed llama.cpp k-quant, not a uniform 4-bit one. Weights are 4-bit (Q4K) for the default tensor type and the token embeddings and 6-bit (Q6K) for the output weight. Activations are not stored in the file: the llama.cpp CPU kernels dynamically quantize them to 8-bit per block at runtime. Weights are quantized with an importance matrix (imatrix-weighted k-quant), per-group and asymmetric.

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 MATH-500 and measured performance with llama-bench synthetic tokens on a representative evaluation target.

The model is reasoning-distilled: the embedded chat template opens the assistant turn with a think tag, the model emits a chain of thought, and the final answer follows the closing think tag. It needs a large generation budget to be useful.

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	34.67 tokens/sec decode, 761.30 ms prefill
Accuracy result	MATH-500 80.0%
Size / memory result	1065.56 MB model size, 3.19x smaller than the f16 baseline
Precision	Mixed: 4-bit weights (Q4K default tensor type and token embeddings), 6-bit output weight (Q6K); activations dynamically quantized to 8-bit at runtime

Original model

Field	Value
Original model	deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B
Original source	Hugging Face
Original developer	DeepSeek AI
Original model card	deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B
Original license	MIT

Model files

File	Description
`deepseek-ai__DeepSeek-R1-Distill-Qwen-1.5B_llamacpp_Q4_K_M.gguf`	Arm-optimized model for deployment
`example.py`	Minimal inference example
`pyproject.toml`	Pinned runtime dependencies for `example.py`, resolved with uv
`uv.lock`	Locked dependency resolution for `pyproject.toml`
`config.yaml`	Model I/O contract used by the example
`benchmarks/`	F16 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, cpu
OS	android — Android 16 / OriginOS 6
Runtime	llama.cpp
Backend / delegate	cpu, ggml-cpu-repack
Batch size	1
Precision	Mixed: 4-bit weights (Q4K default tensor type and token embeddings), 6-bit output weight (Q6K); activations dynamically quantized to 8-bit at runtime; imatrix-weighted k-quant, per-group, asymmetric
Runs	5 warm-up + 20 measured

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	9.84 tokens/sec	34.67 tokens/sec	3.52x
Prefill time	5515.52 ms	761.30 ms	7.24x faster
p50 latency	18531.18 ms	4458.02 ms	4.16x faster
Model size	3395.48 MB	1065.56 MB	3.19x smaller
Peak memory	3469.12 MB	1979.49 MB	1.75x less

Latency here is derived from the measured llama-bench figures at the benched shape (128-token prompt, 128 generated tokens), 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	MATH-500
Split	0-shot
Number of samples	250
Metric(s)	MATH-500 accuracy (pass@1)
Evaluation runtime	llama.cpp

The accuracy run was executed on AWS Graviton4, 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.

Accuracy results

Metric	Original / baseline	Arm-optimized	Change
MATH-500 accuracy	82.8%	80.0%	-2.80 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	Imatrix-weighted llama.cpp k-quant, per-group and asymmetric. Mixed weight precision: 4-bit (Q4K) default tensor type and token embeddings, 6-bit (Q6K) output weight; activations dynamically quantized to 8-bit at runtime by the CPU kernels. Importance matrix calibrated on 32 randomly selected WikiText-2 samples
Runtime/backend selection	Yes	llama.cpp CPU backend with ggml-cpu-repack, built with -march=armv8.6-a+dotprod+i8mm
Graph/runtime compatibility updates	Yes	Performed as part of the llama.cpp GGUF conversion pipeline
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:

bash

uv python install
uv sync --frozen

Run the example

bash

uv run example.py

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.

Expected input

Property	Value
Input shape	[1, T], where T is the runtime sequence length
Input type	int32 token ids
Input range	vocabulary ids, 0 to 151935
Preprocessing	Apply the deepseekr1 chat template, then tokenize with the BPE tokenizer embedded in the `.gguf` (addbos, bos id 151646)

Expected output

Property	Value
Output shape	Token ids generated one at a time
Output type	int32 token ids, decoded to text by llama.cpp
Postprocessing	Decode with the embedded tokenizer; the final answer is the span after the closing think tag (id 151649); stop on the EOS token (id 151643) 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 MATH-500 (250-problem stratified subset) 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

—Peak memory is Android USS read from /proc/<pid>/smaps_rollup, not the peak RSS that server-class evaluators report. The two are not interchangeable across targets.
—Reasoning budget matters. Traces are long and the reported score was obtained with maxtokens 12288 at nctx 14336, while the shipped serving window is n_ctx 4096, sized for the phone's KV-cache budget. Smaller budgets truncate traces, and a truncated trace yields no answer at all. DeepSeek advises against a system prompt and against greedy decoding for the R1-distill family.

About this version

Original Model: deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B by DeepSeek AI - 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 MIT.

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.