---
title: moss-image-hexagon
canonical_url: "https://www.modelscope.cn/models/fengerhu1/moss-image-hexagon"
md_url: "https://www.modelscope.cn/models/fengerhu1/moss-image-hexagon.md"
repository: fengerhu1/moss-image-hexagon
last_updated: 2026-10-31
parameters: 84.0M
tensor_type:
  - F32
  - I64
library_name:
  - safetensors
  - gguf
downloads: 19
stars: 0
tags:
  - gguf
---

# moss-image-hexagon

> moss-image-hexagon - fengerhu1 在 ModelScope 开源的模型。MOSS-Image weights for Hexagon NPU (v79/v81): DiT turbo Q4_K_M, 4-step F16, Qwen3.5-9B text encoder, FLUX.2 VAE

- **Repository**: fengerhu1/moss-image-hexagon
- **Parameters**: 84.0M
- **Tags**: gguf
- **Downloads**: 19
- **Stars**: 0
- **Last updated**: 2026-10-31

Source: https://www.modelscope.cn/models/fengerhu1/moss-image-hexagon

---

# MOSS-Image weights (Hexagon NPU)

MOSS-Image text-to-image weights packaged for running on the Qualcomm Hexagon
NPU (HVX v79 / v81). Lineage: `OpenMOSS-Team/MOSS-Image-SFT`, distilled for few
steps by `lodestones` / `akhaliq`, quantised by `molbal`.

## Files

| File | Size | Role |
| --- | ---: | --- |
| `moss-turbo8-q4km-f16t.gguf` | 3.60 GB | **DiT, recommended.** Turbo Q4_K_M, runs clean at 4 steps |
| `moss-4step-distill-f16.gguf` | 10.17 GB | DiT, same LoRA at full F16 (no quantisation) |
| `qwen3.5-9b-q4km.gguf` | 5.68 GB | Text encoder (Qwen3.5-9B, Q4_K_M) |
| `flux2-vae.safetensors` | 0.34 GB | FLUX.2 VAE. Separate file — the VAE is not embedded in the DiT gguf |
| `tokenizer.json` | 0.02 GB | Qwen3.5 tokenizer |

## Which DiT to use

`moss-turbo8-q4km-f16t.gguf` is the one to reach for: 3.6 GB, and at 4 steps it
is both smaller and no slower than the F16 build. The F16 file is the reference
when you want an unquantised baseline — at 8 steps it is visibly cleaner than
4 steps, which is why it is kept.

Source of the turbo file: `molbal/MOSS-Image-GGUF` →
`moss_image_sft_turbo-Q4_K_M.gguf`. The only local change is that its 17 BF16
tensors were rewritten to F16, because the Hexagon backend has no BF16 matmul
kernel and those tensors would otherwise fall back to the CPU.

`moss-4step-distill-f16.gguf` was built here: the official
`OpenMOSS-Team/MOSS-Image-SFT` safetensors plus the
`akhaliq/MOSS-Image-SFT-4-steps` LoRA (252 targets), fused and written as F16.

## Running it

These models were validated with `stable-diffusion.cpp` on a Hexagon v79 device.
Binaries are not distributed here — see the upstream project.

```bash
sd-cli \
  --diffusion-model moss-turbo8-q4km-f16t.gguf \
  --llm            qwen3.5-9b-q4km.gguf \
  --vae            flux2-vae.safetensors \
  --tokenizer      tokenizer.json \
  --mmap \
  --backend diffusion=HTP0,te=cpu,vae=HTP0 \
  --cfg-scale 1.0 \
  --sampling-method euler \
  --scheduler simple \
  -H 512 -W 512 --steps 4 -t 6 \
  -p "a small wooden cabin beside a calm lake at sunrise"
```

**All four of `--cfg-scale 1.0`, `euler`, `simple` and `--steps` matter.**
These are distilled models trained for classifier-free-guidance-free sampling;
raising `--cfg-scale` doubles the DiT cost and makes output worse, not better.
`euler` + `simple` is the combination the distillation was validated with —
`discrete` also runs but changes the look.

Backend split notes for Hexagon:

- `diffusion=HTP0` — the DiT is the main win, ~4x over CPU on v79.
- `te=cpu` — the text encoder is faster on the CPU. It needs 5.4 GB against a
  3.3 GB DSP budget, so on the NPU it re-stages weights every segment and ends
  up ~5x slower.
- `vae=HTP0` — ~3.5x over CPU, and numerically within 1/255 of the CPU path.

## Measured on a OnePlus 13 (SM8750, Hexagon v79, 6 threads, 512x512)

| DiT | Steps | DiT sampling | VAE | End to end |
| --- | ---: | ---: | ---: | ---: |
| turbo Q4_K_M | 4 | 22.5 s | 15.4 s | ~46 s |
| turbo Q4_K_M | 8 | 41.7 s | 15.4 s | ~61 s |
| 4step F16 | 4 | 31.7 s | 15.4 s | ~56 s |
| 4step F16 | 8 | 51.3 s | 15.4 s | ~80 s |

Timings are single runs; this device's CPU clock drifts between 960 MHz and
2.4 GHz, so treat them as ±20%.

## Licences

Base model `OpenMOSS-Team/MOSS-Image-SFT` and its derivatives are Apache-2.0.
The text encoder is Qwen3.5-9B and the VAE comes from FLUX.2; check the terms of
those upstream releases before redistributing or using commercially.