Qwen3.8-27B 支持哪些推理框架：四家的核实结果与核实方法
「Qwen3.8-27B 能用 vLLM 跑吗」这类问题，网上的答案往往是某个论坛帖子里的一句话，还不带日期。模型迭代这么快，去年的答案今年可能就反了。
比起记住结论，更值得掌握的是怎么自己核实。这篇给出截至 2026-08-24 的核实结果，以及做这次核实用的方法——方法比结果保质期长得多。
核实结果一览
| 框架 | 支持 | 证据位置 |
|---|---|---|
| vLLM | 是 | vllm/model_executor/models/qwen3_5.py，registry 六条注册项 |
| SGLang | 是 | python/sglang/srt/models/ 下三个 qwen3_5* 文件 |
| transformers | 是 | src/transformers/models/qwen3_5/（另有 qwen3_5_moe） |
| llama.cpp | 是 | conversion/qwen.py 中 Qwen3_5TextModel，架构枚举 QWEN35 |
| Ollama | 是 | 官方库 qwen3.8，十二个标签 |
四个主流推理框架加 Ollama，全部已经支持。 下面说每一处的具体情况，以及是怎么查出来的。
核实方法：认准 architectures 字段
所有核实都从同一个地方出发——模型的 config.json 顶层：
"architectures": ["Qwen3_5ForConditionalGeneration"]
这个字符串是模型和框架之间的唯一约定。 框架加载模型时就是读这个字段去查自己的注册表，查到了就用对应实现，查不到就报「不支持这个架构」。
所以核实方法就是：拿这个字符串去框架仓库里搜。 搜得到就是支持，搜不到再考虑是不是命名风格不同（见最后一节的陷阱）。
注意这里的关键：要搜的是架构类名，不是模型名。 搜「Qwen3.8」很可能一无所获，因为框架代码里根本不出现营销名称，它只认 Qwen3_5ForConditionalGeneration 这种类名。
vLLM
在 registry.py 里搜 Qwen3_5，能查到六条注册项，分三组：
| 组 | 类名 |
|---|---|
| 纯文本 | Qwen3_5ForCausalLM / Qwen3_5MoeForCausalLM |
| 多模态 | Qwen3_5ForConditionalGeneration / Qwen3_5MoeForConditionalGeneration |
| 多步预测 | Qwen3_5MTP / Qwen3_5MoeMTP |
27B 的 config.json 里写的是 Qwen3_5ForConditionalGeneration，对应第二组。
实现文件是 vllm/model_executor/models/qwen3_5.py（741 行）和 qwen3_5_mtp.py（323 行）。这份实现怎么按层分流的，拆解见 64 层在 vLLM 里怎么分流。
有一条限制要提前知道：源码里有个硬性拦截，mamba_cache_mode 设为 all 时会直接抛 NotImplementedError，提示改用 align。这不是警告，是模型根本构造不起来。
SGLang
python/sglang/srt/models/ 目录下有三个相关文件：
| 文件 | 行数 |
|---|---|
qwen3_5.py | 2457 |
qwen3_5_mtp.py | 436 |
qwen3_5_text.py | 225 |
拆成三个文件本身就说明支持是完整的——纯文本、多模态、MTP 分别有实现，不是塞在一个文件里凑合。
transformers
src/transformers/models/qwen3_5/ 下有五个文件：
| 文件 | 字节 |
|---|---|
modeling_qwen3_5.py | 88,546 |
modular_qwen3_5.py | 28,781 |
configuration_qwen3_5.py | 8,266 |
tokenization_qwen3_5.py | 3,127 |
__init__.py | 1,035 |
另有一个独立的 qwen3_5_moe 模块。
有个细节值得留意：这个模型有自己的 tokenization_qwen3_5.py，而不是复用前代的分词器实现。结合它 248,320 的词表，说明分词这一层是有专门处理的。
vLLM 的源码里还留了一条兼容性注释，说 transformers 5.x 把 MoE 的顶层配置类改名为 Qwen3_5MoeTextConfig，而 4.x 及以下返回 Qwen3_5MoeConfig，所以它两个都接受。这条注释顺带告诉你：transformers 的支持跨了大版本，两个版本的类名不一样。
llama.cpp
注册在 conversion/qwen.py：
@ModelBase.register("Qwen3_5ForConditionalGeneration", "Qwen3_5ForCausalLM")
class Qwen3_5TextModel(_Qwen35MRopeMixin, _LinearAttentionVReorderBase):
model_arch = gguf.MODEL_ARCH.QWEN35
一个装饰器同时注册了多模态和纯文本两个类名，都映射到架构枚举 QWEN35。gguf-py/gguf/constants.py 里 QWEN35 和 QWEN35MOE 两个枚举都在。
两个基类的名字透露了转换时要做的额外工作：_LinearAttentionVReorderBase 说明线性注意力的权重需要重排，_Qwen35MRopeMixin 涉及 mrope 参数的处理。这些细节值得单独说，见 llama.cpp 转 GGUF 时对权重做了什么。
Ollama
官方库有 qwen3.8 条目，十二个标签覆盖 4 位量化到 bf16 多档，对照表见 十二个标签。
「支持」不是一个开关，它有三个层次
上面那张表用了「是」这个字，但实际情况比一个字要复杂。同一个框架对同一个模型的支持，可以分成三层，逐层递减。
第一层：能不能加载。 框架认得 architectures 里的类名，能把权重装进去跑出结果。这是最基本的一层，也是多数人说「支持」时的意思。
第二层：模型的特性支不支持。 Qwen3.8-27B 有几个不是所有模型都有的东西——多模态输入、MTP、混合注意力、256K 长上下文。这些是不是每一个都覆盖到了，是另一个问题。
从注册表能看出一部分答案：vLLM 把 MTP 注册成了独立模型（Qwen3_5MTP），SGLang 也有单独的 qwen3_5_mtp.py。这说明两家都做了 MTP，但也说明用主模型的方式加载是拿不到 MTP 的——它得单独走。
多模态同理。ForCausalLM 和 ForConditionalGeneration 是两个注册项，前者纯文本、后者带视觉塔。你用哪个类加载，决定了能不能喂图片。
第三层：周边功能支不支持。 前缀缓存、LoRA、张量并行、量化格式、投机解码——这些是框架级功能，对不同模型的覆盖度可能不一样。
vLLM 那条 mamba_cache_mode 的限制就是典型例子：模型能加载、能推理，但某种前缀缓存模式用不了，会直接抛异常。这在第一层看是「支持」，在第三层看是「有条件支持」。
实际建议：如果你的方案依赖某个具体特性，别停在「这个框架支持这个模型」这句话上。去搜那个特性相关的代码或文档，确认它在这个模型上有没有例外。例外通常写在源码注释和异常提示里，不写在支持列表上。
两个会让你误判的陷阱
这次核实过程中真实踩到了两个，都值得记下来。
陷阱一：分发平台的支持标签会骗人
ModelScope 的模型 API 返回里有个 BackendSupport 结构，vllm、sglang、ollama、lmdeploy 字段全是 null。
按字面读，会得出「这些框架都不支持」的结论。但对照上面的核实结果，四家其实全都支持。
null 的含义是平台元数据没填，不是不支持。 分发平台的标签依赖人工或自动化流程去维护，滞后和遗漏都很常见。要判断支持与否，永远回到框架仓库本身。
陷阱二：命名风格差异会让你搜空
在 llama.cpp 里搜 qwen3_5 会一无所获——它用的命名是 Qwen35，没有下划线。
更麻烦的是，这个仓库还把转换逻辑从 convert_hf_to_gguf.py 重构进了 conversion/ 包，所以照着旧教程去那个老文件里搜，也是空的。
两个因素叠加，很容易得出「llama.cpp 不支持」的错误结论。
规避办法：搜不到时别急着下结论，换几种写法试试——去掉下划线、改变大小写、只搜数字部分（比如 35）。再不行就搜架构枚举名或者去仓库的模型支持列表文档里找。
「没搜到」和「不支持」是两件事，这个区别在快速迭代的项目上尤其要紧。
小结
- 截至 2026-08-24，vLLM、SGLang、transformers、llama.cpp、Ollama 全部支持 Qwen3.8-27B
- 核实方法：拿
config.json里architectures的类名去框架仓库搜，别搜营销名 - 分发平台的「后端支持」标签不可信，字段为空只说明没填
- 命名风格和目录重构都可能让你搜空，搜不到时多换几种写法
- 这类结论保质期很短，用之前请按上面的方法自己复核一遍
再强调一遍那条方法：打开模型的 config.json，抄下 architectures 里的字符串，拿它去框架仓库搜。 这一步花不了两分钟，却能替掉一整轮在论坛帖子和过期教程里翻找的功夫，而且得到的是当下的事实而不是别人几个月前的印象。搜到了看实现文件有多完整，搜不到就换几种命名写法再试一次。
想深入某个框架的实现，可以看 vLLM 的分层调度。更多拆解在 Qwen3.8-27B 专题。