"For nine rounds I averaged the updates my workers sent me and trusted every number. On the tenth round one of them sent me a gradient the size of a small moon, and I learned that trust, at scale, is just a slow way of being attacked."
An Aggregation Server That Has Stopped Taking the Mean
Chapter Overview
This chapter closes Part VII, and with it the infrastructure half of the book, by confronting the failure modes that scale-out amplifies rather than the capabilities it unlocks. Every earlier chapter measured a system by what it could do: more data through the pipeline, more parameters in the model, more requests per second off the fleet. Here the question inverts. We ask what happens when the fleet is large enough that something is always broken, when some of the broken parts are broken on purpose, and when the very size that makes the system powerful also magnifies its mistakes into systematic harm. A distributed AI system at scale is not just bigger than a single machine; it has a larger attack surface, a longer list of things that can fail independently, and a heavier set of responsibilities to the people its decisions touch. This chapter teaches you to design for that world, where failure is the steady state and trust is something you must construct rather than assume.
A word on why this chapter is the right place to end the infrastructure parts. The earlier chapters earned their scale; this one pays for it. Each defense here is the distributed, adversarial version of an idea the book has already met: fault tolerance is recovery from Chapter 2 hardened against malice, robust aggregation is the all-reduce of Chapter 4 taught to distrust its inputs, differential privacy is the secure aggregation of Chapter 14 given a formal leakage bound, and governance is the MLOps discipline of Chapter 26 extended to the questions a regulator or a harmed user might ask. Read together, the eight sections make one argument: a system that scales out must also scale its defenses out, because at fleet scale there is no center left to protect it, and no single machine to hold accountable when it goes wrong.
Prerequisites
This chapter gathers the book's reliability, privacy, and federation threads and turns each against an adversary, so it assumes the chapters that introduced them cooperatively. From Chapter 2 it assumes the distributed-systems vocabulary of crash versus Byzantine faults, replication, and recovery, which Section 35.1 sharpens into a reliability-versus-adversary distinction. From Chapter 14 it assumes federated and decentralized learning, FedAvg, gossip, and secure aggregation, the setting where poisoning in Section 35.4 and robust aggregation in Section 35.5 do their work. From Chapter 18 it assumes fault-tolerant training, checkpointing, elastic scaling, and straggler mitigation, which Section 35.2 reframes as a reliability budget. From Chapter 26 it assumes the MLOps machinery of versioning, lineage, and monitoring that Section 35.7 extends into governance, and from Chapter 33 it assumes the cluster substrate, multi-tenancy, and resource isolation on which fleet-scale security and accounting rest. Readers comfortable with those five threads can read this chapter as the place where the book asks what its own systems owe to a world that does not always cooperate.
Learning Objectives
- Distinguish reliability against accidental faults from security against deliberate adversaries, and place a distributed AI failure in the crash-fault-to-Byzantine spectrum of Chapter 2.
- Design fault tolerance and recovery for an AI workload, turning the checkpointing and elastic restart of Chapter 18 into an explicit reliability budget.
- Map the security surface of a distributed AI system and reason about data and model poisoning and backdoor attacks in distributed and federated settings.
- Replace naive averaging with Byzantine-robust aggregation rules (coordinate-wise median, trimmed mean, Krum, geometric median) and state the fraction of adversaries each tolerates.
- Apply differential privacy and DP-SGD to bound what a model or an update leaks, and reason about the privacy-utility trade-off across a fleet.
- Build auditability and governance across a fleet (lineage, model cards, datasheets) and account for the bias and carbon cost that scale with the fleet.
If you keep one thing from this chapter, keep this: at fleet scale, failure is the steady state and trust is not given, so every defense, fault tolerance, robust aggregation, privacy, governance, must itself be distributed, because there is no center left to protect the system and no single machine to hold accountable. A training run on ten thousand nodes will always have a node down, so reliability is a budget you spend, not an event you react to. A federated model trained across a million phones cannot inspect any one of them, so it must aggregate in a way that survives the ones that lie. A system that learns from people must bound what it leaks about them and answer for what it decides about them, on machines no single auditor can walk. Read forward, the chapter is a tour of those defenses in order: reliability and recovery, the security surface, poisoning and robust aggregation, differential privacy, governance, and the bias and carbon the fleet multiplies. Read as a question, it is a single checklist you apply to any system at scale: what fails here, who would attack it, what does it leak, and who answers when it goes wrong? The roadmap below walks the eight sections that build that checklist.
Chapter Roadmap
- 35.1 Reliability in Distributed AI Why failure is the steady state once a system spans a fleet, the line between tolerating accidental faults and resisting deliberate ones, and the Byzantine model from Chapter 2 reintroduced as the worst case the rest of the chapter answers.
- 35.2 Fault Tolerance and Recovery Checkpointing, replication, and elastic restart for AI workloads, turning the survival tactics of Chapter 18 into a deliberate reliability budget that decides how much redundancy a training run or a serving fleet should buy.
- 35.3 Security in Distributed AI Examines the model-theft and multi-tenant exposure threat model, then develops NVIDIA Confidential Computing mode: encrypted VRAM, GPU attestation against the NVIDIA DeviceRoot CA, TDX+CC composite attestation for end-to-end confidential ML pipelines, and current limitations of multi-GPU CC.
- 35.4 Data and Model Poisoning in Distributed and Federated Settings Covers gradient poisoning and backdoor attacks in federated learning, then adds the 2025 LLM attack surface: direct and indirect prompt injection, RAG corpus poisoning, supply-chain slopsquatting, and a layered defence combining instruction hierarchy enforcement, tool sandboxing, and LLM-as-judge output screening.
- 35.5 Byzantine-Robust Aggregation Replacing the naive mean of Chapter 14 with coordinate-wise medians, trimmed means, Krum, and geometric-median rules that survive a bounded fraction of liars, and the breakdown point each one guarantees.
- 35.6 Privacy and Differential Privacy in Distributed Learning From the promise of secure aggregation to the provable bound of differential privacy and DP-SGD, so that what leaves a device or enters a shared model carries a formal limit on what it can leak.
- 35.7 Auditability and Governance Across a Fleet Lineage, model cards, datasheets, and the records that let an organization answer for a decision made on thousands of machines, extending the MLOps discipline of Chapter 26 into accountability.
- 35.8 Bias and Environmental Cost at Scale The two responsibilities the fleet quietly multiplies, a small bias becoming systematic and a few watts becoming a carbon budget, and the measurement and mitigation practices that keep both in view.
What's Next?
This chapter, and Part VII with it, finishes the infrastructure: we now have a fleet that scales, survives its own failures, resists adversaries, protects what it learns, and answers for what it decides. Chapter 36: Web-Scale Text Processing and Distributed RAG opens Part VIII, where the book stops building parts and starts assembling them into end-to-end distributed AI systems. The case studies ahead draw on every part at once, the data pipelines of Part II, the parallel training of Parts III and IV, the serving fleets of Part V, the agents and operations of Parts VI and VII, to show how a real system distributes intelligence across machines under all the constraints this book has named. We have built the toolkit; now we watch it do work, starting with the distributed retrieval and generation that turns the whole web into a model's working memory.
Bibliography & Further Reading
Foundational Papers
Lamport, L., Shostak, R., Pease, M. "The Byzantine Generals Problem." ACM Transactions on Programming Languages and Systems 4(3), 1982. dl.acm.org
The founding statement of the Byzantine fault model: how to reach agreement when some participants lie arbitrarily, and the bound that no more than a third may be traitors. The worst case that frames Sections 35.1 and 35.5.
Bonawitz, K., Ivanov, V., Kreuter, B., et al. "Practical Secure Aggregation for Privacy-Preserving Machine Learning." ACM CCS 2017. eprint.iacr.org
The protocol that lets a server sum client updates without seeing any one of them, robust to dropouts; the cryptographic backbone of the privacy and aggregation material of Sections 35.5 and 35.6.
Attacks & Defenses
Blanchard, P., El Mhamdi, E. M., Guerraoui, R., Stainer, J. "Machine Learning with Adversaries: Byzantine Tolerant Gradient Descent (Krum)." NeurIPS 2017. papers.nips.cc
Introduces Krum, which selects the update closest to its neighbors and provably tolerates a bounded fraction of Byzantine workers; the first robust-aggregation rule of Section 35.5.
Yin, D., Chen, Y., Kannan, R., Bartlett, P. "Byzantine-Robust Distributed Learning: Towards Optimal Statistical Rates." ICML 2018. arXiv:1803.01498
Establishes coordinate-wise median and trimmed-mean aggregation with optimal statistical convergence rates under Byzantine attack; the workhorse defenses of Section 35.5.
Bagdasaryan, E., Veit, A., Hua, Y., Estrin, D., Shmatikov, V. "How To Backdoor Federated Learning." AISTATS 2020. arXiv:1807.00459
Shows that a single malicious client can plant a backdoor in a federated model through update replacement; the canonical backdoor attack motivating Section 35.4.
Bhagoji, A. N., Chakraborty, S., Mittal, P., Calo, S. "Analyzing Federated Learning through an Adversarial Lens." ICML 2019. arXiv:1811.12470
A systematic study of model-poisoning attacks against federated learning and the defenses they evade; the threat-model grounding for Section 35.4.
Privacy
Abadi, M., Chu, A., Goodfellow, I., et al. "Deep Learning with Differential Privacy." ACM CCS 2016. arXiv:1607.00133
Introduces DP-SGD, gradient clipping plus calibrated noise plus a moments accountant, the practical recipe for training a model with a provable privacy bound; the engine of Section 35.6.
Dwork, C., Roth, A. "The Algorithmic Foundations of Differential Privacy." Foundations and Trends in Theoretical Computer Science, 2014. cis.upenn.edu
The standard monograph defining differential privacy, its composition theorems, and the privacy-utility trade-off; the formal foundation behind the guarantees of Section 35.6.
Responsibility
Mitchell, M., Wu, S., Zaldivar, A., et al. "Model Cards for Model Reporting." ACM FAccT 2019. arXiv:1810.03993
Proposes the model card, a structured record of a model's intended use, performance across groups, and limitations; the accountability artifact at the center of Section 35.7.
Gebru, T., Morgenstern, J., Vecchione, B., et al. "Datasheets for Datasets." Communications of the ACM 64(12), 2021. arXiv:1803.09010
Argues that every dataset should ship with a datasheet documenting its provenance, composition, and intended use; the data-lineage companion to model cards in Section 35.7.
Strubell, E., Ganesh, A., McCallum, A. "Energy and Policy Considerations for Deep Learning in NLP." ACL 2019. arXiv:1906.02243
The paper that put a carbon number on training large models and started the field's reckoning with its energy footprint; the opening case of the environmental cost in Section 35.8.
Patterson, D., Gonzalez, J., Le, Q., et al. "Carbon Emissions and Large Neural Network Training." 2021. arXiv:2104.10350
A careful accounting of the carbon of large-model training and the levers, hardware, datacenter, and energy mix, that reduce it; the measurement discipline of Section 35.8.