Verified Compute Allocation Disclosures as a Foundational Governance Tool

A promising first step toward pacing the frontier

Thanks to Page Hedley, Thomas Larsen, and others for feedback and discussion.

Confidence level: Medium. We have thought about these arguments substantially but wouldn’t be surprised if we were missing important considerations.

We think that frontier AI companies should begin pacing as soon as possible; by pacing, we mean intervening to delay the time at which AIs at a given capability level are developed.

Our proposed first step toward pacing is verified compute allocation disclosures (VCAD): companies should regularly report how their compute is used, for example by classifying compute used for AI R&D vs. safety R&D vs. external inference. These reports should be verified by third-party auditors, ideally with government support.¹

Once VCAD has been set up, companies have the ability to credibly demonstrate things about their workloads, such as what percentage of their compute is being used for AI R&D.

In this post:

We introduce a framework for thinking about pacing proposals: (a) whether the pacing is conditional on something, (b) what safeguards it requires, (c) what restrictions on the inputs to AI R&D it requires, and (d) what needs to be verified to enforce it.

We argue that VCAD is crucial to nearly all pacing proposals that are less extreme than shutting off the GPUs. We make two key claims which we’ve found that others aren’t tracking:

• VCAD is required for verifying nearly all restrictions on the inputs to AI R&D, including those that don’t directly reference compute (such as delaying internal deployment). The basic reason is that an attack on essentially any input-restrictions pacing regime is to do prohibited things with compute that isn’t effectively monitored. Even if you’re only verifying safeguards such as monitoring requirements, VCAD is often required to make sure that the safeguards aren’t disabled on hidden compute.

• Slowing software progress, rather than only delaying training runs, makes pacing much more effective. If you only delay training runs without slowing software progress, you get a “software overhang”: an undesirable buildup of unused software progress. This could lead to sudden bursts of progress when training runs are eventually approved, and furthermore the unused software progress could be stolen by China or more generally diffuse to other actors. This means that even if you grant that VCAD isn’t needed for verifying training run delays, it’s highly desirable because it’s needed to verify software progress slowdowns.

Finally, we describe how VCAD could concretely lead to pacing (introducing the importance of “D”, the public disclosures) and argue that VCAD is urgent.

Framework for thinking about pacing proposals

This figure summarizes how we think about the landscape of pacing proposals:

Unconditional vs. conditional pacing. Unconditional pacing involves applying a consistent pacing lever and magnitude, full stop. For example, a 10% AI R&D compute cap throughout takeoff. Conditional pacing involves pacing only insofar as some condition is met; for example, risk assessments or capability thresholds. This could lead to e.g. one company doing it and another company not doing it, or one company doing it one week and then not doing it the next week. This is a spectrum: “quasi-conditional” pacing could involve making ad hoc adjustments to pacing magnitude depending on high-level observations, which aren’t pre-registered.

Input restrictions and safeguards. Input restrictions involve limiting the inputs to AI R&D: for example, R&D compute. Safeguards are targeted interventions to make AI development safer, such as not using neuralese. Some proposals, such as requiring safeguards directly, seem at first glance not to require input restrictions. However, such proposals require input restrictions when the required safeguards haven’t been met – for example, they might require pausing all training runs of models above a certain size until safeguards have been implemented, which requires verifying that none of the various datacenters are doing such training runs. This applies more generally to all of the proposals that we’ve seriously considered.

Verification. Our best guess is that verifying compute inventory as well as allocation is required for nearly all proposals, even ones focused on safeguards. The basic reason is that an attack on essentially any pacing regime is to do prohibited things with compute that isn’t effectively monitored. This is expanded upon in the next section. Other verification mechanisms, such as verifying implementation of safeguards, are useful for subsets of proposals. Capability measurements are required for some proposals and highly desirable for all proposals.

Why VCAD is crucial for nearly all pacing proposals

By VCAD, we mean Verified Compute Allocation Disclosures: records classifying how a company’s compute is used (for example, AI R&D vs. safety R&D vs. external inference) that are verified by third-party auditors. Ideally there are public disclosures of the compute allocations, but this isn’t as necessary (so the required part is technically more like VCA, but we use VCAD below for consistency).

VCAD is required for verifying non-extreme input restrictions, and for verifying many types of safeguards

All proposals require the ability to restrict inputs. All proposals require the ability to have input restrictions, even safeguard-focused ones, in order to ensure that companies pace if they’re not meeting the required safeguards.

VCAD is necessary to verify a variety of input restrictions, not just AI R&D compute caps. Verifying an AI R&D compute cap restriction is the case where VCAD is most obviously necessary, and this is the input restriction that we’re most excited about. However, it’s also needed for verifying other input restrictions. This is because verifying compute allocation disclosures will have two structural components:

