Two tabs open, a 40,000-page contract-review job due by tomorrow morning, and a choice between Ling-3.0 Flash VL and its text-only Flash sibling. The pricing cards look almost identical: same rough per-million-token input rate, same output rate. So the obvious move is to grab the VL model and skip the OCR step entirely. That’s the move that burns your budget at page 18,000.
The rate isn’t where the cost lives
A vision-language model doesn’t charge extra for “seeing” an image the way a surcharge would. Before the transformer sees any of it, the model converts the image into a block of input tokens through patch embedding and tiling, then bills those tokens at the same per-token input rate as text. Depending on resolution and how aggressively the provider tiles a page, that block can run anywhere from a few hundred to well over a thousand tokens for a single scanned document page. A flat per-token rate on the pricing card can sit right next to a text-only sibling’s rate and make vision look free. It isn’t. The rate is the same; the token count per request is the thing that moved.
I can’t tell you Ling-3.0 Flash VL’s exact tiling scheme from the price table alone. The site’s model rows carry live per-token and (where applicable) per-image rates, not tokenizer internals, and tiling behavior is provider-specific and shifts between model versions. Before committing a 40,000-page run to any VL tier, pull one representative page through the API and read the usage object in the response. That number is the one that matters, not the headline rate on the model page.
Where the parity trap bites
This is the non-obvious part. A VL variant priced at parity with its text sibling is often the worse deal for document-heavy work, specifically because the parity is on rate, not on volume. A clean typed-text page might cost 300-400 input tokens through a text pipeline fed by cheap OCR. The same page through a VL model’s vision encoder, tiled into multiple patches at high resolution, can land at 4-5x that input token count before you’ve written a single prompt token. Multiply by 40,000 pages and the gap compounds fast. A job budgeted against the text-tier estimate can blow through its allocation with 22,000 pages still unprocessed and a 48-hour contractual window closing.
The same logic shows up on a smaller scale with something like GLM-4.7 Flash: a 31B-total, 3B-active model built to be cheap for high-volume text work. Its whole economic case rests on small active-param compute per token. Feed a VL variant of a similarly-sized model thousand-token image blocks per request and you’ve erased the exact advantage the Flash tier exists to deliver.
Running the numbers
Before picking a tier, build two line items and run them through the calculator with today’s live rates on both sides:
Text pipeline: OCR extraction (often near-zero marginal cost if you’re running an open OCR tool locally) plus roughly 300-400 input tokens and 150 output tokens per page, priced against the text-only sibling’s rate.
Vision pipeline: estimated image token overhead per page (test it, don’t assume it) plus the same output tokens, priced against the VL tier’s rate.
For 40,000 pages, even a modest 3-4x token multiplier on the vision side usually outweighs any per-token discount a flash-tier VL model might offer over a larger text model. The exception is when your documents genuinely need layout understanding (tables, handwriting, mixed scripts, stamps) that a text-only OCR pass can’t recover accurately. Then the extra tokens are buying something real.
Provider choice matters here too, independent of VL versus text. As of this writing, the spread between the cheapest and priciest provider serving the identical model runs past 20x on DeepSeek V4 Flash and past 20x on Qwen3 235B A22B, with similar spreads on Llama 3.1 405B and Llama 3.1 8B. A reader who picks the “right” tier but the wrong provider can lose more money than the VL-versus-text decision cost them in the first place. Check the provider spread on whichever row you land on before you lock in a route.
The decision rule
Test one representative page through the VL model’s API and read the actual input token count from the response, not an estimate. If that count sits under roughly 2-3x what the same page would cost as plain extracted text, and your documents need genuine visual parsing, run the VL tier and treat the markup as the price of accuracy. If the count runs past that, or your documents are clean typed text that a free OCR pass handles fine, route through OCR first and feed the text-only sibling. The per-token rate parity on the pricing card is not the signal. The token count per page is, and it only shows up once you’ve sent a page through and read the number back.