今天聊一個讓我拍案叫絕的社區(qū)實(shí)驗(yàn)——有人把兩個 9B 模型的層直接堆在一起，拼成了一個 18B 模型，然后用 1000 步 LoRA"縫合"了一下……結(jié)果居然吊打了 Qwen 3.6-35B MoE，而且只要一半的顯存。

關(guān)于 Jackrong 的模型系列，老讀者應(yīng)該不陌生了，我之前多次介紹過：

什么是 Frankenmerge？

先解釋一下這個野路子

Frankenmerge是社區(qū)發(fā)明的一種模型合并方式，靈感來自弗蘭肯斯坦——把不同模型的"身體部位"拼在一起，看能不能造出一個更強(qiáng)的"怪物"

具體做法非常直接暴力：把模型 A 的全部 32 層和模型 B 的全部 32 層首尾相連，疊成一個 64 層的新模型，嵌入層和輸出頭用其中一個模型的就行

直接把兩個模型拼在一起，第 32 層到第 33 層的接縫處會產(chǎn)生嚴(yán)重的分布不匹配——就像把兩段不同口徑的水管硬焊在一起，水流經(jīng)過接口時會亂成一團(tuán)

但這次的實(shí)驗(yàn)者 Kyle Hessling 有一招妙手：他精心挑選了兩個同源但不同方向的模型來拼接，然后用 1000 步 QLoRA 做了一次"縫合手術(shù)"

兩個源模型：同源不同路

兩個被拼在一起的模型都出自 Jackrong 之手，都基于 Qwen3.5-9B，但走了完全不同的蒸餾方向：

前半部分（Layer 0-31）：Qwopus3.5-9B-v3.5

這是 Jackrong 的看家之作，用 Claude Opus 的推理數(shù)據(jù)做蒸餾，走的是"先行動、再糾錯"的 act-then-refine 路線：

• 比 v3 多了一倍的 SFT 數(shù)據(jù)

• 強(qiáng)項(xiàng)在 agentic 工具調(diào)用、代碼生成、token 高效推理

• 27B 版本在 MMLU-Pro 上達(dá)到 90.36%

• 44 項(xiàng) SWE 測試通過 43 項(xiàng)（97.7%）

后半部分（Layer 32-63）：Qwen3.5-9B-GLM5.1-Distill-v1

這個模型走的是 GLM-5.1 蒸餾路線，風(fēng)格完全不同：

• 訓(xùn)練數(shù)據(jù)來自 GLM-5.1 教師模型，約 100 萬條推理數(shù)據(jù)（清洗后）

• 強(qiáng)項(xiàng)在結(jié)構(gòu)化任務(wù)分解、問題拆解、推理組織

• 推理范式是"理解任務(wù)→分解問題→逐步推理→構(gòu)建答案"

兩個模型的推理風(fēng)格形成了互補(bǔ)：

維度

Qwopus v3.5（Opus 風(fēng)格）

GLM5.1 Distill（GLM 風(fēng)格）

推理方式

先行動再糾正

先分解再推理

長處

工具調(diào)用、代碼生成

任務(wù)理解、答案組織

風(fēng)格

靈活、高效

結(jié)構(gòu)化、穩(wěn)定

作者的假設(shè)是：更深的網(wǎng)絡(luò) + 多樣化的推理訓(xùn)練 = 更強(qiáng)大、更魯棒的模型。

縫合手術(shù)：1000 步 QLoRA

直接拼出來的模型有個嚴(yán)重問題：代碼輸出是亂的

HTML 標(biāo)簽不閉合、CSS 花括號不配對、JS 括號丟失——因?yàn)榈?32 層和第 33 層之間的特征分布斷裂，結(jié)構(gòu)化輸出經(jīng)過這個"傷口"時就會變形。

解決方案非常優(yōu)雅：用 1000 步 QLoRA 做了一次"縫合修復(fù)"（Heal Fine-Tune）

訓(xùn)練配置：

配置項(xiàng)

方法

QLoRA（4-bit NF4）

LoRA rank

64

目標(biāo)模塊

所有 attention + MLP 投影

訓(xùn)練數(shù)據(jù)

Jackrong 的推理數(shù)據(jù)（70%）+ 競賽編程（15%）+ 多輪對話（15%）

訓(xùn)練步數(shù)

1000 步

Batch size

