Router advertises a model id the TEI backend rejects

[eksrha]

Summary

The router advertises a model id on /v1/models that the TEI backend rejects when it is sent back on /v1/embeddings. Every embedding request therefore logs a warning and relies on TEI's fallback to its single loaded model.

Observed behaviour

GET /v1/models returns:

{"object":"list","data":[
  {"id":"BAAI/bge-m3","object":"model","owned_by":"inference-stack"},
  {"id":"BAAI/bge-reranker-v2-m3","object":"model","owned_by":"inference-stack"}
]}

A client that discovers the model id this way and sends it as model in the embedding request gets, on every call:

WARN openai_embed: The provided `model=BAAI/bge-m3` has not been found,
     the `model` parameter should be provided either empty or with `model=/model` instead.

The request still succeeds — TEI has exactly one model loaded and falls back to it.

Why this matters

It works today only because the fallback is unambiguous. Two things make that fragile:

1. The advertised contract is not honoured. /v1/models is the discovery mechanism; a client is expected to use what it returns. Right now that value is not accepted by the endpoint it was discovered for.
2. The fallback is load-bearing. If TEI tightens validation, or if an instance ever serves more than one model, the fallback either disappears or becomes ambiguous — and embedding fails wholesale rather than degrading.

The warning is also pure log noise at one line per request, which makes real embedding problems harder to spot.

Suggested direction

Options, roughly in order of preference:

1. Translate in the router. Accept the advertised id on the way in and rewrite it to what the backend expects before proxying. Keeps the public contract stable and hides the backend detail — which is what a router is for.
2. Advertise what the backend accepts. Simpler, but leaks a TEI implementation detail into the API and makes the id less descriptive.
3. Document that model should be omitted. Cheapest, but leaves the discovery endpoint returning a value that cannot be used as documented.

Option 1 looks right: the mismatch is exactly the kind of backend variation the router exists to absorb.

Notes

• Reproducible against the current deployment; not specific to any one caller.
• Affects the embedding path. The reranker path uses a separate model id and was not checked — worth confirming it does not have the same mismatch.