Why researchers ignored our GPU platform, and what made them adopt the next one

A launch that wasn’t a success

In 2025, I shipped my first GPU platform for medical AI research. It ran on Kubeflow, and it went live. On paper, the job was done.

Then I looked at who was using it. Far fewer researchers than we had planned for. Most of them still logged into the GPU machines over SSH, installed their own packages, and lined up for the most powerful cards while the others sat idle.

The platform was live. It was also failing at the one thing it was built for. This article is about that gap: the distance between a platform that runs and a platform people use.

What I heard when I asked

So I stopped building and started asking. I sat down with the researchers, one by one, and asked a simple question: why aren’t you using it?

The answer was the same every time. Kubeflow was too complex for their daily work. They were not platform engineers, and they did not want to become one to train a model. Their day already had a shape: open VS Code or Jupyter, connect over SSH, run the job. My platform asked them to give that up.

Their habits also explained the other problems. Without a queue, everyone went straight to the fastest GPUs and left the rest idle. Without a shared environment, everyone installed their own package versions, and the same bugs kept coming back.

None of this was a technical failure. It was a fit problem: I had built a good platform for the wrong way of working.

The options on the table

I saw three ways forward.

The first was to keep Kubeflow and train every team on it. It is a powerful platform, and training would have closed part of the gap. But it still asked researchers to change how they work, and that was exactly what they had told me they would not do.

The second was to go back to direct SSH and add rules on top: who uses which GPU, which packages are allowed. Nothing would change for users. Nothing would be under control either, and the idle GPUs and environment bugs would stay.

The third was Slurm. It is a simpler scheduler, and many researchers already knew it from research computing. It hands out every GPU through a queue, so nobody has to fight for the fastest card. And it works from a login node over SSH, the way they already worked.

I chose Slurm. Not because it was the most powerful option, but because it was the one people would actually use.

What we built

This time, I built it with the researchers, not for them. We went from a proof of concept to an MVP, then to production, and they tested every step before we moved to the next one.

The cluster runs Slurm, with two masters, one login node and ten GPU compute nodes. The work is split into three partitions: training, data processing, and interactive sessions. Each kind of job gets the resources it needs without blocking the others.

Jobs run in containers with the NVIDIA Container Toolkit. Every team gets the same software stack and the same versions, and nobody installs packages by hand on the nodes anymore.

Researchers kept their tools. They still use VS Code, Jupyter and SSH, now with single sign-on. The only change is that they submit jobs from the login node instead of logging into the GPUs directly.

Behind the scenes, Ansible deploys every node, Munge authenticates them, a shared NAS holds the data, and Grafana shows the state of the cluster at a glance.

What changed

The difference showed up in how people worked, not in a launch announcement.

Several research teams now use the cluster every day, and most training jobs run on it. A platform that was barely used became the default way to train models.

Every GPU is in use. Jobs go to the queue, not to the fastest machine, so the cards that used to sit idle now do real work.

There is one controlled environment. The bugs that came from package versions installed by hand on the nodes are gone.

And nobody had to learn new habits. Researchers open the same editor, connect the same way, and get more out of the same hardware.

What I’d tell another platform team

Three lessons stayed with me.

Measure adoption, not launch dates. My first platform was live, and still a failure until I asked users why. A go-live date tells you the platform runs. Only usage tells you it works.

Build on habits, not against them. Researchers adopt a platform that fits the tools they already use, not one that asks them to change. The best feature I shipped was the one they never noticed: they kept working the way they always had.

Fix the environment first. Most of the bugs came from the setup, not from the code. One shared, controlled environment did more for reliability than any new feature.

Today, I judge every platform I build the same way: by how many people use it, not by the day it went live.