Qwen3.8-27B 能加 LoRA 吗：框架声明了七个可适配模块

2026-08-24

「Qwen3.8-27B 能不能微调」这个问题，如果指的是全参数微调，那是硬件和数据的问题，本文回答不了。

但如果指的是 LoRA 这类参数高效微调，推理框架的源码里其实有明确答案——它们会声明这个模型的哪些模块支持挂载适配器。这份清单不是推测，是代码里写死的。

这篇读那份清单，以及它透露的几个信息。

这篇的依据和边界

来源是 SGLang 和 vLLM 主干仓库里 Qwen3.5 系列的实现代码，采集时间 2026-08-24。

必须先说清楚边界：本文讲的是推理框架对 LoRA 适配器的加载支持，不是训练侧的可行性。

我们没有训练过任何适配器、没有加载过 LoRA、没有跑过微调。 本文不会出现「微调需要多少显存」「几张卡够用」「训练要多久」这类说法——那些需要实测，我们没做。

那份清单

SGLang 的实现里，这个类属性列出了七个模块：

supported_lora_modules = [
    "qkv_proj",
    "o_proj",
    "out_proj",
    "in_proj_qkvz",
    "gate_up_proj",
    "down_proj",
    "lm_head",
]

按功能分组来看，会清楚很多。

全注意力层相关的两个：qkv_proj 是 Q、K、V 三个投影的融合，o_proj 是输出投影。这是 LoRA 最经典的挂载位置。

线性注意力层相关的两个：in_proj_qkvz 和 out_proj。前者是 Gated DeltaNet 的输入投影融合体，后者是它的输出投影。

前馈网络的两个：gate_up_proj 是 gate 和 up 两个投影的融合，down_proj 是降维投影。

输出头一个：lm_head。

值得注意的一：线性注意力层也能挂

in_proj_qkvz 出现在这份清单里，这件事挺有意义。

Qwen3.8-27B 的 64 层里，48 层是线性注意力，只有 16 层是全注意力。如果 LoRA 只能挂在全注意力层上，那它只能覆盖四分之一的层——对微调效果的影响可想而知。

清单里有 in_proj_qkvz 和 out_proj，说明那 48 层线性注意力也在可适配范围内。这对这个架构来说是必要的：混合注意力模型如果只能微调其中一种层，那这个「混合」就成了负担而不是优势。

值得注意的二：有一个相关模块不在清单里

前面写过，vLLM 的权重映射里，线性注意力那一支有两个融合投影（见权重名字怎么对上框架）：

in_proj_qkvz，由 in_proj_qkv 和 in_proj_z 拼成
in_proj_ba，由 in_proj_b 和 in_proj_a 拼成

LoRA 清单里只有前者，没有 in_proj_ba。

源码没有解释为什么。从功能上推测，in_proj_qkvz 承载的是 Q、K、V 和门控 z，是主要的特征投影；而 in_proj_ba 对应的 a、b 从命名看更像是状态更新的控制参数——这类参数的规模和性质与常规投影矩阵不同，未必适合用低秩分解去适配。

但这是推测。能确定的只有一条事实：这个模块不在框架声明的可适配清单里。 如果你的适配器配置里包含了它，加载时很可能出问题。

值得注意的三：输出头可以适配

lm_head 在清单里，vLLM 那边也有对应声明：

embedding_modules = {
    "embed_tokens": "input_embeddings",
    "lm_head": "output_embeddings",
}

注释说明这是把 PEFT 的嵌入与输出头 LoRA 目标映射到框架的嵌入包装器上。

能对输出头做 LoRA，在需要调整输出分布的场景下是有用的——比如让模型适应一批新的领域词汇。不是所有实现都开放这个位置。

值得一提的是这个模型的 tie_word_embeddings 是 false，也就是说 lm_head 是一份独立权重，不和输入嵌入共享。正因为不共享，单独适配 lm_head 才有意义——如果两者绑定，动一个就会影响另一个。

