Exploring Memory Exhaustion as a Verification Approach

Memory Exhaustion belongs to a class of verification approaches known as Resource Exhaustion. The goal of Resource Exhaustion is to provide strong guarantees about what workloads are being run in a given datacenter. This could be used to enforce an international agreement on acceptable AI development.

Resource Exhaustion works by ensuring that resources on GPUs (such as compute and memory) are being completely utilised by authorised workloads, hence leaving no room for any unauthorised workloads. For example, by showing that 100% of available FLOP/s have been used for authorised inference, we can infer that there is no capacity left for unauthorised training.

The main benefit of Resource Exhaustion approaches is that they are a software-only solution to AI verification, in the sense that they do not require us to place any hardware sensors within monitored datacenters. However, Resource Exhaustion methods, while promising, are very speculative and are in the early stages of R&D.

Resource Exhaustion has traditionally focused on Compute Exhaustion, where we verify that 100% of available FLOP/s have been used for the authorised workload. Compute Exhaustion suffers from two drawbacks. First, it is difficult to determine the maximum FLOP/s available on a GPU due to uncertainties regarding chip overclocking, etc. Second, it is difficult to ensure that workloads cannot be optimised to take up less than 100% of available capacity. While there is initial research into these problems, we have yet to learn how feasible and secure Compute Exhaustion will turn out to be.

Memory Exhaustion is a promising alternative that can also be used as a complementary layer of defence. Memory Exhaustion works by verifying that 100% of memory is being used by the authorised workload, leaving none available for unauthorised workloads. The benefit of Memory Exhaustion is that it is easier to determine the total memory available on a chip via inspection (as compared to determining the maximum FLOP/s). It is also easier to make incompressible data that takes up 100% of space (as opposed to unoptimisable workloads that take up 100% of FLOP/s). One risk of Memory Exhaustion is that while no unauthorised workloads can be run without compute, it might be possible to run unauthorised workloads without any memory (e.g. by streaming in matrix multiplications from the network). This is one of the many open questions regarding Memory Exhaustion, which is currently even more speculative and early-stage than Compute Exhaustion.

Mechanism Design

We outline a system-level protocol for how Memory Exhaustion could be implemented:

1. Datacenter Identification: The auditor identifies a target datacenter and determines the number of GPUs present and the total memory available.
2. Workload Declaration: The datacenter operator declares an authorised workload that takes up the entirety of GPU memory (HBM).
3. Workload Execution: The datacenter operator runs the workload.
4. Random Challenges: At random times, the auditor challenges the datacenter operator to return hashes of random segments of the current memory state. The auditor checks these hashes to ensure that they correspond to the authorised workload.

Confidentiality

To preserve the confidentiality of the workload (including sensitive data such as model weights and inputs), the entire process will be run using zero-knowledge proofs. For example, the datacenter operator declares the hashes of the model weights and inputs and submits hashes of the memory segments when challenged. Zero-knowledge proofs allow them to prove that the memory segments indeed correspond to running the model on some input.

Security

It is important to verify that the memory state is indeed stored on the GPU itself rather than in an external location like an SSD. Our protocol must hence show that the data is stored close to the GPU compute cores. This is done by requiring timed challenges with multiple alternating rounds of hashing and memory accesses, where the result of one round of hashing determines the address of the next memory access. Only the final result is returned to the auditor as the challenge response. Note that care must be taken to design a hashing function that can only be efficiently computed on the target GPU model. The fact that these challenges need to be timed also means that it is important to minimise network jitter between the auditor and the datacenter.

Compressibility

An adversary might claim that their GPUs are fully packed with an approved workload. But if the data is secretly compressible, there will be leftover room for unauthorised workloads. In the extreme case, the “sensitive data” might just be all zeros and hence trivially compressible.

We therefore require that data be stored in an incompressible way. This is done using an encoding and decoding process, where all data is first incompressibly encoded before it is written, and then decoded whenever it needs to be read.

A simple encoding scheme would be to XOR all data with a pseudorandom datastream before it is written. This datastream would be generated from a seed provided by the auditor. This ensures that the stored data is incompressible. When the data needs to be used, the pseudorandom stream can be regenerated from the seed to decode the original data. During the random challenges, the datacenter operator simply runs the hashing function on the encoded data.

This encoding and decoding scheme must be carefully chosen. While a faster encoding scheme reduces overhead, one that is too fast would compromise security. This is because, when challenged, an honest operator needs to fetch the encoded data from memory, while a dishonest operator (in the all-zeros case) could just encode the data on the fly without needing to perform any memory reads. To prevent this, encoding must take longer than a memory read. A scheme where decoding is faster than encoding would be ideal.

Full Mechanism

After accounting for the considerations above, we present the complete protocol:

1. Datacenter Identification: The auditor identifies a target datacenter and determines the number of GPUs present and the total memory available.
2. Workload Declaration: The datacenter operator declares the authorised workload that they intend to run, including hashes of sensitive data such as model weights.
3. Workload Execution: The datacenter operator runs the workload.
   1. All memory writes are first encoded.
   2. All memory reads are decoded before use.
   3. Hashes of inputs are streamed to the auditor.
4. Random Challenges: The auditor issues random timed challenges to the datacenter operator.
   1. The datacenter operator must run multiple rounds of hashing and memory accesses on the encoded memory state.
   2. The final response is sent to the auditor.
   3. The auditor verifies via a zero-knowledge proof that the challenge response matches a memory state consistent with the authorised workload and the declared hashes of the inputs and model weights.

Memory Bandwidth Exhaustion

This section presents highly speculative ideas on Memory Bandwidth Exhaustion. In Bandwidth Exhaustion, workloads are required to constantly read from or write to memory at maximum bandwidth. This would provide even stronger security guarantees.

Memory Write Exhaustion

During workload execution, the auditor constantly streams new randomness to serve as the encoding seed. All memory writes must be encoded with the latest seed. The random challenges verify that the memory state has been freshly encoded, proving that memory is constantly being written.

Memory Read Exhaustion

During workload execution, on each memory read, the datacenter operator hashes the encoded data and streams the results to the auditor.

A dishonest operator could potentially declare all-zero data and run the encoding and hashing on the compute cores without using any memory bandwidth at all. To prevent this, we will need an encoding scheme such that encoding plus hashing at full memory bandwidth takes up more compute than is available on the GPU. This means that in our scheme, decoding must be faster than encoding (so that an honest operator can run the scheme at full bandwidth).

As before, the hashing function has to be carefully designed so that it can only be run efficiently on the target GPU model. It also needs to incorporate fresh randomness from the auditor.

Open Questions and Research Areas

• Workload Declaration
  • Are the memory states of today’s workloads deterministic?
  • How can we ensure that workloads are auditable while remaining confidential?
• Workload Execution
  • How can we find a secure encoding scheme that minimises overhead?
• Random Challenges
  • How can we design the challenge function to ensure that the full memory state is actually stored on the GPU?
  • How do we address network jitter?
  • How can we verify everything in zero-knowledge?
• Other
  • Is it possible to run unauthorised workloads efficiently without memory?