Repository navigation
fix: bound CUDA memory for fast image preprocessing - #36295
Merged
Merged
Conversation
mickqian
requested review from
HaiShaw,
JustinTong0323,
yctseng0211,
yhyang201 and
yuan-luo
as code owners
August 25, 2026 08:22
This was referenced Aug 26, 2026
5 tasks
This was referenced Sep 2, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
potential vram leak is observed with fast-image-processor, due to the memory pool allocated by global cuda allocator held by the tokenizer processor is not released after the image feature is moved to CPU.
Modifications
Use a dedicated MemPool for image processor, scope the processor call with this pool, thus the unused vram will be released and returned to cuda driver once the processor call finishes
Summary
This fixes apparent tokenizer-side VRAM growth during long-running VLM serving. The tensors were already freed, but the process-wide CUDA caching allocator retained the largest preprocessing scratch allocation.
Correctness
Tested with the real BF16
Qwen/Qwen3.8-27Bcheckpoint on one NVIDIA H200, BF16 KV cache, eager execution, and a seeded 100-item OCRBench sample. The test limit accepted the same 97 requests in every run.The fast-path answer digest is identical before and after the change:
42af989d32865a9aa3015315116e7670871b0de4788abc9145a3077d6666bb1c. Fast and PIL obtain the same score, so this experiment does not show a model-level accuracy loss from the torchvision processor.The second replay staying at 956 MiB verifies that processor HBM is bounded rather than growing with repeated requests.
Processor microbenchmark
Six seeded images from 512x512 through 4096x3072, real Qwen3.8 processor, three rounds on NVIDIA H200:
Tests
test/registered/unit/multimodal/test_processor_device_selection.py: 8 passedCI States
Latest PR Test (Base): ✅ Run #32827919455
Latest PR Test (Extra): ❌ Run #32827919312
Latest PR Test (AMD ROCm 7.2): ❌ Run #32827919291