8

學(xué)習(xí)率

2e-5，cosine 調(diào)度

訓(xùn)練時間

~14 小時（RTX 5090）

Loss 下降

1.02 → 0.62（下降 39%）

Loss 下降 39%，說明第 32 層的接縫確實(shí)是一個真實(shí)的誤差源，訓(xùn)練能有效修復(fù)它。

修復(fù)效果立竿見影：

• 編程測試從 11/15 恢復(fù)到 12/15

• HTML/CSS 輸出變得干凈整潔

• 總分從 39/44 提升到 40/44

這是最讓我震驚的部分

一個 9.2GB 的 Q4_K_M 量化模型，在 44 項(xiàng)測試中拿到了40/44（90.9%），而全新發(fā)布的 Qwen 3.6-35B-A3B MoE（Q4_K_M，22GB）只拿到了38/44（86.4%）

測試類別

Qwopus 9B（源模型）

Qwopus-GLM-18B（縫合版）

Qwen 3.6-35B MoE

基礎(chǔ)生成

6/6

6/6

5/6

推理

4/4

4/4

4/4

工具調(diào)用

6/6

6/6

6/6

Agent 任務(wù)

4/4

4/4

4/4

結(jié)構(gòu)化輸出

2/2

2/2

2/2

上下文處理

2/3

2/3

2/3

多語言

2/2

2/2

2/2

編程

13/15

12/15

12/15

性能

2/2

2/2

1/2

總計41/44（93.2%）40/44（90.9%）38/44（86.4%）

推理速度

126.0 tok/s

66.0 tok/s

174.2 tok/s

GGUF 大小

5.3 GB

9.2 GB

22 GB

幾個值得注意的點(diǎn)：

1. 工具調(diào)用 6/6 滿分——單次調(diào)用、可選參數(shù)、工具選擇、復(fù)雜參數(shù)、響應(yīng)處理全過

2. Agent 推理 4/4 滿分——計劃生成、多步工具工作流、錯誤恢復(fù)、自我糾正全過

3. 中文輸出密度最高——129-138 個 CJK 字符，超過了所有測試模型

4. 推理速度 66 tok/s，比源模型慢了一半（畢竟層數(shù)翻倍了），但仍然實(shí)用

5. 12GB 顯存就能跑——RTX 3060/4070 這種消費(fèi)級顯卡直接上

作者還做了一組非常硬核的前端代碼生成測試——6 個越來越復(fù)雜的 HTML/CSS/JS 任務(wù)：

測試任務(wù)

檢查項(xiàng)

通過

輸出大小

天氣儀表盤

響應(yīng)式、CSS 變量、暗色模式、5日預(yù)報

9/9

14.5K

電商產(chǎn)品頁

圖片畫廊、顏色選擇器、標(biāo)簽頁、粘性底欄

12/12

16.7K

SaaS 落地頁

漸變動畫、打字效果、滾動動畫、輪播、定價卡

13/13

24.1K

數(shù)據(jù)分析儀表盤

SVG 柱圖、環(huán)形圖、可排序表格、折疊側(cè)欄

13/13

22.3K

多步注冊表單

3步向?qū)?、?shí)時校驗(yàn)、密碼強(qiáng)度、狀態(tài)下拉框

12/12

23.3K

貪吃蛇游戲

Canvas 循環(huán)、方向鍵、碰撞檢測、本地存儲

11/12

11.2K

總計62/63（98.4%）

62/63 項(xiàng)檢查通過，唯一的失敗是貪吃蛇游戲在最后一個閉合標(biāo)簽寫成了html>。

所有 6 個文件做到了：

• CSS 花括號完美配對（零失衡）

• JS 括號完美配對（零失衡）

• 零亂碼或幻覺文本

• 功能可運(yùn)行——暗色模式、滾動動畫、SVG 圖表、表單驗(yàn)證、Canvas 游戲循環(huán)全部工作

這對一個"兩個 9B 拼起來再縫 1000 步"的模型來說，屬實(shí)驚人

模型架構(gòu)

屬性

總層數(shù)

64（32 + 32）

總參數(shù)

~18B

Hidden Size

4096

注意力頭

16（4 個 KV 頭，GQA）

中間層維度

上下文長度

262,144 tokens

注意力類型

混合（線性 + 全注意力，每 4 層一個全注意力）

