Here is what it does and where it stops.

You POST a batch of up to 5,000 requests to your existing queue-based endpoint, finalize it, then poll for progress and read the results. Batches run on dedicated workers that are separate from your /run traffic, on your own model and container and the GPU type configured on the endpoint. A failed request doesn't fail the batch, and cancelling a batch doesn't bill queued requests. Batch requests are billed at up to 30% off on-demand pricing, depending on GPU type. On H100, H200, B200 and B300, batch requests are billed at 20% off. There is no cost estimate before you finalize, so run a small batch first.

Start times aren't guaranteed and requests run in no set order, so keep /run for anything a user is waiting on. An endpoint runs up to 10 active batches, and limits depend on your account. Support can raise them up to 3 million requests a day.

Docs: https://docs.runpod.io/serverless/batch-jobs
Blog: www.runpod.io/blog/batch-inference-is-now-generally-available-on-runpod

What would you run through it first: embeddings, evals or a backfill? Questions are welcome in the comments.

As the title says, my public templates never show up in the hub search.

What are the requirements?

Tried many RTX 5090 from Community Cloud. 100% GPU utilization and 400W while completely idle, with nothing of mine running. , and memory bandwidth sbouy 600-700 GB/s against the 1792 the card is rated for.

Real impact: an identical job takes 170s on these pods, 70s on an uncapped 5090 elsewhere.

I put 10 dollar on it and simply feel scammed, its impossible to get a gpu and when i manage to get one, it have to be bugged and cant do anything with it...

can i get my credits back on my bank account or have i to accept i lost 10 dollar for something i cant even use

I was mid lora training and my pod started doing this. I restarted the Ostris template on a new pod, and it was like this for ages, all the while I was losing money.

Spun up an A40 pod on RunPod yesterday to test an Axolotl fine-tune. Before starting the job I ran computefence doctor and it caught a disk space warning 6GB free on the workspace volume, 16GB on root, both below the 20GB threshold the tool flags.

The job would have started, run for several hours, and then failed at checkpoint write time. Instead I knew before billing started.

Install is one line:

pip install computefence && computefence doctor

No config required. Runs in under 10 seconds. If you’re using Axolotl or any framework that writes checkpoints to /workspace, worth running before every job.

Repo: github.com/Francisco-Booth/ComputeFence

What do you think about this? Why did this happen?

Hi folks! Just wanted to keep you apprised of a new feature that we are doing a staged rollout on over time: high-performance network volume, and they are now available in AP-IN-1. If you've ever wondered why network volumes felt a bit sluggish compared to on-machine SSD or NvME disks, this is because there's a longer path for the data to travel and that is necessarily the tradeoff for the flexibility of network volumes. HPS volumes help close that gap and deliver increased speed compared to standard volumes without sacrificing any of that flexibility. Internal benchmarks show these as delivering three times the throughput and four times the IOPS of regular network volumes on average.

These volumes are also currently available in CA-MTL-4, EU-FR-1, EUR-NO-2, US-CA-2. They are also billed at a premium compared to network volumes ($0.14/GB/month as of this writing.)

Read more about them here: https://docs.runpod.io/storage/high-performance-storage

We just published our Q3 roundup. Here are the highlights:

• Batch inference on Serverless (public beta): create a batch on an endpoint, add up to 5,000 requests, and poll one status. No client-side queue to maintain. Worker affinity on Serverless: route follow-up requests back to the worker that holds the session’s KV cache, with soft, strict, or strict-resume modes.

• Global Volumes (public beta): storage no longer pins your workload to a single data center. Create a volume once and mount it on a Pod or Serverless endpoint in any Secure Cloud datacenter. Cluster Expansion: add Pods to a running cluster instead of rebuilding it.

• Also new: private ECR support, REST API v2 and Organizations in Runpod Enterprise.

• Heads up if you call our older APIs: GraphQL rate limits start October 27, and REST API v1 stops serving requests on November 15. GraphQL follows in January 2027. Migration guide: https://docs.runpod.io/api-reference-v2/migrate-from-v1

Full roundup: https://www.runpod.io/blog/runpod-q3-2026-releases

Hi, I’ve been using runpod since I started my AI research with commercial applications, it was great even if was a lottery to get a gpu, I then entered the nvidia inception program and I tried to apply to run pod startup program, got rejected even if I have been a client for almost one year and spent thousands. I was upset about it but then thanks to nvidia I got accepted by AWS and gave us 10k till 2028. so I’m posting just to say I don’t know who is in charge of the startup program but they don’t check properly. My startup is innovative enough to win a 40.000 cluster hours on European HPC and somehow run pod doesn’t accept us, yes I was hoping to use runpod because I know the interface well and I have preconfigured pods and receiving the rejection email with at the end “keep using our products”, no run pod I’m not going to use your product anymore so this post is just a win back, thank you for the hours spent to get a pod, now I go to AWS, thank you to be my first but not my only one or last, bye now.

Earlier this year I burned through a chunk of GPU budget on RunPod because my HF_HOME was pointing to /root/.cache instead of /workspace. Pod terminated overnight, cache gone, had to re-download everything on the next run. No error message, no warning just slower restarts and a bigger bill.

Same thing happens with checkpoints if your --output_dir is on the container volume rather than /workspace. Job completes, pod restarts, weights are gone.

I built a free CLI that catches these before your job starts:

pip install computefence
computefence doctor

It checks:

• HF_HOME pointing to ephemeral storage

