Sensitive AI workloads face an exposure that encryption during storage and transport does not resolve: data must also be protected while it is being processed. Google’s TPU 8tx targets that boundary through confidential computing, while its TPU 8i Max addresses the memory constraints of large-context inference. For network architects, the distinction creates a deployment question: which system can meet the workload’s performance requirements without moving sensitive data outside its required protection domain?
How the Tpu 8TX Addresses Data in Use
Google is expanding its eighth-generation TPU lineup with TPU 8tx and TPU 8i Max, bringing the generation to four system configurations introduced within one year. These are not four separate chip designs. The security-focused 8tx reuses TPU 8t silicon, while the memory-focused 8i Max packages two TPU 8i chips together.
The 8tx pairs its accelerators with custom 5th Gen AMD EPYC “Turin” hosts. Google describes the resulting system as a confidential computing offering for governments and regulated enterprises handling sensitive information alongside proprietary or frontier models. Its protection mechanism uses an isolated trusted execution environment to encrypt data during processing.
That mechanism addresses a specific gap in conventional encryption coverage. Information protected on disk or across a connection ordinarily becomes accessible in memory when computation begins. For a deployment that requires confidentiality throughout inference, the processing environment therefore becomes part of the security boundary, rather than merely a destination for encrypted network traffic.
Google’s stated protection should be read within that scope. The supplied details describe the intended hardware isolation mechanism but do not establish how every surrounding application or operational control behaves. Buyers should distinguish the advertised data-in-use protection from any broader assumption that an entire AI service is secure by default.
Host Bandwidth and Network Topology Shape the Protected Path
Google selected the Turin hosts to fit the TPU 8t interface, PCIe Gen5 x16. Its dual-socket configuration supplies 128 Gen5 lanes, which Google says avoids I/O oversubscription when connecting four TPUs and high-speed NICs. This makes host connectivity part of the design rationale, rather than treating confidential computing as an isolated CPU feature.
Google also explains why a newer host interface would not necessarily improve this configuration. An AMD EPYC Venice host with Gen6 connectivity would operate at Gen5 for these accelerators, adding no accelerator bandwidth. The vendor ties that choice to its 2027 hardware qualification schedule.
The accelerator network takes a different route from the training-oriented TPU 8t. Google equips 8tx with Boardfly, the topology used by TPU 8i, whose maximum chip-to-chip path spans seven hops rather than the training torus’s sixteen. Google claims latency can be as much as 2x lower than TPU 8t and describes the performance penalty as near-zero.
Sequential inference makes that architectural choice relevant. A multi-step agent repeatedly waits for one operation before proceeding to another, so communication delay can accumulate through the workflow. The latency claim remains Google’s claim, but the topology explains why the protected system is also positioned for real-time serving.
More Memory Does Not Establish the Same Security Boundary
TPU 8i Max tackles a separate constraint: workloads whose memory demands become limiting before their compute resources do. Google identifies agents processing whole codebases or extended video as examples. Combining two TPU 8i chips gives the package twice the compute, SRAM, and HBM bandwidth of an individual TPU 8i.
The specifications separate capacity from throughput:
- HBM capacity reaches 384 GB, approximately one-third above TPU 8i.
- HBM bandwidth reaches 17.2 TB/s, twice the single-chip figure.
- On-chip SRAM reaches 768 MB, also twice the single-chip amount.
Those increases support a different deployment objective from confidential processing. Consider an agent examining a codebase whose contents must remain within a confidential computing domain: greater memory capacity alone does not demonstrate compliance with that requirement. Google explicitly directs users with that constraint to TPU 8tx for serving and inference.
Establish the Protection Requirement Before Sizing Inference
The two systems should therefore be evaluated against different acceptance criteria. For 8i Max, the central question is whether additional memory resources address the workload’s bottleneck. For 8tx, evaluation must also establish that the required processing stays within the confidential domain.
Network teams should make that boundary explicit before comparing capacity or latency figures. Google’s guidance supports choosing 8tx when confidential processing is mandatory, with Boardfly retaining the low-latency interconnect intended for real-time work. Any proposal to place part of that workload elsewhere should first demonstrate that it preserves the same data-handling requirement, rather than relying on the shared TPU generation as evidence of equivalent protection.
