在机器学习领域,针对已经训练好的模型创建一个快速的 Demo 通常是必要的,本文针对快速创建机器学习应用的几个框架:gradio、streamit 和 dash 进行简单的对比。
综合比较
gradio | streamit | dash | |
---|---|---|---|
主要使用场景 | 可交互小 Demo | 工作流、DashBoard | DashBoard、生产环境的复杂演示应用 |
上手难度 | 简单 | 简单 | 中等 |
组件丰富度 | 低 | 高 | 高 |
综合扩展性 | 低 | 中 | 高 |
Jupyter Notebook 内支持 | 是 | 否 | 是 |
是否完全开源 | 是 | 是 | 部分企业级功能未开源 |
github stars | 13.4k | 23.1k | 18.2k |
案例列表 | demos | streamit gallery | dash gallery |
接下来,我们分别结合一定的示例,讲解这三个框架的使用以及各自更加具体的特点。
Gradio
使用
gradio 基于 svelte,它的初步使用非常简单,同时它的自封装组件的功能也相对比较完整,因此可以让开发者专注于编写基于 python 代码的业务处理逻辑,无需关注更多 web 前端页面的实现细节。
例如,我们实现一个简单的图片分类器:
1 | import gradio as gr |
它的一个演示效果:
这里对于开发者来说,只需要实现 image_classifier
这个 python 函数即可,无需关注图片上传处理、UI 展示等工作。
特点
优点:
- 组件的封装程度高,并且尤其适合机器学习模型相关的应用,比如 NLP、CV 领域的模型,最近比较火的 stable-diffusion-webui 就是基于 gradio 搭建的,也可以方便地做一个 ChatGPT 的简单对话框。
- 可以快速创建可共享的链接,从而方便将链接分享给用户。
- 可以直接在 Jupyter Notebook 中展示。
缺点:
- 组件的扩展性比较差,如果你想定制一个组件,需要 fork 它的代码,修改源代码从而添加组件,并不支持独立的自定义组件。
- 使用场景较为简单,如果你有复杂的数据图表展示等需求,使用 gradio 会难以满足。
简单来说,如果你想快速制作一个演示 demo,并且你需要的功能正好 gradio 的官方组件列表中也有现成的组件可用,那么你就可以使用 gradio,否则就不建议使用了。
Streamit
streamit 基于 React ,它的上手使用也非常之简单,也是可以在前后端开发知识为 0 的情况下就可以轻松上手,例如我们通过以下几行代码:
1 | import streamlit as st |
就可以快速制作一个可交互的滚动条:
特点
优点:
- 默认组件库更为精细化,并且组件的类型比较多,例如支持更多的可视化展示例如 Matplotlib、Vega Lite (2D charts) 和 deck.gl (maps and 3D charts);数据集本地上传等功能
- 支持自定义组件以及异步加载,也因此社区组件比较丰富。
缺点:
- streamit 更加独立,没有办法较好地直接展示在 Notebook 中。
- streamit 由于更加灵活,并且内置功能较多,完全熟练使用需要一定的时间上手,不如 gradio 简单。
Dash
dash 基于 Plotly.js、React 和 Flask,因此相对于前两者,它的启动和编码方式更“像”一个 python 后端,也因此代码会稍微多一些。
我们这里依旧展示一个官方提供的最小的 demo:
1 | from dash import Dash, html, dcc |
它的一个展示效果:
)
特点
优点:
- 除了 Python,可以支持、R、Julia 来编写程序。
- 后端基于 flask,也意味着后端的扩展能力非常强大。
- 可视化相关的图表支持非常丰富。
- 可以通过一定的适配,支持在 Jupyter Notebook 中使用。
缺点:
- 实际上,使用 dash 相当于使用 python 编写 html + 后端,因此代码会比较冗长,同时也不适合网站开发者,和现代的主流前后端开发理念有所违和。
- 不适合大型项目,通常来说用户响应速度没有 JS 快(因为是纯 python 编写前端)
其他补充
除了以上三种方案,对于更加复杂的企业级应用,一般建议采用前后端分离的应用开发方案,这部分相对来说建议专人负责,本篇就不进行过多介绍了。