Felladrin/halogen-qwen3.5-0.8b

Qwen3.5-0.8B in halogen's .hgn format

Qwen3.5-0.8B converted from GGUF into the .hgn container that halogen loads.

This is an unofficial conversion. It is not affiliated with peonist-ai, and the weights are Qwen's, under Apache-2.0.

Status: it loads and verifies, but it does not generate text yet

halogen's own checkpoint verifier accepts the file:

halogen: Qwen3.5-0.8B - 336 tensors, 2.1 GB
verify: pass 0 streamed 2.1 GB in 0.01 s = 170.0 GB/s
verify: all 336 tensors match; warm stream 180.8 GB/s

And the server reaches readiness on it, finding the right layer count:

serve: listening on 127.0.0.1:8730 - 24 layers, ctx 262144, greedy batch-1
halogen: engine listening

But the first request faults in the embedding kernel. halogen 0.1.3 is built for Qwen3.8-27B, and the hidden size, the MLP intermediate size, the DeltaNet v-dim and the DeltaNet rank are fixed at the 27B values. The layer count is read from the checkpoint, the rest is not. So this file is useful for testing the format, not for serving.

You need HALOGEN_DRAFTER=0 to get that far, because the default drafter is DFlash2 and this checkpoint carries no drafter.

What is in the file

tensors	336
size	2,054,306,176 bytes
payloads	all bf16
source	ggml-org/Qwen3.5-0.8B-GGUF, Qwen3.5-0.8B-Q8_0.gguf

lm_head.weight is a copy of embed_tokens.weight, because the source has tied embeddings and no output.weight.

The tokenizer is not included. Qwen3.5-0.8B and Qwen3.8-27B share the same 248320-token vocabulary, so the tokenizer that ships with the 27B weights works.

How it was made

The GGUF does not hold the original weights as they are. llama.cpp's conversion/qwen.py adds 1 to every norm.weight except linear_attn.norm.weight, stores -exp(A_log) instead of A_log, and reorders V heads when the key and value head counts differ. The converter undoes all three. Each inverse was checked against the shipped Qwen3.8-27B checkpoint, which exists in both formats, so the values could be compared against a real .hgn instead of against the converter itself.

For reference, skipping those three steps gives you a file where every byte is a correct bf16 of the GGUF value and every RMSNorm is off by one.