Sev Geraskin: somebody has to keep the fair running

The Ferris wheel was still there. The people who made it work weren't.

Sev Geraskin began his Futureproof talk with a childhood recollection of a fairground losing its operators, maintenance and reliable support during the collapse of the Soviet Union. The physical machinery outlasted the arrangements that kept it useful.

He remembered teenagers getting the bumper cars running again. Someone knew enough to try. Someone was willing to get their hands into the machinery.

That story travelled with him into AI infrastructure. A model can be available, a GPU can be installed and a product can have a very impressive demo. People still depend on power, maintenance and whoever answers when something stops working.

The fair doesn't run on the existence of a Ferris wheel. There's an unglamorous human arrangement underneath it. Sev wanted us to look there.

Sev's route into the subject was personal: craft in his family history, parents who became engineers, then his own work in distributed computing. By the time he reached the kitchen-table GPU, the question had become familiar. What does it take to keep a useful thing running?

One machine at home makes the dependencies hard to ignore. It needs somewhere to sit. It makes noise. It consumes electricity. Someone has to notice when it fails.

Scaling introduces more of those obligations. It also changes who can reach the service and who has the authority to interrupt it. In Sev's account, the distance between a working demonstration and a dependable service was full of these practical decisions.

That makes a useful companion to Amber Case's work on calm technology. People shouldn't have to become unpaid system administrators to use a tool. Making a service feel simple can require a considerable amount of care from the people operating it.

The best engineering example in Sev's talk was small enough to understand without owning a GPU.

A monitor checks a server. The server says it is healthy. But no user requests arrive. Is everything working, or has something between the person and the server broken?

Now the monitor itself stops reporting. Is the server down, or has the thing checking it disappeared?

Sev described designing for those differences rather than treating a heartbeat as the whole story. A component can pass its own test while the person trying to use the service gets nothing.

That's a sharp question to bring back to any AI product. What does your dashboard actually know about the user's experience? If every internal light is green, what could still be broken outside the part you are watching?

His work at PolarGrid concerns running inference near users across GPU sites. In the talk, voice was the concrete reason to care about that distance. A delay before the first word changes the rhythm of an exchange, even if the answer eventually arrives intact.

Sev reported latency improvements from the infrastructure his team was building. The broader design point survives without turning one reported measurement into a universal promise: people experience the whole path to the answer. A model benchmark doesn't include every part of that path.

Sev moved from monitoring a network to distributing its points of failure. If one machine becomes unavailable, another should be able to take the request. If every route depends on one special machine, the supposed redundancy has a very important asterisk.

In the Q&A, he explained distributed computing through that absence of a special computer: machines work together, with another able to take over when one becomes unavailable.

Then the question gets political. One company, one connection or one operator can also become the point everything depends on. Buying more machines doesn't necessarily change that arrangement.

My Sovereign AI for Whom? essay asks who gets access to the compute and who carries its costs. Sev brought a working engineer's version of that question: which dependencies remain, and who has the ability to keep the service available?

Technical resilience and community control have to be designed deliberately. A diagram with lots of dots doesn't settle either one.

Sev's community-compute proposal took the argument into a building. He imagined computing alongside places for people to learn and work, with housing included in the design.

The Compute Community Centre study describes a commons on a public-library model. Its current account also names unresolved questions about the building and its costs. This is a proposal people can examine and help develop, with the work of establishing it still ahead.

Asked about a pilot, Sev described the need to bring a location, equipment and participants together. Interest from people in the audience didn't make it a funded project. It made the next conversation possible.

His Economy of Wisdom framework asks how an organization affects the people it touches, including the hardship it absorbs and the fulfilment it enables. In this setting, that shifts attention beyond how busy the GPUs are. What can someone do because this resource exists? Who gets help learning? Who does the maintenance?

Our BC + AI communities already depend on people showing up to share skills and make introductions. A permanent computing commons would add physical infrastructure and operating responsibilities to that social work. Those responsibilities need owners as surely as the equipment does.

Sev ended by asking who is responsible for the lives that depend on the infrastructure.

Start there when you draw the architecture. Put the operator, the maintenance and the person's route into the system on the page. Then ask what happens when each one disappears.

Somebody has to keep the fair running.