牧野鷹揚
I am highly likely to leave Runpod after my project is finished
Engineers using RunPod: check your GPU clocks and training throughput before leaving a job running overnight. My experience shows how expensive severely underclocked compute can become. I originally liked RunPod. It felt accessible and friendly for personal AI projects. The handling of this incident has changed that. From September 23–26, my RTX PRO 6000 Blackwell Workstation GPU delivered about 21% of my reference run’s training throughput, while billing continued at the full hourly rate. Same GPU model, matching core training code and model settings: - Median GPU clock: 2,662 MHz → 585 MHz - Training throughput: 645 → 137 samples/second - Both reported roughly 600 W under load The second dataset was larger; the comparison above is per sample. The slowdown persisted across thousands of telemetry readings. On October 2, RunPod support confirmed low clocks on the host under a full 600 W load and repeated NVIDIA driver errors. The precise cause remains unresolved. A moderator in RunPod’s Discord also acknowledged that more than one user had raised concerns about this issue. As of October 9, I have not received a clear root-cause explanation or recurrence-prevention plan. The dashboard I checked did not display GPU clock frequency. I also have no commitment to a clock-frequency dashboard or automatic underclocking alerts. Basic clock visibility should be the minimum. The advice was to spot the problem myself, stop the Pod and deploy elsewhere. Customers are responsible for their code. Monitoring host health and addressing a documented host-side performance problem should be the provider’s responsibility. Engineers should be able to leave training running overnight without babysitting rented hardware to protect themselves from wasted charges. I asked for a proportional refund to my original payment method. On October 8, RunPod refused, citing its policy on consumed services. Its email described the credit adjustment as a one-time exception, with no guarantee of similar adjustments in future incidents. Credits requiring me to keep using the platform are not an adequate remedy for me. Framing this as an exceptional courtesy, while leaving the same risk with the customer, is unacceptable. Imagine renting a supercar for the Nürburgring and discovering it delivers only a quarter of its normal power. The rental company refuses a refund because you already drove it, then offers credit toward another rental. That is how this feels. In my view, a “consumed usage” policy should not shield a provider from responsibility for defective service. I want a clear technical explanation, safeguards and a proportionate cash remedy. Until then, do not assume high GPU utilization means you are receiving the performance you paid for.
Response from RunpodSep 8, 2026
Thanks for the honest take! Glad Runpod's been solid for your AI side project. Pod availability can get tight for popular GPU types at times, and we know that matters most when you're relying on it for production. If you hit that again, send the GPU type, region, and timeframe to [email protected] and we'll dig into it.