inference/research
verifiedhigh · 0.90updated 2026-10-03

Qwen2-VL-7B-Instruct

dense 8.291B

Fields

id
models/qwen2-vl-7b-instruct
Family
qwen2-vl
Vendor
Alibaba (Qwen)
Release year
2024
Architecture
dense
Params (B)
8.291
Active params (B)
8.291
Hidden size
3,584
Layers
28
KV heads
4
Head dim
128
GQA ratio
7
Max context
32,768
Context scaling
mrope
Context scaling method
mrope
Activation
silu
Attention variant
GQA + mrope
KV cache (bytes/token)
57,344
FLOPs per active token
16,582,000,000
Open weights
yes
License
apache-2.0
notes
TWO-PART MODEL. (1) Vision: custom 32-layer ViT, hidden_size 1280, 16 heads, patch_size 14, spatial_merge_size 2, temporal_patch_size 2, out_hidden_size 3584. No windowed attention in Qwen2-VL (full attention over all patches). (2) LLM: Qwen2-7B dense decoder, 28 layers, hidden 3584, 28 heads / 4 KV heads, head_dim 128 (verified: k_proj weight is [512, 3584] = 4*128). ARCHITECTURE = dense, because the LLM backbone is dense. CONTEXT_SCALING = mrope: rope_scaling.type is literally 'mrope' with mrope_section [16,24,24] (t,h,w interleaved across 64 of the 128 head-dim halves), so positions are 3-D, not 1-D. VISION TOKENS: dynamic resolution, no fixed grid. tokens = (H/28)*(W/28) because patch 14 merges 2x2. A 448x448 image = 16*16 = 256 vision tokens. DOMINANCE: vision does NOT dominate at typical resolutions -- a 256-token image against a ~1000-token text prompt puts text at ~80% of prefill. But cost is attacker-controlled via image size: a 4K image (3840x2160) is 137*77 = 10,549 vision tokens, which completely dominates. KV CACHE: 28 layers * 4 kv_heads * 128 head_dim * 2 (K and V) * 2 bytes (bf16) = 57,344 B/token (= 56 KiB). At 32,768 ctx that is 1.75 GiB of resident KV per sequence. FLOPs_per_token_active = 2 * 8.291e9 = 1.66e10 for the LLM decode step only; the vision encoder is a one-time ~0.6B-param forward pass per image that this per-token figure does not capture. params_b 8.291 = HF API safetensors total (8,291,375,616), not the '7B' in the name -- the vision tower plus the 152,064-row embedding table account for the difference. SERVICEABILITY JOIN (added 2026-10-03; the architecture x engine matrix this record was missing, with a citation per cell in docs/13-model-compatibility.md): FAMILY=multimodal. REQUIRED KERNEL CLASS: an encoder tower (ViT / SigLIP / ConvNet / audio encoder) running on a SEPARATE schedule from the decoder, plus a projector into the decoder's embedding space, plus - for the mrope and DeepStack families - a multi-axis rotary scheme in the decoder rather than plain 1-D RoPE. Three engine-side consequences, all cited. (1) The encoder tower is a separate compute path, so its throughput is a different problem from decode throughput and engines that disclaim encoder throughput are disclaiming this. vLLM says so in its own words: 'We currently support pooling models primarily for convenience. This is not guaranteed to provide any performance improvements over using Hugging Face Transformers or Sentence Transformers directly' [[vllm-pooling-models]] - that is the general statement this class inherits. TRT-LLM's answer is a documented mechanism: a Multimodal Encoder Side Stream that prefetches encoder work on a separate CUDA stream plus a per-model Multimodal Embeddings Cache, currently available only for seven architectures (Gemma4, Gemma4Unified, Mistral3, Qwen3VL, Qwen3VLMoe, Qwen3_5, Qwen3_5Moe) [[mdl2-trtllm-supported-models]]. (2) Several towers carry hard external dependencies: Gemma3nForConditionalGeneration 'depends on timm>=1.0.17 to make use of its MobileNet-v5 vision backbone' and 'is only supported on V1 due to shared KV caching' [[mdl2-vllm-supported-models-2026-10]]; MiniCPM-V 4.6 requires transformers>=5.7.0 because it was upstreamed as a native model type [[mdl2-trtllm-supported-models]]. (3) Hybrid-only multimodal models expose a memory knob unique to this class: vLLM's --language-model-only flag sets all supported multimodal modalities to 0 so the multimodal modules are not loaded, 'to free up more GPU memory for KV cache' for Llama-4, Step3, Mistral-3 and Qwen-3.5 [[mdl2-vllm-supported-models-2026-10]].SUPPORTED BY (cited): vLLM native rows include InternVLChatModel and InternVLForConditionalGeneration, LlavaOnevisionForConditionalGeneration, LlavaNextForConditionalGeneration, MolmoForCausalLM and Molmo2ForConditionalGeneration, PaliGemmaForConditionalGeneration, SmolVLMForConditionalGeneration, Glm4vForConditionalGeneration, Qwen2VL/Qwen3VL, MiniCPMV, Mllama, Phi4MM, Gemma4, NemotronH_Nano_VL_V2, VoxtralForConditionalGeneration (which requires mistral-common[audio]) and Qwen3OmniMoeThinkerForConditionalGeneration [[mdl2-vllm-supported-models-2026-10]]. SGLang's multimodal table covers InternLM2-VL, LLaVA-OneVision, LLaVA-NeXT(-Video), Ling-3.0-flash-VL, LFM2.5-VL, MiniCPM-V-2, GLM-4.5V, GLM-OCR, Qwen3-VL 235B-A22B and 30B-A3B, Qwen3-Omni-30B-A3B, Kimi-VL-A3B, MiMo-VL-7B-RL, Step3-VL-10B, dots.ocr, PaddleOCR-VL, Cosmos3, deepseek-vl2, Janus-Pro-7B, NVILA-8B and gemma-3-4b-it, plus openai/whisper-large-v3 and Qwen3-ASR-1.7B on the audio route [[mdl2-sglang-multimodal-language-models]]. TRT-LLM's multimodal matrix covers a narrower set with an explicit per-row modality string and per-row Untested cells [[mdl2-trtllm-supported-models]]. Older GGUF-side engines reach the class through llama.cpp's projector graph, which llama.cpp-embedding-server states it cannot serve on the embedding route [[llama-cpp-embedding-server]]. PER-MODALITY CAVEATS CITED: TRT-LLM marks Gemma4Unified and MiniCPM-V 4.6 Untested for CUDA Graph / chunked prefill, MiniMax-M3 Untested for attention DP and KV cache reuse, Qwen4Exp Untested across the board, and notes audio requires a checkpoint with a sound_config and is supported only on the full non-disaggregated path [[mdl2-trtllm-supported-models]]. Step-3.7's vision tower runs in BF16 even when the text decoder is quantized [[mdl2-trtllm-supported-models]] - a precision asymmetry that silently costs memory. vLLM's fallback path accepts image inputs only, with video 'to be added in a future release' [[mdl2-vllm-supported-models-2026-10]]. CONTEXT_SCALING_METHOD (mrope): config-derived; the existing free text 'mrope' agrees.

