-
-
Notifications
You must be signed in to change notification settings - Fork 519
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pn.chat.WebLLM module #7298
Comments
I believe that in an ideal world Panel provided core building blocks and panel-xyz packages provided ad on functionality. This would enable specialized communication, communities, and documentation as well as a faster release cycle for the add on projects. I believe chat and WebLLM in an ideal world falls in to the addon category. If we truly believe webllm can create value for Panel it's ok for me in a practical world to include in Panel if we have the people to support it. As I see it one area where Panel is missing components is systematically supporting ML and Dl tasks similarly to Gradio. We don't have the (high quality) components and high level interface needed to easily and systematically support X media to Y media tasks. An example task is speech to text, where we don't have an audio input component. The question is similarly if those components should live in Panel or an extension package. I see them as more core to Panel than WebLLM. |
I'd love to see WebLLM directly integrated within Panel chat because it helps user quickly get started with LLMs without the headache of installing another package. Plus, WebLLM requires no additional dependencies besides downloading & caching the model. As a datapoint, Prefect used to have many integrations separated into their own repos: I suppose the reason being was that integrations in separate repos weren't very visible so users weren't aware of them.
I think we first need to make more users adopt Panel to achieve that. |
My feeling aligns with @MarcSkovMadsen here, I believe there's benefits to making this a separate project. Panel has grown very large and I'd like to come up with a real extension mechanism to stop it from continuing to grow ever further. Since Panel has to ship the bundled code, each component further bloats the distributed package. I do get your point though @ahuang11, I believe the only way extensions will be successful is if we make them visible. As we already discussed internally at minimum that would include:
Talking specifically about |
With the release of Panel's integration of JSComponent and ability to couple with WebLLM, I believe that, Panel has a great opportunity to distinguish itself from other dashboarding libraries besides its amazing integration with interactive plotting (HoloViews) by leveraging its ability to run LLMs directly on the client side with minimal setup.
I propose we migrate the example from this page into a module and make it easy for developers to use or extend it.
The text was updated successfully, but these errors were encountered: