Qwen3.6 AEON RYS 15/20 and SignalLatch

What this is

This is a Qwen3.6-27B AEON-derived model line built around a specific RYS branch: duplicate the source layer window 15..19 and insert that copy after source layer 19. The resulting logical stack has 69 layers instead of the original 64.

The non-finetuned release is the practical base: an AEON RYS 15/20 model exported to a custom ik-llama-compatible IQ4_NL GGUF. SignalLatch is the behavior-finetuned release: checkpoint-386 LoRA merged into that RYS base at strength 0.10, then exported as the same practical GGUF deployment target.

Required runtime

Use the custom AEON ik-llama fork. The GGUFs in this release line are intended for that runtime path, especially for graph split, Qwen3.6/Qwen3.5 hybrid handling, Jinja chat formatting, and DeepSeek-style reasoning extraction.

github.com/noonr48/qwen36-aeon-ik-llama

./build/bin/llama-server \
  -m /path/to/Qwen3.6-27B-AEON-RYS-SignalLatch-v1.1-Lite-Mixed-Q4NL.gguf \
  -c 65536 \
  -ngl 999 \
  -np 1 \
  -fa on \
  -sm graph \
  --temp 0.7 \
  --jinja \
  --reasoning-format deepseek \
  --reasoning-budget 0

For long-context use, increase context as your system allows. The default KV type is f16. The logged 24 GB-class SignalLatch profile is -c 65536 on one RTX 3090 at about 20.8 GiB VRAM. A current 32 GB RTX 5090 reference fits -c 160000 -np 2, which creates two 80k slots and uses about 27.5 GB VRAM.

# Long-context shape
-c 160000 -np 2 -ctk f16 -ctv f16

# Conservative validation shape used for the canvas comparison
-c 131072 -ctk f32 -ctv f32

Practical single-GPU deployment: the SignalLatch Q4_NL release is small enough for practical use on a single RTX 3090 / 24 GB-class card at the baseline 65536 context profile. Do not read the 160k reference as a 24 GB-class memory claim; a true two-slot 160k-per-slot run did not fit on the 32 GB RTX 5090 in our test.

Parallel RAM-cache serving

For agent harness use, the current custom fork can expose stable slot aliases and still run RAM prompt-cache save/load on those pinned lanes. This is the setup pattern used when an OpenAI-compatible harness needs two independent workers without losing repeated repo context between turns.

./build/bin/llama-server \
  -m /path/to/Qwen3.6-27B-AEON-RYS-SignalLatch-v1.1-Lite-Mixed-Q4NL.gguf \
  -c 360000 \
  -np 2 \
  -ngl 999 \
  -b 256 \
  -ub 64 \
  -fa on \
  -sm layer \
  -ctk f16 \
  -ctv f16 \
  --temp 0.7 \
  --jinja \
  --reasoning-format deepseek \
  --reasoning-budget 0 \
  --alias qwen36-aeon-rys-signallatch-q4nl-p2 \
  -cram 65536

Configure the agent client as two OpenAI-compatible model names:

qwen36-aeon-rys-signallatch-q4nl-p2-slot0
qwen36-aeon-rys-signallatch-q4nl-p2-slot1

Those suffixes pin work to the matching slot. The total context budget is split by -np, -cram is a server-wide MiB budget, and context checkpoints must remain enabled for RAM-cache restore to avoid full prompt reprocessing. For the tested two-GPU parallel path, use -sm layer; -sm graph disables the recurrent checkpoints needed by this restore path.

Materialized RYS weights

The current release uses materialized RYS. The copied 15,20 window is exported as ordinary GGUF tensors, so output layers 20..24 have their own copied tensors from source layers 15..19.

This keeps the HF checkpoint, GGUF conversion, quantization, and downstream fine-tune workflow explicit and stable. It also means the copied weights are loaded like normal weights.