qwen3.5-27B+lora静态合并

核心结论

在合并 Qwen3.5 LoRA 权重时，基础模型必须使用：

Qwen3_5ForConditionalGeneration

不可使用：

Qwen3_5ForCausalLM

合并完成后，需要检查导出的模型 config.json，确认继续保留 architectures 参数，并且值为：

"architectures": ["Qwen3_5ForConditionalGeneration"]

如果该字段缺失，或者被写成了 Qwen3_5ForCausalLM，后续使用合并模型时可能会加载到错误的模型类。

为什么必须使用 Qwen3_5ForConditionalGeneration

LoRA 合并不是简单地把两个文件复制到一起，而是先加载基础模型，再把 LoRA adapter 挂载到这个基础模型实例上，最后执行：

model = model.merge_and_unload()

因此，合并时使用的基础模型类会直接决定以下内容：

• 基础模型的模块结构
• LoRA 权重应该注入到哪些层
• 合并后权重名称和模块名称是否匹配
• 保存出来的 config.json 如何描述模型架构
• 后续推理框架或 AutoModel 类如何重新识别这个模型

当前脚本中正确的加载方式是：

from transformers import AutoProcessor, Qwen3_5ForConditionalGeneration

model = Qwen3_5ForConditionalGeneration.from_pretrained(
    base_model_path,
    dtype=torch.bfloat16,
    device_map="cpu",
    trust_remote_code=True,
    local_files_only=True,
    low_cpu_mem_usage=True,
)

Qwen3_5ForConditionalGeneration 表示该模型的完整条件生成架构。它通常不仅仅包含普通文本 causal language model 的部分，还会和模型自身的处理器、生成接口、特殊输入格式、配置元数据保持一致。

如果原始基础模型的配置里声明的就是 Qwen3_5ForConditionalGeneration，合并时也应该继续使用这个类。这样可以保证：

• 加载出来的模型结构和原始模型一致
• LoRA adapter 的目标模块可以正确对应
• merge_and_unload() 合并的是正确对象
• save_pretrained() 保存出的模型元数据和实际权重结构一致
• 后续加载模型时不会因为架构字段错误而选错模型类

LLaMA Factory 静态合并遇阻原因

本次合并最开始尝试过使用 LLaMA Factory 的静态合并能力，但在 Qwen3.5-27B 上遇到了阻塞。结合现象来看，问题重点不只是 LoRA 权重本身，而是 LLaMA Factory 内部依赖的 Transformers 加载链路没有正确满足这个模型的合并需求。

具体表现可以理解为：

• Qwen3.5-27B 需要按 Qwen3_5ForConditionalGeneration 架构加载
• LLaMA Factory 静态合并流程更依赖框架内部的自动模型识别和通用合并逻辑
• 即使把 LLaMA Factory 环境中的 Transformers 升级到较新的版本，也没有覆盖或正确适配这次 Qwen3.5-27B 所需的合并路径
• 最终导致静态合并阶段无法稳定按正确模型类完成加载、合并和保存

所以这次没有继续依赖 LLaMA Factory 静态合并，而是改用独立脚本，显式指定：

Qwen3_5ForConditionalGeneration.from_pretrained(...)

这样做的核心目的是绕开自动识别可能选错架构的问题，直接让合并过程从一开始就绑定到正确的模型类。对于 Qwen3.5-27B 这种对模型类和配置字段比较敏感的模型，显式加载比依赖通用静态合并流程更可控。

简要总结：本次遇阻的主要原因是 LLaMA Factory 静态合并链路中，即便使用较新的 Transformers，也没有满足 Qwen3.5-27B 对 Qwen3_5ForConditionalGeneration 架构的合并要求。因此需要使用自定义合并脚本，并在合并后确认 config.json 中的 architectures 仍然是 Qwen3_5ForConditionalGeneration。

architectures 参数的作用

config.json 中的 architectures 是模型目录的关键元数据。它不是装饰字段，而是告诉 Transformers 或其他兼容加载器：

"architectures": ["Qwen3_5ForConditionalGeneration"]

含义是：这个模型目录应该按 Qwen3_5ForConditionalGeneration 这个架构加载。

或者推理服务内部自动读取模型目录，加载器依赖 architectures、model_type、auto_map 等配置字段来决定具体模型类。

所以合并后必须检查：

"architectures": ["Qwen3_5ForConditionalGeneration"]

最终判断标准

一次正确的 Qwen3.5 LoRA 合并应该满足：

• 合并脚本使用 Qwen3_5ForConditionalGeneration.from_pretrained(...)
• PeftModel.from_pretrained(...) 挂载 LoRA adapter 时没有模块不匹配错误
• merge_and_unload() 能正常执行
• model.save_pretrained(...) 和 processor.save_pretrained(...) 都正常完成
• 导出的 config.json 中保留：

"architectures": ["Qwen3_5ForConditionalGeneration"]

只要合并后的模型目录仍然声明为 Qwen3_5ForConditionalGeneration，后续加载和推理阶段就更容易和原始基础模型保持一致，避免因为模型类识别错误导致的加载失败或推理异常。