Research Engineer / Research Scientist, Remote Compute Accounting

Compression is one of the open questions: weights or a KV cache engineered for fast lossless decompression would let a prover reconstruct state it was not actually holding, freeing the hardware for whatever else it wanted to do. Showing that workload state cannot be decompressed inside the challenge window, or modifying workloads so that it cannot, would unlock the approach. Beyond that, a prover may hold secret memory capacity in error-correcting-code cells or overprovisioned regions; the challenge has to be designed so honest response time stays feasible; and the deadline has to be short enough to block cheating while surviving network latency and kernel launch times.

Your work

You would own the question of how much of a cluster can be accounted for from outside it, and how little room can be left over.

Concretely, that means designing challenge protocols and then measuring whether real accelerators can satisfy them: microbenchmarking, writing challenge kernels, characterising what high-bandwidth memory can and cannot do under adversarial conditions, and deciding whether the numbers support a claim someone could stake an agreement on. The work sits between two disciplines: measurement is GPU performance engineering, the rest is constructing a hardness assumption and then trying to break it. We expect most candidates to be strong on one side and curious about the other. You'd work alongside cryptographers and hardware-security colleagues, and you'd be expected to publish, including when the answer is that something does not work.

Representative projects

• Implement a candidate challenge function and characterise honest-response latency across real cluster topologies.
• Establish how much spare capacity a cluster could retain while still passing every challenge, then design that margin down.
• Run the adversarial compression study: how much of a frontier model's weights or KV cache can be losslessly decompressed inside a realistic challenge window, and how much hardware does that free up?
• Design and evaluate post-training that measurably raises the cost of compressing weights, without measurably hurting the model.
• Quantify how much memory a prover could plausibly hide, and what protocol changes make hiding it useless.
• Extend the approach from memory occupancy to compute, through proof-of-useful-work schemes where the declared workload's own computation carries the evidence.
• Take the protocol end to end against a live inference cluster and write up what broke.
• Design a red-team/blue-team competition for the protocol: cheap to run, because they need no new hardware.
• Red-team our own timing assumptions.

About you

We are hiring this role at a range of levels. We care more about ability and trajectory than years of experience.

You may be a good fit if you:

• Have GPU performance or systems measurement experience (kernels, microbenchmarks, memory hierarchies, distributed timing) or a cryptographic background and a real appetite for getting your hands on hardware.
• Are rigorous about measurement, including about the ways your own measurement can be fooled.
• Can hold an adversary in your head while you optimise something.
• Are comfortable working on a protocol that may turn out not to work, and saying so in public if it does not.
• Thrive in ambiguous, early-stage environments where defining the problem is part of the job.

Strong candidates may also have:

• CUDA or equivalent low-level accelerator programming.
• Compression, information theory, or model quantisation experience.
• Background in timing-based protocols, proofs of space or time, or distance bounding.
• Experience characterising hardware you don’t have documentation for.
• Familiarity with LLM inference internals: batching, KV cache management, scheduling.