AI Engineer Europe 2026
GPU Cloud Deployment Without Leaving Your IDE — Audry Hsu, RunPod
Read the talk
GPU Cloud Deployment Without Leaving Your IDE
Audry Hsu demonstrates how RunPod Flash moves Python inference functions onto cloud GPUs, then extends image generation into a pipeline with prompt expansion and photo composition.
From a talk by Audry Hsu
Before you start: Familiarity with async Python functions, HTTP requests and the distinction between local code and remote GPU execution will help you follow the demonstration.
From model training to infrastructure work
Yunus, an Oxford attendee, already has a practical reason to use RunPod: his university provides credits, and he spends them on LLM training. That is the starting requirement—access to compute so he can work on a model.
RunPod supplies the GPUs and compute; developers bring their code and models. Audry Hsu describes the work that gets between those two things: aligning CUDA and PyTorch versions, testing new GPU SKUs, resolving hardware-related bugs, and configuring deployment and scaling. Infrastructure configuration competes directly with model development. The platform’s purpose is to move that work out of the developer’s path.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From spare GPUs to deployment options
Hsu traces RunPod’s origins to Zhen and Pardeep, who founded the company in 2022 with basement GPUs left over from a failed crypto-mining venture. They built a prototype and offered free GPU access on Reddit in exchange for feedback. That became a pattern of building in public with the community; Hsu says the company generated revenue from the beginning.
Hsu reports around 500 developers on the platform, more than 30 data centers across 10 countries, and $120 million in annual recurring revenue. She names France, Romania and Iceland within the European footprint, and also mentions Asia Pacific. RunPod’s company announcement separately supports the ARR milestone as a company-reported figure. The customers shown span AI-native companies and large enterprises, connected by a need for flexible, reliable GPU infrastructure.
The product choice depends on how the workload uses that infrastructure:
| Product | Workload fit | Operating model |
|---|---|---|
| Pods | Persistent development or compute environment | Rent on demand, pay by the second, tear down when finished |
| Serverless | Variable request frequency and load | Autoscale workers up and down |
| Clusters | Multi-node training | Coordinate compute across nodes |
| Hub | Quick exploration | Deploy pre-vetted open-source repositories |
A running Pod keeps its GPU reserved for that Pod. Serverless instead adjusts worker capacity to demand; Hsu introduces scale-down as the way to avoid leaving unused capacity running. Hub offers starting points such as ComfyUI, Stable Diffusion and vLLM. The demonstration follows the Serverless route.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Keep the development loop local
During inference development, testing a small code change can require a much larger deployment procedure:
- Commit the change and push it to GitHub.
- Build a Docker image.
- Pull the image from a container registry onto a server.
- Allocate a GPU.
- Test the result, then repeat.
RunPod Flash, a Python SDK, is designed to remove those manual steps from the iteration loop so a function can run on a cloud GPU directly from the local development environment.
The execution boundary is an ordinary async Python function with a Flash endpoint decorator. Flash packages and deploys that function to the GPU cloud, while the surrounding main function and helper functions remain local. File reload repackages and pushes changes so the developer can test again without manually rebuilding and uploading a container. The GPU function moves; local orchestration stays local.
The recording uses the then-demonstrated endpoint decorator and flash run. The current repository documents @Endpoint and commands including flash dev and flash deploy; those should not be read as the exact API shown onstage.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Send an image request through the local server
The first GPU function generates an image with PyTorch and pretrained Stable Diffusion XL Turbo, selected for fast image generation. It saves the image and returns a Base64-encoded representation. The project and dependencies are already installed when Hsu begins running it.
Hsu invokes flash run, which starts a local FastAPI development server. She refers first to image_generation.py and later to image_generation_async while finding the script to run. A local helper sends a POST request to the development endpoint, then decodes the returned image so it can be displayed. The serialization boundary can be expressed with two small Python helpers:
python
import base64
from pathlib import Path
def encode_image(path: Path) -> str:
return base64.b64encode(path.read_bytes()).decode("ascii")
def save_image(encoded_image: str, destination: Path) -> None:
destination.write_bytes(base64.b64decode(encoded_image))
The GPU side returns text representing the image bytes; the local side reconstructs a file from those bytes.
The audience supplies the subject: cats flying through a cloudy London sky. Before that prompt reaches the model, the request needs live troubleshooting around its URL, localhost and HTTP. Once the request gets through, the local server reports that the job has started and entered the queue. This separates two questions that are easy to conflate during a demo: whether the request reached the service, and whether it carried the intended model input.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Configure workers, correct the prompt, swap the model
While the job runs, Hsu returns to the endpoint decorator. It carries the endpoint name, GPU-family selection and worker settings. Her spoken GPU-pool name corresponds closely to ADA_80_PRO, which the GPU pool reference maps to H100 GPUs with 80 GB of memory; the pool identifier is not an architecture name. The demonstration sets a maximum of five workers and one active worker that stays running.
The first output is a dragon. The service has run, but the intended cats prompt was not passed as a flag. Hsu adds the prompt flag and submits again, then points out the idle-timeout setting, which controls how long a worker remains idle. The corrected request produces cats, but their abstract appearance is not the result she wanted.
The next edit changes the model rather than the request path. Hsu comments out the original implementation and substitutes DreamShaper, which she describes as a Stable Diffusion 1.5 fine-tune. Her working comparison is XL Turbo for quick generation versus DreamShaper for the artistic and illustrative quality she wants here. She sets DreamShaper to 25 inference steps, reviews the size parameters, and resends the same cats request.
The change stays inside the IDE: edit the function, let Flash propagate it, and send the request again. There is no manual commit, Docker rebuild, upload or GPU-allocation sequence between those two model trials. Hsu and the audience prefer the new image. The useful result is a shorter development procedure and a preferred output in this session; no timed comparison or controlled image-quality evaluation accompanies it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Add prompt generation and photo composition
A single remote model call is only part of an application. The next example uses prepared orchestration code to connect three stages:
- Call Qwen 3 on an already-hosted public endpoint to generate richer image prompts.
- Send those prompts to DreamShaper on the Flash-managed endpoint.
- Pass the images through Nano Banana 2, Google’s Gemini 3.1 Flash Image, for photo composition.
Hsu’s intended subjects are RunPod’s founders. This extends the local orchestration pattern from calling one GPU function to coordinating prompt generation, image generation and an external composition model.
The audience shapes the new input into two men with glasses walking in London on a cloudy day, with a close-up of their faces. Hsu requests three generated images and starts the pipeline, leaving it running while she answers a pricing question.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Understand what stays running
Asked about pricing, Hsu initially describes a charge for the time each request runs. She then leaves the terminal to inspect the endpoint in the web console. She describes roughly five or six provisioned workers and three running for the three requested photos, before pointing to worker uptime as the billed quantity and discussing an H100 per-second rate.
Worker lifetime, not just inference duration, is the useful cost boundary. Current Serverless billing documentation specifies charges from worker startup through full stop, including initialization, execution and idle timeout; active workers run continuously. That qualifies the request-only shorthand and matters for the always-on worker in this example. Hsu explains Serverless’s premium over Pods through the scaling it provides. Her recommendation is to start experimentation with a low worker count or a Pod when only one or two GPUs are needed, then use Serverless when the application needs hundreds of workers and distribution across data centers for availability.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Inspect the generated and composed images
The finished presentation separates the intermediate image from the final composition. On the left is DreamShaper’s output from Qwen 3’s expanded version of the original London prompt. The expansion adds thoughtful expressions, weathered faces, soft-focus background clouds, a muted urban palette of grays and deep blues, and overcast lighting. Qwen contributes visual direction before DreamShaper turns it into an image.
On the right is the composed photo of Pardeep and Zhen. Hsu jokes that Pardeep looks handsome while Zhen looks unexpectedly old, then scrolls to the reference photo supplied to the composition stage. Showing that reference makes the final operation easier to understand: the pipeline combines the generated scene with a separate photographic input.
The final visible result pair shows generated and composed images beneath golden trees in Hyde Park, London. The workflow still begins in the local development environment, even though the application coordinates remote inference and composition. Hsu closes by extending that starting point beyond the open-source models shown: developers can also bring their own private models.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Python SDK for defining remote GPU functions, dependencies and deployment configuration. The repository documents the current API.
Stability AI's model card and downloadable files for SDXL Turbo image generation.
Lykon's image-generation model repository, with model files and Diffusers usage examples.
The Qwen team's introduction to Qwen3 models, thinking modes and deployment options.
Google's announcement of Gemini 3.1 Flash Image, also called Nano Banana 2, for image generation and editing.
Further reading
- Runpod GPU types and poolsDocumentation
Lists GPU identifiers, memory capacities and pool mappings, including ADA_80_PRO for H100 GPUs.
Updates since the talk
- Serverless billing and worker costsDocumentation
Explains active and flex workers and charges for startup, execution, idle timeout and storage.
Read the complete timestamped transcript
- 0:00
[on hold music] Hey, everyone.
- 0:16
I'm Audry. Um, I work at RunPod. Have-- Were any of you in my earlier session?
- 0:24
Okay, good, 'cause then I'm gonna s- s- This intro is the same, but what I'm gonna show is l- a little bit different. Um, d- has anyone heard of RunPod or used RunPod before?
- 0:35
You have? Do, do you mind if I ask you, um, how you've used us or heard about us before? Yeah, as part of our university, we have some RunPod credits.
- 0:42
So I, I use this as, uh, yeah, for LLM training and- LLM training? Okay, at your university. And where do you go to uni? Uh, u- Oxford. Oxford. Yeah.
- 0:49
I did a study abroad there one summer. It's awesome there. Yeah. [laughs] Okay. Love it. Thank you. Okay. And your name is? Yunus. Yunus. Okay. So Yunus might know a little bit about this already, but I'll, I'll, I'll talk you guys through a little intro.
- 1:02
Um, what do we do? We're a AI cloud infrastructure company. Um, and our mission is to build the foundational platform for developers to scale their AI workloads. And basically, what that means is, um, we bring the hardware, we bring the GPUs, and the compute.
- 1:23
Um, we make it easy for you guys to bring your code, bring your models, and deploy as quickly as possible. We don't want you spending time, um, configuring infrastructure and thinking about things like, um, scaling.
- 1:39
W- why RunPod exists. A lot of teams that we've talked to, they are all wrestling with the same thing. That infrastructure-- They're spending more time with the infrastructure than, than they are with the models.
- 1:49
So things like CUDA version, um, alignment, like what versions of PyTorch run well together, um, which, which, uh, new of the GPU, uh, SKUs, like, have been tested, and, like, keep figuring out the bugs there.
- 2:05
So a lot of that is-- are things that we try to take that, um, configuration problem away from you guys, so you guys can just build, um, focus on training your model or building your apps.
- 2:17
And a little bit of a backstory about our company. So this is Zen and Pardeep, our two founders. Um, they started RunPod in 2022. They had a failed crypto mining venture, so they had a bunch of spare GPUs in their basement.
- 2:34
Um, they built a prototype of what is the foundation of RunPod today, and they just posted on Reddit and said, "Does, does anyone want some free GPUs, um, in exchange for feedback?"
- 2:47
And that is literally how our company started, and ever since then, we've been building with, in public with the community. Um, so we've been revenue generating from the very beginning, um, which is very, very rare.
- 3:00
Um, and even today, we have around five hundred developers on our platform.
- 3:06
We're in thirty-plus data centers across ten countries. Um, in Europe, that includes France, Romania, Iceland, if that's part of Europe, uh, [laughs] Asia Pacific. Um, and we recently hit, um, a pretty big milestone of one hundred and twenty million in annual recurring revenue.
- 3:27
This is just a quick glance of some of the customers that we have. You might be surprised seeing that some of these are AI native companies, um, and some large enterprises as well.
- 3:41
And kind of the bottom line of what they have in common is that they need flexible and reliable GPU infrastructure. So, um, I definitely would say we're punching above our weight class.
- 3:55
Really quick, high level, um, there's different ways to build on RunPod, depending on what you're trying to do. Um, so if you need a more persistent, um, VM environment, then Pods is a great use case.
- 4:07
Um, if you, you can rent a pod on demand, um, pay by the second, and once you're done, you can tear it all down, um, and start again. Pods are if you need, um, reserved GPU, so as long as your pod is running, then the GPU is yours and no one can take it away from you.
- 4:26
Um, serverless, if you have-- if you're ready to deploy something and you, and, and you care more about scaling, so your workloads are more variable in terms of, um, frequency and load, um, we help you auto scale, um, your workers for you and scale them back down when you don't have any requests happening, so you don't pay
- 4:45
for, um, any idle time. Um, clusters, great use case for training, multi-node. And then Hub is also, um, a place where you can deploy already, uh, open source AI repos that have already been pre-vetted by us for popular models, um, like ComfyUI, um, Stable Diffusion, um, vLLM.
- 5:11
Um, and that's one way if you're just exploring, uh, to just click around and get started really quickly.
- 5:18
Uh, I'm gonna talk about serverless, um, today, and the product that we just...
- 5:26
And I'm gonna switch my displays again here really, really quick so we can mirror my screen.
- 5:43
So one of the things that is a huge pain for developers is if they're still in the iteration or the development phase. So normally, um,
- 5:54
when you are working on, let's say, some, some code around your, um, inference model and you're still testing things out, you have to make a commit- Push it to GitHub, um, build your Docker image, um, pull it down from the i- um, container registry, [smacks lips]
- 6:13
um, and then load it onto a server, and then allocate a GPU on it, and then you get to test it and see if it's working as you expected.
- 6:21
And then you do that all over again [chuckles] until, until you're ready. So the problem that Flash is trying to solve here, and Flash is our Python SDK, is that we want to eliminate all of that iteration cycle so that you can, um, deploy your function on a GPU right from your local development environment.
- 6:45
And I'll zoom in here really quick. So this is all you need to know about Flash in one little paragraph, is it's... You have a regular async Python function.
- 6:58
You add our Flash endpoint decorator, and it's gonna deploy and package everything inside your function onto a GPU cloud. Everything ar- around it, your, uh, main function, any helper functions that you have, those all run on your local development environment.
- 7:15
But if you need GPU compute, that, that can run, um, on the cloud, and you can... We have hot mod, uh, h- file reload, so if you change anything in your application anywhere, then it gets repackaged and pushed up immediately, and you can test and iterate super quickly.
- 7:33
And I'm just gonna show an example of this.
- 7:42
Okay. So I have a function here, generate image. Simply, I'm loading PyTorch. I'm loading a pre-trained Stable Diffusion model, Stable Diffusion XL Turbo.
- 7:59
Really great for fast, uh, generation of images. And [smacks lips]
- 8:05
I'm going to save the image down and that... gonna return it Base64 encoded. [smacks lips]
- 8:12
So I can run this right now here. I've already, um, installed all my dependencies. I already have a Flash project going. I'm going to flash run,
- 8:27
uh, image_generation.py. And what I'm going to actually do is I have a little [keyboard clacking]
- 8:34
flash, flash run. So Flash Run spins up a local development server here. Uh, it's just a FastAPI server, and I can send my request here
- 8:52
to this endpoint, and I'm gonna do that really quickly. Just get to, to my project. And [keyboard clacking]
- 9:06
this is just a little helper script that's gonna send a post request to it and then, um, decode that image so that you guys c- actually get to see what it looks like once it's generated.
- 9:20
And it was image_generation_async. Here we go. [keyboard clacking] And let's pass a prompt to it.
- 9:38
Can I get a help from the audience? [chuckles] What do we wanna generate today? [chuckles]
- 9:43
Literally anything, anything random. Cats flying in the sky. Okay. Cats flying in the sky. W- what does the sky look like? What time of day is it? Cloudy. Um- London.
- 9:56
London ... in London. Yeah. Flying in, flying on a cloudy day in the sky
- 10:05
s- somewhere in London, and I passed it correctly.
- 10:17
He's, he's looking at it so closely. He's helping me debug live. I love it. [laughs] Thank you. [laughs] It's super hard to see in dark mode, but, uh-
- 10:26
I passed URL, and that's true. Based after a localhost? Um.. [keyboard clacking]
- 10:39
I must have... Oh, you've got your... Oh, no, never mind Is it my HTTP?
- 10:53
Okay, there we go. Okay. Going back to the local dev server.
- 11:05
It sees the request. It's started the job. It's queued it.
- 11:14
And we're just gonna wait for a second to see if it finishes. And so while that's happening, let me bring your attention back to... [sighs]
- 11:28
Make it bigger for you guys. [smacks lips] Um, the endpoint decorator. So this is where all the magic happens.
- 11:38
I have passed a name for my endpoint. I specify a GPU family, um, so the Ada 80 Pros, these are different variations of NVIDIA H100 cards. Um, I can specify my max number of workers to be five, so I can have at max five of them running at once.
- 11:57
Um, I just put one active worker, so this is one that's always gonna be running and always on, [smacks lips] and that's definitely a dragon. [chuckles]
- 12:06
And it didn't take my prompt probably because I...
- 12:11
Did I not pass it as a... I didn't pass it as a flag.
- 12:21
Prompt, there we go. Okay, now it's definitely generating cats flying.
- 12:30
Okay, back to the endpoint decorator. Um, and then there's other different configurations for timeout, which is how long, um, a worker is idle. Here we go.
- 12:41
Okay, this looks terrible, guys. [laughs] They are cats. They're abstract cats. Um, and I'm not from London, but maybe someone can tell me if this looks like a London Jimny.
- 12:56
Maybe? Oh, yeah. [laughs] Okay. So I don't, I don't, I don't like, I don't like what just happened, so what we're going to do instead is we're going to switch out our model.
- 13:08
So I'm just gonna comment out this code here,
- 13:12
and then down here let's swap in DreamShaper, which is a fine-tuned, um,
- 13:24
model based off of Stable Diffusion 1.5. Um, so this one is while... where Stable Diffusion XL Pro is, um, more optimized for just quick generation, I think this one is gonna generate a more, uh, a better quality image for us, and it's specifically better for kind of like more art and illustrative styles.
- 13:46
So we've changed some of the parameters in it. It's gonna have a few more, um, inference steps to it. Just gonna set that to 25. Height and width, 10 by 24.
- 13:57
That's fine. And let's just send the same request again,
- 14:03
and let's see what happens, what's different. So again, what made this really fast is instead of making a code change, committing it, rebuilding my Docker, uploading it somewhere, and then allocating GPU infrastructure, all of this is happening right here from my IDE, and I never have to leave.
- 14:28
Oh, it's good. This is good, right, guys? Mm-hmm. We like this one?
- 14:34
Okay. So one more... one last thing that I'm just gonna show you guys to round things out is I think where, um, using a developer tool like Flash makes a big difference is when you're trying to, um, not just, like, make one single call to one model.
- 14:52
It's, it's about all the orchestration code around it, right? So I have here a pipeline that I've pre-prepared, um, and what it's going to do is instead of me generating and writing out every prompt, um, it's gonna send a request to Qwen that's already hosted on a public endpoint.
- 15:13
Um, and Qwen is g- Qwen 3 is gonna generate all the prompts for me. Um, and then after that, it's gonna send that to our, um, DreamShaper running on our endpoint, and then, um, after that, there's one more pipeline that it goes through.
- 15:29
It's gonna send the request to NanoBanana 2, which is a premium Google model that's really good at composing photos together. Um, and I'm hoping that I can compose some cool pictures of our founders, and I can send them to them after this demo is done.
- 15:47
Okay. Um, now let's run the whole pipeline here.
- 15:56
And check... Okay. Prompt, two men walking in London on a... It is cloudy today.
- 16:10
Cloudy tay. Close up of their faces. Um, any other requests for these two men?
- 16:21
AI engineers? AI engineers? I don't know if it's- How do they look? Like, are they doing something?
- 16:28
Glasses? I don't know. Glasses? Yeah. Okay. Two men
- 16:34
with glasses. Close up of their faces. Okay, and let's generate,
- 16:43
let's generate three of those, and let's compose it together.
- 16:55
Okay. And so, so how does it work in terms of pricing? Pricing? Sure. Um, so every request that we send to it, you're only charged for how long that request is running.
- 17:07
So let's see. I'm gonna... I said this whole session was gonna be only in the terminal, but I'm gonna go back into the console just to show you what's, what's running.
- 17:21
Let's see. This is the endpoint that we created from the terminal. Um, here are the workers.
- 17:32
I think we said, like, five workers, so we have about five or six here that are provisioned. Um, three of them are running 'cause I asked for three photos.
- 17:40
Um, and so this is uptime. This is what you're being charged for, and let me see the cost of an H100 right now is .00116 cents per second.
- 17:57
Is it the same as for a pod, or is it, uh... or is this pricing a bit different? Pricing is a little bit different for serverless versus pods because pods, um, you don't get any of the scaling with it.
- 18:08
So there's a little bit of a premium for serverless. So what we usually recommend is if you're still, um, experimenting- Then either start with a very low worker count or start with pods, right?
- 18:19
'Cause when you're experimenting, you might only need limited number of GPUs, one GPU at a time, two GPUs at a time. Um, serverless for when you need hundreds of workers running on hundreds of GPUs, and you want them distributed for a better availability across different data centers. [laughs]
- 18:40
Okay, guys. Here, [laughs] here's th- here's our final presentation. So this was our original prompt, two men with glasses walking in London on a cloudy day, close-up of their faces.
- 18:49
So on the left, this is what, um, DreamShaper generated based off of the, um, prompt engineering that Qwen 3 did for us. So it's a lot better of a prompt than what I sent in.
- 19:02
It has a lot better cues about notes on, like... I can read it out to you since I know it's hard to see. Um, "Thoughtful expressions and weathered faces.
- 19:12
Soft focus on background clouds. Muted urban palette with grays and deep blues. Overcast lighting."
- 19:19
Um, and then on the right is the final composed photo, um, of... This, this is a hand- this is a very handsome picture of Pardeep, and this is somehow a [laughs] very old photo of Zed.
- 19:32
And I'm just gonna scroll down to show you that this is the reference photo that I sent it. [laughs] [laughs]
- 19:41
Um, but overall, um, overall, yeah, I just wanted to show you guys, like, this is how you can get started really quickly. Um, you can start in your local development environment.
- 19:52
You can use open sourced models. You can use bring your own model, um, private model. Um, and this was really fun to do. So thank you guys for hanging out with me. [clapping] [outro jingle]