Vision-Language Model (VLM)
Running LLaVA locally: from a 4.37GB Q4 build to a 17.1GB OneVision-2, on one card
From llava-1.5-7b-hf — still pulling over 2.5 million downloads a month — to LLaVA-OneVision-2-8B released in April 2026, this lineage has changed repositories three times and licences twice. Here are the real VRAM numbers, the real commands, and the exact card to rent.
LLaVA · self-hosted
LLaVA (Large Language and Vision Assistant) came out of work by Haotian Liu, Chunyuan Li, Yuheng Li and Yong Jae Lee at UW–Madison and Microsoft Research. It was the first project to show that the minimalist recipe — vision encoder, a projection layer, a language model — was genuinely competitive. Its standing is still visible in the download counts: llava-hf/llava-1.5-7b-hf clears 2,521,243 downloads in a month, making it one of the most cited, most fine-tuned, most pipeline-embedded open VLMs in existence.
The catch is that almost every tutorial you will find stops at LLaVA-1.5 (2023) or LLaVA-1.6 (early 2024). The line has actually moved house three times. haotian-liu/LLaVA was home for the 1.5/1.6 era. Development then shifted to LLaVA-VL/LLaVA-NeXT, whose README now labels its own training pipeline legacy and points readers at lmms-engine. Active work happens in EvolvingLMMs-Lab/LLaVA-OneVision-1.5: the LLaVA-OneVision-1.5 technical report landed 2025-09-30 (arXiv 2509.23661), an RL recipe followed on 2025-12-11, the codec-aligned OneVision-Encoder on 2026-02-10, and LLaVA-OneVision-2 shipped from that same repo on 2026-04-30. So no, LLaVA is not dead — you just have to pull from the right repo.
One trap is specific to this family: what eats your VRAM is often not the weights, it is the visual tokens. LLaVA-1.5 uses CLIP ViT-L/14-336 and emits a fixed 576 visual tokens per image (336÷14=24, 24²=576). LLaVA-1.6 added AnyRes, supporting 672×672, 336×1344 and 1344×336; a 672×672 image is split into a 2×2 grid plus a global thumbnail, so 5×576 ≈ 2,880 tokens go straight into context. OneVision-2 then applies HEVC-style codec-aligned patch selection on video — keep I-frames dense, keep only motion- and residual-rich patches from P-frames — fitting 18 frames instead of 6 into the same token budget, roughly 3× the temporal coverage. Which means the same 8B model needs a completely different card depending on whether you feed it one photo or sixteen frames. Below, tier by tier, with a card you can boot on NexGPU right now.
01 —
Which LLaVA versions actually exist today, and what each one costs in VRAM
Parameter counts read from Hugging Face safetensors metadata; VRAM is weights only (bf16/fp16 at 2 bytes per parameter), excluding KV cache and visual-token activations.
| Version | Parameters | VRAM | Context | Notes |
|---|---|---|---|---|
| LLaVA-OneVision-2-8B-Instruct (lmms-lab-encoder) | 8.53B (8,527,213,568) | bf16 weights ≈ 17.1GB | Context ceiling not published on the card; video side is set by num_frames × max_pixels | The current flagship, released 2026-04-30. Qwen3-8B backbone plus the codec-aligned OneVision-Encoder, natively bilingual EN/ZH, architecture LlavaOnevision2ForConditionalGeneration. Needs transformers>=5.7.0, torch>=2.4 and trust_remote_code=True; the codec video backend additionally wants ffmpeg 4.4.x–7.x. Apache-2.0. |
| LLaVA-OneVision-2-4B-Instruct | 4B (Qwen3-4B-Instruct-2507 backbone) | Weights not released — no estimate given | Same OneVision-2 family | The official README marks this coming soon and the weights are not downloadable from Hugging Face yet. If a blog post claims the 4B is out, skip it rather than burn GPU-hours on a 404. If you need that tier today, use LLaVA-OneVision-1.5-4B-Instruct. |
| LLaVA-OneVision-1.5-8B-Instruct (plus 8B-RL) | 8.53B (8,527,214,624) | bf16 weights ≈ 17.1GB | Not published on the card | Shipped September 2025 with a DeepGlint-AI/rice-vit-large-patch14-560 vision tower and a Qwen language side. The selling point is native-resolution processing plus a genuinely open training pipeline — the 85M-sample mid-training corpus was released alongside the weights. An RL variant, mvp-lab/LLaVA-OneVision-1.5-8B-RL, followed in December 2025 at an identical parameter count. Apache-2.0. |
| LLaVA-OneVision-1.5-4B-Instruct | 4.74B (4,741,610,528) | bf16 weights ≈ 9.5GB | Not published on the card | The most comfortable tier for a single 24GB card: 9.5GB of weights leaves a dozen-plus GB entirely for KV cache and multi-image tokens. For bulk captioning, product-image tagging, or invoice and ID field extraction, this beats forcing the 8B onto the same card. Apache-2.0. |
| llava-onevision-qwen2-7b-ov-hf / -72b-ov-hf (2024 OneVision) | 8.03B (8,030,807,584) / 73.18B (73,181,570,592) | fp16 ≈ 16.1GB / ≈ 146GB | Requires transformers >= 4.45 | The tier with native transformers support and no trust_remote_code needed — architecture LlavaOnevisionForConditionalGeneration, recognised directly by vLLM. Note that the 72B's fp16 weights come to about 146GB, more than a single H200's 141GB, so one card physically cannot hold it: tensor-parallel or drop precision. Apache-2.0. |
| LLaVA-1.6 / LLaVA-NeXT and LLaVA-1.5 (previous generation) | 7B / 13B / 34B | 1.5-7B fp16 ≈ 14.1GB, 1.5-13B fp16 ≈ 26.7GB; 1.6-7B GGUF: Q4_K_M 4.37GB, Q5_K_M 5.13GB, Q8_0 7.7GB | llava:7b is 32K; llava:13b and llava:34b are 4K (per Ollama) | The generation with the deepest tooling support — Ollama's llava:7b (4.7GB), llava:13b (8.0GB) and llava:34b (20GB) are all 1.6. Licensing is the trap here: LLaVA-1.5 weights carry the Llama 2 Community License, while llava-v1.6-mistral-7b-hf (built on Mistral-7B-Instruct-v0.2) is the Apache-2.0 one. Check which you actually pulled before shipping commercially. |
02 —
Pick by workload — do not rent an H100 to caption one photo
NexGPU spans 51 countries and regions, 1,175 verified rentable nodes, 2,498 GPUs across 75 models, up to 14 GPUs per node and 2,152GB max node VRAM. Rates below are list price per GPU-hour.
Get LLaVA-1.6-7B running on Q4 first — quality comparison and prompt iteration
RTX 3090 24GB$0.193/GPU-hr
Q4_K_M weights are 4.37GB plus the mmproj-model-f16 vision projector; what remains of 24GB is plenty to run AnyRes at full resolution. It is also the cheapest 24GB card on the network — a third less than the 16GB Tesla T4 at $0.298.
LLaVA-OneVision-1.5-4B in bf16 as a resident bulk captioning / tagging API
RTX 4090 24GB$0.540/GPU-hr
9.5GB of weights leaves a dozen-plus GB for vLLM's KV cache and multi-image tokens, and per-request latency is clearly better than a 3090. This is the sweet spot for something you leave running and serve traffic from.
LLaVA-OneVision-2-8B bf16 online serving, or 16-frame video QA
RTX 5090 32GB$0.723/GPU-hr
After 17.1GB of weights you still have roughly 14GB for visual tokens and concurrency. In multi-frame work it is never the weights that blow up first, it is the activations — a 24GB card OOMs the moment you raise num_frames, and 32GB is the safe line.
OneVision-72B fp16 full-precision evaluation, or full-parameter / large-scale LoRA on 8B
A100 SXM4 80GB (two-way tensor parallel)$1.088/GPU-hr
73.18B in fp16 is about 146GB — more than a single H200's 141GB, so one card is physically out. Two 80GB cards is the floor. With up to 14 GPUs per node on NexGPU, scaling up to full-parameter fine-tuning later does not mean rebuilding your environment elsewhere.
03 —
Four steps to a running LLaVA
Built around the current LLaVA-OneVision-2-8B-Instruct, with a GGUF route at the end for smaller cards.
- 01
Spin up an instance on a vLLM prebuilt image
At console.nexgpu.net, pick a card by VRAM (RTX 5090 32GB or better for the 8B in bf16) and choose a PyTorch or vLLM image from the 2,000+ prebuilt options so you skip CUDA and driver setup entirely. Get in over SSH, Jupyter or the web terminal. OneVision-2 is version-sensitive, so pin the dependencies first — anything below transformers 5.7.0 will fail outright when the custom modelling code loads.
pip install -U vllm "transformers>=5.7.0" "torch>=2.4" pillow requests decord - 02
Pull the weights and serve an OpenAI-compatible endpoint
One vLLM command downloads the model and stands up the HTTP server. OneVision-2 ships custom modelling code, so trust_remote_code is not optional. If you are instead running the 2024-era llava-onevision-qwen2-7b-ov-hf, transformers supports it natively and you can drop that flag. Expect a few minutes of downloading 17GB before first token — that time is billed per second, and compute billing stops the moment you stop the instance.
vllm serve lmms-lab-encoder/LLaVA-OneVision-2-8B-Instruct --trust-remote-code --dtype bfloat16 --port 8000 - 03
Send your first image over the OpenAI protocol
Once it is up it is plain /v1/chat/completions, mixing image_url and text entries in the content array. The most common failure here is setting max_model_len too low: a single 672×672 image under AnyRes can consume nearly 2,900 visual tokens, and with a system prompt on top you hit the ceiling fast — after which you get the error about image features not matching the number of image tokens.
curl http://localhost:8000/v1/chat/completions -H 'Content-Type: application/json' -d '{"model":"lmms-lab-encoder/LLaVA-OneVision-2-8B-Instruct","messages":[{"role":"user","content":[{"type":"image_url","image_url":{"url":"https://example.com/a.jpg"}},{"type":"text","text":"How many people are in this image, and what is each doing?"}]}]}' - 04
Low-VRAM route: GGUF plus llama.cpp
On 16GB or less, quantise. cjpais/llava-1.6-mistral-7b-gguf carries the full ladder from Q3_K_XS at 2.99GB to Q8_0 at 7.7GB. Note that the vision half lives in a separate mmproj-model-f16.gguf and must be loaded with --mmproj; downloading only the language weights will not work. Also be aware that llama.cpp folded the old llava-cli into the unified libmtmd — the entry point today is llama-mtmd-cli, LLaVA is classified there as a legacy architecture, and the mtmd sub-project states it is under very heavy development with breaking changes expected, so pin your version before production. For a one-liner, ollama run llava:7b (4.7GB) also works.
llama-mtmd-cli -m llava-v1.6-mistral-7b.Q4_K_M.gguf --mmproj mmproj-model-f16.gguf --image ./a.jpg -p "Describe this image"
A real LoRA fine-tune, costed out
Say you want LLaVA-OneVision-1.5-8B-Instruct adapted to your own support-ticket screenshots. Take an A100 PCIE 80GB at $0.824/GPU-hr and run single-card LoRA for 12 hours: 12 × $0.824 = $9.89. Data plus weights occupy 80GB of storage (17.1GB of weights, dataset, checkpoints); at the $0.414/GB-month median that is 80 × $0.414 × 3 ÷ 30 = $3.31 for three days. Pulling the LoRA adapter back down is 0.5GB × $0.0081/GB = $0.004. Total: roughly $13.2. For perspective, the LLaVA-OneVision-1.5 team disclosed that training the 8B cost them around $16,000 (reckoned at roughly $0.60 per A100 GPU-hour) — you do not have to repeat that; standing on their Apache-2.0 weights and fine-tuning costs two figures. Cheaper still: just validating quality with Q4-quantised LLaVA-1.6-7B on an RTX 3090 24GB for two hours is 2 × $0.193 = $0.386, less than a coffee. At the top end: OneVision-72B in fp16 needs two A100 SXM4 80GB cards, so a six-hour evaluation run is 2 × $1.088 × 6 = $13.06. Everything is metered per second and priced per hour — no minimum, no setup fee, no quota request. Compute billing stops when the instance stops; storage runs until you destroy it.
04 —
FAQ
Is LLaVA obsolete? Is it still worth self-hosting in 2026?
How much VRAM does LLaVA actually need? Give me the numbers.
Why do I get 'image features and image tokens do not match' as soon as I run it?
Can I use LLaVA commercially? How does the licensing work?
How do I deploy LLaVA-OneVision-2 for video, and how many GPUs does it take?
LLaVA versus Qwen-VL or InternVL — which should I pick?
More in Multimodal vision models
Start building on NexGPU
Enterprise R&D team or solo developer — either way, your first job can be running in minutes.
Sign up to browse live network pricing. No payment method required.