融合模块带来的一个实际问题

清单里的名字大多是融合后的模块名：qkv_proj、gate_up_proj、in_proj_qkvz。

而你用 PEFT 之类的工具训练适配器时，指定的目标模块往往是融合前的原始名字：q_proj、v_proj、gate_proj。

两套命名对不上，中间靠的就是 packed_modules_mapping 这份反查表：

packed_modules_mapping = {
    "qkv_proj": ["q_proj", "k_proj", "v_proj"],
    "gate_up_proj": ["gate_proj", "up_proj"],
    "in_proj_qkvz": ["in_proj_qkv", "in_proj_z"],
    "in_proj_ba": ["in_proj_b", "in_proj_a"],
}

框架靠它知道：qkv_proj 里装着 Q、K、V 三份，各占哪一段。适配器只训练了 Q 和 V 也没关系，按段放进去就行。

这对使用者的实际意义：如果你只对 q_proj 和 v_proj 训了适配器，加载到融合后的 qkv_proj 上是可行的，框架会处理位置对应。但如果你训练时用的模块名压根不在这个映射表里，那就对不上了。

所以训练前值得先看一眼这份表，确认你打算适配的模块名，在框架这边是能反查到的。

清单之外的一个观察：视觉塔不在里面

那七个模块名，对照一下会发现它们全都属于语言模型部分：注意力投影、线性注意力投影、前馈网络、输出头。

视觉塔相关的模块一个都没有。

这意味着按这份清单挂 LoRA，适配的是模型的语言能力，视觉编码部分不受影响。对多数场景这是合理的——你想让模型学会某个领域的表达方式或任务格式，改语言侧就够了；视觉塔负责的是「把图像翻译成向量」这件相对通用的事（结构见图像怎么变成 token）。

但如果你的需求是让模型适应某类特殊图像——比如医学影像、工业质检图这种和自然图像差别很大的输入——那么只调语言侧可能不够。这种情况下需要什么方案，超出了本文能依据源码回答的范围。

能确定的是：框架声明的这七个模块里没有视觉塔。 你的适配方案如果依赖调整视觉部分，得先确认所用工具链是否支持，别默认「加了 LoRA 就是整个模型都适配了」。

全参数微调这条路

前面都在说 LoRA。全参数微调本文不展开，只说三条能确定的事实。

一，权重是 Apache-2.0 的开源权重，许可上不禁止微调（细节见许可实读）。

二，这是个 27B 的稠密模型，全参数微调需要同时容纳权重、梯度、优化器状态，量级远超推理。具体需要什么配置取决于优化器选择、并行策略、是否用梯度检查点等等——本文不给数字，这类估算脱离具体方案没有意义。

三，它是多模态模型，微调时要考虑视觉塔和语言模型是不是都动。框架里这两部分是分开标记的，训练侧同样需要明确。

想估算资源，正确的做法是从推理侧的四笔账出发（见要多少显存），再按你选的训练方案叠加梯度和优化器状态。这个推导本文不做，因为它高度依赖你的具体配置。

小结

框架源码明确声明了七个支持 LoRA 的模块：qkv_proj、o_proj、out_proj、in_proj_qkvz、gate_up_proj、down_proj、lm_head
48 层线性注意力也在可适配范围内，不是只能动那 16 层全注意力
in_proj_ba 不在清单里，原因源码未说明
lm_head 可适配，且因为 tie_word_embeddings 为 false，单独适配它是有意义的
训练侧用原始模块名、框架侧用融合模块名，靠 packed_modules_mapping 对应
全参数微调的资源估算本文不给，那取决于你的具体训练方案

最实用的一条：动手前先去你要用的那个框架的源码里搜 supported_lora_modules。这份清单是权威的、是当下版本的、而且就那么几行——比在教程和论坛里找答案可靠得多。

更多拆解在 Qwen3.8-27B 专题。