NVIDIA Nemotron 3.5 Super VL Comes to JumpStart | Zeniteq
Loading
Loading article
Zeniteq is now available on mobile for iPhone, iPad and Apple Watch.Download nowLearn more
NVIDIA Nemotron 3.5 Super VL Comes to JumpStart
AWS adds managed deployment for NVIDIA’s multimodal model, with a smaller NVFP4 default, BF16 reference weights and serving limits worth checking before launch.
AWS has integrated NVIDIA’s Nemotron 3.5 Super VL multimodal model into Amazon SageMaker JumpStart, offering both NVFP4 and BF16 variants. The NVFP4 default, optimized for inference, significantly reduces checkpoint size to 75 GB compared to 249 GB for BF16. While NVFP4 matches performance on most benchmarks, developers building browser-based agents should note a substantial 11-point accuracy gap in WebVoyager testing. Furthermore, users must account for strict context window limits of 15,600 tokens, which are far smaller than the model's theoretical million-token capacity, necessitating careful strategies for processing long documents or video sequences.
AWS announced NVIDIA Nemotron 3.5 Super VL in Amazon SageMaker JumpStart on November 9, 2026. AWS users can deploy the vision-language model through SageMaker Studio or the SageMaker Python SDK, choosing between NVFP4 and BF16 variants with different checkpoint sizes and supported instance types.
The announcement adds an AWS deployment option for an existing model. NVIDIA originally released Super VL on October 15, 2026, targeting workflows that combine text, images, documents, video and tool use.
The consequential detail in AWS’s announcement is the default: NVFP4. Its checkpoint is about 75 GB, compared with roughly 249 GB for BF16. NVIDIA’s published results show closely matched scores on several multimodal tests, although a larger gap on an offline web-navigation benchmark gives agent developers a reason to compare both.
Two Variants With Different Deployment Footprints
Super VL accepts text, images and video, then generates text. Its outputs can include tool calls and schema-constrained JSON, making it relevant to document extraction, screen-reading agents and video question answering.
AWS lists these configurations:
Detail
NVFP4
BF16
Parameters
120 billion total, 12 billion active per token
Same
Approximate checkpoint size
75 GB
249 GB
JumpStart instances
ml.g7.24xlarge by default; also ml.g7.48xlarge
ml.p5en.48xlarge
Primary role
Optimized inference
Reference weights for customization
JumpStart LoRA adapter serving
Not supported
Not supported
Both variants use the OpenMDW License Agreement, version 1.1. BF16 is the full-precision reference in this comparison: its core numerical format is 16-bit brain floating point, not 32-bit floating point.
The 12-billion-active figure describes how much of the model participates in processing each token. It does not make this equivalent to deploying a dense 12-billion-parameter model. The complete model still has 120 billion parameters, and AWS specifies substantial instances for both variants.
I’d treat NVFP4 as the sensible starting point for an inference evaluation. The checkpoint is about 3.3 times smaller, and AWS provides a different hardware deployment path for it. Production suitability still depends on accuracy, response time and capacity under the intended workload.
What NVFP4 Changes, and What It Leaves Alone
NVIDIA produces NVFP4 from BF16 using quantization-aware distillation. AWS describes four-bit weights and activations, abbreviated W4A4, running on Blackwell GPUs.
The conversion is mixed precision. The C-RADIO vision encoder, vision-language connector, Mamba convolutions and embeddings remain in BF16; the mixture-of-experts router remains in FP32. The vision encoder processes images and sampled video frames, while the connector maps that visual information into the language backbone.
Keeping those components at higher precision avoids quantizing every stage of the visual pipeline. It is a design choice, not a guarantee that every visual task retains identical accuracy. The benchmark comparison provides the more useful evidence.
The NVIDIA model card describes a hybrid backbone combining Mamba-2, attention and mixture-of-experts layers. Its MoE layers have 512 routed experts, with 22 active per token. That selective activation helps explain the difference between total and active parameter counts.
The checkpoint reduction is approximately 70%, calculated from AWS’s 249 GB and 75 GB figures. That is a storage-size comparison. It cannot be translated directly into a 70% reduction in GPU memory use, latency or cloud spending: runtime memory also supports activations, request processing and other serving requirements.
Published Benchmarks Show a Mostly Close Comparison
AWS highlights five multimodal benchmarks with reasoning enabled. NVIDIA’s model card also reports an offline WebVoyager comparison relevant to browser agents.
Benchmark
BF16
NVFP4
NVFP4 difference
MMLongBench-Doc
62.82
62.82
0.00
OCRBench v2, English
68.12
68.34
+0.22
CharXiv reasoning
80.82
79.88
−0.94
Video-MME v2
32.85
32.54
−0.31
OSWorld-Verified
51.14
52.30
+1.16
WebVoyager, offline
77.72
66.31
−11.41
These are vendor-published scores from AWS’s comparison and NVIDIA’s model card, not independent measurements. The first five rows use the reasoning-on conditions identified by AWS; WebVoyager is explicitly an offline evaluation in NVIDIA’s table.
NVFP4 matches BF16 on the long-document test and scores slightly higher on English OCR and OSWorld-Verified. BF16 leads slightly on chart reasoning and video understanding. Those results support starting with the smaller checkpoint, but they do not show that quantization improves reliability generally.
The 11.41-point WebVoyager gap deserves attention from teams building browser agents. It is much larger than the differences in AWS’s highlighted multimodal results. OSWorld-Verified and WebVoyager measure different tasks, so a higher score on one cannot cancel out a lower score on the other.
My reading is that NVFP4 has a strong deployment-efficiency case, while web-navigation quality remains a workload-specific decision. A representative browser-task evaluation would be more useful than choosing solely from the headline benchmark table.
How to Approach a JumpStart Deployment
AWS supports two entry points: SageMaker Studio for an interactive deployment and the SageMaker Python SDK for a programmatic workflow.
A practical deployment sequence is:
Find NVIDIA Nemotron 3.5 Super VL in JumpStart. Choose NVFP4 for the optimized inference checkpoint or BF16 when the reference build is required.
Match the instance to the variant. AWS lists ml.g7.24xlarge and ml.g7.48xlarge for NVFP4, and ml.p5en.48xlarge for BF16.
Evaluate representative requests against the endpoint. Include realistic images, output lengths, tool results and conversation history, not only short text prompts.
Reasoning is enabled by default and configurable through enable_thinking. Structured output is supported through response_format. These controls matter for different application needs: a field-extraction pipeline may prioritize predictable JSON, while a troubleshooting agent may need more reasoning and tool interaction.
Two advertised model capabilities require a separate serving check. Super VL contains a built-in Multi-Token Prediction head for speculative decoding, but AWS says speculative decoding is not enabled in the JumpStart serving configuration. Neither variant loads LoRA adapters through this endpoint.
BF16 reference weights are available for supervised fine-tuning, reinforcement learning, distillation, domain adaptation and custom quantization. That customization work needs its own training and deployment plan; selecting BF16 in JumpStart does not turn the base-model endpoint into an adapter-serving service.
The Context Window Is the Main Workload Constraint
NVIDIA specifies a model context capacity of up to one million tokens. AWS’s published JumpStart serving configurations use 520 to 15,600 tokens.
That distinction affects application design. The model’s maximum capacity is not the context budget available in the configurations described by AWS. NVIDIA also specifies that prompts, visual inputs, conversation history, tool results and generated output share the configured window.
Documents Need More Than an OCR Score
AWS estimates that a 1,536 × 1,024-pixel page image consumes about 1,536 context tokens. A page therefore occupies a meaningful portion of a 15,600-token configuration before instructions and output are included.
The JumpStart configuration accepts one image and one video per request. Multipage document processing consequently needs an explicit strategy, such as page-by-page calls followed by aggregation. The one-million-token model specification should not be read as permission to send an entire document collection to this endpoint unchanged.
For document extraction, I’d evaluate field accuracy and consistency across pages alongside OCR quality. Correctly reading individual words is only one part of reconstructing a table or associating a value with the right heading.
GUI Agents Still Need an Execution Layer
Super VL targets screen grounding and reasoning for computer-use agents. It can interpret a screenshot and produce text or tool calls.
The surrounding application still needs to execute actions, capture updated screens, maintain state and enforce permissions. Tool calling provides a model interface for that loop; it does not supply the complete computer-control system.
Video Requests Have Payload Limits
AWS describes short MP4 analysis and question answering, including inline base64-encoded video. Endpoint request-size limits still apply.
The model’s vision encoder processes sampled video frames, so clip selection and frame sampling affect what visual evidence reaches the model. Teams should check that important events survive that preprocessing, particularly when a question concerns a brief action.
Pricing Needs a Separate Check
The reviewed announcement does not fully establish regional availability or endpoint pricing. Those details need checking before committing capacity.
The smaller NVFP4 checkpoint and different instance mapping are useful deployment facts, but they do not establish a specific hourly or per-token saving. A meaningful AI pricing comparison needs the actual instance rate, achieved throughput, utilization and acceptable response time.
NVFP4 is the better-supported first candidate for a standard inference evaluation. BF16 remains valuable for reference comparisons and customization work. Browser-agent teams have an additional reason to retain both in their evaluation plan: NVIDIA’s offline WebVoyager result shows that near-parity on several visual benchmarks can coexist with a substantial difference on another task.
Frequently Asked Questions
4 questions
1
Is This a New NVIDIA Model Release?
No. NVIDIA released Nemotron 3.5 Super VL on October 15, 2026. The November 9 announcement adds deployment through Amazon SageMaker JumpStart.
2
Which Variant Is the JumpStart Default?
NVFP4 is the default. Its checkpoint is approximately 75 GB, compared with 249 GB for BF16, and its default instance is ml.g7.24xlarge.
3
Does JumpStart Provide the Full Million-Token Context?
AWS’s published serving configurations use 520 to 15,600 tokens. The one-million-token figure describes the model’s supported maximum, not those deployment configurations.
4
Can the Endpoint Load LoRA Adapters?
No. AWS says the JumpStart endpoint serves the base weights without LoRA adapters. Customizing the BF16 reference weights requires a separate workflow.
