NVIDIA Nemotron Nano V2 VL

🎯 Pitch

A 12B vision-language model matches the unrestricted reasoning performance of its 72B teacher on MathVista while using 35% less compute—simply by giving it a "reasoning budget." This hybrid Mamba-Transformer model also hits top marks on OCRBench v2 and doubles video processing speed by learning which video patches to ignore, all without destroying the base LLM's code-writing skills.

1. Executive Summary

This paper introduces Nemotron Nano V2 VL, a 12B vision–language model that delivers substantial improvements over its predecessor Llama-3.1-Nemotron-Nano-VL-8B through a combination of an upgraded hybrid Mamba-Transformer LLM backbone (Nemotron Nano V2), expanded multi-stage supervised fine-tuning across 8M+ samples (spanning image, video, document, and text reasoning data), and Efficient Video Sampling (EVS) (pruning temporally static patches to accelerate video throughput by 2× or more with minimal accuracy loss). The model achieves leading scores on OCRBench v2 private leaderboard while reaching 35% higher inference throughput in long document scenarios compared to the prior 8B model, and establishes that a smaller model with reasoning budget control can outperform unrestricted reasoning on several tasks — though text reasoning capabilities still degrade after initial multimodal training, requiring a dedicated code reasoning recovery stage to restore the LiveCodeBench score from 50.9 back to 69.8.

2. Context and Motivation

The Core Problem: Training VLMs That Excel at Document and Video Understanding Without Sacrificing Text Reasoning

The fundamental challenge this paper tackles is deceptively simple to state but fiendishly difficult to execute: how do you add vision capabilities to a strong language model without breaking the very reasoning abilities that made the LLM useful in the first place?

This is not a new problem—every vision–language model (VLM) training pipeline grapples with it—but the paper's explicit framing in Section 3 and the detailed stage-by-stage text benchmark tracking in Table 6 make it the organizing tension of the entire project. The authors observe that after their initial multimodal SFT stage (Stage 1), the LiveCodeBench score of the underlying LLM drops from 70.0 to 50.87—a catastrophic 27% relative decline in code reasoning ability. The RULER long-context score collapses from 77.9 to 8.8, effectively erasing the model's ability to handle extended sequences. These are not minor regressions; they represent a near-total loss of specific capabilities that the text-only backbone possessed.

This matters for several practical reasons:

Real-world VLM deployment requires both modalities. An enterprise document-understanding system needs to extract text from PDFs AND perform arithmetic/date calculations/code generation on that extracted content. If the model's math and code skills degrade during vision training, the system fails at its core use case—even if OCR accuracy improves.
Long-context video understanding demands long-context text understanding. Processing hour-long videos with hundreds of frames generates enormous token sequences. If the LLM backbone forgets how to attend over long contexts (as the RULER collapse from 77.9 → 8.8 demonstrates), video understanding benchmarks like Video-MME that depend on long-range temporal reasoning become impossible to improve, regardless of how good the vision encoder is.
The training economics penalize brute-force solutions. One obvious approach to avoiding text degradation is to simply include more text reasoning data during multimodal training, but the paper explicitly notes in Section 3.4 that they "explored several mitigation strategies that were unsuccessful, including augmenting the SFT stage 1 dataset with additional code reasoning examples and disabling loss scaling." Naively mixing in more code data didn't work—suggesting the mechanism of forgetting is not simply a data-imbalance problem but something more fundamental about how multimodal training interferes with text-only reasoning circuits.

Why Existing VLM Training Approaches Fall Short

The paper positions itself within a mature VLM research landscape, but identifies specific limitations in the standard training paradigm:

Multi-stage training exists, but degradation recovery is poorly characterized. Prior work like InternVL (Chen et al., 2024d), LLaVA (Liu et al., 2024b), and Eagle (Li et al., 2025b; Chen et al., 2025a) has established multi-stage VLM training recipes—typically pretraining the vision-language connector followed by multimodal SFT. However, these works primarily report final benchmark numbers without tracking the intermediate text-only performance train-wreck that occurs. The paper's decision to publish the full stage-by-stage text benchmark trajectory in Table 6 (showing MATH-500 at 96.8 post-Stage 1 despite code dropping to 50.87—an interesting asymmetry where math holds up better than code) provides diagnostic signal that prior work has largely omitted. This transparency makes the degradation problem concrete and measurable rather than anecdotal.

Hybrid Mamba-Transformer architectures promise efficiency but add training complexity. The previous generation model, Llama-3.1-Nemotron-Nano-VL-8B, used a conventional Transformer backbone. Nemotron Nano V2 VL upgrades to Nemotron Nano V2 (NVIDIA et al., 2025), a hybrid Mamba-Transformer architecture. This architectural shift is motivated by throughput: the Mamba layers process sequences with constant memory and sub-quadratic complexity, offering 35% higher throughput in long document scenarios (Section 1). However, hybrid architectures introduce new training dynamics—the interaction between Mamba's state-space processing and Transformer attention during multimodal fine-tuning is not as well-studied, and the paper implicitly demonstrates that the multimodal training interference with text capabilities manifests differently (and perhaps more severely) in this architecture.

Long-context VLMs require both architectural and data innovations. Extending context length from 16K to 128K (as the paper does) is not simply a matter of changing a config parameter. The paper employs context parallelism (Section 3.6) to partition the LLM input along the sequence dimension across GPUs—an infrastructure choice that interacts with the vision pipeline because vision encoder and projection replicas need to be split across the context-parallel shards. Prior work like LongViLA (Chen et al., 2024c) explored context parallelism for video VLMs, but the paper extends this to a hybrid Mamba-Transformer setting and validates it across multiple SFT stages with different maximum lengths (49K for Stages 2–3, 311K for Stage 4). The staged approach—gradually increasing context length rather than jumping directly to 128K—is motivated by training stability and data availability: the 49K stage uses 1.4M video/multi-image samples, while the 300K stage uses only 74K samples (12B tokens) of long-context data, suggesting that very long-context multimodal training data remains scarce and must be used efficiently.

Video processing token efficiency is underexplored. Prior VLMs typically process videos by uniformly sampling frames and encoding each as visual tokens, leading to token counts that scale linearly with video duration. This creates a fundamental tension: longer videos provide more information but incur prohibitive inference costs. The paper observes that many video frames contain temporally static regions—a lecture video's slide background, a cooking video's kitchen counter—that contribute visual tokens without information gain. Efficient Video Sampling (EVS) (Bagrov et al., 2025) directly addresses this by pruning temporally static patches, but integrating it into a VLM without retraining and quantifying the accuracy-throughput tradeoff across precision formats (BF16 vs. FP8, Figure 4) is new and practically significant.

OCR and document understanding VLMs hit a performance ceiling on existing benchmarks. The paper positions itself against OCR-focused VLMs by targeting OCRBench v2—a benchmark explicitly designed (Fu et al., 2024a) to test visual text localization AND reasoning, not just character recognition. Prior models may achieve high OCR accuracy but fail on reasoning questions that require interpreting extracted text. The paper's architecture choices (dynamic tiling with thumbnail for global context, pixel shuffle for token reduction to 256 per tile, maximum 12 tiles + 1 thumbnail per image) are directly motivated by the need to preserve fine-grained text readability while maintaining global layout understanding—a dual requirement that simpler VLM designs (single-resolution encoding, no tiling) struggle with.

How This Paper Positions Itself

The paper situates itself not as a radical architectural departure but as a systematic engineering contribution that combines proven components (RADIOv2.5 vision encoder, Nemotron Nano V2 backbone, multi-stage SFT from Eagle) with careful training-stage optimization and thorough diagnostics. The novel contributions are in the details:

The explicit text-recovery stages (Stages 3 and 4) as a first-class part of the VLM recipe. Rather than treating text degradation as an unavoidable side effect or hiding it behind final-benchmark reporting, the paper adds TWO dedicated recovery stages—one for code reasoning (1M samples, 15B tokens) and one for long context (74K samples, 12B tokens, average length 160K tokens)—and measures their effectiveness systematically. This makes "text capability preservation" a design objective rather than an afterthought.
The integration of reasoning budget control from the LLM world into the VLM setting. Nemotron Nano V2 (the text-only backbone) introduced reasoning budgets—constraining the number of output tokens during chain-of-thought to balance accuracy and inference cost. The paper demonstrates that this technique transfers to VLMs and produces the counterintuitive finding that capped reasoning (e.g., 4K–8K tokens) can outperform unrestricted reasoning (up to 16,384 tokens) on several vision tasks (Figure 3). The authors hypothesize this occurs because early termination can "abort malformed reasoning traces with repetition loops on out-of-distribution tasks" and "truncate overly verbose reasoning chains for problems requiring minimal reasoning" (Section 4.3)—a phenomenon that would be invisible without studying budget control explicitly.
The tiling ablation as an honest assessment of architectural tradeoffs. Rather than simply claiming their tiling strategy is optimal, the paper runs an alternative native-resolution pipeline with convolutional token reduction (Table 7) and discovers that native resolution matches or beats tiling on several benchmarks, with the gap on OCR tasks being attributable to specific image-rescaling behavior in the tiling algorithm. This willingness to publish negative or nuanced results—"the gap on OCRBench-V2 (English) persists"—establishes credibility and provides actionable guidance for practitioners deciding between tiling and native-resolution approaches.
Quantization as a deployment-first consideration, not an afterthought. The paper releases FP8 and FP4 (NVFP4-QAD) checkpoints calibrated for vLLM inference, with Quantization-Aware Distillation used specifically because post-training quantization alone yielded accuracy drops on NVFP4. The PTQ vs. QAD comparison in Table 8 (showing NVFP4-PTQ drops DocVQA from 94.22 → 92.38 while NVFP4-QAD recovers to 93.95) demonstrates that careful quantization-aware distillation is necessary for 4-bit deployment—a practical concern that many VLM papers ignore. The motivation is explicitly "to bridge this train–serve gap" between Transformer Engine's delayed-scaling FP8 (used during training) and vLLM's static quantization (used at inference), a detail that reflects real-world deployment experience.

In summary, the paper's intellectual contribution is not a single technique but a training-stage architecture for VLM development that (1) tracks and actively recovers text reasoning capabilities, (2) incrementally extends context length with dedicated data mixtures at each stage, (3) evaluates reasoning budget control as a tunable parameter rather than a binary on/off choice, and (4) prioritizes deployment quantizability from the start. The open-source release of 8M+ training samples, the NVPDFTex toolchain, and the training code reflects an explicit philosophy that VLM development is bottlenecked by data quality and training infrastructure as much as by model architecture—a stance that positions this work as a practical contribution to the VLM ecosystem rather than a pure research demonstration.

3. Technical Approach

3.1 Reader Orientation

The system being built is a 12B-parameter vision–language model that can answer questions about images, multi-page documents, long videos, charts, and user interfaces, while also maintaining the mathematical reasoning and code generation abilities of its text-only predecessor. The core problem it solves is the tension between adding visual understanding and preserving text reasoning—a phenomenon where multimodal fine-tuning causes catastrophic forgetting of code, math, and long-context capabilities. The solution's shape is a five-stage supervised fine-tuning pipeline (Figure 2) that progressively extends the model's capabilities: first aligning vision and language representations, then training on broad multimodal data, then extending context length for video and documents, then explicitly recovering degraded code reasoning, and finally extending to ultra-long contexts. After training, the model supports two inference modes—reasoning-off (greedy decoding, up to 1,024 output tokens) and reasoning-on (temperature 0.6, top-p 0.95, up to 16,384 output tokens, with optional budget caps at 2K, 4K, 8K, or 12K tokens)—enabling users to trade computation for accuracy.

3.2 Big-Picture Architecture (Diagram in Words)

The model consists of three trainable modules connected in sequence, plus a multi-stage training controller:

Vision Encoder (RADIOv2.5) — a pre-trained vision foundation model (the c-RADIOv2-VLM-H variant) that converts images into dense feature maps. It accepts tiles of size 512 × 512 pixels (patch size 16, producing 32 × 32 = 1,024 visual tokens per tile before compression) and is kept frozen during Stage 0 training but unfrozen in all subsequent stages.
MLP Projector — a learned connector that maps vision encoder outputs into the language model's embedding space. It consists of a 2-layer MLP with a pixel shuffle operation that performs 2× spatial downsampling, reducing the 1,024 visual tokens per tile to 256. This module is the primary bridge establishing cross-modal alignment and is trained alone during Stage 0 before all components are jointly fine-tuned.
Language Model Backbone (Nemotron-Nano-12B-V2) — a hybrid Mamba-Transformer decoder-only architecture that processes interleaved visual and text token sequences. It provides 35% higher throughput on long document scenarios compared to the previous-generation Transformer-only backbone (Llama-3.1-Nemotron-Nano-VL-8B) due to Mamba layers' sub-quadratic sequence processing complexity.
Training Controller (Multi-Stage SFT Orchestrator) — a meta-component that determines, for each of five stages, which parameters are frozen or trainable, what maximum sequence length applies, which data mixture is used, and what learning rate schedule to follow. It implements progressive context extension (16K → 49K → 300K) and targeted capability recovery.

Information flows through these components as follows: an image or video frame enters → the image is resized and tiled according to a dynamic aspect-ratio-preserving algorithm (producing up to 12 tiles plus one global thumbnail) → each tile passes through the frozen-or-unfrozen vision encoder to produce a feature map → the feature map undergoes pixel shuffle 2× downsampling in the MLP projector to produce 256 visual tokens per tile → visual tokens are interleaved with text tokens (question, system prompt, instruction) into a single sequence → the combined sequence feeds into the Nemotron-Nano-12B-V2 backbone, which applies alternating Mamba state-space layers and Transformer self-attention layers → the backbone autoregressively generates output tokens. For video, the same pipeline applies per-frame (2 frames per second, maximum 128 frames), with optional Efficient Video Sampling (EVS) that prunes temporally static patches before the vision encoder to reduce token count and accelerate inference by 2× or more.

3.3 Roadmap for the Deep Dive

First, the vision preprocessing pipeline—dynamic tiling, pixel shuffle token reduction, video frame sampling, and EVS—because this determines what the model actually "sees" and how much compute each input consumes.
Second, the five-stage training recipe in chronological order (Stage 0 through Stage 4), with each stage's motivation, data mixture, frozen/unfrozen parameter choices, hyperparameters, and what capability it is designed to establish or recover. The stage-by-stage text benchmark tracking from Table 6 will be woven in to show exactly where degradation occurs and where recovery happens.
Third, the training infrastructure—sequence packing, loss square-averaging, context parallelism, FP8 precision with BF16 fallback for sensitive layers, and the hardware configuration—because these design choices directly enable the context length extensions and training throughput.
Fourth, the inference-time mechanisms—reasoning budget control, Efficient Video Sampling integration, and the tiling vs. native-resolution ablation—because these represent the deployable model's controllable knobs and the architectural tradeoffs the authors investigated.

3.4 Detailed, Sentence-Based Technical Breakdown

This is primarily a systems and training methodology paper whose core idea is that a carefully orchestrated multi-stage training pipeline—with explicit stages dedicated to recovering text capabilities degraded by multimodal training—can produce a VLM that excels at document understanding, video comprehension, and reasoning tasks while maintaining competitive text-only performance. The paper does not introduce novel loss functions or new architectures; rather, it combines established components (RADIOv2.5 encoder, Nemotron Nano V2 backbone, Eagle-style multi-stage SFT) and contributes a systematic study of the training dynamics that cause text reasoning degradation, plus practical recipes for recovery.

Vision Preprocessing Pipeline: From Pixels to Visual Tokens

The model's vision preprocessing pipeline determines how raw images and video frames are converted into sequences of visual embeddings that the language model can process alongside text. This pipeline involves four sequential operations: aspect-ratio-preserving resizing, dynamic tiling, vision encoding, and token compression.

Aspect-ratio-preserving resizing. Given an input image of arbitrary dimensions, the system first resizes it so that both width and height become multiples of s = 512 pixels. This follows the InternVL (Chen et al., 2024d) matching strategy: the image is scaled to fit within a target resolution while ensuring that the resulting dimensions are exact multiples of the tile size. The specific algorithm selects a target width w' and height h' such that w' mod 512 = 0, h' mod 512 = 0, and the aspect ratio of the original image is preserved as closely as possible while keeping the total number of tiles within the allowed maximum. A crucial detail: this resizing step can introduce large scaling factors for small images—if a small 200×300 image needs to fill a 512×512 tile, it gets significantly upscaled, which the paper later identifies as a contributing factor to tiling's advantage on OCR benchmarks compared to native-resolution encoding (Section 4.5, Table 7).

Dynamic tiling. After resizing, the image is divided into non-overlapping tiles of size 512 × 512 pixels. The number of tiles is determined by the resized dimensions: if the image is w' × h' pixels after resizing, it produces (w'/512) × (h'/512) tiles. During training, the maximum number of tiles is capped at 12. In addition to these tiles, the system always generates a thumbnail tile: a single 512 × 512 tile containing a downsampled version of the entire image. This thumbnail provides global context—the model can see the overall layout, relative positions of elements, and the gestalt of the image—while the individual tiles provide high-resolution detail for text reading, fine-grained object recognition, and local reasoning. The total visual token budget for an image is therefore (num_tiles + 1) × tokens_per_tile, where the +1 accounts for the thumbnail.

For video inputs, each extracted frame is limited to a single tile (no multi-tile per frame and no separate thumbnail). This is a deliberate efficiency choice: at 2 frames per second with up to 128 frames, the token count would explode if each frame were tiled, and video frames typically don't require the extreme resolution needed for document OCR. The video preprocessing therefore strikes a different resolution-vs-quantity tradeoff: more frames at moderate resolution rather than fewer frames at high resolution.

Vision encoding. Each 512 × 512 tile is processed by the RADIOv2.5 vision encoder, specifically the c-RADIOv2-VLM-H variant. With a patch size of 16, each tile is decomposed into (512/16) × (512/16) = 32 × 32 = 1,024 patches. The vision encoder maps each patch to a visual feature vector, producing a 32 × 32 feature map of 1,024 tokens per tile. The RADIOv2.5 architecture is an agglomerative vision foundation model (Heinrich et al., 2025)—a class of models designed to serve as general-purpose visual backbones across diverse downstream tasks. The c-RADIOv2-VLM-H variant is specifically the version trained to work well as a frozen feature extractor for vision–language models, meaning its internal representations are already aligned toward semantically meaningful features that language models can interpret.

Token compression via pixel shuffle. The raw 1,024 tokens per tile would impose substantial compute and memory costs when processing documents with 12+ tiles. To reduce this, the MLP projector applies a pixel shuffle operation with 2× downsampling. Pixel shuffle is a spatial rearrangement operation originally introduced for super-resolution (Shi et al., 2016) that reshapes a feature map to trade spatial resolution for channel depth. Here, it is used in reverse: features from 2 × 2 spatial blocks are reorganized to reduce the spatial dimensions by a factor of 2 while increasing the channel dimension by a factor of 4. The result is that the 32 × 32 feature map becomes a 16 × 16 feature map, reducing the token count from 1,024 to 16 × 16 = 256 visual tokens per tile. After the spatial reduction, a 2-layer MLP projects these 256 tokens into the language model's embedding dimension, making them directly concatenable with text token embeddings.

