Name your models so every seller spells them alike

One model, many strings, many rows

A model that every seller names differently is compared as several models, and a buyer looking for the cheapest place to run it sees fragments instead of one row with every price. The fix belongs to the maker: publish one canonical name, a fixed grammar for variants (size, tuning, quantisation, date), and an alias list for the spellings already in use. Then keep all three stable, because every change starts the splitting again.

We see the same problem with hardware first. A workstation card such as the RTX PRO 6000 96 GB is written with its words in a different order by different sellers, and matching them takes a rule someone has to maintain. Models have it worse, because a model has more variants than a card has form factors.

What a split row costs the buyer and the maker

The token price table covers 467 distinct models, and 93 of them are sold by more than one seller. That second figure is only as accurate as the matching behind it. When one host writes the name with a hyphen, another with a space and a third with the date appended, each can land as its own model with one seller, and the comparison a buyer came for never forms.

For the maker this looks like a smaller market than exists. Searches for the model return pages that disagree about what it is called, and an assistant asked where to run it has several half-answers to merge.

Splits also hide price differences. When the same weights appear under several names, the gap between the cheapest and the dearest seller of that model is not visible anywhere, because no row holds both. A buyer could have paid less and nothing on the page could show them.

Variants are where names fall apart

The base name is rarely the trouble. The suffixes are. Instruct or chat, a size, a quantisation level, a context variant, a date or a point release, all appended in whatever order the seller's catalogue prefers. Two of those strings may be the same weights, or may not, and a buyer cannot tell from the outside.

Some differences are real and should stay as separate rows. A 4-bit quantised build and a 16-bit build of the same model are different products: they need different memory and can give different answers. The goal is not to merge everything. It is that sellers serving the same thing write the same string, and sellers serving different things do not.

Dates in names cause their own trouble. A date written as a full year in one place and a short form in another produces a pair of strings for one release, and a date that marks when a host deployed the model rather than when you released it produces a string you never published at all.

Publish a grammar, not only a name

Write the order of parts and the spelling of each, once, on a page buyers and hosts can find. Family, version, size, tuning, then date, all lower case, hyphen separated, for example. Say what the quantisation suffix looks like when a host publishes a quantised build, even though you did not make it. A host has a convention to follow only if one exists.

Then publish the aliases. Every string you have used for a model in an API, a weights repository or a launch post, mapped to its canonical name. That list is what lets anyone matching names, including us, join rows with confidence instead of by guesswork.

Keep the canonical string identical to what your own API accepts. If the API wants one form and the documentation shows another, hosts will copy the documentation and buyers will get errors from your API.

What hosts copy when they list your model

A host adding your model to its catalogue copies something. If your page offers a canonical string and a suffix grammar, it copies those. If it offers only a launch post with a marketing name, the host makes up an identifier from whatever its own catalogue already looks like, and the next host does the same with different results.

Ask hosts to show the canonical name somewhere on their page even when their API uses a shorter string. A price table or a search engine matching names can then join the host's row to yours through it, and a buyer comparing sellers sees one model with several prices instead of several models with one each.

Stability is the larger half of the job

Renaming a model after launch breaks every match built on the old name. So does reusing a name for new weights, which is worse, because the rows still match and now hold different things. A moving alias such as latest should be documented as moving, with the dated identifier it currently points to and the date it last changed.

When a rename cannot be avoided, keep the old string as an alias that still resolves, list it in the alias table with the date it changed, and say so in the release notes. Matching survives a rename that is written down.

If our listing splits or merges your model wrongly, a claimed vendor can dispute the value, with the page that shows the canonical name as evidence. A maker that claims its listing can also answer the questions asked of its category with a source.