Qwen3.8-27B 的两份 preprocessor 配置：尺寸上限与归一化参数

2026-08-16

想知道一张图片进到 Qwen3.8-27B 之前会被怎么处理，很多人第一反应是去翻 model card 的 Quickstart。但 Quickstart 那几段示例代码里，图像和视频都只是一个 image_url / video_url 的 https 链接，请求里连一个预处理参数都没传。真正把预处理口径写下来的，是权重仓根目录下两个很容易被忽略的文件：preprocessor_config.json 和 video_preprocessor_config.json。

截至 2026-08-16 我们核对的快照（1d4bf0f）里，这两个文件分别是 390 字节和 385 字节，各 21 行。它们小到可以整个贴进一篇文章里，也正因为小，容易被当成「没什么信息」而跳过。实际上恰恰相反——它们能告诉你的东西是有限的，而知道「哪些东西它们没说」，比记住那几个数字更要紧。

逐字段列全：两份文件一共只有这些键

先把两份配置的全部内容摊开。下表把 size 展开成两项，一共 9 个条目，两个文件都没有第十项。

字段	`preprocessor_config.json`	`video_preprocessor_config.json`
`size.longest_edge`	`16777216`（第 3 行）	`25165824`（第 3 行）
`size.shortest_edge`	`65536`（第 4 行）	`4096`（第 4 行）
`patch_size`	`16`（第 6 行）	`16`（第 6 行）
`temporal_patch_size`	`2`（第 7 行）	`2`（第 7 行）
`merge_size`	`2`（第 8 行）	`2`（第 8 行）
`image_mean`	`[0.5, 0.5, 0.5]`（第 9-13 行）	`[0.5, 0.5, 0.5]`（第 9-13 行）
`image_std`	`[0.5, 0.5, 0.5]`（第 14-18 行）	`[0.5, 0.5, 0.5]`（第 14-18 行）
`processor_class`	`"Qwen3VLProcessor"`（第 19 行）	`"Qwen3VLProcessor"`（第 19 行）
末尾类型键	`image_processor_type`: `"Qwen2VLImageProcessorFast"`（第 20 行）	`video_processor_type`: `"Qwen3VLVideoProcessor"`（第 20 行）

把两列对着看一眼就有结论：两个文件的差异只有三处——size.longest_edge、size.shortest_edge，以及末尾那个类型键的键名与取值。剩下的 patch_size、temporal_patch_size、merge_size、归一化的 image_mean / image_std、以及 processor_class，图像侧和视频侧逐字相同。

这一点值得单独说一句：视频那份文件里，归一化参数的字段名依然叫 image_mean / image_std，不是 video_mean 之类。翻配置时按 video_ 前缀去搜是搜不到的。

`size` 里那两个数字，仓库没有给出换算口径

longest_edge 是 16777216、shortest_edge 是 65536，视频侧是 25165824 与 4096。这四个数字的量级明显不是「像素边长」的常见写法，所以最自然的疑问是：它到底按什么单位算，一张多大的图会被缩到什么程度。

这个问题在本仓库里核不出来。model card 全文只在讲长视频那一节括注了一次换算参照：README.md:561 建议把视频侧的 longest_edge 设为 469762048，括号里注明「corresponding to 224k video tokens」。除此之外没有通用公式，图像侧那两个数（16777216 / 65536）对应多少 token，README 没有写，两个配置文件本身也没有写。我们不做任何推算——把一个未标注单位的整数除来除去得出「所以能传 XX 分辨率的图」，那是猜，不是核实。

同样地，这两个上下限意味着传大图会不会更慢、会占多少显存，本文一个字都不谈：我们没有下载权重、没有部署、没有推理过一个 token，没有任何依据。

patch 相关的三个字段，和 `config.json` 对得上

patch_size / temporal_patch_size / merge_size 这三个字段在两份预处理配置里都是 16 / 2 / 2。它们在 config.json 的 vision_config 里也有同语义的落点，我们把它们并排放一下（行号为 config.json 内的行）：

`config.json` 里的字段	值	行号
`vision_config.patch_size`	`16`	134
`vision_config.spatial_merge_size`	`2`	135
`vision_config.temporal_patch_size`	`2`	136
`vision_config.depth`	`27`	124
`vision_config.hidden_size`	`1152`	126
`vision_config.out_hidden_size`	`5120`	133
`vision_config.deepstack_visual_indexes`	`[]`（空数组）	123

需要留意的是名字并不完全一致：预处理配置这边叫 merge_size，config.json 那边叫 spatial_merge_size，两处的值都是 2；patch_size 与 temporal_patch_size 则是两边同名同值。改配置时按哪个名字去搜，取决于你改的是哪个文件，这一点很容易搞混。

顺带记一笔：config.json:123 的 deepstack_visual_indexes 在我们采集时是一个空数组。这只是文本状态的照实记录，它意味着什么、会不会影响什么，我们不做推断。

更值得注意的，是这两个文件里「没有的字段」

model card 的 Video Input 示例里，有一段被整体注释掉的代码（README.md:405-417，每一行都以 # 开头，不是可执行代码）。那段注释写着：当 vLLM 以 --media-io-kwargs '{"video": {"num_frames": -1}}' 启动时，可以通过 extra_body 配置视频抽帧；并写明 By default, fps=2 and do_sample_frames=True（README.md:409），以及 This feature is currently supported only in vLLM.（README.md:407）。

于是很自然会想：fps=2 这个默认值是不是就写在 video_preprocessor_config.json 里？

