GitHub Repo
Transformers Community Reports Image Preprocessing Regression, Linux Multi-Image Requests See About 20% Higher Latency
A Transformers community report from October 28 says an in-place normalization optimization may change Linux memory allocation behavior and slow Qwen3-VL multi-image preprocessing. The report includes version bisection and a rollback comparison, but as of review, no maintainer had confirmed the issue or provided an official fix.
On October 28, the Transformers community reported a performance regression: processing multi-image Qwen3-VL inputs on Linux CPUs is slower in versions 5.18.0 and 5.19.0 than in 5.17.0. The reporter used version bisection to trace the slowdown to a normalization change intended to “avoid unnecessary image copies,” and said that reverting this change alone restored latency. Test outputs remained consistent, pointing to a performance issue. Original report
The tests used an Intel Xeon Platinum 8488C, eight PyTorch threads, and 30 images at 512×512 pixels per input. In vLLM’s multimodal processing path, the reporter measured preprocessing time increasing from 84.9 milliseconds to 104.4 milliseconds, then dropping to 86.1 milliseconds after the rollback. These measurements cover a specific processing stage for a particular input and environment; they cannot be directly translated into a 20% decrease in end-to-end model throughput. Test setup and results
One point to watch is that eliminating a copy does not necessarily make the entire pipeline faster. The reporter observed an increase in minor page faults and hypothesized that in-place normalization changed glibc allocation and deallocation order, causing subsequent floating-point image buffers to more often receive newly mapped memory and incur additional page handling on first access. Adjusting allocator thresholds brought the two versions’ speeds closer, supporting this hypothesis; however, the reporter also stated that the allocation order had not been fully traced. Memory behavior analysis
Hugging Face documentation explains that image processors handle resizing, normalization, and tensor conversion; when the torchvision backend receives non-tensor input, it runs on the CPU by default. Engineering teams investigating latency in multimodal services should therefore measure preprocessing and GPU inference separately, and record the backend, image count, and memory allocator environment. Image processor documentation
As of review, the issue remained open, with no maintainer confirmation or linked fix. Whether image and video processors that share the normalization path are also affected remains to be verified. Follow-up should track reproduction across allocators and any proposed fix; changing glibc parameters should not yet be treated as a general solution.