Published zembed-1 weights don't match the zembed-1 API checkpoint — which checkpoint should self-hosters use before Sept 4?
The migration guide recommends self-hosting these weights as a replacement for the hosted API, but they don't reproduce the API's vectors. Measured today (2026-07-26; same texts, both input_types, trust_remote_code custom module confirmed engaged — ZembedTransformer suffix + lasttoken pooling active; bf16; sentence-transformers 5.4/5.6):
- 16-query probe at dimensions=2560: cosine(API, these weights) mean 0.42, min 0.26
- Single identical text, side by side: query-mode 0.63, document-mode 0.62 — uniform divergence on BOTH input types, so this looks like a different checkpoint, not an invocation issue
Why it matters: anyone whose corpus indexes were built through the API (input_type="document") cannot self-host these weights as-is — query vectors land in a different space and retrieval geometry breaks, contrary to the migration guide's premise ("or self-host zembed-1 weights from HuggingFace").
Three questions before the Sept 4 shutdown:
- Is the API serving a newer checkpoint than this repo? If so, will it be published here?
- The migration guide's Modal recipe references zeroentropy/zembed-1-fp8, which is private (404). Can access be granted to this account?
- If the API checkpoint won't be released: please confirm officially that API users must re-embed their corpora even when self-hosting zembed-1, so migration plans can be sized correctly.
For balance: zerank-2's published weights DO match the API — identical orderings on our rerank pools and score-scale correlation 0.9966 using the documented sigmoid(logit/5) mapping. That half of the migration works exactly as documented. Thanks!