Daniel Norberg

GPU scheduling looks like a technical problem. It's actually an org design problem wearing infrastructure clothes. The queue is just where the politics become visible. Here's what I mean: → Demand side (what's waiting, who's next) is owned by ML platform teams optimising for experiment velocity → Supply side (what capacity exists) is owned by infra/FinOps optimising for utilisation and spend When these collide, the "scheduling problem" becomes: who gets to define the rules? The formality of your answer scales with org size: At 5-10 people: Slack messages work. "Please don't use GPU 0 today." At 20-50 people: You need basic queuing. Jobs should wait, not crash. (Adept learned this the hard way. Their workflows would crash instead of queue when Slurm couldn't satisfy a 240-GPU request.) At 100+ people: You need explicit quotas. But quotas reveal waste. One bank had GPUs "allocated" at <35% utilisation because teams reserved capacity "just in case." At scale: You need borrowing + preemption contracts. Uber's approach: guarantee a baseline, allow opportunistic borrowing, reclaim with preemption. But this only works if users understand when they're running on borrowed time. The pattern: each governance transition happens when the previous approach's failure modes become intolerable. The winning move isn't a smarter algorithm. It's making allocation legible: baselines everyone can plan around, borrowing rules that don't surprise people, and preemption contracts that feel fair. Priority is a product decision wearing an infrastructure costume.

In honor of its 20th anniversary, what is your favorite YouTube video of all time?

I will write a little thread of the non obvious things I miss with Sweden