今天聊一个让我拍案叫绝的社区实验——有人把两个 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 打赢 22GB

这是最让我震惊的部分

一个 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 这种消费级显卡直接上

前端代码压力测试:98.4% 通过率

作者还做了一组非常硬核的前端代码生成测试——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

制作不易,如果这篇文章觉得对你有用,可否点个关注。给我个三连击:点赞、转发和在看。若可以再给我加个,谢谢你看我的文章,我们下篇再见!