不在。我们对两个预处理配置逐词做了存在性检查，fps、num_frames、do_sample_frames、max_pixels、min_pixels 五个关键词在两个文件里全部为 False，config.json 里 fps 同样为 False。也就是说，README 注释里给出的那两个默认值，在这个权重仓的配置文件中找不到对应字段；它由哪一层提供，README 没有说明，我们也没能在仓库里核到。

除此之外，这两个文件里还没有 do_resize、do_rescale、do_normalize、rescale_factor、do_convert_rgb 这些在图像预处理配置里常见的键——全文就是上表那 9 个条目，没有更多。这些缺省项在实际加载时会取什么行为，属于框架侧的事，本仓库没写，我们不替它推断。

三处对不上的地方（只陈述差异，不推断原因）

其一，README 建议的视频 longest_edge 与仓库发布值不同。 README.md:561 原文说发布出来的 video_preprocessor_config.json 里 size 参数配置得比较保守，建议改为 469762048，示例 JSON 在 README.md:563，写作 {"longest_edge": 469762048, "shortest_edge": 4096}。而仓库里 video_preprocessor_config.json:3 的实际值是 25165824。shortest_edge 两处一致，都是 4096（README.md:563 与 video_preprocessor_config.json:4）。同一段还提到可以通过引擎启动参数覆盖默认值，实现细节指向两个外部 PR 链接（README.md:566，vLLM PR 34330 与 SGLang PR 18467），我们没有访问这两个链接。

其二，抽帧默认值写在 README 注释里，配置文件里没有对应字段。 位置分别是 README.md:409（注释行）和 video_preprocessor_config.json 全文（21 行，见上表）。

其三，预处理器类名的代际标记在四处不统一。 preprocessor_config.json:20 的 image_processor_type 是 "Qwen2VLImageProcessorFast"，而同一文件 :19 的 processor_class 是 "Qwen3VLProcessor"；video_preprocessor_config.json:20 是 "Qwen3VLVideoProcessor"；config.json:3 的 architectures 是 "Qwen3_5ForConditionalGeneration"、config.json:7 的 model_type 是 "qwen3_5"。四处出现了 Qwen2VL、Qwen3VL、Qwen3_5 三种写法。

以上三处我们只标明差异和各自的具体位置。哪个「是对的」、为什么会这样，本文不推断，也不据此对项目作任何评价。

自己核一遍：两条可执行的判定动作

如果你要在自己的环境里确认上面这些，不需要下载权重，把这两个 JSON 和 config.json 拿到手就够了。在存放这几个文件的目录下执行：

python -c "
import io
for name in ['preprocessor_config.json','video_preprocessor_config.json']:
    d=io.open(name,encoding='utf-8').read()
    for kw in ['fps','num_frames','do_sample_frames','max_pixels','min_pixels','longest_edge','shortest_edge']:
        print(name,kw,kw in d)
print('fps in config.json:', 'fps' in io.open('config.json',encoding='utf-8').read())
"

我们跑这条命令得到的结果是：两个文件里 fps / num_frames / do_sample_frames / max_pixels / min_pixels 全为 False，longest_edge / shortest_edge 为 True，config.json 中 fps 为 False。

要比对图像侧与视频侧的差异，直接把两个文件读成 dict 逐键对照即可——它们各自就是上表那 9 个条目，肉眼看完也就是一分钟的事。Windows 下用 PowerShell 或 CMD 执行上面这段时，注意把外层的双引号与内层的单引号对应关系保留原样（Python 的 -c 参数在 Windows 命令行里对引号更敏感），或者干脆把它存成一个 .py 文件再跑。

验证完之后怎么判断结论是否成立：如果你的检查结果与上面不一致，最可能的原因是上游已经更新了这两个文件——这个模型仓在我们采集时（2026-08-16）的快照是 1d4bf0f，最后更新时间是 2026-08-14。这类随仓配置随时可能变，以你手上那份仓库的实际内容为准。

用这两个文件之前，得知道的几条限定

README 里那段讲视频抽帧的代码在原文中是注释状态，并写明该能力「目前只在 vLLM 支持」（README.md:407）。不要把它当成一个已经跨框架可用的开关。
model card 提到 Qwen3.8-27B 会有一个托管版本（带默认 1M 上下文长度、官方内置工具等），原文最后一句写的是该服务 coming soon、Stay tuned for updates.（README.md:16）。按 README 自述，那些特性在我们采集时尚未上线。
这是一个权重仓，不是代码工程：仓库里没有实现代码可查。凡是 README 没写、配置文件里也没有的语义（比如 size 的单位换算、num_frames 的取值含义），在这个仓库范围内就是核不出来的，写文章时该说「未能核实」就说未能核实。

真正能从这两个文件里带走的，其实就三条：图像与视频的预处理口径高度一致，只差 size 的两个上下限和末尾那个类型键；归一化参数简单到全是 0.5；以及抽帧相关的参数根本不住在这里。剩下的，去框架文档里找。

延伸阅读

本文依据 Hugging Face 仓库 Qwen/Qwen3.8-27B 的 model card 与随仓配置文件（config.json、generation_config.json、preprocessor_config.json、chat_template.jinja 等）整理，核对日 2026-08-16，对应仓库快照 1d4bf0f。本文内容为 model card 与配置文件口径，我们没有下载权重、没有部署、也没有推理过这个模型，因此不涉及生成质量、推理速度与显存占用的任何描述；文中所有评测数字均为 model card 自述，我们没有复现。模型仓库内容随上游更新而变动，请以官方最新说明为准。