HIP-0904: Zen6 — Dense, Coder and Ternary Checkpoints

Abstract

Zen6 is the current Zen generation (HIP-0039). It was published on 2026-09-21 as three open-weight Hugging Face repositories:

• zenlm/zen6. A 64-layer hybrid-attention model in mixed NVFP4 and FP8, with a DFlash 2 drafter bundled beside it and YaRN scaling to 1,048,576 positions.
• zenlm/zen6-coder. A 512-expert mixture as GGUF IQ4_XS, with a one-layer MTP drafter.
• zenlm/zen6-flash. A 64-layer model in ternary GGUF, with a vision projector and a DFlash 2 drafter.

All three are re-hosts.

• Every weight file is byte-identical to a named upstream file.
• Only zen6 changes a model file: three rope fields in its config.json.
• The only measured number in any of the three repositories is the upstream's GSM8K qualification of zen6.

zen6 and zen6-coder are also served SKU ids on /v1/models. Under HIP-0039 §2.3 they do not promise these weights.

This HIP records the layout of each repository, where each file came from, what has been measured and what is only claimed, and the defects found on 2026-09-25.

Motivation

Zen6 was published on Hugging Face on 2026-09-21 and is served on /v1/models. Until 2026-09-25, no HIP, catalog, site or doc named it.

Its cards also disagree with the files beside them. The zen6 card's architecture table gives a different head count, vocabulary and attention type from its config.json. The zen6-coder card describes a file format that is not in its repository.

A reader choosing between the three needs the artifacts, not the cards: what each file is, where it came from, what runs it, and which numbers carry a receipt.

Specification

The key words MUST, MUST NOT, SHOULD, SHOULD NOT and MAY are to be interpreted as in RFC 2119.

