Add DeepSeek model client

[mxsl-gr]

Hi, this PR is add DeepSeek model client and has passed unit testing.
I can provide my api_key if needed for testing

the PR content:

• DeepSeek chat client
• spring starter
• unit test
• chat client documents

For some reasons, products from OpenAI and others can't be directly used in Chinese Mainland.

DeepSeek is a strong, economical, and efficient Mixture of Experts (MoE) language model, with an API pricing of $0.14/$0.28 per 1 million tokens.

the link: DeepSeek

If they can supported, it will further aid spring-ai to promotion in Chinese Mainland.

If necessary, I can take care of subsequent maintenance since I'm currently using them.

The Moonshot PR is #596
The ZhiPuAI PR is #623
The MiniMax PR is #628

[GakkiNo1]

There are a lot of AI companies, and a lot of AI models, so the code can't be finished by creating clients all the time. Another thing is that deepseek has already said in the document that his API is fully compatible with openAI, that is to say, chatclient set the proxy address can call deepseek smoothly, i think the project maintainer needs to consider this problem: not to add a new model, but to add a new way to call，above are just my own thoughts。

[mxsl-gr]

There are a lot of AI companies, and a lot of AI models, so the code can't be finished by creating clients all the time. Another thing is that deepseek has already said in the document that his API is fully compatible with openAI, that is to say, chatclient set the proxy address can call deepseek smoothly, i think the project maintainer needs to consider this problem: not to add a new model, but to add a new way to call，above are just my own thoughts。

hi, I agree with your point. I have two thoughts.

if the companies provided an API standard compatible with OpenAI, in most cases, you can use it by just replacing the base url and API key, it's great.

while the OpenAI API design is not a standard, there are indeed many followers of its design, especially in mainland China. But this need the followers maintaining compatibility with the OpenAI API design. During the stage when their features are converging, it is predictable as they want to lower the barrier for potential users. But if they continue to develop, their paths may not necessarily converge.
A somewhat inappropriate example is Quarkus and Spring. Quarkus is relatively aggressive in native aspects, but they need to lower the barrier for developers using Spring. So, they provide Spring extensions to work in some cases to achieve low-barrier migration. However, if Spring API gets new designs, Quarkus may not necessarily follow them continuously.

Secondly, the two are not completely compatible. I encountered this with the n parameter. I have a scenario where I need to generate multiple options and then score them, but Deepseek currently does not support the n parameter. I think that if the API does not support it, it’s best not to include it in the configuration. This is something that cannot be achieved if using OpenAI implementation.

in conclusion, I think widely used model providers can still have independent implementations, but it doesn’t hurt to add a new way to call.