AI Engineer World's Fair 2026
AI Apps in a Flash: Ship to GPUs Without Docker — Dean Quiñanola, Runpod
Read the talk
AI Apps in a Flash: Ship to GPUs Without Docker
Dean Quiñanola develops one Runpod Flash function from a GPU check into text and image generation, then deploys it as a hosted backend. The live demo shows what Flash removes from development—and where cold starts, rollouts and model behavior still matter.
From a talk by Dean Quiñanola
At a glance
Ideas worth remembering
Flash removes manual Docker builds and image pushes from the demonstrated iteration workflow; remote worker startup and deployment still take place.
flash devprovides a local FastAPI interface for remote GPU execution, including code changes and dependency installation during development.Live iteration still requires attention to rollout state: the image-generation demo initially encountered an older running version.
flash deploypackages and uploads the application for hosted serving; callers use the resulting deployment ID rather than the local development server.A completed inference request proves the execution path worked, while the missing string-cheese and bow-tie details show that output quality remains a separate concern.
A code change should not require another image push
A small AI application change can trigger a surprisingly long deployment sequence: edit the code, build a Docker image, push it to Docker Hub, execute it, inspect the result—and repeat if something went wrong. Dean Quiñanola, a staff engineer at Runpod, opens with a personal estimate: depending on the change, one pass through that loop sometimes takes about fifteen minutes.
Runpod Flash aims to remove that repeated packaging work from development. The desired interaction is familiar: write Python, execute it, inspect the result, then edit and execute again. The GPU lives in the cloud, but testing should feel close to working with a local GPU. Deployment remains a separate step; the immediate goal is to shorten the distance between a code change and its observable result.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Local-looking functions, remote endpoints and shared caches
At the time of the recording, Flash primarily targets serverless endpoints, with support for pods described as work in progress. It offers both queue endpoints and load-balanced endpoints. Quiñanola does not develop their scheduling differences here; the feature tour concentrates on how Python code can use remote compute without requiring the developer to manage every server connection.
Three capabilities support that development experience:
- Endpoint-to-endpoint calls. A function can call another function even when they are deployed to different endpoints. Flash handles the communication underneath the local-looking call, removing the need to write the server-contact plumbing for each connection.
- Network volumes with warm caching. Attached network volumes carry cached material across serverless scale-up. The useful distinction is where the cache lives: it can remain available through the volume rather than being confined to one worker.
- Live serverless. Developers edit and test code through a workflow that feels local while execution uses remote resources. The CLI also provides the route from that development session to a hosted inference service.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Start with a function that identifies its GPU
The demo follows one function as its job grows. Initially, it asks Torch what GPU is available. Running flash dev launches a local FastAPI server that provides a place to exercise the function. Executing the request provisions a serverless endpoint, which then appears in the Runpod console. Localhost is the development interface; the GPU work happens remotely.
Provisioning still takes work. Quiñanola opens the logs, waits for the worker and identifies a cold start. The container logs expose startup and health checks before the job completes. Flash has removed the developer's manual image-building sequence, but this first request still waits for a usable remote worker.
What confirms that the function actually reached a GPU? Its returned hardware information identifies an NVIDIA GeForce RTX 4090 and includes RAM and GPU-count information. That result gives the next edits a concrete starting point: the function already executes on the remote machine, so the demo can now change what it does.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Add text generation and install dependencies during iteration
The next edit adds text-generation code and Python dependencies to the same function. Quiñanola deliberately tries it without a Hugging Face token first. The development interface refreshes, and he submits “Is string cheese real?” The run installs dependencies on the fly and emits a warning about contacting the Hugging Face server without the token. These are the useful things to inspect together: the dependency change, its installation during execution and the authentication warning.
The request completes, but its answer is unhelpful: “I'm sorry, but I cannot provide answers.” Quiñanola's response—“that's spicy”—captures the difference between successfully running inference and obtaining the answer you wanted. The infrastructure has delivered a model response; the response itself needs another look.
He enables the Hugging Face token through a code change, then changes the prompt to “Who is Batman?” The next completed response identifies Batman as a fictional character. Because both authentication and the prompt changed, this does not establish that adding the token corrected the earlier refusal. It does demonstrate another edit-and-execute pass without a manual Docker build or registry push.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Image generation exposes a rollout still serving old code
The function's next job is image generation. After the code refreshes, the localhost interface exposes generate image, and the prompt combines the previous examples: create an image of string cheese Batman. The workload has changed from reporting hardware, to generating text, to producing an image, while the development entry point remains the same.
This time, the logs show a rollout in progress. Quiñanola finds that the older version is still running and terminates it rather than waiting for the rollout. The replacement then uses the new version. Live development therefore still involves deployment state: refreshing the local interface does not by itself mean every remote worker has already switched to the edited code.
The new run returns a base64-encoded image. Quiñanola prepares that output for display and renders it in the browser. How closely does the result follow the prompt? His verdict is immediate: “That's not string cheese.” The example demonstrates a completed remote image-generation path, while also showing that successful execution does not guarantee the requested visual detail.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
End the development session, then deploy a hosted backend
Canceling the development session deprovisions its endpoint; Quiñanola checks that it disappears from the console. This gives the temporary development environment a clear lifetime. To make the application available beyond that session, he runs flash deploy.
The command packages the application, creates an archive, builds Flash, uploads the result and deploys it on Runpod's servers. “Without Docker” describes the developer-facing workflow: there is no Dockerfile, manual image build or registry push in this sequence. Packaging and remote serving still happen, and the earlier demo exposed container logs underneath the abstraction.
The prepared request needs the new deployment's ID. After finding it, Quiñanola updates the request and asks for a cute baby sea otter with a bow tie. This call uses the hosted backend rather than localhost, making it the path a customer-facing application could use. Worker logs show the remote execution, and the completed request prints its output for display.
The rendered sea otter has no bow tie. As with string cheese Batman, the inference service completes the request while the generated image misses part of the specification. The demonstrated result is an application that can receive a request and return an image independently of the local development server; it is not a demonstration of reliable prompt adherence.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Fan experiments out across endpoints, then start from an example
The closing example expands from a single inference function to a batch of experiments. A hackathon project wraps Flash with an interface for uploading a data sheet containing experiments, specifications and models. The wrapper fans the work out, creates endpoints, runs training and reports results back. The data sheet becomes the input for distributing multiple experiments instead of manually setting up each endpoint.
Quiñanola reports that the participant built the project in three to four hours despite starting without knowledge of Flash, asking along the way whether the idea was possible. It won the previous day's hackathon. This is an anecdote about how quickly someone assembled an orchestration layer on top of Flash; the talk does not provide training-throughput or cost measurements for it.
The suggested starting sequence is straightforward: create a Runpod account, install Flash, write code and log in so the API key is available. Initialization can supply a skeleton application. Then choose flash dev for the local development interface or flash deploy for a hosted application.
The strongest practical recommendation is to study the Flash examples repository for existing cases before building your own. Quiñanola also suggests opening that repository with Claude Code so the coding assistant can use its examples as context, and mentions available skills. The ending returns to the same working unit as the demo: start with code you can exercise, change its job, inspect the remote result, and deploy when it is ready to serve.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Read the complete timestamped transcript
- 0:12
Hello, good afternoon, everyone. I'm, uh, Dean Quiñanola from Runpod Flash, and, um, I wanna talk to you about how you might be able to deploy AI applications without Docker. So currently, this is how you deploy a serverless application. Well, especially AI applications. You write code, you build your Dockerfile, you run a bunch of commands, Docker build, all that, and then you
- 0:42
push the image to Docker Hub. Then you execute it. Then maybe you'll get what you want. If, if not, you have to change your code again, rebuild it, re-push it, execute. Um, in my experience, sometimes this one loop takes about fifteen minutes depending on the changes you're doing. So my name is Dean Quiñanola. I am a staff engineer at Runpod, and I have an entire team that's working on making that easy.
- 1:13
So why did we build Flash? Development iteration loop requires a makeover. It's really a hassle. A lot of you guys are software engineers or ML engineers who really don't wanna deal with all the DevOps. So as you're working on your ideas or you... as you're working on your experiments, you want the results. So no more need for Docker. Run code like it's local, as if you have the GPU. Uh, test your changes instantly, and debug
- 1:42
quickly if you need to. So this is how we're thinking about keeping it simple. You write your code, you execute. You get the results. Rewrite your code, execute, you get the results, right? Of course, there's the deployment part. I'll talk about that later.
- 2:02
So it's so simple, it feels like it's running locally. So what are the features that we have? So we are able to build and deploy faster. We optimize the resource utilization. There's a lot of tricks happening under the hood, and it's intuitive. It's just Python code. It's really whatever you can run locally with a GPU, just do it on the cloud. So what can you do with Flash today? We have serverless endpoints. It's mostly locked on serverless right now, but we're working towards doing it for pods.
- 2:32
Uh, we have queue endpoints for it and load balance endpoints that you can use it for. Here's the, uh, really cool feature that I put in, an endpoint-to-endpoint communication. Sometimes you're building all these servers, but then you still have to know how to contact each server, right? You don't have to do that with this 'cause it's just a code talking to another code. You execute a function, and it looks like it's just local. But once you deploy it in different endpoints, it's all talking to each other. It's all
- 3:02
happening under the hood. We also have network volume attachments. Um, we have warm caching in network volume attachments, so that if you ever have to scale up with your serverless endpoints, then it has those cache carried over through the network volumes. And then the most important part is the live serverless. Uh, you are coding and testing as if it's all happening in your local system. And then, you know, it-- this would just be a toy project if you can't deploy to production, right?
- 3:33
So you wanna deploy to production, so serve the inference, serve all the, uh, stuff that you're building, and we're making that possible all through the CLI. So let's get a demo. Hopefully, I can do this with one hand.
- 3:48
Okay. All right. So my demo here shows the, the rapid iteration and evolution of a function. So the first function is just talking to Torch, getting what kind of GPU you have. So I'll do this live. I'll do flash
- 4:09
dev. And what this does is it launches a FastAPI localhost, so you can actually toy around with it. So now you wanna try it out. Let's try it out. Execute. So it's provisioning this serverless endpoint, and if we go to Runpod console, refresh this, you'll see this. This is running now.
- 4:33
And as it's loading,
- 4:36
let's, let's show the logs so you can actually see it.
- 4:44
All right. Worker is ready.
- 4:52
Yep.
- 5:02
Oh, print job.
- 5:06
Cold start. This is common with all serverless platforms.
- 5:13
Oh, there it is. So it's running. We got logs, container logs. So it's testing all these things, making sure it's all healthy, and it ran the job. So now if we go back here, you'll see the result. It ran on an NVIDIA G-Geforce RTX forty ninety. You see all the RAM, GPU count. Now, here's the kicker. What if I wanna change this function and just wanna test it? So here's a different
- 5:43
iteration of this function. What we do is we add more code, and this code really just does generation of text. And I've added some dependencies, the Python dependencies there. Oh, actually, let's do this without the Hugging Face token first. Let's see what's happening. See, it refreshed everything. I refresh this. Test it again.
- 6:11
What prompt do we need? Uh, let's do string cheese. Is it real?
- 6:19
Run it.
- 6:22
You see it again here.
- 6:30
Container. Okay,
- 6:33
it's coming up. You'll see all the... The, the logs are simpler here because you're not supposed to be inundated with so much stuff. But what it's doing is it's, on the fly, installing the dependencies, and it even gave me a warning about communicating with the Hugging Face server without the token, and it should be finished. Okay, now it's finished, let's see the result. I ask, "Is string cheese real?" "I'm sorry, but I cannot provide answers."
- 7:05
All right, that's, that's spicy. All right, let's, let's change that up. Let's enable my HF token. That's just changing the code, right? Now, we release this again. Let's change the, uh, prompt.
- 7:25
Let's see.
- 7:29
Who is Batman? Let's execute that.
- 7:35
Ready. All right. Let's see. How is this working here?
- 7:41
It's cool. I'm doing this with one hand.
- 7:46
All right, that's finished. Now we see the result. Oh, there you, there you go. "Batman's a fictional character." All right. We knew that. Let's go for something that's more intensive than just generating text. Now we'll do
- 8:04
an image generation. All right. It refreshed. Let's refresh this local host. Now you see generate image, and then we'll test this out with a prompt. Let's create an image of a string cheese Batman.
- 8:29
All right. This is how creative AI could be.
- 8:35
Let's look at what's happening here.
- 8:40
Running logs. Oh, look at that, rollout in progress.
- 8:55
Okay.
- 8:59
Oh, I got plenty of time.
- 9:07
That's not it. All right. I just had to terminate that 'cause it was running the, the older version. All right, now it's new. I didn't wanna wait for that rollout.
- 9:20
I just wanna see string cheese Batman. All right. So it, it responded with a base64. Okay, let me clean that up before I show that.
- 9:34
So
- 9:37
how you can render this is through the browser.
- 9:47
All right. Let's see what string cheese Batman looks like.
- 9:53
That's not string cheese, but that proves it, right? It did it. Now, what if you wanna deploy this? So check this out. When I cancel it, it actually deprovisioned that endpoint, so you don't have to have that lying around. See, it's gone now. Now, what if we wanna deploy this? So let's deploy that.
- 10:18
Flash deploy. That packages up the whole thing, builds it up, sends it to our servers. Again, no Docker. You're not dealing with Docker here. This is instantaneous packaging of your application, sending it out to our servers, and serving it.
- 10:38
Now, here's the cool part. Once it's out there,
- 10:42
I have prepared this prompt,
- 10:46
but I just need to change this ID later 'cause this is gonna matter. All right, so it's created the archive, built Flash. All right, sending it out, uploaded, deploying. Now it's up. All right, let's see the ID here.
- 11:07
Okay. Now let's get this going. So my prompt is a cute baby sea otter with a bow tie.
- 11:19
Generate that image. Oh yeah, I wanna show you where this is. Now, this is fully servable, right? Like, you can have your customers, you know, use your application that uses this back end. It no longer lives in my local host. This is being hosted.
- 11:37
All right, let's see workers log.
- 11:45
Okay. When it's done, it should print the output here. There we go. All right. Let me wrap this so I could pull this up.
- 12:02
Whoo. This is crazy doing it in one hand. All right. Let's load up the picture of a sea otter with a bow tie. There's no bow tie
- 12:14
But that's not the point. We... All right, so you get that. That's the demo. We had a hackathon yesterday, and I just wanted to be, to present this to you. I'm very proud of this guy, uh, Fong Cao. He created a wrapper around our Flash that enables you to upload a data sheet of all your experiments, of some specifications, of some models, and run it instantly. And it just fans out, builds out all these endpoints, runs
- 12:44
your training, and then reports back to you. And he did this within three to four hours, and he had no idea how to do Runpod Flash. He had to ask me questions if this was even possible. I'm like, "Let's see." And he was very surprised when he won yesterday because his, his project was not even his best one, apparently, and he keeps losing to other hackathons, so just really proud of this guy. How do you get
- 13:14
started with Runpod Flash? So you sign up for an account on Runpod, scan that QR code, get some $10, uh, credit now, and all you really have to do is just install it, write your code, log in to have your, uh, API key in there. Initialize, it'll have some skeleton application if you want. Flash dev, the local dev that you have, or Flash deploy to production. And we have all these URLs. The best advice I have is visit the Runpod
- 13:43
Flash examples on GitHub because of we have all these cases and examples that you could kind of refer. Or if you like AI coding, just run Claude Code into that repository, and it will learn everything. We also have skills if you're into that. And that is my presentation.