How to use from
Docker Model Runner
docker model run hf.co/CreekHop/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF:
Quick Links

Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF

GGUF quantizations of: YFC-112358/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4

Chinese to English Translation of Source Model Card

Three-Stage Construction

Stage 1. DELLA fuses three models of different lineages into a single "general intelligence composite" $G$. Stage 2. The increment of Qwopus3.6-27B-Fusion relative to its ancestor is linearly superimposed onto $G$, completely intact (no pruning). Both stages use the true ancestor, Qwen/Qwen3.6-27B (not any descendant), as their base model — so all task vectors $\Delta$ live in the same reference frame, which is what makes the superposition meaningful. Stage 3. re-anchors the entire result of the first two stages:

out=Cold-Fusion+(stage2Qwen3.6)\text{out} = \text{Cold-Fusion} + (\text{stage2} - \text{Qwen3.6})

i.e., it linearly transports the task vector relative to Qwen3.6 onto Cold-Fusion-GAIN-V1.1, which is based on Qwen3.8. This step is bit-exact — no pruning, no randomness — but it crosses model generations; whether it actually holds depends on whether the two base generations are aligned (see cold_amp below).

⚠️ In this release the retention coefficient $W_{V3} = 0.30$ (not 1.00), so the output is $\text{Qwen3.6} + 0.30 \cdot T(\Delta_{v3}) + 1.00 \cdot \Delta_{\text{ColdFusion}}$. Since $\beta = 1.00$, the base has already landed entirely on Cold-Fusion (Qwen3.8); $\alpha$ only controls how much of the Qwen3.6-side task vector is added. The choice $\alpha = 0.30$ was measured and calibrated, not picked arbitrarily: before construction we measured that Cold-Fusion's displacement relative to official Qwen3.8 is only $\approx 0.7,|W|$ (i.e., in Cold-Fusion − Qwen3.6, 98.7% is generation difference and only 1.3% is its own fine-tuning), while $\Delta_{v3}$ is about $13,|W|$ on the MLPs and nearly orthogonal to it (measured cosine $= +0.005$). With $\alpha = 1.00$, Cold-Fusion's behavior would be drowned out at roughly 15× the volume; with $\alpha = 0.30$, the displacement landing on the MLPs is ≈ 4.6× that of $\delta_{CF}$ (before $T$ truncation).

🧩 Companion adapter: YFC-112358/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-LoRA — Stage 3's $T(\Delta_{v3})$ was saved separately as a rank-48 PEFT LoRA ($\alpha$ is a load-time knob: lora_alpha = α×48; this repo ≡ Cold-Fusion + 0.30·that direction), so it can be applied to any Qwen3.8-family model. embed_tokens / lm_head were not passed through $T$ due to memory limits and are not included in the adapter.

Recipe (can be handed directly to mergekit)

# ===== stage 1: build the "general intelligence composite" G =====
merge_method: della_linear
base_model: Qwen/Qwen3.6-27B
models:
  - model: DavidAU/Qwen3.6-27B-V1.1-FF711-Darker-Hero-GAIN-H2.0
    parameters: { weight: 0.90, density: 0.85 }
  - model: YFC-112358/Qwen3.6-27B-Della-Deckard-Isometry-Geodesic-v2
    parameters: { weight: 0.80, density: 0.85 }
  - model: nightmedia/Qwen3.6-27B-Seven
    parameters: { weight: 0.25, density: 0.55 }
parameters:
  epsilon: 0.30
  lambda: 1.0
  normalize: false
  int8_mask: true
dtype: float32
out_dtype: bfloat16
tokenizer: { source: "Qwen/Qwen3.6-27B" }

# ===== stage 2: G vs #4, with #4 dominant =====
merge_method: task_arithmetic
base_model: Qwen/Qwen3.6-27B
models:
  - model: KyleHessling1/Qwopus3.6-27B-Fusion-BF16
    parameters: { weight: 1.00, density: 1.00 }
  - model: ./stage1-G
    parameters:
      weight: [1.0, 1.0, 1.0, 1.0]
      density: 1.00
parameters:
  epsilon: 0.30
  lambda: 1.0
  normalize: false
  int8_mask: true
dtype: float32
out_dtype: bfloat16
tokenizer: { source: "Qwen/Qwen3.6-27B" }

# ===== stage 3: re-anchor the whole stage-2 output onto Cold-Fusion (3.8) =====
merge_method: task_arithmetic
base_model: Qwen/Qwen3.6-27B
models:
  - model: DavidAU/Qwen3.8-27B-Cold-Fusion-GAIN-V1.1
    parameters: { weight: 1.00 }
  - model: ./stage2-out
    parameters: { weight: 1.00 }
parameters:
  normalize: false
  int8_mask: true
dtype: float32
out_dtype: bfloat16
tokenizer: { source: "DavidAU/Qwen3.8-27B-Cold-Fusion-GAIN-V1.1" }

