Future feature requirement

[Solidier001]

It seems to me that SpringAI currently focuses only on generative large models. Will there be a future feature similar to Amazon's Deep Java Library that allows developers to import and train their own models?

[tzolov]

this @Solidier001 , this possible. But we would be interested to learn more about use cases for it?

[michaelisvy]

hello, I have some use-cases but I know they wouldn't be the easiest to implement.

Anybody who works with GPUs have to use a library that is specific to the GPU provider (for instance, in the case of NVIDIA, they use Cuda). In the coming years, there is going to be more competition between GPU providers, and it would be great to have an abstraction layer on top of GPU implementation libraries (in the same way that we have TransactionManagers as abstraction layers in Spring). I can see the following benefits:

• abstraction layer so people are not tightly coupled to one vendor (more of a mid-term goal, as the market is currently dominated by NVIDIA)
• reduction in the boilerplate code (as current libraries are very low level)
• Bringing those libraries to the Java community (there would need to be a wrapper from C++ to Java, as those libraries only have connectors in C++ or Python)

I'm just giving my 2 cents here as I work in an AI team and can see a lot of companies having the same painpoint as us. But I know it wouldn't be simple to implement.

[michaelisvy]

hello, I have some use-cases but I know they wouldn't be the easiest to implement.

Anybody who works with GPUs have to use a library that is specific to the GPU provider (for instance, in the case of NVIDIA, they use Cuda). In the coming years, there is going to be more competition between GPU providers, and it would be great to have an abstraction layer on top of GPU implementation libraries (in the same way that we have TransactionManagers as abstraction layers in Spring). I can see the following benefits:

• abstraction layer so people are not tightly coupled to one vendor (more of a mid-term goal, as the market is currently dominated by NVIDIA)
• reduction in the boilerplate code (as current libraries are very low level)
• Bringing those libraries to the Java community (there would need to be a wrapper from C++ to Java, as those libraries only have connectors in C++ or Python)

I'm just giving my 2 cents here as I work in an AI team and can see a lot of companies having the same painpoint as us. But I know it wouldn't be simple to implement.

[michaelisvy]

hello, I have some use-cases but I know they wouldn't be the easiest to implement.

Anybody who works with GPUs have to use a library that is specific to the GPU provider (for instance, in the case of NVIDIA, they use Cuda). In the coming years, there is going to be more competition between GPU providers, and it would be great to have an abstraction layer on top of GPU implementation libraries (in the same way that we have TransactionManagers as abstraction layers in Spring). I can see the following benefits:

• abstraction layer so people are not tightly coupled to one vendor (more of a mid-term goal, as the market is currently dominated by NVIDIA)
• reduction in the boilerplate code (as current libraries are very low level)
• Bringing those libraries to the Java community (there would need to be a wrapper from C++ to Java, as those libraries only have connectors in C++ or Python)

I'm just giving my 2 cents here as I work in an AI team and can see a lot of companies having the same painpoint as us. But I know it wouldn't be simple to implement.