Note: this is a repost of a verification design I developed working as a consultant with the team at Lucid Computing and originally posted on the Lucid Labs Substack.
Overview
In this design brief we present “Traffic Shaping for Workload Classification” – a verification solution that enables a third party to verify that frontier training[1] is either not occurring in a declared compute facility, or is occurring, but at a cost multiple that would render a frontier training run of a new model that is 10x or more the size of current frontier models economically infeasible. Our design builds on existing traffic restriction and compartmentalization designs, which require reorganizing compute into size-restricted “pods” and introducing traffic shapers to throttle the external network traffic to the pod to a threshold per GPU which is sufficient for inference, but insufficient for frontier training. Additionally, our design requires the introduction of a “random router” for inference requests, which ensures that inference requests are routed randomly to pods. This adds resistance to decentralized training techniques like pipeline parallelism.
Unlike network tap designs with recomputation, our design does not require analysis of the network traffic or recomputation of output results. Instead, the design introduces a number of network-based constraints on AI data centers, which together make training a new model that is larger than the current frontier model size extremely inefficient. While the exact level of cost inefficiency the design imposes on an adversarial training run will vary depending on the exact model size and architecture the adversary chooses, our analysis suggests that these inefficiencies would likely serve as a substantial deterrent to state actors or individual labs defecting from a treaty or regulatory regime and attempting to train new frontier models that are significantly larger than the current frontier.
For example, based on an analysis of today’s best-known inference and training architectures (see Appendix A below for details) we estimate that retrofitting data centers with a Traffic Shaping solution could enforce an inefficiency multiplier (lower-bound) of approximately 350x on adversaries attempting to covertly train a new frontier model that is approximately 10x the size of the current frontier (60T parameters). By this we mean that at least 350x more GPUs would be required for training a model in the same amount of clock time, or 350x the time would be required with the same number of GPUs, versus a comparable cluster operating without the bandwidth constraints enforced. Central estimates of the inefficiency factor are closer to 1000x - 10,000x range depending on the adversary’s choice of training architecture.
Overall, Traffic Shaping offers a workload classification solution that is rapidly deployable today, based on mature technologies and which has significantly lower up-front technical deployment complexity and less security concerns for key stakeholders than alternative designs like full recomputation. Given these characteristics, Traffic Shaping appears to be a very attractive candidate solution to verify that new models larger than the current frontier are not being trained covertly in declared data centers during a coordinated slowdown.
Solution Specification
Our verification solution requires several modifications to the network topology[2] of a cluster:
1) Pod Size and Resource Restrictions
Data centers complying with this design must group all machines into inference “pods” such that each pod is restricted to the minimum arrangement of machines and resources required to service inference requests for models with a fixed maximum size, with reasonable efficiency, but no more than that. When we consider “resources” here, we especially consider external (uplink) network bandwidth, HBM and fast memory and fast storage. For example, for serving a Fable-sized model (estimated 6T parameter MoE) we might model a pod as a rack with 72 GPU GB200s, 13.5TB of HBM3, 30.5TB of fast memory and 4TB of fast storage (see Appendix A for more details). An example network topology for a data center with this verification design deployed is illustrated below.
Figure 1: Inference Data Center Network Topology With the Solution Deployed
2) Network Monitoring / Throttling
As shown in Figure 1, a network shaper must be installed at the “north-south uplink” point at the boundary of each pod. The objective of this tap is to restrict network traffic, averaged over each time interval (e.g. 1 minute, or hour) to a quantity that is sufficient for serving inference but insufficient for enabling pods to efficiently contribute to training runs.
3) Load Balancer / Router Which Randomly Assigns Inference Requests to Pods
The load balancers / routers used for routing inference requests to pods must be replaced by new versions of these network components so that the following constraints are satisfied:
The new load balancers are configured and agreed upon by all parties and are built on either commodity hardware or open standards and specifications and developed through a mediated co-design process between the verifier and the data center owner (prover).
The load balancers do not enable recording or analysis of inference requests, but do ensure that inference requests are routed to pods randomly[3].
Pod sub-networks are restricted so that they can only receive requests proxied by the load balancer / router infrastructure (end users cannot send successive requests directly to the same pod).
The purpose of this component is to make it far more difficult for adversaries to utilize decentralized training techniques based on pipeline parallelism or similar, by making it far more difficult for pods to communicate with each other in decentralized training strategies that would attempt to utilize pods as nodes.
4) Physical Security
All machines and networking components related to the pod and inference load balancers must be physically secured. GPU machines must also be internally inspected at least initially to ensure that they do not contain additional networking components beyond those that have been declared, particularly wireless network components. The networking infrastructure must also be physically secured. We believe that the best way to physically secure the cluster is through a combination of cameras, custom-designed physical server enclosures, random spot inspections and countermeasures against wireless networking. However a complete analysis of the physical security required to support a real-world deployment of this design is beyond the scope of this document.
Why Pre-Training New Frontier Models Under Traffic Shaping Restrictions is Difficult
The goal of our design is to ensure that pre-training a new frontier LLM using only GPUs located in pods is economically infeasible. Our design is primarily concerned with preventing pre-training of new models that are strictly larger than the current frontier. While it is impossible to perfectly model the inefficiency multiple an adversary would face, we can explain from an engineering standpoint why a pod-constrained training run would be much more difficult than an ordinary training run. And we can also produce estimates of real world inefficiency factors by analytically modeling the most likely training approaches adversaries would consider when constrained by this design. An example of such an exercise is presented in Appendix A and suggests that conservative lower-bound inefficiency multiples are likely to be at least 350x, even for decentralized training strategies and are likely 1000x or more for adaptations of standard centralized training strategies. This is due to the following high-level difficulties our design presents for an adversary attempting to train a new frontier model utilizing GPUs in pods:
Network Bandwidth Bottlenecks Performance
Inference produces relatively small volumes of external traffic, while training requires frequent movement of gradients, model state, and intermediate activations among the machines participating in the run. By limiting each pod’s external bandwidth to a level that comfortably supports inference, the design turns any communication that must cross pod boundaries into a severe performance bottleneck. Standard centralized training would be particularly affected because gradient synchronization and model-parallel communication occur repeatedly throughout training.
Low-communication techniques can reduce some forms of data-parallel synchronization, but they do not eliminate the inner-loop communication required when a model must be distributed across multiple pods. In particular, pipeline activations and mixture-of-experts routing traffic would still have to traverse the restricted uplinks. Appendix A evaluates several representative training strategies and provides quantitative estimates of the resulting inefficiency.
Pods Can’t Hold a Full Model Copy for Frontier Training
An additional difficulty for any adversarial data center operator attempting to train a new frontier model using pods is that the majority of training techniques – even many decentralized training techniques like Distributed Low-Communication Training (DiLoCo) – assume that each “node” (a collection of fast-network-connected computers contributing to training) can at least hold at least a full copy of the model. So if an adversary wishes to train a new model with significantly more parameters than the current frontier (e.g. 10x), this is immediately problematic because training using ordinary centralized training methods also typically require more bytes of high-bandwidth memory (HBM) than inference by approximately 6-10x. Since the pods are sized for inference on a smaller model, an adversary trying to train a new frontier model 10x would fail to fit a full copy of model state on a single pod by a factor of about 60x (one pod has about 1/60th of the HBM required to store a full copy of model state).
Random Routing Deters Pipeline Parallel Training
There are some “pipeline parallel” training techniques like SWARM, which explicitly remove the constraint that all model state must fit on a single node by separating the model into “stages” (sections) of layers and storing just one stage per node.
These techniques nevertheless depend on stable communication between successive pipeline stages: the pod holding one stage must be able to send its activations to the specific pod holding the next stage. However our design’s randomized load balancer deliberately prevents this stage-to-stage affinity. Because requests are routed to pods at random and pods cannot communicate directly, an adversary could not reliably deliver each intermediate result to its intended destination without repeatedly retransmitting it, accepting substantial idle time, or otherwise incurring a large routing penalty.
Replicating every pipeline stage across every pod would avoid the routing problem, but would reintroduce the memory constraint that pipeline parallelism is intended to solve. Thus, random routing creates an additional barrier that is largely independent of the bandwidth cap. Appendix A analyzes this constraint in the context of SWARM-style training and provides a more detailed estimate of its effect on training efficiency.
Tradeoffs Versus Network Taps With Recomputation
Network taps with recomputation if implemented correctly, can offer stronger guarantees that training is not taking place in a compute facility than the design presented here. However, while traffic shaping offers weaker guarantees around workload classification – particularly for training utilizing an entirely new methodology or for models sizes smaller than the current frontier – our approach also offers significant advantages over recomputation, especially in cases where rapid deployment is required. Specifically, traffic shaping:
Relies only on mature technologies and standard, well understood networking components.
Avoids having to address recompute difficulties related to GPU nondeterminism.
Avoids the requirement for model developers to redesign their models and harnesses to remove internal sources of non-determinism and asynchronicity that can result in recomputation failures.
Does not require verifier access to model weights or unencrypted inference data.
Avoids the requirement to build and deploy recomputation pods, as well as capex costs of assigning GPUs and other hardware to the pods.
Most critically, traffic shaping avoids the requirement to develop a security and access regime that would enable auditors and labs to mutually trust that the recomputation pods are able to maintain the integrity of the recompute, the security of model weights and privacy of end-user data.
The above represents substantial technical complexity and deployment risk, especially at global scale and considering potential state actor adversaries. By contrast a traffic shaping solution consists of a more straightforward and technically and operationally simpler deployment requirements, which we discuss in the next section.
Deployment Requirements
1. Introduce Data Center Physical Security
Establish physical security of network components and GPU machines, most likely utilizing a combination of cameras and spot inspections by human auditors.
2. Group GPU Machines Into Pods and Add Network Taps and Randomized Inference Routers
Install standard network hardware to group inference machines into pods, throttle north-south network traffic using standard network taps or shapers and install randomized inference routers. Enforce request/responses to pods only through routers. While this step does introduce hardware manufacturer supply chain risk, we believe that the complexity is likely to be manageable even for state actors, based on the fact that commodity hardware can be used, the required operations are relatively simple and there is not a requirement to capture or analyze data (including encrypted data) except for total throughput. In some cases (e.g. network taps / shapers) network devices could even be installed in series if blue and red teams each want to have one full copy of a device that they manufacture to ensure that requirements are enforced.
3. Pods Must Become Pure Inference Appliances
This is the most burdensome requirement for model developers. Each pod must become a pure inference appliance. Its only application-level interface should be the approved inference request/response channel. The actual web search, API request, browser operation or code execution should originate outside the pod. The pod should emit a bounded, structured tool intent as part of its ordinary encrypted model output. An agent harness outside the pod executes the web search or other tool, then submits the result as a new inference request through the existing randomizing load balancer. The actual Internet connection never originates inside the pod.
A full analysis of the impact of this requirement on model developers is beyond the scope of this design brief, but initial analysis suggests that compliance is possible for model developers with modest reengineering of inference-serving architectures. It is relatively low-friction for serving-native workloads such as text generation, embeddings, classification, reranking, and many LoRA-at-inference patterns, especially when teams already deploy through hardened serving stacks like Triton, vLLM, KServe, ONNX Runtime, or TEI/TGI. It becomes much more disruptive for workflows that rely on interactive debugging, ad hoc package installation, direct data-store access, in-pod tool execution, full training or fine-tuning, session-affine state, or research-grade custom kernels and Python control flow. Many of these are not impossible under the design, but they move from “inside the model pod” to an external harness, session service, registry, or staging environment.
Conclusion
Traffic Shaping for Workload Classification is a verification design which, while still at the design stage and not yet implemented or red-teamed, current analysis suggests has the potential to offer regulators, model developers and treaty partners an effective, rapidly-deployable deterrent in optionality scenarios, with significantly less technical complexity and operational uncertainty than other proposed workload classification solutions like recomputation. The Lucid Computing engineering team is currently working to develop a proof of concept implementation of Traffic Shaping for red-teaming in an adversarial testbed at one of our partner clusters over the coming months.
Appendix A: Empirical Analysis of Defensible Conservative Cost-Inefficiency Bounds for Adversarial Training Using Pods With This Design Deployed
The following is an empirical analysis of estimated conservative inefficiency multiplier lower-bounds generated by a Claude/Fable Deep Research analysis.
A.1 Purpose and Method
This appendix models the inefficiency multiple an adversarial data center operator would face if it attempted to pre-train a new frontier model using only GPUs located in inference pods configured as described in the main body of this design brief. We define the inefficiency multiple I as the ratio of total GPU-hours required to complete a fixed training run (same model, same token count) under the constraints of this design versus on the same hardware operating without constraints. Equivalently, I is the wall-clock slowdown at a fixed pod count, or the pod-count multiple at fixed wall-clock time.
Every estimate in this appendix is constructed as a lower bound under adversary-favorable assumptions: wherever a modeling choice is ambiguous, we resolve it in the direction that helps the adversary. We grant the adversary perfect overlap of communication and computation, zero pipeline bubbles, zero straggler and fault overhead, free coordination compute outside the pods, aggressive low-precision training recipes, and the best published communication-reduction techniques. The resulting figures should therefore be read as floors on the penalty, not predictions of realized performance. These are engineering estimates, not proofs; Section A.10 discusses residual risks and the assumptions that matter most.
Three adversary strategies are analyzed, per the structure of the main text:
Case 1: The most straightforward adaptation of ordinary centralized training (fully sharded data parallelism, and tensor/pipeline/data 3-D parallelism as used in Megatron-style systems).
Case 2: Low-communication data-parallel methods of the DiLoCo family, including streaming and quantized variants.
Case 3: Fully decentralized pipeline-parallel methods of the SWARM family, which do not require any node to hold a full model replica.
A.2 Reference Pod, Models, and Notation
The pod is modeled as one NVIDIA GB200 NVL72 rack, the reference configuration named in the main text. Specifications are taken from NVIDIA’s published datasheet [1].
The 40% MFU assumption matches the best publicly documented sustained utilization for large runs: the Llama 3 405B run reports 38–43% MFU [11] and INTELLECT-1 reports 36–41% [5]. The 8 B/param training-state figure is an aggressive FP8-era recipe in the spirit of DeepSeek-V3’s FP8 mixed-precision framework [10]; the conventional figure of ~16 B/param for mixed-precision Adam training follows the accounting in the ZeRO paper [7]. We use the aggressive 480 TB figure throughout, which favors the adversary.
Consistency check on pod sizing. M_inf at FP8 occupies 6 TB of weights, fitting comfortably in one pod’s 13.5 TB of HBM with ~7 TB of headroom for KV cache and activations. This confirms the main text’s premise that a single NVL72 rack is a natural, efficient serving pod for a Fable-sized model, with no need for cross-pod traffic during inference beyond request/response.
Memory shortfall check. A full training-state replica of M_adv requires Σ/m_HBM ≈ 36 pods (aggressive recipe) to 71 pods (conventional recipe) worth of HBM. This bracket is consistent with the “~60x” figure quoted in the main text; we suggest the main text cite the 36–71x range for precision.
A.3 Sizing the Uplink Cap from Maximum-Throughput Inference
The cap β must comfortably accommodate a pod serving M_inf at full utilization. External inference traffic is bounded by the pod’s compute, because every ingress byte that matters must be prefetched (prefilled) and every egress byte must be decoded:
Prefill (ingress-bounding). At 50% inference MFU on FP8 (360 PFLOP/s) and 2 × 400B = 8×10¹¹ FLOPs per prefilled token, the pod prefills at most ≈ 450,000 tokens/s. Note this already accounts for the design’s randomized routing forcing full-context resends on every request (no session affinity): resent context is simply more prefill, and prefill capacity is the binding constraint.
Decode (egress-bounding). Decode is HBM-bandwidth-bound. With FP8 weights (~6 TB read per batched forward step at high concurrency, when essentially all experts are activated) plus KV traffic, the pod sustains on the order of 90 forward steps/s; at ~1,000+ concurrent sequences this yields ≈ 100,000 output tokens/s.
Converting to bytes: text averages ~4 bytes/token. Maximum text ingress is therefore ≈ 1.8 MB/s raw, or ≈ 5–6 MB/s with a generous 3x allowance for TLS, HTTP, JSON framing, and retries. Vision-heavy workloads are the worst case for ingress, at roughly 50–150 bytes per consumed token; a mix that saturates prefill with image-heavy requests reaches ≈ 30–60 MB/s. Egress is ≈ 1–2 MB/s for text, rising to ≈ 10 MB/s for embedding-heavy workloads returning dense vectors. Structured tool-intent outputs (per the pure-inference-appliance requirement) are negligible at these scales.
Recommended cap: β = 1 Gbps (125 MB/s) per direction per pod, averaged over 60 seconds — equivalent to ≈ 14 Mbps per GPU. This provides at least 2x headroom over the worst-case legitimate mix modeled above, so the cap should be operationally invisible to a compliant operator. All inefficiency results below scale inversely with β: if a deployment chose a 10 Gbps cap, every multiple in this appendix would be divided by 10, which is why we recommend the cap be set from a workload model like the one above rather than from generic provisioning habits.
A.4 Unconstrained Training Baseline
Unconstrained, one pod training M_adv processes:
τ₀ = R_pod / C_t = 2.88×10¹⁷ / 2.4×10¹³ = 12,000 tokens/s per pod.
For scale, consider a reference frontier run of 40T tokens, i.e. ≈ 1×10²⁷ FLOPs. Unconstrained, this is ≈ 3.5×10⁹ pod-seconds ≈ 110 pod-years ≈ 69 million GPU-hours — e.g., ~440 pods (≈ 32,000 GPUs) for three months. The inefficiency multiples below should be read against this baseline.
A.5 The Delivery Bound Under Randomized Routing
The design’s randomizing load balancer imposes a structural penalty on any pod-to-pod communication, and it is worth deriving this penalty once, since all three cases reduce to it.
Setting. Pods can only receive traffic proxied by the router, which selects a destination uniformly at random among the N ≥ 100 pods in its cell; a request to reach one specific pod succeeds with probability 1/N ≤ 1/100. Egress is not randomized in the same way — a pod’s response returns to whichever external harness sent the request — so the adversary’s harness can collect from pods efficiently, but delivering a payload into the correct pod requires repeated random attempts.
Delivery lemma (heuristic). If a payload of s bytes is useful only to a fraction f of the pods in the cell (e.g., the pods holding a particular pipeline stage), then any delivery scheme consumes at least s/f bytes of the cell’s aggregate ingress in expectation per useful delivery. Retransmission until a hit costs exactly this. Bundling payloads for all stages into every request, broadcasting, erasure coding, and multi-hop relaying (which faces the same memoryless routing at every hop) all pay the same expected cost or worse, because the router delivers information to the target set at rate f times the ingress spent. Misrouted bytes are not merely wasted by the sender — they consume the receiving pod’s capped ingress, so the penalty binds at the cell level.
Memory-placement invariant. How large can f be? If the adversary’s model has training state Σ divided into S pipeline stages replicated across the cell, each pod can hold m/(Σ/S) stages, so the number of pods holding any given stage is k = N·m/Σ regardless of S, giving:
f = m/Σ — i.e., f ≈ 13.5/480 ≈ 1/36 with HBM only, or 30.5/480 ≈ 1/16 granting full use of Grace LPDDR5X as training-state memory (offload traffic over the 900 GB/s NVLink-C2C links is fast enough that we grant it as free).
The minimum viable stage count is S_min = ⌈Σ/m⌉ = 36 (HBM only) or 16 (with LPDDR offload), since each stage must fit on one pod.
Core formula. In pipeline training, each token requires 2(S−1) boundary crossings (forward activations plus backward activation-gradients), each carrying b_eff bytes (b = 2d bytes ≈ 32 KB at BF16 with d = 16,384, divided by any compression factor). Combining with the lemma, per-pod constrained throughput is β·f / (2(S−1)·b_eff), and:
I ≥ τ₀ · 2(S−1) · b_eff / (f · β)
This formula, with the parameter table in §A.2, generates all headline numbers below and can be re-run with updated parameters as hardware and model architectures evolve.
A.6 Case 1 — Direct Adaptation of Centralized Training
Case 1a: Fully sharded data parallelism (ZeRO-3 / FSDP [7]). Sharded approaches stream parameters to every worker each step: each pod must ingest ≈ 2Σ_weights ≈ 120 TB per optimizer step (forward and backward all-gathers of FP8 weights). At β this takes ≈ 9.6×10⁵ seconds per step. Compute per step for a generous per-replica batch of 4M tokens across 36 pods is ≈ 9.3 seconds. Slowdown ≈ 10⁵ before any routing penalty, and 10⁵–10⁶ with it. This family is simply non-viable across capped links, which is consistent with why frameworks like PRIME confine FSDP to intra-node fabric [5].
Case 1b: 3-D parallelism (tensor within pod, pipeline across pods, data parallel across replicas [8]). This keeps weights resident and is the strongest conventional adaptation. Two cross-pod flows remain:
Pipeline activations: by the formula in A.5 with f = 1 (imagining, counterfactually, that routing could be fully defeated), S = 36 and BF16 activations give I ≈ 220x from the bandwidth cap alone.
Gradient synchronization: per-step data parallelism must move ≈ 2 × 60 TB of FP8 gradients across each 36-pod replica’s uplinks per step ≈ 3.3 TB per pod per step ≈ 26,700 s at β, versus ≈ 9.3 s of compute at a 4M-token per-replica batch — a ≈ 2,900x penalty on its own. Larger batches amortize this but run into well-documented critical-batch-size limits on optimization efficiency [9]; 4M tokens per replica per step is already generous relative to published frontier practice.
Combined, and then multiplied by the routing penalty (×16–36) on both flows, the most straightforward adaptation of centralized training lands at ≈ 10⁴–10⁵, with ≥ 10³ as a highly conservative floor. This supports the main text’s claim of “likely 1000x or more” for adaptations of standard centralized strategies. An adversary’s obvious next moves — synchronize gradients rarely, or abandon full replicas — are precisely Cases 2 and 3.
A.7 Case 2 — DiLoCo-Family Low-Communication Training
DiLoCo [2] and its descendants (Streaming DiLoCo [3], OpenDiLoCo [4], and the INTELLECT-1 production run [5]) dramatically reduce inter-node synchronization: workers take H = 100–500 local steps between outer synchronizations, and pseudo-gradients compress well (int8 in INTELLECT-1, with a reported ~400x reduction in data-parallel communication [5]; further overlap and 4-bit outer communication in Streaming DiLoCo [3]).
The decisive limitation in our setting is the family’s core assumption: each worker holds a full model replica and optimizer state. For M_adv this is 480–960 TB — a single “DiLoCo node” must span 16–36 pods (§A.2), and because pods cannot address one another directly, all intra-node traffic (the inner training loop itself) must cross capped, randomly-routed uplinks. DiLoCo optimizes exactly the term that was already smallest and leaves the dominant term untouched:
Outer synchronization (granted essentially free): even at H = 100 with int8 pseudo-gradients, this adds only ~2 MB per token before routing — negligible next to the inner loop, so we drop it in the adversary’s favor.
Inner loop: the node’s only viable internal organization across pods is a pipeline, which is the delivery bound of §A.5. With LPDDR offload (S = 16, f = 1/16) and BF16 activations: I ≈ 1,500x; granting 4x activation compression: I ≈ 370x. Without offload (S = 36, f = 1/36): I ≈ 7,800x, or ≈ 1,960x with 4x compression.
Case 2 conservative floor: ≥ ~350–400x, with central estimates of 1,500–8,000x. The published evidence base is also worth noting: the largest public DiLoCo-style runs are ~10B parameters with each node comfortably holding the full model [5] — four orders of magnitude below M_adv’s state footprint per node.
A.8 Case 3 — SWARM-Style Pipeline Parallelism
SWARM parallelism [6] removes the full-replica assumption: nodes hold single stages, pipelines are stochastically wired among correct next-stage peers, and rebalancing handles faults. It is the best-known published fit for the pod-constrained setting and was demonstrated training a 1B-shared-parameter model on preemptible T4s with under 200 Mb/s links [6].
Two observations govern its performance here. First, SWARM’s stochasticity is chosen from the set of valid next-stage nodes; the design’s router substitutes uniform randomness over all pods, which is strictly worse for the adversary and is exactly the delivery-lemma setting. Second, SWARM’s stage-replica averaging is a mild DP term we grant as free (it can be DiLoCo-ified). The bound is therefore the same core formula, and we also grant: zero pipeline bubbles, zero fault overhead, free external orchestration, and AQ-SGD-style activation compression [12] — noting that AQ-SGD’s 2–4-bit results are for fine-tuning at ≤ 1.5B parameters, and comparable compression for from-scratch frontier pretraining is unproven.
noting that AQ-SGD’s 2–4-bit results are for fine-tuning at ≤ 1.5B parameters, and comparable compression for from-scratch frontier pretraining is unproven.Case 3 conservative floor: ≥ ~350x under every simultaneously-granted charitable assumption we consider defensible, degrading to ≈ 140x only if two additional unproven techniques (8x lossless-for-quality activation compression at frontier scale, and an unusually narrow architecture for a 60T-parameter model) both succeed. Cases 2 and 3 converge on the same bound because both reduce to delivering activations into specific stage-holders through a memoryless random router.
A.9 Summary of Bounds and Economic Feasibility
Headline claim supported: I ≥ 100x, with roughly 1.4–3.5x of margin remaining even after stacking every charitable and speculative assumption simultaneously, and with central estimates one to two orders of magnitude higher. This is consistent with, and slightly strengthens, the main text’s framing (≥ 100x even for decentralized strategies; ≥ 1,000x for centralized adaptations).
In concrete terms, against the ≈ 1×10²⁷-FLOP reference run of §A.4 (110 pod-years; 69M GPU-hours unconstrained):
At the conservative decentralized floor (≈ 370x): ≈ 41,000 pod-years ≈ 26 billion GPU-hours. A covert fleet of 10,000 pods (720,000 GPUs) — several times larger than today’s largest disclosed single-model training clusters — would need ≈ 4 years. At an illustrative $2–4 per GPU-hour of opportunity cost, this is a $50–100B diversion for one training run.
At central estimates (≥ 1,500x): ≥ 165,000 pod-years — decisively infeasible in the short-to-medium term for any actor.
Even at the speculative extreme (≈ 140x): ≈ 15,000 pod-years, i.e. 10,000 pods for ~1.5 years, a diversion of a scale that is very difficult to conceal and that presumes multiple frontier research breakthroughs by the adversary succeed simultaneously and silently.
A.10 Adversary Countermeasures Considered, Residual Risks, and Design Recommendations
Countermeasures already priced into the bounds. Payload bundling, broadcast, erasure coding, and multi-hop relaying (delivery lemma, §A.5); activation compression up to 4–8x [12]; LPDDR offload of optimizer state; infrequent and quantized outer synchronization [2, 3, 5]; unbounded external harness compute; perfect overlap; zero fault/bubble overhead; batch scaling to generous per-replica sizes [9].
Residual risk 1 — Stage-clustered routing cells (most important). The routing penalty assumes the adversary cannot control which pods sit behind which router. If the operator may freely assign pods to routers, it could dedicate an entire ≥100-pod cell to a single pipeline stage; uniform routing within a homogeneous cell is then harmless (f → 1), and the bound collapses to the cap-only pipeline term: ≈ 90–220x uncompressed and as low as ≈ 25x with compression. Design Recommendation A-1: the assignment of pods to routers must be randomized under auditor control and periodically re-randomized. Because a pod’s resident training-state shard is 14–30 TB, re-homogenizing cells after a reshuffle would require migrating that state through capped 125 MB/s uplinks (≈ 30–70 hours per pod per reshuffle), so even weekly re-randomization imposes a large standing tax on any attempt to defeat the routing penalty. With A-1 in place, stage placement is uniform in expectation and f = m/Σ as modeled.
Residual risk 2 — Local storage expansion. The invariant f = m/Σ improves for the adversary as per-pod memory m grows. Undeclared NVMe could raise m substantially (partially offset by offload thrash: streaming tens of TB of optimizer state per step through PCIe/NVMe stalls compute). Design Recommendation A-2: per-pod local storage must be declared, capped, and included in the physical inspection regime, and the deployed cap β should be set with the declared m in mind.
Residual risk 3 — Algorithmic innovation. The bounds are only as durable as the assumption that pre-training a monolithic 60T-parameter model requires moving ~2d bytes per token per stage boundary. Research directions that could erode the margin include extreme activation compression validated at pretraining scale, architectures with unusually small inter-layer widths relative to parameter count, and modular/federated paradigms that compose many pod-sized models (e.g., distillation federations); no published method in the last category currently matches monolithic frontier pretraining quality [13], but this should be treated as a standing watch item, consistent with this design’s positioning as a short-to-medium-term deterrent and Phase-1 milestone.
Residual risk 4 — What this design does not claim. These bounds concern pre-training models strictly larger than the frontier the pods are sized for. Training models that fit within a single pod (≤ M_inf scale), fine-tuning, and RL post-training within one pod are outside the modeled threat and are the natural target of the Phase-2 recomputation design; the router and cap still deny such runs any efficient multi-pod scale-out.
Sensitivity. All results scale linearly in 1/β (double the cap, halve the multiple), linearly in b_eff (i.e., in the hidden dimension d and compression), and via f = m/Σ in the ratio of pod memory to adversary-model training state (a 10x-frontier target gives Σ/m ≈ 16–36; a merely 2x-frontier target would shrink the routing penalty roughly proportionally and should be re-run through §A.5’s formula). Parties adopting this design should re-derive β and the bounds from the then-current pod hardware, frontier model architecture, and declared storage, using the formulas in §A.5.
Douillard, A., et al. DiLoCo: Distributed Low-Communication Training of Language Models. arXiv:2311.08105. https://arxiv.org/abs/2311.08105
Douillard, A., et al. Streaming DiLoCo with Overlapping Communication: Towards a Distributed Free Lunch. arXiv:2501.18512. https://arxiv.org/abs/2501.18512
Jaghouar, S., et al. OpenDiLoCo: An Open-Source Framework for Globally Distributed Low-Communication Training. arXiv:2407.07852. https://arxiv.org/abs/2407.07852
Ryabinin, M., Dettmers, T., Diskin, M., Borzunov, A. SWARM Parallelism: Training Large Models Can Be Surprisingly Communication-Efficient. ICML 2023. arXiv:2301.11913. https://arxiv.org/abs/2301.11913
Rajbhandari, S., et al. ZeRO: Memory Optimizations Toward Training Trillion Parameter Models. arXiv:1910.02054. https://arxiv.org/abs/1910.02054
Shoeybi, M., et al. Megatron-LM: Training Multi-Billion Parameter Language Models Using Model Parallelism. arXiv:1909.08053. https://arxiv.org/abs/1909.08053
McCandlish, S., Kaplan, J., Amodei, D., et al. An Empirical Model of Large-Batch Training. arXiv:1812.06162. https://arxiv.org/abs/1812.06162
Wang, J., Yuan, B., et al. Fine-tuning Language Models over Slow Networks using Activation Quantization with Guarantees (AQ-SGD). NeurIPS 2022. arXiv:2206.01299. https://arxiv.org/abs/2206.01299
Wasil, A., Reed, T., Miller, J.W., Barnett, P. Verification Methods for International AI Agreements. arXiv:2408.16074. https://arxiv.org/abs/2408.16074
When we say “frontier training” or sometimes “training” in this document, we are specifically discussing training of LLMs that are strictly larger than models for which we currently wish compute facilities to be allowed to serve inference requests for. Traffic Shaping as a design works in such a way that the strength of the deterrent to new training increases as the size of the model an adversary is trying to train increases relative to the current allowed inference size.
This design requires a number of new network devices to be introduced into the compute facility. Given that the verifier will require a high-level of trust in these devices and the facility owner (prover) will likely have a high level of concern about security and data privacy risks from these devices, we imagine that the devices will be designed and manufactured through a co-design process involving both parties, possibly mediated by one or more independent third-party organizations. To achieve a high-level of mutual trust, this process may include utilizing existing commodity hardware, redundant components from multiple suppliers and components based on open source and open standards.
Introducing random routing is likely to have a performance impact on the compute resource, particularly under high-load. To mitigate this, additional design elements may be introduced. For example a mechanism that enables a pod to request that the router remove it from the pool of pods receiving new requests for some period (e.g. 10 seconds) in order to reduce load on that pod. Limits would need to be imposed on how many pods could utilize this mechanism at one time to prevent exploitation by an adversary attempting to efficiently route messages for training. More research is needed on the performance impact of random routing on inference and mitigations.
Note: this is a repost of a verification design I developed working as a consultant with the team at Lucid Computing and originally posted on the Lucid Labs Substack.
Overview
In this design brief we present “Traffic Shaping for Workload Classification” – a verification solution that enables a third party to verify that frontier training[1] is either not occurring in a declared compute facility, or is occurring, but at a cost multiple that would render a frontier training run of a new model that is 10x or more the size of current frontier models economically infeasible. Our design builds on existing traffic restriction and compartmentalization designs, which require reorganizing compute into size-restricted “pods” and introducing traffic shapers to throttle the external network traffic to the pod to a threshold per GPU which is sufficient for inference, but insufficient for frontier training. Additionally, our design requires the introduction of a “random router” for inference requests, which ensures that inference requests are routed randomly to pods. This adds resistance to decentralized training techniques like pipeline parallelism.
Unlike network tap designs with recomputation, our design does not require analysis of the network traffic or recomputation of output results. Instead, the design introduces a number of network-based constraints on AI data centers, which together make training a new model that is larger than the current frontier model size extremely inefficient. While the exact level of cost inefficiency the design imposes on an adversarial training run will vary depending on the exact model size and architecture the adversary chooses, our analysis suggests that these inefficiencies would likely serve as a substantial deterrent to state actors or individual labs defecting from a treaty or regulatory regime and attempting to train new frontier models that are significantly larger than the current frontier.
For example, based on an analysis of today’s best-known inference and training architectures (see Appendix A below for details) we estimate that retrofitting data centers with a Traffic Shaping solution could enforce an inefficiency multiplier (lower-bound) of approximately 350x on adversaries attempting to covertly train a new frontier model that is approximately 10x the size of the current frontier (60T parameters). By this we mean that at least 350x more GPUs would be required for training a model in the same amount of clock time, or 350x the time would be required with the same number of GPUs, versus a comparable cluster operating without the bandwidth constraints enforced. Central estimates of the inefficiency factor are closer to 1000x - 10,000x range depending on the adversary’s choice of training architecture.
Overall, Traffic Shaping offers a workload classification solution that is rapidly deployable today, based on mature technologies and which has significantly lower up-front technical deployment complexity and less security concerns for key stakeholders than alternative designs like full recomputation. Given these characteristics, Traffic Shaping appears to be a very attractive candidate solution to verify that new models larger than the current frontier are not being trained covertly in declared data centers during a coordinated slowdown.
Solution Specification
Our verification solution requires several modifications to the network topology[2] of a cluster:
1) Pod Size and Resource Restrictions
Data centers complying with this design must group all machines into inference “pods” such that each pod is restricted to the minimum arrangement of machines and resources required to service inference requests for models with a fixed maximum size, with reasonable efficiency, but no more than that. When we consider “resources” here, we especially consider external (uplink) network bandwidth, HBM and fast memory and fast storage. For example, for serving a Fable-sized model (estimated 6T parameter MoE) we might model a pod as a rack with 72 GPU GB200s, 13.5TB of HBM3, 30.5TB of fast memory and 4TB of fast storage (see Appendix A for more details). An example network topology for a data center with this verification design deployed is illustrated below.
Figure 1: Inference Data Center Network Topology With the Solution Deployed
2) Network Monitoring / Throttling
As shown in Figure 1, a network shaper must be installed at the “north-south uplink” point at the boundary of each pod. The objective of this tap is to restrict network traffic, averaged over each time interval (e.g. 1 minute, or hour) to a quantity that is sufficient for serving inference but insufficient for enabling pods to efficiently contribute to training runs.
3) Load Balancer / Router Which Randomly Assigns Inference Requests to Pods
The load balancers / routers used for routing inference requests to pods must be replaced by new versions of these network components so that the following constraints are satisfied:
The purpose of this component is to make it far more difficult for adversaries to utilize decentralized training techniques based on pipeline parallelism or similar, by making it far more difficult for pods to communicate with each other in decentralized training strategies that would attempt to utilize pods as nodes.
4) Physical Security
All machines and networking components related to the pod and inference load balancers must be physically secured. GPU machines must also be internally inspected at least initially to ensure that they do not contain additional networking components beyond those that have been declared, particularly wireless network components. The networking infrastructure must also be physically secured. We believe that the best way to physically secure the cluster is through a combination of cameras, custom-designed physical server enclosures, random spot inspections and countermeasures against wireless networking. However a complete analysis of the physical security required to support a real-world deployment of this design is beyond the scope of this document.
Why Pre-Training New Frontier Models Under Traffic Shaping Restrictions is Difficult
The goal of our design is to ensure that pre-training a new frontier LLM using only GPUs located in pods is economically infeasible. Our design is primarily concerned with preventing pre-training of new models that are strictly larger than the current frontier. While it is impossible to perfectly model the inefficiency multiple an adversary would face, we can explain from an engineering standpoint why a pod-constrained training run would be much more difficult than an ordinary training run. And we can also produce estimates of real world inefficiency factors by analytically modeling the most likely training approaches adversaries would consider when constrained by this design. An example of such an exercise is presented in Appendix A and suggests that conservative lower-bound inefficiency multiples are likely to be at least 350x, even for decentralized training strategies and are likely 1000x or more for adaptations of standard centralized training strategies. This is due to the following high-level difficulties our design presents for an adversary attempting to train a new frontier model utilizing GPUs in pods:
Network Bandwidth Bottlenecks Performance
Inference produces relatively small volumes of external traffic, while training requires frequent movement of gradients, model state, and intermediate activations among the machines participating in the run. By limiting each pod’s external bandwidth to a level that comfortably supports inference, the design turns any communication that must cross pod boundaries into a severe performance bottleneck. Standard centralized training would be particularly affected because gradient synchronization and model-parallel communication occur repeatedly throughout training.
Low-communication techniques can reduce some forms of data-parallel synchronization, but they do not eliminate the inner-loop communication required when a model must be distributed across multiple pods. In particular, pipeline activations and mixture-of-experts routing traffic would still have to traverse the restricted uplinks. Appendix A evaluates several representative training strategies and provides quantitative estimates of the resulting inefficiency.
Pods Can’t Hold a Full Model Copy for Frontier Training
An additional difficulty for any adversarial data center operator attempting to train a new frontier model using pods is that the majority of training techniques – even many decentralized training techniques like Distributed Low-Communication Training (DiLoCo) – assume that each “node” (a collection of fast-network-connected computers contributing to training) can at least hold at least a full copy of the model. So if an adversary wishes to train a new model with significantly more parameters than the current frontier (e.g. 10x), this is immediately problematic because training using ordinary centralized training methods also typically require more bytes of high-bandwidth memory (HBM) than inference by approximately 6-10x. Since the pods are sized for inference on a smaller model, an adversary trying to train a new frontier model 10x would fail to fit a full copy of model state on a single pod by a factor of about 60x (one pod has about 1/60th of the HBM required to store a full copy of model state).
Random Routing Deters Pipeline Parallel Training
There are some “pipeline parallel” training techniques like SWARM, which explicitly remove the constraint that all model state must fit on a single node by separating the model into “stages” (sections) of layers and storing just one stage per node.
These techniques nevertheless depend on stable communication between successive pipeline stages: the pod holding one stage must be able to send its activations to the specific pod holding the next stage. However our design’s randomized load balancer deliberately prevents this stage-to-stage affinity. Because requests are routed to pods at random and pods cannot communicate directly, an adversary could not reliably deliver each intermediate result to its intended destination without repeatedly retransmitting it, accepting substantial idle time, or otherwise incurring a large routing penalty.
Replicating every pipeline stage across every pod would avoid the routing problem, but would reintroduce the memory constraint that pipeline parallelism is intended to solve. Thus, random routing creates an additional barrier that is largely independent of the bandwidth cap. Appendix A analyzes this constraint in the context of SWARM-style training and provides a more detailed estimate of its effect on training efficiency.
Tradeoffs Versus Network Taps With Recomputation
Network taps with recomputation if implemented correctly, can offer stronger guarantees that training is not taking place in a compute facility than the design presented here. However, while traffic shaping offers weaker guarantees around workload classification – particularly for training utilizing an entirely new methodology or for models sizes smaller than the current frontier – our approach also offers significant advantages over recomputation, especially in cases where rapid deployment is required. Specifically, traffic shaping:
The above represents substantial technical complexity and deployment risk, especially at global scale and considering potential state actor adversaries. By contrast a traffic shaping solution consists of a more straightforward and technically and operationally simpler deployment requirements, which we discuss in the next section.
Deployment Requirements
1. Introduce Data Center Physical Security
Establish physical security of network components and GPU machines, most likely utilizing a combination of cameras and spot inspections by human auditors.
2. Group GPU Machines Into Pods and Add Network Taps and Randomized Inference Routers
Install standard network hardware to group inference machines into pods, throttle north-south network traffic using standard network taps or shapers and install randomized inference routers. Enforce request/responses to pods only through routers. While this step does introduce hardware manufacturer supply chain risk, we believe that the complexity is likely to be manageable even for state actors, based on the fact that commodity hardware can be used, the required operations are relatively simple and there is not a requirement to capture or analyze data (including encrypted data) except for total throughput. In some cases (e.g. network taps / shapers) network devices could even be installed in series if blue and red teams each want to have one full copy of a device that they manufacture to ensure that requirements are enforced.
3. Pods Must Become Pure Inference Appliances
This is the most burdensome requirement for model developers. Each pod must become a pure inference appliance. Its only application-level interface should be the approved inference request/response channel. The actual web search, API request, browser operation or code execution should originate outside the pod. The pod should emit a bounded, structured tool intent as part of its ordinary encrypted model output. An agent harness outside the pod executes the web search or other tool, then submits the result as a new inference request through the existing randomizing load balancer. The actual Internet connection never originates inside the pod.
A full analysis of the impact of this requirement on model developers is beyond the scope of this design brief, but initial analysis suggests that compliance is possible for model developers with modest reengineering of inference-serving architectures. It is relatively low-friction for serving-native workloads such as text generation, embeddings, classification, reranking, and many LoRA-at-inference patterns, especially when teams already deploy through hardened serving stacks like Triton, vLLM, KServe, ONNX Runtime, or TEI/TGI. It becomes much more disruptive for workflows that rely on interactive debugging, ad hoc package installation, direct data-store access, in-pod tool execution, full training or fine-tuning, session-affine state, or research-grade custom kernels and Python control flow. Many of these are not impossible under the design, but they move from “inside the model pod” to an external harness, session service, registry, or staging environment.
Conclusion
Traffic Shaping for Workload Classification is a verification design which, while still at the design stage and not yet implemented or red-teamed, current analysis suggests has the potential to offer regulators, model developers and treaty partners an effective, rapidly-deployable deterrent in optionality scenarios, with significantly less technical complexity and operational uncertainty than other proposed workload classification solutions like recomputation. The Lucid Computing engineering team is currently working to develop a proof of concept implementation of Traffic Shaping for red-teaming in an adversarial testbed at one of our partner clusters over the coming months.
Appendix A: Empirical Analysis of Defensible Conservative Cost-Inefficiency Bounds for Adversarial Training Using Pods With This Design Deployed
The following is an empirical analysis of estimated conservative inefficiency multiplier lower-bounds generated by a Claude/Fable Deep Research analysis.
A.1 Purpose and Method
This appendix models the inefficiency multiple an adversarial data center operator would face if it attempted to pre-train a new frontier model using only GPUs located in inference pods configured as described in the main body of this design brief. We define the inefficiency multiple I as the ratio of total GPU-hours required to complete a fixed training run (same model, same token count) under the constraints of this design versus on the same hardware operating without constraints. Equivalently, I is the wall-clock slowdown at a fixed pod count, or the pod-count multiple at fixed wall-clock time.
Every estimate in this appendix is constructed as a lower bound under adversary-favorable assumptions: wherever a modeling choice is ambiguous, we resolve it in the direction that helps the adversary. We grant the adversary perfect overlap of communication and computation, zero pipeline bubbles, zero straggler and fault overhead, free coordination compute outside the pods, aggressive low-precision training recipes, and the best published communication-reduction techniques. The resulting figures should therefore be read as floors on the penalty, not predictions of realized performance. These are engineering estimates, not proofs; Section A.10 discusses residual risks and the assumptions that matter most.
Three adversary strategies are analyzed, per the structure of the main text:
A.2 Reference Pod, Models, and Notation
The pod is modeled as one NVIDIA GB200 NVL72 rack, the reference configuration named in the main text. Specifications are taken from NVIDIA’s published datasheet [1].
The 40% MFU assumption matches the best publicly documented sustained utilization for large runs: the Llama 3 405B run reports 38–43% MFU [11] and INTELLECT-1 reports 36–41% [5]. The 8 B/param training-state figure is an aggressive FP8-era recipe in the spirit of DeepSeek-V3’s FP8 mixed-precision framework [10]; the conventional figure of ~16 B/param for mixed-precision Adam training follows the accounting in the ZeRO paper [7]. We use the aggressive 480 TB figure throughout, which favors the adversary.
Consistency check on pod sizing. M_inf at FP8 occupies 6 TB of weights, fitting comfortably in one pod’s 13.5 TB of HBM with ~7 TB of headroom for KV cache and activations. This confirms the main text’s premise that a single NVL72 rack is a natural, efficient serving pod for a Fable-sized model, with no need for cross-pod traffic during inference beyond request/response.
Memory shortfall check. A full training-state replica of M_adv requires Σ/m_HBM ≈ 36 pods (aggressive recipe) to 71 pods (conventional recipe) worth of HBM. This bracket is consistent with the “~60x” figure quoted in the main text; we suggest the main text cite the 36–71x range for precision.
A.3 Sizing the Uplink Cap from Maximum-Throughput Inference
The cap β must comfortably accommodate a pod serving M_inf at full utilization. External inference traffic is bounded by the pod’s compute, because every ingress byte that matters must be prefetched (prefilled) and every egress byte must be decoded:
Converting to bytes: text averages ~4 bytes/token. Maximum text ingress is therefore ≈ 1.8 MB/s raw, or ≈ 5–6 MB/s with a generous 3x allowance for TLS, HTTP, JSON framing, and retries. Vision-heavy workloads are the worst case for ingress, at roughly 50–150 bytes per consumed token; a mix that saturates prefill with image-heavy requests reaches ≈ 30–60 MB/s. Egress is ≈ 1–2 MB/s for text, rising to ≈ 10 MB/s for embedding-heavy workloads returning dense vectors. Structured tool-intent outputs (per the pure-inference-appliance requirement) are negligible at these scales.
Recommended cap: β = 1 Gbps (125 MB/s) per direction per pod, averaged over 60 seconds — equivalent to ≈ 14 Mbps per GPU. This provides at least 2x headroom over the worst-case legitimate mix modeled above, so the cap should be operationally invisible to a compliant operator. All inefficiency results below scale inversely with β: if a deployment chose a 10 Gbps cap, every multiple in this appendix would be divided by 10, which is why we recommend the cap be set from a workload model like the one above rather than from generic provisioning habits.
A.4 Unconstrained Training Baseline
Unconstrained, one pod training M_adv processes:
τ₀ = R_pod / C_t = 2.88×10¹⁷ / 2.4×10¹³ = 12,000 tokens/s per pod.
For scale, consider a reference frontier run of 40T tokens, i.e. ≈ 1×10²⁷ FLOPs. Unconstrained, this is ≈ 3.5×10⁹ pod-seconds ≈ 110 pod-years ≈ 69 million GPU-hours — e.g., ~440 pods (≈ 32,000 GPUs) for three months. The inefficiency multiples below should be read against this baseline.
A.5 The Delivery Bound Under Randomized Routing
The design’s randomizing load balancer imposes a structural penalty on any pod-to-pod communication, and it is worth deriving this penalty once, since all three cases reduce to it.
Setting. Pods can only receive traffic proxied by the router, which selects a destination uniformly at random among the N ≥ 100 pods in its cell; a request to reach one specific pod succeeds with probability 1/N ≤ 1/100. Egress is not randomized in the same way — a pod’s response returns to whichever external harness sent the request — so the adversary’s harness can collect from pods efficiently, but delivering a payload into the correct pod requires repeated random attempts.
Delivery lemma (heuristic). If a payload of s bytes is useful only to a fraction f of the pods in the cell (e.g., the pods holding a particular pipeline stage), then any delivery scheme consumes at least s/f bytes of the cell’s aggregate ingress in expectation per useful delivery. Retransmission until a hit costs exactly this. Bundling payloads for all stages into every request, broadcasting, erasure coding, and multi-hop relaying (which faces the same memoryless routing at every hop) all pay the same expected cost or worse, because the router delivers information to the target set at rate f times the ingress spent. Misrouted bytes are not merely wasted by the sender — they consume the receiving pod’s capped ingress, so the penalty binds at the cell level.
Memory-placement invariant. How large can f be? If the adversary’s model has training state Σ divided into S pipeline stages replicated across the cell, each pod can hold m/(Σ/S) stages, so the number of pods holding any given stage is k = N·m/Σ regardless of S, giving:
f = m/Σ — i.e., f ≈ 13.5/480 ≈ 1/36 with HBM only, or 30.5/480 ≈ 1/16 granting full use of Grace LPDDR5X as training-state memory (offload traffic over the 900 GB/s NVLink-C2C links is fast enough that we grant it as free).
The minimum viable stage count is S_min = ⌈Σ/m⌉ = 36 (HBM only) or 16 (with LPDDR offload), since each stage must fit on one pod.
Core formula. In pipeline training, each token requires 2(S−1) boundary crossings (forward activations plus backward activation-gradients), each carrying b_eff bytes (b = 2d bytes ≈ 32 KB at BF16 with d = 16,384, divided by any compression factor). Combining with the lemma, per-pod constrained throughput is β·f / (2(S−1)·b_eff), and:
I ≥ τ₀ · 2(S−1) · b_eff / (f · β)
This formula, with the parameter table in §A.2, generates all headline numbers below and can be re-run with updated parameters as hardware and model architectures evolve.
A.6 Case 1 — Direct Adaptation of Centralized Training
Case 1a: Fully sharded data parallelism (ZeRO-3 / FSDP [7]). Sharded approaches stream parameters to every worker each step: each pod must ingest ≈ 2Σ_weights ≈ 120 TB per optimizer step (forward and backward all-gathers of FP8 weights). At β this takes ≈ 9.6×10⁵ seconds per step. Compute per step for a generous per-replica batch of 4M tokens across 36 pods is ≈ 9.3 seconds. Slowdown ≈ 10⁵ before any routing penalty, and 10⁵–10⁶ with it. This family is simply non-viable across capped links, which is consistent with why frameworks like PRIME confine FSDP to intra-node fabric [5].
Case 1b: 3-D parallelism (tensor within pod, pipeline across pods, data parallel across replicas [8]). This keeps weights resident and is the strongest conventional adaptation. Two cross-pod flows remain:
Combined, and then multiplied by the routing penalty (×16–36) on both flows, the most straightforward adaptation of centralized training lands at ≈ 10⁴–10⁵, with ≥ 10³ as a highly conservative floor. This supports the main text’s claim of “likely 1000x or more” for adaptations of standard centralized strategies. An adversary’s obvious next moves — synchronize gradients rarely, or abandon full replicas — are precisely Cases 2 and 3.
A.7 Case 2 — DiLoCo-Family Low-Communication Training
DiLoCo [2] and its descendants (Streaming DiLoCo [3], OpenDiLoCo [4], and the INTELLECT-1 production run [5]) dramatically reduce inter-node synchronization: workers take H = 100–500 local steps between outer synchronizations, and pseudo-gradients compress well (int8 in INTELLECT-1, with a reported ~400x reduction in data-parallel communication [5]; further overlap and 4-bit outer communication in Streaming DiLoCo [3]).
The decisive limitation in our setting is the family’s core assumption: each worker holds a full model replica and optimizer state. For M_adv this is 480–960 TB — a single “DiLoCo node” must span 16–36 pods (§A.2), and because pods cannot address one another directly, all intra-node traffic (the inner training loop itself) must cross capped, randomly-routed uplinks. DiLoCo optimizes exactly the term that was already smallest and leaves the dominant term untouched:
Case 2 conservative floor: ≥ ~350–400x, with central estimates of 1,500–8,000x. The published evidence base is also worth noting: the largest public DiLoCo-style runs are ~10B parameters with each node comfortably holding the full model [5] — four orders of magnitude below M_adv’s state footprint per node.
A.8 Case 3 — SWARM-Style Pipeline Parallelism
SWARM parallelism [6] removes the full-replica assumption: nodes hold single stages, pipelines are stochastically wired among correct next-stage peers, and rebalancing handles faults. It is the best-known published fit for the pod-constrained setting and was demonstrated training a 1B-shared-parameter model on preemptible T4s with under 200 Mb/s links [6].
Two observations govern its performance here. First, SWARM’s stochasticity is chosen from the set of valid next-stage nodes; the design’s router substitutes uniform randomness over all pods, which is strictly worse for the adversary and is exactly the delivery-lemma setting. Second, SWARM’s stage-replica averaging is a mild DP term we grant as free (it can be DiLoCo-ified). The bound is therefore the same core formula, and we also grant: zero pipeline bubbles, zero fault overhead, free external orchestration, and AQ-SGD-style activation compression [12] — noting that AQ-SGD’s 2–4-bit results are for fine-tuning at ≤ 1.5B parameters, and comparable compression for from-scratch frontier pretraining is unproven.
noting that AQ-SGD’s 2–4-bit results are for fine-tuning at ≤ 1.5B parameters, and comparable compression for from-scratch frontier pretraining is unproven.Case 3 conservative floor: ≥ ~350x under every simultaneously-granted charitable assumption we consider defensible, degrading to ≈ 140x only if two additional unproven techniques (8x lossless-for-quality activation compression at frontier scale, and an unusually narrow architecture for a 60T-parameter model) both succeed. Cases 2 and 3 converge on the same bound because both reduce to delivering activations into specific stage-holders through a memoryless random router.
A.9 Summary of Bounds and Economic Feasibility
Headline claim supported: I ≥ 100x, with roughly 1.4–3.5x of margin remaining even after stacking every charitable and speculative assumption simultaneously, and with central estimates one to two orders of magnitude higher. This is consistent with, and slightly strengthens, the main text’s framing (≥ 100x even for decentralized strategies; ≥ 1,000x for centralized adaptations).
In concrete terms, against the ≈ 1×10²⁷-FLOP reference run of §A.4 (110 pod-years; 69M GPU-hours unconstrained):
A.10 Adversary Countermeasures Considered, Residual Risks, and Design Recommendations
Countermeasures already priced into the bounds. Payload bundling, broadcast, erasure coding, and multi-hop relaying (delivery lemma, §A.5); activation compression up to 4–8x [12]; LPDDR offload of optimizer state; infrequent and quantized outer synchronization [2, 3, 5]; unbounded external harness compute; perfect overlap; zero fault/bubble overhead; batch scaling to generous per-replica sizes [9].
Residual risk 1 — Stage-clustered routing cells (most important). The routing penalty assumes the adversary cannot control which pods sit behind which router. If the operator may freely assign pods to routers, it could dedicate an entire ≥100-pod cell to a single pipeline stage; uniform routing within a homogeneous cell is then harmless (f → 1), and the bound collapses to the cap-only pipeline term: ≈ 90–220x uncompressed and as low as ≈ 25x with compression. Design Recommendation A-1: the assignment of pods to routers must be randomized under auditor control and periodically re-randomized. Because a pod’s resident training-state shard is 14–30 TB, re-homogenizing cells after a reshuffle would require migrating that state through capped 125 MB/s uplinks (≈ 30–70 hours per pod per reshuffle), so even weekly re-randomization imposes a large standing tax on any attempt to defeat the routing penalty. With A-1 in place, stage placement is uniform in expectation and f = m/Σ as modeled.
Residual risk 2 — Local storage expansion. The invariant f = m/Σ improves for the adversary as per-pod memory m grows. Undeclared NVMe could raise m substantially (partially offset by offload thrash: streaming tens of TB of optimizer state per step through PCIe/NVMe stalls compute). Design Recommendation A-2: per-pod local storage must be declared, capped, and included in the physical inspection regime, and the deployed cap β should be set with the declared m in mind.
Residual risk 3 — Algorithmic innovation. The bounds are only as durable as the assumption that pre-training a monolithic 60T-parameter model requires moving ~2d bytes per token per stage boundary. Research directions that could erode the margin include extreme activation compression validated at pretraining scale, architectures with unusually small inter-layer widths relative to parameter count, and modular/federated paradigms that compose many pod-sized models (e.g., distillation federations); no published method in the last category currently matches monolithic frontier pretraining quality [13], but this should be treated as a standing watch item, consistent with this design’s positioning as a short-to-medium-term deterrent and Phase-1 milestone.
Residual risk 4 — What this design does not claim. These bounds concern pre-training models strictly larger than the frontier the pods are sized for. Training models that fit within a single pod (≤ M_inf scale), fine-tuning, and RL post-training within one pod are outside the modeled threat and are the natural target of the Phase-2 recomputation design; the router and cap still deny such runs any efficient multi-pod scale-out.
Sensitivity. All results scale linearly in 1/β (double the cap, halve the multiple), linearly in b_eff (i.e., in the hidden dimension d and compression), and via f = m/Σ in the ratio of pod memory to adversary-model training state (a 10x-frontier target gives Σ/m ≈ 16–36; a merely 2x-frontier target would shrink the routing penalty roughly proportionally and should be re-run through §A.5’s formula). Parties adopting this design should re-derive β and the bounds from the then-current pod hardware, frontier model architecture, and declared storage, using the formulas in §A.5.
Appendix A References
When we say “frontier training” or sometimes “training” in this document, we are specifically discussing training of LLMs that are strictly larger than models for which we currently wish compute facilities to be allowed to serve inference requests for. Traffic Shaping as a design works in such a way that the strength of the deterrent to new training increases as the size of the model an adversary is trying to train increases relative to the current allowed inference size.
This design requires a number of new network devices to be introduced into the compute facility. Given that the verifier will require a high-level of trust in these devices and the facility owner (prover) will likely have a high level of concern about security and data privacy risks from these devices, we imagine that the devices will be designed and manufactured through a co-design process involving both parties, possibly mediated by one or more independent third-party organizations. To achieve a high-level of mutual trust, this process may include utilizing existing commodity hardware, redundant components from multiple suppliers and components based on open source and open standards.
Introducing random routing is likely to have a performance impact on the compute resource, particularly under high-load. To mitigate this, additional design elements may be introduced. For example a mechanism that enables a pod to request that the router remove it from the pool of pods receiving new requests for some period (e.g. 10 seconds) in order to reduce load on that pod. Limits would need to be imposed on how many pods could utilize this mechanism at one time to prevent exploitation by an adversary attempting to efficiently route messages for training. More research is needed on the performance impact of random routing on inference and mitigations.
Further research is needed into the optimal way to enforce this restriction in a way that can be trusted by all parties.