# Model aliases and revisions: provider response identity

Connect a public model alias to its artifact revision, tokenizer and chat template through response identity checks and a verifiable release record.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/provider-model-alias-revision-identity/
Language: en

A public model alias is convenient because clients can keep it stable while infrastructure changes. It is insufficient for investigating differences, however. Different weight, tokenizer or chat-template revisions may successively serve one alias. A provider contract should link the public identifier to a verifiable internal record without presenting a short name as an exact checkpoint or exposing unnecessary site details.

## Separate namespaces

The [OpenRouter API overview](https://openrouter.ai/docs/api_reference/overview) shows a response model field and additional information available only when the provider supports it. The public model ID belongs to the service interface. An internal release identifier describes the installed component set. They remain different entities even if a team initially uses the same string for both.

Record each identifier's uniqueness scope. A local replica name is not a global model version. If several replicas should serve one release, check each participating configuration rather than infer agreement from the first machine.

## Build a release record

Include artifact source and revision, weight format, tokenizer, message template, engine version and material launch settings. External clients can receive a documented safe identifier while operations retains the detailed mapping internally.

The [vLLM serve reference](https://docs.vllm.ai/en/stable/cli/serve/) demonstrates that server settings form part of the configuration. Preserve the real command or normalized settings without secrets. A container name and mutable tag alone do not identify its contents precisely.

## Treat the template as a component

The [Hugging Face guide](https://huggingface.co/docs/transformers/chat_templating) explains that messages become a sequence containing control tokens. Changing the template can therefore alter behavior under identical weights and public names. Reflect this in the release record rather than treating it as trivial formatting.

Use a small synthetic dialogue set with different roles and one supported tool. Check structural properties and preservation of messages. This does not require identical prose every time or establish quality for every user task.

## Detect mixed rollouts

During an update, compare the advertised alias with the handling replica's internal release. If old and new instances coexist, make that an explicit strategy rather than an unknown state. Save transition timing and new-request admission rules.

A diagnostic record connects request ID, public name and release ID without prompt content. If only some replicas differ, this link supports configuration investigation. Without it, every discrepancy may be incorrectly attributed to generation randomness or GPU state.

## Avoid excessive identity promises

Matching release records establishes the selected components rather than bitwise equality on any hardware. Stricter reproducibility claims need their own scope and tests. Do not invent system_fingerprint support or fill it arbitrarily to resemble another interface.

The [served-model-name guide](/journal/vllm-served-model-name/) covers aliases, while [model canaries](/journal/model-update-canary/) cover updates. The deliverable here is traceable configuration identity for diagnosis and releases, without claims that an external integration is already operating.