pub fn pixel_bounds(
vcfg: &VisionConfig,
operator_max: Option<usize>,
) -> (u64, u64)Expand description
The area bounds this checkpoint permits, in pixels.
GLM states its budget in MERGED TOKENS (min_image_tokens = 16,
max_image_tokens = 8000) where the Qwen family states a pixel area, so the
conversion is tokens × factor² — one merged token covers exactly one
factor × factor pixel block. An operator --vision-max-pixels still wins
when it is the tighter of the two: the flag exists to bound memory, and a
checkpoint may not raise its way past it.
★ The ENCODER’S OWN CAPACITY is the third bound, and it is not optional.
GlmVit sizes every buffer from derive_max_patches(vcfg.max_pixels, patch_size), so a host-side budget derived only from the checkpoint’s token
count would hand it images it cannot hold: GLM declares 8000 merged tokens,
which is 32000 unmerged patches, against an encoder that allocates 6400 rows
when nothing else bounds it. That produces a refused request, not a wrong
answer — but it is the same class of defect the max_pixels field exists to
remove, two sides of the pipeline deriving a bound independently and
agreeing only by luck. Both now call the SAME function.