大模型世界的縫合怪，兩個9B拼成18B，吊打Qwen3.6-35B

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

關于 Jackrong 的模型系列，老讀者應該不陌生了，我之前多次介紹過：

什么是 Frankenmerge？

先解釋一下這個野路子

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

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

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

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

兩個源模型：同源不同路

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

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

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

• 比 v3 多了一倍的 SFT 數據

• 強項在 agentic 工具調用、代碼生成、token 高效推理

• 27B 版本在 MMLU-Pro 上達到 90.36%

• 44 項 SWE 測試通過 43 項（97.7%）

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

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

• 訓練數據來自 GLM-5.1 教師模型，約 100 萬條推理數據（清洗后）

• 強項在結構化任務分解、問題拆解、推理組織

• 推理范式是"理解任務→分解問題→逐步推理→構建答案"

兩個模型的推理風格形成了互補：

維度

Qwopus v3.5（Opus 風格）

GLM5.1 Distill（GLM 風格）

推理方式

先行動再糾正

先分解再推理

長處

工具調用、代碼生成

任務理解、答案組織

風格

靈活、高效

結構化、穩定

作者的假設是：更深的網絡 + 多樣化的推理訓練 = 更強大、更魯棒的模型。

縫合手術：1000 步 QLoRA

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

HTML 標簽不閉合、CSS 花括號不配對、JS 括號丟失——因為第 32 層和第 33 層之間的特征分布斷裂，結構化輸出經過這個"傷口"時就會變形。

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

訓練配置：

配置項

方法

QLoRA（4-bit NF4）

LoRA rank

64

目標模塊

所有 attention + MLP 投影

訓練數據

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

訓練步數

1000 步

Batch size

8

學習率

2e-5，cosine 調度

訓練時間

~14 小時（RTX 5090）

Loss 下降

1.02 → 0.62（下降 39%）

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

修復效果立竿見影：

• 編程測試從 11/15 恢復到 12/15

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

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

這是最讓我震驚的部分

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

測試類別

Qwopus 9B（源模型）

Qwopus-GLM-18B（縫合版）

Qwen 3.6-35B MoE

基礎生成

6/6

6/6

5/6

推理

4/4

4/4

4/4

工具調用

6/6

6/6

6/6

Agent 任務

4/4

4/4

4/4

結構化輸出

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

幾個值得注意的點：

1. 工具調用 6/6 滿分——單次調用、可選參數、工具選擇、復雜參數、響應處理全過

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

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

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

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

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

測試任務

檢查項

通過

輸出大小

天氣儀表盤

響應式、CSS 變量、暗色模式、5日預報

9/9

14.5K

電商產品頁

圖片畫廊、顏色選擇器、標簽頁、粘性底欄

12/12

16.7K

SaaS 落地頁

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

13/13

24.1K

數據分析儀表盤

SVG 柱圖、環形圖、可排序表格、折疊側欄

13/13

22.3K

多步注冊表單

3步向導、實時校驗、密碼強度、狀態下拉框

12/12

23.3K

貪吃蛇游戲

Canvas 循環、方向鍵、碰撞檢測、本地存儲

11/12

11.2K

總計62/63（98.4%）

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

所有 6 個文件做到了：

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

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

• 零亂碼或幻覺文本

• 功能可運行——暗色模式、滾動動畫、SVG 圖表、表單驗證、Canvas 游戲循環全部工作

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

模型架構

屬性

總層數

64（32 + 32）

總參數

~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 顯存的消費級顯卡就能跑

我的看法

說說我的真實感受。

讓我興奮的地方：

1. 想法太朋克了。把兩個模型的層直接堆在一起——這種做法在學術界基本不會有人認真去做，但社區開發者就是敢想敢試。更關鍵的是，它真的 work 了。

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

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

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

我的顧慮：

1. 評測套件不夠標準化。44 項測試是自建的，覆蓋面雖然廣但沒有用社區公認的 benchmark（比如 MMLU、HumanEval、LiveCodeBench）。作者自己也說了"未經過完整或全面的評估"。

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

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

4. 可復現性存疑。這個實驗的成功高度依賴兩個源模型的"互補性"和那 1000 步的修復訓練。換兩個別的模型來拼，大概率不會有這么好的效果。

更深層的啟發：

這個項目最有價值的發現可能不是模型本身，而是它背后的兩個洞察：

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

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

.5

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