Every fact below was read on 2026-09-25 from the Hugging Face API (https://huggingface.co/api/models/<id>?blobs=true) and from the files at the revision given. GGUF metadata was read from the file headers with HTTP range requests.

§1 Repositories

GitHub has zenlm/zen6, zenlm/zen6-coder and zenlm/zen6-flash. They hold the card, plus a training/ recipe for zen6 and zen6-coder, and no weights.

§2 zen6

The target model is a Qwen3_5ForConditionalGeneration (model_type: qwen3_5):

Quantization is NVIDIA ModelOpt 0.47.0.dev0 MIXED_PRECISION:

• NVFP4 (4-bit float weights and activations, group size 16) on 193 modules: every gate_proj, up_proj and down_proj, plus lm_head.
• FP8 (8-bit float weights and activations) on 208 modules: every attention projection, linear and full.
• KV cache: FP8.
• Unquantized: MTP.

The weights are three safetensors shards holding 2,194 tensors and 21,921,428,072 bytes: 1,842 language-model tensors, 333 vision, 15 MTP and 4 lm_head.

The drafter is dflash2/: DFlash2DraftModel in bfloat16, 3,848,817,896 bytes.

§3 zen6-coder

The zen6-coder GGUF headers give:

The repository holds five files:

• UD-IQ4_XS/Qwen3.8-Flash-Next-UD-IQ4_XS-0000{1,2,3}-of-00003.gguf, 93,682,584,224 bytes in total.
• MTP/mtp-Qwen3.8-Flash-Next-Q8_0.gguf, 4,137,429,120 bytes. It is the same architecture with 49 blocks and nextn_predict_layers: 1.
• MTP/README.md.

The card states 180B total parameters, 125B in the base model and 6B active per token. The headers are consistent with that but do not prove it, and this HIP does not assert it.

§4 zen6-flash

The PQ2_0 GGUF header gives:

A loader MUST implement GGML type 142 and apply the recorded Hadamard transform before these weights mean anything.

§5 Provenance

Files match their upstream when the LFS SHA-256 or git blob id is equal. The comparison was run against each upstream's file listing from the same API.

The three fields that differ in zen6's config.json, all under text_config.rope_parameters:

• rope_type: default → yarn
• factor: absent → 4.0
• original_max_position_embeddings: absent → 262144

All three checkpoints descend from Qwen3.8, so they meet HIP-0039 §3.3.

§6 Measured

The only receipt in any Zen6 repository is zen6's qualification.json with its qualification-criteria.json. Both are byte-identical to the upstream's.

What the receipt covers. It measures the upstream checkpoint with its upstream config. No receipt covers the YaRN edit, any context above 262,144, or the DFlash 2 drafter.

Unmeasured claims. The cards' throughput tables, DFlash 2 speedups, retention percentages and benchmark comparisons carry no receipt. This HIP relies on none of them.

Serving. The live SKUs zen6 and zen6-coder report a 1,000,000-token window on /v1/models. Under HIP-0039 §2.3, that window is the SKU's contract and says nothing about these files.

§7 Runtimes

The upstream receipt names only one runtime for these weights: SGLang @ 2948168 running zen6 (§6).

hanzoai/engine @ d25f18e contains:

• a qwen4exp model (hanzo-engine/src/models/qwen4exp.rs and quantized_qwen4exp.rs);
• a --dflash <dir> draft option;
• an --mtp-model option.

Whether it loads any of these three checkpoints has not been measured.

§8 Defects

As of 2026-09-25. A card fix is a new revision of that repository, and the repository revisions in §1 move with it.

1. Licence files. None of the three repositories carries LICENSE or NOTICE, which HIP-0039 §3.2 requires.

2. zen6 card against config.json. Under HIP-0039 §3.5 the config is the fact.

   Field	Card says	config.json says
   heads	32 query, 8 key/value	24 query, 4 key/value
   vocabulary	152,064	248,320
   target attention	"Sliding-Window Attention"	full attention; sliding windows are the drafter's
   drafter block	3–5 tokens	block_size: 8
   drafter positions	a 1M position table	262,144
   modality	pipeline_tag: text-generation	ships a vision tower

3. zen6-coder. The card describes a "Halogen W4B" format, and no such file is in the repository. The GitHub description says "38B-Class"; the card says 180B.

4. zen6-flash. The card lists the BF16 projector as 1.2 GB. The file is 931,145,856 bytes.

5. Commands that cannot run. The hanzo-engine serve commands on the zen6 and zen6-coder cards pass --context-window, --kv-cache-quant and --mtp. The engine at d25f18e defines none of them.

6. Not HIP-0039 §3.4. None of the cards says it is a re-host, and none names the files it copied.

Rationale

• Why re-host. It puts a current checkpoint under the Zen name the day upstream publishes one, with no training cost. Its price is that Zen6 open weights are exactly as good as their upstreams, and the cards have to say so (HIP-0039 §3.4). Training a Zen-specific checkpoint would be a later generation with its own receipt.
• Why the files are the specification. config.json, the GGUF headers and LFS hashes are what a runtime reads and what a reader can re-check. Card prose is neither.
• Why the defects are listed here. A HIP that repeated the cards would carry their errors. One that silently corrected them would hide that the published cards are wrong. Listing the defects lets each be fixed and struck through.

Security Considerations

• Pin revisions. A loader SHOULD pin the revision in §1, or its successor, and check LFS SHA-256 against the upstream (§5).
• zen6-flash SHA256SUMS. It is the drafter repository's, and it lists 481 files. Of the files zen6-flash ships, it covers only the drafter. It does not cover the PQ2_0, PTQ1_0 or projector files, and it names a LICENSE and NOTICE that zen6-flash does not ship.
• YaRN beyond the receipt. The zen6 YaRN edit takes the model outside its measured regime. A runtime that applies YaRN statically scales every position, including the short prompts the receipt measured. A deployment that relies on either long context or short-prompt accuracy MUST measure its own.
• Uncalibrated KV cache. The FP8 KV cache ran with uncalibrated scales, and the qualification record says so. This affects accuracy, not isolation.
• Custom tensor types. zen6-flash stores weights as GGML type 142 behind a Hadamard transform. Only a runtime that implements that type decodes them; any other loader MUST refuse the file rather than guess.
• Licence. zen6-coder is licensed qwen-community-1.0, not Apache-2.0. Its terms bind anyone who redistributes or serves it.
• Remote code. No Zen6 repository ships Python, and none carries the custom_code tag.

References

• HIP-0039 Zen; HIP-0043 inference engine; HIP-0510 Enso router; HIP-0511 model families.
• https://huggingface.co/zenlm/zen6 · https://huggingface.co/zenlm/zen6-coder · https://huggingface.co/zenlm/zen6-flash
• Upstreams: RadixArk/Qwen3.8-27B-NVFP4, incoai/Qwen3.8-27B-DFlash2, unsloth/Qwen3.8-Flash-Next-GGUF, prism-ml/Ternary-Bonsai-2-27B-gguf, ProCreations/Ternary-Bonsai-2-27B-DFlash2.
• https://github.com/zenlm/zen6 · https://github.com/zenlm/zen6-coder · https://github.com/zenlm/zen6-flash

Copyright

Copyright and related rights waived via CC0.