Monitoring GPU Communication Patterns for LLM Training Detection

In order to enable international cooperation between the US and China on mitigating the risks from advanced AI we need to work on the technical feasibility of verification mechanisms. One thing we might want to verify as part of this regime is whether an AI workload being run on a cluster of GPUs is a training workload or an inference workload because we might want to only allow inference of existing models and not training new ones. One thing about training LLMs is that they require massive amount of data transfer between GPUs, enabled by rapidly advancing interconnect technology, like NVlink and RoCE. Our goal is to use system-level monitors that measure the size of data being transferred in and out of a GPU node and use these together to determine whether a workload is training or if it is inference. Then, we want to red-team this to see what vulnerabilities it has to a determined attacker.

We start by implementing the training detection described by Seferis and Fist (https://dl.acm.org/doi/10.1609/aaai.v40i44.41127), which frames compute structuring as a way an adversary might subvert a verification protocol and argues that examining interconnect traffic could detect it. We then adopt the adversarial evaluation methodology of Rahman and Tajdari (https://arxiv.org/pdf/2606.19262), but apply it to a communication-size signal rather than the on-GPU telemetry they use. With that detector built and validated on benign workloads, we move to red-teaming. Seferis and Fist already suggest evasions worth testing, such as decentralized training and splitting one continuous run into shorter separate ones, and we will implement those alongside strategies of our own.

The output is a report documenting how we implemented the detector, walking through each red-teaming experiment, and identifying which evasion strategies were most effective for a potential adversary.

AI systems keep getting more and more powerful and are on pace to be capable of causing catastrophic harms. Part of the reason for this rapid pace of progress is multi-lateral competition between frontier labs as well as an international AI arms race between the US and China. An attempt at a treaty or less-formal agreement to develop advanced AI in ways that minimize catastrophic harms will have a much higher likelihood of success if signatories (either US and China or individual AI companies) have a way of robustly verifying that the other party is also acting in accordance with the agreement. If an agreement were reached today, we wouldn’t have a technically-sound way to mutually share information about AI training runs or deployments in a way that maintains privacy of the specific AI workload being run. For this reason, working on the technical details of how AI workloads can be verified is important today, so that the technology matures in time for when a treaty is needed.

An initial pause on training more advanced AI models would require the verification regime to determine whether an AI workload is a training run or inference. Monitoring the volume of communication between GPUs can potentially be one of the easiest to implement training vs. inference verification because it can improve upon the existing ways that cloud-providers collect privacy-preserving data for normal operational reasons. Any proposal for verification, however, must be robust against an adversary trying to subvert it, so by showing ways an adversary could work around this particular inference verification regime, this project can be used as a starting point for future iterated development.

First, mentees will implement a training detection program that works in the way Seferis & Fist describe in their paper (https://dl.acm.org/doi/10.1609/aaai.v40i44.41127). A successful output for this looks like a monitoring script which runs on all nodes used in the experiments and reports data communication sizes to some central server that then makes the judgement of whether the workload is training vs. inference along with tests of the detector across a broad range of benign, sample LLM training and inference workloads.

Second, mentees will design and implement strategies for adversarial pre-training workloads that can subvert the detector they built. Some of these strategies might be, disguising gradient synchronization as an inference KV-cache transfer, using DiLoCo (https://arxiv.org/pdf/2311.08105) or related decentralized training algorithms to drastically reduce the communication overhead of DDP, or others.

Thirdly, mentees will write a report that outlines how they implemented the inference verification setups and which adversarial strategies were most effective at subverting the detector. Finally, they will conclude with recommendations for making inference verification more robust in practice.

• Understands distributed ML training and inference
• Comfortable with Linux, SSH, and remote-cluster environment
• Highly proficient using Python
• Prior courses or projects in ML systems or networking are a plus