Instructions to use CreekHop/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF with libraries, inference providers, notebooks, and local apps. Follow these links to get started.
- Notebooks
- Google Colab
- Kaggle
- Local Apps Settings
- llama.cpp
How to use CreekHop/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF with llama.cpp:
Install (macOS, Linux)
curl -LsSf https://llama.app/install.sh | sh # Start a local OpenAI-compatible server with a web UI: llama serve -hf CreekHop/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF:Q4_K_M # Run inference directly in the terminal: llama cli -hf CreekHop/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF:Q4_K_M
Install from WinGet (Windows)
winget install llama.cpp # Start a local OpenAI-compatible server with a web UI: llama serve -hf CreekHop/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF:Q4_K_M # Run inference directly in the terminal: llama cli -hf CreekHop/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF:Q4_K_M
Use pre-built binary
# Download pre-built binary from: # https://github.com/ggerganov/llama.cpp/releases # Start a local OpenAI-compatible server with a web UI: ./llama-server -hf CreekHop/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF:Q4_K_M # Run inference directly in the terminal: ./llama-cli -hf CreekHop/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF:Q4_K_M
Build from source code
git clone https://github.com/ggerganov/llama.cpp.git cd llama.cpp cmake -B build cmake --build build -j --target llama-server llama-cli # Start a local OpenAI-compatible server with a web UI: ./build/bin/llama-server -hf CreekHop/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF:Q4_K_M # Run inference directly in the terminal: ./build/bin/llama-cli -hf CreekHop/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF:Q4_K_M
Use Docker
docker model run hf.co/CreekHop/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF:Q4_K_M
- LM Studio
- Jan
- Ollama
How to use CreekHop/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF with Ollama:
ollama run hf.co/CreekHop/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF:Q4_K_M
- Unsloth Desktop
- Pi
How to use CreekHop/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF with Pi:
Start the llama.cpp server
# Install llama.cpp: brew install llama.cpp # Start a local OpenAI-compatible server: llama serve -hf CreekHop/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF:Q4_K_M
Configure the model in Pi
# Install Pi: npm install -g @earendil-works/pi-coding-agent # Add to ~/.pi/agent/models.json: { "providers": { "llama-cpp": { "baseUrl": "http://localhost:8080/v1", "api": "openai-completions", "apiKey": "none", "models": [ { "id": "CreekHop/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF:Q4_K_M" } ] } } }Run Pi
# Start Pi in your project directory: pi
- Docker Model Runner
How to use CreekHop/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF with Docker Model Runner:
docker model run hf.co/CreekHop/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF:Q4_K_M
- Lemonade
How to use CreekHop/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF with Lemonade:
Pull the model
# Download Lemonade from https://lemonade-server.ai/ lemonade pull CreekHop/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF:Q4_K_M
Run and chat with the model
lemonade run user.Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF-Q4_K_M
List all available models
lemonade list
- Hermes Agent
How to use CreekHop/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF with Hermes Agent:
Start the llama.cpp server
# Install llama.cpp: brew install llama.cpp # Start a local OpenAI-compatible server: llama serve -hf CreekHop/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF:Q4_K_M
Configure Hermes
# Install Hermes: curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash hermes setup # Point Hermes at the local server: hermes config set model.provider custom hermes config set model.base_url http://127.0.0.1:8080/v1 hermes config set model.default CreekHop/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF:Q4_K_M
Run Hermes
hermes
- Atomic Chat
- OpenClaw
How to use CreekHop/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF with OpenClaw:
Start the llama.cpp server
# Install llama.cpp: brew install llama.cpp # Start a local OpenAI-compatible server: llama serve -hf CreekHop/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF:Q4_K_M
Configure OpenClaw
# Install OpenClaw: npm install -g openclaw@latest # Register the local server and set it as the default model: openclaw onboard --non-interactive --mode local \ --auth-choice custom-api-key \ --custom-base-url http://127.0.0.1:8080/v1 \ --custom-model-id "CreekHop/Qwen3.8-27B-Della-Deckard-Fable-Qwopus-ColdFusion-v4-GGUF:Q4_K_M" \ --custom-provider-id llama-cpp \ --custom-compatibility openai \ --custom-text-input \ --accept-risk \ --skip-health
Run OpenClaw
openclaw agent --local --agent main --message "Hello from Hugging Face"
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:
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_ampis 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
densityvalues 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_ampat 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
4-bit
5-bit
6-bit
8-bit
16-bit