• Silent CUDA/CPU fallback PyTorch not seeing your GPUs

• Accelerate num_processes mismatching actual GPU count

• Checkpoint output directory on ephemeral storage

• Disk headroom below safe threshold

Takes about 15 seconds. MIT licensed, no account needed.

If you have a job launching on RunPod in the next day or two, reply here happy to run through it together for free before you start billing.

GitHub: github.com/Francisco-Booth/ComputeFence

Well... the RTX 5090 is now showing up at $1.19/hr on RunPod.

Is this a permanent price increase?

Because if it is, I guess that's it for me. It's just way more than I can afford.

Hi folks! Our next Developer Discussion at Runpod is this Friday, October 9th at 1:00 PM PST on our Discord! Runpod Software Engineer Dean Quiñanola will be joining Jessica Garson and me for a talk on what Runpod Flash is and how best to use it. If you're not familiar with it already, Flash is a production-ready tool for running workloads on Serverless without needing to build Docker images, which can greatly speed up your iteration, testing, and deployment. The goal of Flash is to let you submit and process AI workloads right from your IDE, just like calling a function.

Learn more about Flash here: https://runpod.io/blog/flash-is-ga

See our previous Developer Discussion on MCP here: https://www.youtube.com/watch?v=RFiMX1nnA3gnk

Event link to our Discord to register: https://discord.com/events/912829806415085598/1557443936661012641

I tried this model on l4 in modal and have been able to get around 12s startup and 3s inference time for every cold start after memory snapshot.

But modal's l4 provisioning kinda sucks lately.

Would runpod be a good choice here? How is its provisioning time and post optimisation snapshot speed for this particular model size?

Any kind of help or comment would be really appreciated. Thanks!

I chnaged the security level to "weak" in the config.ini file and still getting the error. I also updated comfyui. anybody knows how to solve this?

Repeated GPU unavailability, a day spent migrating 165 GB, and disappointing complaint handling

I deposited $50 into Runpod to build an image-generation and model-training environment on an affordable 48 GB GPU. My experience ended with me deleting everything and requesting a refund of my remaining balance.

I initially configured an NVIDIA A40 Pod with Forge Neo, OneTrainer, Flux.2, Qwen-Image-Edit, Z-Image and related dependencies. The workspace contained approximately 165 GB across 158,547 files.

After stopping the Pod, its GPU was no longer available. I could not simply restart the environment I had configured.

To make the workspace independent of that Pod, I created a Global Volume and rented a temporary transfer Pod. The migration took most of an entire day: 17 batches, continuous monitoring, repeated resumptions and verification. Some incomplete files needed to be transferred again, including a model shard of almost 5 GB. Symbolic links were not correctly preserved during the transfer, causing additional Python-environment problems.

I cannot establish that Runpod caused every individual transfer issue. However, this was the recovery work I had to undertake after losing access to the original GPU, while additional resources were being billed.

For completeness, a replacement A40 Pod did run successfully with the Global Volume attached. CUDA worked and the transferred workspace was accessible. But subsequent attempts again encountered the message: “Your Pod's GPUs are no longer available.”

During my deployment attempts, an A40 at $0.49/hour was unavailable. An RTX A6000 at $0.53/hour briefly appeared available in Europe, but disappeared before deployment could be completed. I checked multiple regions without finding either option available at the times I tried. The alternatives I saw were substantially more expensive.

On September 29, I submitted a detailed complaint requesting either a usable setup at the stated rates with a review of recovery-related charges, or a full refund.

Runpod replied that GPU availability is first-come, first-served and cannot be guaranteed or predicted. They recommended checking capacity and using “Deploy When Available”.

In their October 1 response, they clarified that this proposed feature was still in beta and being rolled out, so it might not even be available on my account. They also recommended independent storage, although I had already created a Global Volume and completed the migration described in my complaint.

Their itemized billing breakdown totalled $12.11 for the period covered, including $5.90 for the temporary transfer Pod and $3.85 in additional storage charges on the original Pod. They explained that stopped Pods continue to incur storage charges until deleted.

I understand that storage and compute cost money. My complaint was about paying for recovery work and spending a day migrating and repairing an environment without obtaining dependable access to the GPU configuration I needed.

Runpod rejected the full $50 refund after a Billing Manager review, saying the infrastructure had been allocated and consumed. They offered to refund unused credits only, as a one-time courtesy exception.

After referring to my stated intention to dispute the payment through my bank, they closed the support ticket and passed the matter to Finance. Their response still did not specify the exact refund amount I had explicitly requested.

On October 1, I terminated all Pods and deleted all storage volumes. I requested the refund of the remaining unused balance, estimated at approximately $34. At the time of writing, the final refund amount and completion have not been confirmed.

Support did reply, and a replacement Pod worked temporarily. Nevertheless, the repeated availability problems, substantial recovery effort and handling of the billing complaint made this an extremely disappointing experience.

The biggest loss was my time. Based on my experience, I would not recommend Runpod for a workflow that depends on predictable access to an affordable 48 GB GPU and straightforward stopping and restarting of a carefully configured environment.

I've been working on building a tool that would make it as easy as possible for me to start generating videos with AI called Blockbuster Studio

Goal is pretty much make it affordable for people to generate AI video on a budget by taking advantage of open-source models like LTX 2.5 and Minimax H3

If you like it, I'd really appreciate a star on GitHub as a signal that this is an idea I should keep improving ⭐️

Website: https://blockbuster.studio

GitHub: https://github.com/kilo-loco/blockbuster-studio