Expanded out, this is $\text{out} = \text{ColdFusion} + (\text{stage2} - \text{Qwen3.6})$: both task vectors use Qwen/Qwen3.6-27B as their reference frame and both have weight 1.00, so $\text{base} + (\text{CF} - \text{base}) + (\text{stage2} - \text{base}) = \text{CF} + \text{stage2} - \text{base}$.

⚠️ This step is a cross-generation linear transport with no mathematical guarantee. The Qwen3.6 and Qwen3.8 architectures are identical field by field (hidden 5120 / 64 layers / vocab 248320 / FFN 17408 / MTP included / vision tower included), so all shape checks pass green and the model loads — but that does not prove the two generations' weights live in the same base. The measured cold_amp is given in the table below: continued training on the same base should land in 0.02–0.20; if it were close to 1.0, that would mean two independent pre-trainings, and this step would be adding noise.

  • stage1-G was never written to disk. Both stages are computed back-to-back within the same row block: first $G = \text{base} + \sum \tilde{\Delta}_i$ is obtained, then $\Delta_G = G - \text{base}$ is immediately used for stage 2. Mathematically identical to writing to disk first and reading it back (fp32 throughout), but it saves ≈54 GB of upload+download.
  • ε is auto-narrowed. mergekit requires density ± epsilon ∈ (0,1); in stage 1, 0.85 + 0.30 would be out of bounds and throw an error directly. For this model, ε was narrowed per source up to the legal limit (keeping a 0.02 margin), so the expected densities still equal their respective density values exactly (fable and v2 both have density 0.85 ⇒ ε was narrowed to 0.13 for both). In stage 2 both sources have density 1.00 with no pruning, so ε automatically goes to zero — that part has no randomness at all.

Fusion Health Readings (measured during construction)

Metric Meaning Median value
amp $|\text{total increment}| / |\text{ancestor weights}|$ 0.0202
share Mass ratio of G to Qwopus 26.002
kill₂ Fraction of non-zeros eliminated by stage-2 sign election 0.0%
cold_amp $|\text{Qwen3.8·ColdFusion} - \text{Qwen3.6}| / |\text{Qwen3.6}|$ 0.1217

$\text{share} = |\text{w}G \cdot \Delta_G| / |\Delta{\text{qwopus}}|$. This recipe does not aim for it to be less than 1: Qwopus's increment relative to its ancestor is inherently tiny (attention/vocab/output head are bit-identical to the ancestor; only the MLPs differ by 0.2–0.8%), so share is naturally large. Its role here is simply to give an honest comparison of the true magnitudes of the two sources.

Usage

from transformers import AutoModelForCausalLM, AutoTokenizer
m = AutoModelForCausalLM.from_pretrained("YFC-112358/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4", dtype="bfloat16", device_map="auto")
t = AutoTokenizer.from_pretrained("YFC-112358/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4")

Sampling: start from temperature=0.7, top_p=0.8, top_k=20. The config/tokenizer comes from the Cold-Fusion (3.8) repo — the weights are anchored on that side.

Deviations From the Original Recipe (Supplementary Statement)

  • Stage 2 is a pure linear superposition, not DELLA. With density: 1.00, MagPrune degenerates into an identity mapping (no ranking, no Bernoulli sampling, no 1/p rescaling), so stage 2 is strictly equal to $\text{out} = G + 1.00 \cdot (\text{Qwopus} - \text{Qwen/Qwen3.6-27B})$, i.e., mergekit's task_arithmetic. The reason for doing it this way: per-source audits showed Qwopus's increment relative to its ancestor is concentrated in the MLPs and only 0.2–0.8% in magnitude — pruning another 40% off such a small increment would cut signal and leave noise.
  • Stage 3 is a cross-generation linear re-anchoring, which is the biggest uncertainty of this model. $\text{out} = \text{Cold-Fusion (based on Qwen3.8)} + (\text{stage2} - \text{Qwen3.6})$ holds only if the two generations' weights live in the same base (i.e., 3.8 was continued from 3.6). The two architectures are identical field by field, so shape checks, loading, and inference will not throw errors — the way it fails is by quietly getting dumber. Measured cold_amp at construction time: 0.1217; the reference range for same-base fine-tuning is 0.02–0.20. If that value were close to 1.0, treat this model as an experiment. Also, Cold-Fusion-GAIN-V1.1 was still at the author-annotated "cook #1 / working title" stage when constructed, and its weights may have since been replaced; specify a commit if you want an exact reproduction.
  • No TIES sign election (equivalent to della_linear). The task vectors of v2 and Fable are nearly orthogonal (cos ≈ 0.01); with election on, Fable would be the majority direction and about half of v2's retained elements would be wiped out (measured kill ≈ 13%, exactly the order of half of v2) — effectively projecting away v2's orthogonal features. To preserve it fully, election was disabled this time.
Downloads last month
1,041
GGUF
Model size
27B params
Architecture
qwen35
Hardware compatibility
Log In to add your hardware

4-bit

5-bit

6-bit

8-bit

16-bit

Inference Providers NEW
This model isn't deployed by any Inference Provider. 🙋 Ask for provider support

Model tree for CreekHop/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF