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?
Comment From: tzolov
this @Solidier001 , this possible. But we would be interested to learn more about use cases for it?
Comment From: 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.
Comment From: 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.
Comment From: 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.
Comment From: markpollack
Providing a feature similar to DLJ, is out of our scope. Integrating with DLJ (ONXX) as we do with embeddings would be within scope.