A text-only LLM agent is forgiving on hardware: a single A100 80GB handles 50-100 concurrent sessions comfortably. Add screenshots to the loop, and the math changes completely. A vision-language model has to sit resident in VRAM before the first screenshot ever arrives, and a 1080p screenshot encodes to 512-2,048 visual tokens depending on tiling strategy, before the model has generated a single word about what it sees. This guide covers sizing GPUs for browser-use and computer-use agents specifically.
Quick picks
- Best for DOM-based web automation (no screenshots): whatever GPU your underlying LLM needs; browser-use's DOM-based approach doesn't require a vision model at all, so a text-only agent's sizing guidance applies directly.
- Best for screenshot-driven agents at moderate concurrency: A100 80GB running a 7B-class vision-language model like Qwen2.5-VL-7B, colocated with the headless browser pool on the same pod.
- Best for a fully self-contained system with no external API: a GPU with 16GB+ VRAM running UI-TARS, which ships its own model rather than requiring you to pick and serve one separately.
Two fundamentally different agent architectures need different GPUs
DOM-based agents (browser-use is the reference implementation) read a webpage's actual DOM structure rather than a screenshot, and get near-100% click accuracy on standard websites as a result. They don't need a vision model, so GPU sizing is identical to any text-only LLM agent: whatever your chosen reasoning model needs.
Screenshot-based agents (the pattern behind Anthropic's Computer Use, OpenAI's computer-using agent capabilities, and self-hosted options like UI-TARS) see the screen the way a human does and decide where to click based on pixel content. This is necessary for desktop applications and GUIs without a clean DOM, but it requires a vision-language model in the loop for every single action, not just at the start of a task.
Sizing the VLM backbone for screenshot-based agents
| Model | VRAM | Recommended Runpod GPU | Best for |
|---|---|---|---|
| Qwen2.5-VL-7B-Instruct | ~16-20 GB at BF16 | RTX 4090 or L40S | General screenshot understanding, moderate concurrency |
| InternVL3 8B | ~17 GB at BF16 | RTX 4090 or L40S | Document-heavy pages: forms, tables, dense text |
| InternVL3 26B | ~26 GB at INT8 | A100 80GB or H100 | Higher-accuracy document extraction at scale |
| UI-TARS | 16 GB+ (ships its own model) | RTX 4090 or L40S | Fully self-contained, no separate model choice needed |
Why colocation matters more here than for a typical LLM deployment
Text-only agents tolerate a few hundred milliseconds of model latency without feeling broken. Browser and computer-use agents are more sensitive: a visible pause between an action and the agent reading its result makes the whole interaction feel unresponsive. Running the VLM server and the headless browser pool on the same physical Runpod Pod cuts screenshot transfer from a network round-trip down to a loopback call, which is the difference between an agent that feels instant and one that feels like it's thinking too hard about every click. That colocation advantage only exists when you control the GPU instance directly, which is the main practical reason to self-host this stack rather than call a hosted computer-use API for every action.
A minimal architecture
- Deploy Qwen2.5-VL-7B-Instruct (or your chosen VLM) with vLLM on a Runpod Pod:
vllm serve Qwen/Qwen2.5-VL-7B-Instruct --dtype bfloat16 --max-model-len 16384 --max-num-seqs 60 --port 8000 - Run your browser automation (Playwright via
browser-use, or a custom screenshot loop) on the same pod, calling the local vLLM endpoint over loopback rather than a network hop - Size
--max-num-seqsto your expected concurrent session count; each active session holds a screenshot's worth of visual tokens in the KV cache for the duration of its action loop
When self-hosting beats a hosted computer-use API
The crossover point depends on volume, not principle. A single H100 running self-hosted inference at spot pricing pays for itself against per-session hosted computer-use pricing once you're running roughly 50+ sessions a day, though exact numbers shift with GPU spot pricing and whichever hosted API you're comparing against. Below that volume, a hosted API's simplicity usually wins; above it, the GPU cost amortizes fast enough that self-hosting is the better economics, with the added benefit of controlling exactly which VLM you run and keeping screenshots of internal applications off a third-party API.
FAQ
Do I need a GPU for browser automation?
Only if your agent uses a self-hosted model. DOM-based agents like browser-use need whatever GPU your underlying LLM requires; if you're calling a cloud API for reasoning, no GPU is needed for the browser automation layer itself.
What's the minimum VRAM for a self-hosted computer-use agent?
Roughly 16-20 GB for a capable 7B-class vision-language model at BF16, which covers most screenshot-based automation tasks. Document-heavy or high-accuracy use cases benefit from a larger VLM and correspondingly more VRAM.
Should I colocate the browser and the model on the same GPU instance?
Yes, if latency matters to the user experience. Colocation eliminates the network round-trip for every screenshot, which is the main latency cost in a screenshot-driven action loop.
