ModelScope 上的千问3.8-27B：和 Hugging Face 那份是不是同一个
在国内拉 Hugging Face 的权重经常不顺，所以多数人会转去 ModelScope（魔搭）。但转之前总会有个疑虑：魔搭上这个「千问3.8-27B」，和 HF 上那个 Qwen/Qwen3.8-27B，是不是同一份东西？
这个疑虑是合理的。社区上传的转换版、量化版、微调版满天飞，名字看起来都差不多。
好在两边都有公开的元数据 API，可以逐字段对一遍。这篇就干这件事。
这篇的依据
两个不需要鉴权的接口：
https://huggingface.co/api/models/Qwen/Qwen3.8-27B
https://modelscope.cn/api/v1/models/Qwen/Qwen3.8-27B
采集时间 2026-08-24。你可以自己 curl 一遍复核。
我们没有下载权重、没有做过文件级校验、没有跑过模型。 下面比对的是两个平台返回的元数据，不是权重文件本身的哈希。这个区别很重要，最后一节会说清楚它的边界在哪。
逐字段核对
把两边返回里的关键字段并排放：
| 字段 | Hugging Face | ModelScope |
|---|---|---|
| 仓库路径 | Qwen/Qwen3.8-27B | Qwen / Qwen3.8-27B |
| 中文名 | 无此字段 | 千问3.8-27B |
| architectures | ["Qwen3_5ForConditionalGeneration"] | ["Qwen3_5ForConditionalGeneration"] |
| model_type | qwen3_5 | ["qwen3_5"] |
| license | apache-2.0 | apache-2.0 |
| 权重格式 | safetensors | ["safetensors"] |
| 任务类型 | image-text-to-text | 视觉多模态对话 / image-text-to-text |
四个关键字段完全一致：架构类名、模型类型、许可、权重格式。
其中 architectures 这一项最有说服力。Qwen3_5ForConditionalGeneration 是个相当具体的字符串，它决定了推理框架加载时走哪份实现代码（这条链路见 64 层在 vLLM 里怎么分流）。两边一致，说明至少 config.json 的核心部分是同一份。
组织路径也对得上：都在 Qwen 这个官方组织名下，不是第三方镜像账号。
时间线：魔搭上得更早
两边的时间戳换算出来是这样的：
| 事件 | 时间（UTC） |
|---|---|
| ModelScope 创建 | 2026-08-12 09:25 |
| HF 最后修改 | 2026-08-14 15:00 |
| ModelScope 最后更新 | 2026-08-14 18:24 |
ModelScope 上的仓库比 HF 的最后一次修改还早两天创建，然后在 HF 更新当天的三小时后也跟着更新了。
这个节奏说明两边是同步维护的，不是「HF 发布后有人搬运到魔搭」。对国内用户是个好消息：不用担心魔搭上的是滞后版本。
那个「后端支持」字段全是 null
ModelScope 的返回里有一个 BackendSupport 结构，长这样：
"BackendSupport": {
"architectures": null,
"backend_info": {
"deploy_task": null,
"lmdeploy": null,
"lmdeploy_turbomind": null,
"ollama": null,
"sglang": null,
"vllm": null
},
"model_id": "Qwen/Qwen3.8-27B"
}
vllm、sglang、ollama、lmdeploy——全是 null。
看到这个很容易得出一个结论：这些框架都不支持这个模型。
这个结论是错的。 实际情况是：
| 框架 | 实际支持状况（2026-08-24 核实） |
|---|---|
| vLLM | 已合入，models/qwen3_5.py + qwen3_5_mtp.py，registry 有注册项 |
| SGLang | 已合入，qwen3_5.py / qwen3_5_text.py / qwen3_5_mtp.py 三个文件 |
| Ollama | 官方库有 qwen3.8 条目，多个量化 tag |
| llama.cpp | 已合入，转换类 Qwen3_5TextModel，架构枚举 QWEN35 |
四个全都支持。null 的含义是这个平台的元数据字段没填，不是「不支持」。
这是个很值得记住的判断陷阱：平台元数据字段为空，只能说明平台没填，不能反推事实。 想知道某个框架支不支持某个架构，可靠办法是去框架仓库里搜 architectures 里那个类名，而不是看分发平台的标签。
顺带一个相关的坑：搜 llama.cpp 时如果按 qwen3_5 去 grep 会一无所获，因为它用的命名是 Qwen35（没有下划线），而且转换逻辑已经从 convert_hf_to_gguf.py 重构进了 conversion/ 包。命名风格和目录结构都可能让你误判成「不支持」。
热度数据：差着一个量级
两边都公开了下载量，截至 2026-08-24 采集：
| 平台 | 下载量 | 收藏 |
|---|---|---|
| Hugging Face | 2,645,226 | 12,435 likes |
| ModelScope | 76,614 | 1,163 stars |
差着大约 35 倍。这个差距本身不说明模型质量的任何问题——两个平台的用户基数、统计口径、计数规则都不一样，跨平台比绝对值意义有限。
放在这里只有一个用途：如果你在魔搭上看到某个模型下载量只有几万，别急着觉得冷门，先想想它在 HF 上是什么量级。
这类数字每天都在变，本文标注采集时点，你读到时一定已经不是这个值了。
这次核对的边界在哪
必须说清楚：以上比对的是元数据，不是权重文件本身。
我们核对了架构类名、模型类型、许可、权重格式、组织路径、更新时间线——这些一致，可以相当有把握地说两边是同一份模型的两个分发点。
但我们没有下载任何权重文件、没有比对文件哈希、没有核对分片数量与大小。要做到文件级的确认，得把两边的 18 个分片 都拉下来算校验值，我们没做。
对绝大多数使用场景，元数据一致加上官方组织路径，已经足够了。如果你的场景对权重完整性有强要求（比如合规审计），那就得自己做文件级校验，别停在这一步。
真要做文件级校验，思路是这样的
先说清楚：下面是方法描述，我们没有实际执行过。 提供它是因为「元数据一致」和「字节一致」之间确实隔着一段距离，有人需要跨过去。
思路分三层，从便宜到贵：
第一层，比对文件清单。 两边的模型文件页都能列出仓库里有哪些文件。Qwen3.8-27B 的权重是 18 个 safetensors 分片加一组配置文件，如果两边的文件名集合和字节大小完全对上，一致性的把握就已经很高了。这一层不用下载任何权重，只读文件列表。
第二层，比对哈希。 Hugging Face 的模型 API 支持返回每个文件的 LFS 记录，里面带着内容哈希。如果 ModelScope 侧也能拿到同口径的哈希值，就可以逐文件对。难点在于两个平台用的哈希算法和记录方式未必相同——对不上的时候，先确认是不是口径差异，别急着下结论说文件不一样。
第三层，下载后本地算。 最笨也最可靠：两边都拉一份，本地跑同一个哈希算法逐文件比。代价是几十 GB 的流量和存储，只有合规审计这类场景值得。
多数人停在第一层就够了。从「同一个官方组织 + 元数据一致 + 文件清单一致」到「字节完全一致」，这最后一步的边际收益，通常撑不起它的成本。
顺带看懂返回里的另外几个字段
ModelScope 那份返回里还有几个字段值得认一下：
Libraries 是 ["safetensors"]，表明权重用的是 safetensors 格式，不是老式的 pickle 序列化。这一项对安全性有实际意义——safetensors 的设计目标之一就是加载时不执行任意代码。
Frameworks 是空数组。和前面那串 null 一个道理：字段没填，不代表没有框架支持。
Tasks 里标的是视觉多模态对话（image-text-to-text），与 HF 的 pipeline_tag 一致。这个标签决定了你在平台上按任务类型筛选时它出不出现，也提示了它是个能吃图的模型，而不是纯文本模型。
License 是 apache-2.0，与 HF 一致。许可这一项跨平台必须一致——如果哪天你发现两边不一样，那基本可以确定其中一边有问题，这时候该以模型仓库里那份 LICENSE 文件的实际内容为准，而不是平台标签。
小结
- 魔搭上的「千问3.8-27B」与 HF 上的
Qwen/Qwen3.8-27B，元数据核心字段完全一致，都在官方Qwen组织下 - 两边同步维护，魔搭甚至建得更早，不存在滞后问题
BackendSupport里那一串null是字段没填，不是框架不支持——vLLM、SGLang、Ollama、llama.cpp 四家实际都已支持- 判断框架支持与否，去框架仓库搜架构类名，别信分发平台的标签
- 本文只核对了元数据，文件级校验需要自己做
想看这个模型在其他渠道的分发情况，可以读 Qwen3.8 系列全家谱，或回到 Qwen3.8-27B 专题。