Build Lightning-Fast AI Apps with Gradio and SambaNova

The second episode of DevTalks features Abu Bakr, who founded Gradio while completing his PhD in applied machine learning at Stanford and now serves as Head of Applications at Hugging Face following Gradio’s acquisition. The session covers what Gradio is, what changed in Gradio 6, how to use SambaNova as an inference provider through Hugging Face, and a question worth asking directly: why use a high-level framework at all when an LLM can write your front end for you.

TL;DR

• Gradio turns a Python function into a web UI, an API and an MCP server. The same app can be consumed by a person in a browser, a script over REST, or an LLM in an IDE, with no separate work for each.
• Gradio 6 is faster, lighter and far more customizable. The front end migrated to Svelte 5, the API gained live auto-generated docs, and the HTML component can now build fully custom components.
• The framework still earns its place in AI-assisted coding because an app can stay a single Python file with one language, one test suite and security practices already handled.
• SambaNova is selectable as an inference provider on Hugging Face, so a reasoning model can be wrapped in a Gradio app with one call and no separate infrastructure.

What is Gradio?

Gradio is an open-source Python library for building web-based machine learning apps, with good engineering practices baked in. It is used by around a million developers every month. The design goal was to make it simple to build solid web applications entirely in Python, the language most ML developers already work in.

The core pattern is short. You write a Python function, pass it into an interface along with the input components it needs and the output components it returns, then launch it. The components are predefined: a text box for a prompt, a gallery for images, a number field for a count. Calling the queue method adds a queuing system that handles thousands of concurrent users, which matters as soon as the app is deployed anywhere real. Adding a single share parameter generates a public link that lets anyone try the demo while the compute continues to run locally.

One Python function, three interfaces

The part that is easy to miss is that Gradio does not only produce a UI. The same function also becomes an API and an MCP server.

Using a Gradio app via API

Every launched Gradio app carries a "use via API" link at the bottom. Clicking it returns instructions for calling that specific app programmatically, with snippets for the Python client, JavaScript and curl. Combined with a public share link, this means an app built locally can be queried by anyone, from any of those environments, without deploying anything.

Exposing the same app over MCP

Setting the MCP server parameter to true turns the app into an MCP server usable from Claude Code, Cursor or any other LLM client. The one thing worth doing is annotating the function so the model has context on how to use it. Gradio 6 extends this to building ChatGPT apps, which means custom UIs that render inside the LLM rather than just a tool that returns text.

What is new in Gradio 6

Gradio 6 was built against three goals: make it faster, make it sleeker, and make it infinitely customizable.

Faster and lighter

The Python side runs on FastAPI, and the prepackaged front-end components are written in Svelte. Migrating the underlying framework to Svelte 5 made Gradio substantially faster, to the point that apps feel noticeably quicker. Install size also dropped, which matters when Gradio is a dependency of something else you are shipping.

A faster API with live documentation

The Gradio 6 API is significantly faster and returns useful metadata, including ETAs when several people are hitting it at once. Audio, images and video stream out of the box, so an image generation workflow can emit partial results. Documentation is auto-generated and stays current with what you built. It is also live in a second sense: your most recent interaction with the UI populates the example queries, so the sliders and uploads you just used become the programmatic example.

Custom components without the walled garden

This is the change Abu Bakr calls the most important. In earlier versions the HTML component displayed static markup, and building a genuinely custom component meant knowing Svelte, installing Node and running Gradio’s build process. In Gradio 6 the HTML component can define entire templates populated from the component’s value, take props, use scoped CSS, trigger custom events like click or double click, and act as an input component. Subclassing it produces reusable components with whatever attributes you choose. The practical result is that a custom component is now basic HTML and JavaScript, which an LLM writes well if you paste a few examples from the guide in as context.

Using SambaNova inference through Hugging Face

On Hugging Face you can filter models by the providers that serve them and select SambaNova, which means you can use SambaNova RDU-backed inference without going through SambaCloud separately. In the demo, DeepSeek R1 is a reasoning model that would normally take a while to think through a question, and the answers come back immediately.

Wrapping that in an app is one line. The load function takes a Hugging Face model name and a provider, set here to SambaNova, and launching it generates a working UI you can then customize or share via a public link. One Hugging Face API call lets you switch both the model and the provider behind it.

Why use a framework when an LLM can write the front end

Abu Bakr raises the objection himself: Gradio lets you build front ends without knowing JavaScript, HTML or CSS, but so do LLMs. Four reasons developers still reach for the framework.

• You keep thinking in Python. ML developers think in inputs and outputs, arrays, images and text, not DOM events and state management. An AI-generated app tends to sprawl across many front-end files, where a Gradio app is often a single Python file, which matters when you come back to maintain it.
• A monolingual codebase means unified tooling. Unit tests through to end-to-end tests all run in pytest. Linting and development happen through uv and ruff. No separate front-end server to run, and hot reload is built in.
• A smaller surface for bugs. Good security practices come with the framework, so things like CORS and auth are handled rather than being yours to get wrong.
• Fewer lines, fewer tokens. Gradio apps are more concise, whether you or a model is writing them.

Trackio: the argument in practice

Trackio is a free, local-first experiment tracking library built on Gradio, with the same API as Weights and Biases. The motivation was that comparable tools are cloud-first, requiring an account and leaving your logs inside someone else’s system, a risk illustrated by Neptune being acquired and shutting down its experiment tracking.

Because it is built on Gradio, the entire thing including the dashboard is Python: roughly 5,000 lines covering the front end, logging and deployment, with all four test types running in Python. Where a UI element was not supported, a custom component holds about 280 lines of HTML and JavaScript isolated in one file. Abu Bakr’s wider point is about what open source is worth when writing software is cheap: the value is forking something that mostly fits your workflow rather than rebuilding it, and a concise Python codebase is one an LLM can read and modify with far fewer tokens.

Practices worth copying

Reviewing Microsoft’s Trellis space, which converts a 2D image into a 3D object, the session picks out four things it does well.

• Publish on Hugging Face Spaces. It is free, and it puts the app in front of a community instead of leaving it on localhost.
• Make it Zero GPU compatible. Zero GPU is Hugging Face hardware that lets the community share GPUs, so people can try your app without you covering inference costs. It is a one-line decorator.
• Provide examples. Users should not have to hunt for a suitable input file before they can see what your app does.
• Use the walkthrough component for multi-step flows. Cramming several stages into one screen makes an app noisy; the walkthrough component paces the user through the steps.

The Q&A also covered combining MCP servers. Spaces can be filtered to MCP-compatible apps, of which there are several thousand, and a library called tool sets bundles several into one so you do not have to register them individually or load every tool up front. The delegation angle came up too: an expensive frontier model can hand work like summarization to an MCP server backed by a fast open-source model, which is where inference speed and per-model cost start to matter.