Notes

TWO-PART MODEL. (1) Vision: custom 32-layer ViT, hidden_size 1280, 16 heads, patch_size 14, spatial_merge_size 2, temporal_patch_size 2, out_hidden_size 3584. No windowed attention in Qwen2-VL (full attention over all patches). (2) LLM: Qwen2-7B dense decoder, 28 layers, hidden 3584, 28 heads / 4 KV heads, head_dim 128 (verified: k_proj weight is [512, 3584] = 4*128). ARCHITECTURE = dense, because the LLM backbone is dense. CONTEXT_SCALING = mrope: rope_scaling.type is literally 'mrope' with mrope_section [16,24,24] (t,h,w interleaved across 64 of the 128 head-dim halves), so positions are 3-D, not 1-D. VISION TOKENS: dynamic resolution, no fixed grid. tokens = (H/28)*(W/28) because patch 14 merges 2x2. A 448x448 image = 16*16 = 256 vision tokens. DOMINANCE: vision does NOT dominate at typical resolutions -- a 256-token image against a ~1000-token text prompt puts text at ~80% of prefill. But cost is attacker-controlled via image size: a 4K image (3840x2160) is 137*77 = 10,549 vision tokens, which completely dominates. KV CACHE: 28 layers * 4 kv_heads * 128 head_dim * 2 (K and V) * 2 bytes (bf16) = 57,344 B/token (= 56 KiB). At 32,768 ctx that is 1.75 GiB of resident KV per sequence. FLOPs_per_token_active = 2 * 8.291e9 = 1.66e10 for the LLM decode step only; the vision encoder is a one-time ~0.6B-param forward pass per image that this per-token figure does not capture. params_b 8.291 = HF API safetensors total (8,291,375,616), not the '7B' in the name -- the vision tower plus the 152,064-row embedding table account for the difference.

