Fix/minicpmv46 missing version#44980
Conversation
MiniCPM-V 4.6 uses the transformers v5.7+ native MiniCPMV4_6ImageProcessor,
which no longer exposes the legacy `version` attribute. Since
MiniCPMV4_6ProcessingInfo inherited the base get_hf_processor() that wraps
the image processor in the vendored MiniCPMVProcessor, startup crashed with:
AttributeError: 'MiniCPMV4_6ImageProcessor' object has no attribute 'version'
(reported in OpenBMB/MiniCPM-V#1113).
Fix it in two layers:
1. MiniCPMV4_6ProcessingInfo now overrides get_hf_processor() to return the
native MiniCPMV4_6Processor directly. 4.6 already implements its own
image/video handling and prompt-update logic, so it neither needs nor is
compatible with the vendored processor designed for 2.x/4.0/4.5. The v5+
image_mean/image_std ndarray->list normalization is preserved.
2. As a defensive safety net for any future MiniCPM image processor that
drops `version`, MiniCPMVProcessor.__init__ now reads it via
getattr(image_processor, "version", None) instead of hard-crashing.
`version` is only used to special-case the 2.5 tokenization path; any
other value already takes the default branch.
Verified end-to-end with `vllm serve` on transformers 5.9.0: MiniCPM-V 2.5,
MiniCPM-o 4.5, and MiniCPM-V 4.6 all start and answer image+text requests
correctly.
Signed-off-by: wjinxu <1299461899@qq.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Apply the same defensive fallback to MiniCPMOProcessor.__init__ as was done for MiniCPMVProcessor: read `version` via getattr(..., None) instead of hard-crashing. MiniCPM-o shares the same vendored-processor pattern, so a future MiniCPM-o variant on a transformers v5.7+ native image processor (which no longer carries `version`) would otherwise hit the identical AttributeError. No behavior change for current 2.6/4.5 models, whose image processors still expose `version`. Signed-off-by: wjinxu <1299461899@qq.com> Co-authored-by: Cursor <cursoragent@cursor.com>
|
Yes, when merging #44282 before, it wasn't fully tested. |
|
@DarkLight1337 The That RTD build (#33053507) ran before the This PR only adds |
Empty commit to re-run buildkite + Read the Docs after the `ready` label was applied (previous run's docs build was skipped by pre_run_check.sh while the label/merge-count gate was still failing). No code changes. Signed-off-by: wjinxu <1299461899@qq.com> Co-authored-by: Cursor <cursoragent@cursor.com>
Signed-off-by: wjinxu <1299461899@qq.com> Co-authored-by: Cursor <cursoragent@cursor.com>
Signed-off-by: wjinxu <1299461899@qq.com> Co-authored-by: Cursor <cursoragent@cursor.com>
Signed-off-by: wjinxu <1299461899@qq.com> Co-authored-by: Cursor <cursoragent@cursor.com>
Signed-off-by: wjinxu <1299461899@qq.com> Co-authored-by: Cursor <cursoragent@cursor.com> Signed-off-by: divineearthly <divineearthly@gmail.com>
Signed-off-by: wjinxu <1299461899@qq.com> Co-authored-by: Cursor <cursoragent@cursor.com>
Signed-off-by: wjinxu <1299461899@qq.com> Co-authored-by: Cursor <cursoragent@cursor.com>
Reported in OpenBMB/MiniCPM-V#1113 (
vllm serve openbmb/MiniCPM-V-4_6).Fix
Two layers:
MiniCPMV4_6ProcessingInfo.get_hf_processor()now returns the nativeMiniCPMV4_6Processordirectly instead of the vendored wrapper. MiniCPM-V 4.6 already implements its own image/video handling and prompt-update logic, so it neither needs nor is compatible with the vendored processor designed for 2.x/4.0/4.5. The transformers v5+image_mean/image_stdndarray→list normalization is preserved.Defensive safety net:
MiniCPMVProcessor.__init__readsgetattr(image_processor, "version", None)instead of hard-crashing, so any future MiniCPM image processor that dropsversiondegrades gracefully.versionis only used to special-case the 2.5 tokenization path; any other value already takes the default branch.Test Plan
Verified end-to-end with
vllm serveon transformers 5.9.0 (a true v5 env), image+text request to each:The 4.6 run confirms the original
AttributeErroris gone; 2.5/4.5 confirm the vendored path is unaffected.Fixes OpenBMB/MiniCPM-V#1113
cc @DarkLight1337 @tc-mb