This token compression is critical for scalability. Without it, a 12-tile document image would produce 12 × 1,024 + 1,024 = 13,312 visual tokens; with compression, it produces 12 × 256 + 256 = 3,328 visual tokens—a 4× reduction. Since the LLM backbone's self-attention (in its Transformer layers) scales quadratically with sequence length, this 4× token reduction translates to roughly a 16× reduction in attention computation for the visual prefix.

Efficient Video Sampling (EVS). For video inputs specifically, an additional optimization can be applied before the vision encoder. EVS (Bagrov et al., 2025) examines consecutive frames and identifies temporally static patches—spatial regions (corresponding to individual patches in the vision encoder) whose content remains nearly unchanged between frames. These static patches are pruned: the current frame reuses the visual token from the previous frame for that spatial position rather than re-encoding it. Importantly, EVS preserves positional identity (the token retains its spatial and temporal position information) and semantic consistency (the token still represents the same object or background element), so the downstream LLM sees the same sequence structure—just with computation saved by not re-encoding redundant information.

The pruning is controlled by an EVS ratio, which represents the fraction of patches that get pruned. An EVS ratio of 50% means half of all patches across frames are identified as temporally static and skipped during encoding. The ratio is not a hard threshold but emerges from a similarity computation between corresponding patches in consecutive frames: if the patch representations are sufficiently close (under a distance metric not specified in the paper but defined in the original EVS work), the patch is marked static. The paper evaluates EVS ratios from 50% to 90% and shows (Figure 4) that even at 80%, Video-MME accuracy drops only from 66.0 to 65.6 (a 0.4-point decline) while time-to-first-token decreases from 4,131 ms to 1,990 ms and throughput doubles from 34 tok/s to 98 tok/s in BF16. This is a compelling accuracy-efficiency tradeoff: the model can process videos substantially faster while maintaining nearly identical understanding quality.

Stage 0: Vision-Language Alignment via MLP Warm-Up

This stage establishes the initial cross-modal connection between the vision encoder's output space and the language model's embedding space. The core idea is that randomly initializing the MLP projector and training it jointly with all other parameters would cause destructive gradient interference—the untrained projector would produce noisy, uninformative visual embeddings that corrupt the language model's pre-trained representations during early training.

Frozen/unfrozen strategy. During Stage 0, the vision encoder and language model weights are completely frozen (no gradient updates). Only the MLP projector—a 2-layer MLP with pixel shuffle—is trainable. This means the vision encoder continues to produce the same feature representations it was pre-trained to produce, and the language model continues to process text using its existing representations, while the projector learns to translate between these two fixed spaces. The projector's objective is to map visual features into token embeddings such that, when interleaved with text, the language model can attend to them meaningfully and generate appropriate responses.

Training data. The Stage 0 dataset consists of approximately 2.2 million samples (up to 36 billion tokens) drawn from a "diverse multimodal subset of the Stage 1 SFT dataset" (Section 3.1). The paper does not enumerate the exact data sources used here, but indicates the subset spans "multiple tasks, including captioning, visual question answering, visual grounding, OCR, and document extraction." The diversity is intentional: the projector needs to learn a general mapping that works across task types, not one specialized to captioning or QA. Including OCR and document extraction data from the start is notable because these tasks require preserving fine-grained visual detail (text characters, layout structure), which places different demands on the projector compared to tasks like object recognition.

Training hyperparameters. The paper specifies an initial learning rate of 2 × 10^-4 for Stage 0, which is an order of magnitude higher than the subsequent stages (which use 2 × 10^-5). This higher learning rate is appropriate because the projector is randomly initialized and needs to move quickly to align the two modalities, whereas the pre-trained components (when unfrozen in later stages) need gentle updates to avoid catastrophic forgetting. A global batch size of 1,024 is used across 32 GPU nodes, with a linear warmup fraction of 0.1 and a weight decay of 0.01. Training runs for 2,158 iterations, taking 6 hours on 32 NVIDIA H100 GPU nodes (Table 2).

Stage 1: Broad Multimodal Supervised Fine-Tuning at 16K Context

This is the largest training stage, where the model acquires the bulk of its visual understanding capabilities. The shift from Stage 0 to Stage 1 is marked by two critical changes: (1) all model components are unfrozen, meaning the vision encoder, MLP projector, and language model backbone are all updated jointly, and (2) the context length is set to 16,384 tokens, establishing the base context window.

Why unfreeze everything? The frozen-projector approach from Stage 0 provides a good initialization, but the vision encoder was pre-trained on general vision tasks (not specifically for language-guided tasks like reading text in charts or grounding referring expressions). Jointly fine-tuning the vision encoder allows it to adapt its representations to the specific demands of VQA, OCR, and document understanding—for example, learning to produce features that make small text characters more distinguishable, or developing better representations for chart elements like bar heights and axis labels. Similarly, the language model needs to adapt its internal representations to effectively attend to and reason over the interleaved visual tokens, which requires updating its attention patterns and feedforward networks.

Training data composition. This is the most data-intensive stage, trained on approximately 32.5 million samples totaling about 112.5 billion tokens. The data falls into two broad categories:

Category 1: Text reasoning data (6.5M samples, ~40B tokens). This is a subset of the Nemotron Nano V2 Stage 1 SFT data—the same text data that was used to train the LLM backbone's reasoning capabilities. It spans "diverse domains and tasks such as mathematics, science, code, multilingual understanding, multi-turn dialogue, tool-use, and safety" (Section 3.2). Crucially, the authors include this data specifically "to preserve the text comprehension capabilities" of the backbone—they anticipate that multimodal training will interfere with text reasoning and try to mitigate this by mixing in the original text data. However, as Table 6 reveals, this mitigation is only partially successful: LiveCodeBench still drops from 70.0 to 50.87, and RULER collapses from 77.9 to 8.8, indicating that simply mixing text data with multimodal data does not prevent catastrophic interference.

Category 2: Multimodal data (26M samples, ~72B tokens). This is drawn from nine task categories with dozens of source datasets (Section 3.2):

Image Captioning (OpenImages, TextCaps, TextVQA, PixMo-cap): teaches the model to describe image content, including reading and incorporating text visible in images.
Video Captioning (Localized Narratives, YouCook2, VaTeX): extends captioning to temporal sequences.
General Visual QA (TextVQA, VQAv2, OK-VQA, GQA, CLEVR, CLEVR-Math, TallyQA, Dolly-15K, ScreenQA, VizWiz, MapQA, ScienceQA, PMC-VQA, MetaMathQA, UniGeo, CMM-Math, Geo-170K, VisualWebInstruct, LRV-Instruction, OCR-VQA, EST-VQA, ST-VQA, PixMo-AskModelAnything, ALLaVA-4v, SLAKE, VQA-RAD, DreamSim, Spot-the-Diff, NLVR2): the broadest category, covering visual question answering across domains including medical imaging, geometry, science diagrams, map reading, accessibility (VizWiz), GUI screens, and counterfactual/reasoning-heavy questions.
Video QA (CLEVRER, Perception Test, ALFRED, NextQA, VCG+112K): tests temporal reasoning and action understanding in videos.
Visual Grounding (RefCOCO): teaches the model to map referring expressions (e.g., "the red cup on the left") to specific image regions.
OCR, Table & Document Extraction (SynthDog-en, SynthTabNet, DocLayNet, WebSight, TabRecSet, FinTabNet, PubTables-1M, TextOCR, HierText, FUNSD, CASIA-HWDB2, RCTW-17, ReCTS-19, human-annotated CommonCrawl samples, synthetic tables, arXiv paper annotations from NVPDFTex, multilingual Wikimedia dumps): the largest OCR/document cluster, covering synthetic and real-world document parsing, table structure extraction, handwriting recognition (Chinese and English), form understanding, and multilingual text recognition. The NVPDFTex pipeline deserves special attention: it is a custom LaTeX compiler toolchain that generates annotated OCR ground truth by compiling LaTeX source documents and extracting text bounding boxes, font metadata, and reading order information—providing pixel-perfect alignment between rendered output and ground-truth text that would be impossible to obtain from scanned documents.
Document, Chart, Table and GUI QA (ChartQA, InfoVQA, AI2D, DocVQA, FigureQA, ECD-10K, ArXivQA, PlotQA, PixMo-Docs, TabMWP, SlideVQA, Docmatix, DocReason25K, UniChart, SimChart9K, MMTab, VisText, ScreenQA, WaveUI-25K, plus synthetic QA on FinTabNet/HierText/CommonCrawl transcriptions): focuses on reasoning ABOUT extracted content—answering questions that require interpreting chart data, navigating document structure, or understanding GUI layouts.
Visual Grounding (Visual7W, OpenImages): additional grounding data.
Function Calling (Glaive function calling, xLAM-60K): teaches the model to interpret visual inputs that require tool-use actions.

The paper augments many of these datasets with "both human-annotated reasoning traces and model-generated traces produced by Qwen2.5-VL-32B-Instruct, GLM-4.1V, and GLM-4.5V" (Section 3.2). This is a knowledge distillation strategy: larger, more capable VLMs generate step-by-step reasoning chains that demonstrate how to solve complex visual questions, and the 12B model learns to imitate this reasoning process. The use of multiple teacher models (not just one) likely improves robustness by exposing the student to diverse reasoning styles. For datasets lacking explicit QA labels, the authors "generate synthetic question–answer pairs from existing OCR extractions or captions using LLMs from the Qwen2.5 and Qwen3 families"—effectively converting unstructured text (extracted document content, image captions) into structured training examples without human annotation.

Training hyperparameters. Stage 1 uses a lower learning rate of 2 × 10^-5 (10× lower than Stage 0) with a global batch size of 128 (reduced from 1,024), trained on 64 GPU nodes for 30 hours (Table 2). The weight decay increases from 0.01 to 0.05. The maximum sequence length is 16,384 tokens (16K). The reduced batch size at this stage is notable—the authors do not explain this choice explicitly, but it is likely driven by memory constraints: with all model components unfrozen and a 16K context length, each sample requires significantly more GPU memory for activations and gradients than Stage 0 (where the vision encoder and LLM were frozen, vastly reducing backpropagation memory). The 64-node configuration (vs. 32 in Stage 0) partially compensates for the smaller per-GPU batch size.

