Audry Hsu (RunPod) demos Flash, a tool that deploys async Python functions to GPU cloud instances directly from the IDE using a single `@flash.endpoint` decorator, replacing the traditional commit-push-build-pull container workflow; hot reload lets model changes happen with one line of code instead of a container rebuild. A second demo chains three models — Qwen 3 for image prompt generation, DreamShaper for rendering, and Nano Banana 2 for compositing results into a single photo. Cited H100 pricing is $0.00116 per second, billed only while a worker handles a request, with RunPod recommending pods for experimentation and serverless when scaling to hundreds of workers across data centers. (Pricing and scaling guidance are vendor claims from the talk.) # Channel Identity Observations — RunPod / Audry Hsu ## Explicit Self-Description Evidence - **Company identity (stated by presenter):** "We're a AI cloud infrastructure company. Um and our mission is to build the foundational platform for developers to scale their AI workloads." - **Role framing:** "We bring the hardware, we bring the GPUs and the compute... we make it easy for you guys to bring your code, bring your models, and deploy as quickly as possible." - **Company facts claimed by presenter:** - Founded 2022 by "Zenin and Pradeep," originating from a failed crypto mining venture with spare GPUs. - "Around 500 developers on our platform. We're in 30-plus data centers across 10 countries." - "We recently hit... 120 million in annual recurring revenue." - "We've been revenue generating from the very beginning." - **Product scope claimed:** Pods (persistent on-demand GPU VMs), serverless (autoscaling), clusters (multi-node training), and hub (pre-vetted open-source AI repos like ComfyUI, Stable Diffusion, vLLM). - **Featured product:** Flash, a Python SDK — "you have a regular async Python function, you add our flash endpoint decorator, and it's going to deploy and package everything inside your function onto a GPU cloud." ## Intended Audience (Observable) - **Developers, live and interactive:** The format is a live conference-style session with audience Q&A ("Has anyone heard of RunPod or used RunPod before?"), including an Oxford student attendee using RunPod credits for LLM training. - **Developer-tool framing throughout:** References to "your local development environment," Docker builds, GitHub commits, container registries, FastAPI, PyTorch, and IDE-based workflows. - **AI/ML practitioners specifically:** Demos involve Stable Diffusion XL Turbo, DreamShaper, Qwen 3 prompt generation, and a multi-model orchestration pipeline. ## Claimed Scope of Channel/Company Presentation - **Solving infrastructure friction for model builders:** "They're spending more time with the infrastructure than they are with the models" — citing CUDA version alignment, PyTorch compatibility, and GPU SKU testing. - **Positioning statement:** "We're punching above our weight class" with customers ranging from "AI native companies" to "large enterprises." - **Pricing transparency demonstrated live:** "The cost of an H100 right now is 0.00116 cents per second," with per-second billing for serverless requests. ## Demonstrated Presentation Patterns (Not Claims) - **Live technical demo with real iteration:** The presenter runs `flash run`, fixes a URL error live ("He's helping me debug live"), swaps models (XL Turbo → DreamShaper), and shows hot-reload behavior. - **Audience-driven interactivity:** Prompt generation sourced from audience suggestions ("Cats flying in the sky... cloudy... in London"). - **Honest handling of imperfect results:** Presenter acknowledges "this looks terrible, guys" on the first image and pivots to a better model — demonstrating candid, demo-driven presentation rather than polished marketing. - **End-to-end showcase:** A multi-model pipeline (Qwen 3 → DreamShaper → Nano Banana 2) showing orchestration beyond single calls. ## Notes on Distinguishing Claims vs. Demonstration - Company metrics (500 developers, 30+ data centers, $120M ARR, customer logos) are **creator claims** presented without external verification in the source. - The Flash SDK workflow, terminal commands, pricing console, and image generation are **directly demonstrated** in the transcript. # Delivery Observations — Audry Hsu, RunPod ## Overall Tone & Register - **Conversational, developer-to-developer register.** The talk opens casually ("Hey everyone. I'm Audrey.") and consistently uses informal phrasing like "this is where all the magic happens" and "This is good, right, guys? We like this one?" - **Light self-deprecating humor** during the demo mishaps: "Okay, this looks terrible, guys." and "They're cats. They're abstract cats." - **Enthusiasm markers** such as "this is a very handsome picture of Pradeep" and "this was really fun to do." ## Filler & Disfluency Patterns - **Heavy use of "um"** throughout — a stable, recurring feature, e.g., "Um we work at RunPod," "Um, and then there's other different configurations for timeout, um, a worker is idle." - **Repeated word stuttering** appears multiple times: "I'll I'll I'll talk you guys through," "we we're in 30-plus data centers," "this is is the things that we try to take." - Disfluencies cluster during **live transitions and improvisation**, less so in rehearsed intro sections. ## Teaching Habits - **Audience check-ins as openers:** "Were any of you in my earlier session?" and "Has anyone heard of RunPod or used RunPod before?" - **Interactive audience participation** during the demo: "Can I get a help from the audience? What do we want to generate today? Literally anything. Anything random." — then builds the prompt live from their answers ("Cats flying in the sky... cloudy... in London"). - **Problem-before-solution framing:** she describes the pain point ("you have to make a commit, push it to GitHub, build your Docker image...") before introducing Flash as the fix. - **Recaps the value proposition right after each demo segment:** "instead of making a code change, committing it, rebuilding my Docker... all of this is happening right here from my IDE and I never have to leave." ## Recurring Phrases & Structural Verbal Tics - **"really quick / really quickly"** as a transition marker: "I'll zoom in here really quick," "And I'm going to do that really quickly," "Uh I'm going to talk about serverless um today... so we can mirror my screen" — appears at least 4–5 times. - **"you guys"** as a consistent address form: "so you guys can just focus on training your model," "so that you guys get actually get to see what it looks like," "thank you guys for hanging out with me." - **"Um, so"** as a frequent pivot back to slides/points: "Um, so every request that we send to it...", "Um, so this one is..." - **"So"** repeatedly re-launches explanations mid-flow: "So a little bit of that is...", "So this is all you need to know about Flash in one little paragraph." ## Demo Communication Patterns - **Thinking aloud while operating live:** narrates her own errors as they happen — "Did you stop after localhost?" and "it didn't take my prompt probably because I didn't I not pass it as a flag." - **Acknowledges and credits audience debugging help:** "He's He's looking at it so closely. He's helping me debug live. I love it. Thank you." - **Handles audience questions inline**, e.g., the pricing question mid-demo, answered directly: "Pricing is a little bit different for serverless versus pods because pods um, you don't get any of the scaling with it." - **Reads out hard-to-see screen content for accessibility:** "I can read it out to you since I know it's hard to see." ## Vocabulary & Framing Choices - **Plain-language glosses after technical claims:** "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." - **Tricolon/list structures** for emphasis: "we bring the hardware, we bring the GPUs and the compute... bring your code, bring your models, and deploy as quickly as possible." - **Product-narrative storytelling** with concrete origin details: "They had a failed crypto mining venture, so they had a bunch of spare GPUs in their basement." ## Uncertainty Notes - The transcript lacks timestamps for pause length, pacing, or vocal tone, so observations are limited to word choice and structure; **delivery pace and vocal emphasis cannot be assessed**. - Audience speaker attribution is ambiguous in places (e.g., the debug exchange around "localhost"), so who said what beyond Hsu's own lines is **uncertain**. # Position Extraction: GPU Cloud Deployment Without Leaving Your IDE — Audry Hsu, RunPod ## Speaker Identification - **Audry Hsu** (per video metadata), an employee at **RunPod**, is the primary speaker. - **Yunus** (audience member, Oxford University student) briefly contributes. --- ## Company Background (Audry Hsu) ### What RunPod Is - RunPod is an **AI cloud infrastructure company**; its stated mission is to build the foundational platform for developers to scale AI workloads. - RunPod provides GPUs/compute; customers bring code and models. ### Founding Story - Founded in **2022** by **Zenin (Zed) and Pradeep**. - Origin: after a **failed crypto mining venture**, the founders had spare GPUs in a basement, built a prototype, and posted on Reddit offering free GPUs in exchange for feedback. - Claimed milestones (per Hsu): - **Revenue-generating from the beginning** ("very, very rare") - ~**500 developers** on the platform *(stated with hedging: "around")* - **30+ data centers across 10 countries** (including France, Romania, Iceland — Hsu adds the qualification "if that's part of Europe") - **$120 million annual recurring revenue** ("recently hit") - Customers include AI-native companies and large enterprises; the commonality Hsu identifies is a need for **flexible, reliable GPU infrastructure**. She characterizes RunPod as "punching above our weight class." ### Rationale ("Why RunPod Exists") - Hsu's stated reasoning: teams spend more time on infrastructure than models — CUDA version alignment, PyTorch compatibility, GPU SKU testing — so RunPod removes that configuration burden. --- ## Product Claims ### Product Lines - **Pods**: persistent VM environment; on-demand rental, pay by the second; reserved GPU ("as long as your pod is running, the GPU is yours"). - **Serverless**: for variable/scaling workloads; auto-scales workers and scales down to avoid idle charges. - **Clusters**: for multi-node training. - **Hub**: pre-vetted open-source AI repos (ComfyUI, Stable Diffusion, vLLM). ### Flash SDK (Main Topic) - **Problem claim**: the standard iteration cycle (commit → GitHub push → Docker build → pull from registry → load to server → allocate GPU → test) is "a huge pain" for developers. - **Claimed solution**: Flash (a Python SDK) deploys a GPU function from the local dev environment via an `@flash_endpoint` decorator; surrounding code runs locally, GPU code runs in the cloud. - **Features demonstrated**: - Hot file reload — changes are repackaged and pushed immediately. - Endpoint configuration: name, GPU family (Ada 80 Pros, "variations of Nvidia H100 cards"), max workers (5), active workers (1), idle timeout. ### Demo Sequence - First model: **Stable Diffusion XL Turbo** (characterized as fast); audience prompt "cats flying on a cloudy day in London" produced poor results ("This looks terrible... They're abstract cats" — Hsu's own admitted failure). - Swapped to **DreamShaper** (fine-tuned Stable Diffusion 1.5), characterized as better quality, more art/illustrator-oriented; used 25 inference steps. - Pipeline demo: **Qwen 3** (public endpoint) generated prompts → DreamShaper generated images → **Nano Banana 2** ("a premium Google model... really good at composing photos") composed the final images. --- ## Pricing Q&A ### Audience Question - An unnamed audience member asked how pricing works and whether it's the same as pods. ### Hsu's Answer - Serverless charges **per request runtime** ("you're only charged for how long that request is running"). - Serverless carries a **premium over pods** because pods lack scaling. - Recommendation: for experimentation, use a **low worker count or pods**; serverless for "hundreds of workers... distributed for better availability." - Quoted rate: **H100 at $0.00116 per second** (stated as "0.00116 cents per second" — a verbal inconsistency between cents and dollars; the figures conflict as spoken). --- ## Audience Position (Yunus) - Uses RunPod through his **university (Oxford)**, which provides RunPod credits, for LLM training. --- ## Preserved Tensions and Qualifications - **Demo failures**: the first image generation failed visually; Hsu acknowledged it openly rather than smoothing over. - **Pricing unit ambiguity**: "0.00116 cents per second" vs. a plausible dollar reading — the transcript does not resolve this. - **Iceland/Europe hedge**: Hsu's uncertainty about Iceland's classification remains in the record. - All company metrics are speaker-reported promotional claims from a vendor talk, not independently verified. # Speaker Attribution Record ## Video **Title:** GPU Cloud Deployment Without Leaving Your IDE — Audry Hsu, RunPod **Video ID:** `01a15ca9-0d2f-761c-9f3b-cad011b2d889` ## Speakers & Roles ### Primary Speaker - **Audrey Hsu** — **Creator / Presenter** (introduced as: *"I'm Audrey. Um I work at RunPod.") - Role: RunPod employee delivering a live demo session, including an earlier session referenced in the same event. - Note: Title spells "Audry"; speaker self-identifies as "Audrey." ### Audience Participants (Guests) - **Yunus** — **Audience guest**, Oxford university student; stated he uses RunPod credits at his university for training/LLM work. - **Unidentified audience members** — contributed prompt suggestions ("Cats flying in the sky", "cloudy", "in London", "Glasses") and asked a pricing question: > "Is it the same as for a pod or is the pricing a bit…" - One audience member assisted with live debugging (speaker: *"He's helping me debug live."*). ### Referenced Third Parties (non-speaking) - **Zenin (Zed) and Pradeep** — RunPod co-founders, named in the backstory; subjects of generated demo images. - Unnamed university/enterprise customers shown on a customer slide. ## Provenance & Source Facts ### Company Claims (attributed to presenter, unverified) - Founded **2022** by Zenin and Pradeep; originated from spare GPUs after a failed crypto mining venture, prototyped via a Reddit free-GPU post. - ~**500 developers**, **30+ data centers across 10 countries**, **$120M ARR** milestone. - Serverless H100 pricing stated as **0.00116 cents per second**; pods priced differently from serverless. ### Referenced Products / Models - **RunPod**: Pods, Serverless, Clusters, Hub; **Flash** (Python SDK). - Third-party models in demos: **Stable Diffusion XL Turbo**, **DreamShaper** (fine-tuned SD 1.5), **Gwen 3** (public endpoint), **Nano Banana 2** (described as a "premium Google model"), **vLLM**, **ComfyUI**, **FastAPI**, **PyTorch**. ## Promotional Segments — Flagged - **Entire session is a vendor presentation** by a RunPod employee promoting RunPod's platform and Flash SDK. - Notably promotional claims: revenue/ARR figures, customer slide ("punching above our weight class"), pricing pitch, and closing: > "this is how you can get started really quickly… use open-sourced models… bring your own model." ## Availability & Gaps - No curated metadata supplied; no transcript-level information on **comment availability**. - No timestamps in source; audience Q&A is embedded mid-demo. - Referenced **earlier session** by same speaker not included in this transcript. \>\> Hey everyone. I'm Audrey. Um I work at RunPod. Have Were any of you in my earlier session? Okay, good. Cuz then I'm going to sit This intro is the same, but what I'm going to show is a little bit different. Has anyone heard of RunPod or used RunPod before? You have? Do you Do you mind if I ask you um how you've used us or heard about us before? I thought about university. We have some RunPod credits, so I I use this as a yeah for better than training and LLM training. Okay, at your university? And where do you go to uni? Uh you Oxford. Oxford. I did a study abroad there one summer. It's awesome there. Okay, love it. 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. 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. 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. Why RunPod exists. A lot of teams that we've talked to, they're all wrestling with the same thing that infrastructure They're spending more time with the infrastructure than then they are with the models. So things like CUDA version um alignment, like what versions of PyTorch run well together. Um which which uh new the GPU uh SKUs like have been tested and like keep figuring out the bugs there. 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 feel um focus on training your model or building your apps. And a little bit of a backstory about our company. So this is Zenin and Pradeep are 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. 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?" 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. Um and even today we have around 500 developers on our platform. We're in 30-plus data centers across 10 countries. Um in Europe that includes France, Romania, Iceland, if that's part of Europe. Uh Asia Pacific. Um and we recently hit um a pretty big milestone of 120 million in annual recurring revenue. 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. 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. 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. 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. 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 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. Um and that's one way if you're just exploring uh to just click around and get started really quickly. Uh I'm going to talk about serverless um today. And the product that we just And I'm going to switch my displays again here really really quick so we can mirror my screen. 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 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 container registry, um and then load it onto uh a server, and then allocate a GPU on it, and then you get to test it and see if it's working as you expect it. And then you do that all over again 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. 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, you add our flash endpoint decorator, and it's going to deploy and package everything inside your function onto a GPU cloud. Everything around it, your um main function, any helper functions that you have, those all run on your local development environment, but if you need GPU compute, that that can run um on the cloud. And you can we have hot mod uh 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. And I'm just going to show an example of this. 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, really great for fast uh generation of images, and I'm going to save the image down and that going to return it base64 encoded. 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 uh image generation.py. And what I'm going to actually do is I have a little flash flash run. So flash run spins up a local development server here. Uh it's just a fast API server. And I can send my request here to this endpoint. And I'm going to do that really quickly. Just get to to my project. And this is just a little helper script that's going to send a post request to it and then um decode that image so that you guys get actually get to see what it looks like once it's generated. And it was image generation async. Here we go. And let's pass a prompt to it. Can I get a help from the audience? What do we want to generate today? Literally anything. Anything random. Cats flying in the sky. Okay. Cats flying in the sky. What does the sky look like? What time of day is it? Cloudy. Um in London. Yeah. Flying in Flying on a cloudy day in the sky somewhere in London. And I passed it correctly. He's He's looking at it so closely. He's helping me debug live. I love it. Thank you. \[laughter\] It's kind of hard to see in dark mode, but uh I passed URL and that's true. Did you stop after localhost? Uh Is it my HTTP? Okay, there we go. Okay, going back to the local dev server. It sees the request. It started the job. It's queued it. And we're just going to wait for a second to see if it finishes. And so while that's happening, let me bring your attention back to Make it bigger for you guys. Um, the endpoint decorator. So this is where all the magic happens. 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. Um, I just put one active worker, so this is one that's always going to be running and always on. And that's definitely a dragon. And it didn't take my prompt probably because I didn't I not pass it as a I didn't pass it as a flag. Prompt. There we go. Okay, now it's definitely generating cats flying. \>\> \[snorts\] \>\> 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. Okay, this looks terrible, guys. \>\> \[laughter\] \>\> 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 chimney. Maybe. 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. So I'm just going to comment out this code here. And then down here let's swap in DreamShaper, which is a fine-tuned um 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 going to generate a more uh a better quality image for us. And it's specifically better for kind of like more art and illustrator styles. So I've changed some of the parameters in it. It's going to have a few more um, inference steps to it. We're going to set that to 25. Height and width 10 by 24, that's fine. And let's just send the same request again. 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. This is good, right, guys? We like this one? Okay. So one more one last thing that I'm just going to 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. It's It's all 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 going to send a request to Gwen that's already hosted on a public endpoint. Um, and Gwen is Gwen 3 is going to generate all the prompts for me. Um, and then after that it's going to send that to our um, DreamShaper running on our endpoint. And then um, after that there's one more pipeline that it goes through. It's going to send the request to Nano Banana 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. Okay. Um Now let's run the whole pipeline here. Check. Okay. Prompt two men walking in London on a It is cloudy today. Cloudy day close-up of their faces. Um, any other requests for these two men? Um, how do they look? Like are they doing something? Glasses, yeah. Okay. Two men with glasses close-up of their faces. Okay, and let's generate. Let's generate three of those and let's compose it together. Okay. 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. So let's see. I'm going to I said this whole session was going to be only in the terminal, but I'm going to go back into the console just to show you what's what's running. Let's see. This is the endpoint that we created from the terminal. Um, here are the workers. I think we said like five workers, so we have about five or six here that are provisioned. Um, three of them are running cuz I asked for three photos. 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 0.00116 cents per second. Is it the same as for a pod or is it or is is the pricing a bit Pricing is a little bit different for serverless versus pods because pods um, you don't get any of the scaling with it. 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? Cuz 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. \>\> \[laughter\] \>\> Okay, guys, here's here's the here's our final presentation. So this was our original prompt. Two \[snorts\] men with glasses walking in London on a cloudy day, close-up of their faces. So on the left, this is what um, DreamShaper generated based off of the um, prompt engineering that Gwen 3 did for us. So it's a lot better of a prompt than what I sent in. 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, soft focus on background clouds, muted urban palette with grays and deep blues, overcast lighting. 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 Pradeep. And this is somehow a very old photo of Zed. And I'm just going to scroll down to show you that this is the reference photo that I sent it. 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. You can use open-sourced models. You can use bring your own model, private model. Um, and this was really fun to do. So, thank you guys for hanging out with me. \>\> \[applause\]