You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Llama Stack has a remote Qdrant provider but no inline Qdrant provider. It would be nice to also have inline as an option.
💡 Why is this needed? What if we don't build it?
Llama Stack users who want to use Qdrant need to deploy and manage a separate Qdrant server process.
Other thoughts
Qdrant has a local mode which would allow it to be used as an inline provider, so it seems like it would be simple to add it that way. Llama Stack already has both remote and inline providers for Chroma, so I think having both for Qdrant could follow the same pattern. Specifically, there are separate llama_stack/providers/inline/vector_io/chroma/ and llama_stack/providers/remote/vector_io/chroma/ directories each with their own separate configuration class but they share one common implementation class that lives in the remote directory. That's a little confusing (because the implementation is for both inline and remote but it lives i the remote directory). However, I think it's better than any other alternative that I can come up with.
The text was updated successfully, but these errors were encountered:
🚀 Describe the new functionality needed
Llama Stack has a remote Qdrant provider but no inline Qdrant provider. It would be nice to also have inline as an option.
💡 Why is this needed? What if we don't build it?
Llama Stack users who want to use Qdrant need to deploy and manage a separate Qdrant server process.
Other thoughts
Qdrant has a local mode which would allow it to be used as an inline provider, so it seems like it would be simple to add it that way. Llama Stack already has both remote and inline providers for Chroma, so I think having both for Qdrant could follow the same pattern. Specifically, there are separate
llama_stack/providers/inline/vector_io/chroma/
andllama_stack/providers/remote/vector_io/chroma/
directories each with their own separate configuration class but they share one common implementation class that lives in the remote directory. That's a little confusing (because the implementation is for both inline and remote but it lives i theremote
directory). However, I think it's better than any other alternative that I can come up with.The text was updated successfully, but these errors were encountered: