An LLM counts text tokens: pieces of words, about four characters or three-quarters of an English word each. A VLM also counts image tokens, and those are determined by the image’s pixel dimensions, not its content: the vision encoder cuts the image into fixed-size patches or tiles, and each one becomes a token or a block of tokens. A 1-megapixel image costs more than a thousand tokens on current models, while a 20-word instruction costs about 27. For manufacturers, that ratio decides whether a VLM is practical on a production line.
This article is part of our guide to industrial AI. For how VLMs and LLMs differ in architecture, start with VLM vs LLM. Here we work through the token arithmetic and what it means at line rate.
How LLMs count text tokens
A tokenizer splits text into sub-word pieces from a fixed vocabulary. Common words are one token; long or unusual words, part numbers and code split into several. Useful rules of thumb for English:
- 1 token ≈ 4 characters ≈ 0.75 words
- 100 tokens ≈ 75 words
- A 20-word instruction ≈ 20 ÷ 0.75 ≈ 27 tokens
- Serial numbers, hex strings and code tokenize less efficiently than prose
Both the prompt (input tokens) and the answer (output tokens) count toward cost and the model’s context window. Output tokens are also the slow part, because the model generates them one at a time.
How VLMs count image tokens
A vision encoder cannot read a whole image at once. It divides it into a grid and turns each cell into a vector. The token count is therefore set by geometry:
A classic open-model example: a vision transformer with 14-pixel patches reading a 336 × 336 image produces 24 × 24 = 576 image tokens. Commercial APIs publish their own rules. Two examples, from the providers’ documentation at the time of writing:
Claude (Anthropic): 28 × 28-pixel patches
Each 28 × 28-pixel block is one visual token, so an image costs ⌈width ÷ 28⌉ × ⌈height ÷ 28⌉ tokens. Larger images are scaled down, keeping the aspect ratio, to a cap: a 1,568-pixel long edge and 1,568 tokens on the standard tier, and a 2,576-pixel long edge and 4,784 tokens on the high-resolution tier of newer models.
Gemini (Google): 768 × 768-pixel tiles
An image up to 384 pixels on both sides counts as 258 tokens. Larger images are split into 768 × 768-pixel tiles of 258 tokens each, so a 1,536 × 1,536 image is 4 tiles, or 1,032 tokens.
The rules differ, but the lesson is the same: tokens scale with pixel area until a resize cap kicks in. Color depth and file format do not change the count; a grayscale JPEG and a color PNG of the same size cost the same.
Worked examples
| Input | Calculation (28-px patches) | Tokens |
|---|---|---|
| 20-word instruction | 20 ÷ 0.75 | ≈ 27 |
| 200 × 200 crop | ⌈7.1⌉ × ⌈7.1⌉ = 8 × 8 | 64 |
| 336 × 336 region of interest | 12 × 12 | 144 |
| 1,000 × 1,000 image (1 MP) | ⌈35.7⌉ × ⌈35.7⌉ = 36 × 36 | 1,296 |
| 1,920 × 1,080 frame, high-resolution tier | ⌈68.6⌉ × ⌈38.6⌉ = 69 × 39 | 2,691 |
| 1,920 × 1,080 frame, standard tier | Resized to 1,456 × 819 | about 1,560 |
| 5 MP inspection camera (2,448 × 2,048) | Resized to the tier cap | about 1,560 (standard) to 4,784 (high-res) |
Notice the last row. A 5-megapixel inspection camera has about five times the pixels of the 1-megapixel image, but the API shrinks it to its cap before the model sees it. The token bill stops growing, and so does the detail: fine defects that were several pixels wide in the original may shrink to a pixel or less.
What this means at line rate
Take a line running 300 parts per minute, with one 1-megapixel image per part sent to a VLM:
- Image tokens per minute: 300 × 1,296 = 388,800
- Per 8-hour shift: 388,800 × 480 minutes = about 187 million input tokens
- Add the answer: a 50-word explanation is about 67 output tokens, or 20,100 per minute, generated one token at a time
- Time budget: 60 ÷ 300 = 200 ms per part, for capture, transfer, encoding, generation and the reject signal
Multiply by your provider’s price per million input and output tokens to get the running cost; unlike a purpose-trained model on an edge GPU, it never stops. Latency is the harder limit: a network round trip plus encoding over a thousand image tokens and generating a sentence rarely fits a 200 ms window reliably. This is the main reason VLMs work on exceptions rather than on every part.
Five ways to cut image tokens without losing the defect
- Crop to the region of interest. A 336 × 336 crop around the feature is 144 tokens instead of 1,296: nine times fewer. Use classical vision to locate the part first, then send only the crop.
- Size the image to the defect, not the camera. Work out the smallest defect in pixels. With a 100 mm field of view on 1,000 pixels, each pixel is 0.1 mm, so a 0.2 mm scratch is 2 pixels wide. Downscale that image by half and the scratch is 1 pixel, and may disappear. Keep enough resolution for the defect and crop the rest.
- Send only flagged or uncertain parts. If the inline model flags 2% of parts, the VLM sees 6 parts a minute instead of 300, cutting tokens 50-fold.
- Keep prompts and answers short. Ask for a defect class and a one-line reason, not an essay; output tokens cost more time than input tokens.
- Batch offline work. Reports, labeling help and trend reviews do not need real-time answers and can run in batches at lower priority.
Video and multi-camera stations
Video is a sequence of images, so tokens multiply by the frames sampled. One frame per second from a 1-megapixel stream is 1,296 tokens per second, or about 4.7 million per hour. Multi-camera stations multiply again by the number of views. Most VLMs sample video sparsely for that reason, which also means they can miss short events a dedicated vision system would catch.
How this compares with a purpose-trained vision model
| VLM via API | Purpose-trained model at the edge | |
|---|---|---|
| What drives cost | Tokens per image, every image | Fixed hardware cost; no per-image fee |
| Typical role | Explanation, triage, search | Pass/fail, classification, counting on every part |
| Resolution | Capped by the provider’s resize rules | Set by the system design, up to the full camera resolution |
| Latency | Network plus encoding plus generation | Milliseconds, on the line |
| Data location | Leaves the plant unless self-hosted | Stays on the line |
When a VLM is the right tool, self-hosting a smaller open model on a local GPU removes the per-token fee and keeps images on site, at the cost of lower capability. For the edge hardware side of that decision, see our comparison of GPU, CPU and FPGA for image processing.
Planning a VLM or AI vision pilot?
Sciotex designs and builds industrial AI systems and sizes them to the defect, the line rate and the budget: purpose-trained models where speed matters, VLMs where explanation does. Designed, programmed, built and supported in the US since 1997.
Frequently asked questions
The vision encoder divides the image into fixed-size patches or tiles after any resizing, and each becomes one or more tokens. For example, with 28 × 28-pixel patches a 1,000 × 1,000 image is 36 × 36 = 1,296 tokens.
It depends on the image size and the model. A small thumbnail can be under 100 tokens, a 1-megapixel image is roughly 1,000–1,300 tokens, and large images are resized to a cap, typically around 1,500 to 5,000 tokens depending on the model and resolution tier.
Image tokens are usually billed at the input-token rate, but one image is worth hundreds or thousands of text tokens, so images dominate the cost of most multimodal requests.
No. Token count depends on pixel dimensions after resizing, not on file size, compression, color depth or format.
Crop to the region of interest, keep only the resolution the smallest defect needs, send only flagged or uncertain images to the VLM, keep prompts and answers short, and batch work that does not need a real-time answer.
