[Feature] Track token usage metrics for embedding models

[joeyutong]

Search before asking

• I searched in the issues and found nothing similar.

Description

Embedding model calls currently do not consistently report token usage metrics.

Chat models already have a token accounting path: provider usage is attached to the chat response and later recorded as model-level token metrics. Embedding models return only vectors, so provider usage returned by OpenAI-compatible or DashScope-style embedding APIs can be dropped before it reaches the metrics layer.

Affected paths include:

• Direct Java or Python embedding model calls.
• Vector store and RAG paths that auto-generate embeddings during add, update, or query.
• Cross-language resource paths where the wrapper may receive an action metric group but the provider-side embedding resource performs the actual request.

This makes it harder to validate and compare embedding model cost/usage, especially when a job mixes chat, embedding, and vector store operations. Embedding metrics do not need completionTokens, but should expose input-side token usage, for example promptTokens and totalTokens, under the same model/provider metric dimensions used by chat metrics where possible.

Are you willing to submit a PR?

• I'm willing to submit a PR!

[zxs1633079383]

Hi, I would like to work on this and have a first PR ready.

I took a first look at the current metric path and the related work in #860
and #861. My current understanding is that embedding token metrics should follow
the same production constraint as chat token metrics: record usage under the
request/action metric group that initiated the embedding call, not under a
mutable cached resource binding.

Proposed first PR scope:

• Add provider-neutral embedding token usage accounting for promptTokens and
  totalTokens when provider usage is available.
• Cover both Python and Java embedding model paths with unit tests.
• Keep providers that do not expose usage as no-op, so embedding calls do not
  fail or invent token counts.
• Align the metric dimensions with the existing chat model token metrics where
  practical.

I noticed the related metric work in #860 and #861. I kept the first PR small
and based on current main, so it should be easy to review or rebase if the
chat request-scoped metric changes from #861 land first.