mirror of
https://github.com/gradio-app/gradio.git
synced 2025-04-18 12:50:30 +08:00
Reorganize Guides in a more logical order (#8262)
* guides reorg * separate flagging * examples * tweak * Update 01_quickstart.md * redirect * redirect * add changeset --------- Co-authored-by: gradio-pr-bot <gradio-pr-bot@users.noreply.github.com>
This commit is contained in:
Abubakar Abid
GitHub
parent
4ae17a4653
commit
d708ca8fca
5
.changeset/little-stars-fry.md
Normal file
5
.changeset/little-stars-fry.md
Normal file
@ -0,0 +1,5 @@
|
||||
---
|
||||
"website": minor
|
||||
---
|
||||
|
||||
feat:Reorganize Guides in a more logical order
|
||||
@ -4,7 +4,7 @@ Gradio is an open-source Python package that allows you to quickly **build** a d
|
||||
|
||||
<img src="https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/gradio-guides/lcm-screenshot-3.gif" style="padding-bottom: 10px">
|
||||
|
||||
It just takes a few lines of Python to create a beautiful demo like the one above, so let's get started 💫
|
||||
It just takes a few lines of Python to create a demo like the one above, so let's get started 💫
|
||||
|
||||
## Installation
|
||||
|
||||
@ -53,7 +53,7 @@ The `Interface` class has three core arguments:
|
||||
|
||||
The `fn` argument is very flexible -- you can pass *any* Python function that you want to wrap with a UI. In the example above, we saw a relatively simple function, but the function could be anything from a music generator to a tax calculator to the prediction function of a pretrained machine learning model.
|
||||
|
||||
The `input` and `output` arguments take one or more Gradio components. As we'll see, Gradio includes more than [30 built-in components](https://www.gradio.app/docs/components) (such as the `gr.Textbox()`, `gr.Image()`, and `gr.HTML()` components) that are designed for machine learning applications.
|
||||
The `inputs` and `outputs` arguments take one or more Gradio components. As we'll see, Gradio includes more than [30 built-in components](https://www.gradio.app/docs/components) (such as the `gr.Textbox()`, `gr.Image()`, and `gr.HTML()` components) that are designed for machine learning applications.
|
||||
|
||||
Tip: For the `inputs` and `outputs` arguments, you can pass in the name of these components as a string (`"textbox"`) or an instance of the class (`gr.Textbox()`).
|
||||
|
||||
@ -85,9 +85,9 @@ Now, anyone around the world can try your Gradio demo from their browser, while
|
||||
To learn more about sharing your demo, read our dedicated guide on [sharing your Gradio application](https://www.gradio.app/guides/sharing-your-app).
|
||||
|
||||
|
||||
## An Overview of Gradio
|
||||
## Core Gradio Classes
|
||||
|
||||
So far, we've been discussing the `Interface` class, which is a high-level class that lets to build demos quickly with Gradio. But what else does Gradio do?
|
||||
So far, we've been discussing the `Interface` class, which is a high-level class that lets to build demos quickly with Gradio. But what else does Gradio include?aaa
|
||||
|
||||
### Chatbots with `gr.ChatInterface`
|
||||
|
||||
@ -111,7 +111,7 @@ That's the gist of the core `gradio` Python library, but Gradio is actually so m
|
||||
|
||||
## What's Next?
|
||||
|
||||
Keep learning about Gradio sequentially using the Gradio Guides, which include explanations as well as example code and embedded interactive demos. Next up: [key features about Gradio demos](https://www.gradio.app/guides/key-features).
|
||||
Keep learning about Gradio sequentially using the Gradio Guides, which include explanations as well as example code and embedded interactive demos. Next up: [let's dive deeper into the Interface class](https://www.gradio.app/guides/the-interface-class).
|
||||
|
||||
Or, if you already know the basics and are looking for something specific, you can search the more [technical API documentation](https://www.gradio.app/docs/).
|
||||
|
||||
|
||||
@ -1,192 +0,0 @@
|
||||
# Key Features
|
||||
|
||||
Let's go through some of the key features of Gradio. This guide is intended to be a high-level overview of various things that you should be aware of as you build your demo. Where appropriate, we link to more detailed guides on specific topics.
|
||||
|
||||
1. [Components](#components)
|
||||
2. [Queuing](#queuing)
|
||||
3. [Streaming outputs](#streaming-outputs)
|
||||
4. [Streaming inputs](#streaming-inputs)
|
||||
5. [Alert modals](#alert-modals)
|
||||
6. [Styling](#styling)
|
||||
7. [Progress bars](#progress-bars)
|
||||
8. [Batch functions](#batch-functions)
|
||||
|
||||
## Components
|
||||
|
||||
Gradio includes more than 30 pre-built components (as well as many user-built _custom components_) that can be used as inputs or outputs in your demo with a single line of code. These components correspond to common data types in machine learning and data science, e.g. the `gr.Image` component is designed to handle input or output images, the `gr.Label` component displays classification labels and probabilities, the `gr.Plot` component displays various kinds of plots, and so on.
|
||||
|
||||
Each component includes various constructor attributes that control the properties of the component. For example, you can control the number of lines in a `gr.Textbox` using the `lines` argument (which takes a positive integer) in its constructor. Or you can control the way that a user can provide an image in the `gr.Image` component using the `sources` parameter (which takes a list like `["webcam", "upload"]`).
|
||||
|
||||
**Static and Interactive Components**
|
||||
|
||||
Every component has a _static_ version that is designed to *display* data, and most components also have an _interactive_ version designed to let users input or modify the data. Typically, you don't need to think about this distinction, because when you build a Gradio demo, Gradio automatically figures out whether the component should be static or interactive based on whether it is being used as an input or output. However, you can set this manually using the `interactive` argument that every component supports.
|
||||
|
||||
**Preprocessing and Postprocessing**
|
||||
|
||||
When a component is used as an input, Gradio automatically handles the _preprocessing_ needed to convert the data from a type sent by the user's browser (such as an uploaded image) to a form that can be accepted by your function (such as a `numpy` array).
|
||||
|
||||
|
||||
Similarly, when a component is used as an output, Gradio automatically handles the _postprocessing_ needed to convert the data from what is returned by your function (such as a list of image paths) to a form that can be displayed in the user's browser (a gallery of images).
|
||||
|
||||
Consider an example demo with three input components (`gr.Textbox`, `gr.Number`, and `gr.Image`) and two outputs (`gr.Number` and `gr.Gallery`) that serve as a UI for your image-to-image generation model. Below is a diagram of what our preprocessing will send to the model and what our postprocessing will require from it.
|
||||
|
||||
|
||||
|
||||
In this image, the following preprocessing steps happen to send the data from the browser to your function:
|
||||
|
||||
* The text in the textbox is converted to a Python `str` (essentially no preprocessing)
|
||||
* The number in the number input in converted to a Python `float` (essentially no preprocessing)
|
||||
* Most importantly, ihe image supplied by the user is converted to a `numpy.array` representation of the RGB values in the image
|
||||
|
||||
Images are converted to NumPy arrays because they are a common format for machine learning workflows. You can control the _preprocessing_ using the component's parameters when constructing the component. For example, if you instantiate the `Image` component with the following parameters, it will preprocess the image to the `PIL` format instead:
|
||||
|
||||
```py
|
||||
img = gr.Image(type="pil")
|
||||
```
|
||||
|
||||
Postprocessing is even simpler! Gradio automatically recognizes the format of the returned data (e.g. does the user's function return a `numpy` array or a `str` filepath for the `gr.Image` component?) and postprocesses it appropriately into a format that can be displayed by the browser.
|
||||
|
||||
So in the image above, the following postprocessing steps happen to send the data returned from a user's function to the browser:
|
||||
|
||||
* The `float` is displayed as a number and displayed directly to the user
|
||||
* The list of string filepaths (`list[str]`) is interpreted as a list of image filepaths and displayed as a gallery in the browser
|
||||
|
||||
Take a look at the [Docs](https://gradio.app/docs) to see all the parameters for each Gradio component.
|
||||
|
||||
## Queuing
|
||||
|
||||
Every Gradio app comes with a built-in queuing system that can scale to thousands of concurrent users. You can configure the queue by using `queue()` method which is supported by the `gr.Interface`, `gr.Blocks`, and `gr.ChatInterface` classes.
|
||||
|
||||
For example, you can control the number of requests processed at a single time by setting the `default_concurrency_limit` parameter of `queue()`, e.g.
|
||||
|
||||
```python
|
||||
demo = gr.Interface(...).queue(default_concurrency_limit=5)
|
||||
demo.launch()
|
||||
```
|
||||
|
||||
This limits the number of requests processed for this event listener at a single time to 5. By default, the `default_concurrency_limit` is actually set to `1`, which means that when many users are using your app, only a single user's request will be processed at a time. This is because many machine learning functions consume a significant amount of memory and so it is only suitable to have a single user using the demo at a time. However, you can change this parameter in your demo easily.
|
||||
|
||||
See the [docs on queueing](/docs/gradio/interface#interface-queue) for more details on configuring the queuing parameters.
|
||||
|
||||
## Streaming outputs
|
||||
|
||||
In some cases, you may want to stream a sequence of outputs rather than show a single output at once. For example, you might have an image generation model and you want to show the image that is generated at each step, leading up to the final image. Or you might have a chatbot which streams its response one token at a time instead of returning it all at once.
|
||||
|
||||
In such cases, you can supply a **generator** function into Gradio instead of a regular function. Creating generators in Python is very simple: instead of a single `return` value, a function should `yield` a series of values instead. Usually the `yield` statement is put in some kind of loop. Here's an example of an generator that simply counts up to a given number:
|
||||
|
||||
```python
|
||||
def my_generator(x):
|
||||
for i in range(x):
|
||||
yield i
|
||||
```
|
||||
|
||||
You supply a generator into Gradio the same way as you would a regular function. For example, here's a a (fake) image generation model that generates noise for several steps before outputting an image using the `gr.Interface` class:
|
||||
|
||||
$code_fake_diffusion
|
||||
$demo_fake_diffusion
|
||||
|
||||
Note that we've added a `time.sleep(1)` in the iterator to create an artificial pause between steps so that you are able to observe the steps of the iterator (in a real image generation model, this probably wouldn't be necessary).
|
||||
|
||||
## Streaming inputs
|
||||
|
||||
Similarly, Gradio can handle streaming inputs, e.g. a live audio stream that can gets transcribed to text in real time, or an image generation model that reruns every time a user types a letter in a textbox. This is covered in more details in our guide on building [reactive Interfaces](/guides/reactive-interfaces).
|
||||
|
||||
## Alert modals
|
||||
|
||||
You may wish to raise alerts to the user. To do so, raise a `gr.Error("custom message")` to display an error message. You can also issue `gr.Warning("message")` and `gr.Info("message")` by having them as standalone lines in your function, which will immediately display modals while continuing the execution of your function. Queueing needs to be enabled for this to work.
|
||||
|
||||
Note below how the `gr.Error` has to be raised, while the `gr.Warning` and `gr.Info` are single lines.
|
||||
|
||||
```python
|
||||
def start_process(name):
|
||||
gr.Info("Starting process")
|
||||
if name is None:
|
||||
gr.Warning("Name is empty")
|
||||
...
|
||||
if success == False:
|
||||
raise gr.Error("Process failed")
|
||||
```
|
||||
|
||||
|
||||
|
||||
## Styling
|
||||
|
||||
Gradio themes are the easiest way to customize the look and feel of your app. You can choose from a variety of themes, or create your own. To do so, pass the `theme=` kwarg to the `Interface` constructor. For example:
|
||||
|
||||
```python
|
||||
demo = gr.Interface(..., theme=gr.themes.Monochrome())
|
||||
```
|
||||
|
||||
Gradio comes with a set of prebuilt themes which you can load from `gr.themes.*`. You can extend these themes or create your own themes from scratch - see the [theming guide](https://gradio.app/guides/theming-guide) for more details.
|
||||
|
||||
For additional styling ability, you can pass any CSS (as well as custom JavaScript) to your Gradio application. This is discussed in more detail in our [custom JS and CSS guide](/guides/custom-CSS-and-JS).
|
||||
|
||||
|
||||
## Progress bars
|
||||
|
||||
Gradio supports the ability to create custom Progress Bars so that you have customizability and control over the progress update that you show to the user. In order to enable this, simply add an argument to your method that has a default value of a `gr.Progress` instance. Then you can update the progress levels by calling this instance directly with a float between 0 and 1, or using the `tqdm()` method of the `Progress` instance to track progress over an iterable, as shown below.
|
||||
|
||||
$code_progress_simple
|
||||
$demo_progress_simple
|
||||
|
||||
If you use the `tqdm` library, you can even report progress updates automatically from any `tqdm.tqdm` that already exists within your function by setting the default argument as `gr.Progress(track_tqdm=True)`!
|
||||
|
||||
## Batch functions
|
||||
|
||||
Gradio supports the ability to pass _batch_ functions. Batch functions are just
|
||||
functions which take in a list of inputs and return a list of predictions.
|
||||
|
||||
For example, here is a batched function that takes in two lists of inputs (a list of
|
||||
words and a list of ints), and returns a list of trimmed words as output:
|
||||
|
||||
```py
|
||||
import time
|
||||
|
||||
def trim_words(words, lens):
|
||||
trimmed_words = []
|
||||
time.sleep(5)
|
||||
for w, l in zip(words, lens):
|
||||
trimmed_words.append(w[:int(l)])
|
||||
return [trimmed_words]
|
||||
```
|
||||
|
||||
The advantage of using batched functions is that if you enable queuing, the Gradio server can automatically _batch_ incoming requests and process them in parallel,
|
||||
potentially speeding up your demo. Here's what the Gradio code looks like (notice the `batch=True` and `max_batch_size=16`)
|
||||
|
||||
With the `gr.Interface` class:
|
||||
|
||||
```python
|
||||
demo = gr.Interface(
|
||||
fn=trim_words,
|
||||
inputs=["textbox", "number"],
|
||||
outputs=["output"],
|
||||
batch=True,
|
||||
max_batch_size=16
|
||||
)
|
||||
|
||||
demo.launch()
|
||||
```
|
||||
|
||||
With the `gr.Blocks` class:
|
||||
|
||||
```py
|
||||
import gradio as gr
|
||||
|
||||
with gr.Blocks() as demo:
|
||||
with gr.Row():
|
||||
word = gr.Textbox(label="word")
|
||||
leng = gr.Number(label="leng")
|
||||
output = gr.Textbox(label="Output")
|
||||
with gr.Row():
|
||||
run = gr.Button()
|
||||
|
||||
event = run.click(trim_words, [word, leng], output, batch=True, max_batch_size=16)
|
||||
|
||||
demo.launch()
|
||||
```
|
||||
|
||||
In the example above, 16 requests could be processed in parallel (for a total inference time of 5 seconds), instead of each request being processed separately (for a total
|
||||
inference time of 80 seconds). Many Hugging Face `transformers` and `diffusers` models work very naturally with Gradio's batch mode: here's [an example demo using diffusers to
|
||||
generate images in batches](https://github.com/gradio-app/gradio/blob/main/demo/diffusers_with_batching/run.py)
|
||||
|
||||
|
||||
@ -11,7 +11,22 @@ We see that the `Interface` class is initialized with three required parameters:
|
||||
- `inputs`: which Gradio component(s) to use for the input. The number of components should match the number of arguments in your function.
|
||||
- `outputs`: which Gradio component(s) to use for the output. The number of components should match the number of return values from your function.
|
||||
|
||||
Let's take a closer look at these components used to provide input and output.
|
||||
In this Guide, we'll dive into `gr.Interface` and the various ways it can be customized, but before we do that, let's get a better understanding of Gradio components.
|
||||
|
||||
## Gradio Components
|
||||
|
||||
Gradio includes more than 30 pre-built components (as well as many [community-built _custom components_](https://www.gradio.app/custom-components/gallery)) that can be used as inputs or outputs in your demo. These components correspond to common data types in machine learning and data science, e.g. the `gr.Image` component is designed to handle input or output images, the `gr.Label` component displays classification labels and probabilities, the `gr.Plot` component displays various kinds of plots, and so on.
|
||||
|
||||
**Static and Interactive Components**
|
||||
|
||||
Every component has a _static_ version that is designed to *display* data, and most components also have an _interactive_ version designed to let users input or modify the data. Typically, you don't need to think about this distinction, because when you build a Gradio demo, Gradio automatically figures out whether the component should be static or interactive based on whether it is being used as an input or output. However, you can set this manually using the `interactive` argument that every component supports.
|
||||
|
||||
**Preprocessing and Postprocessing**
|
||||
|
||||
When a component is used as an input, Gradio automatically handles the _preprocessing_ needed to convert the data from a type sent by the user's browser (such as an uploaded image) to a form that can be accepted by your function (such as a `numpy` array).
|
||||
|
||||
|
||||
Similarly, when a component is used as an output, Gradio automatically handles the _postprocessing_ needed to convert the data from what is returned by your function (such as a list of image paths) to a form that can be displayed in the user's browser (a gallery of images).
|
||||
|
||||
## Components Attributes
|
||||
|
||||
@ -19,7 +34,7 @@ We used the default versions of the `gr.Textbox` and `gr.Slider`, but what if yo
|
||||
|
||||
Let's say you want to customize the slider to have values from 1 to 10, with a default of 2. And you wanted to customize the output text field — you want it to be larger and have a label.
|
||||
|
||||
If you use the actual class for `gr.Textbox` and `gr.Slider` instead of using the string shortcut, you have access to much more customizability through component attributes.
|
||||
If you use the actual classes for `gr.Textbox` and `gr.Slider` instead of the string shortcuts, you have access to much more customizability through component attributes.
|
||||
|
||||
$code_hello_world_2
|
||||
$demo_hello_world_2
|
||||
@ -40,17 +55,15 @@ Gradio supports many types of components, such as `Image`, `DataFrame`, `Video`,
|
||||
$code_sepia_filter
|
||||
$demo_sepia_filter
|
||||
|
||||
When using the `Image` component as input, your function will receive a NumPy array with the shape `(height, width, 3)`, where the last dimension represents the RGB values. We'll return an image as well in the form of a NumPy array.
|
||||
When using the `Image` component as input, your function will receive a NumPy array with the shape `(height, width, 3)`, where the last dimension represents the RGB values. We'll return an image as well in the form of a NumPy array.
|
||||
|
||||
You can also set the datatype used by the component with the `type=` keyword argument. For example, if you wanted your function to take a file path to an image instead of a NumPy array, the input `Image` component could be written as:
|
||||
As mentioned above, Gradio handles the preprocessing and postprocessing to convert images to NumPy arrays and vice versa. You can also control the preprocessing performed with the `type=` keyword argument. For example, if you wanted your function to take a file path to an image instead of a NumPy array, the input `Image` component could be written as:
|
||||
|
||||
```python
|
||||
gr.Image(type="filepath", shape=...)
|
||||
```
|
||||
|
||||
Also note that our input `Image` component comes with an edit button 🖉, which allows for cropping and zooming into images. Manipulating images in this way can help reveal biases or hidden flaws in a machine learning model!
|
||||
|
||||
You can read more about the many components and how to use them in the [Gradio docs](https://gradio.app/docs).
|
||||
You can read more about the built-in Gradio components and how to customize them in the [Gradio docs](https://gradio.app/docs).
|
||||
|
||||
## Example Inputs
|
||||
|
||||
@ -75,7 +88,7 @@ There are three arguments in the `Interface` constructor to specify where this c
|
||||
|
||||
|
||||
|
||||
If you're using the `Blocks` API instead, you can insert text, markdown, or HTML anywhere using the `gr.Markdown(...)` or `gr.HTML(...)` components, with descriptive content inside the `Component` constructor.
|
||||
Note: if you're using the `Blocks` class, you can insert text, markdown, or HTML anywhere in your application using the `gr.Markdown(...)` or `gr.HTML(...)` components.
|
||||
|
||||
Another useful keyword argument is `label=`, which is present in every `Component`. This modifies the label text at the top of each `Component`. You can also add the `info=` keyword argument to form elements like `Textbox` or `Radio` to provide further information on their usage.
|
||||
|
||||
@ -94,49 +107,3 @@ Here's an example:
|
||||
$code_interface_with_additional_inputs
|
||||
$demo_interface_with_additional_inputs
|
||||
|
||||
|
||||
## Flagging
|
||||
|
||||
By default, an `Interface` will have "Flag" button. When a user testing your `Interface` sees input with interesting output, such as erroneous or unexpected model behaviour, they can flag the input for you to review. Within the directory provided by the `flagging_dir=` argument to the `Interface` constructor, a CSV file will log the flagged inputs. If the interface involves file data, such as for Image and Audio components, folders will be created to store those flagged data as well.
|
||||
|
||||
For example, with the calculator interface shown above, we would have the flagged data stored in the flagged directory shown below:
|
||||
|
||||
```directory
|
||||
+-- calculator.py
|
||||
+-- flagged/
|
||||
| +-- logs.csv
|
||||
```
|
||||
|
||||
_flagged/logs.csv_
|
||||
|
||||
```csv
|
||||
num1,operation,num2,Output
|
||||
5,add,7,12
|
||||
6,subtract,1.5,4.5
|
||||
```
|
||||
|
||||
With the sepia interface shown earlier, we would have the flagged data stored in the flagged directory shown below:
|
||||
|
||||
```directory
|
||||
+-- sepia.py
|
||||
+-- flagged/
|
||||
| +-- logs.csv
|
||||
| +-- im/
|
||||
| | +-- 0.png
|
||||
| | +-- 1.png
|
||||
| +-- Output/
|
||||
| | +-- 0.png
|
||||
| | +-- 1.png
|
||||
```
|
||||
|
||||
_flagged/logs.csv_
|
||||
|
||||
```csv
|
||||
im,Output
|
||||
im/0.png,Output/0.png
|
||||
im/1.png,Output/1.png
|
||||
```
|
||||
|
||||
If you wish for the user to provide a reason for flagging, you can pass a list of strings to the `flagging_options` argument of Interface. Users will have to select one of the strings when flagging, which will be saved as an additional column to the CSV.
|
||||
|
||||
|
||||
|
||||
@ -4,7 +4,7 @@ In the [previous Guide](/main/guides/the-interface-class), we discussed how to p
|
||||
|
||||
## Providing Examples
|
||||
|
||||
As covered in the [Key Features](/guides/key-features/#example-inputs) guide, adding examples to an Interface is as easy as providing a list of lists to the `examples`
|
||||
Adding examples to an Interface is as easy as providing a list of lists to the `examples`
|
||||
keyword argument.
|
||||
Each sublist is a data sample, where each element corresponds to an input of the prediction function.
|
||||
The inputs must be ordered in the same order as the prediction function expects them.
|
||||
|
||||
46
guides/02_building-interfaces/02_flagging.md
Normal file
46
guides/02_building-interfaces/02_flagging.md
Normal file
@ -0,0 +1,46 @@
|
||||
|
||||
# Flagging
|
||||
|
||||
You may have noticed the "Flag" button that appears by default in your `Interface`. When a user using your demo sees input with interesting output, such as erroneous or unexpected model behaviour, they can flag the input for you to review. Within the directory provided by the `flagging_dir=` argument to the `Interface` constructor, a CSV file will log the flagged inputs. If the interface involves file data, such as for Image and Audio components, folders will be created to store those flagged data as well.
|
||||
|
||||
For example, with the calculator interface shown above, we would have the flagged data stored in the flagged directory shown below:
|
||||
|
||||
```directory
|
||||
+-- calculator.py
|
||||
+-- flagged/
|
||||
| +-- logs.csv
|
||||
```
|
||||
|
||||
_flagged/logs.csv_
|
||||
|
||||
```csv
|
||||
num1,operation,num2,Output
|
||||
5,add,7,12
|
||||
6,subtract,1.5,4.5
|
||||
```
|
||||
|
||||
With the sepia interface shown earlier, we would have the flagged data stored in the flagged directory shown below:
|
||||
|
||||
```directory
|
||||
+-- sepia.py
|
||||
+-- flagged/
|
||||
| +-- logs.csv
|
||||
| +-- im/
|
||||
| | +-- 0.png
|
||||
| | +-- 1.png
|
||||
| +-- Output/
|
||||
| | +-- 0.png
|
||||
| | +-- 1.png
|
||||
```
|
||||
|
||||
_flagged/logs.csv_
|
||||
|
||||
```csv
|
||||
im,Output
|
||||
im/0.png,Output/0.png
|
||||
im/1.png,Output/1.png
|
||||
```
|
||||
|
||||
If you wish for the user to provide a reason for flagging, you can pass a list of strings to the `flagging_options` argument of Interface. Users will have to select one of the strings when flagging, which will be saved as an additional column to the CSV.
|
||||
|
||||
|
||||
15
guides/03_additional-features/01_queuing.md
Normal file
15
guides/03_additional-features/01_queuing.md
Normal file
@ -0,0 +1,15 @@
|
||||
# Queuing
|
||||
|
||||
Every Gradio app comes with a built-in queuing system that can scale to thousands of concurrent users. You can configure the queue by using `queue()` method which is supported by the `gr.Interface`, `gr.Blocks`, and `gr.ChatInterface` classes.
|
||||
|
||||
For example, you can control the number of requests processed at a single time by setting the `default_concurrency_limit` parameter of `queue()`, e.g.
|
||||
|
||||
```python
|
||||
demo = gr.Interface(...).queue(default_concurrency_limit=5)
|
||||
demo.launch()
|
||||
```
|
||||
|
||||
This limits the number of requests processed for this event listener at a single time to 5. By default, the `default_concurrency_limit` is actually set to `1`, which means that when many users are using your app, only a single user's request will be processed at a time. This is because many machine learning functions consume a significant amount of memory and so it is only suitable to have a single user using the demo at a time. However, you can change this parameter in your demo easily.
|
||||
|
||||
See the [docs on queueing](/docs/gradio/interface#interface-queue) for more details on configuring the queuing parameters.
|
||||
|
||||
20
guides/03_additional-features/02_streaming-outputs.md
Normal file
20
guides/03_additional-features/02_streaming-outputs.md
Normal file
@ -0,0 +1,20 @@
|
||||
# Streaming outputs
|
||||
|
||||
In some cases, you may want to stream a sequence of outputs rather than show a single output at once. For example, you might have an image generation model and you want to show the image that is generated at each step, leading up to the final image. Or you might have a chatbot which streams its response one token at a time instead of returning it all at once.
|
||||
|
||||
In such cases, you can supply a **generator** function into Gradio instead of a regular function. Creating generators in Python is very simple: instead of a single `return` value, a function should `yield` a series of values instead. Usually the `yield` statement is put in some kind of loop. Here's an example of an generator that simply counts up to a given number:
|
||||
|
||||
```python
|
||||
def my_generator(x):
|
||||
for i in range(x):
|
||||
yield i
|
||||
```
|
||||
|
||||
You supply a generator into Gradio the same way as you would a regular function. For example, here's a a (fake) image generation model that generates noise for several steps before outputting an image using the `gr.Interface` class:
|
||||
|
||||
$code_fake_diffusion
|
||||
$demo_fake_diffusion
|
||||
|
||||
Note that we've added a `time.sleep(1)` in the iterator to create an artificial pause between steps so that you are able to observe the steps of the iterator (in a real image generation model, this probably wouldn't be necessary).
|
||||
|
||||
Similarly, Gradio can handle streaming inputs, e.g. an image generation model that reruns every time a user types a letter in a textbox. This is covered in more details in our guide on building [reactive Interfaces](/guides/reactive-interfaces).
|
||||
18
guides/03_additional-features/03_alerts.md
Normal file
18
guides/03_additional-features/03_alerts.md
Normal file
@ -0,0 +1,18 @@
|
||||
# Alerts
|
||||
|
||||
You may wish to display alerts to the user. To do so, raise a `gr.Error("custom message")` in your function to halt the execution of your function and display an error message to the user.
|
||||
|
||||
Alternatively, can issue `gr.Warning("custom message")` or `gr.Info("custom message")` by having them as standalone lines in your function, which will immediately display modals while continuing the execution of your function. The only difference between `gr.Info()` and `gr.Warning()` is the color of the alert.
|
||||
|
||||
```python
|
||||
def start_process(name):
|
||||
gr.Info("Starting process")
|
||||
if name is None:
|
||||
gr.Warning("Name is empty")
|
||||
...
|
||||
if success == False:
|
||||
raise gr.Error("Process failed")
|
||||
```
|
||||
|
||||
Tip: Note that `gr.Error()` is an exception that has to be raised, while `gr.Warning()` and `gr.Info()` are functions that are called directly.
|
||||
|
||||
12
guides/03_additional-features/04_styling.md
Normal file
12
guides/03_additional-features/04_styling.md
Normal file
@ -0,0 +1,12 @@
|
||||
# Styling
|
||||
|
||||
Gradio themes are the easiest way to customize the look and feel of your app. You can choose from a variety of themes, or create your own. To do so, pass the `theme=` kwarg to the `Interface` constructor. For example:
|
||||
|
||||
```python
|
||||
demo = gr.Interface(..., theme=gr.themes.Monochrome())
|
||||
```
|
||||
|
||||
Gradio comes with a set of prebuilt themes which you can load from `gr.themes.*`. You can extend these themes or create your own themes from scratch - see the [theming guide](https://gradio.app/guides/theming-guide) for more details.
|
||||
|
||||
For additional styling ability, you can pass any CSS (as well as custom JavaScript) to your Gradio application. This is discussed in more detail in our [custom JS and CSS guide](/guides/custom-CSS-and-JS).
|
||||
|
||||
8
guides/03_additional-features/05_progress_bars.md
Normal file
8
guides/03_additional-features/05_progress_bars.md
Normal file
@ -0,0 +1,8 @@
|
||||
# Progress bars
|
||||
|
||||
Gradio supports the ability to create custom Progress Bars so that you have customizability and control over the progress update that you show to the user. In order to enable this, simply add an argument to your method that has a default value of a `gr.Progress` instance. Then you can update the progress levels by calling this instance directly with a float between 0 and 1, or using the `tqdm()` method of the `Progress` instance to track progress over an iterable, as shown below.
|
||||
|
||||
$code_progress_simple
|
||||
$demo_progress_simple
|
||||
|
||||
If you use the `tqdm` library, you can even report progress updates automatically from any `tqdm.tqdm` that already exists within your function by setting the default argument as `gr.Progress(track_tqdm=True)`!
|
||||
59
guides/03_additional-features/06_batch-functions.md
Normal file
59
guides/03_additional-features/06_batch-functions.md
Normal file
@ -0,0 +1,59 @@
|
||||
# Batch functions
|
||||
|
||||
Gradio supports the ability to pass _batch_ functions. Batch functions are just
|
||||
functions which take in a list of inputs and return a list of predictions.
|
||||
|
||||
For example, here is a batched function that takes in two lists of inputs (a list of
|
||||
words and a list of ints), and returns a list of trimmed words as output:
|
||||
|
||||
```py
|
||||
import time
|
||||
|
||||
def trim_words(words, lens):
|
||||
trimmed_words = []
|
||||
time.sleep(5)
|
||||
for w, l in zip(words, lens):
|
||||
trimmed_words.append(w[:int(l)])
|
||||
return [trimmed_words]
|
||||
```
|
||||
|
||||
The advantage of using batched functions is that if you enable queuing, the Gradio server can automatically _batch_ incoming requests and process them in parallel,
|
||||
potentially speeding up your demo. Here's what the Gradio code looks like (notice the `batch=True` and `max_batch_size=16`)
|
||||
|
||||
With the `gr.Interface` class:
|
||||
|
||||
```python
|
||||
demo = gr.Interface(
|
||||
fn=trim_words,
|
||||
inputs=["textbox", "number"],
|
||||
outputs=["output"],
|
||||
batch=True,
|
||||
max_batch_size=16
|
||||
)
|
||||
|
||||
demo.launch()
|
||||
```
|
||||
|
||||
With the `gr.Blocks` class:
|
||||
|
||||
```py
|
||||
import gradio as gr
|
||||
|
||||
with gr.Blocks() as demo:
|
||||
with gr.Row():
|
||||
word = gr.Textbox(label="word")
|
||||
leng = gr.Number(label="leng")
|
||||
output = gr.Textbox(label="Output")
|
||||
with gr.Row():
|
||||
run = gr.Button()
|
||||
|
||||
event = run.click(trim_words, [word, leng], output, batch=True, max_batch_size=16)
|
||||
|
||||
demo.launch()
|
||||
```
|
||||
|
||||
In the example above, 16 requests could be processed in parallel (for a total inference time of 5 seconds), instead of each request being processed separately (for a total
|
||||
inference time of 80 seconds). Many Hugging Face `transformers` and `diffusers` models work very naturally with Gradio's batch mode: here's [an example demo using diffusers to
|
||||
generate images in batches](https://github.com/gradio-app/gradio/blob/main/demo/diffusers_with_batching/run.py)
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# Sharing Your App
|
||||
|
||||
How to share your Gradio app:
|
||||
In this Guide, we dive more deeply into the various aspects of sharing a Gradio app with others. We will cover:
|
||||
|
||||
1. [Sharing demos with the share parameter](#sharing-demos)
|
||||
2. [Hosting on HF Spaces](#hosting-on-hf-spaces)
|
||||
@ -108,6 +108,7 @@ export const redirects = {
|
||||
"/gradio-and-llm-agents": "/guides/gradio-and-llm-agents",
|
||||
"/fastapi-app-with-the-gradio-client":
|
||||
"/guides/fastapi-app-with-the-gradio-client",
|
||||
"guides/key-features": "guides/queuing",
|
||||
"/docs/client": "/docs/python-client/client",
|
||||
"/docs/job": "/docs/python-client/job",
|
||||
"/docs/set_static_paths": "/docs/gradio/set_static_paths",
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user