Skip to content

Practice: Build and share a demo

Seven short questions. Answer each before opening the collapsible.

1. What are the three arguments to gr.Interface, and what does each do?

Show answer

fn (the Python function to run), inputs (the input component type), and outputs (the output component type). fn can be any function; in an AI app it calls your model. inputs and outputs define what kind of UI components wrap it (text boxes, images, etc.).

2. How do you turn a gr.Interface into a running app?

Show answer

Call .launch() on it. In a notebook the interface renders inline; from a script it serves at http://localhost:7860. That single call starts the web server and the UI.

3. To demo a transformers model, what goes inside fn?

Show answer

Your inference code: load a model or pipeline, then write a function that takes the user’s input, runs the model on it, and returns the result. Gradio wraps the UI around that function, so the fn is just the inference you already know how to write.

4. What is the difference between inputs="text" and inputs=gr.Textbox(...)?

Show answer

"text" gives a default text box (Gradio even infers the label from your function’s parameter name). Instantiating gr.Textbox(label=..., placeholder=..., lines=...) lets you customize it. Strings are shorthand for the default; the class gives control.

5. What does launch(share=True) do, and what is its limitation?

Show answer

It creates a temporary public URL (about 72 hours) that tunnels to the demo running on your machine, so you can send someone a link to try right now. The limitation: it only works while your notebook or script keeps running, and the link expires.

6. How do you give a demo a permanent home, and what does it need?

Show answer

Publish it to Hugging Face Spaces (the same Hub as models and datasets). A Space is a Git repo with an app.py (your Gradio code) and a requirements.txt (its dependencies); push those and the Hub builds and hosts the demo for free at a stable URL, running on its own machine.

7. When would you reach for the Blocks API instead of gr.Interface?

Show answer

When the simple one-function-with-inputs-and-outputs shape does not fit: custom layouts, multiple panels or tabs, or components that update each other. For most demos Interface is enough; Blocks is the lower-level option for when it genuinely is not.

About 12 minutes in a notebook. You will wrap a real model in a UI and get a shareable link.

Part A: a model demo in a few lines. Build a text-generation demo:

from transformers import pipeline
import gradio as gr
model = pipeline("text-generation")
def predict(prompt):
return model(prompt)[0]["generated_text"]
gr.Interface(fn=predict, inputs="text", outputs="text").launch()

Type a prompt into the rendered interface and watch it complete.

What you should see, and why

A text box, a submit button, and an output area, rendered inline (notebook) or at localhost:7860 (script). The model you loaded with pipeline runs through your predict function, and Gradio handles the entire UI. You wrote zero frontend code; the interface is generated from the fn and the component types.

Part B: customize and share. Give the input box a label and request a public link:

box = gr.Textbox(label="Your prompt:", placeholder="Once upon a time", lines=3)
gr.Interface(fn=predict, inputs=box, outputs="text").launch(share=True)
What you should see, and why

The input box now has your label, placeholder, and three lines, and launch(share=True) prints a temporary public URL you can open from another device or send to someone. Note it works only while this cell keeps running, which is exactly why a permanent demo belongs on a Space.

Part C (reasoning). You want a colleague to try your model next week while you are on vacation, with your laptop off. Does share=True work, and what is the right approach?

What you should notice

No. The share=True link tunnels to the demo running on your machine, so it dies when your laptop is off (and the link expires in about 72 hours anyway). The right approach is to publish to Hugging Face Spaces: push an app.py and requirements.txt, and the Hub hosts the demo on its own machine at a stable URL that works regardless of your laptop.

Nine cards. Click any card to reveal the answer. Use the Print flashcards button to lay the set out one card per page for offline review.

Q. What are the three arguments to gr.Interface?
A.

fn (the function to run), inputs (input component type), outputs (output component type). fn can be any Python function; in an AI app it calls your model.

Q. How do you start a Gradio demo?
A.

Call .launch() on the Interface. It renders inline in a notebook or serves at localhost:7860 from a script.

Q. How do you demo a transformers model with Gradio?
A.

Load a model or pipeline, write a function that takes user input, runs the model, and returns the result, then pass that function as fn to gr.Interface. Gradio wraps the UI around it.

Q. inputs='text' vs inputs=gr.Textbox(...)?
A.

The string gives a default text box (label inferred from the parameter name). Instantiating gr.Textbox(label=, placeholder=, lines=) lets you customize it. Strings are shorthand; the class gives control.

Q. What does launch(share=True) do?
A.

Creates a temporary public URL (~72 hours) tunneling to the demo on your machine, for a quick share. It only works while your notebook/script keeps running.

Q. How do you host a demo permanently?
A.

Hugging Face Spaces: push an app.py (Gradio code) and requirements.txt to a Space repo; the Hub builds and hosts it for free at a stable URL on its own machine.

Q. What do Gradio components represent?
A.

Your model’s input and output types: gr.Textbox, gr.Image, gr.Audio, gr.Label, gr.Slider, and more. Matching components to the model defines the kind of demo (image in + label out = classifier).

Q. When do you use the Blocks API instead of Interface?
A.

When the one-function-with-inputs-and-outputs shape doesn’t fit: custom layouts, tabs, multiple panels, or components that update each other. Interface covers most demos; Blocks is the lower-level option.

Q. Why does shipping a demo matter?
A.

A model nobody can try is a model nobody trusts. A demo closes the gap from ‘I trained something’ to ‘people use it’, enables non-coder feedback, and surfaces real-world failure cases a metric hides.