# Model alias и реальная ревизия: идентичность ответа провайдера

Как связать публичный model alias с реальной ревизией, tokenizer и chat template: идентичность ответа, release record и проверка смены модели.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/provider-model-alias-revision-identity/
Language: ru

Публичное имя модели удобно клиенту: его можно оставить стабильным при изменении инфраструктуры. Но для расследования расхождений такого имени недостаточно. За одним alias могут последовательно работать разные ревизии весов, tokenizer или chat template. Контракт провайдера должен связывать внешний идентификатор с проверяемой внутренней записью, не выдавая короткую строку за точный checkpoint и не раскрывая лишние детали внутренней площадки.

## Разделите пространства имён

[Обзор API OpenRouter](https://openrouter.ai/docs/api_reference/overview) показывает поле model в ответе и дополнительные сведения, доступные только при поддержке провайдера. Публичный model ID относится к интерфейсу сервиса. Внутренний идентификатор релиза описывает установленный набор компонентов. Это разные сущности, даже если команда первоначально использует для них одинаковую строку.

Запишите область уникальности каждого значения. Нельзя считать локальное имя реплики глобальной версией модели. Если несколько реплик должны обслуживать один release, проверка соответствия выполняется на каждой участвующей конфигурации, а не выводится из состояния первой машины.

## Соберите release record

В запись включают источник и ревизию артефакта, формат весов, tokenizer, шаблон сообщений, версию движка и существенные параметры запуска. Для внешнего клиента можно публиковать только документированный безопасный идентификатор, сохраняя подробное соответствие внутри системы эксплуатации.

[Параметры vLLM serve](https://docs.vllm.ai/en/stable/cli/serve/) показывают, что настройки сервера являются частью выбранной конфигурации. Сохраните реальную команду или нормализованную запись параметров без секретов. Название контейнера и изменяемый tag сами по себе не заменяют точную версию его содержимого.

## Проверьте шаблон как компонент

[Руководство Hugging Face](https://huggingface.co/docs/transformers/chat_templating) объясняет, что сообщения превращаются в последовательность с управляющими токенами. Поэтому смена chat template может изменить поведение при тех же весах и внешнем имени. Такая операция должна отражаться в release record, а не считаться несущественным форматированием.

Используйте небольшой набор синтетических диалогов с разными ролями и одним поддерживаемым инструментом. Проверка фиксирует ожидаемые структурные свойства и отсутствие потери сообщений. Она не требует одинакового текста для каждого запуска и не подтверждает качество всех возможных пользовательских задач.

## Обнаружьте смешанный rollout

Во время обновления сравните объявленный alias с внутренней версией обработавшей запрос реплики. Если старые и новые экземпляры одновременно доступны, это должно быть частью выбранной стратегии, а не неизвестным состоянием. Сохраните время перехода и правила допуска новых запросов.

Диагностическая запись связывает request ID, публичное имя и release ID без содержания prompt. Если разница возникает только на части реплик, такая связь помогает проверить конфигурацию. Без неё любое расхождение легко ошибочно объяснить случайностью генерации или состоянием GPU.

## Не обещайте лишнюю идентичность

Совпадение release record подтверждает выбранный набор компонентов, но не гарантирует побитовое совпадение вычислений на любом оборудовании. Если сервис заявляет более строгую воспроизводимость, её область и метод проверки описываются отдельно. Поле system_fingerprint нельзя придумывать или заполнять произвольным значением ради внешней похожести.

Практические детали alias разобраны в [served-model-name](/ru/journal/vllm-served-model-name/), а обновление — в [canary-проверке модели](/ru/journal/model-update-canary/). Итог здесь — прослеживаемая идентичность конфигурации, полезная для диагностики и релизов, без утверждения о действующем подключении внешней платформы.