SERVICEABILITY JOIN (added 2026-10-03; the architecture x engine matrix this record was missing, with a citation per cell in docs/13-model-compatibility.md): FAMILY=multimodal. REQUIRED KERNEL CLASS: an encoder tower (ViT / SigLIP / ConvNet / audio encoder) running on a SEPARATE schedule from the decoder, plus a projector into the decoder's embedding space, plus - for the mrope and DeepStack families - a multi-axis rotary scheme in the decoder rather than plain 1-D RoPE. Three engine-side consequences, all cited. (1) The encoder tower is a separate compute path, so its throughput is a different problem from decode throughput and engines that disclaim encoder throughput are disclaiming this. vLLM says so in its own words: 'We currently support pooling models primarily for convenience. This is not guaranteed to provide any performance improvements over using Hugging Face Transformers or Sentence Transformers directly' [[vllm-pooling-models]] - that is the general statement this class inherits. TRT-LLM's answer is a documented mechanism: a Multimodal Encoder Side Stream that prefetches encoder work on a separate CUDA stream plus a per-model Multimodal Embeddings Cache, currently available only for seven architectures (Gemma4, Gemma4Unified, Mistral3, Qwen3VL, Qwen3VLMoe, Qwen3_5, Qwen3_5Moe) [[mdl2-trtllm-supported-models]]. (2) Several towers carry hard external dependencies: Gemma3nForConditionalGeneration 'depends on timm>=1.0.17 to make use of its MobileNet-v5 vision backbone' and 'is only supported on V1 due to shared KV caching' [[mdl2-vllm-supported-models-2026-10]]; MiniCPM-V 4.6 requires transformers>=5.7.0 because it was upstreamed as a native model type [[mdl2-trtllm-supported-models]]. (3) Hybrid-only multimodal models expose a memory knob unique to this class: vLLM's --language-model-only flag sets all supported multimodal modalities to 0 so the multimodal modules are not loaded, 'to free up more GPU memory for KV cache' for Llama-4, Step3, Mistral-3 and Qwen-3.5 [[mdl2-vllm-supported-models-2026-10]].SUPPORTED BY (cited): vLLM native rows include InternVLChatModel and InternVLForConditionalGeneration, LlavaOnevisionForConditionalGeneration, LlavaNextForConditionalGeneration, MolmoForCausalLM and Molmo2ForConditionalGeneration, PaliGemmaForConditionalGeneration, SmolVLMForConditionalGeneration, Glm4vForConditionalGeneration, Qwen2VL/Qwen3VL, MiniCPMV, Mllama, Phi4MM, Gemma4, NemotronH_Nano_VL_V2, VoxtralForConditionalGeneration (which requires mistral-common[audio]) and Qwen3OmniMoeThinkerForConditionalGeneration [[mdl2-vllm-supported-models-2026-10]]. SGLang's multimodal table covers InternLM2-VL, LLaVA-OneVision, LLaVA-NeXT(-Video), Ling-3.0-flash-VL, LFM2.5-VL, MiniCPM-V-2, GLM-4.5V, GLM-OCR, Qwen3-VL 235B-A22B and 30B-A3B, Qwen3-Omni-30B-A3B, Kimi-VL-A3B, MiMo-VL-7B-RL, Step3-VL-10B, dots.ocr, PaddleOCR-VL, Cosmos3, deepseek-vl2, Janus-Pro-7B, NVILA-8B and gemma-3-4b-it, plus openai/whisper-large-v3 and Qwen3-ASR-1.7B on the audio route [[mdl2-sglang-multimodal-language-models]]. TRT-LLM's multimodal matrix covers a narrower set with an explicit per-row modality string and per-row Untested cells [[mdl2-trtllm-supported-models]]. Older GGUF-side engines reach the class through llama.cpp's projector graph, which llama.cpp-embedding-server states it cannot serve on the embedding route [[llama-cpp-embedding-server]]. PER-MODALITY CAVEATS CITED: TRT-LLM marks Gemma4Unified and MiniCPM-V 4.6 Untested for CUDA Graph / chunked prefill, MiniMax-M3 Untested for attention DP and KV cache reuse, Qwen4Exp Untested across the board, and notes audio requires a checkpoint with a sound_config and is supported only on the full non-disaggregated path [[mdl2-trtllm-supported-models]]. Step-3.7's vision tower runs in BF16 even when the text decoder is quantized [[mdl2-trtllm-supported-models]] - a precision asymmetry that silently costs memory. vLLM's fallback path accepts image inputs only, with video 'to be added in a future release' [[mdl2-vllm-supported-models-2026-10]].

CONTEXT_SCALING_METHOD (mrope): config-derived; the existing free text 'mrope' agrees.

Cross-references

This record references no other records — it is a leaf. It is cited by 0.