# TPU 8tx vs TPU 8i Max: Which Workloads Should Evaluate Each?

Google's specialized TPU systems target different constraints, so the useful comparison starts with confidentiality and inference bottlenecks.

By Paras Madan | 2026-11-10

Google announced TPU 8tx and TPU 8i Max on November 9 as specialized systems built around its existing eighth-generation TPU family. TPU 8tx targets confidential inference and smaller training workloads; TPU 8i Max combines two 8i chips in a package for larger inference requirements. They should not be treated as interchangeable upgrades.

The first decision is what limits the workload today. A confidentiality requirement and a memory-bandwidth bottleneck can both be important, but they call for different evidence before a hardware migration.

## What changed in the specialized systems

[Google's announcement](https://cloud.google.com/blog/topics/ai-infrastructure/tpu-8tx-and-tpu-8i-max) describes TPU 8tx as using the same TPU silicon as 8t, paired with fifth-generation AMD EPYC host processors and hardware support for confidential computing. It uses the Boardfly network topology rather than simply preserving every aspect of the original 8t system.

TPU 8i Max packages two 8i chips together. Google describes doubled compute, SRAM and HBM bandwidth, along with higher rack density. Those are system characteristics, not a published promise that any particular model will serve twice as many requests.

Neither description makes the specialized systems a new TPU generation. That matters when comparing an existing deployment: first establish which system-level changes affect your application, rather than assuming a generational improvement everywhere.

## Use the original 8t and 8i distinction as a baseline

Google's earlier [8t and 8i technical breakdown](https://cloud.google.com/blog/products/compute/tpu-8t-and-tpu-8i-technical-deep-dive/) positions the base systems differently. Its published specifications list 216 GB HBM and 128 MB SRAM for 8t, compared with 288 GB HBM and 384 MB SRAM for 8i. The respective HBM bandwidth figures are 6,528 GB/s and 8,601 GB/s.

Those numbers describe the original chips. They are useful context, but should not silently become a complete specification sheet for the new packages. In particular, doubling compute or bandwidth does not establish an undocumented memory capacity, supported model context length or per-request latency.

## When to investigate TPU 8tx

Start with 8tx if the application's requirement is protecting model or customer data during processing, and the proposed confidential-computing boundary matches the threat model. Ask which components are covered, how the deployment proves the expected software is running, and how keys are released to the workload.

For example, a company evaluating private document inference should first map the path from encrypted storage through preprocessing, inference and response delivery. Protecting the accelerator portion does not by itself establish protection for every surrounding service. A procurement conversation about confidential hardware should therefore include the application security team, not just the team comparing accelerator throughput.

## When to investigate TPU 8i Max

Start with 8i Max if profiling points to an inference constraint that more local compute, SRAM or HBM bandwidth could address. Define the target in application terms: latency at a particular input length, output speed at a particular concurrency, or cost for a fixed mix of requests.

A useful comparison would keep the model, numerical precision, prompt distribution and serving objective fixed. Then change the system and measure whether the required deployment size falls. Without that control, an attractive throughput number can come from a looser latency target or a different batch shape rather than the hardware choice alone.

The same caution applies to long context. More hardware resources can make a workload easier to serve, but the model and serving stack still determine what context lengths are supported. Do not sell an infrastructure change to users as a model capability that has not been established.

## Pricing and availability still need confirmation

The announcement does not provide a complete public price list, regional availability matrix or general-availability procurement instructions for these systems. Treat it as a reason to begin an evaluation conversation, not evidence that a production migration can start immediately.

Ask for the supported software stack, capacity options, pricing basis and availability date together. **A faster system is only an improvement if it meets the same application requirement at an acceptable total cost.** Until those inputs exist, the defensible choice is a shortlist based on the workload's actual constraint, not a universal winner.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help AI infrastructure teams explain technical tradeoffs through clear product stories and developer-focused content.

[Book a 30-minute call](https://cal.com/paras-madan/30min)