[BE] fix: register deepseek as a canonical provider so DeepSeek model prices load

[Anuj7411]

Details

Following the pattern of #7262 (which registered azure), #7432 (perplexity) and #7433 (xai) — deepseek is not currently in PROVIDERS_MAPPING, so all 12 entries in model_prices_and_context_window.json tagged with litellm_provider: "deepseek" silently drop at load time. Every one publishes non-zero input+output rates: deepseek-chat, deepseek-reasoner, deepseek-v4-flash, deepseek-v4-pro, plus the deepseek/deepseek-coder, deepseek/deepseek-r1, deepseek/deepseek-v3, deepseek/deepseek-v3.2 variants.

9 of the 12 also publish cache_read_input_token_cost. DeepSeek's cost calculator in LiteLLM (litellm/llms/deepseek/cost_calculator.py) is a one-liner that delegates directly to generic_cost_per_token — the same helper OpenAI/xAI use — so DeepSeek's usage payload follows the same OpenAI shape (prompt_tokens_details.cached_tokens flattened under original_usage.*). Route it through the existing SpanCostCalculator::textGenerationWithCacheCostOpenAI calculator; no new cache-calc method needed, just a mirror of the openai / azure / xai entries in PROVIDERS_CACHE_COST_CALCULATOR.

Change checklist

• User facing
• Documentation update

Issues

• Resolves #
• OPIK-

AI-WATERMARK

AI-WATERMARK: yes

• Tools: Claude Code (CLI)
• Model(s): Claude Opus 4.7
• Scope: scouted the reachable DeepSeek model count (12, 9 with cache_read), inspected LiteLLM's DeepSeek cost calc to confirm it delegates to generic_cost_per_token, drafted the two-line plumbing change following the [BE] fix: register azure as a canonical provider so Azure model prices load #7262 / [BE] fix: register xai as a canonical provider so xAI/Grok model prices load #7433 pattern, and wrote the parameterized branch-coverage test
• Human verification: ran the test suite locally; cross-checked expected dollar values against rates in model_prices_and_context_window.json

Testing

Local verification on JDK 25 + Maven 3.9.9. Result: 102/102 green (2 new parameterized cases under calculateCostHandlesDeepseekModels, style matching #7262).

Scenarios covered:

1. Plain text-generation route — deepseek/deepseek-coder (input 1.4e-7, output 2.8e-7, no cache rates). With prompt_tokens=1000, completion_tokens=200, expected 0.000196 (1000 * 1.4e-7 + 200 * 2.8e-7).
2. Cache-aware route via OpenAI calc — deepseek/deepseek-chat (input 2.8e-7, output 4.2e-7, cache_read 2.8e-8). With original_usage.prompt_tokens=1000, original_usage.completion_tokens=200, original_usage.prompt_tokens_details.cached_tokens=300, expected 0.0002884 (non-cached input 700 * 2.8e-7 + 200 * 4.2e-7 + 300 * 2.8e-8).

Documentation

No docs change. Behavior change is invisible to end users beyond accurate (non-zero) cost numbers for DeepSeek traces on 12 previously-dropped models.

[andrescrz]

Hi @Anuj7411

Thanks again for the contribution!

Could you please resolve the merge conflicts in the PR? Once that's done, we'll continue with the review.

Thanks!

[Anuj7411]

Rebased on latest main; conflicts were purely additive (xai landed first, so this now slots deepseek alongside xai in PROVIDERS_MAPPING and PROVIDERS_CACHE_COST_CALCULATOR, plus the two new test methods sit side-by-side). No logic changes on either commit. Ready for re-review

[andrescrz]

Hi @Anuj7411

Thanks for the contribution! I reviewed the PR and everything looks good from my side. I've approved it, and all CI checks have passed successfully.

We'll merge it shortly, and the change will be included in the next Opik release.

Thanks again for contributing to Opik!