Dean Quiñanola, staff engineer at Runpod, introduces Runpod Flash, a tool for running Python on cloud GPUs as if the GPU were local, eliminating the Docker build-push-run loop. Topics include live serverless iteration, serverless queue and load-balanced endpoints, endpoint-to-endpoint calls like local functions, network volumes with warm caching, and one-command deployment to production without Docker. A live demo verifies GPU availability (RTX 4090), evolves a function from text generation to image generation with on-the-fly dependency installs, and deploys the app. He also shows a hackathon project that fans experiments out across endpoints and how to get started. # Video Identity Observation: Runpod Flash Talk ## Source Scope - **Video ID:** `01a15ca6-a47c-757f-987d-3ccb2959dca1` - **Title:** *AI Apps in a Flash: Ship to GPUs Without Docker — Dean Quiñanola, Runpod* - **Format:** Single recorded talk with a live demonstration - **Curated metadata:** Not supplied. All observations below rely on the title and transcript. > **Note:** The title spells the speaker's surname "Quiñanola," while the transcript renders it as "Kinyanola" at the opening and in the self-introduction. This is most likely a transcription artifact, and the title spelling is used here. --- ## 1. Explicit Self-Description (Creator Claims) ### 1.1 Speaker Identity - **Role:** "I am a staff engineer at RunPod and I have an entire team that's working on making that easy." - **Affiliation:** Presents as speaking for Runpod's Flash product: "I'm uh Dean Kinyanola from Runpod Flash." ### 1.2 Product Positioning - The talk frames Flash as a way to remove Docker from the AI deployment loop: "So, no more need for Docker. Run code like it's local, as if you have the GPU." - The speaker characterizes the product as simple and Python-native: "It's just Python code. It's really whatever you can run locally with a GPU, just do it on the cloud." ### 1.3 Self-Described Limitations and Roadmap - **Current scope:** "It's mostly locked on serverless right now, but we're working towards doing it for pods." - **Deployment:** "I'll talk about that later." Deployment is presented as a distinct later step. ### 1.4 Claims About Organizational Context - A hackathon anecdote is offered as evidence of the tool's accessibility: a colleague built a wrapper around Flash "within three to four hours" and "had no idea how to do runpod flash." - The speaker expresses personal pride in this colleague: "just really proud of this guy." --- ## 2. Observable Presentation Patterns ### 2.1 Intended Audience Inferred from the speaker's direct address: - **Stated audience:** "A lot of you guys are software engineers or ML engineers who really don't want to deal with all the DevOps." - **Implied audience:** Developers running AI experiments who want fast GPU feedback loops. ### 2.2 Claimed Scope of the Talk **Explicit claims about what Flash does:** - Faster build and deploy cycles: "So we are able to build and deploy faster." - Resource optimization: "We optimize the resource utilization." - Endpoint-to-endpoint communication, where "it's just a code talking to another code." - Network volume attachments with warm caching. - "Live serverless" for coding and testing against cloud resources. - CLI-driven workflows, including `flash dev` and `flash deploy`. **Demonstrated in the talk:** - `flash dev` launching a local FastAPI host and provisioning a serverless endpoint. - Iterating on a function that returns GPU information (reported as an NVIDIA GeForce RTX 4090). - Iterating on a text-generation function, including on-the-fly dependency installation. - Iterating on an image-generation function, which returned base64 output rendered in a browser. - `flash deploy`, described as packaging, building, and uploading without Docker. ### 2.3 Demonstration Style - **Live, unscripted-feeling demo:** The speaker repeatedly narrates in real time, such as "Let's see the result" and "Okay, it's coming up." - **Visible failures are kept in:** - The text model initially refused a question: "I'm sorry but I cannot provide answers." - A generated image did not match the prompt: "That's not string cheese, but that proves it right." - A sea otter image lacked the requested bow tie: "There's no bow tie. But that's not the point." - **Self-aware humor:** The speaker jokes about "that's spicy" and "that's crazy doing it in one hand." - **Practical wrap-up:** Ends with resources, including the Runpod Flash examples on GitHub, a suggestion to use AI coding tools against that repository, and a mention of skills. ### 2.4 Calls to Action - Sign up for a Runpod account, with the speaker stating a "$10 credit" offer. - Install Flash, write code, log in with an API key, and initialize a project. - Consult the GitHub examples repository. --- ## 3. Claims Versus Demonstrated Evidence | Claim | Evidence in Transcript | Status | |---|---|---| | Runs code "like it's local" | Live `flash dev` run and iterative edits | **Partially demonstrated** (cold start and roll-out waits were visible) | | Deploys without Docker | Narrated `flash deploy`; no Docker commands shown | **Stated, not independently verified** | | Warm caching via network volumes | Mentioned only | **Claim only** | | Endpoint-to-endpoint communication | Mentioned only | **Claim only** | | Works on pods | Explicitly described as future work | **Stated as not yet available** | | Fast iteration | Speaker says a traditional loop can take "about 15 minutes" | **Speaker's own experience** | --- ## 4. Non-Inferences (Boundaries of This Observation) - No channel-wide conclusions are drawn. This observation covers one talk only. - The speaker's private motivations are not inferred beyond stated pride in a colleague and the product framing. - Performance metrics beyond the speaker's own "15 minutes" anecdote are not supported by this transcript. - The "$10 credit" and pricing details are creator claims about an offer, not verified terms. # Delivery Observation: Dean Quiñanola — "AI Apps in a Flash" ## Tone & Overall Register - **Conversational, improvisational presenter.** Heavy use of fillers and self-corrections throughout: *"um," "uh," "right?"* appear constantly (e.g., *"So, why did we build flash? development iteration loop requires a makeover. It's really a hassle."*). - **Casual asides during the live demo**, including calling out his own constraint: *"Hopefully I can do this with one hand"* / *"This is crazy doing it in one hand"* — repeated at least three times ([222], [458], [723]). - **Lighthearted reactions to demo output**, treating model responses as comedic beats: *"that's that's spicy," "That's not string cheese, but that proves it right. It did it," "There's no bow tie. But that's not the point."* ## Recurring Phrases & Vocabulary - **"Under the hood"** — used twice for hidden platform mechanics: *"There's a lot of tricks happening under the hood"* ([128]) and *"it's all happening under the hood"* ([178]). - **"It's just Python code" / "just local"** — the core simplification message recurs: *"Run code like it's local, as if you have the GPU"* ([95]), *"it looks like it's just local"* ([172]), *"coding and testing as if it's all happening in your local system"* ([200]). - **Anti-Docker repetition** — the phrase *"no Docker"* / *"You're not dealing with Docker here"* is stated at least three times ([79], [599]-ish framing, [623]). - **Intensifiers "just" and "really"** appear pervasively: *"it's just a code talking to another code," "it just fans out builds out all these endpoints," "It's really a hassle," "It's really whatever you can run locally."* - **Interactive demo filler**: *"Let's try it out," "Let's see," "Let's execute that," "All right"* — used as verbal pacing between demo steps. ## Teaching Habits - **Problem-first framing before the product**: opens with the traditional Docker workflow and quantifies the pain — *"sometimes this one loop takes about 15 minutes"* — before introducing Flash. - **Contrast loop teaching**: presents the old workflow vs. the new one in parallel simple loops: *"You write your code, you execute, you get the results. Rewrite your code, execute, you get the results."* - **Anticipates skepticism and answers it live**: *"you know this would just be a toy project if you can't deploy to production, right?"* — preempting the obvious objection. - **Progressive demo escalation**: GPU query → text generation → image generation → production deploy, narrating each iteration and its logs rather than jumping to the end state. - **Uses running commentary on logs** to make internals visible: *"Let's show the logs. So you can actually see it,"* and *"it even gave me a warning about communicating with the hugging face server without the token."* - **Social proof via a third-party story**: closes with a hackathon anecdote — *"he did this within three to four hours. And he had no idea how to do runpod flash."* - **Concrete call to action**: QR code, $10 credit, and a specific recommendation — *"The best advice I have is visit the runbot flash examples on GitHub."* ## Communication Patterns - **Rhetorical question hooks** to transition sections: *"So, why did we build flash?" "So, what can you do with Flash today?" "So, how do you get started with runpad flash?"* - **Narrates his own mistakes transparently**: forgetting the HF token (*"Oh, actually, let's do this without the hugging face token first"*), the cold start (*"Oh, John. Cold start. This is common with all serverless platforms"*), and terminating a stale rollout (*"That's not it. All right. I just had to terminate that"*). - **Uses "here's the kicker" / "here's the cool part" / "really cool feature"** as emphasis markers before feature reveals ([189], [335], [156]). ## Stability & Uncertainty - The **filler density and "All right / Let's see" pacing** appear consistent across both the slides section and the demo, though some of this may be driven by the single-handed live-demo constraint, which is specific to this talk. - The **rhetorical-question structure** is observable in at least three transitions, but the talk covers only one product intro + one demo; recurrence across other talks cannot be assessed from this sample. - Attributing calm under demo friction (cold start, stale rollout) to practiced habit is **not certain from one video**, though the behavior itself is directly observable. # Observation Record: "AI Apps in a Flash: Ship to GPUs Without Docker" **Source:** Video `01a15ca6-a47c-757f-987d-3ccb2959dca1` **Speaker:** Dean Quiñanola, identified in the curated title and self-introduction as a staff engineer at Runpod. The transcript spells the name "Kinyanola." **Format:** Conference-style talk with a live demo --- ## 1. Central Position The speaker argues that AI application developers should be able to deploy serverless GPU workloads **without writing or managing Docker images**, and that the development loop should feel like running code locally. > "So, no more need for Docker. Run code like it's local, as if you have the GPU." --- ## 2. Problem Framed by the Speaker ### 2.1 Current workflow as described 1. Write code. 2. Write a Dockerfile and run build commands. 3. Push the image to Docker Hub. 4. Execute. 5. If the result is wrong, change code and repeat from step 2. - **Stated cost:** In the speaker's "experience," one iteration of this loop "sometimes" takes "about 15 minutes depending on the changes you're doing." - **Stated audience:** Software and ML engineers who "really don't want to deal with all the DevOps." --- ## 3. Claimed Solution: Runpod Flash ### 3.1 Stated goals - Build and deploy faster. - Optimize resource utilization. The speaker says "there's a lot of tricks happening under the hood" but does not describe them. - Keep the interface intuitive: "It's just Python code." - Make cloud execution feel like local execution with a GPU. ### 3.2 Features the speaker attributes to Flash | Feature | Speaker's description | Qualification given | |---|---|---| | Serverless endpoints | Primary deployment target | "It's mostly locked on serverless right now" | | Pod support | Planned | "We're working towards doing it for pods" | | Queue and load-balanced endpoints | Available endpoint types | None stated | | Endpoint-to-endpoint communication | Functions call across endpoints as if local | Described as happening "under the hood" | | Network volume attachments with warm caching | Cache carries over when serverless endpoints scale up | None stated | | Live serverless | Dev iteration locally, then production serving via CLI | Presented as "making that possible" | --- ## 4. Demo Observations The speaker presents a live sequence of a function's evolution. The following records what was shown and said, including outcomes that did not match the framing. ### 4.1 Sequence 1. **Hardware probe (Torch).** `flash dev` launched a local FastAPI host. Execution provisioned a serverless endpoint. The speaker noted a **cold start** and called it "common with all serverless platforms." The result reported an **NVIDIA GeForce RTX 4090**. 2. **Text generation without HF token.** On-the-fly dependency installation occurred. A warning about contacting Hugging Face without a token appeared. The model answered "is string cheese real?" with a refusal: *"I'm sorry but I cannot provide answers."* The speaker remarked "that's that's spicy." 3. **Text generation with HF token.** After enabling the token, the speaker asked "who is Batman" and received "Batman's a fictional character." 4. **Image generation.** One run executed an older version. The speaker noted a rollout was in progress, then terminated the endpoint and retried. The output was base64, rendered through the browser. The image was not string cheese Batman. The speaker said: "That's not string cheese, but that proves it right. It did it." 5. **Deprovisioning.** Canceling the local session deprovisioned the endpoint. 6. **Deployment.** `flash deploy` packaged, built, and uploaded the application. The speaker called packaging "instantaneous" and said "no Docker." 7. **Production run.** The deployed endpoint generated an image of "a cute baby sea otter with a bow tie." The speaker stated: "There's no bow tie. But that's not the point." ### 4.2 Qualifications within the demo - The speaker's own framing of the cold start and rollout delay acknowledges latency that the "feels like local" claim does not fully cover. - Output quality was not the focus. The speaker explicitly disregarded the missing bow tie and the non-matching Batman image as beside the point. --- ## 5. Supporting Anecdote (Hackathon) The speaker described a colleague ("Funka") who, in roughly three to four hours at a hackathon, built a wrapper around Flash. The wrapper takes a spreadsheet of experiment specifications and model configurations, fans out endpoints, runs training, and reports results. - The speaker reports the colleague had "no idea how to do runpod flash" and asked whether it was feasible. - The speaker reports the project won, although it "was not even his best one apparently." - **Evidentiary status:** This is an anecdote from the speaker. No project details, metrics, or verification are provided in the transcript. --- ## 6. Getting Started (as stated) - Sign up for a Runpod account. The speaker mentions a **$10 credit** offered via a QR code. - Install Flash, write code, log in with an API key, and initialize. - Use `flash dev` for local development and `flash deploy` for production. - Reference the **Runpod Flash examples on GitHub**. The speaker also suggests AI coding tools can learn from that repository. - The speaker mentions **skills** available for AI-assisted use, without elaboration. --- ## 7. Unresolved Tensions and Qualifications - **"No Docker" versus packaging:** The speaker says Docker is not needed, yet deployment is described as building and packaging the application before upload. The transcript does not explain what replaces the image build. - **"Feels local" versus latency:** The speaker acknowledges cold starts and rollout waits during the demo. The "as if local" framing is presented as the goal, not as measured experience. - **Platform scope:** Flash is "mostly locked on serverless right now." Pod support is future work. - **Cost of the old loop:** The 15-minute figure is described as the speaker's experience and "depending on the changes." It is not a measured benchmark. - **Unexplained optimizations:** Claims about resource utilization and "tricks under the hood" are asserted without description. - **Output quality:** The demo produced a refusal and a non-matching image. The speaker treated these as incidental to the workflow demonstration. --- ## 8. Claims Not Substantiated in the Transcript - Specific speed improvements over Docker workflows - Resource utilization gains - Cache performance on scale-up - Pricing beyond the stated $10 credit - Production readiness or scale - Endpoint-to-endpoint communication latency or security model # Attribution Observation: AI Apps in a Flash, Ship to GPUs Without Docker ## Video Identity - **Video ID:** `01a15ca6-a47c-757f-987d-3ccb2959dca1` - **Title (metadata):** AI Apps in a Flash: Ship to GPUs Without Docker, Dean Quiñanola, Runpod - **Format:** Single-speaker presentation with a live demo - **Supplied metadata:** Title only. No channel, upload date, description, speaker list, or comment data was supplied. ## Speakers and Roles ### Primary Speaker - **Name (metadata):** Dean Quiñanola - **Name (transcript):** Introduced as "Dean Kinyanola." The transcript spelling differs from the title spelling. This is most likely a transcription variant, but it is not confirmed. - **Self-stated role:** Staff engineer at RunPod - **Self-stated affiliation:** Works on Runpod Flash and leads or is part of a team building it - **Role in video:** Presenter, product speaker, and live demonstrator - **Speaking pattern:** Continuous first-person narration for the full transcript ### Other Individuals Referenced (Not Speaking) - **Funka:** A RunPod hackathon participant described by the speaker. Per the speaker, he built a wrapper around Flash in three to four hours and won a hackathon. He did not speak in the transcript. - **"John":** Appears once in an audience-style exchange ("Oh, John. Cold start."). The transcript does not establish who John is or whether he speaks in the video. Treat this as **unresolved**. - **Unnamed audience:** The speaker addresses "you guys" and "a lot of you," implying a live audience. No audience member is identified. ## Promotional Content **The entire transcript is promotional for RunPod Flash.** The following segments are explicitly promotional: - **Product pitch:** Claims about faster build/deploy, resource optimization, and "no more need for Docker." - **Feature listing:** Serverless endpoints, Q endpoints, load-balanced endpoints, endpoint-to-endpoint communication, network volume caching, and live serverless. - **Live demonstration:** Flash dev, Flash deploy, and live deployment to RunPod servers. - **Call to action:** Sign-up instructions, a QR code, and a stated **$10 credit**. - **Getting-started guidance:** Install, log in, initialize, and use the examples repository. - **Testimonial-style anecdote:** The Funka hackathon story. ## Sources and References Named in the Transcript ### Tools and Platforms - **Docker and Docker Hub:** Described as the current deployment baseline the product replaces. Docker build and image push are referenced. - **RunPod console:** Shown on screen during the demo. - **Hugging Face:** Referenced for the token and model access. The speaker says a warning appeared about connecting without a token. - **Nvidia GeForce RTX 4090:** Named as the GPU the demo job ran on, per the speaker's reading of the output. - **Cloud code (as transcribed):** Mentioned as an AI coding tool that can learn from the examples repository. The transcript spells it "cloud code." - **FastAPI:** Referenced as the local host server launched by `flash dev`. - **PyTorch (torch):** Used in the first demo function to report GPU details. ### Resources - **RunPod Flash examples on GitHub:** Recommended as the primary learning resource. The speaker says "a bunch of URLs" are available. The URLs are not included in the transcript. - **RunPod Flash skills:** Mentioned without detail. ## Third-Party and Anecdotal Claims These claims originate from the speaker, not independently verified sources. - **Development loop duration:** The speaker says, "in my experience," the build-push-execute loop sometimes takes about **15 minutes**. This is a personal estimate. - **Hackathon outcome:** The speaker reports that Funka built a wrapper in **three to four hours** with no prior Flash experience, won the hackathon, and "keeps losing to other hackathons." These are secondhand statements about a named third party. - **Demo outputs:** The speaker reports model and image outputs, including a text response to "is string cheese real," an answer about Batman, and a generated sea otter image. The speaker also notes the image lacked a bow tie. These are live demo results reported by the speaker, not independently checked. - **Cold start:** The speaker says cold starts are "common with all serverless platforms." This is a general claim made by the speaker. ## Availability Limits - **Comments:** No comment data was supplied. - **Slides or visuals:** Not supplied. Some on-screen content (console, logs, rendered image, endpoint IDs) is referenced in speech but not captured in the transcript. - **Visible URLs and QR code:** Referenced but not transcribed. The examples repository URL and sign-up URL are not available from the source. - **Speaker identity verification:** The name spelling differs between metadata and transcript. The affiliation is self-stated only. - **Audience identity:** Not available. ## Open Items - Confirm the spelling of the speaker's name: "Quiñanola" (title) versus "Kinyanola" (transcript). - Identify "John" and confirm whether he is an audience member or a participant. - Obtain the GitHub examples URL and sign-up URL, since they were displayed or spoken but not transcribed in full. Hello, good afternoon everyone. I'm uh Dean Kinyanola from Runpod Flash and um I want to 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 docker file, you run a bunch of commands, docker build, all that. And then you push the image to docker hub. Then you execute it. Then maybe you'll get what you want. If not, you have to change your code again, rebuild it, repush it, execute. Um, in my experience, sometimes this one loop takes about 15 minutes depending on the changes you're doing. So, my name is Dean Kinyanola. I am a staff engineer at RunPod and I have an entire team that's working on making that easy. 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 want to deal with all the DevOps. So, as you're working on your ideas or 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 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. 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. Uh we have Q 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 because 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 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 serless. Uh you are coding and testing as if it's all happening in your local system. And then you know this would just be a toy project if you can't deploy to production, right? So you want to 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. 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 dev. And what this does is it launches a fast API local host. So you can actually toy around with it. So now you want to 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. And as it's loading, let's let's show the logs. So you can actually see it. All right. Workers ready. Yep. Oh, John. Cold start. This is common with all serverless platforms. 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 GeForce RTX 4090. You see all the RAM, GPU count. Now, here's the kicker. What if I want to change this function and just want to test it? So, here's a different 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 here. Oh, actually, let's do this without the hugging face token first. Let's see what's happening. See, it refreshed everything. I refreshed this. Test it again. What prompt do we need? Uh, let's do string cheese. Is it real? Run it. You see it again here. Container. Okay. It's coming up. You'll see all the the logs are simpler here because you're not supposed to be inundated with so much stuff. But what it's doing is in 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. 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. Let's see who is Batman. Let's execute that. Ready? And let's see how's this working here. It's cool. I'm doing this with one hand. \>\> All right, let's finish. Now we see the result. Oh, there. 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 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. All right, this is how creative AI could be. Let's look at what's happening here. Running logs. Oh, look at that. Roll out in progress. Okay. I got plenty of time. That's not it. All right. I just had to terminate that because it was running the the older version. All right. Now it's new. I didn't want to wait for that roll out. I just want to see string cheese Batman. All right. So, it's it responded with a base 64. Okay. Let me clean that up before I show that. So how you can render this is through the browser. All right, let's see what string cheese Batman looks like. That's not string cheese, but that proves it right. It did it. Now, what if you want to 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 want to deploy this? So, let's deploy that. 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. Now, here's the cool part. Once it's out there, I have prepared this prompt, but I just need to change this ID later because this is going to 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. Okay. Now, let's get this going. So, my prompt is a cute baby sea otter with a bow tie. Generate that image. Oh, yeah. I want to 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. All right, let's see workers log. 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. 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. 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 I'm very proud of this guy uh Funka. 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 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 started with runpad flash? So, well, 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, 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 runbot flash examples on GitHub because we have all these cases and examples that you could kind of refer or if you like AI coding just run cloud code into that repository and it will learn everything. We also have skills if you're into that. And that is my presentation.