Что такое Nemotron 3.5 Super VL и зачем ей JumpStart
NVIDIA Nemotron 3.5 Super VL это мультимодальная vision-language модель на 120 млрд параметров, из которых на каждом токене активны 12 млрд. На вход она принимает текст, изображения и видео, на выходе даёт текст. В Amazon SageMaker JumpStart модель доступна в двух вариантах: квантованный NVFP4 и полноточный BF16. Об этом сообщает блог AWS Machine Learning.
Практический смысл: 120-миллиардную VLM можно поднять за несколько шагов в SageMaker Studio или несколькими строками SageMaker Python SDK, без сборки контейнера и поиска весов. NVIDIA строила модель под документный интеллект, понимание GUI для computer-use агентов, видео-QA и мультимодальные агентные приложения. Эта рамка задаёт и статью.
Дальше по порядку: что внутри, как выбрать вариант и инстанс, как задеплоить через Studio и SDK, как передать картинку или видео, как управлять reasoning, что известно про бенчмарки, где модель полезна и где упирается в ограничения. Если вам нужен текстовый чат, 120B VLM на дорогом инстансе вам не нужна.
Ключевые характеристики в одном экране
- 120 млрд параметров всего, 12 млрд активных на токен.
- Языковой бэкбон: гибридный MoE, 88 слоёв с чередованием Mamba-2 и MoE-слоёв, 512 routed experts, 22 активных эксперта на токен, 8 attention-слоёв.
- Визуальная часть: C-RADIO vision encoder плюс vision-language коннектор, который отображает эмбеддинги в пространство языкового бэкбона.
- Вход: текст, изображения, сэмплированные кадры видео. Выход: текст.
- Контекст до 1 млн токенов на уровне модели. Конкретный лимит в JumpStart зависит от параметров деплоя, его видно в консоли при выборе конфигурации.
- Встроенная MTP-голова (Multi-Token Prediction), которая поддерживает спекулятивное декодирование.
- Reasoning настраивается на уровне отдельного запроса.
- Два варианта в JumpStart: NVFP4 и BF16.
Почему это важно для тех, кто работает в AWS
Самостоятельный запуск 120B VLM означает сборку окружения, подбор совместимых весов, настройку сервера инференса и отладку kv-cache на длинном контексте. JumpStart убирает эту часть: модель лежит в каталоге как готовый деплой, а endpoint поднимается из Studio или SDK. Выбор варианта весов и типа инстанса остаётся за вами, и это главное решение, которое влияет на латентность, стоимость и возможность дообучения.
JumpStart не единственный путь. Собственный inference-стек с vLLM, NVIDIA NIM или локальный запуск на своём железе остаются вариантами, особенно когда нужен полный контроль над версиями рантайма и параметрами сэмплинга. Здесь разбираем именно управляемый деплой в SageMaker.
Архитектура: гибридный MoE, C-RADIO и MTP-голова
Языковой бэкбон собран из 88 слоёв, которые чередуют Mamba-2 и MoE. В MoE-слоях 512 routed experts, из них 22 активируются на каждый токен, плюс 8 attention-слоёв и общая MTP-голова. Бэкбон инициализирован из Nemotron 3 Super Base и дистиллирован из Nemotron 3 Ultra Base. Проще говоря, модель унаследовала знания более крупного учителя, но получила собственную, более компактную по вычислениям структуру.
Комбинация даёт два эффекта. MoE разводит общий объём параметров (120 млрд) и вычисления на токен (12 млрд): считать приходится примерно как среднюю модель, а хранить в памяти как крупную. Mamba-2 обрабатывает длинные последовательности дешевле, чем плотное внимание, и на 88 слоёв приходится всего 8 attention-слоёв. Для документов на сотни страниц и видео с десятками кадров это прямо влияет на стоимость запроса.
Визуальная ветка: C-RADIO кодирует изображения и сэмплированные кадры видео, коннектор переводит результат в пространство эмбеддингов языкового бэкбона. В обоих вариантах, NVFP4 и BF16, энкодер и коннектор остаются в BF16. Визуальная часть не квантуется, и это заметная деталь, к ней вернёмся в разделе про выбор варианта.
MTP-голова обучена предсказывать несколько токенов вперёд и умеет ускорять генерацию через спекулятивное декодирование. Важная оговорка: включение этого режима в конфигурации JumpStart в материалах релиза не описано, поэтому рассчитывать на ускорение из коробки не стоит. Подробности в разделе ограничений.
Как модель обучали: от continued pre-training до RL
Пайплайн обучения выглядит так: continued pre-training, затем long-context и software-engineering mid-training, затем vision-language training. После этого двухэтапный мультимодальный supervised fine-tuning, reinforcement learning с верифицируемыми наградами и человеческой обратной связью в NeMo RL и NeMo Gym, multi-teacher on-policy дистилляция и финальный этап дообучения MTP-головы. Источник: анонс в блоге AWS.
Отдельный этап software-engineering mid-training объясняет, почему NVIDIA продвигает модель для GUI-понимания и computer-use сценариев: работа с интерфейсами и кодом требует похожих навыков, а именно чтения структурированных визуальных паттернов и планирования последовательности действий.
Что даёт контекст до 1 млн токенов на практике
Длинный контекст нужен там, где на вход подаётся много визуальной информации: договор на 200 страниц, набор скриншотов сессии, длинная запись экрана. Видео при этом не идёт потоком: C-RADIO кодирует отдельные кадры, поэтому число кадров напрямую определяет длину контекста, латентность и стоимость запроса. Практическое правило простое: для общего описания видео хватает редких кадров, для вопросов про динамику действий нужны частые.
Один миллион токенов это потолок модели, а не бесплатная опция. При деплое длина контекста задаётся конфигурацией и влияет на потребление памяти; начинайте с размера, который реально нужен вашей задаче. Полные настройки контекста для JumpStart-обслуживания в доступных материалах не приведены: сверяйте их в карточке модели и консоли на момент деплоя.
NVFP4 или BF16: какой вариант и инстанс выбрать
NVFP4 получен из BF16 с помощью NVIDIA Model Optimizer и quantization-aware дистилляции. Это 4-битные веса и активации (W4A4) на GPU Blackwell. Назначение варианта: инференс с упором на латентность и пропускную способность. BF16 это полноточные референсные веса для кастомизации: SFT, RL, дистилляция, доменная адаптация и собственная квантизация.
Привязку конкретных типов инстансов к вариантам (например, G7 с RTX PRO 4500 Blackwell для NVFP4 и ml.p5en.48xlarge с NVIDIA H200 для BF16) доступные источники не подтверждают. В материалах модели перечислены другие варианты железа: DGX Spark, RTX PRO 6000, H200, 2× H100, GB200. Поэтому тип инстанса и его наличие в вашем регионе проверяйте в консоли JumpStart на момент деплоя: AWS обновляет каталог, и доступность меняется. Общий разбор того, как NVFP4 и спекулятивное декодирование ведут себя в реальных замерах, есть в отдельном материале AI-Manual.
Сравнительная таблица вариантов
| Параметр | NVFP4 | BF16 |
|---|---|---|
| Точность языкового бэкбона | 4-битные веса и активации (W4A4) | Полная точность BF16 |
| Железо | GPU Blackwell; конкретные типы инстансов JumpStart в источниках не подтверждены | Полноточные веса; конкретные типы инстансов JumpStart в источниках не подтверждены |
| Назначение | Быстрый инференс: латентность и пропускная способность | Референсные веса для SFT, RL, дистилляции, доменной адаптации, кастомной квантизации |
| Что остаётся в BF16 | Vision encoder, коннектор, Mamba-свёртки, эмбеддинги | Всё |
| MoE-роутер | FP32 | BF16 |
| Публичные замеры пропускной способности для JumpStart | В доступных материалах нет | В доступных материалах нет |
Конкретных чисел пропускной способности и латентности для JumpStart-конфигураций в доступном источнике нет. Любые обещания в духе «в N раз быстрее» проверяйте на своём профиле запросов: длина контекста, доля визуальных входов и размер батча меняют картину сильнее, чем сама квантизация.
Что именно квантуется, а что нет
Квантование не тотальное. Vision encoder и коннектор остаются в BF16, поэтому извлечение текста со скриншотов и разбор таблиц не проходят через 4-битное сжатие. MoE-роутер хранится в FP32: маршрутизация по 512 экспертам остаётся стабильной, а роутер как раз чувствителен к потере точности. Mamba-свёртки и эмбеддинги тоже в BF16.
Под 4 бита уходят веса и активации языкового бэкбона (W4A4). Именно там сосредоточены основные вычисления, и именно там возможны отличия в сложных рассуждениях. Для документов и GUI-задач такой расклад выглядит разумным компромиссом, но проверять его стоит на своих примерах, а не на общих заверениях. По грубой арифметике 120 млрд параметров в 4 битах это около 60 ГБ весов, в BF16 около 240 ГБ; к этому добавляются активации, кэш и визуальная часть, поэтому BF16 требует существенно больше памяти на инстансе.
Пошаговое развёртывание в SageMaker JumpStart
Две траектории: клики в Studio для быстрой проверки и SDK для повторяемых пайплайнов. Если вы уже разворачивали модели из JumpStart, схема будет знакомой; пример с управляемым endpoint реального времени разобран в материале про Qwen3-TTS на Amazon SageMaker.
Деплой через SageMaker Studio
- Откройте SageMaker Studio и перейдите в каталог JumpStart.
- Найдите модель по запросу Nemotron 3.5 Super VL.
- Выберите вариант: NVFP4 для инференса или BF16 для кастомизации.
- Выберите тип инстанса, совместимый с выбранным вариантом. Список доступных инстансов смотрите в консоли JumpStart: привязка конкретных типов к вариантам в источниках не подтверждена.
- Задайте параметры конфигурации, включая длину контекста и, если доступно, ограничения по памяти.
- Нажмите Deploy и дождитесь статуса InService: загрузка 120B-весов занимает заметно больше времени, чем у 7-8B моделей.
- Отправьте тестовый запрос в UI и проверьте ответ на простом изображении.
Studio удобен для первой проверки и демонстраций. Для повторяемых окружений и CI/CD берите SDK: ручные клики плохо воспроизводятся и не версионируются.
Деплой через SageMaker Python SDK
import sagemaker
from sagemaker.jumpstart.model import JumpStartModel
session = sagemaker.Session()
model = JumpStartModel(
model_id="<id модели из каталога JumpStart>", # сверьте с каталогом
role=session.get_execution_role(),
)
predictor = model.deploy(
initial_instance_count=1,
instance_type="<тип инстанса под выбранный вариант>",
# параметры контекста и окружения задаются здесь же
)
response = predictor.predict(payload)
print(response)
predictor.delete_endpoint()
Имена классов и аргументов сверяйте с актуальной документацией JumpStart: SDK меняется, а часть параметров конфигурации зависит от конкретного пакета модели. Обязательный шаг в конце любого теста - удаление endpoint. Инстансы с GPU класса H200 и Blackwell стоят дорого, и забытый endpoint продолжает расходовать бюджет круглосуточно.
Выбор конфигурации контекста
Длина контекста это компромисс между памятью, стоимостью и качеством. Больший контекст позволяет подать многостраничный PDF или длинную последовательность кадров, но увеличивает потребление памяти на инстансе и стоимость каждого запроса. Практический подход: начните с умеренного значения под реальную задачу (например, несколько страниц текста или десяток кадров видео), замерьте качество и повышайте лимит только если ответы упираются в обрезку.
Для видео главный рычаг не длина контекста как таковая, а число сэмплированных кадров. Удвоение кадров удваивает визуальную часть запроса, и это обычно заметнее по счёту, чем переключение между вариантами весов.
Работа с изображениями и видео: base64, кадры, формат запроса
Изображения передаются в теле запроса как base64-строка, видео сводится к набору сэмплированных кадров, каждый из которых кодируется тем же путём. Точную JSON-схему endpoint нужно сверить с документацией пакета в JumpStart: у разных VLM-пакетов отличается и обёртка, и способ кодирования data URL. Ниже общий вид, а не гарантированный контракт API.
Изображение через base64: пошагово
- Прочитайте файл в бинарном режиме.
- Закодируйте содержимое в base64 и соберите data URL с MIME-типом (image/png или image/jpeg).
- Соберите payload: текстовая инструкция плюс визуальный элемент.
- Отправьте запрос на endpoint и разберите ответ.
import base64, json
with open("page.png", "rb") as f:
b64 = base64.b64encode(f.read()).decode("utf-8")
payload = {
"messages": [
{
"role": "user",
"content": [
{"type": "text", "text": "Извлеки номер договора и дату подписания."},
{"type": "image_url", "image_url": {"url": f"data:image/png;base64,{b64}"}},
],
}
],
"temperature": 0.0,
}
print(json.dumps(payload)[:200])
Входные форматы модели по карточке: текстовые строки, изображения и сэмплированные кадры видео. Поддержка нескольких изображений в одном запросе в доступных материалах не описана, поэтому не рассчитывайте на неё без проверки. Планируйте пайплайн с расчётом на один визуальный вход за запрос: либо подавайте страницы по одной и агрегируйте результаты на своей стороне, либо извлекайте текст заранее и работайте с ним как с текстовым контекстом. Лимиты проверяйте в документации пакета.
Видео как набор кадров
Модель не смотрит видео потоком. C-RADIO кодирует сэмплированные кадры, коннектор отображает их в пространство эмбеддингов, и дальше это обычный мультимодальный контекст. Отсюда три практических следствия.
- Частота сэмплирования задаёт, что модель вообще увидит: редкие кадры дают общее описание сюжета, частые нужны для вопросов про порядок действий.
- Число кадров напрямую определяет длину контекста и стоимость запроса.
- Качество ответа зависит от выбора кадров не меньше, чем от модели: сцена смены состояния требует кадров до и после события.
Рабочий пример: видео-QA по записи экрана. Нарезаете кадры на моменты кликов и переходов между экранами, задаёте вопрос «на каком шаге пользователь уходит из формы», получаете ответ по последовательности изображений и текста.
Reasoning и параметры сэмплинга
Reasoning настраивается на уровне отдельного запроса. Это удобно: один и тот же endpoint обслуживает и тяжёлые задачи с рассуждением, и быстрый OCR без передеплоя и без второго инстанса.
Когда reasoning включать, а когда нет
- Включать: многошаговые GUI-задачи, вопросы по длинным документам с противоречиями, видео-QA, где нужно сопоставить события во времени.
- Выключать: чистый OCR, извлечение фиксированных полей, простая классификация изображений. Здесь рассуждение добавляет токены и латентность без прироста качества.
По сэмплингу логика стандартная. Для детерминированных задач (распознать текст, вытащить реквизиты, разметить тип документа) ставьте temperature близко к нулю и ограничивайте top_p, чтобы убрать вариативность. Для генеративных описаний видео или сводок по документам температура выше, иначе ответы получаются шаблонными. Конкретные значения подбираются на своём наборе примеров: универсального рецепта нет, а дефолты зависят от пакета модели в JumpStart.
Заявленные бенчмарки: MMLongBench-Doc, OCRBench v2, OSWorld-Verified
NVIDIA ориентирует модель на четыре класса задач и сопровождает анонс бенчмарками. Что каждый из них измеряет:
- MMLongBench-Doc: вопросы по длинным многостраничным документам, где ответ нужно найти и связать между страницами.
- OCRBench v2: распознавание и понимание текста на изображениях, включая сложные раскладки и мелкий шрифт.
- OSWorld-Verified: задачи computer-use в реальной GUI-среде, где модель выбирает действия по скриншоту.
Конкретные значения в доступных материалах не приведены, поэтому чисел здесь нет. В карточке модели MMLongBench-Doc и OCRBench-v2 упоминаются среди бенчмарков, для которых использовались официальные open-source реализации или внутренний scaffolding; OSWorld-Verified в доступных источниках не упоминается. Даже с опубликованными цифрами выводы стоит делать осторожно: это результаты вендора на его методике, а не независимый замер на ваших документах. После квантизации NVFP4 поведение на граничных случаях может отличаться от BF16, поэтому для критичных процессов соберите небольшой eval-набор из 50-100 своих примеров и прогоните оба варианта.
Сценарии применения: где модель реально полезна
Документный интеллект
Вопросы по договору на десятки страниц, извлечение реквизитов, разбор таблиц и плохих сканов. Длинный контекст помогает, но с одной оговоркой: пока многостраничный документ подаётся постранично, выигрыш от миллиона токенов реализуется только при работе с текстом или при передаче страниц отдельными запросами с агрегацией. Модель хорошо отвечает на вопросы «что написано и что это значит», но заменой специализированному OCR-пайплайну не служит: для поточной оцифровки архивов дешевле отдельный OCR плюс текстовая модель.
GUI-агенты и computer-use
Разбор скриншота, определение кнопок и полей, планирование следующего шага. Здесь работает software-engineering mid-training и ориентир на OSWorld-Verified. Учтите архитектуру агента: реальный цикл это скриншот, решение, действие, снова скриншот. Если один запрос принимает один визуальный вход, обработка идёт последовательно, и латентность агента складывается из длины этой цепочки. Для интерактивных сценариев важнее скорость отдельного шага, чем пиковая пропускная способность.
Видео-QA
Вопросы по обучающим видео, разбор демонстраций экрана, проверка соблюдения процедуры. Модель отвечает по набору кадров, поэтому качество определяется тем, насколько удачно выбраны моменты. Для проверки регламента имеет смысл комбинировать редкую сетку кадров для контекста и плотную выборку вокруг ключевых событий.
Мультимодальные агентные приложения объединяют всё перечисленное: текстовая инструкция, скриншот, извлечённый из документа фрагмент, вопрос по видео. Ограничение по одному визуальному входу на запрос превращается в вопрос проектирования оркестрации, а не блокер.
Ограничения, о которых стоит знать до деплоя
Один визуальный вход на запрос. В доступных материалах поддержка нескольких изображений в одном запросе не описана. Для пайплайнов со скриншотами и PDF это означает последовательные вызовы и собственную логику агрегации. Проверьте актуальные лимиты в документации пакета перед проектированием.
LoRA и спекулятивное декодирование: что подтверждено, а что нет. Модель в принципе можно кастомизировать через supervised fine-tuning и low-rank adaptation (LoRA), а MTP-голова поддерживает спекулятивное декодирование на уровне модели. Однако доступность этих возможностей именно в конфигурации SageMaker JumpStart в материалах не уточняется. Если вам нужны адаптеры LoRA на управляемом endpoint или ускорение через спекулятивное декодирование из коробки, уточняйте это в документации JumpStart до деплоя: возможно, потребуется BF16-вариант и собственный пайплайн обучения. Общий разбор того, как устроено дообучение LoRA и квантизация на практике, есть в материале про квантизацию и LoRA.
Разница в производительности между NVFP4 и BF16 ожидаема: разная точность весов и разное железо дают разную латентность и пропускную способность. Публичных замеров именно для JumpStart-конфигураций в доступных материалах нет, поэтому цифры придётся получать самостоятельно на своём профиле запросов.
Стоимость. GPU-инстансы под 120B-модель дорогие, и платите вы за время работы endpoint, а не за запросы. Тестовый endpoint, забытый на выходные, съест бюджет незаметно.
Чем NVFP4 может отличаться от BF16 по качеству
Vision encoder и коннектор в BF16, роутер в FP32, значит визуальная часть и маршрутизация экспертов защищены от деградации. Основной риск сосредоточен в языковом бэкбоне на W4A4: сложные многошаговые рассуждения по документу или длинная цепочка GUI-действий могут дать расхождения с BF16. Для извлечения полей и OCR разница обычно минимальна. Если задача критичная и бюджет позволяет, прогоните оба варианта на своём наборе и сравните не только точность, но и долю отказов и повторных попыток.
Стоимость и альтернативы JumpStart
Цены на GPU-инстансы под эту модель различаются по регионам и меняются, поэтому конкретных цифр здесь нет. Логика простая: счёт определяется типом инстанса и временем работы endpoint. NVFP4 на Blackwell обычно дешевле в пересчёте на запрос за счёт 4-битных весов и более компактного железа, BF16 дороже, но нужен, когда планируется дообучение или требуется эталон качества.
JumpStart не единственный путь. Собственный inference-стек даёт контроль над версиями рантайма и параметрами вроде спекулятивного декодирования. NVIDIA NIM удобен, если вы уже работаете в экосистеме NVIDIA и хотите контейнерный деплой. Локальный запуск на своём железе имеет смысл при постоянной нагрузке и требованиях к изоляции данных, но 120B в BF16 дома не поднять.
Чек-лист по деньгам: удалить endpoint после тестов, выбрать минимальный достаточный контекст, ограничить число кадров видео и не гонять reasoning там, где хватает прямого ответа.
Итог: кому и когда стоит разворачивать Nemotron 3.5 Super VL в JumpStart
Берите NVFP4 на Blackwell, если нужен быстрый инференс для документов, GUI-автоматизации или видео-QA и вы готовы жить с одним визуальным входом на запрос. Берите BF16, если планируете SFT, RL, дистилляцию, доменную адаптацию или свою квантизацию, либо если нужен эталон качества для сравнения. Перед выбором уточните в консоли JumpStart доступные типы инстансов и доступность LoRA и спекулятивного декодирования в управляемой конфигурации: в доступных материалах эти детали не подтверждены.
Практический порядок действий:
- Опишите сценарий и измерьте его в токенах и изображениях: одна страница PDF, один скриншот, десять кадров видео.
- Выберите вариант: NVFP4 для инференса, BF16 для кастомизации или эталона.
- Определите достаточную длину контекста и число кадров, не берите максимум по умолчанию.
- Прогоните 50-100 своих примеров и сравните качество и латентность с текущим решением.
- Удалите endpoint после тестов и настройте мониторинг использования, если оставляете его в работе.