在开源模型的世界里，下载权重从来不等于能用。一个 120B 参数、249GB 检查点的视觉 - 语言模型摆在 Hugging Face 上，只是故事的起点；真正拦住企业的，是推理成本、部署复杂度和精度损失之间的三角博弈。英伟达和亚马逊给出的新解法是：把 Nemotron 3.5 Super VL 直接放进 Amazon SageMaker JumpStart，让企业用几步点击或几行 SDK 代码就能把它调起来。
现象：一次上架，两个变体，一套新默认值
AWS 官方博客宣布，NVIDIA Nemotron 3.5 Super VL 正式登陆 SageMaker JumpStart。这是 Nemotron 3.5 家族里的视觉 - 语言模型（VLM），吃进去的是图像、视频和文本，吐出来的是文本。
JumpStart 给了两个版本。NVFP4 是量化版，检查点约 75GB，跑在 ml.g7.24xlarge（默认）和 ml.g7.48xlarge 上，底层是 NVIDIA RTX PRO 4500 Blackwell Server Edition GPU；BF16 是全精度参考权重，检查点约 249GB，跑在 ml.p5en.48xlarge 上，底层是 NVIDIA H200。同一个模型，两种进入企业的路径：前者为推理优化，后者为 SFT、RL、蒸馏、领域适配和自定义量化留足空间。
更有意思的是精度账。按 NVIDIA 模型卡的数据（推理模式开启），NVFP4 在 MMLongBench-Doc 长文档理解上与 BF16 完全持平，都是 62.82 分；在 OCRBench v2 上 68.34 对 68.12，在 OSWorld-Verified 视觉 agent 任务上 52.30 对 51.14，量化版反而略高；CharXiv 图表推理 79.88 对 80.82，Video-MME v2 视频理解 32.54 对 32.85，差距都在 1 分以内。检查点体积从 249GB 压到 75GB，降幅约七成，精度损失却几乎可以忽略。
120B 总参数、12B 激活，纸面数字和真实体验是两回事
Super VL 的骨架是混合架构：交错的 Mamba-2、MoE 专家混合层和注意力层，配上独立的 C-RADIO 视觉编码器。120B 是总参数，每生成一个 token 只激活 12B。这套设计的目的很直白：把大模型的推理成本打下来。
但真正决定体验的不是模型卡上的数字，而是云端的 serving 配置。模型支持最高 100 万 token 的上下文，JumpStart 的 serving 配置实际只开放 520 到 15,600 token。模型内置了 Multi-Token Prediction（MTP）头，原生支持投机解码，JumpStart 的 serving 配置里却没有启用。纸面参数负责吸引眼球，serving 配置才决定你实际买到什么。这对所有盯着“开源即免费”的企业都是提醒：上云之前，先看默认配置。
量化不再是妥协，而是默认选项
过去企业面对大模型，总要在“全精度但贵得离谱”和“量化但怕精度崩”之间选。Nemotron 3.5 Super VL 的 NVFP4 给出第三种答案：用量化感知蒸馏从 BF16 量化而来，在五个关键基准上把差距压在 1 分以内，个别项目还能反超。
这不是偶然的精度运气。量化感知蒸馏意味着量化过程被纳入训练目标，模型在压缩前就“学会”了低精度表示。当 75GB 的检查点能在 RTX PRO 4500 Blackwell 这种单槽、低功耗的数据中心 GPU 上跑起来，部署的经济学就变了。企业不必一上来就押注 H200 集群，可以先用 G7 实例验证业务闭环，再决定要不要上全精度做定制。
半秒首 token 的背后，长文档延迟是另一道题
AWS 用 JumpStart 发布容器测了一组数据：250 输入 token、1500 输出 token、5 个并发流式请求。ml.g7.24xlarge 上的 NVFP4 每请求输出吞吐 63.07 tokens/秒，首 token 时间 0.45 秒；ml.g7.48xlarge 上 64.01 tokens/秒、0.51 秒；ml.p5en.48xlarge 上的 BF16 达到 140.85 tokens/秒、0.53 秒。短请求场景下，首 token 时间都压在 0.5 秒左右，体验接近。
但 AWS 也特意说明，这些测量不是孤立的 BF16 对 NVFP4 精度对比，因为变体跑在不同的 GPU 系统和配置上。更值得玩味的数字藏在长 prompt 里：切换到 summarize 配置（10,000 输入 token），ml.g7.24xlarge 的首 token 时间跳到 12.62 秒。Super VL 主打的正是文档智能和长上下文理解。当你的输入真的很长，延迟会成倍放大。这不是缺陷，而是选型时必须算进去的账。
为 agent 而生，不是为聊天而生
英伟达对这款模型的定位很清晰：文档智能、GUI 理解（面向 computer-use agents）、视频问答、多模态 agent 应用。它支持 7 种语言，包括中文、英文、法文、德文、意大利文、日文和西班牙文；推理模式可以通过 enable_thinking 按请求开关；输出支持 tool calling 和 JSON schema。
换句话说，Super VL 要做的不是陪你聊天，而是替你看文档、读图表、操作界面、理解视频，然后调用工具把事办完。这正是“能看会读会动手”的 agent 基座该有的样子。
结论：开源模型的下一战，在云厂商的部署按钮上
对 AWS 来说，JumpStart 的模型库又多了一枚重炮。企业客户不用再自己折腾 vLLM 或 TensorRT-LLM 的部署细节，模型、量化版本、实例配置一起打包好，点几下就能跑。
对英伟达来说，这是把开源模型生态推向企业最后一公里的打法。权重开放只是第一步，真正的渗透发生在云厂商的一键部署入口里。当开发者习惯在 SageMaker 里选 Nemotron，NVIDIA 的 NIM 生态就顺着这条管道流进了企业生产环境。
对开发者而言，选择变得简单：日常推理用 NVFP4，精度几乎不打折，成本却低一大截；只有当你要做 SFT、RL、蒸馏或自定义量化时，才需要搬出 249GB 的 BF16 全精度版本。
当然也有需要留意的地方。模型采用 OpenMDW 许可证协议 1.1 版，企业商用前需要法务确认条款；长上下文场景的首 token 延迟需要按业务场景实测；基准成绩由 NVIDIA 自行报告，第三方复现仍有空间。
开源模型的竞争，正在从“谁的权重更开放”变成“谁的一键部署更好用”。当 120B 的模型也能被几行代码调起来，真正的护城河就不再是参数规模，而是谁能把部署的摩擦力磨到最薄。
快报