Currently the library provides a custom class for a lot of (if not all) models shipped in deepinfra, which requires a lot of maintenance, because new models come and go. Also, if you want to use a particular model, you have to know the name of the class to import -- even though the full name is meta-llama/Llama-2-70b-chat-hf the library exports it as Llama2_7B.
I think it is better to orient the API around model categories (i.e text-generation, image-generation) and then pass the particular model name as an argument (the OpenAI API works the same way):
import {TextGeneration} from 'deepinfra-api';
const tg = new TextGeneration("meta-llama/Llama-2-70b-chat-hf", MY_TOKEN);
const res = await tg.generate({"input": "Hello"});
This way you can change the model name, without touching anything else.
The code above is almost possible now with 2 caveats:
the TextGeneration class is called TextGenerationBaseModel
the base models are not exported
the base models are abstract (i.e not supposed to use them)
the endpoint url is passed in place of name (i.e https://api.deepinfra.com/v1/inference/meta-llama/Llama-2-70b-chat-hf instead of just meta-llama/Llama-2-70b-chat-hf). About this -- ideally the code should work with both. If the passed string has a single /, then treat it as a model name and use https://api.deepinfra.com/v1/inference/MODEL_NAME template, otherwise treat it as URL).
I think if we do all of the above, a lot of boilerplate code will go away (i.e no need to have a file + class + test for each model, only for each type).
NOTE: All of the above is slightly complicated by COG based models, only SDXL and clip-features ATM, I don't think new ones will be added, actually the opposite. For them we need a special class, because they are their own type (i.e their own non-shared-with-others API/interface). Those two we have to have custom classes for.
So to summarize, I suggest:
drop all custom model classes (except SDXL)
rename TYPEBaseModel to TYPE and export them instead, making them non-abstract
accept model_name in addition to endpoint_url (and advertise model_name more heavilty, endpoint_url is for advanced use-cases)
Currently the library provides a custom class for a lot of (if not all) models shipped in deepinfra, which requires a lot of maintenance, because new models come and go. Also, if you want to use a particular model, you have to know the name of the class to import -- even though the full name is
meta-llama/Llama-2-70b-chat-hf
the library exports it asLlama2_7B
.I think it is better to orient the API around model categories (i.e text-generation, image-generation) and then pass the particular model name as an argument (the OpenAI API works the same way):
This way you can change the model name, without touching anything else.
The code above is almost possible now with 2 caveats:
TextGeneration
class is calledTextGenerationBaseModel
https://api.deepinfra.com/v1/inference/meta-llama/Llama-2-70b-chat-hf
instead of justmeta-llama/Llama-2-70b-chat-hf
). About this -- ideally the code should work with both. If the passed string has a single/
, then treat it as a model name and usehttps://api.deepinfra.com/v1/inference/MODEL_NAME
template, otherwise treat it as URL).I think if we do all of the above, a lot of boilerplate code will go away (i.e no need to have a file + class + test for each model, only for each type).
NOTE: All of the above is slightly complicated by COG based models, only SDXL and clip-features ATM, I don't think new ones will be added, actually the opposite. For them we need a special class, because they are their own type (i.e their own non-shared-with-others API/interface). Those two we have to have custom classes for.
So to summarize, I suggest:
TYPEBaseModel
toTYPE
and export them instead, making them non-abstractmodel_name
in addition toendpoint_url
(and advertisemodel_name
more heavilty, endpoint_url is for advanced use-cases)@ovuruska any thoughts?