AI Apps in a Flash: Ship to GPUs Without Docker — Dean Quiñanola, Runpod
Dean Quiñanola, a staff engineer at Runpod, presents Runpod Flash, a way to run Python on cloud GPUs as if they were local, with no Dockerfiles, image builds, or registry pushes. The talk covers serverless and load-balanced endpoints, endpoint-to-endpoint calls, network volumes with warm caching, and live serverless iteration. A live demo moves from GPU detection to text and image generation and then deploys to production with a single command.
The loop Dean Quiñanola opens with will be familiar to anyone building AI systems: write code, write a Dockerfile, build the image, push it to Docker Hub, run it, find that something is wrong, and repeat. He says a single pass through that loop can take about 15 minutes, which is a serious drag on experimentation. Runpod Flash is his team’s answer. It lets you run Python on cloud GPUs as if the GPU were local, without Dockerfiles, image builds, or registry pushes.
Why the container loop is the problem
Dean’s argument is that the development iteration loop ‘requires a makeover.’ Many of the people using this tooling are software or ML engineers who would rather spend their time on models and experiments than on DevOps. His goal is a loop that reduces to write code, execute, get results, rewrite, execute again. He wants changes to be testable instantly and debuggable quickly, so that the cloud feels local.
What Flash offers today
He grouped the capabilities into a few areas:
- Serverless endpoints, both queue-based and load-balanced. Flash is currently focused on serverless, with pods planned later.
- Endpoint-to-endpoint calls. A function on one endpoint can invoke another endpoint as if it were a local function, so developers don’t need to know where each server lives or how to contact it. He describes this as ‘just code talking to another code.’
- Network volume attachments with warm caching. When serverless endpoints scale up, cache state carries over through network volumes, which reduces repeated setup costs.
- Live serverless. This is the core of the iteration story: you code and test as if everything runs on your own machine, while the work actually executes on cloud hardware. He stresses that without a route to production, this would be ‘just a toy project,’ so the same workflow has to be able to serve inference.
Live demo: from a GPU probe to image generation
The demo runs through a single function that evolves over time. He starts by using PyTorch to report which GPU the endpoint is running on, and running flash dev launches a local FastAPI server backed by a real serverless endpoint. The Runpod console shows the endpoint provisioning, and the logs reveal a cold start, which he notes is typical of serverless platforms. The result reports an NVIDIA GeForce RTX 4090 along with RAM and GPU count.
He then swaps in a text-generation version of the function, adding Python dependencies that get installed on the fly. The first run lacks a Hugging Face token, and the platform warns about that. Asked whether string cheese is real, the model declined to answer, which he called ‘spicy.’ After enabling the token and changing the prompt, the model correctly explained that Batman is a fictional character.
Next he moves to image generation, prompting for ‘string cheese Batman.’ A rollout delay leads him to terminate the endpoint and run the newer version, which returns a base64-encoded image that he decodes in the browser. He admits it is not really string cheese, but says it proves the pipeline works. Cancelling the dev session deprovisions the endpoint, so nothing is left running.
Deploying with one command
flash deploy packages the application, builds it, uploads it to Runpod’s servers, and serves it. Dean emphasizes that no Docker is involved and that packaging is effectively instantaneous. Once deployed, the endpoint is no longer tied to his local host. Customers or other applications can call it. In the final step he generates a ‘cute baby sea otter with a bow tie’ image from the hosted endpoint. The bow tie does not appear, which he shrugs off as beside the point.
A hackathon project and getting started
He describes a hackathon project by a colleague named Funka. The tool wraps Flash so that a spreadsheet of experiments and model specifications can be uploaded, fanned out across many endpoints, run as training jobs, and reported back. Funka built it in three to four hours without prior Flash experience and went on to win, which Dean presents as a point of pride.
For newcomers, the path is to sign up for a Runpod account, which comes with about $10 in credit, install Flash, log in with an API key, and initialize a project, optionally using a skeleton application. From there you can use flash dev for local iteration or flash deploy for production. His main recommendation is the flash-examples repository on GitHub, which covers many use cases. He also suggests that AI coding assistants can learn Flash by being pointed at that repository, and notes that skills are available for those who use them.