Instructions to use YFC-112358/Qwen3.6-27B-Della-Deckard-Isometry-Geodesic-v2 with libraries, inference providers, notebooks, and local apps. Follow these links to get started.
- Libraries
- Transformers
How to use YFC-112358/Qwen3.6-27B-Della-Deckard-Isometry-Geodesic-v2 with Transformers:
# Use a pipeline as a high-level helper from transformers import pipeline pipe = pipeline("image-text-to-text", model="YFC-112358/Qwen3.6-27B-Della-Deckard-Isometry-Geodesic-v2") messages = [ { "role": "user", "content": [ {"type": "image", "url": "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/p-blog/candy.JPG"}, {"type": "text", "text": "What animal is on the candy?"} ] }, ] pipe(text=messages)# Load model directly from transformers import AutoProcessor, AutoModelForMultimodalLM processor = AutoProcessor.from_pretrained("YFC-112358/Qwen3.6-27B-Della-Deckard-Isometry-Geodesic-v2") model = AutoModelForMultimodalLM.from_pretrained("YFC-112358/Qwen3.6-27B-Della-Deckard-Isometry-Geodesic-v2", device_map="auto") messages = [ { "role": "user", "content": [ {"type": "image", "url": "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/p-blog/candy.JPG"}, {"type": "text", "text": "What animal is on the candy?"} ] }, ] inputs = processor.apply_chat_template( messages, add_generation_prompt=True, tokenize=True, return_dict=True, return_tensors="pt", ).to(model.device) outputs = model.generate(**inputs, max_new_tokens=40) print(processor.decode(outputs[0][inputs["input_ids"].shape[-1]:])) - Notebooks
- Google Colab
- Kaggle
- Local Apps Settings
- vLLM
How to use YFC-112358/Qwen3.6-27B-Della-Deckard-Isometry-Geodesic-v2 with vLLM:
Install from pip and serve model
# Install vLLM from pip: pip install vllm # Start the vLLM server: vllm serve "YFC-112358/Qwen3.6-27B-Della-Deckard-Isometry-Geodesic-v2" # Call the server using curl (OpenAI-compatible API): curl -X POST "http://localhost:8000/v1/chat/completions" \ -H "Content-Type: application/json" \ --data '{ "model": "YFC-112358/Qwen3.6-27B-Della-Deckard-Isometry-Geodesic-v2", "messages": [ { "role": "user", "content": [ { "type": "text", "text": "Describe this image in one sentence." }, { "type": "image_url", "image_url": { "url": "https://cdn.britannica.com/61/93061-050-99147DCE/Statue-of-Liberty-Island-New-York-Bay.jpg" } } ] } ] }'Use Docker
docker model run hf.co/YFC-112358/Qwen3.6-27B-Della-Deckard-Isometry-Geodesic-v2
- SGLang
How to use YFC-112358/Qwen3.6-27B-Della-Deckard-Isometry-Geodesic-v2 with SGLang:
Install from pip and serve model
# Install SGLang from pip: pip install sglang # Start the SGLang server: python3 -m sglang.launch_server \ --model-path "YFC-112358/Qwen3.6-27B-Della-Deckard-Isometry-Geodesic-v2" \ --host 0.0.0.0 \ --port 30000 # Call the server using curl (OpenAI-compatible API): curl -X POST "http://localhost:30000/v1/chat/completions" \ -H "Content-Type: application/json" \ --data '{ "model": "YFC-112358/Qwen3.6-27B-Della-Deckard-Isometry-Geodesic-v2", "messages": [ { "role": "user", "content": [ { "type": "text", "text": "Describe this image in one sentence." }, { "type": "image_url", "image_url": { "url": "https://cdn.britannica.com/61/93061-050-99147DCE/Statue-of-Liberty-Island-New-York-Bay.jpg" } } ] } ] }'Use Docker images
docker run --gpus all \ --shm-size 32g \ -p 30000:30000 \ -v ~/.cache/huggingface:/root/.cache/huggingface \ --env "HF_TOKEN=<secret>" \ --ipc=host \ lmsysorg/sglang:latest \ python3 -m sglang.launch_server \ --model-path "YFC-112358/Qwen3.6-27B-Della-Deckard-Isometry-Geodesic-v2" \ --host 0.0.0.0 \ --port 30000 # Call the server using curl (OpenAI-compatible API): curl -X POST "http://localhost:30000/v1/chat/completions" \ -H "Content-Type: application/json" \ --data '{ "model": "YFC-112358/Qwen3.6-27B-Della-Deckard-Isometry-Geodesic-v2", "messages": [ { "role": "user", "content": [ { "type": "text", "text": "Describe this image in one sentence." }, { "type": "image_url", "image_url": { "url": "https://cdn.britannica.com/61/93061-050-99147DCE/Statue-of-Liberty-Island-New-York-Bay.jpg" } } ] } ] }' - Docker Model Runner
How to use YFC-112358/Qwen3.6-27B-Della-Deckard-Isometry-Geodesic-v2 with Docker Model Runner:
docker model run hf.co/YFC-112358/Qwen3.6-27B-Della-Deckard-Isometry-Geodesic-v2
Qwen3.6-27B-Della-Deckard-Terse-v2
A linear task-vector merge that makes Qwen3.6-27B-Della-Deckard-v1 think 7x shorter on grade-school math without losing accuracy, at the cost of a measured regression on harder multi-step problems.
One formula describes the entire model:
W_out = W_v1 + 0.5 * (W_terse - W_qwen3.6) # 400 two-dimensional projection tensors
W_out = W_v1 # the other 799 tensors, byte-identical
That is it. No pruning, no sign election, no rotation. The sections below explain why it ended up that simple, including a documented failed attempt at something more sophisticated.
Naming note. This model was built by a notebook titled Isometry-Geodesic, and an earlier auto-generated card described it as a geodesic polar-decomposition merge. That description was wrong and has been replaced by this one. The geodesic path was attempted, measured, and rejected by its own gate on 400/400 tensors. See What did not work. Nothing in this repo is isometric or geodesic.
Measured results
Evaluated with vLLM on a single A100, temperature=0.6, top_p=0.95, top_k=20, max_tokens=8192. "Think" = tokens emitted before </think>.
| Model | Suite | pass@1 | gen median | think median | gen max | overruns |
|---|---|---|---|---|---|---|
Qwen/Qwen3.6-27B (official) |
GSM8K, 20q | 0.75 | 1375.5 | 1133.5 | 8192 | 1 |
Della-Deckard-v1 |
GSM8K, 20q | 0.75 | 691.5 | 539.5 | 1370 | 0 |
| this model | GSM8K, 20q | 0.85 | 139.0 | 76.0 | 222 | 0 |
Della-Deckard-v1 |
Hard, 10q x 4 | 0.800 | 524.5 | 359.3 | 2349 | 0 |
| this model | Hard, 10q x 4 | 0.725 | 264.5 | 175.5 | 511.5 | 0 |
Read this table honestly:
- The compression is large and real. 1133 -> 76 think tokens is 14.9x against the official base and 7.1x against v1, on the same 20 questions with the same sampler. A ratio that size is not sampling noise.
- GSM8K accuracy did not drop (0.75 -> 0.85). But n=20, single sample: that is 15 vs 17 correct. Treat it as "no measurable loss", not as an improvement.
- The hard set regressed. 0.800 -> 0.725 is 32/40 vs 29/40 generations. Three generations. Not statistically meaningful on its own, but it moves in the same direction as the think-length collapse (359 -> 176), and that combination is the signature of over-compression. It is reported here rather than dropped.
- The base model hit the 8192-token ceiling once. Neither merge ever did.
Against the builder's own pre-registered acceptance gates:
| # | Gate | Result |
|---|---|---|
| 1 | GSM8K think median down >= 3x | PASS (7.1x) |
| 2 | GSM8K pass@1 >= v1 | PASS (0.85 vs 0.75) |
| 3 | Hard pass@1 >= v1 - 3pp | FAIL (-7.5pp) |
| 4 | Hard think median >= 400 tok | FAIL (175.5) |
| 5 | Overruns not increased | PASS (0 vs 0) |
Gates 3 and 4 are exactly the "easy questions may be short, hard questions may not" check. This model fails it. See Recommended next run.
Use it if / don't use it if
Good fit: high-volume short-answer workloads where v1 or stock Qwen3.6 burns an absurd thinking budget on trivial input; latency-bound interactive use; cost-bound batch inference. A 7-15x reduction in generated tokens is a direct throughput and price multiplier.
Bad fit: competition math, multi-hop reasoning, long agentic chains, anything where you want the model to deliberate. Use v1 or stock Qwen3.6 instead. The hard-set numbers above are the warning.
Unknown: all vision capability. This is a VLM and no multimodal evaluation was run. The vision tower is byte-identical to official Qwen3.6-27B (verified, see below), so it should be no worse than the base, but the language model it feeds into has moved.
Ingredients
| Role | Repo |
|---|---|
| Host, receives the edit | YFC-112358/Qwen3.6-27B-Della-Deckard-v1 |
| Task-vector source | maldv/Qwen3.6-27B-Isometry-Terse |
| Common origin, defines the vector | Qwen/Qwen3.6-27B |
All three share the identical 1199-tensor / 51.7 GB BF16 layout. Preflight confirmed 0 missing, 0 extra, 0 shape mismatches across all three.
What was actually applied
Tensors are sorted into three buckets by name and shape:
| Bucket | Count | Treatment |
|---|---|---|
2-D projection weights, min(shape) >= 128 |
400 | W_v1 + 0.5 * (W_terse - W_base) |
embed_tokens, lm_head |
2 | copied from v1 |
Vision tower, MTP, norms, a_log, dt_bias, conv1d, everything else |
797 | copied from v1 |
The 799 passthrough tensors are byte-identical to v1, which means Xet deduplicates them on upload and on your download.
Why the passthrough set is that large
Because the upstream edit does not touch anything else. This was measured, not assumed:
| Tensor group | ||W_terse - W_base|| / ||W_base|| |
| --- | --- |
| Vision tower (model.visual.*) | max|delta| = 0.000e+00, exactly |
| All norms, a_log, dt_bias, conv1d, biases (269 tensors) | 0.000000 |
| embed_tokens | 0.00000 |
| lm_head | 0.00000 |
maldv/Qwen3.6-27B-Isometry-Terse modifies only the 2-D projection matrices. Copying
the rest is not a shortcut, it is the correct thing to do.
Why a plain linear add is safe here
This is the measurement that justifies the merge, and it is the reason a naive-looking recipe is defensible.
Sampling 16 probe tensors across layers 0-63, comparing v1's own DELLA displacement against the Terse displacement, both relative to official Qwen3.6:
cos( W_v1 - W_base , W_terse - W_base ) = +0.0003 -> theta = 89.98 degrees
random-vector baseline for these shapes = +/- 0.008 to 0.014
|| W_terse - W_base || / || W_v1 - W_base || = 1.98
The two edits are orthogonal to within measurement noise. They occupy independent subspaces, so adding one to the other does not overwrite or dilute either. This is the best case for task arithmetic and it is why no sign election, no DARE/TIES pruning, and no interference resolution is needed: there is no interference to resolve.
The second number is the warning that was underweighted. The Terse displacement is 1.98x larger than everything v1's three-way DELLA merge did. At coefficient 0.5 the injected edit is roughly the same size as v1's entire merge, and the resulting total displacement is
|| delta_out || / || delta_v1 || = sqrt(1 + (0.5 * 1.98)^2 + 2 * 0.5 * 1.98 * 0.0003) = 1.41
The coefficient ladder computed before the run only went up to 1.217 (coefficient 0.35)
and 1.116 (coefficient 0.25). The value shipped here, 0.5, is above the range that was
tabulated as reasonable. The hard-set regression is consistent with that.
What did not work: the geodesic path
The original plan was more ambitious, and failed in an informative way. Documented here because a negative result on a real 27B is worth more than silence.
The hypothesis. maldv/Qwen3.6-27B-Isometry-Terse is named for an isometric edit. If
the edit is genuinely a left-multiplied orthogonal map,
W_terse = M @ W_base , M orthogonal, M = I + Q (R - I) Q^T
then you can recover R by orthogonal Procrustes on a small basis Q of
colspace(W_terse - W_base), take a fractional matrix power R^t via Schur
decomposition, and fold a partial rotation into v1:
W_out = W_v1 + Q (R^t - I) Q^T W_v1
The attraction: the left factor stays orthogonal, so ||W_out||_F == ||W_v1||_F holds
exactly, per tensor. The singular value spectrum is preserved. v1's capability is
rotated rather than averaged away, so there is no dilution term at all.
The necessary condition passed. Per-tensor norm ratios ||W_terse|| / ||W_base||
measured 1.000018 to 1.001891. The isometry claim is true to about 1e-3.
The sufficient condition failed, badly. Orthogonal Procrustes on 10 probe tensors:
| Tensor | rank r | res (best rotation) | res0 (identity) | explained | median angle |
|---|---|---|---|---|---|
layers.0.mlp.down_proj |
249 | 0.1267 | 0.1302 | 2.7% | 0.23 deg |
layers.0.mlp.gate_proj |
278 | 0.3676 | 0.3812 | 3.6% | 1.45 deg |
layers.0.mlp.up_proj |
282 | 0.3691 | 0.3806 | 3.0% | 1.48 deg |
layers.42.mlp.down_proj |
597 | 0.0724 | 0.0735 | 1.5% | 0.12 deg |
layers.0.linear_attn.in_proj_qkv |
832 | 0.0181 | 0.0191 | 5.2% | 0.05 deg |
layers.19.self_attn.o_proj |
832 | 0.0503 | 0.0525 | 4.1% | 0.11 deg |
layers.31.self_attn.q_proj |
337 | 0.1555 | 0.1610 | 3.4% | 0.48 deg |
res0 is the residual of doing nothing. res is the residual after fitting the optimal
orthogonal matrix. They are the same to within a few percent: the best possible rotation
explains 1.5-5.2% of the edit. The gate required 50%.
It is not a rank-truncation artifact. A rank ladder on gate_proj layer 0 separates
the two explanations cleanly:
| r | energy captured | explained by rotation |
|---|---|---|
| 8 | 71.1% | 0.6% |
| 32 | 89.2% | 1.8% |
| 128 | 98.2% | 2.6% |
| 278 (full) | 100.0% | 3.6% |
The subspace is captured completely. The rotation still explains nothing. Fitting a right-multiplied map instead of a left-multiplied one changes the numbers slightly and the conclusion not at all.
The lesson. Norm preservation does not imply rotation. In a 5120 x 17408 weight
matrix, any perturbation that happens to be near-orthogonal to W preserves ||W|| to
second order, and near-orthogonality is generic in high dimensions. Checking
||W_edited|| / ||W_base|| ~ 1 is a necessary condition so weak that it is nearly free.
The Procrustes residual is the test that has teeth, and "Isometry" in an upstream repo
name should be read as a description of how the authors built it, not as a promise
about the composite map.
So all 400 tensors took the documented linear fallback. The final tally:
ROT 0 LINEAR 400 NOOP 0 passthrough 799
Verification
| Check | Result |
|---|---|
| Tensor-by-tensor reconciliation vs v1 | 1199/1199, 0 missing, 0 extra, 0 shape mismatch, 0 dtype change |
| Shards | 26, layout reused from v1 so index.json is byte-identical |
| dtype | BF16 throughout |
| Non-finite values | assert torch.isfinite(out).all() on every tensor, 0 failures |
| Skipped tensors | none |
AutoConfig / AutoTokenizer round-trip |
Qwen3_5Config, 248077-token vocab, chat template present |
Per-tensor norm ratios ||W_out|| / ||W_v1|| landed between 1.000029 and 1.000592 across
all 400 edited tensors, i.e. the edit is small in Frobenius terms even though its
behavioral effect is large.
config.jsonreportsmodel_type: qwen3_5andQwen3_5Config. This is correct and inherited from official Qwen3.6-27B, which reuses the 3.5 modeling code. Do not "fix" it; editing it will break loading.
Usage
vLLM
from vllm import LLM, SamplingParams
from transformers import AutoTokenizer
M = "YFC-112358/Qwen3.6-27B-Della-Deckard-Terse-v2"
tok = AutoTokenizer.from_pretrained(M)
llm = LLM(model=M, max_model_len=16384, gpu_memory_utilization=0.90)
sp = SamplingParams(temperature=0.6, top_p=0.95, top_k=20, max_tokens=8192)
prompt = tok.apply_chat_template(
[{"role": "user", "content": "A train travels 120 km in 1.5 hours. What is its average speed?"}],
tokenize=False, add_generation_prompt=True,
)
print(llm.generate([prompt], sp)[0].outputs[0].text)
Transformers
from transformers import AutoModelForCausalLM, AutoTokenizer
M = "YFC-112358/Qwen3.6-27B-Della-Deckard-Terse-v2"
tok = AutoTokenizer.from_pretrained(M)
model = AutoModelForCausalLM.from_pretrained(M, dtype="auto", device_map="auto")
msgs = [{"role": "user", "content": "Explain the CAP theorem in three sentences."}]
ids = tok.apply_chat_template(msgs, add_generation_prompt=True, return_tensors="pt").to(model.device)
out = model.generate(ids, max_new_tokens=2048, temperature=0.6, top_p=0.95, top_k=20)
print(tok.decode(out[0][ids.shape[-1]:], skip_special_tokens=True))
Standard Qwen3.6 chat template. max_tokens can be set far lower than for the base
model; on GSM8K the longest of 20 completions was 222 tokens.
Limitations
- Hard-problem regression. Gates 3 and 4 above both failed. Do not use this for demanding reasoning without running your own evaluation.
- Small evaluation. 20 GSM8K questions at 1 sample, 10 hard questions at 4 samples. Enough to establish the length effect, not enough to rank accuracy.
- The coefficient is above the tabulated safe range. 0.5 versus a ladder that stopped at 0.35.
- No multimodal evaluation. Vision weights are untouched; the language model is not.
- No safety evaluation. The upstream Terse model folds in a stated uncensored source. Behavior on refusals and unsafe prompts relative to official Qwen3.6 has not been characterized. Do not deploy without your own testing.
- No long-context, coding, tool-use, or multilingual evaluation.
- Built by hand, not with mergekit. The mergekit-equivalent recipe would be
task_arithmeticwith baseQwen/Qwen3.6-27B, v1 at weight 1.0 and Terse at weight 0.5, restricted to 2-D projection tensors. That configuration was not used and has not been verified to reproduce this repo.
Recommended next run
For anyone continuing this line, including the author:
T_LINis the only coefficient that affects the output.T,R_CAP,TOL_REL,EXPL_GATE, andRES_GATEgovern the rotation path, which never executed. ChangingTdoes nothing. This is easy to get wrong when reading the notebook.- Try
T_LIN = 0.30. The pre-computed ladder puts total displacement at ~1.16x v1's, inside the tabulated range, versus 1.41x here. The likely outcome is hard-set think length back above 300 tokens while keeping most of the GSM8K compression. - Widen the hard set before trusting any accuracy delta. 10 questions x 4 samples cannot resolve 7 percentage points. 30+ questions, and add a length-sensitive suite.
- Consider a per-layer coefficient. Compression this aggressive from a uniform coefficient suggests late layers may tolerate more than early ones.
Credits
Qwen/Qwen3.6-27B- Qwen team, base model and vision towermaldv/Qwen3.6-27B-Isometry-Terse- the terseness task vector; 7 reasoning finetunes plus an output-projection overlayYFC-112358/Qwen3.6-27B-Della-Deckard-v1- the host, itself a DELLA merge of a reasoning-distill LoRA andnerkyor/Qwen3.6-27B-DSV4Pro-Thinking-Distill, plus a cross-generation task vector fromnightmedia/Qwen3.5-27B-Engineer-Deckard-Gemini
Built on Colab free tier: 12.7 GB RAM, no GPU, 155 GB streamed over HTTP Range requests, never holding more than about 1 GB of tensor in memory. Evaluation cost roughly 5 USD of A100 time.
中文说明
这是什么
把 maldv/Qwen3.6-27B-Isometry-Terse 相对官方 Qwen/Qwen3.6-27B 的任务向量,
以系数 0.5 线性叠加到 Della-Deckard-v1 上,只作用于 400 个二维投影权重,
其余 799 个张量逐字节沿用 v1。
W_out = W_v1 + 0.5 * (W_terse - W_base)
没有剪枝,没有符号选举,没有旋转。
核心结果
GSM8K 思考长度:官方 1133.5 → v1 539.5 → 本仓 76.0 token,相对官方压缩 14.9 倍, 相对 v1 压缩 7.1 倍,正确率没有下降(0.75 → 0.85,但 n=20,只能说"未见损失")。
代价写在明面上:难题集正确率 0.800 → 0.725,思考长度 359 → 176。 作者自己预设的五条验收线里,第 3 条(难题正确率不低于 v1 减 3 个百分点)和 第 4 条(难题思考长度不低于 400 token)都没过。样本量很小(10 题 × 4 次采样, 差距只有 3 次生成),但方向与长度坍缩一致,属于过度压缩的典型信号,所以照实写出来。
适合:批量短答、延迟敏感、成本敏感的场景。 不适合:竞赛数学、多跳推理、长链 agent。这类任务请用 v1 或官方版。 未知:全部视觉能力,本次一次多模态评测都没跑。
为什么直接线性相加是安全的
实测 cos(v1 的位移, Terse 的位移) = +0.0003,夹角 89.98 度,
而同尺寸随机向量的基线是 ±0.008~0.014。两个编辑正交到噪声以内,
各自占据独立子空间,相加不会互相覆盖。这正是任务算术最理想的情形,
也是本仓不需要任何冲突消解机制的原因——根本没有冲突。
但第二个数是被低估的警告:|Δ_terse| / |Δ_v1| = 1.98。
Terse 的位移是 v1 整个三路 DELLA 合并的近两倍。系数取 0.5 时,
总位移达到 v1 的 1.41 倍,而事先算好的系数阶梯只列到 0.35(1.217 倍)。
发布的这个系数超出了自己论证过的安全区间,难题集的退步与此一致。
没成功的那条路(值得看)
原计划要做的是「等距测地线折入」:假设 W_terse = M · W_base(M 正交),
用正交 Procrustes 解出 M,再取分数幂 M^t 折进 v1。好处是左因子仍正交,
逐张量 Frobenius 范数与 v1 精确相等,奇异值谱不变,v1 的能力被旋转而不是被平均稀释。
必要条件通过了:逐张量范数比实测 1.000018 ~ 1.001891,等距声明在 1e-3 量级上成立。
充分条件惨败:最优正交矩阵只能解释这个编辑的 **1.5% ~ 5.2%**(门槛是 50%)。
res(转完的残差)和 res0(什么都不做的残差)几乎一样。
秩阶梯进一步排除了「截断不够」这个解释——r 从 8 加到 278,能量捕获从 71% 到 **100%**,
解释率只从 0.6% 爬到 **3.6%**。左乘换右乘,结论不变。
教训:范数守恒不等于旋转。 在 5120×17408 这种尺度上,
任何与 W 近似正交的扰动都会二阶保范数,而高维空间里近似正交是常态。
查 ||W_edited|| / ||W_base|| ≈ 1 是一个弱到几乎免费的必要条件;
真正有鉴别力的是 Procrustes 残差。上游仓库名里的 "Isometry"
应当理解为作者的构造方式,而不是对复合映射的承诺。
最终统计:ROT 0 / LINEAR 400 / NOOP 0 / 直通 799。
关于命名
本仓由一个名为 Isometry-Geodesic 的 notebook 构建,早先自动生成的卡片 把它描述成测地线极分解合并——那个描述是错的,因为 400 个张量全部走了线性退路。 本仓不含任何等距或测地线成分,卡片已重写。
复现与调参提示
- 只有
T_LIN影响输出。T/R_CAP/TOL_REL/EXPL_GATE/RES_GATE全部服务于从未执行的旋转分支,改T不会有任何效果。读 notebook 时极易搞错。 - **建议下一轮试
T_LIN = 0.30**,总位移约 1.16 倍,落回论证过的区间。 - 难题集扩到 30 题以上再谈正确率差异,当前样本量分辨不了 7 个百分点。
- Downloads last month
- 100