The text capability degradation problem. Table 6 reveals the central tension of this stage. After Stage 1 training, the model shows substantial degradation on several text-only benchmarks compared to the frozen-backbone Stage 0 baseline (which represents the original LLM's capabilities since the LLM was frozen during Stage 0):

LiveCodeBench drops from 70.0 to 50.9 (a 27% relative decline): the model's code generation and reasoning ability is severely damaged.
RULER drops from 77.9 to 8.8 (an 89% relative decline): the model's long-context processing capability is essentially destroyed.
AIME-25 drops from 75.9 to 68.0 (10% relative decline): competition math reasoning degrades but less catastrophically than code.
MATH-500 drops from 97.7 to 96.8 (0.9% relative decline): standard math reasoning holds up remarkably well, suggesting math circuits in the LLM are less vulnerable to multimodal interference than code circuits.
GPQA drops from 65.0 to 60.9 (6% relative decline): graduate-level science reasoning shows moderate degradation.

The differential impact—code and long-context collapsing while math remains stable—provides insight into how multimodal fine-tuning interferes with the LLM backbone. Code reasoning likely depends on syntactic and structural patterns that get overwritten when the model's attention layers adapt to processing dense visual token sequences. Long-context capability (RULER) depends on the model's ability to maintain position representations and attend correctly across thousands of tokens—a capability that may be disrupted when the early layers of the LLM are repurposed to handle the sudden influx of visual tokens at the beginning of every sequence. Math reasoning, by contrast, may rely on more abstract, semantically grounded operations that are less coupled to specific token-level patterns and thus less affected by the distribution shift in input tokens.

The authors note they "explored several mitigation strategies that were unsuccessful, including augmenting the SFT stage 1 dataset with additional code reasoning examples and disabling loss scaling" (Section 3.4). The failure of simply adding more code data suggests the problem is not a data-imbalance issue that can be fixed by reweighting—it is a more fundamental interference phenomenon where gradient updates from multimodal training actively unlearn specific text capabilities. Disabling loss scaling (which adjusts per-token loss weights to balance contributions from sequences of different lengths) also didn't help, indicating the issue is not about how different samples are weighted but about the content of the gradient updates themselves.

Stage 2: Context Extension to 49K for Video and Multi-Image Understanding

After establishing multimodal capabilities at 16K context in Stage 1, Stage 2 extends the model's context window to 49,152 tokens. The motivation is direct: video inputs with 128 frames at 256 visual tokens per frame produce 32,768 visual tokens alone, plus text tokens for the question and answer, easily exceeding 16K. Multi-page document QA similarly requires processing many pages' worth of visual and extracted text tokens. Without context extension, the model would be forced to truncate inputs, losing information from earlier frames or pages.

Training data and reuse strategy. Stage 2 is trained on approximately 11 million samples (around 55 billion tokens). A critical design choice is the data reuse ratio: 25% of the data comes from Stage 1 (reused), while 75% is new video and multi-image data. The authors "experimented with varying proportions of Stage 1 data and found that a 25% reuse ratio offers a good balance between training efficiency and maintaining accuracy across text, vision, multi-frame and video benchmarks" (Section 3.3). Too little reuse would cause the model to forget Stage 1 capabilities (the distribution shift to predominantly video data could overwrite image understanding); too much reuse would dilute the new context-extension signal and waste training compute on examples the model already handles well.

The 25% reuse subset includes text reasoning data (to continue reinforcing those capabilities), single-image tasks (to maintain image QA/captioning/document understanding), and general multimodal data. The remaining 75% consists of approximately 1.4 million video and multi-image samples (about 17 billion tokens) across eight task areas:

Video Classification (Kinetics): classifying actions in short video clips.
Dense Video Captioning (YouCook2, HiREST, ActivityNet): generating detailed descriptions of events at multiple timestamps.
Video Captioning (EgoExoLearn): describing procedural activities from egocentric and exocentric viewpoints.
Temporal Action Localization (Breakfast Actions, Perception Test, HiREST, HACS Segment, FineAction, Ego4D-MQ, ActivityNet): identifying when specific actions start and end within a video.
Video Temporal Grounding (YouCook2, QuerYD, MedVidQA, Ego4D-NLQ, DiDeMo): given a natural language query, finding the corresponding video segment.
General Video QA (LLaVA-Video-178K, Ego4D, TVQA, Perception Test, NextQA, EgoExoLearn, CLEVRER, plus relabeled datasets): answering questions about video content, with some datasets relabeled by Qwen2.5-VL-72B-Instruct into multiple-choice and open-ended formats.
Multi-page QA (synthetic, from CommonCrawl PDFs): answering questions that require information spread across multiple document pages.
Multi-image Captions (Mementos): describing sequences of images.

A notable data engineering detail: for all non-QA datasets (classification, temporal action localization, temporal grounding), the authors convert the labels into QA format using template questions. For captioning datasets, they use Qwen2.5-family LLMs to synthesize questions given the captions. This ensures all training examples follow a consistent input-output format regardless of the original dataset structure, which simplifies training and likely improves the model's ability to generalize across task types.

Context parallelism infrastructure. Extending context to 49K tokens creates out-of-memory issues during training because the attention mechanism's memory footprint scales quadratically with sequence length. To address this, the authors employ 2-way context parallelism in the LLM backbone (Section 3.6). Context parallelism partitions the input sequence along the sequence dimension across GPUs: each GPU processes a contiguous chunk of the sequence and exchanges key-value pairs at attention boundaries. At 2-way parallelism, the sequence is split into two halves, halving the maximum sequence length any single GPU needs to handle.

Context parallelism has an important interaction with the vision pipeline: for N-way context parallelism, N replicas of the vision encoder and vision projection modules are instantiated. To efficiently utilize these replicas, the inputs to the vision encoder are split into N shards along the batch dimension (following Chen et al., 2024c). Each shard is processed independently by its vision encoder replica, and the N vision projection outputs are gathered before being passed to the LLM. This design avoids redundant vision encoding: rather than each context-parallel replica encoding all images (which would N× the vision encoding cost), each replica encodes only a subset of the batch's images, and the results are shared.

Impact on benchmarks. Table 4 shows the effect of Stage 2: LongVideoBench improves from 59.4 (after Stage 1) to 63.6, MMLongBench-Doc improves from 29.2 to 32.0, and Video-MME jumps dramatically from 57.6 to 65.8. These gains validate the context extension: the model can now effectively process longer video sequences and multi-page documents that were previously truncated. However, Table 6 reveals that text benchmarks show only modest recovery: LiveCodeBench edges up from 50.87 to 55.00, and RULER from 8.80 to 17.39. The video-focused data in Stage 2 does help slightly with long-context text understanding (RULER improves), but the code reasoning deficit remains largely unaddressed—a finding that directly motivates Stage 3.

Stage 3: Code Reasoning Recovery at 49K Context

This stage is a targeted intervention to recover the code reasoning capability lost during multimodal training. After observing that Stage 2's video data did not restore the LiveCodeBench score (55.00 vs. the original 70.0), the authors introduce a dedicated code-only training stage.

Training data and design rationale. Stage 3 trains on approximately 1 million samples (about 15 billion tokens) of "only code reasoning data" (Section 3.4) at 49,152 maximum sequence length. The paper does not enumerate specific code datasets, but since the data is drawn from Nemotron Nano V2's training pipeline (NVIDIA et al., 2025), it likely includes competitive programming problems, code generation tasks, code completion, and debugging exercises spanning multiple programming languages. The key design choice is exclusivity: no vision data whatsoever is included in this stage. This is counterintuitive from a catastrophic-forgetting perspective—wouldn't training on code-only data cause the model to forget the visual capabilities it just acquired? The authors explicitly check this: "As shown in Table 4, the vision benchmarks remain stable between SFT stage 2 and stage 3" (Section 4.2). The vision benchmarks are essentially flat: AI2D goes from 87.1 → 87.3, ChartQA from 90.0 → 90.2, DocVQA from 94.3 → 94.2, OCRBench from 85.3 → 85.4. This stability is a significant finding: it suggests that once visual capabilities are established through large-scale multimodal training (Stages 1–2), they are robust to subsequent text-only fine-tuning, at least for the 1M-sample / 15B-token scale used here.

Why does code recovery work when augmenting Stage 1 with extra code data failed? The paper does not explicitly address this, but a plausible mechanism is interference avoidance through sequential rather than simultaneous training. In Stage 1, the model received interleaved gradients from vision tasks (updating attention patterns to handle visual tokens, modifying feedforward layers to process visual features) and text tasks (maintaining code/ math reasoning) simultaneously. These conflicting gradient signals likely interfered destructively—an update that improves visual understanding might reduce code performance and vice versa. In Stage 3, there is no such conflict: the vision capabilities are already well-established (the model doesn't need to learn anything new about vision), and the code-focused updates can strengthen the specific circuits that support code reasoning without simultaneously fighting vision-related gradients. This is effectively a form of elastic weight consolidation (Kirkpatrick et al., 2017) implemented through training order rather than explicit regularization: learn the interfering tasks first, then fine-tune on the task-of-interest while the previously learned tasks remain stable.

Results. Table 6 shows the impact: LiveCodeBench jumps from 55.00 (after Stage 2) to 69.44 (after Stage 3)—a near-complete recovery of the original 70.0, with only a 0.56-point residual gap. Other text benchmarks show mixed effects: MATH-500 recovers from 97.3 → 97.6, AIME-25 stays flat at 72.7, GPQA dips slightly from 63.0 → 60.6, and IFEval scores remain roughly stable. The code-specific nature of the data means it primarily benefits coding benchmarks while having limited impact on or slightly degrading other text capabilities. RULER improves from 17.39 → 21.46, suggesting that the code reasoning data (which often involves long functions and multi-file contexts) has some beneficial spillover for general long-context understanding, but the improvement is modest—the dedicated long-context Stage 4 is still needed.

Training configuration. Stage 3 uses 64 GPU nodes, taking 3.5 hours (Table 2). The learning rate follows the same cosine schedule with 2 × 10^-5 initial learning rate and 0.05 weight decay. Context parallelism remains at 2-way, since the maximum sequence length is still 49K.

Stage 4: Ultra-Long Context Extension to 300K

The final training stage pushes the context window to 311,296 tokens (approximately 300K), enabling the model to process extremely long documents, extended video sequences, and deep reasoning chains. This stage addresses the RULER deficit that persisted through Stages 2 and 3: despite some improvement, RULER was still at 21.46 after Stage 3, far below the original 77.91.

Training data. Stage 4 incorporates "long-context data from the Stage 3 SFT stage of Nemotron Nano 2" (Section 3.5), consisting of about 74,000 samples or 12 billion tokens. Critically, these samples are 160,000 tokens long on average—far longer than the 49K context used in Stages 2–3. Training with a maximum sequence length of 311,296 accommodates the longest samples in this distribution. The paper does not detail the content of these long-context samples, but given they are drawn from the Nemotron Nano 2 text-only LLM pipeline, they likely include very long documents, multi-turn dialogues with extensive history, code repositories, and information retrieval tasks requiring synthesis across thousands of tokens.

Unlike Stage 3 (which was code-only), Stage 4 appears to be text-only as well—the data is specifically described as "long-context data" from the LLM training stage, suggesting no additional vision data is included. The vision benchmarks in Table 4 show slight fluctuations but no clear trend: AI2D stays at 87.2, ChartQA at 89.8, DocVQA at 94.4, OCRBench at 85.6—all within normal run-to-run variation.

Results and the RULER recovery. Table 6 shows the dramatic effect: RULER jumps from 21.46 (after Stage 3) to 72.12 (after Stage 4)—a recovery to 93% of the original 77.91. This is a striking result. The mechanism is likely similar to the code recovery in Stage 3: once the interference from multimodal training is isolated (the model no longer receives conflicting vision + text gradients), dedicated long-context training can restore the positional and attention mechanisms that enable effective processing of extended sequences. The residual gap (72.12 vs. 77.91) may represent an irreducible loss from the original multimodal interference, or it might be recoverable with more long-context training data.

Other text benchmarks remain stable through Stage 4: MATH-500 drops slightly from 97.6 → 96.9, AIME-25 from 72.7 → 71.3, GPQA from 60.6 → 64.1, LiveCodeBench from 69.44 → 69.36. The stability of LiveCodeBench is particularly noteworthy—the code reasoning recovered in Stage 3 survives the long-context training of Stage 4 without degradation, suggesting that the recovered capabilities are robust.

Training infrastructure. Stage 4 uses 8-way context parallelism (up from 2-way in Stages 2–3), reflecting the extreme memory demands of 300K-context training. At 8-way parallelism, the sequence is partitioned across 8 GPUs, with each GPU responsible for approximately 39K tokens—comparable to the 49K/2 = 24.5K per GPU in earlier stages. Training runs for 5.5 hours on 64 GPU nodes (Table 2). The learning rate and other hyperparameters follow the same 2 × 10^-5 schedule.

Training Infrastructure and Optimization Techniques

The training pipeline incorporates several infrastructure-level optimizations that are critical for making the multi-stage recipe computationally feasible and numerically stable.

FP8 training with selective BF16 retention. All training stages use FP8 precision to accelerate computation and reduce memory usage. However, certain layers are kept in BF16 due to numerical sensitivity: specifically, "the first and last layers of the LLM and the transformer blocks of the vision encoder" (Section 3.6). The first layer of the LLM (the embedding projection) processes raw input tokens and is sensitive to the precision of the initial embedding lookup; the last layer (the output projection / language modeling head) computes the final logits where small errors directly affect the loss; and the vision encoder's transformer blocks contain the self-attention operations that process visual patches—precision loss here could corrupt fine-grained visual features needed for OCR and detail recognition. The authors report they "did not observe any training instabilities with this setup, and both the training loss curve and benchmark scores closely match those of a full-BF16 model" (Section 3.6)—a crucial validation that mixed-precision training does not silently degrade model quality. They also experimented with keeping the vision encoder or vision projection in BF16 and found "no significant difference," suggesting the current configuration is not at the edge of precision-induced instability.

Sequence packing with balance-aware strategy. Image, video, and text samples vary dramatically in sequence length: a text-only math problem might be a few hundred tokens, while a 128-frame video with questions could be tens of thousands. Batching these diverse samples naively would require padding shorter sequences to match the longest sequence in the batch, wasting enormous amounts of computation on padding tokens. To address this, the training pipeline employs online sequence packing: during training, a buffer maintains several thousand samples, and the dataloader dynamically combines samples to fill each batch's total token budget as efficiently as possible. The packing is balance-aware (described in Li et al., 2025b), meaning it accounts for data source diversity: the packer ensures that each batch contains a balanced mix of task types and domains rather than, say, packing 50 OCR samples together. This prevents gradient updates from being dominated by a single task type in any given batch, which would cause training instability and poor generalization.

Loss square-averaging. With sequence packing, different samples within a batch have different lengths, and simply averaging per-token loss across the batch would overweight longer sequences (which contribute more tokens). Conversely, computing per-sample loss and averaging would underweight the information in long sequences (each long sequence gets one vote regardless of how much content it contains). Loss square-averaging (referenced as "similar to InternVL," Chen et al., 2025b) provides a middle ground: it computes the total loss as the square root of the sum of squared per-sample losses, which gives more weight to sequences with higher loss (typically longer, more complex samples) without letting any single sequence dominate. The exact formula is not provided in the paper, but the conceptual goal is to mitigate bias toward shorter or longer sequences during training.

AdamW optimizer with cosine annealing. All stages use the AdamW optimizer with β1 = 0.9 and β2 = 0.999. The learning rate follows a cosine annealing schedule with a linear warmup (warmup fraction = 0.1 for all stages). The initial learning rate and weight decay vary by stage: Stage 0 uses lr = 2 × 10^-4, wd = 0.01; Stages 1–4 use lr = 2 × 10^-5, wd = 0.05. The higher learning rate and lower weight decay in Stage 0 reflect the fact that only a randomly initialized projector is being trained; the lower learning rate and higher weight decay in later stages represent conservative fine-tuning of pre-trained components to prevent catastrophic forgetting.

Hardware and training times. The full training pipeline uses NVIDIA H100 GPUs, with the number of GPU nodes varying by stage: 32 nodes for Stage 0, 64 nodes for Stages 1–4. Total training times are 6 hours (Stage 0), 30 hours (Stage 1), 15 hours (Stage 2), 3.5 hours (Stage 3), and 5.5 hours (Stage 4)—a total of approximately 60 hours of training. The two largest stages (1 and 2) account for 45 of the 60 hours, reflecting their role as the primary capability-building stages, while Stages 3 and 4 are lightweight recovery stages that fine-tune on small datasets.

Video frame sampling. The default video processing extracts 2 frames per second with a maximum of 128 frames per video. For videos shorter than 64 seconds, all frames at 2 fps are included (e.g., a 30-second video produces 60 frames). For videos longer than 64 seconds, 128 frames are uniformly sampled from the entire duration (e.g., a 5-minute video still produces exactly 128 frames, spaced roughly 2.3 seconds apart). This cap is crucial for controlling the visual token count: 128 frames × 256 tokens per frame = 32,768 visual tokens, which fits within the extended context windows (49K for Stages 2–3, 300K for Stage 4) while leaving room for text tokens.

Inference-Time Mechanisms: Reasoning Budget Control

Nemotron Nano V2 VL inherits the reasoning budget control mechanism from its text-only sibling, Nemotron Nano V2 (NVIDIA et al., 2025). The core idea is that during reasoning-on mode, the model generates chain-of-thought reasoning before producing a final answer, but the length of that reasoning can be constrained by a token budget. This creates a tunable accuracy-efficiency tradeoff: longer reasoning chains can solve more complex problems but cost more inference compute; shorter chains are cheaper but may be insufficient for multi-step reasoning.

How budget control works operationally. When reasoning-on mode is activated (temperature 0.6, top-p 0.95, maximum output length 16,384 tokens), a budget parameter B ∈ {2K, 4K, 8K, 12K} can be specified. The model generates reasoning tokens autoregressively until either (a) it produces an end-of-reasoning token signaling it's ready to answer, (b) it reaches the budget limit B plus a 500-token grace period, or (c) it reaches the absolute maximum of 16,384 tokens. The 500-token grace period is a safety margin: if the model is in the middle of a reasoning step when the budget expires, it gets a small additional allowance to finish the thought rather than being cut off mid-sentence. At B = 0, the model operates in reasoning-off mode (greedy decoding, maximum 1,024 output tokens).

The counterintuitive finding: capped reasoning can outperform unrestricted reasoning. Figure 3 presents the paper's most surprising empirical result: for many vision tasks, a budget-constrained reasoning mode achieves higher accuracy than unrestricted reasoning (up to 16,384 tokens). For example, on CV-Bench (spatial reasoning), budget 8K achieves 81.0 vs. 78.3 for unrestricted; on OCRBench, budget 4K achieves 85.6 vs. 83.5 for unrestricted; on TextVQA, budget 2K achieves 85.4 vs. 76.1 for unrestricted. The unrestricted case is not simply matching the best budget—it is often significantly worse.

Why this happens. The authors propose two mechanisms (Section 4.3):

Early termination of malformed reasoning traces. In reasoning-on mode, the model may occasionally enter repetition loops or degenerate reasoning patterns (e.g., cycling through the same analytical steps, generating non-sequiturs, or producing "reasoning" that doesn't converge toward an answer). With unrestricted generation, these loops can consume thousands of tokens before the model either escapes or hits the output limit. A budget cap truncates these malformed traces early, preventing the model from wasting computation on reasoning it will ultimately fail to convert into a correct answer—and, in the process, preventing the model from confusing itself with its own degenerate output.
Truncation of overly verbose reasoning. For problems that require minimal reasoning (e.g., straightforward factual visual questions, simple OCR extraction), the model in unrestricted mode may still generate lengthy reasoning chains out of a learned behavioral bias (the training data encouraged thorough reasoning). This verbosity can introduce errors: the more tokens generated, the more opportunities for a hallucinated fact, a logical slip, or a misinterpretation to derail the final answer. A budget cap forces conciseness, reducing the surface area for error introduction.

This finding has practical implications: deploying the model with reasoning-on does not automatically improve accuracy. Users should experiment with budget values for their specific task distribution, as the optimal budget depends on the complexity of questions in that domain. The paper's Figure 3 shows that different task categories have different optimal budgets: General VQA tasks peak at 2K–4K, STEM reasoning at 12K–unrestricted, document/OCR understanding at 4K–8K, and spatial/video understanding at 8K–12K. This heterogeneity supports the idea that reasoning budget should be treated as a task-specific hyperparameter rather than a global setting.

Image Processing Ablation: Tiling vs. Native Resolution

The paper includes a rare self-critical experiment: comparing the default tiling pipeline against an alternative approach where images are passed at native resolution to the vision encoder followed by convolutional token reduction (Section 4.5, Table 7). This ablation serves two purposes: it validates that the tiling design is genuinely beneficial (rather than an arbitrary choice), and it identifies specific failure modes that inform future work.

The alternative: native resolution with convolutional token compression. Instead of splitting images into tiles, this approach feeds the entire resized image at native resolution through the vision encoder to produce a feature map proportional to the image dimensions. After encoding, a convolutional layer with stride 4 performs 4× sequence compression (reducing spatial dimensions by a factor of 2 in each direction, hence 4× token reduction), mapping the feature map to a smaller grid of visual tokens. This approach has the advantage of simplicity: no tiling logic, no thumbnail, no need to stitch together per-tile representations.

Experimental setup. For each variant (tiling vs. native resolution vs. native resolution with tiling-size matching), the authors train the model through Stages 0 and 1 of the full recipe, excluding text reasoning datasets from Stage 1. They evaluate on 10 multimodal benchmarks at the last 10 saved checkpoints and select the checkpoint with the highest average benchmark score for each strategy—a thorough evaluation protocol that accounts for training variance.

Results and analysis. The three columns of Table 7 show:

Tiling achieves the highest average score (75.0) across the 10 benchmarks.
Native resolution achieves 74.8 average—very close, indicating that for many tasks, the tiling advantage is marginal.
Native resolution with tiling-size matching (where images are resized to exactly the dimensions the tiling algorithm would have selected, but then processed as a single image without actual tiling) achieves 75.1—slightly exceeding tiling at 75.0.

The per-benchmark breakdown reveals a more nuanced story. Native resolution loses ground on OCRBench (82.8 vs. 84.5 for tiling) and OCRBench-V2 English (57.6 vs. 61.4). The authors analyze this gap: "the tiling algorithm occasionally applies large rescaling factors to smaller images to preserve aspect ratio." Small images (e.g., a narrow receipt or a short text snippet) get upscaled more aggressively in the tiling pipeline because they need to fill 512 × 512 tiles while maintaining the aspect ratio—this upscaling effectively increases the resolution at which text is encoded, improving OCR accuracy. Native resolution, by contrast, may encode small images at lower effective resolution, making fine text harder to read.

The tiling-size matching experiment confirms this hypothesis: by resizing images to the same dimensions the tiling algorithm would select but encoding them as a single image, OCRBench recovers to 85.3 (matching tiling's 84.5). However, OCRBench-V2 English still lags at 57.6 (vs. 61.4 for tiling)—suggesting that some additional benefit of tiling (beyond the rescaling effect) remains for more challenging OCR tasks. The authors "plan to further investigate strategies to address this gap in future work," acknowledging that tiling provides genuine advantages for high-resolution text reading that native-resolution approaches have not yet fully replicated.

This ablation is both honest and practically useful: it tells practitioners that if their task distribution doesn't involve fine-grained text reading (e.g., general VQA, spatial reasoning), native-resolution encoding with convolutional compression may be simpler and nearly as accurate; but for OCR-heavy applications, tiling with its rescaling behavior provides meaningful gains that persist even when controlling for image size.

Quantization for Deployment: PTQ vs. QAD

The paper addresses a practical deployment challenge: the FP8 training regime uses Transformer Engine's delayed-scaling FP8, where dynamic scaling factors are computed from a running history of activation maxima during training. However, production inference stacks like vLLM and TensorRT-LLM assume static quantization with scaling factors fixed during a one-time calibration. The mismatch between dynamic training-time quantization and static inference-time quantization can cause accuracy drops if not explicitly bridged.

Post-Training Quantization (PTQ). The simpler approach: calibrate on 1,024 samples drawn from the training set and compute per-tensor static scales for weights and activations. The scale for each tensor is determined by the maximum absolute value (amax) observed over the calibration dataset. The resulting FP8 (E4M3 format) or NVFP4 checkpoints can be loaded directly into vLLM. Table 8 shows that FP8-PTQ is essentially lossless: AI2D goes from 87.21 (BF16) to 87.56, ChartQA from 89.68 to 89.44, DocVQA from 94.22 to 94.32—all within normal variation. However, NVFP4-PTQ shows noticeable degradation: DocVQA drops from 94.22 to 92.38, ChartQA from 89.68 to 88.84, AI2D from 87.21 to 86.37. The 4-bit quantization is aggressive enough that simple post-training calibration cannot preserve accuracy.

Quantization-Aware Distillation (QAD). To recover the NVFP4 accuracy loss, the authors employ distillation: a PTQ-quantized student model is trained to match the final output logits of a BF16 teacher model, using a KL divergence loss (logit-matching) applied only to the final model outputs. The training hyperparameters mirror SFT Stage 1, except the learning rate is reduced to 2 × 10^-6 (10× lower than Stage 1's 2 × 10^-5). The distillation is performed in BF16 to simulate lower-precision behavior—the student model runs in BF16 but its forward pass emulates the quantization effects, and the gradients flow through the simulated quantization to update the student's weights to be more robust to 4-bit representation.

The QAD results in Table 8 demonstrate substantial recovery: NVFP4-QAD achieves DocVQA 93.95 (vs. 92.38 for PTQ, recovering 1.57 points toward the 94.22 BF16 baseline), ChartQA 89.96 (vs. 88.84), and AI2D 87.14 (vs. 86.37). The OCRBench-V2 English score actually exceeds the BF16 baseline at 61.94 vs. 61.74, which is likely within measurement noise but confirms that QAD has not degraded OCR capabilities. The gap between NVFP4-QAD and BF16 is now small (within 1 point on most benchmarks), making 4-bit deployment viable for resource-constrained inference scenarios.

The paper specifies that unless otherwise noted, "we quantize the language backbone—i.e., all linear layers, including both weights and activations—and retain the embedding layers, KV cache or others in higher precision" (Section 4.6). This mixed-precision strategy targets the most compute-intensive operations (linear layer matmuls in the LLM) for quantization while keeping memory-bound and precision-sensitive components (embeddings, attention key-value caches) in higher precision—a standard and effective approach in LLM quantization.

4. Key Insights and Innovations

Innovation 1: Text Capability Degradation as a First-Class Diagnostic, Not an Afterthought

The dominant practice in VLM development—from LLaVA (Liu et al., 2024b) to InternVL (Chen et al., 2024d) to Eagle (Li et al., 2025b)—is to train a vision–language model, evaluate it on multimodal benchmarks, and publish the final numbers. Text-only capability preservation is acknowledged as important but rarely tracked systematically through training stages and published in full. Practitioners know multimodal fine-tuning degrades text performance, but the degradation is treated as a regrettable side effect to be minimized through data mixture tuning, not as a diagnostic signal that reveals how and why different reasoning capabilities interact with visual representations.

This paper makes a fundamental conceptual shift: text capability trajectories across training stages are first-class experimental observables, on par with vision benchmark scores. Table 6 is not merely a results table—it is a diagnostic instrument. By publishing the full stage-by-stage trajectory of MATH-500, AIME-25, GPQA, LiveCodeBench, IFEval, SciCode, MMLU-Pro, and RULER alongside the vision benchmarks (Table 4), the authors enable a differential diagnosis of multimodal interference: LiveCodeBench and RULER collapse (70.0 → 50.9 and 77.9 → 8.8 after Stage 1) while MATH-500 barely budges (97.7 → 96.8). This asymmetry—code and long-context reasoning are far more vulnerable than mathematical reasoning—is not an incidental finding; it is a conceptual contribution about the structure of neural network interference. It suggests that code reasoning and long-context attention share representational substrates that are overwritten when visual token processing is introduced to the LLM's early layers, while mathematical reasoning circuits are more insulated—possibly because they operate at higher levels of semantic abstraction.

Prior work has occasionally reported text degradation (e.g., the LLaVA paper notes instruction-following degradation after multimodal training), but no major VLM paper has published a full, multi-benchmark text capability trajectory across all training stages. The field has been flying blind on this question, optimizing vision benchmarks and hoping text capabilities survive. By making the trajectory transparent and showing that the degradation pattern is differential (not uniform), the paper reframes text preservation from a nuisance variable into a scientific question: which capabilities are vulnerable, which are robust, and what does that tell us about the LLM's internal organization?

This is a fundamental diagnostic innovation, not an incremental refinement. It changes what VLM developers should measure and report. The fact that the paper's own attempts to mitigate degradation by adding code data to Stage 1 failed (Section 3.4)—and that a dedicated code-only recovery stage succeeded—provides empirical teeth: this is not a problem that can be solved by tweaking data mixtures within a single stage. It requires architectural thinking about training order and interference isolation.

Innovation 2: Sequential Capability Recovery as a Training Paradigm

If Innovation 1 is about diagnosing the problem, Innovation 2 is about the solution strategy that diagnosis enables. The paper's most significant methodological contribution is the demonstration that capabilities degraded by multimodal training can be recovered through dedicated, sequential fine-tuning stages that isolate the target capability from vision data gradients.

The field's implicit assumption—visible in the standard two-stage VLM recipe (pretrain connector, then jointly fine-tune everything)—is that capabilities are acquired cumulatively: later training stages build on earlier ones without destroying them. The catastrophic LiveCodeBench and RULER drops in Table 6 falsify this assumption for the specific case of adding vision to a strong text reasoner. The deeper question is whether the lost capabilities are permanently overwritten or suppressed but recoverable. The paper's Stages 3 and 4 provide a clear answer: they are recoverable.

Stage 3 (code-only, 1M samples, 15B tokens, 49K context) recovers LiveCodeBench from 55.0 back to 69.4—within 0.6 points of the 70.0 original—without degrading vision benchmarks (Table 4 shows AI2D, ChartQA, DocVQA, OCRBench all stable). Stage 4 (long-context-only, 74K samples, 12B tokens, 300K context) recovers RULER from 21.5 to 72.1—within 5.8 points of the 77.9 original—again without harming vision performance. This is not merely a training trick; it is evidence for a theory of interference as reversible suppression rather than permanent overwriting.

The conceptual advance is the reframing of VLM training from a monolithic integration problem (how do we add vision without breaking text?) to a sequential recovery problem (we add vision, things break in predictable ways, and we can fix them afterward with targeted interventions). This is analogous to the medical model of diagnosis followed by treatment, and it stands in contrast to the dominant "mix everything together and hope" approach to data curation.

Why did adding code data to Stage 1 fail while a separate Stage 3 succeeded? The paper doesn't answer this mechanistically, but the result itself constitutes a methodological innovation: it establishes that simultaneous gradient conflict (vision updates interfering with code updates in the same training step) is fundamentally different from sequential fine-tuning. The latter allows the model to first establish vision capabilities (Stages 1–2), then strengthen code circuits using gradients that do not simultaneously fight vision-related updates. This finding has implications beyond this paper—it suggests that any multi-capability training pipeline (not just VLMs) may benefit from isolating interfering capabilities into sequential rather than simultaneous training phases.

This is a fundamental methodological shift, not an incremental recipe refinement. It provides a principled alternative to the "just mix in more data" approach that the field has defaulted to, and it is supported by the specific failure of data-mixing mitigation (Section 3.4) followed by the success of sequential recovery (Table 6).

Innovation 3: Reasoning Budget Control as a Task-Specific Accuracy Optimizer

The Nemotron Nano V2 text-only model (NVIDIA et al., 2025) introduced reasoning budgets as a way to trade inference compute for accuracy—a familiar idea in the LLM space. What Nemotron Nano V2 VL contributes is not the budget mechanism itself but the counterintuitive empirical finding that capped reasoning can outperform unrestricted reasoning on vision tasks, and the conceptual reframing of reasoning budget as a task-specific hyperparameter rather than a global on/off switch.

The dominant assumption in the VLM field—visible in the design of benchmarks like MMMU and MathVista that evaluate chain-of-thought reasoning—is that more reasoning is always at least as good as less. If a model can think for 16K tokens, it should perform at least as well as when constrained to 4K. Figure 3 shatters this assumption: on CV-Bench (spatial reasoning), budget 8K achieves 81.0 vs. 78.3 for unrestricted; on OCRBench, budget 4K achieves 85.6 vs. 83.5; on TextVQA, budget 2K achieves 85.4 vs. 76.1. The unrestricted case is not merely failing to improve—it is actively worse.

The conceptual contribution is the diagnosis of why unrestricted reasoning degrades performance, which the authors attribute to two mechanisms: (1) malformed reasoning traces that loop or degenerate, consuming tokens without converging toward a correct answer, and (2) overly verbose reasoning on simple problems that introduces error opportunities. These are not merely implementation bugs—they reflect a fundamental property of autoregressive models trained to imitate reasoning traces: the model learns to perform reasoning as a behavioral pattern, not necessarily to use reasoning effectively. When that behavioral pattern is unconstrained, it can become self-defeating, generating output that confuses the model's own subsequent generation.

This insight has practical significance beyond this specific model: it implies that VLM evaluation protocols should sweep reasoning budgets, not just report a single "reasoning-on" number. The fact that different task categories have different optimal budgets (General VQA peaks at 2K–4K, STEM reasoning at 12K–unrestricted, document/OCR at 4K–8K) means that the field's current practice of reporting one reasoning-on score (with a fixed maximum output length) may systematically underestimate model capabilities by using a suboptimal budget for that specific task.

This is a conceptual reframing with empirical teeth, not a new technique. The budget control mechanism already existed; what's new is the demonstration that it produces non-monotonic accuracy curves on vision tasks and the identification of the mechanisms (degenerate traces, error-introducing verbosity) that explain this non-monotonicity. It shifts the question from "should we use reasoning?" to "how much reasoning is optimal for this specific task?"—a more nuanced and practically useful framing.

Innovation 4: Honest Ablation as a Contribution to Architectural Understanding

VLM papers typically present their architectural choices (tiling strategy, token compression method, resolution handling) as optimal and compare only against prior models. Nemotron Nano V2 VL does something rarer and more valuable: it runs a genuine head-to-head ablation of its tiling pipeline against a native-resolution alternative (Section 4.5, Table 7) and publishes the nuanced result—native resolution nearly matches tiling on average (74.8 vs. 75.0), loses ground on OCR benchmarks due to specific rescaling effects, and can be recovered by matching the tiling algorithm's image sizing without actually tiling (75.1, slightly exceeding tiling).

This ablation is not about claiming superiority—it is about understanding why tiling helps and where it doesn't. The conceptual contribution is the identification that tiling's advantage on OCR tasks is partially (but not entirely) attributable to the larger rescaling factors applied to small images during the aspect-ratio-preserving resizing step. When native-resolution encoding uses the same image sizes that tiling would select (Column 3: "Native Resolution with tiling-size matching"), OCRBench recovers from 82.8 to 85.3 (matching tiling's 84.5). But OCRBench-V2 English still lags at 57.6 vs. 61.4, suggesting an additional benefit of tiling beyond rescaling—possibly related to the independent encoding of local regions allowing finer-grained feature extraction for text characters.

In a field where architectural choices are often justified post-hoc ("we chose tiling because it works well") rather than investigated systematically, this ablation represents a methodological innovation in reporting standards. It tells practitioners something actionable: if your task distribution is not OCR-heavy, native-resolution encoding with convolutional compression is a simpler, nearly-equivalent alternative. If you need state-of-the-art text reading, tiling provides genuine gains that are partially replicable through smarter resizing but partially intrinsic to the tiled encoding approach.

The authors' explicit acknowledgment that "the gap on OCRBench-V2 (English) persists" and their commitment to "further investigate strategies to address this gap in future work" models a scientific approach to architecture development that is more common in academic papers than in industry technical reports. This is an incremental but culturally significant contribution: it demonstrates that honest ablation—publishing results where your chosen method doesn't clearly win—builds credibility and provides actionable guidance in ways that selective reporting of only favorable comparisons does not.

5. Experimental Analysis

Evaluation Methodology

Dataset. The paper evaluates on 45 benchmarks spanning seven categories: General VQA (13 benchmarks including MMBench, MMStar, BLINK, MUIRBench, HallusionBench, etc.), STEM Reasoning (8 benchmarks including MMMU, MMMU-Pro, MathVista-Mini, MathVision, MathVerse-Mini, DynaMath, LogicVista, WeMath), Document Understanding/OCR/Charts (13 benchmarks including OCRBench, OCRBench-V2, ChartQA, DocVQA, InfoVQA, TextVQA, etc.), Visual Grounding & Spatial Reasoning (2 benchmarks: TreeBench, CV-Bench), GUI Understanding (3 benchmarks: ScreenSpot, ScreenSpot-v2, ScreenSpot-Pro), Video Understanding (3 benchmarks: LongVideoBench, MLVU, Video-MME), and Multimodal Multilingual Understanding (3 benchmarks: MTVQA, MMMB, Multilingual MMBench). All evaluations use the VLMEvalKit framework with a vLLM backend inference server.
Base model(s). The primary model is Nemotron Nano V2 VL (12B parameters), built on the Nemotron-Nano-12B-V2 hybrid Mamba-Transformer LLM backbone with the c-RADIOv2-VLM-H vision encoder. The predecessor model, Llama-3.1-Nemotron-Nano-VL-8B (an 8B parameter Transformer-only VLM), serves as the internal baseline across all vision benchmarks in Table 4. For external comparisons, the paper uses InternVL3.5 (14B), GLM-4.5V (106B-A12B, a Mixture-of-Experts architecture with 12B active parameters), and Qwen3-VL (8B) — models of comparable or somewhat larger scale that represent state-of-the-art open-source VLMs.
Metrics. All multimodal benchmarks report accuracy (%) as the primary metric, with exact string matching or benchmark-specific grading functions applied via VLMEvalKit. For text-only evaluations, the paper reports Pass@1 averaged over multiple runs (16 runs for AIME-2025, 4 runs for MATH-500/GPQA-Diamond/LiveCodeBench/IFEval, 1 run for SciCode/RULER) to account for sampling variance in reasoning-on mode. MMLU-Pro uses a 1000-sample subset accuracy. Video benchmarks report accuracy on individual benchmarks (LongVideoBench, MLVU M-Avg, Video-MME without subtitles). For WildVision, the metric is win rate (%) against a reference model. The paper does not report confidence intervals or standard deviations on any benchmark scores, which limits the ability to distinguish genuine improvements from sampling noise.
Baselines. The internal primary baseline is Llama-3.1-Nemotron-Nano-VL-8B (the previous-generation model), evaluated on 14 vision benchmarks in Table 4 (AI2D: 85.0, ChartQA: 86.3, DocVQA-val: 91.2, InfoVQA-val: 77.4, MMMU-val: 48.2, OCRBench: 83.9, OCRBench-V2 CN: 37.9, OCRBench-V2 EN: 60.1, Video-MME: 54.7). The external baselines are InternVL3.5 (14B, Wang et al., 2025b), GLM-4.5V (106B-A12B, Hong et al., 2025), and Qwen3-VL (8B, Yang et al., 2025a), with scores sourced from their respective technical reports where available and independently reproduced using VLMEvalKit where not (marked with * in Tables 3 and 5). For quantized model evaluations (Table 8), the BF16 checkpoint serves as the baseline with minor discrepancies attributed to "variations in evaluation framework implementations."
Generation budget / compute accounting. For reasoning-off mode, the model uses greedy decoding with a maximum of 1,024 generated tokens for all benchmarks except RDTableBench (which uses 16,384 tokens due to its table-to-SQL format requiring longer outputs). For reasoning-on mode, settings shift to temperature 0.6, top-p 0.95, and maximum output length 16,384 tokens. Reasoning budget control experiments (Figure 3) evaluate at discrete caps of 2K, 4K, 8K, and 12K tokens (each with a 500-token grace period), plus the unrestricted 16,384-token setting. The paper does not report FLOPs or wall-clock inference time in the main benchmark comparisons — the primary "cost" metric is output token count, not total computation. For video efficiency experiments (Figure 4), time-to-first-token (TTFT, in milliseconds) and throughput (tokens/second) are reported alongside accuracy, measured on an RTX 6000 PRO SE GPU using vLLM with 128 input frames, 30 text input tokens, and 128 output tokens.
Cross-validation / statistical protocol. For the image processing ablation (Section 4.5, Table 7), the authors evaluate on the last 10 saved checkpoints for each strategy and select the checkpoint with the highest average benchmark score — a form of repeated-measures evaluation that accounts for training variance. For the main results tables (Tables 3–6), no cross-validation or statistical significance testing is reported. The stage-by-stage benchmark trajectories (Tables 4 and 6) represent single-run evaluations (one checkpoint per stage), meaning the observed fluctuations (e.g., AI2D going from 87.1 to 87.3 to 87.2 across Stages 2–4) could reflect checkpoint noise rather than genuine capability shifts. For the RULER recovery from 21.46 to 72.12 between Stages 3 and 4 (Table 6), the 50.7-point jump is clearly beyond noise, but smaller movements (e.g., GPQA oscillating between 60.9 → 63.0 → 60.6 → 64.1) are harder to interpret without variance estimates.

Main Quantitative Results

Multimodal Benchmark Comparisons Against Internal Predecessor

The paper's most direct causal comparison is against its own previous-generation model, Llama-3.1-Nemotron-Nano-VL-8B, evaluated on 14 vision benchmarks after each training stage (Table 4). The final Stage 4 model (reasoning-off) achieves:

AI2D: 87.2 (vs. 85.0 for predecessor, +2.2 points)
ChartQA: 89.8 (vs. 86.3, +3.5 points)
DocVQA (val): 94.4 (vs. 91.2, +3.2 points)
InfoVQA (val): 79.2 (vs. 77.4, +1.8 points)
MMMU (val): 55.3 (vs. 48.2, +7.1 points)
OCRBench: 85.6 (vs. 83.9, +1.7 points)
OCRBench-V2 (Chinese): 44.2 (vs. 37.9, +6.3 points)
OCRBench-V2 (English): 62.0 (vs. 60.1, +1.9 points)
Video-MME: 66.0 (vs. 54.7, +11.3 points)

The most dramatic improvements are in MMMU (+7.1 points) and Video-MME (+11.3 points). The MMMU gain likely reflects the expanded STEM reasoning data in Stage 1 and the stronger LLM backbone (Nemotron-Nano-12B-V2 vs. the previous model's Llama-3.1-8B). The Video-MME improvement combines the context extension to 49K tokens (Stage 2), the dedicated video QA datasets (1.4M samples in Stage 2), and the architectural efficiency of the hybrid Mamba-Transformer backbone, which processes long visual token sequences more effectively. The paper does not ablate these factors separately, so it is impossible to attribute the 11.3-point gain to any single improvement.

The relatively modest gains on OCRBench (+1.7) and OCRBench-V2 English (+1.9) despite the extensive OCR data additions (SynthDog-en, SynthTabNet, DocLayNet, WebSight, NVPDFTex outputs, etc.) suggest that OCR performance on these benchmarks may be approaching a ceiling, or that the benchmark's difficulty is insufficient to differentiate the improvements in document understanding the model has acquired.

Multimodal Benchmark Comparisons Against External SOTA Models

Table 3 presents reasoning-off and reasoning-on comparisons against InternVL3.5 (14B), GLM-4.5V (106B-A12B), and Qwen3-VL (8B) across the seven benchmark categories. The Nemotron Nano V2 VL model shows competitive but not dominant performance:

Where Nemotron Nano V2 VL leads (reasoning-off):

ChartQA (Test): 89.8 vs. 86.5 (InternVL3.5) — a 3.3-point lead
AI2D (Test): 87.2 vs. 85.1 (InternVL3.5) — a 2.1-point lead
DocVQA (Test): 94.7 vs. 93.4 (InternVL3.5) — a 1.3-point lead
InfoVQA (Test): 79.4 vs. 78.3 (InternVL3.5) — a 1.1-point lead
TextVQA (Val): 85.4 vs. 77.8 (InternVL3.5) — a 7.6-point lead
HallusionBench: 72.3 vs. 54.0 (InternVL3.5) — an 18.3-point lead

The large leads on TextVQA and HallusionBench are noteworthy. TextVQA requires reading and reasoning about text in natural images — a direct test of the expanded OCR training data and tiling strategy. HallusionBench tests resistance to visual hallucination and language-vision illusions, where the model's structured multi-stage training may confer robustness advantages over InternVL3.5's non-thinking mode. However, InternVL3.5 reports only its base ("Non-Thinking") scores for these benchmarks — its "Thinking" mode scores (when available) might narrow or reverse these gaps (e.g., InternVL3.5 achieves 70.4 on MMStar in non-thinking mode vs. 65.9 for Nemotron Nano V2 VL; InternVL3.5's thinking score is not reported but could plausibly exceed 71+).

Where Nemotron Nano V2 VL lags notably (reasoning-off):

ScreenSpot: 39.4 vs. 87.5 (InternVL3.5) and 94.4 (Qwen3-VL) — a catastrophic gap
ScreenSpot-v2: 41.7 vs. 88.6 (InternVL3.5)
ScreenSpot-Pro: 4.8 vs. 54.6 (Qwen3-VL)
MUIRBench: 33.2 vs. 58.0 (InternVL3.5)
WildVision (win rate): 16.0 vs. 73.0 (InternVL3.5)

The ScreenSpot family results are the most significant weakness. ScreenSpot tests GUI grounding — the ability to localize UI elements given natural language instructions — and the 40-50+ point gap against InternVL3.5 and Qwen3-VL indicates a fundamental capability deficit. The paper does not discuss this gap or analyze its causes, which is a notable omission. Possible explanations include: (1) insufficient GUI-specific training data relative to InternVL3.5, which emphasizes agentic and GUI capabilities; (2) the tiling strategy may not be well-suited to high-resolution screenshots where UI elements are densely packed and small; (3) the training data mix, while including ScreenQA and WaveUI-25K, may lack the diversity and scale of GUI grounding data that InternVL3.5 and Qwen3-VL prioritize. The ScreenSpot-Pro score of 4.8 (vs. 54.6 for Qwen3-VL) on professional high-resolution computer use suggests the model is essentially non-functional for GUI agent applications — a major limitation for users considering deployment in automation or agentic workflows.

MUIRBench (multi-image understanding) at 33.2 vs. 58.0 indicates weaker multi-image reasoning, despite Stage 2's inclusion of multi-image captioning (Mementos) and multi-page QA data. This may reflect the challenge of the benchmark being heavier on compositional reasoning across images rather than extraction of information from individual images.

WildVision win rate of 16.0 — meaning the model is preferred only 16% of the time against a reference model (likely GPT-4V or similar) — is among the lowest reported in Table 3 (Qwen3-VL: 75.0, InternVL3.5: 73.0). WildVision tests open-ended visual dialogue quality and human preference alignment, suggesting the model's training may be over-optimized for benchmark-style accuracy metrics at the expense of conversational quality and human preference alignment.

Reasoning-on mode comparison (Table 3): When reasoning-on is enabled, Nemotron Nano V2 VL gains substantially on STEM reasoning benchmarks:

MMMU (val): 55.3 → 67.8 (+12.5 points), compared to InternVL3.5-Thinking at 73.3 and Qwen3-VL-Thinking at 74.1
MathVision: 31.5 → 53.6 (+22.1 points), vs. InternVL3.5-Thinking at 59.9
MathVerse-Mini: 34.3 → 58.2 (+23.9 points), vs. InternVL3.5-Thinking at 62.8
LogicVista: 38.7 → 58.4 (+19.7 points), vs. InternVL3.5-Thinking at 60.2

The reasoning-on gains are substantial in absolute terms but typically still trail InternVL3.5-Thinking and GLM-4.5V-Thinking by 5-15 points, suggesting that while the budget control mechanism enables effective chain-of-thought reasoning, the underlying reasoning capability of the 12B backbone is still below the frontier set by larger or more reasoning-specialized models.

Multilingual multimodal benchmarks (Table 5): Nemotron Nano V2 VL underperforms across the board on multilingual benchmarks compared to InternVL3.5:

MTVQA (Avg): 24.3 vs. 34.2 (InternVL3.5)
MMMB (en/zh/pt/ar/tr/ru): averages approximately 83.1 vs. InternVL3.5 averages approximately 82.4 (slight edge), but GLM-4.5V leads at ~85.4
Multilingual MMBench: averages approximately 81.6 vs. InternVL3.5 at 80.6 (slight edge)

The MTVQA gap of 9.9 points (24.3 vs. 34.2) is the most concerning. MTVQA tests multilingual text-centric visual question answering — a direct test of OCR capabilities across languages. Despite the multilingual data in Stage 1 (mBART-translated arXiv papers, multilingual Wikimedia dumps), the model's multilingual OCR performance significantly lags InternVL3.5. The weakness may stem from the vision encoder (c-RADIOv2-VLM-H) being primarily English-optimized, or from insufficient multilingual text-image paired data in the training mix relative to InternVL3.5's dataset composition.

Text-Only Capability Trajectory Across Training Stages

Table 6 is the paper's most diagnostically valuable result, tracking text reasoning benchmark performance through all five training stages. The baseline is Stage 0 (LLM frozen, MLP projector only is trained), which preserves the original Nemotron-Nano-12B-V2 capabilities exactly:

Stage 0 (LLM baseline, reasoning-on):

MATH-500: 97.7
AIME-25: 75.9
GPQA: 65.0
LiveCodeBench: 70.0
RULER: 77.9
IFEval_prompt_strict: 84.2
SciCode_problem_accuracy: 7.5
MMLU-Pro-1000: 77.8

Stage 1 degradation (after 112.5B tokens of multimodal SFT, reasoning-on):

LiveCodeBench: 70.0 → 50.9 (–19.1 points, a 27% relative decline)
RULER: 77.9 → 8.8 (–69.1 points, an 89% relative decline)
AIME-25: 75.9 → 68.0 (–7.9 points)
GPQA: 65.0 → 60.9 (–4.1 points)
IFEval_prompt_strict: 84.2 → 77.5 (–6.7 points)
SciCode_problem_accuracy: 7.5 → 5.0 (–2.5 points)
MATH-500: 97.7 → 96.8 (–0.9 points, essentially stable)
MMLU-Pro-1000: 77.8 → 75.2 (–2.6 points)

The asymmetry is stark and informative: LiveCodeBench and RULER absorb catastrophic damage while MATH-500 remains nearly untouched. This differential degradation pattern is not discussed in the paper's main text beyond noting the drop, but it is the single most important diagnostic signal about how multimodal training interferes with the LLM backbone. The fact that code reasoning (LiveCodeBench) and long-context understanding (RULER) collapse while mathematical reasoning (MATH-500) is preserved suggests that the interference targets specific neural circuits — likely those involving structured syntactic processing (code) and positional attention mechanisms (long context) — while sparing more abstract semantic reasoning circuits (math). This is a non-obvious finding that the paper under-interprets.

Stage 2 partial recovery (after video context extension, reasoning-on):

LiveCodeBench: 50.9 → 55.0 (+4.1 points recovered)
RULER: 8.8 → 17.4 (+8.6 points recovered)
AIME-25: 68.0 → 72.7 (+4.7 points recovered)

The video-focused training provides partial recovery of code and long-context capabilities, but the mechanism is unclear. Video data involves long sequences (potentially exercising positional attention) but not code-specific patterns. The modest RULER improvement (8.8 → 17.4) suggests that processing long video sequences does help re-establish some positional attention mechanisms, but the recovery is far from complete — RULER is still at only 22% of its original value.

Stage 3 code recovery (after code-only SFT, reasoning-on):

LiveCodeBench: 55.0 → 69.4 (+14.4 points, near-complete recovery to within 0.6 of original 70.0)
AIME-25: 72.7 → 72.7 (stable)
MATH-500: 97.3 → 97.6 (+0.3, stable)

The near-complete recovery of LiveCodeBench (to 99.1% of original) while vision benchmarks remain stable (Table 4: AI2D 87.1 → 87.3, ChartQA 90.0 → 90.2, DocVQA 94.3 → 94.2) is the paper's strongest single finding in support of its multi-stage recovery strategy. This demonstrates that (a) the code reasoning capability was not permanently lost during multimodal training but rather suppressed, (b) dedicated code-only fine-tuning can selectively restore it, and (c) visual capabilities are robust to subsequent text-only fine-tuning at the 1M-sample scale. The generalizability of this finding — whether it holds for other capability pairs and at larger training scales — is not tested but is a natural direction for future work.

Stage 4 long-context recovery (after ultra-long-context SFT, reasoning-on):

RULER: 21.5 → 72.1 (+50.6 points, recovery to 93% of original 77.9)
LiveCodeBench: 69.4 → 69.4 (stable, confirming Stage 3 recovery is robust)
GPQA: 60.6 → 64.1 (+3.5 points, modest improvement)

The RULER recovery from 21.5 to 72.1 is dramatic and validates Stage 4's dedicated long-context training. However, the residual 5.8-point gap from the original 77.9 might be irreducible — the original long-context capability may have been partially overwritten rather than suppressed. Alternatively, additional long-context training data (beyond the 74K samples / 12B tokens used) might close the gap further.

Final vs. original comparison (Stage 4 vs. Stage 0):

MATH-500: 96.9 (vs. 97.7, –0.8)
AIME-25: 71.3 (vs. 75.9, –4.6)
GPQA: 64.1 (vs. 65.0, –0.9)
LiveCodeBench: 69.4 (vs. 70.0, –0.6)
RULER: 72.1 (vs. 77.9, –5.8)
IFEval_prompt_strict: 78.2 (vs. 84.2, –6.0)
SciCode_problem_accuracy: 6.9 (vs. 7.5, –0.6)
MMLU-Pro-1000: 77.1 (vs. 77.8, –0.7)

The final model retains most of its original text capabilities to within a few points, with the notable exceptions of AIME-25 (–4.6), RULER (–5.8), and IFEval (–6.0). This represents a net success for the recovery strategy — the model gains substantial vision capabilities while preserving text reasoning to within ~1–6 points of the original LLM, compared to the post-Stage-1 nadir where LiveCodeBench was at 50.9 and RULER at 8.8. The residual AIME-25 gap (–4.6 points) suggests that competition-level math reasoning is more difficult to fully recover than standard math (MATH-500 at –0.8) — possibly because AIME problems require longer, more creative reasoning chains that are more susceptible to interference from the multimodal training process.

Reasoning Budget Control Experiments

Figure 3 presents the effect of capping reasoning output length at 2K, 4K, 8K, and 12K tokens (with 500-token grace periods) versus reasoning-off (budget 0) and unrestricted reasoning (16,384 tokens). The results are shown across four task clusters: General VQA, Document/OCR/Chart Understanding, Spatial & Video Understanding, and STEM & Chart Reasoning. The headline finding is that capped reasoning frequently outperforms unrestricted reasoning, with the optimal budget varying by task.

General VQA (Figure 3a):

MMStar: reasoning-off 65.9, peak at budget 2K (68.3*), unrestricted 71.7 (unrestricted wins)
POPE: reasoning-off 88.8, peak at budget 4K (89.0*), unrestricted 87.0
BLINK: reasoning-off 57.6, peak at budget 4K (60.0*), unrestricted 56.7
HallusionBench: reasoning-off 72.3, peak at budget 2K (73.1*), unrestricted 73.1 (tied)
R-Bench (dis): reasoning-off 75.2, peak at budget 2K (75.2), unrestricted 69.7

For POPE and BLINK, budget control provides a clear accuracy advantage over unrestricted reasoning (+2.0 and +3.3 points respectively). For R-Bench, unrestricted reasoning is actively harmful (75.2 → 69.7, a 5.5-point drop compared to reasoning-off), while budget 2K preserves the reasoning-off accuracy. The MMStar case is the only one where unrestricted reasoning clearly wins, suggesting that the complex multi-modal reasoning in MMStar benefits from extended chains.

Document, OCR & Chart Understanding (Figure 3b):

AI2D: reasoning-off 87.2, peak at budget 8K (87.2), unrestricted 84.7
DocVQA: reasoning-off 94.7, peak at budget 4K (95.0*), unrestricted 93.2
ChartQA: reasoning-off 89.8, peak at budget 4K (89.8), unrestricted 84.9
OCRBench: reasoning-off 85.6 (peak), unrestricted 83.5
TextVQA: reasoning-off 85.4 (peak), unrestricted 76.1
InfoVQA: reasoning-off 79.4, peak at budget 12K (80.4*), unrestricted 80.4 (tied)

The document understanding tasks show a striking pattern: reasoning-off matches or exceeds budget-controlled reasoning on AI2D, ChartQA, OCRBench, and TextVQA, while unrestricted reasoning is worse across the board (TextVQA drops from 85.4 to 76.1, a 9.3-point loss). This strongly supports the paper's hypothesis that verbose reasoning introduces errors on tasks where the answer is extractable directly from the visual input. For TextVQA — where the task is reading and understanding text in images — generating thousands of tokens of reasoning before answering apparently introduces more confusion than clarification.

Spatial & Video Understanding (Figure 3c):

CV-Bench: reasoning-off 81.0 (peak), unrestricted 78.3
LongVideoBench: reasoning-off 63.6 (peak), unrestricted 57.0
Video-MME: reasoning-off 66.0 (peak), unrestricted 63.0
TreeBench: reasoning-off 38.5, peak at budget 2K (42.5*), unrestricted 42.5 (tied)

Video understanding benchmarks show uniform degradation with reasoning-on (unrestricted), with reasoning-off outperforming by 3–6 points. This is expected: video questions often require identifying specific events or actions that are directly observable, and extended reasoning chains — which may drift into speculation or hallucinated temporal sequences — degrade rather than enhance performance. TreeBench (spatial reasoning) shows a modest gain at budget 2K (+4.0 points over reasoning-off), suggesting that brief structured reasoning helps for spatial problems but longer chains add no value.

STEM & Chart Reasoning (Figure 3d):

MathVista-Mini: reasoning-off 69.0, peak at unrestricted (75.5*)
MathVision: reasoning-off 31.5, peak at unrestricted (53.6*)
MathVerse-Mini: reasoning-off 34.3, peak at unrestricted (58.2*)
LogicVista: reasoning-off 38.7, peak at unrestricted (58.4*)
MMMU (val): reasoning-off 55.3, peak at unrestricted (67.8*)
MMMU-Pro: reasoning-off 14.5, peak at unrestricted (28.0*)

STEM reasoning is the only category where unrestricted reasoning consistently and substantially outperforms all budget-constrained variants, with improvements ranging from +6.5 points (MathVista-Mini) to +19.7 points (LogicVista). This aligns with the intuition that multi-step mathematical and logical reasoning genuinely benefits from longer chain-of-thought. Interestingly, the improvement is monotonic — higher budgets strictly improve accuracy — suggesting that, unlike in General VQA or Document Understanding, STEM reasoning does not suffer from the "overly verbose reasoning introduces errors" problem. This may be because mathematical reasoning chains are inherently more structured and less prone to hallucinatory drift than open-ended visual reasoning.

The paper does not report whether the starred (*) values in Figure 3 represent the best budget for each task selected post-hoc (which would overstate the benefit of budget control) or whether a consistent budget-selection policy was applied across tasks. This matters for practical deployment: if each task requires its own optimal budget, the user must either know the task distribution in advance or incur the cost of budget-sweeping at inference time.

Efficient Video Sampling (EVS) Ablation

Figure 4 reports accuracy, time-to-first-token (TTFT), and throughput for EVS ratios from 50% to 90% on LongVideoBench and Video-MME, evaluated in both BF16 and FP8 precision on an RTX 6000 PRO SE GPU. The key results:

BF16 precision:

EVS OFF: LongVideoBench 63.6, Video-MME 66.0, TTFT 4,131 ms, throughput 34 tok/s
EVS 50%: LongVideoBench 63.7, Video-MME 66.0, TTFT 2,699 ms (–35%), throughput 65 tok/s (+91%)
EVS 80%: LongVideoBench 62.4, Video-MME 65.6 (–0.4), TTFT 1,990 ms (–52%), throughput 98 tok/s (+188%)
EVS 90%: LongVideoBench 60.7, Video-MME 64.0 (–2.0), TTFT 1,654 ms (–60%), throughput 120 tok/s (+253%)

FP8 precision:

EVS OFF: LongVideoBench 64.2, Video-MME 66.4, TTFT 3,436 ms, throughput 51 tok/s
EVS 50%: LongVideoBench 63.7, Video-MME 66.5, TTFT 2,384 ms (–31%), throughput 80 tok/s (+57%)
EVS 80%: LongVideoBench 62.8, Video-MME 65.1 (–1.3), TTFT 1,717 ms (–50%), throughput 103 tok/s (+102%)
EVS 90%: LongVideoBench 60.4, Video-MME 64.0 (–2.4), TTFT 1,567 ms (–54%), throughput 132 tok/s (+159%)

The takeaway is that EVS provides substantial speedups with minimal accuracy loss at ratios up to 75–80%. At 75% EVS in BF16, the accuracy impact is negligible (LongVideoBench 62.5 vs. 63.6, Video-MME 66.1 vs. 66.0) while TTFT halves and throughput nearly triples. At 90%, the accuracy loss becomes more noticeable (–2.0 to –2.4 points on Video-MME), representing the beginning of the accuracy-speedup Pareto frontier where further pruning meaningfully degrades video understanding.

The FP8 results track BF16 closely, confirming that the EVS mechanism is not precision-dependent — the temporal patch similarity is computed on visual features robust to FP8 quantization. The FP8 baseline actually shows slightly higher accuracy than BF16 on LongVideoBench (64.2 vs. 63.6 with EVS OFF), which is likely within measurement noise but confirms no systematic degradation from FP8 quantization in the video pipeline.

A notable pattern is that Video-MME accuracy is more sensitive to high EVS ratios than LongVideoBench: at 90% EVS (FP8), Video-MME drops from 66.4 to 64.0 (–2.4) while LongVideoBench drops from 64.2 to 60.4 (–3.8). The paper does not explain this differential sensitivity — one hypothesis is that LongVideoBench's longer video durations mean that aggressive temporal pruning removes more informative frames, while Video-MME's diverse task mix includes some questions answerable from fewer frames.

Image Processing Ablation: Tiling vs. Native Resolution

Table 7 compares three image processing strategies across 10 benchmarks, with each strategy trained through Stages 0 and 1 (without text reasoning data) and evaluated at the checkpoint with the highest average benchmark score:

Tiling (default): Average 75.0

AI2D: 87.1, ChartQA: 89.8, DocVQA: 94.5, InfoVQA: 80.2, MMMU: 56.8
MathVista-Mini: 69.7, OCRBench: 84.5, OCRBench-V2 CN: 40.5, OCRBench-V2 EN: 61.4, TextVQA: 85.6

Native Resolution (no tiling, convolutional token reduction): Average 74.8 (–0.2)

AI2D: 86.4, ChartQA: 88.4, DocVQA: 95.1, InfoVQA: 80.7, MMMU: 56.0
MathVista-Mini: 71.3, OCRBench: 82.8, OCRBench-V2 CN: 45.3, OCRBench-V2 EN: 57.6, TextVQA: 84.6

Native Resolution with tiling-size matching: Average 75.1 (+0.1 over tiling)

AI2D: 87.8, ChartQA: 90.3, DocVQA: 94.9, InfoVQA: 79.0, MMMU: 56.2
MathVista-Mini: 71.2, OCRBench: 85.3, OCRBench-V2 CN: 42.7, OCRBench-V2 EN: 57.6, TextVQA: 86.2

The most significant gap is OCRBench-V2 English: 61.4 (tiling) vs. 57.6 (both native variants), a 3.8-point deficit. OCRBench drops from 84.5 (tiling) to 82.8 (native), with tiling-size matching recovering to 85.3. This confirms that for OCR tasks specifically, the tiling pipeline provides genuine benefits beyond image resizing — the independent encoding of local regions appears to capture fine text details that native-resolution encoding with 4× compression loses. However, the fact that OCRBench-V2 Chinese improves under native resolution (40.5 → 45.3) suggests that the optimal processing strategy may be language-dependent, possibly because Chinese characters have different spatial frequency characteristics than Latin script.

The average scores are remarkably close (75.0 vs. 74.8 vs. 75.1), indicating that for non-OCR-heavy task distributions, the choice between tiling and native resolution is largely an implementation convenience decision rather than a critical accuracy determinant. This is an important practical finding: developers who don't need state-of-the-art OCR can simplify their pipeline significantly.

Quantization Results

Table 8 compares BF16, FP8-PTQ, NVFP4-PTQ, and NVFP4-QAD checkpoints evaluated in vLLM on five benchmarks:

BF16: AI2D 87.21, ChartQA 89.68, OCRBench 854, DocVQA-val 94.22, OCRBenchV2 EN 61.74
FP8-PTQ: AI2D 87.56 (+0.35), ChartQA 89.44 (–0.24), OCRBench 854 (identical), DocVQA-val 94.32 (+0.10), OCRBenchV2 EN 61.83 (+0.09)
NVFP4-PTQ: AI2D 86.37 (–0.84), ChartQA 88.84 (–0.84), OCRBench 863 (+9), DocVQA-val 92.38 (–1.84), OCRBenchV2 EN 60.88 (–0.86)
NVFP4-QAD: AI2D 87.14 (–0.07), ChartQA 89.96 (+0.28), OCRBench 851 (–3), DocVQA-val 93.95 (–0.27), OCRBenchV2 EN 61.94 (+0.20)

Note: OCRBench scores appear anomalously high (854, 863, 851) compared to the typical 0–100 scale reported elsewhere in the paper (Tables 3–4 show OCRBench scores of 83.5–85.6). This is likely a scaling difference in the vLLM evaluation framework's reporting of this specific benchmark and should not be interpreted as a 10× improvement.

FP8-PTQ is essentially lossless — all benchmark scores are within normal checkpoint-to-checkpoint variation of the BF16 baseline. NVFP4-PTQ shows a consistent accuracy drop of roughly 0.8–1.8 points across all benchmarks, with DocVQA-val taking the largest hit (–1.84 points). NVFP4-QAD recovers most of this loss through distillation: the gap to BF16 narrows to 0.07–0.27 points on AI2D, ChartQA, and DocVQA, representing a 90%+ recovery of the PTQ-induced accuracy loss. The OCRBenchV2 EN score even slightly exceeds the BF16 baseline (61.94 vs. 61.74), which may be within measurement noise but suggests no systematic degradation from QAD on OCR tasks.

The practical implication is clear: NVFP4-PTQ is not deployable without unacceptable accuracy loss for document understanding tasks (DocVQA drops 1.84 points, ~2% relative), but NVFP4-QAD closes the gap to within ~0.3 points of BF16, making 4-bit deployment viable. The additional computational cost of QAD (one additional training stage with distillation) is amortized over inference savings — a worthwhile tradeoff for bandwidth- or memory-constrained deployments.

Ablation Studies and Robustness Checks

Training stage progression on vision benchmarks (Table 4): The stage-by-stage vision benchmark trajectory validates the multi-stage design. Stage 1 provides the bulk of vision capability acquisition (AI2D: 67.6 → 87.1, ChartQA: 70.9 → 89.9, DocVQA: 79.1 → 94.4, MMMU: 49.0 → 54.8). Stage 2's context extension provides large gains on video benchmarks (LongVideoBench: 59.4 → 63.6, Video-MME: 57.6 → 65.8) and moderate gains on document benchmarks (MMLongBench-Doc: 29.2 → 32.0), confirming that the 49K context extension is necessary for long-sequence tasks. Stage 3 (code recovery) has essentially no impact on vision benchmarks — all scores are within ±0.3 points of Stage 2 — confirming that the code-only training does not degrade visual capabilities at this data scale. Stage 4 (long-context extension) similarly leaves vision benchmarks essentially unchanged, with most scores fluctuating by ±0.2 points.

Text benchmark stage-by-stage trajectory (Table 6): The detailed text benchmark tracking reveals a pattern that the paper's main text only partially addresses: the degradation and recovery are capability-specific, not uniform. MATH-500 barely moves (97.7 → 96.8 → 97.3 → 97.6 → 96.9), suggesting math reasoning is highly robust to multimodal interference. AIME-25 shows moderate degradation (75.9 → 68.0) and incomplete recovery (71.3 final, –4.6 residual), suggesting that competition-level math uses different neural circuits than standard math problems, and those circuits are partially but not fully recoverable. GPQA oscillates (65.0 → 60.9 → 63.0 → 60.6 → 64.1) — the pattern is noisy but the net change is only –0.9, suggesting graduate-level science reasoning is largely preserved. IFEval degrades and does not recover (84.2/89.3 → 77.5/84.1 → 77.3/83.9 → 76.5/83.4 → 78.2/84.7), with final scores 5–6 points below original — instruction-following precision appears to be a capability that multimodal training permanently degrades and the recovery stages do not address.

Unsuccessful mitigation strategies (Section 3.4): The paper explicitly reports that two attempted approaches to prevent text degradation failed: "augmenting the SFT stage 1 dataset with additional code reasoning examples and disabling loss scaling." This negative result is valuable because it rules out the most obvious fix (add more code data to the multimodal mix) and suggests that the interference is not a simple data-imbalance problem. The fact that loss scaling (which adjusts per-token loss weights based on sequence length) didn't help indicates the issue is not about long vs. short sequence weighting but about gradient conflict between vision and code task objectives. The paper does not report the magnitude of these failed attempts — how much additional code data was added, and what the resulting LiveCodeBench scores were — which limits the diagnostic value of this negative result.

Data reuse ratio in Stage 2 (Section 3.3): The authors state they "experimented with varying proportions of Stage 1 data and found that a 25% reuse ratio offers a good balance between training efficiency and maintaining accuracy across text, vision, multi-frame and video benchmarks." However, no ablation table or figure is provided showing the effect of different reuse ratios. This is a significant omission: the 25% number is presented as a finding but without the experimental evidence to support it. Readers cannot assess whether the optimum is broad (any ratio from 15–35% works similarly well) or narrow (performance drops sharply at 20% or 30%).

Vision encoder / vision projection in BF16 vs. FP8 (Section 3.6): The paper reports that "experiments keeping either the vision encoder or vision projection in BF16 did not yield a significant difference." No quantitative results are provided for this claim. Given that the vision encoder processes the raw pixel input and is responsible for preserving fine-grained visual detail, the robustness to FP8 quantization is an important finding that deserves more than a one-sentence assertion without supporting data.

EVS precision comparison (Figure 4): The side-by-side BF16 and FP8 EVS ablation is a robustness check on the interaction between quantization and temporal pruning. The FP8 results closely track BF16 across all EVS ratios — for example, at 80% EVS, LongVideoBench is 62.4 (BF16) vs. 62.8 (FP8), Video-MME is 65.6 (BF16) vs. 65.1 (FP8). This suggests that the temporal patch similarity computation used by EVS is not sensitive to FP8 quantization of the vision encoder features, which is a non-obvious result given that similarity metrics on low-precision representations can become noisy at high compression ratios.

Absence of specified ablations: Several experiments that would strengthen the paper's core claims are absent. (1) No ablation on the effect of excluding text reasoning data entirely from Stage 1 — would the vision benchmarks improve further, and how much worse would the text degradation be? This would establish the lower bound on text degradation and quantify the vision-text tradeoff. (2) No ablation on the number of training samples in Stages 3 and 4 — the paper uses 1M code samples and 74K long-context samples, but doesn't show that these quantities are sufficient (is recovery saturating, or would more data close the residual gap to the original LLM?). (3) No ablation on Stage 3 data composition — is pure code data necessary, or would a mix of code + math + long-context text data in Stage 3 recover multiple capabilities simultaneously? The current recipe requires separate stages for code and long-context recovery, which doubles the number of recovery stages; a unified recovery stage would be practically preferable if it works. (4) No ablation on the learning rate or optimizer settings for the recovery stages — the paper uses the same learning rate (2e-5) for all stages 1–4, but recovery might benefit from a different learning rate than initial multimodal training.

Critical Assessment

Claim: "Nemotron Nano V2 VL achieves leading accuracy on OCRBench v2 private data leaderboard"

The paper states this in the abstract and introduction, but does not provide the OCRBench v2 private leaderboard score anywhere in the paper. Tables 3 and 4 report OCRBench-V2 scores on English (62.0) and Chinese (44.2) subsets, but these are the public benchmark evaluations, not the private leaderboard results. The abstract's claim about "leading accuracy on OCRBench v2 private data leaderboard" is a forward-looking statement (the model was submitted to the leaderboard and achieved a leading position at the time of submission) but is not substantiated with evidence in the paper — no screenshot of the leaderboard, no comparison against leaderboard-ranked models, no mention of the specific score or position. This makes the claim unverifiable from the paper's content alone and reduces it to an assertion rather than a demonstrated result.

Claim: "Substantial improvements over Llama-3.1-Nemotron-Nano-VL-8B"

This claim is clearly supported by Table 4, which shows consistent improvements across all 14 vision benchmarks. The gains range from +1.7 points (OCRBench: 85.6 vs. 83.9) to +11.3 points (Video-MME: 66.0 vs. 54.7). However, the comparison conflates multiple simultaneous changes: a new architecture (hybrid Mamba-Transformer vs. Transformer-only), a larger backbone (12B vs. 8B, though the parameter count comparison is complicated by the hybrid architecture's different efficiency characteristics), expanded training data (8M+ samples vs. an unspecified but presumably smaller predecessor dataset), and an improved training recipe (5 stages vs. an unspecified predecessor recipe). The 11.3-point Video-MME gain cannot be attributed to any single factor — it could be driven primarily by the context extension (16K → 128K), the hybrid architecture's efficiency on long sequences, or the Stage 2 video-specific training data. A FLOPs-matched or parameter-matched comparison against the predecessor would have been more informative but was not conducted.

Claim: "35% higher throughput in long multi-page document understanding scenarios"

This claim appears in Section 1 as a benefit of the hybrid Mamba-Transformer architecture, but no throughput measurements for document understanding scenarios are reported anywhere in the paper. Figure 4 reports video throughput (tokens/second on video benchmarks). The paper does not compare document-processing throughput between Nemotron Nano V2 VL and its predecessor on any document benchmark. The 35% figure is therefore an unsubstantiated claim — it may be derived from the Nemotron Nano V2 technical report's measurements on text-only throughput, but the paper does not reference such measurements or adapt them to the VLM setting where vision token processing dominates the sequence length. This is a significant gap given the claim's prominence.

Claim: "EVS achieves 2× or more throughput improvement with minimal or no impact on accuracy"

This claim is substantiated by Figure 4. At 50% EVS (BF16), throughput increases from 34 tok/s to 65 tok/s (1.9×) with zero accuracy loss on both LongVideoBench and Video-MME. At 75% EVS (BF16), throughput reaches 88 tok/s (2.6×) with accuracy losses of only 0.2 points (LongVideoBench: 63.6 → 63.4, interpolating between 70% and 75% data points) and 0.0 points (Video-MME: 66.0 → 66.1). The "2× or more" claim is accurate and the "minimal or no impact" qualifier is supported — at ratios up to 75%, the accuracy impact is within the noise floor of these benchmarks. At 90%, the throughput gain (3.5×) is accompanied by non-trivial accuracy loss (LongVideoBench: –2.9 points), so the claim's boundaries are well-defined by the data.

However, the measurements are on a single GPU (RTX 6000 PRO SE) with a specific vLLM configuration (128 frames, 30 text ISL, 128 OSL). Throughput ratios may differ on different hardware (H100, A100) or with different input configurations (fewer frames, longer text), so the 2× claim should be understood as an illustrative measurement rather than a guaranteed speedup across all deployment scenarios.

Claim: "Text reasoning capabilities are largely preserved after the multi-stage training pipeline"

This claim is partially supported by Table 6, with important caveats. MATH-500 is essentially fully preserved (97.7 → 96.9, –0.8). GPQA is largely preserved (65.0 → 64.1, –0.9). MMLU-Pro is largely preserved (77.8 → 77.1, –0.7). LiveCodeBench is well-preserved after recovery (70.0 → 69.4, –0.6). However, AIME-25 shows a notable residual gap (75.9 → 71.3, –4.6), RULER shows a moderate residual gap (77.9 → 72.1, –5.8), and IFEval shows a persistent gap (84.2 → 78.2, –6.0 on prompt_strict; 89.3 → 84.7, –4.6 on instruction_strict). SciCode is too low-accuracy to reliably assess (7.5 → 6.9).

The characterization as "largely preserved" is fair for most capabilities but overstates the IFEval and AIME-25 results. A 5–6 point drop on instruction-following and competition math is meaningful — in the context of LLM leaderboards, 5 points on IFEval or AIME can represent months of training improvements or the difference between a top-quartile and median model. The paper's framing of the recovery as a success is justified relative to the post-Stage-1 nadir (where LiveCodeBench was at 50.9), but the residual gaps are not negligible and the paper does not investigate whether they could be closed with more recovery data or different recovery stage configurations.

Claim: "Capped reasoning can outperform unrestricted reasoning"

This claim is well-supported for specific task categories by Figure 3. On document/OCR tasks (3b), capped reasoning at 2K–4K tokens consistently outperforms unrestricted at 16,384 tokens, with TextVQA showing the most dramatic effect (85.4 at budget 0 vs. 76.1 unrestricted, a 9.3-point gap). On video tasks (3c), reasoning-off outperforms unrestricted by 3–6 points. On STEM tasks (3d), unrestricted reasoning is clearly superior, so the claim does not hold universally — the paper is careful to present results by task category rather than making a blanket statement.

However, the paper's explanation — that capped reasoning avoids "malformed reasoning traces with repetition loops on out-of-distribution tasks" and "truncation of overly verbose reasoning chains" — is hypothetical rather than demonstrated. The paper does not analyze the actual reasoning traces to confirm these mechanisms. A qualitative analysis showing examples of degenerate reasoning traces under unrestricted mode vs. clean, concise reasoning under capped mode would substantially strengthen this claim. Without such evidence, alternative explanations are possible: for instance, the temperature 0.6 sampling in reasoning-on mode might simply produce noisier outputs than the greedy decoding used in reasoning-off mode, and the budget cap reduces noise by limiting how many noisy tokens are generated — a statistical rather than mechanistic explanation.

Missing Baselines and Comparisons

Several comparisons that would contextualize the model's performance are absent:

No comparison against proprietary models. GPT-4V, Claude 3.5 Sonnet, Gemini 1.5 Pro, and Grok-1.5V are all capable VLMs that would provide an upper bound on what is achievable. The paper's WildVision win rate of 16.0 (Table 3) implies the model is compared against some reference, but that reference is not specified.
No comparison against the text-only Nemotron Nano V2 (12B) on text benchmarks. While Table 6 shows the Stage 0 frozen backbone scores (representing the original LLM), these are evaluated through the VLM pipeline with vision tokens present (even if the vision encoder is frozen). A direct comparison against the standalone text-only model on identical benchmarks would clarify whether the residual text degradation is due to the visual token processing overhead at inference time or to permanent changes in the model weights.
No comparison against Nemotron Nano V2 VL without reasoning capability. The paper presents reasoning-on as a feature, but does not compare against a version of the model trained without reasoning traces in the data. This would quantify the net benefit of including reasoning chain training data and whether the budget control mechanism is necessary primarily because of artifacts introduced by that training.
No FLOPs-matched comparison against the 8B predecessor. The 35% throughput claim is architecture-specific, but a FLOPs-matched comparison — where both models get equal inference compute budgets and their accuracies are compared — would provide a more rigorous efficiency comparison, particularly on long document and video tasks where the hybrid architecture's asymptotic complexity advantages should be most visible.

Potential Weaknesses in Experimental Design

Single-run evaluations without variance estimates. All benchmark scores in Tables 3–6 and 8 are reported as point estimates without confidence intervals, standard deviations, or information about the number of evaluation runs. The text benchmarks (Table 6) specify the number of runs for Pass@1 averaging (16 for AIME, 4 for MATH-500/GPQA/LiveCodeBench/IFEval, 1 for SciCode/RULER), but the vision benchmarks in Tables 3 and 4 are not described with run counts. Given that reasoning-on mode uses temperature 0.6 and top-p 0.95 (introducing sampling variance), and that some benchmark score changes are small (e.g., 0.2–0.5 point fluctuations between stages in Table 4), the absence of variance information limits confidence in whether these differences are genuine or sampling noise.

Evaluation framework dependence. The paper notes that "minor discrepancies relative to previously reported baselines are attributable to variations in evaluation framework implementations" (Section 4.6). This is a genuine concern: VLMEvalKit vs. native evaluation scripts vs. vLLM backends can produce different scores for the same model on the same benchmark due to differences in prompt formatting, image preprocessing, answer extraction, and grading logic. The paper's reliance on VLMEvalKit for most evaluations and on other models' self-reported scores for comparison creates potential inconsistencies. For example, InternVL3.5's self-reported scores may use a different evaluation framework than Nemotron Nano V2 VL's VLMEvalKit scores, making the comparison less apples-to-apples than it appears. The authors partially address this by independently evaluating some models in VLMEvalKit (marked with *), but this is not done systematically for all benchmarks and all models.

Small sample sizes for some benchmarks. The paper evaluates on benchmarks with varying test set sizes. MMMU (val) has 900 questions; MMMU-Pro has 1,730 questions; OCRBench-V2 has 1,664 questions (English) and 416 questions (Chinese); but some benchmarks like ZeroBench, CRPE, TreeBench, and the MMLU-Pro-1000 subset are smaller. The WildVision win rate is based on human preference judgments, and the sample size and annotator details are not reported in the paper (WildVision is described in Lu et al., 2024b). Small test sets mean that even substantively meaningful accuracy differences may not be statistically distinguishable from noise.

Training data scale not ablated. The paper uses 32.5M samples (112.5B tokens) in Stage 1, 11M samples (55B tokens) in Stage 2, 1M samples (15B tokens) in Stage 3, and 74K samples (12B tokens) in Stage 4. No data scaling ablations are performed. It is unclear whether the 1M code samples in Stage 3 are sufficient or excessive — would 500K samples achieve the same LiveCodeBench recovery? Would 2M samples close the residual 0.6-point gap? Similarly, the 74K long-context samples in Stage 4 might be insufficient for full RULER recovery or might be more than necessary. Without scaling curves, the training recipe is a point solution rather than a principled allocation of training tokens across stages.

OCRBench v2 leaderboard claim is unverifiable from paper content. As noted above, the abstract's claim about OCRBench v2 private leaderboard performance is not supported by data in the paper. The paper reports public OCRBench-V2 scores (62.0 English, 44.2 Chinese in Table 3) but does not provide the private leaderboard score, rank, or comparison against leaderboard competitors. This is the paper's headline contribution claim and its substantiation is absent from the experimental sections.

6. Limitations and Trade-offs

The OCRBench v2 Private Leaderboard Claim Is Unverifiable from the Paper's Reported Results

The assumption or constraint. The abstract and introduction prominently position the model as "achieving leading accuracy on OCRBench v2 private data leaderboard." This is the paper's headline claim — it appears in the opening sentence of the abstract and again in Section 1. However, no private leaderboard score, rank, or comparison against leaderboard competitors appears anywhere in the paper's experimental sections. Tables 3 and 4 report OCRBench-V2 scores on the public benchmark subsets (English: 62.0, Chinese: 44.2 in Table 3 under reasoning-off), but these are standard public evaluations via VLMEvalKit, not the private leaderboard results.

The distinction matters because OCRBench v2 (Fu et al., 2024a) has a private test set whose labels are not publicly available — submissions to the private leaderboard are evaluated by the benchmark organizers and posted to a publicly viewable leaderboard. The paper references the leaderboard URL in a footnote (https://99franklin.github.io/ocrbench_v2/) but does not report what score or rank the model achieved there, nor does it compare against other leaderboard entries. The claim of "leading accuracy" therefore rests on evidence external to the paper — a reader cannot verify it from the paper's content.

The consequence. The abstract's framing establishes OCRBench v2 performance as the primary evidence of the model's document understanding capability. A practitioner deciding whether to adopt Nemotron Nano V2 VL for OCR-heavy applications needs to know: what specific accuracy did it achieve, against which competitors, and is the lead statistically or practically meaningful? Without these details, the headline claim functions as an assertion rather than a demonstrated result. If the private leaderboard score differs substantively from the public benchmark scores reported in the paper (62.0 English, 44.2 Chinese), the model's real-world OCR performance on unseen test distributions might be different from what Tables 3–4 suggest.

The claim also complicates reproducibility: the private leaderboard evaluation uses the benchmark organizers' grading pipeline, which may differ from VLMEvalKit's grading in ways that affect scores. A discrepancy between public and private scores would raise questions about evaluation framework dependence that the paper does not address.

What evidence exists in the paper. None. Sections 4.1 and 4.2 report OCRBench-V2 public scores. Section 4.5 (Table 7) reports OCRBench-V2 scores under alternative image processing strategies. No private leaderboard scores, ranks, or comparisons appear in any table or figure. The paper provides no leaderboard screenshot, no submission ID, and no discussion of private-vs-public score differences.

Mitigation status. The paper does not acknowledge this gap. It is not listed as a limitation, and no explanation is offered for why private leaderboard results are claimed but not reported. This is a significant transparency issue — the paper's most prominent quantitative claim is unverifiable from its own experimental sections. Practitioners evaluating the model for OCR applications should treat the "leading accuracy" claim as provisional until independent verification on the private leaderboard is available, or until the authors publish the specific leaderboard score and comparison context.

The Text Capability Recovery Is Incomplete for Several Important Reasoning Benchmarks

The assumption or constraint. The paper's explicit goal, stated in Table 6's caption and Section 3.2, is "to add vision capabilities with minimal impact to the text reasoning capabilities of the underlying LLM." The multi-stage training recipe — particularly the dedicated code recovery stage (Stage 3) and long-context recovery stage (Stage 4) — is presented as a solution to the catastrophic text degradation observed after Stage 1 multimodal training, where LiveCodeBench dropped from 70.0 to 50.9 and RULER collapsed from 77.9 to 8.8.

The recovery strategy is a genuine methodological contribution (as discussed in Innovation 2), and it succeeds in restoring most capabilities to near-original levels. However, the recovery is incomplete for specific benchmarks, and the paper does not investigate whether the residual gaps can be closed. The final model (Stage 4, reasoning-on) shows persistent deficits compared to the original LLM (Stage 0, which represents the frozen backbone's capabilities):

AIME-25: 71.3 vs. 75.9 original (–4.6 points)
RULER: 72.1 vs. 77.9 original (–5.8 points)
IFEval_prompt_strict: 78.2 vs. 84.2 original (–6.0 points)
IFEval_instruction_strict: 84.7 vs. 89.3 original (–4.6 points)

The consequence. These residual gaps are not negligible in practical terms. On the AIME benchmark (competition-level mathematics), 4.6 points can represent the difference between a top-quartile reasoning model and a median one — in the context of LLM leaderboards, 5 points on AIME is a substantively meaningful capability difference. On IFEval (instruction-following precision), a 6-point drop means the model fails to correctly follow formatting, content, and constraint instructions on roughly 6% more prompts than the original LLM would have. For deployment scenarios that require precise instruction adherence — structured data extraction, formatted output generation, tool-use with strict schemas — this degradation directly impacts usability.

The RULER gap (–5.8 points) is particularly concerning given the paper's emphasis on long-context capabilities. Despite Stage 4's dedicated 300K-context training (74K samples, 12B tokens), the model does not fully recover its original long-context processing ability. A practitioner evaluating the model for long-document summarization or multi-turn dialogue over extended histories would get lower effective context utilization than the original text-only Nemotron Nano V2 — the very backbone the VLM was designed to extend.

What evidence exists in the paper. Table 6 provides the full trajectory, clearly showing the residual gaps at Stage 4 compared to Stage 0. The paper acknowledges the Stage 1 degradation explicitly ("After Stage 1, we see a significant drop in text reasoning benchmarks") but does not discuss the residual gaps after recovery in similar detail. Section 4.2 states that "the final model largely preserves the text reasoning capabilities of the original LLM backbone across most tasks" — "largely" and "most" are accurate qualifiers but obscure the specific benchmarks where preservation is incomplete.

Mitigation status. The paper does not attempt to close these residual gaps. It does not experiment with (a) more recovery data in Stage 3 or 4 to determine whether recovery is saturating or could continue with additional tokens, (b) different learning rates or training configurations for recovery stages, (c) combined recovery stages that mix code and long-context data rather than separating them, or (d) alternative recovery approaches such as elastic weight consolidation or replay-based methods. The paper frames the recovery as successful (which it is, relative to the post-Stage-1 nadir), but does not establish whether the residual gaps are fundamental (capabilities permanently lost to multimodal interference) or correctable (insufficient recovery data). This limits the recipe's generalizability: a team applying this approach to their own VLM training would not know whether to expect similar residual gaps and whether more recovery data would help.

GUI Grounding Performance Is Catastrophically Weak, and the Paper Does Not Analyze Why

The assumption or constraint. The model is evaluated on three GUI grounding benchmarks in Table 3: ScreenSpot, ScreenSpot-v2, and ScreenSpot-Pro. These benchmarks test the ability to localize UI elements (buttons, text fields, icons, menus) on screenshots given natural language instructions — a core capability for building GUI agents that can automate interactions with software interfaces. The training data includes GUI-related datasets (ScreenQA, WaveUI-25K) listed in Stage 1's document/chart/table/GUI QA category, suggesting the authors intended GUI understanding to be within scope.

The consequence. The results reveal a capability gap so large that it constitutes a fundamental exclusion zone for the model:

ScreenSpot: 39.4 vs. 87.5 (InternVL3.5) and 94.4 (Qwen3-VL) — a gap of 48–55 points
ScreenSpot-v2: 41.7 vs. 88.6 (InternVL3.5) — a gap of 47 points
ScreenSpot-Pro: 4.8 vs. 54.6 (Qwen3-VL) — a gap of 50 points, and the model is essentially at chance performance on professional high-resolution computer use

These are not marginal differences where the model is slightly worse — these are deficits indicating the model fundamentally cannot perform GUI grounding at a level comparable to peer VLMs. ScreenSpot-Pro at 4.8 means the model correctly localizes UI elements on fewer than 1 in 20 professional screenshots, making it non-viable for any GUI agent application.

What evidence exists in the paper. Table 3 reports the raw scores alongside InternVL3.5, GLM-4.5V, and Qwen3-VL comparisons. The gap is immediately visible — ScreenSpot is the largest single-benchmark deficit against any competitor in the entire results table. However, the paper provides no discussion, analysis, or acknowledgment of this weakness. There is no mention of GUI grounding deficits in the main text, no ablation investigating whether the tiling strategy or vision encoder design is responsible, and no comparison of GUI-specific training data quantity against InternVL3.5 or Qwen3-VL. The models that excel at ScreenSpot (InternVL3.5 at 87.5, Qwen3-VL at 94.4) presumably have substantially different training data compositions or architectural choices optimized for GUI understanding — the paper does not engage with this discrepancy.

Mitigation status. Completely unaddressed. The paper neither acknowledges the limitation nor proposes future work to improve GUI grounding. For practitioners considering deploying this model in agentic workflows, screen automation, or accessibility applications, this is a hard blocker — the model's GUI capabilities are not "could be improved" but "functionally absent." The inclusion of GUI benchmarks in the evaluation suite suggests the authors were aware of the capability's importance, making the absence of analysis particularly notable. Users evaluating the model for their use case should independently verify GUI grounding performance on their specific interface screenshots before committing to deployment.

The 35% Throughput Claim for Document Understanding Is Unmeasured and Undocumented

The assumption or constraint. Section 1 states that "the hybrid Mamba-Transformer architecture of the LLM offers 35% higher throughput in long multi-page document understanding scenarios" compared to the previous-generation Llama-3.1-Nemotron-Nano-VL-8B. This claim is presented as a key efficiency advantage of the architectural shift from a Transformer-only backbone to the Nemotron Nano V2 hybrid architecture. The mechanism is plausible — Mamba layers process sequences with sub-quadratic complexity, which should improve throughput on the very long token sequences characteristic of multi-page document processing (where visual tokens from many pages plus extracted text can produce sequences of 10K+ tokens).

The consequence. The 35% figure is nowhere supported by measurements reported in the paper. The only throughput and latency measurements in the entire paper are:

Figure 4: video processing throughput (tokens/second) and time-to-first-token (milliseconds) for EVS ablations on LongVideoBench and Video-MME, measured on a single RTX 6000 PRO SE GPU.
EVS is an orthogonal optimization (temporal patch pruning) that is not specific to the Mamba-Transformer architecture — it would improve throughput on a Transformer-only backbone as well.

There are no throughput measurements for document understanding scenarios — no comparison of Nemotron Nano V2 VL against the 8B predecessor on multi-page document benchmarks (e.g., MMLongBench-Doc inference throughput), no measurement of tokens-per-second on document processing workloads, and no specification of the hardware or configuration under which the 35% figure was obtained. The claim may derive from the Nemotron Nano V2 text-only technical report (NVIDIA et al., 2025), but that report measures text-only throughput, not VLM throughput where the vision token preprocessing pipeline (tiling, encoding, projection) dominates the initial computation before the LLM backbone begins processing.

For a practitioner evaluating whether to upgrade from the 8B predecessor to the 12B V2 model, the throughput claim is a key decision factor — if the 12B model processes documents 35% faster while being larger, that changes the cost-performance calculus. Without measurements, this claim is unactionable.

What evidence exists in the paper. None beyond the assertion in Section 1. There is no table, figure, or appendix reporting document-processing throughput for either model. The paper's video throughput measurements (Figure 4) show that the 12B model achieves 34 tok/s on video benchmarks in BF16 (EVS OFF) on an RTX 6000 PRO SE, but there is no comparison point for the 8B predecessor on the same hardware and workload.

Mitigation status. Unaddressed. The paper does not acknowledge the absence of throughput measurements, does not provide a citation to a source where the 35% figure is substantiated, and does not specify the experimental conditions under which the claim holds. This is a significant transparency gap for a claim presented in the introduction as a primary motivation for the architectural choice. Independent benchmarking of document-processing throughput against the predecessor model is necessary before accepting the 35% figure as reliable.

The Evaluation Benchmarks Are Evaluated with Different Modes and Frameworks Across Models, Complicating Fair Comparison

The assumption or constraint. The paper compares Nemotron Nano V2 VL against InternVL3.5, GLM-4.5V, and Qwen3-VL in Table 3. For these external models, the authors state: "Unless otherwise noted, we report the evaluation scores directly from the respective model reports. For benchmarks not covered therein, we independently evaluate the models using VLMEvalKit whenever possible." This means the comparison table mixes two different sources of evaluation scores: (1) self-reported scores from other models' technical reports, which may use different evaluation frameworks, prompt templates, image preprocessing pipelines, and grading scripts, and (2) VLMEvalKit-reproduced scores (marked with * or † in Tables 3 and 5) where the authors ran the competitor model themselves.

The consequence. The mix of self-reported and VLMEvalKit scores creates an uneven comparison surface. For benchmarks where InternVL3.5 reports its own scores and Nemotron Nano V2 VL is evaluated via VLMEvalKit, systematic differences in evaluation methodology — not genuine capability differences — could account for part of the observed gaps. This is a known issue in VLM benchmarking: different evaluation frameworks can produce scores varying by several points for the same model on the same benchmark due to differences in answer parsing (e.g., how exact-match is implemented for free-form text answers), image resizing strategies, prompt formatting conventions, and even subtle differences in how the benchmark dataset is loaded and preprocessed.

The paper acknowledges this issue once, in the context of quantized model evaluations: "Minor discrepancies relative to previously reported baselines are attributable to variations in evaluation framework implementations" (Section 4.6). This caveat applies equally to the main results table but is not reiterated there. A concrete example of the problem: InternVL3.5 reports MMBench V1.1 scores of 83.0*/82.3* with an asterisk indicating they were calculated in VLMEvalKit (Table 3). If those scores had been taken from InternVL3.5's own report (which may use a different evaluation pipeline), they might differ by 1–3 points — enough to change the relative ranking on that benchmark.

For Table 5 (multilingual benchmarks), the paper marks scores reproduced by the authors with * and scores obtained from the InternVL3.5 technical report with †. The MTVQA comparison is particularly concerning: Nemotron Nano V2 VL scores 24.3 (reasoning-off), while InternVL3.5 scores 34.2 and the score is marked with † (from InternVL3.5's report). If InternVL3.5's self-reported MTVQA score overestimates its true VLMEvalKit score by even 3–4 points due to evaluation framework differences (which is within the observed range of such discrepancies in the literature), the 9.9-point lead largely evaporates.

What evidence exists in the paper. The paper provides the asterisk/† notation in Tables 3 and 5, acknowledging which scores come from which source. This is a partial transparency measure — it tells the reader when the comparison is not apples-to-apples, but does not quantify the magnitude of the evaluation framework effect. Section 4.6's mention of "variations in evaluation framework implementations" suggests the authors are aware of the problem. The paper does not report self-evaluations of its own model using InternVL3.5's evaluation pipeline or vice versa, which would be the definitive test of whether score differences are real or framework artifacts.

Mitigation status. Partially addressed through the * and † notation, but not resolved. The paper does not systematically re-evaluate all competitor models in VLMEvalKit for all benchmarks — doing so would have been computationally expensive (it would require running inference on InternVL3.5, GLM-4.5V, and Qwen3-VL across 45 benchmarks) but is the standard for rigorous VLM comparison papers. The authors' decision to rely partially on self-reported scores is a practical compromise, but it weakens the strength of the comparative claims, particularly for benchmarks where the score differences are small (1–3 points) and could plausibly be evaluation noise. A reader comparing Nemotron Nano V2 VL against InternVL3.5 should treat score differences of less than ~3 points as within the uncertainty range of cross-framework comparison, and should focus on larger differences (5+ points) or on benchmarks where both models were evaluated in the same framework.

No Data Scaling Ablations for Recovery Stages Leave the Recipe Underdetermined

The assumption or constraint. The Stage 3 code recovery uses 1 million samples (15 billion tokens), and Stage 4 long-context recovery uses 74,000 samples (12 billion tokens). These specific data quantities are presented as the recipe that successfully recovered LiveCodeBench (50.9 → 69.4) and RULER (21.5 → 72.1). The paper treats these quantities as fixed design choices without exploring whether they are necessary, sufficient, or optimal.

The consequence. A practitioner attempting to replicate this approach on their own VLM training pipeline faces an underdetermined recipe. Several critical questions are unanswered:

Is the recovery saturating? Are the 1M code samples and 74K long-context samples at the point of diminishing returns, or would additional data continue to improve recovery? If recovery is saturating, the residual gaps to the original LLM (AIME-25 –4.6, RULER –5.8, IFEval –6.0) may be fundamental limits of the sequential recovery approach. If recovery is still improving, additional data could close these gaps — and the paper provides no guidance on how much more would be needed.
Is the recovery data quantity excessive? Could 500K code samples achieve the same LiveCodeBench recovery as 1M? Could 30K long-context samples achieve similar RULER recovery as 74K? Without scaling curves, the recipe is a point solution — it works for this specific model and dataset combination but does not provide a principle for how much recovery data to allocate. A team with less training budget needs to know the minimum effective dose; a team with more budget needs to know whether additional investment will continue to pay off.
Does the recovery data composition matter? Stage 3 uses code-only data and primarily recovers LiveCodeBench. Stage 4 uses long-context data and primarily recovers RULER. Would a mixed recovery stage (combining code, long-context, and math data) recover multiple capabilities simultaneously in a single stage, reducing the total number of training stages needed? The paper's sequential separation of recovery by capability is presented as a recipe but not justified through ablation.

What evidence exists in the paper. None. The paper reports the data quantities used (Section 3.4–3.5) and the resulting benchmark recovery (Table 6) but does not experiment with varying the amount of recovery data. The statement that the authors "explored several mitigation strategies that were unsuccessful, including augmenting the SFT stage 1 dataset with additional code reasoning examples" (Section 3.4) provides a negative result about data mixing within Stage 1 but does not address data scaling within the dedicated recovery stages.

Mitigation status. Unaddressed beyond the negative result about Stage 1 data mixing. The paper does not acknowledge the absence of recovery-stage data scaling ablations as a limitation, nor does it suggest future work to characterize the scaling behavior of capability recovery. For the recipe to be generalizable beyond this specific model, future work would need to establish whether the recovery is governed by predictable scaling laws (analogous to neural scaling laws for pretraining) or whether the relationship between recovery data quantity and capability restoration is idiosyncratic and model-specific.

7. Implications and Future Directions

How This Work Changes the Landscape

This paper introduces a diagnostic methodology rather than a single architectural innovation: it reframes VLM training from a monolithic integration problem into a sequence of stages where text capability degradation is tracked, measured, and actively recovered. This is not a paradigm shift in the sense of introducing a new model family or loss function — the architectural components (RADIOv2.5 encoder, Nemotron Nano V2 backbone, MLP projector, multi-stage SFT) are all drawn from prior work. Rather, it is a methodological reframing with diagnostic rigor that changes what VLM developers should measure and report during training.

The conceptual shift is from "hope text capabilities survive" to "expect them to degrade, diagnose which ones break, and treat recovery as a first-class training stage." This may seem like an obvious engineering practice, but the VLM literature has largely not adopted it. Major VLM papers report final benchmark numbers without publishing the intermediate text-only performance trajectory that would reveal how much the backbone LLM's reasoning was damaged. Table 6 — showing LiveCodeBench collapsing from 70.0 to 50.9 after Stage 1, then recovering to 69.4 after Stage 3 — is the kind of measurement that the field has been implicitly avoiding. Making it central to the paper's narrative normalizes transparency about multimodal interference, which should become a standard reporting requirement for VLM papers going forward.

The paper also resolves a latent tension in the VLM training literature between two opposing intuitions: (1) "mix everything together and the model will figure it out" (the de facto approach in many multi-stage recipes where text data is interleaved with vision data during SFT) versus (2) "multimodal training irreversibly damages text capabilities" (a pessimistic view sometimes expressed anecdotally but rarely documented). The paper provides evidence that neither extreme is correct. Mixing everything together does cause severe degradation (LiveCodeBench –19.1, RULER –69.1 after Stage 1), but the damage is reversible through sequential recovery stages, not permanent. The attempted mitigation of adding more code data to Stage 1 failed, while the dedicated Stage 3 succeeded, providing a clear empirical boundary: simultaneous gradient conflict between vision and text tasks cannot be resolved by data reweighting within a single stage — it requires sequential isolation of conflicting objectives. This finding shifts the research conversation from "how do we prevent degradation?" to "how do we efficiently recover from it?" — a more tractable question because recovery can be studied in isolation, without the confounding effects of ongoing vision training.

The paper makes two research directions more attractive:

Capability-specific interference analysis. The differential degradation pattern in Table 6 — math survives (MATH-500: 97.7 → 96.8), code collapses (LiveCodeBench: 70.0 → 50.9), long-context is annihilated (RULER: 77.9 → 8.8) — suggests that multimodal fine-tuning interferes with specific neural circuits in the LLM backbone, not with all capabilities uniformly. Understanding which circuits are vulnerable and why becomes a neuroscience-of-neural-networks question that this paper enables by providing a clear, multi-metric diagnostic dataset. Future work could use activation patching, probing, or mechanistic interpretability to identify the specific layers and attention heads that get overwritten during multimodal training.
Sequential training order as a design space. The paper's success with sequential recovery stages (code, then long context, each without vision data) suggests that training order is a first-class design dimension for multi-capability models — not merely a scheduling convenience. This connects to the broader literature on catastrophic forgetting, elastic weight consolidation, and continual learning, but applied to the specific setting of adding a new modality (vision) to a strong single-modality model. The order in which capabilities are trained, recovered, and re-recovered may matter as much as the data composition of each stage.

The paper makes one research direction less attractive: trying to design the "perfect" multimodal data mixture that simultaneously teaches vision while preserving all text capabilities in a single stage. The failure of Stage 1 code-data augmentation and loss-scaling mitigation (Section 3.4) suggests this is a fundamentally difficult optimization problem that may not have a satisfactory solution within a single-stage framework. Future effort is better spent on characterizing the interference patterns and designing recovery protocols than on fine-tuning data mixture ratios.

Follow-Up Research This Work Enables

Mechanistic interpretability of multimodal interference: which layers and attention heads are overwritten during vision training? The differential degradation pattern in Table 6 (LiveCodeBench and RULER collapse while MATH-500 holds steady) is striking but unexplained. A natural follow-up would use activation patching or causal tracing to identify which specific components of the Nemotron Nano V2 LLM backbone are most modified during Stage 1 multimodal training. Hypothesis: the early layers of the LLM — those closest to the visual token inputs — undergo the largest representational changes as they learn to process interleaved vision tokens, and these early-layer changes disproportionately affect code reasoning (which depends on syntactic pattern recognition) and long-context attention (which depends on positional representations established in early layers), while leaving math reasoning (which may be more distributed across middle and late layers) relatively intact. A strong follow-up would (a) measure per-layer representational similarity (e.g., CKA) between the Stage 0 frozen backbone and the Stage 1 fine-tuned model for text-only inputs, (b) identify layers with low similarity as the likely sites of interference, (c) freeze those layers during Stage 1 training and measure whether the degradation pattern changes, and (d) test whether the recovery in Stages 3–4 corresponds to those same layers returning to their pre-Stage-1 representations.

Scaling laws for capability recovery: how much recovery data is needed to restore a given capability to a target performance level? The paper uses 1M code samples (15B tokens) to recover LiveCodeBench and 74K long-context samples (12B tokens) to recover RULER, with no scaling ablations. A principled follow-up would systematically sweep the amount of recovery data in Stage 3 (e.g., 100K, 250K, 500K, 1M, 2M, 4M code samples) and Stage 4 (e.g., 10K, 25K, 50K, 74K, 150K long-context samples) while measuring recovery on the affected benchmarks. The key questions: (a) Is the recovery curve concave (diminishing returns, suggesting a saturation point beyond which additional data is wasted) or convex (accelerating returns, suggesting the 1M/74K allocations are below the efficient frontier)? (b) Do different capabilities exhibit different recovery scaling exponents? (c) Is the residual gap to the original LLM (e.g., AIME-25 at –4.6, RULER at –5.8) closable with more data, or does it represent a permanent capability loss? Answering these questions would transform the paper's point-solution recipe into a generalizable principle for allocating recovery compute budgets — analogous to how Chinchilla scaling laws guide pretraining data allocation.

Unified vs. separated recovery: can a single recovery stage restore multiple degraded capabilities simultaneously? The paper separates code recovery (Stage 3) and long-context recovery (Stage 4) into distinct stages. This is a design choice, not a demonstrated necessity. A natural follow-up would train a combined recovery stage that mixes code and long-context data (e.g., 50% code, 50% long-context samples, totaling the same or greater token count as Stages 3+4 combined) and measure whether it achieves equivalent or better recovery on both LiveCodeBench and RULER. A positive result (unified recovery works as well or better) would simplify the training recipe. A negative result (unified recovery underperforms separated recovery, even at matched total data) would be equally informative — it would suggest that recovery gradients for different capabilities interfere with each other, just as vision and text gradients interfered in Stage 1, implying that the sequential isolation principle applies recursively. The experiment would also test whether a unified recovery stage could address the IFEval gap (–6.0), which neither Stage 3 nor Stage 4 significantly improved, by including instruction-following data in the recovery mix.

The ScreenSpot deficit: root-cause analysis of catastrophic GUI grounding failure. The 40–55 point gap against InternVL3.5 and Qwen3-VL on ScreenSpot benchmarks (Table 3) is the largest single-benchmark weakness in the paper and is completely undiagnosed. A forensic follow-up would systematically test hypotheses: (a) Data hypothesis: Evaluate whether InternVL3.5 and Qwen3-VL include substantially more or different GUI grounding data (e.g., SeeClick-style grounding data, mobile app screenshots with bounding box annotations) than Nemotron Nano V2 VL's ScreenQA + WaveUI-25K combination. If data quantity/quality explains the gap, fine-tuning Nemotron Nano V2 VL on InternVL3.5's GUI dataset (if available) or SeeClick-style data should close most of the deficit. (b) Architecture hypothesis: Test whether the tiling strategy is ill-suited for GUI screenshots, where UI elements are small, densely packed, and require precise spatial localization. Replace the tiling pipeline with native-resolution encoding (as in Table 7's ablation) and measure ScreenSpot scores. If native resolution significantly improves GUI grounding, the tiling design may be fundamentally incompatible with GUI tasks. (c) Resolution hypothesis: GUI screenshots are typically high-resolution (1920×1080 or higher). Test whether encoding screenshots at higher maximum tile counts (e.g., 24 or 36 tiles instead of the current 12) or at higher per-tile resolution recovers ScreenSpot accuracy, which would indicate that the current 12-tile limit is insufficient to capture the spatial detail needed for UI element localization.

Transferability of the recovery recipe across model families and scales. All results are on a single model (Nemotron Nano V2, 12B, hybrid Mamba-Transformer) with a single vision encoder (RADIOv2.5). The Stage 3→4 recovery recipe may be specific to this architecture or may generalize. A strong follow-up would replicate the key finding — catastrophic text degradation after multimodal SFT followed by successful recovery through sequential text-only fine-tuning — on (a) a pure Transformer VLM of comparable scale (e.g., InternVL3.5-14B or Qwen2.5-VL-7B, training from their open-source checkpoints), (b) a smaller scale (1–3B parameters), and (c) a larger scale (30B+ parameters) if resources permit. The specific question is whether the recovery efficiency (how many recovery tokens are needed per point of benchmark recovery) varies with model scale or architecture. If the hybrid Mamba-Transformer architecture experiences worse initial degradation but better recovery than pure Transformers (a plausible hypothesis given the different attention mechanisms), that would inform architecture selection for VLM training — the choice between hybrid and pure Transformer would depend on whether the deployment prioritizes single-stage simplicity or multi-stage capability preservation.

Reasoning budget control as a test-time compute scaling law for VLMs. Figure 3 shows that optimal reasoning budget varies by task category (2K–4K for General VQA, 12K–unrestricted for STEM, 4K–8K for Document/OCR). This is currently a task-level observation — the paper does not provide a per-example budget selection mechanism. A follow-up could develop a lightweight classifier that predicts, for a given visual question, what reasoning budget would maximize expected accuracy. Features could include: the question text length, the number of visual tokens, the type of benchmark the question is from (as a proxy for task category), or even the model's own internal uncertainty estimates (e.g., entropy of early output tokens). Training such a classifier on the budget sweep results from Figure 3 would yield a compute-optimal test-time scaling policy for VLMs — analogous to the main paper discussed in the prompt's reference example, but applied to reasoning token budgets rather than search-vs-revision allocation. The experiment would measure whether per-example budget selection outperforms both reasoning-off and unrestricted reasoning in aggregate across a mixed task distribution, and whether the gains justify the overhead of the budget classifier.

Practical Applications and Downstream Use Cases

Cost-efficient document processing pipelines with staged inference. Organizations processing large volumes of documents (legal contracts, scientific papers, financial reports) can deploy Nemotron Nano V2 VL with a two-tier inference strategy. For straightforward extraction tasks (e.g., "what is the contract date?" or "list all author affiliations"), reasoning-off mode (greedy decoding, max 1,024 tokens) provides high accuracy at minimal cost — Table 3 shows DocVQA at 94.7 and TextVQA at 85.4 in reasoning-off mode, matching or exceeding reasoning-on performance. For complex reasoning tasks that require multi-step inference across document sections (e.g., "does this contract contain a non-compete clause that would prevent the signatory from working at a competitor for more than 12 months?"), reasoning-on mode at budget 8K–12K provides the accuracy benefit of extended chain-of-thought without the cost and error-proneness of unrestricted 16K-token generation — Figure 3b shows DocVQA and InfoVQA peaking at budget 4K–12K, with unrestricted mode providing no additional benefit. The practical gain is a ~50–75% reduction in output tokens for complex queries compared to naïve reasoning-on deployment, translating directly to lower inference costs and reduced latency.

Video analytics at scale with EVS adaptive quality. Video understanding deployments (security footage review, educational content indexing, sports analytics) face a fundamental tension between processing frame rate and inference cost. Figure 4 shows that at 75% EVS ratio (BF16), Video-MME accuracy remains at 66.1 (vs. 66.0 baseline) while throughput triples from 34 to 88 tok/s and time-to-first-token drops from 4,131 to 2,072 ms. This enables a practical adaptive-quality pipeline: start with aggressive EVS (75–80%) for initial video triage (e.g., "does this 2-hour lecture contain any discussion of Fourier analysis?"), and only fall back to lower EVS ratios or full-frame processing for segments that the triage stage flags as potentially relevant. The 2.6× throughput improvement at 75% EVS means that triage can process a video library in roughly one-third the time (or one-third the GPU cost) compared to full-frame encoding, with minimal risk of missing relevant segments — the accuracy loss at 75% is within 0.4 points on Video-MME.

On-device or edge deployment via NVFP4-QAD quantization. For deployment scenarios with tight memory or bandwidth constraints — mobile devices, edge servers, or embedded systems — the NVFP4-QAD checkpoint in Table 8 demonstrates that 4-bit quantization recovers within 0.07–0.27 points of BF16 accuracy on most benchmarks, compared to NVFP4-PTQ which loses 0.84–1.84 points. The practical implication is that a 12B model can be served with roughly half the GPU memory of its BF16 counterpart (4-bit weights vs. 16-bit weights) while maintaining document understanding quality suitable for production use. The DocVQA-val score of 93.95 (vs. 94.22 BF16, a 0.27-point gap) means the quantized model is still practical for document QA applications. The additional QAD training cost (one fine-tuning stage with distillation, approximately 3.5 hours on 64 H100 nodes if scaled proportionally from Stage 3's 3.5 hours for 15B tokens) is a one-time expense amortized over every inference query served — a favorable tradeoff for any deployment serving more than a few million tokens.

Self-improvement data generation pipelines that preserve text quality. When using VLMs to generate training data for themselves or smaller models (e.g., distilling document understanding capabilities), the generator model's text reasoning quality directly affects downstream data quality. The paper's finding that naïve multimodal training degrades code and long-context reasoning (Stage 1: LiveCodeBench 70.0 → 50.9, RULER 77.9 → 8.8) implies that data generated by a VLM trained without text recovery stages would be systematically lower-quality for tasks requiring logical analysis of extracted text — a legal document summarizer fine-tuned on such data might produce grammatically correct but logically flawed summaries. The explicit recovery recipe (Stages 3–4) provides a concrete protocol for data generation teams: do NOT use the Stage 1 or Stage 2 checkpoint for generating reasoning-heavy training data. Use the Stage 4 checkpoint (which has recovered LiveCodeBench to 69.4 and RULER to 72.1), and evaluate the generated data's quality on text reasoning benchmarks before using it for downstream fine-tuning. The recipe also suggests that data generation pipelines should track text benchmark scores through their own fine-tuning stages, rather than assuming final output quality is monotonic with training progress.

When to Prefer This Method

The paper does not present a clear tradeoff between named alternative methods or architectures in a way that yields a structured decision rule. It positions itself as an evolution of the Eagle (Li et al., 2025b; Chen et al., 2025a) multi-stage training paradigm, but does not provide ablations comparing its recovery-stage recipe against, for example, an InternVL-style (Chen et al., 2024d) training pipeline or a LLaVA-style (Liu et al., 2024b) approach with the same total token budget. The external comparisons in Table 3 are against final models with different architectures, training data compositions, and parameter counts — they do not isolate the effect of the multi-stage recovery recipe specifically. Without such an ablation (e.g., training Nemotron Nano V2 VL with all 32.5M Stage 1 samples plus recovery data combined into a single long stage, compared against the sequential five-stage recipe), there is insufficient evidence to articulate a conditional preference rule grounded in the paper's own experiments.

However, the paper's diagnostics do imply a practical heuristic for VLM development teams: if your backbone LLM has strong code or long-context capabilities that are central to your use case, budget for dedicated recovery stages rather than relying on data mixture tuning within multimodal training. The negative result in Section 3.4 — adding code data to Stage 1 did not prevent LiveCodeBench degradation — provides negative evidence against the single-stage approach, while the positive result in Stage 3 — code-only recovery restored LiveCodeBench from 55.0 to 69.4 — provides positive evidence for sequential recovery. The specific heuristic is not a formal decision rule but a risk-management guideline: allocate 10–20% of your SFT compute budget to text-only recovery stages if preserving code or long-context reasoning is important to your downstream application. The paper's allocation was 1M code samples / 15B tokens + 74K long-context samples / 12B tokens out of a total ~219.5B tokens across all stages (~12% of total tokens), which serves as a rough reference point for similar-scale models.

🎯 Pitch

1. Executive Summary

2. Context and Motivation

The Core Problem: Training VLMs That Excel at Document and Video Understanding Without Sacrificing Text Reasoning

Why Existing VLM Training Approaches Fall Short

How This Paper Positions Itself

3. Technical Approach

3.1 Reader Orientation

3.2 Big-Picture Architecture (Diagram in Words)

3.3 Roadmap for the Deep Dive

3.4 Detailed, Sentence-Based Technical Breakdown

Vision Preprocessing Pipeline: From Pixels to Visual Tokens

Stage 0: Vision-Language Alignment via MLP Warm-Up

Stage 1: Broad Multimodal Supervised Fine-Tuning at 16K Context

Stage 2: Context Extension to 49K for Video and Multi-Image Understanding

Stage 3: Code Reasoning Recovery at 49K Context

Stage 4: Ultra-Long Context Extension to 300K

Training Infrastructure and Optimization Techniques

Inference-Time Mechanisms: Reasoning Budget Control

Image Processing Ablation: Tiling vs. Native Resolution

Quantization for Deployment: PTQ vs. QAD

4. Key Insights and Innovations

Innovation 1: Text Capability Degradation as a First-Class Diagnostic, Not an Afterthought

Innovation 2: Sequential Capability Recovery as a Training Paradigm

Innovation 3: Reasoning Budget Control as a Task-Specific Accuracy Optimizer

Innovation 4: Honest Ablation as a Contribution to Architectural Understanding

5. Experimental Analysis

Evaluation Methodology

Main Quantitative Results

Multimodal Benchmark Comparisons Against Internal Predecessor

Multimodal Benchmark Comparisons Against External SOTA Models

Text-Only Capability Trajectory Across Training Stages

Reasoning Budget Control Experiments

Efficient Video Sampling (EVS) Ablation

Image Processing Ablation: Tiling vs. Native Resolution

Quantization Results

Ablation Studies and Robustness Checks

Critical Assessment

Claim: "Nemotron Nano V2 VL achieves leading accuracy on OCRBench v2 private data leaderboard"

Claim: "Substantial improvements over Llama-3.1-Nemotron-Nano-VL-8B"

Claim: "35% higher throughput in long multi-page document understanding scenarios"

Claim: "EVS achieves 2× or more throughput improvement with minimal or no impact on accuracy"

Claim: "Text reasoning capabilities are largely preserved after the multi-stage training pipeline"

Claim: "Capped reasoning can outperform unrestricted reasoning"

Missing Baselines and Comparisons

Potential Weaknesses in Experimental Design

6. Limitations and Trade-offs

The OCRBench v2 Private Leaderboard Claim Is Unverifiable from the Paper's Reported Results

The Text Capability Recovery Is Incomplete for Several Important Reasoning Benchmarks

GUI Grounding Performance Is Catastrophically Weak, and the Paper Does Not Analyze Why

The 35% Throughput Claim for Document Understanding Is Unmeasured and Undocumented

The Evaluation Benchmarks Are Evaluated with Different Modes and Frameworks Across Models, Complicating Fair Comparison

No Data Scaling Ablations for Recovery Stages Leave the Recipe Underdetermined

7. Implications and Future Directions

How This Work Changes the Landscape

Follow-Up Research This Work Enables

Practical Applications and Downstream Use Cases

When to Prefer This Method

Adjacent in domain

MME-CC: A Challenging Multi-Modal Evaluation Benchmark of Cognitive Capacity

VADER: Towards Causal Video Anomaly Understanding with Relation-Aware Large Language Models