只想用 Qwen3.8-27B 的文本能力：纯文本入口存在，但权重得换一份

2026-08-24

Qwen3.8-27B 是个多模态模型，能吃图像和视频。但很多实际场景根本用不上这些——你只想要一个文本模型，视觉塔那部分对你来说是纯粹的负担。

能不能只用文本那一半？

框架层面是支持的，三个主流框架都注册了纯文本入口。但真要走通这条路，关键不在启动参数，而在你手上是哪份权重。这篇把这件事讲清楚。

这篇的依据

来源是 Qwen/Qwen3.8-27B 的 config.json，以及 vLLM、SGLang、llama.cpp 三个仓库里的注册代码与注释。采集时间 2026-08-24。

我们没有加载过任何纯文本版本、没有做过对比测试。 下面讲的是配置字段与框架代码里的声明，不是运行结果。另外，本文不点名任何社区权重仓库——我们没有逐一核实过它们的来源与完整性。

框架这边：三家都留了纯文本入口

三个框架的注册情况是一致的。

vLLM 的 registry 里，Qwen3_5ForCausalLM 和 Qwen3_5ForConditionalGeneration 是两条并列的注册项，分别对应纯文本和多模态。

SGLang 更直观，它把两类入口放进了不同文件：qwen3_5.py 末尾声明的是 ForConditionalGeneration，qwen3_5_text.py 末尾声明的是 ForCausalLM（这个拆分方式见 SGLang 为什么写了三个文件）。

llama.cpp 用一个装饰器同时注册两个类名：

@ModelBase.register("Qwen3_5ForConditionalGeneration", "Qwen3_5ForCausalLM")

所以「框架支不支持纯文本」这个问题的答案是肯定的，而且三家都支持。

但入口不是你选的

关键在于：走哪个入口，由模型配置决定，不由你决定。

框架加载模型时读的是 config.json 顶层的 architectures 字段。Qwen/Qwen3.8-27B 官方那份写的是：

"architectures": ["Qwen3_5ForConditionalGeneration"]

多模态那个。 所以用官方权重启动，框架必然走多模态入口，把 27 层的视觉塔一起装起来。

你没法在命令行里加个参数说「我要走纯文本」——这个选择权在配置文件那边。想走另一条路，就得有一份 architectures 写着 Qwen3_5ForCausalLM 的权重。

那个 language_model_only 字段

config.json 顶层确实有这么一个字段：

"language_model_only": false

名字看起来正是我们要找的开关。但官方权重里它是 false，而且它是模型配置的一部分，不是运行时参数。

改这个字段值是否就能让框架跳过视觉塔，我们没有验证过，不做断言。可以确定的是：它的存在说明这个架构本身预留了纯文本形态——否则没必要有这个字段。

社区确实在做纯文本版本

有两处证据表明「把多模态版剥成纯文本版」是真实发生的实践。

证据一，vLLM 专门写了兼容代码。 权重映射里有这么一条，附带注释：

hf_to_vllm_mapper = WeightsMapper(
    orig_to_new_prefix={"model.language_model.": "model.", ...},
)

注释说明：某些社区的纯文本 checkpoint，保留了从多模态训练栈继承来的多余 model.language_model. 前缀，剥掉它可以让带前缀和不带前缀的 checkpoint 都正确加载（这套映射规则见权重名字怎么对上框架）。

框架不会为不存在的东西写兼容代码。 这条规则的存在本身就说明社区版本确实有，而且命名上确实会留下痕迹。

证据二，SGLang 有一条针对纯文本的注释：

Text-only checkpoints retain mrope_section, but identical position rows make its rotary embedding equivalent to 1-D RoPE.

纯文本的 checkpoint 仍然保留着 mrope_section 字段，但因为各位置行内容相同，多维旋转位置编码实际退化成一维。

这条注释很有信息量：它说明剥离过程不会把多模态相关的配置字段都清理干净，有些残留下来但不再起作用（mrope_section 这个字段本身的含义见 RoPE 维度 64 是怎么来的）。

剥掉视觉塔能省下什么

从 vision_config 能看出视觉塔的规模：27 层深度、内部隐藏维度 1152、中间层维度 4304、16 个注意力头，最后投影到 5120 维输出（结构细节见图像怎么变成 token）。

这部分参数在纯文本场景下完全用不到。 剥掉它能省下对应的权重体积和加载时间。

省多少？本文不给数字。 精确计算需要按视觉塔各层的实际形状逐个累加，而且实际节省还取决于量化方案。我们没有下载权重、没有做过参数量统计，给不出可靠的值。

能说的是量级判断：视觉塔的内部维度（1152）远小于语言模型（5120），层数（27）也不到语言模型（64）的一半。它在整个模型里占的比重不大——这是这类多模态模型的常见格局，视觉塔通常是个相对轻量的前端。

所以剥离带来的收益是实在的，但别指望它能改变你对硬件的基本需求。如果 27B 的语言主干本来就装不下，去掉视觉塔也救不回来。

想走这条路的实际建议

第一，先确认你真的需要。 视觉塔只在你传图像或视频时才会被调用。如果你的请求全是纯文本，它装在那儿主要是占一部分显存，不参与计算。收益是省显存，不是省算力。

第二，检查 architectures 字段。 拿到任何一份声称是纯文本版的权重，第一件事就是打开它的 config.json 看这个字段，确认写的是 Qwen3_5ForCausalLM。这是判断它走哪条路的唯一依据。

第三，对来源保持谨慎。 官方发布的是多模态版本，纯文本版本是第三方转换的产物。转换过程有没有出错、权重是否完整、有没有做过额外改动——这些需要你自己核实，别因为名字像就当成官方版本。核实思路可以参考 ModelScope 那份的核对方法。

第四，遇到加载警告先看是不是预期行为。 纯文本 checkpoint 里残留的多模态字段（比如 mrope_section）可能触发一些提示，按 SGLang 那条注释的说法，这类残留是已知情况。

还有一条路：不剥，只是不用

前面讨论的都是「换一份权重」。但对多数人来说，还有一个更省事的选择：什么都不改，就用官方的多模态权重跑纯文本请求。

视觉塔只在输入里真的含有图像或视频时才会被调用。你的请求全是文本，那 27 层视觉塔就静静待在显存里，不参与任何计算。代价是那部分显存，收益是省掉了所有折腾。

这个方案的优点很实际：用官方权重、来源可靠、不用担心第三方转换的完整性、框架支持也最完善。缺点就是那部分显存白占。

什么时候值得折腾去换纯文本权重？ 大致是显存卡得特别紧、恰好差那么一点的时候。如果你的硬件本来就宽裕，或者本来就差得远，剥离视觉塔都不会改变结论。

先按官方权重跑起来、用 ollama ps 或框架自己的日志看看实际占用，再决定要不要为这点空间去折腾——这个顺序比一上来就找纯文本版本要务实。

小结

vLLM、SGLang、llama.cpp 三家都注册了纯文本入口类 Qwen3_5ForCausalLM
但走哪个入口由 config.json 的 architectures 决定，不是启动参数
官方权重写的是 Qwen3_5ForConditionalGeneration，必然走多模态
顶层有 language_model_only 字段（官方值为 false），说明架构预留了纯文本形态
社区确实在做纯文本转换——vLLM 为此写了前缀剥离规则，SGLang 注明了 mrope_section 残留会退化为一维 RoPE
剥掉视觉塔省的是显存不是算力，具体省多少本文不给数字
用第三方纯文本权重前，务必自己核实来源与完整性

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