Google is reportedly developing Frozen v2, a chip that would embed Gemini's neural network architecture directly into silicon. On July 21, 2026, The Information reported that engineers on the project expect six to ten times more tokens per watt than Google's latest Tensor Processing Units, or TPUs. Production is planned for 2028.

The proposed design would give up some of an accelerator's flexibility to make Gemini inference more efficient. The model's trained parameters could still change, but the chip would be built around a fixed model structure. That creates a clear tradeoff: potentially much lower power use per token, provided future versions of Gemini continue to fit the hardware.

Custom AI chips are already common. Amazon has Trainium and Inferentia, Meta has MTIA, and Apple includes neural engines in its M-series systems on a chip. Frozen v2's reported distinction is how closely it would bind the hardware to one model family's architecture.

What gets frozen, and what can still change

A model's architecture is its structural blueprint. Its weights are the numerical parameters learned during training. Fixing the weights in silicon would tie a chip to a particular trained version of a model. Even a fine-tuning update could leave that hardware unable to run the revised model as intended.

Frozen v1 reportedly took that fixed-weight approach. According to The Decoder, Frozen v2 instead fixes the architecture while allowing weights to be loaded at runtime. The fixed structure could include layer counts, attention-head dimensions, feed-forward block shapes, and the connections between them.

That would allow Google to load newly trained or fine-tuned parameters without replacing the chip, as long as those parameters fit the supported structure. A substantial architectural change would be a different matter. Keeping weights updateable doesn't make the underlying hardware a general-purpose accelerator.

The efficiency argument rests on how much work can be removed by knowing the model's structure in advance. A more flexible accelerator has to support many arrangements of operations and data movement. Hardware designed for a fixed arrangement can specialize those paths rather than handle all of that flexibility during execution.

The reported six-to-tenfold improvement is an engineering projection, not a demonstrated production result. Its size would depend on how much execution and data-movement overhead the design removes from the workloads being compared.

What the power estimate would mean

Large-model inference puts heavy demands on compute and memory bandwidth. Reading model parameters and moving intermediate results consumes power and takes time, which can limit token throughput. Fixing a model's structure in hardware is intended to reduce some of that overhead, though the weights would still need to be available during inference.

If the projected improvement holds for a comparable workload, six to ten times more tokens per watt means six to ten times as many tokens within the same power budget. For the same token volume, it means roughly one-sixth to one-tenth of the power used by the TPU baseline.

That distinction matters at Google's scale, with billions of queries served daily across its services. Reporting on data center expansion describes energy capacity as a constraint on AI growth, even as infrastructure groups manage gigawatts of capacity. More inference output from an existing power allocation could help meet demand without a matching increase in electricity supply.

Google reportedly began the project partly to address internal compute constraints that have limited its ability to serve enterprise Google Cloud customers. Frozen v2 could ease those constraints by moving compatible Gemini workloads onto more efficient hardware.

It wouldn't follow that total inference costs would fall by the same factor, or that every capacity constraint would disappear. Tokens per watt measures energy efficiency. It doesn't establish the cost of manufacturing the chip, deploying it, or operating the rest of the serving system. The reported comparison is also with Google's latest TPUs, not a measured comparison with every competing accelerator.

A model-design decision that lasts for years

The planned 2028 production date leaves a substantial gap between the design decisions and the chip's use at scale. The project is described as having already received more than a year of development work. Once the chip's design is finalized for manufacturing, its hardwired structures cannot follow a software release cycle.

Google is therefore betting that enough of Gemini's architecture will remain stable to justify the investment. The important issue is more specific than whether transformers remain popular. A future model would need to fit the particular structures Frozen v2 supports.

That is a meaningful risk. Researchers are exploring state-space models such as Mamba, hybrid transformer and state-space designs, and other alternatives to full attention. Full attention has a computation cost that grows quadratically with sequence length, giving researchers a reason to look for other approaches.

As TechTimes noted, a fundamental redesign of Gemini could leave Frozen v2's hardwired elements mismatched to the new model. Depending on the change, parts of the chip or the entire design could become unsuitable for that workload.

Jeff Dean, identified in the reporting as Google DeepMind's chief scientist, is credited with originating the Frozen concept. The project suggests confidence that Gemini can retain a useful, stable structure over several years. It doesn't establish that Google expects all AI architecture research to settle on that structure.

The favorable reading of the bet is that transformer-based designs will remain useful long enough for the hardware savings to justify the loss of flexibility. That seems plausible, but broad transformer continuity alone wouldn't guarantee compatibility with every future Gemini version. The relevant test extends through the implied 2028 to 2031 operating window.

Internal hardware, with possible cloud benefits

Frozen v2 is described as intended for internal use rather than as a broadly programmable cloud accelerator. A Google Cloud customer running a fine-tuned Llama model, a Mistral deployment, or a custom architecture shouldn't assume that Gemini-specific hardware could run it efficiently.

That limits the chip's usefulness as a standalone compute offering. It doesn't prevent Google from using it behind a Gemini service sold to customers. The commercial benefit would come from serving a supported model more efficiently, rather than renting out hardware suitable for a wide range of models.

The reported approach gives Google a way to reduce costs within its own stack. If the efficiency projections hold, Google could gain room to lower prices, support more usage, or offer more capability at an existing price. Those are possible uses of the savings, not announced pricing plans.

A useful infrastructure comparison is AWS Nitro, whose custom hardware offloads networking and virtualization work to reduce overhead. The comparison concerns the economics of specialized internal hardware. Frozen v2 would specialize at the model level, where a change in software architecture could have much larger consequences for compatibility.

What infrastructure operators should watch

Frozen v2 is unlikely to change most organizations' hardware choices in 2026 or 2027. It isn't planned for production until 2028, and the reported design is specific to Google's internal Gemini workloads. Several developments would still be useful to track.

  • Production efficiency and service pricing. A measured improvement on deployed workloads would be more useful than the current projection. If Google's costs fall after 2028, some of that headroom could appear in Gemini pricing, latency commitments, or capability at a given price. Current API economics needn't remain fixed.
  • Similar designs from other large operators. A successful deployment could encourage other hyperscalers to specialize hardware around model families they expect to maintain for years. The attraction would depend on whether the savings justify development costs and reduced flexibility.
  • The exact compatibility limits. The broad label “transformer” doesn't explain which future models a chip can support. Changes to layer counts, dimensions, attention mechanisms, or routing could matter if those details are fixed in silicon.

There is precedent for moving stable software functions into dedicated hardware. Smart network interface cards take on networking work, NVMe controllers handle storage-protocol functions, and dedicated circuits perform cryptographic operations. Each design trades flexibility for more efficient execution of a defined task.

Frozen v2 would make that trade for inference within a particular model family. The weights could keep changing, while the hardware remained tied to the structure chosen years earlier. Its success would depend on how much useful Gemini work continues to fit that structure, and whether the resulting savings outweigh the cost of committing to it.