# ModelOpt checkpoint: как проверить scales, calibration и export metadata

Quantized ModelOpt checkpoint нужно принимать вместе со scales, конфигурацией квантования и происхождением calibration.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/modelopt-quantized-checkpoint-provenance/
Language: ru

Quantized ModelOpt checkpoint нужно принимать вместе со scales, конфигурацией квантования и происхождением calibration. Один runtime dtype не доказывает, что offline quantization выполнена корректно. Сохраните source revision, recipe и состав экспорта, затем проверьте поддерживаемый путь inference. Так можно отличить отсутствие нужных scaling tensors от неподходящего kernel или регрессии качества, не сводя все ошибки низкой точности к общей нехватке VRAM и случайному выбору другого флага запуска.

## Разделите recipe и исполнение

Calibration определяет параметры выбранного метода на конкретных данных и настройках. [PTQ examples ModelOpt](https://raw.githubusercontent.com/NVIDIA/Model-Optimizer/main/examples/hf_ptq/README.md) описывают workflow quantization, export и evaluation. Это отличается от указания dtype при запуске runtime. Запишите, какой исходный checkpoint использовался, как подготовлены calibration inputs и какие параметры recipe выбраны. Не выводите их из имени каталога `fp8`: одно название не описывает scaling granularity, примененные слои или процедуру получения результата, достаточную для повторения и анализа изменившегося поведения модели.

## Проверьте состав unified export

[Руководство unified checkpoint](https://nvidia.github.io/Model-Optimizer/deployment/3_unified_hf.html) перечисляет safetensors с весами и scaling factors, `hf_quant_config.json` и дополнительные metadata. Приемка должна проверять согласованность всего комплекта. Нельзя заменить config от соседней модели только ради прохождения loader. Сохраните file manifest и ревизии инструментов, которые создали экспорт. Если веса разбиты на shards, проверьте index и наличие каждой части. Внешний checksum полезен для целостности доставки, но не доказывает содержательную корректность выбранного quantization recipe или его пригодность к целевому workload.

## Пример карточки provenance

Создайте поля source model commit, ModelOpt version, recipe, calibration dataset identity, preprocessing, export format и evaluation fixtures. Для dataset достаточно воспроизводимого описания и разрешенного доступа; не подставляйте случайный набор после получения плохого результата без новой версии карточки. Рядом сохраните список quantized layers и ожидаемые scales, насколько они отражены форматом. Это пример артефакта, не заявление о готовом checkpoint Retrivium. Отдельно укажите, какие параметры заданы вручную и какие выбраны инструментом, чтобы повтор не зависел от памяти автора эксперимента.

## Сверьте model и hardware support

[Матрицы TensorRT-LLM quantization](https://nvidia.github.io/TensorRT-LLM/features/quantization.html) разделяют поддержку моделей и GPU. Совпадение формата еще не подтверждает конкретную комбинацию architecture, recipe и kernel. До benchmark выполните loader acceptance и короткие quality fixtures. Если runtime отвергает комплект, сначала локализуйте metadata или support ограничение. Если загружается, но качество изменилось, сравните согласованный исходный baseline и exported model на одинаковых задачах. Не объявляйте успешную десериализацию доказательством сохраненной точности и не придумывайте процент потери качества по названию низкобитного режима.

## Зафиксируйте границу релиза

Сохраните artifacts, hashes, configs, provenance и результаты функциональной оценки. Runtime настройки должны ссылаться на этот комплект, а не на mutable ветку repository без фиксации. При повторной calibration создайте новую идентичность экспорта, даже если public model alias остается прежним. После обновления serving framework проверьте выбранные kernels отдельно от воспроизводимости самой calibration. Полезный итог соединяет происхождение модели, процесс преобразования и фактическое исполнение, не смешивая их в один dtype. Он дает оператору возможность понять, что изменилось, и повторить проверку без обещания универсального ускорения или сохранения качества на всех задачах только потому, что экспорт завершился успешно.

## Связанные материалы

[Квантизация LLM: как проверить качество перед выбором GPU](/ru/journal/quantization-quality/); [Воспроизводимый стек инференса: как сохранить результат GPU-пилота](/ru/journal/software-stack-reproducibility/).