1. Verifying that the compute the auditors have visibility into follows the claimed allocation.

2. Verifying there aren’t hidden compute uses outside of what they have visibility into.

An attack on essentially any pacing regime is to trick the auditors into believing the wrong claimed allocation (subverting (1)) or to do prohibited things with compute that isn’t effectively monitored (subverting (2)).

For example, VCAD is necessary (or at least highly desirable) to verify:

• Internal deployment lag: Verifying an internal deployment lag requires making sure none of the internal compute workloads are running restricted models. It also requires distinguishing internal from external workloads, verifying that externally deployed models aren’t doing AI R&D which is then snuck into the company (or that the company isn’t using other companies’ externally deployed models for its own AI R&D), and making sure all compute is accounted for.

• Approval before training runs: Restricting training requires that there is no unverified compute doing a training run.

However, if input restrictions are extreme enough, then VCAD isn’t needed. For example, if the GPUs are all shut off, then it becomes relatively easy to verify via e.g. power monitoring. This is doubly true if the GPUs are destroyed. We think that these proposals are promising, but they are less politically feasible than less extreme ones.

Even if only safeguards are being verified rather than input restrictions, VCAD is required in many cases in order to ensure that the safeguards are being applied to all workloads. For example, a requirement to monitor models during internal deployment must be verified by checking that there aren’t unreported workloads which violate it.

Slowing software progress, rather than only delaying training runs, makes pacing much more effective

Relying on training run approval without restrictions on the rest of the R&D process (such as an R&D compute cap) leads to a buildup of software progress (i.e., algorithmic and data progress) waiting to be used:²

This could lead to sudden bursts of progress when training runs are eventually approved, and furthermore the unused software progress could be stolen by China or more generally diffuse to other actors. Because software progress is accumulating, the slowdown from delaying training runs may be minimal; this depends on how much AIs are helping to accelerate AI R&D (the more they help, the more slowdown there is from delaying training runs).³

While we argued above that VCAD is necessary for slowing both software progress and training, it’s more clearly required for slowing software progress (e.g., via AI R&D compute caps or internal deployment lags). So even if VCAD isn’t needed for slowing down training, it’s highly desirable because it’s needed to verify software progress slowdowns, including in conditional pacing regimes such as a safety-case-based one.

More on this point here.

How VCAD could lead to pacing

Our current top pacing proposal is directly enabled by VCAD: reallocating compute from AI R&D to other use cases. VCAD could facilitate pacing in two ways: voluntarily and by mandate.

Voluntary. AI companies are in a collective action problem: they are proceeding faster than they believe optimal. VCAD supplies two elements that can help resolve the problem, prompting a race to the top.

1. Trust: Claims of costly restraint today are not always believed by competitors. VCAD provides a way in which companies can take commercially costly actions in the interest of safety or security that competitors can trust.

2. Public credit: VCAD’s public disclosures (the “D”) offer a simple, commensurable benchmark for cross-company comparisons, which can help channel public and policymaker concern into a concrete request: less compute on R&D.

Interest in pacing is high and will grow with evidence of risk. Demand for reduced R&D allocations gives companies a self-interested reason to reallocate and rewards those that do, spurring a race to the top. Each reallocation would be a unilateral response to, among other things, public demand based on a public benchmark. The dynamic does not depend on, and should not involve, agreement among companies on allocation levels.

Mandatory. We hope that some jurisdiction eventually mandates some form of pacing. Most candidate forms – caps, floors, cap-and-trade, conditional requirements – benefit from verified compute allocation. A standard approach to VCAD that companies have already built and stress-tested makes such legislation faster to write and more workable.

Because pacing is urgent, VCAD is too

Companies are barreling toward highly capable AIs. Pacing might be incredibly urgent in order to avoid having a misaligned AI do recursive self-improvement. Given that VCAD is a crucial part of nearly all pacing proposals, battle-testing it inside AI companies is urgent. While it’s possible that we will be able to figure it out at the last minute, that’s not guaranteed. Furthermore, pacing is more likely to happen if there is an existing VCAD process that a company can follow that is trusted by external actors. Developing this process could take time, so starting the process is urgent.

1. E.g., disclosures must be signed by the board and CEO and reported to Congress, and the Intelligence Community could help verify redacted evidence.

2. An AI R&D compute cap avoids this software overhang, but not a compute overhang: if the cap is later relaxed quickly, the compute that was diverted to inference returns to R&D all at once. So a cap works best as a persistent or gradually relaxed restriction.

3. Beyond delaying AI R&D acceleration, it’s possible that the “much more effective” claim might not hold up in literally every circumstance; for example, if you’re on the brink of surpassing max-controllable-AI, the point at which AIs could take over if they were misaligned, delaying training runs might be especially valuable.