VLM Run Gateway: Run GLM-OCR, DeepSeek-OCR-2, dots.mocr with an OpenAI Compatible API
Open-weight OCR VLMs have advanced significantly over the past year, yet most teams still rely on frontier VLMs for document parsing because researching, evaluating, and deploying the right models remains challenging.
So we built VLM Run Gateway: one OpenAI-compatible endpoint for open-weight OCR and VLM models.
Try the Colab Quickstart
TL;DR: If you’re using frontier VLMs primarily for OCR/document parsing, open-weight OCR models can be dramatically cheaper and often very accurate. With a one-line change, you can switch between open-weight OCR VLMs (DeepSeek OCR 2, GLM-OCR, dots.mocr, Paddle OCR VL, PP-OCRv6, etc.) and process 100K+ pages for under $60.
No single VLM has won: Healthcare forms, construction drawings, and legal contracts each have different accuracy requirements. The “best” OCR model depends on the domain, scan quality, language, and layout density, and choosing the right one often means deploying models separately, running rigorous checks and evaluations on production data, and comparing costs. We see most teams skip the hassle and default to a frontier API.
Document orchestration built in: Teams often choose a VLM early based on quick vibe checks, then build preprocessing, batching, parsing, retries, and evaluation around its API. Six months later, a better model ships, but switching is expensive for reasons unrelated to model capability. The Gateway handles that layer end-to-end: send a PDF URL, and we rasterize it, distribute pages across workers, preserve page order, stream completed pages, retry failures, and isolate OOMs.
OpenAI-compatible API + MCP: We put open-weight OCR VLMs behind a single OpenAI-compatible endpoint. For API integrations into your workflows, use JSON mode with a strongly typed output contract. For agents, we ship an MCP server at https://gateway.vlm.run/mcp with a read_document tool that provides the same cost-efficient parsing, especially for long-form documents. Any MCP-compatible client (Claude Code, Codex, OpenCode, and others) can now consume visual content natively and cost-effectively.
client = OpenAI(
base_url="https://gateway.vlm.run/v1/openai",
api_key="<VLMRUN_API_KEY>",
)
response = client.chat.completions.create(
model="rednote-hilab/dots.mocr",
messages=[{
"role": "user",
"content": [{
"type": "document_url",
"document_url": {"url": "https://.../invoice.pdf"},
}],
}],
extra_body={"document_dpi": 72},
)
Model Catalog: Today you can switch between models like PP-OCRv6 (22M), GLM-OCR (0.9B), dots.mocr (3B), DeepSeek-OCR-2 (3B), PaddleOCR-VL (0.9B), and Florence-2-base-ft (0.2B).
Costs that let you scale: Frontier VLMs are still the right choice for open-ended reasoning, where the task is “figure out what this means” rather than “parse this.” But for extraction, OCR, layout, and parsing, they’re an expensive default. At production scale, the cost difference is significant, often 10x. Every Gateway response includes usage.cost, so you can run the same documents through multiple models and compare the exact costs yourself.
Evals: We have an internal accuracy leaderboard which we’ll soon release publicly. For now, we encourage you to run your own documents against the gateway to compare and validate the outputs and costs.
Other models: The Gateway also hosts other open-weight visual/audio models including Qwen3.5-0.8B, Qwen3-VL-Embedding-2B, and Parakeet ASR, with more coming soon.
Try it out quickly via the CLI:
uvx vlmrun gw models
uvx vlmrun config set --api-key 'vlmrun' # anon-user, rate-limited
uvx vlmrun gw chat <doc>.pdf -m zai-org/glm-ocr
uvx vlmrun gw chat <doc>.pdf -m zai-org/glm-ocr --json-mode
uvx vlmrun gw chat <doc>.pdf -m deepseek-ai/deepseek-ocr-2
uvx vlmrun gw chat <doc>.pdf -m rednote-hilab/dots.mocr
uvx vlmrun gw chat <doc>.pdf -m paddleocr/pp-ocrv6
- Docs: https://docs.vlm.run/gateway
- Catalog: https://docs.vlm.run/gateway/models
- MCP: https://docs.vlm.run/gateway/mcp-server
- Colab Quickstart: https://colab.research.google.com/drive/1RkuVIyuc5Po-UlcSlFyJCam5tjCm9IHM?usp=sharing
Run multiple documents across models in our catalog and tell us which performs best. We’re especially interested in workloads where the results are surprising.

