I’m curious if this proposal necessitates forbidding multi-data center training. My gut reaction is “yes”, since you would have no way of ensuring that any information transferred between data centers isn’t going out to some un-monitored compute. But, I think you might be able to make this work if all (authorized) data centers used in the training run were monitored and mandated than any egress hash from one matches the ingress hash from the other?
(additionally, if multi-data center training isn’t allowable it also seems like you wouldn’t be able to transfer the completed model to a different data center, like one more suited for inference, after training)
A covert adversary is (far) less costly to defend against, since random sampling only needs to catch a single instance of cheating.
I’m skeptical that this claim if the mechanisms for catching cheating is what is described in section 5.2.3, using inspector agents to detect disallowed use instead of a hardline FLOP limit or model whitelist. It seems to me like inspector agents would end up flagging a lot of false positives that would allow a cheating prover to convince the verifiers to disregard them.
Suppose the U.S. government, China, and other jurisdictions were to seek an agreement for more responsible AI development and deployment.
Just for clarity, am I correct in saying that the “Prover” and “Verifier” are not fixed roles and that, in a US-China agreement, a US-backed agency would act as a prover on any Chinese data centers and the role would be flipped for any data centers on US soil? (i.e. distinguished from there being some third-party “Verifier” agency that does all of the verification work)
“I’m curious if this proposal necessitates forbidding multi-data center training.”
That’s a tricky edge case for the “all information in and out of a comput island is explainable”, for two reasons: One is the extreme information bandwidth, the other is that -as you explained- the links between datacenters would be hard to secure.
Since this is an edge-case and the size of upcoming megaclusters will probably eliminate the need for inter-datacenter pretraining, I expect this to not be an immediate dealbreaker.
If one really did insist on multi-datacenter training, you could still do the following: Each cluster is treated as an “island” whose in-out traffic must be fully explainable. Rather than capturing the whole traffic (which would be expensive), you can retrofit a setup that randomly samples from passively tapped optical fiber links. Basically a “panopticon” in which the prover can not predict which link will be sampled by the verifier, or when.
“(additionally, if multi-data center training isn’t allowable it also seems like you wouldn’t be able to transfer the completed model to a different data center, like one more suited for inference, after training)”
I am not quite following. Why would that be the case? Because the model has not been trained in a verified manner? Inference verification and training verification are different beasts. It probably makes sense to start with the former, and rely on post-hoc audits of models before training verification is ready.
Thanks for the post, Naci!
I’m curious if this proposal necessitates forbidding multi-data center training. My gut reaction is “yes”, since you would have no way of ensuring that any information transferred between data centers isn’t going out to some un-monitored compute. But, I think you might be able to make this work if all (authorized) data centers used in the training run were monitored and mandated than any egress hash from one matches the ingress hash from the other?
(additionally, if multi-data center training isn’t allowable it also seems like you wouldn’t be able to transfer the completed model to a different data center, like one more suited for inference, after training)
I’m skeptical that this claim if the mechanisms for catching cheating is what is described in section 5.2.3, using inspector agents to detect disallowed use instead of a hardline FLOP limit or model whitelist. It seems to me like inspector agents would end up flagging a lot of false positives that would allow a cheating prover to convince the verifiers to disregard them.
Just for clarity, am I correct in saying that the “Prover” and “Verifier” are not fixed roles and that, in a US-China agreement, a US-backed agency would act as a prover on any Chinese data centers and the role would be flipped for any data centers on US soil? (i.e. distinguished from there being some third-party “Verifier” agency that does all of the verification work)
“I’m curious if this proposal necessitates forbidding multi-data center training.”
That’s a tricky edge case for the “all information in and out of a comput island is explainable”, for two reasons: One is the extreme information bandwidth, the other is that -as you explained- the links between datacenters would be hard to secure.
Since this is an edge-case and the size of upcoming megaclusters will probably eliminate the need for inter-datacenter pretraining, I expect this to not be an immediate dealbreaker.
If one really did insist on multi-datacenter training, you could still do the following: Each cluster is treated as an “island” whose in-out traffic must be fully explainable. Rather than capturing the whole traffic (which would be expensive), you can retrofit a setup that randomly samples from passively tapped optical fiber links. Basically a “panopticon” in which the prover can not predict which link will be sampled by the verifier, or when.
“(additionally, if multi-data center training isn’t allowable it also seems like you wouldn’t be able to transfer the completed model to a different data center, like one more suited for inference, after training)”
I am not quite following. Why would that be the case? Because the model has not been trained in a verified manner? Inference verification and training verification are different beasts. It probably makes sense to start with the former, and rely on post-hoc audits of models before training verification is ready.
Here is recent work on both, if you are interested: https://amododesign.com/notes/2026-06-23-verification-algorithms/