fix(api): honour encoding_format=base64 in /v1/embeddings

[MohammadHijjawi97]

What

POST /v1/embeddings accepted encoding_format but dropped it and always returned float arrays.

• A client that sets encoding_format="base64" gets a list where the OpenAI API returns a base64 string, so code that decodes the string breaks.
• The OpenAI Python and Node SDKs ask for base64 by default and decode it client-side, so every SDK call to Xinference pays for the float payload. For a 1024-dim vector that is ~22 KB per embedding instead of ~5.5 KB.

Fix

When encoding_format == "base64", each dense vector is encoded the way OpenAI does it: little-endian float32 bytes, base64-encoded. Sparse embeddings (token -> weight dicts) have no base64 form and stay as they are. Default and "float" responses are unchanged.

Before / after (openai SDK 3.26.0 against the handler)

r = await client.embeddings.create(model="m", input="hi", encoding_format="base64")
r.data[0].embedding
# before: [0.5, -1.0, 2.0]
# after:  'AAAAPwAAgL8AAABA'   (decodes to [0.5, -1.0, 2.0])

The SDK default call (create(model=..., input=...)) still returns [0.5, -1.0, 2.0]. It now gets base64 on the wire and decodes it.

Tests

• New xinference/api/tests/test_embedding_encoding_format.py:
  • base64 output round-trips to the original float32 vectors, and encoding_format is not forwarded to the model.
  • Omitted and "float" keep lists.
  • Sparse embeddings are unchanged.
  • The base64 test fails without the fix.
• pytest xinference/api/tests: all pass, plus pre-commit (black, ruff, isort, mypy, codespell) on the changed files.

[qinxuye]

LGTM. Verified dense base64 encoding, unchanged float/default responses and sparse handling. All 14 focused tests passed, and an additional OpenAI SDK check passed for default, float and explicit base64 requests. The Metal CI failure is in F5-TTS model startup (actor connection reset), outside the changed embedding response path.