GGUF Q4_K_M

9.2 GB

層的組成：

Layer  0-31:  Qwopus3.5-9B-v3.5         (Claude Opus 推理蒸餾)
Layer 32-63:  Qwen3.5-9B-GLM5.1-Distill-v1  (GLM-5.1 推理蒸餾)


 嵌入層、LM Head、MTP、視覺編碼器：來自 Qwopus3.5-9B-v3.5

推薦用 llama.cpp：

llama-server \
    -m Qwopus-GLM-18B-Healed-Q4_K_M.gguf \
    --chat-template-file your-qwen35-template.jinja \
    --ctx-size 65536 \
    --flash-attn on \
    --n-gpu-layers 99

下載地址：https://huggingface.co/Jackrong/Qwopus-GLM-18B-Merged-GGUF

9.2GB 的 Q4_K_M 文件，12GB 顯存的消費(fèi)級顯卡就能跑

我的看法

說說我的真實(shí)感受。

讓我興奮的地方：

1. 想法太朋克了。把兩個模型的層直接堆在一起——這種做法在學(xué)術(shù)界基本不會有人認(rèn)真去做，但社區(qū)開發(fā)者就是敢想敢試。更關(guān)鍵的是，它真的 work 了。

2. 兩個源模型的互補(bǔ)性選得很好。Opus 風(fēng)格擅長靈活執(zhí)行和代碼生成，GLM 風(fēng)格擅長結(jié)構(gòu)化分解和答案組織。把這兩種推理范式堆在一起，等于給模型裝了兩套不同的"思維引擎"。這不是隨便拼兩個模型就能達(dá)到的效果。

3. 1000 步修復(fù)的性價比極高。RTX 5090 上跑 14 小時，loss 降了 39%，編程能力恢復(fù)了 1 個測試點(diǎn)，HTML 輸出從亂碼變成了生產(chǎn)級質(zhì)量。這說明層邊界的不匹配是一個可定位、可修復(fù)的問題，不需要從頭訓(xùn)練。

4. 9.2GB 打贏 22GB。這對顯存有限的開發(fā)者來說是個巨大的好消息。RTX 3060 就能跑一個比 Qwen 3.6-35B MoE 更強(qiáng)的模型。

我的顧慮：

1. 評測套件不夠標(biāo)準(zhǔn)化。44 項(xiàng)測試是自建的，覆蓋面雖然廣但沒有用社區(qū)公認(rèn)的 benchmark（比如 MMLU、HumanEval、LiveCodeBench）。作者自己也說了"未經(jīng)過完整或全面的評估"。

2. 編程任務(wù)還有 3 個沒過。函數(shù)命名問題、JS 括號丟失、pytest 代碼塊格式錯誤——這些都是合并留下的"傷疤"。雖然 1000 步修復(fù)了大部分問題，但結(jié)構(gòu)化輸出的穩(wěn)定性還需要更多驗(yàn)證。

3. 推理速度減半。從 126 tok/s 降到 66 tok/s，層數(shù)翻倍帶來的計算開銷是實(shí)打?qū)嵉?。對延遲敏感的場景需要考慮這個代價。

4. 可復(fù)現(xiàn)性存疑。這個實(shí)驗(yàn)的成功高度依賴兩個源模型的"互補(bǔ)性"和那 1000 步的修復(fù)訓(xùn)練。換兩個別的模型來拼，大概率不會有這么好的效果。

更深層的啟發(fā)：

這個項(xiàng)目最有價值的發(fā)現(xiàn)可能不是模型本身，而是它背后的兩個洞察：

第一，推理能力可以通過層疊加來組合。兩個 9B 模型各自學(xué)到了不同風(fēng)格的推理模式，簡單堆疊后這些模式居然能協(xié)同工作。這暗示了推理能力可能比我們想象的更"模塊化"。

第二，層邊界的不匹配是可修復(fù)的。只需要 1000 步的輕量訓(xùn)練就能讓兩個獨(dú)立訓(xùn)練的模型"握手"。這為未來的模型組合和按需拼裝打開了想象空間。

.5

制作不易，如果這篇文章覺得對你有用，可否點(diǎn)個關(guān)注。給我個三連擊：點(diǎn)贊、轉(zhuǎn)發(fā)和在看。若可以再給我加個，謝謝你看我的文章，我們下篇再見！