Buyer's Guide
One Image Can Become Hundreds of Model Input Positions
An image count does not fix a vision encoder's input length. In a simple patch pipeline, the image dimensions and patch size determine the spatial patch population; an extra class embedding adds another position. Compare the accepted preprocessing and exact model path before treating image-per-request offers as equivalent.
Follow pixels into a sequence
The historical Vision Transformer paper provides a simple way to see the conversion. This guide uses its June 3, 2021 revision, section 3.1 and equation 1, for the raw-image patch model used in classification.
For height H, width W, C channels and square patches of side P, the paper describes N = HW / P² flattened patches. Each patch contains P²C channel values. A learned linear projection maps that vector to embedding width D. One learnable class embedding is prepended, giving N + 1 encoder positions. Position embeddings are added to the vectors; they do not add another N positions.
This is a specified architecture, rather than a universal definition of an image token. The practical question is which representation reaches which part of the supplied system.
VP-250: one image, two patch populations
Original fictional example VP-250 stipulates an illustrative supported pipeline with nonoverlapping 16 × 16-pixel patches, three channels and exactly one extra class embedding. Both dimensions are divisible by 16. There is no resizing, cropping, padding, tiling or patch merging. These are invented pipeline assumptions, including support for both dimensions below; they establish no real model's accepted inputs.
Dimensions below are width × height. A 320 × 240-pixel input gives 320 / 16 = 20 patch columns and 240 / 16 = 15 patch rows. The grid contains 20 × 15 = 300 spatial patches. Adding the class embedding gives 301 encoder positions.
Doubling both dimensions to 640 × 480 pixels gives 40 patch columns and 30 patch rows. That grid contains 40 × 30 = 1,200 spatial patches and 1,201 positions including the class embedding.
Both inputs count as one image. Their spatial patch ratio is exactly 1,200 / 300 = 4. Their total-position ratio is 1,201 / 301, approximately 3.990, because each sequence has the same one-position addition. Neither ratio establishes a multiplier for GPU memory, compute cost, latency, energy or output quality. Those outcomes require evidence from the complete implementation.
Scroll the table horizontally on smaller screens.
| Input pixels (width × height) | Patch grid (columns × rows) | Spatial patches | Extra class positions | Total encoder positions | Source |
|---|---|---|---|---|---|
| 320 × 240 | 20 × 15 | 300 | 1 | 301 | Planning analysis |
| 640 × 480 | 40 × 30 | 1,200 | 1 | 1,201 | Planning analysis |
Original fictional arithmetic under VP-250's assumptions; no model execution or performance result is supplied.
768 channel values does not specify the embedding width
Each VP-250 patch contains 16 × 16 × 3 = 768 channel values before projection. The three channels contribute values within each patch; they do not turn the 300-patch image into 900 spatial patches.
The example leaves D unspecified. Its projected patch vector therefore has D components, even though its unprojected vector has 768 values. Counting components within a vector and counting vectors along a sequence answer different questions. For the smaller input, the encoder representation has 301 positions of width D; for the larger, it has 1,201 positions of width D.
Compressed file size describes another object: the encoded file. It does not state the dimensions presented after preprocessing, the patch size or the extra embeddings. VP-250 specifies no file format, compression setting or byte total, so no file-size ratio follows from its grids.
Compare the accepted preprocessing path
An actual system may resize or crop the decoded image, create multiple tiles or views, or combine patch representations later. The submitted dimensions alone then leave an intermediate step unresolved. Ask the software owner to connect the submitted image to the dimensions and representations at the boundary being counted.
Published architectures illustrate why that boundary matters. LLaVA's April 2024 LLaVA-NeXT video article explains AnyRes as dividing a high-resolution image into a grid of sub-images and concatenating their visual representations. A sub-image in that process is a larger processing unit, distinct from one small spatial patch inside its encoder.
The 2021 Swin Transformer paper, section 3.1, describes patch merging that reduces token counts between stages. A count before a merging stage consequently describes a different population from a count after it.
These examples identify possible transformations; they do not add features to VP-250. For an offer, establish the exact model and processor revisions, accepted image handling, resulting dimensions or views, and any extra positions or merging at the stated boundary. If two submitted resolutions are resized to the same encoder dimensions, VP-250's unchanged-dimensions comparison no longer applies.
Make an image-per-request offer comparable
Suppose two fictional offers each promise to handle one image per request. Offer A describes VP-250's 320 × 240 path; offer B describes its 640 × 480 path. The shared image count establishes neither equal encoder lengths nor equivalent task results. A buyer can now ask a concrete question: which accepted image handling and retained visual detail does the application require?
Have the appointed software provider explain the offered conversion using the intended input population. Images with different dimensions and aspect ratios can take different paths. Any comparison should keep the required task and acceptable outputs visible, so reducing or cropping the input cannot silently change the work being compared. VP-250 supplies no preferred resolution.
Identify what the offer calls an image token: a spatial patch, an encoder position, a later visual representation or a service accounting unit. No generated text-token count or billing-token count can be inferred from the ViT grid exercise. Obtain the selected service's own metering definition separately.
The related quota guide addresses admission reservations and usage accounting. The chat-template guide addresses text serialization. The padding guide starts with supplied sequence lengths and compares their batch representation. Here the distinct decision is earlier: how pixels become the vision sequence whose length the offer must explain.
Connect a separate equipment need to physical deployment
If the selected system also needs equipment receiving, rack integration, onsite installation or IT cabling, Leviathan's Complete Physical Infrastructure Deployment service is the relevant scoping route. Use the related service and project inquiry with a nonconfidential equipment list, site, required connections and physical handoff needs.
Vision preprocessing, model integration, serving and capacity tuning remain with the appointed software team. The physical service can discuss the installation stages required for the selected equipment and their availability.
References: [LS1]
Primary sources
- [V1] Dosovitskiy et al. — An Image is Worth 16x16 Words, revision 2Checked 2026-10-20. Section 3.1 and equation 1 describe the historical raw-patch classification architecture, including projection and the extra class embedding.
- [V2] arXiv — ViT revision historyChecked 2026-10-20. Identifies revision 2 as June 3, 2021 and the paper as the ICLR camera-ready version.
- [L2] LLaVA — LLaVA-NeXT: A Strong Zero-shot Video Understanding Model, April 2024Checked 2026-10-20. The AnyRes explanation illustrates sub-image grids and concatenated visual representations. No benchmark, video capacity or serving claim is adopted.
- [S1] Liu et al. — Swin Transformer, revision 1Checked 2026-10-20. Section 3.1 shows that patch merging changes token populations between network stages.
- [LS1] Leviathan Systems — Complete Physical Infrastructure DeploymentChecked 2026-10-20. Defines the physical receiving, integration, installation, cabling and handoff scope with separately assigned software responsibilities.