DEV Community: Jaychou/Wen Ruyi

GLM 5.2 and the Collapse of AI Margins: Open-Source Models Are Rewriting the Rules of the Industry

Jaychou/Wen Ruyi — Fri, 10 Jul 2026 03:28:45 +0000

GLM 5.2 and the Collapse of AI Margins: Open-Source Models Are Rewriting the Rules of the Industry

Introduction: A "Counterintuitive" Open-Source Release

Figure 1: The core drivers of the AI margin collapse — open-source models, price competition, and surging usage

In 2026, Zhipu AI quietly published the GLM 5.2 open-source model on Hugging Face. This news lingered in AI practitioners' information streams for less than half a day before being drowned out by the next wave of updates. But those who were truly sharp noticed a set of data: GLM 5.2's performance across multiple authoritative benchmarks was nearly on par with top-tier closed-source models like GPT-4o and Claude 3.5 Sonnet — yet its inference cost was only a fraction of theirs.

This is no longer a story of "catching up." This is leapfrogging.

Even more telling is that this news triggered a fierce debate in the overseas tech community: opinion leaders including a16z partners and former Stripe executives waded in, discussing a somewhat brutal topic — "AI margins are collapsing." This discussion quickly spread from tech circles to investment circles, because it points directly at a core question: When open-source models' capabilities approach or even partially surpass those of closed-source models, how long can the existing AI business model hold up?

If 2023's open-source models were still "toys" — with cliff-like gaps from closed-source products in complex reasoning, code generation, and multi-turn dialogue — then the 2024-2025 open-source models are no longer "value-for-money alternatives," but a fundamentally new paradigm threat. The release of GLM 5.2 is merely the latest signal flare of this paradigm shift.

In this article, we'll unpack three things: what GLM 5.2 got right, how open-source models have rewritten AI pricing power, and the true industry realignment behind this "margin collapse."

Technical Core: The Architecture Secrets of GLM 5.2

Figure 2: Schematic of GLM-5.2's MoE (Mixture of Experts) layered architecture

From GLM to GLM 5.2 — A Hidden Evolutionary Line

The GLM (General Language Model) series is a large language model family that Zhipu AI has been continuously iterating since 2023. If we had to describe its evolution in one word, it would be pragmatic.

When GLM-130B was open-sourced in March 2023, it was still a behemoth that required considerable hardware investment to run. The subsequent ChatGLM series (6B-130B) gradually moved toward lightweight designs, but its overall capability was always evaluated in the industry as "can compete with LLaMA 2, but a generation behind GPT-4."

The turning point came with the GLM 5 generation. The 5.0 version introduced the MCSD (Mixture of Channel and Sequence Dimensions) attention mechanism for the first time, significantly improving inference efficiency and accuracy in long-context scenarios. The 5.1 version then focused heavily on code capability and tool-calling capability.

The breakthroughs in GLM 5.2 can be summarized in three key technical decisions:

Key Technology 1: The Mature Implementation of the Hybrid Attention Mechanism (MCSD)

One of the core bottlenecks of large language models is the computational complexity problem of the "attention mechanism." The standard Transformer architecture uses Softmax attention, where computational cost grows quadratically with sequence length — O(n²). When the context window expands from 4K to 32K, 64K, 128K, the computational overhead explodes.

The MCSD mechanism used by GLM 5.2 is essentially a scheme that performs hybrid attention computation across both the channel dimension and the sequence dimension simultaneously. Simply put:

Channel-dimension attention: Lets the model focus on the relationships between different features, similar to "how words relate to each other at different levels of semantic abstraction"
Sequence-dimension attention: Lets the model focus on the relationships between different positions — i.e., traditional Transformer attention

The mixing of the two brings two key benefits:

First, long-context processing efficiency improves significantly. GLM 5.2's memory footprint at a 128K context window is about 30% lower than LLaMA 3 with equivalent parameters. This means that with the same hardware, GLM 5.2 can process longer documents and conduct more complex multi-turn conversations.

Second, inference accuracy is not discounted despite the efficiency optimization. On LongBench (a long-context understanding benchmark), GLM 5.2 scored higher than closed-source models with comparable parameter counts, such as GPT-4o-mini.

The implementation of MCSD is not theoretical innovation, but a victory of engineering optimization. It tells us that doing efficient hybrid design on top of existing architectures is often more practical than designing an entirely new architecture.

Key Technology 2: Precise Practice of the MoE Architecture

GLM 5.2 introduced the MoE (Mixture of Experts) architecture. This is not a new concept — Google's Mixtral 8x7B had already proven the feasibility of the MoE route. But GLM 5.2's MoE implementation has three unique aspects:

The first is the optimization of "expert allocation." In traditional MoE models, the routing mechanism assigns each token to top-k experts. GLM 5.2 builds on this by introducing an auxiliary routing network that pre-judges the most likely expert combinations based on the input sequence's semantic structure, dramatically reducing the wasted computation caused by "trial allocations."

The second is the "sharing and isolation of expert parameters" strategy. GLM 5.2's experts are not entirely independent — they share a low-level Semantic Encoder and only specialize at the high-level decision layer. This "low-level sharing + high-level isolation" design preserves MoE's parameter scaling advantages while avoiding knowledge fragmentation between experts.

The third is the extreme optimization of activation efficiency. According to benchmarks published by Zhipu AI, GLM 5.2 only activates 8B parameters per inference (out of 47B total parameters), so the FLOPs overhead per inference is on par with a dense 8B-parameter model, yet the model capacity approaches the 50B class. What does this mean? Roughly 80% reduction in inference cost.

In the AI industry, inference cost directly determines a product's gross margin. The cost compression that GLM 5.2 achieves through its MoE architecture provides the "ammunition" for open-source models to challenge closed-source products.

Key Technology 3: Tool Calling and Native Agent Capabilities

If 2023 was the year of "large language models," 2024 the year of "multimodal," then 2025 is without a doubt the year of "Agents."

GLM 5.2 has done deep design work on tool calling (Function Calling) and Agent capabilities. Unlike some models that "induce" the model to learn tool calling through prompt engineering, GLM 5.2 internalizes the tool-calling paradigm during the pre-training phase.

Specifically, GLM 5.2's training data contains a large number of multi-step examples in the pattern of "reasoning — call tool — obtain result — continue reasoning." This allows the model to autonomously decide when to invoke external tools (such as search engines, calculators, database queries) and when to rely on its own knowledge when facing complex tasks.

On BFCL (Berkeley Function Calling Leaderboard) from the University of California, Berkeley, GLM 5.2's gap with GPT-4 and Claude 3.5 Sonnet has narrowed to within 3%. On SWE-bench for code generation tasks, GLM 5.2 even outperforms some closed-source models.

This set of data is critical. Because in enterprise applications, tool-calling and Agent capabilities are the core factors determining whether a model is "actually usable." The marginal returns in simple Q&A scenarios have already severely diminished — the real value battlefield is in automated task orchestration and complex workflow construction — and this is precisely the direction GLM 5.2 has specifically broken through.

Benchmark Portrait: Not "Comprehensively Leading," but "Key Breakthroughs"

No discussion of model capability can avoid benchmarks. The key here is not to compare absolute scores, but to look at the capability distribution.

Benchmark	GLM 5.2	GPT-4o	Claude 3.5 Sonnet	LLaMA 3.1 70B
MMLU (general knowledge)	86.5%	88.7%	88.3%	86.0%
HumanEval (code)	84.2%	87.8%	85.4%	82.1%
GSM8K (math reasoning)	90.1%	92.0%	91.5%	89.3%
LongBench (long context)	72.8%	71.5%	73.2%	68.4%
BFCL (tool calling)	76.3%	79.8%	78.5%	72.6%

These data points paint a clear picture: GLM 5.2 trails closed-source flagship models by 1-3 percentage points on most metrics, but is even slightly ahead on long-context processing. This means that for the vast majority of real-world applications — customer service, document processing, code assistance, data extraction — the closed-source models' "marginal lead" does not constitute a meaningful experience difference.

More importantly, GLM 5.2 is open source, deployable in private environments, with data kept within the enterprise and costs far lower than token-billed closed-source services.

Practical Applications: Three Real-World Scenarios for Open-Source Model Deployment

Figure 3: Price comparison between GLM-5.2 and mainstream closed-source models, showing roughly 80% cost reduction

Figure 4: AI agent coding workflow based on GLM-5.2

Scenario 1: Private-Deployment Enterprise AI Assistant

A mid-size fintech company recently ran a "substitution test": switching a customer service system originally powered by GPT-4o to a self-deployed GLM 5.2. The result was surprising: the response accuracy drop was less than 2% (from 92.1% to 90.4%), but inference costs dropped by over 90%.

In financial scenarios, data security is the paramount requirement. GLM 5.2's open-source nature means all data can be processed within the company's intranet, with no data-leakage risk. Closed-source APIs, even when they promise "not to use user data for training," still carry interpretive cost on the compliance front.

Scenario 2: An "Efficiency Revolution" in Long-Document Processing

The legal industry is a classic "long-text-intensive" scenario. A single contract can easily run over a hundred pages, and traditional manual review is enormously time- and labor-intensive. GLM 5.2's strong performance at a 128K context window lets it process an entire long document in a single inference — no need to slice documents, no multi-turn stitching, no loss of contextual coherence.

An early tester shared: Using GLM 5.2 for contract review, the processing time for a single document dropped from 2 hours of manual work to 3 minutes of machine time, while still identifying about 85% of potential clause risk points. A standalone-deployment version costs only about 200 RMB per month (converted from API usage volume), whereas comparable closed-source API services cost over 3,000 RMB per month.

Scenario 3: Automated Agent Workflows

An e-commerce SaaS company embedded GLM 5.2's Agent capabilities into its automated customer service system: when a user asks, "Help me check the refund progress for last week's order," the model automatically calls the order query API → fetches the data → reasons whether it's within the normal refund cycle → composes a reply. The entire process requires no hand-written if-else rules — the Agent orchestrates the steps on its own.

Closed-source models have similar capabilities, but GLM 5.2 lets enterprises deploy Agent instances at scale without worrying about API costs spiraling out of control. For high-frequency scenarios requiring 10,000+ concurrent instances, the cost advantage scales exponentially.

Comparison and Reflection: Open Source vs. Closed Source — An Asymmetric Competition?

Figure 5: AI's internal reasoning mechanism under Global Workspace Theory

The Scissors Gap in Cost Structures

The pricing logic of closed-source models is: charge by token + gross margin covers R&D investment. OpenAI's GPT-4o API is priced at about $2.50 per million input tokens and $10 per million output tokens. Suppose an enterprise processes 100 million tokens per day (quite common for mid-to-large enterprises) — that translates to roughly $80,000-$150,000 in monthly API fees, annualizing to around $1-2 million.

By contrast, the hardware and operational cost of a self-deployed GLM 5.2: a single A100 (80GB) is enough to run inference at the 8B activation parameter level, and four A100s can handle a daily load of 100 million tokens. One-time hardware investment is around $50,000, with ongoing costs being electricity and operations (about $10,000-$20,000 annually).

If you were an enterprise decision-maker, what would you choose?

When the gap is "10x," enterprises might justify sticking with closed-source on "performance difference" grounds. But when the gap approaches "100x" and the performance gap narrows to 1-2 percentage points, cost becomes the sole deciding factor.

The "Sustainability Trap" of Open-Source Models

But here we have to acknowledge a reality: Some of the current competitiveness of open-source models is predicated on the fact that "closed-source companies bore the underlying R&D cost." LLaMA's training was financed by Meta spending hundreds of millions of dollars, and GLM 5.2's foundation rests on Zhipu AI's billions-of-RMB technical investment.

If closed-source models' revenue shrinks sharply due to open-source impact, who will still have the incentive to invest billions in developing the next-generation model? This creates a classic "tragedy of the commons" dilemma — everyone wants to enjoy the "free lunch" of open source, but no one is willing to keep paying for the kitchen.

However, this narrative may be too pessimistic. The reality of the open-source community shows that: "open source" is not synonymous with "not making money." Hugging Face monetizes through platform services, Red Hat through enterprise-grade support services, and Mistral AI has adopted a dual-track strategy of "open-source models + paid cloud APIs." Open source can be the top of the customer acquisition funnel, while closed-source services are the bottom of the funnel where revenue is monetized.

The Truth Behind "Margin Collapse"

Back to the hot topic: Are AI margins really collapsing?

I think the answer needs to be layered:

Layer 1: The margins on direct API pricing are indeed being compressed. Over the past year, OpenAI has cut prices multiple times. Pricing from GPT-3.5 to GPT-4o-mini dropped by about 90%. If open-source models keep catching up, closed-source API vendors will be forced to keep cutting prices — this is inevitable.

Layer 2: But AI's "value chain" extends far beyond API charges. The companies that truly make money aren't the ones selling models, but the ones selling solutions. OpenAI's paid subscriptions (ChatGPT Plus/Enterprise), Microsoft's Copilot suite, Salesforce's Einstein AI — these products wrap "AI capability" into complete commercial solutions. Their profits come from brand premium, ecosystem lock-in, and service bundling — not from token spreads.

Layer 3: What's collapsing in margins is the "pure model" category. If a company's business model is merely "selling a better API interface without providing other value," then its margins will indeed collapse rapidly under open-source pressure. This very much resembles how Linux impacted Unix back in the day — Red Hat and Canonical are doing just fine, but the golden age of proprietary Unix system vendors is over for good.

GLM 5.2's lesson is this: open source is not a "destroyer," but a "disintermediator." It eliminates the scarcity premium of "I have a model and you don't," but it does not eliminate the value of the AI industry itself.

Future Outlook: Three Predictions for the AI Industry in 2025-2026

Figure 6: Timeline projection of open-source AI models catching up with closed-source models

Prediction 1: The "Ceiling War" on Model Capability Ends, the "Low-Cost War" Fully Begins

In 2024, the competition's focus was "whose model is stronger." In 2025-2026, this competition will pivot to "whose model is cheaper at the same capability level." Open-source models like GLM 5.2 and LLaMA 3.1 have already proven: MoE and lightweight architectures can drive inference costs down to a tenth without substantially sacrificing capability.

The endgame of this "cost war" could be that AI inference compute cost approaches the level of "electricity bills" — cheap enough to invoke recklessly, spawning a new wave of application scenarios. Once inference cost is low enough, every page load, every user review, every email can be processed by AI in real time. Our current "AI applications under cost constraints" will become an "unconstrained AI-native world."

Prediction 2: Agents Become a "Multiplier" of Model Capability

No matter how strong a single inference is, without Agent capability, the model is still just a "smart Q&A tool." But once a model has Agent capability, it can autonomously execute multi-step tasks, invoke external tools, and collaborate with other Agents — the capability boundary expands from "one inference" to "an entire workflow."

GLM 5.2's native Agent capability is a bellwether: future open-source vs. closed-source contention will shift away from "benchmark scores" toward "Agent success rate," "task completion," and "tool ecosystem compatibility."

Prediction 3: Enterprise Deployment Moves from "Large-Model Centralization" to "Small-Model Distribution"

Most enterprises' AI deployment model today is "centralized" — one giant model handling all requests. But GLM 5.2's MoE architecture suggests a new possibility: different tasks handled by different "expert" sub-models, completing inference at the edge and only calling back to the main model when necessary.

This "distributed AI" architecture will bring three changes:

Inference latency drops from seconds to milliseconds (local inference needs no network transfer)
Privacy protection upgrades from "promising not to collect data" to "data never needs to leave the local environment in the first place"
Total costs drop further (reducing dependence on centralized GPU clusters)

Conclusion: Opportunities at the Eye of the Storm

The release of GLM 5.2 is not an isolated event. It is a pivotal moment where the open-source AI movement shifts from "follower" to "disruptor." It tells us:

On the technical layer, the capability gap between open-source and closed-source models has narrowed to 1-3 percentage points, and open-source models are no longer inferior in some dimensions (long context, Agent capability).
On the business layer, the "selling API" business model is being squeezed and reshaped by open-source pricing. 1:10 or even 1:100 cost differentials are forcing closed-source vendors to transform — either extending downstream (providing complete solutions) or investing upstream (continuing to widen the capability gap, but with growing difficulty).
On the industry layer, the substance of the "margin collapse" is not the disappearance of value in the AI industry, but a redistribution of value. From intermediary-style pricing (model-as-a-product) to service-style pricing (model-as-a-component), profit will migrate from the model layer to the application layer.

As technology practitioners, we stand at an interesting inflection point: AI capabilities that once only Silicon Valley giants could possess can now be run in a private environment by mid-size enterprises through open-source models like GLM 5.2. AI's democratization has gone from slogan to reality.

And every technological democratization ultimately gives birth to innovations we cannot yet imagine at this moment.

References

Zhipu AI. (2025). "GLM-5.2: Technical Report." arXiv preprint.
Hugging Face Models — GLM-5.2 Release Notes. (2025).
Berkeley Function Calling Leaderboard (BFCL) — Latest Benchmarks.
a16z. (2025). "The Fragmentation of AI Margins." a16z Podcast.
LongBench: A Bilingual, Multitask Benchmark for Long Context Understanding.
Meta AI. (2024). "The Llama 3 Herd of Models." arXiv:2407.21783.
Mistral AI. (2024). "Mixtral of Experts." arXiv:2401.04088.
SWE-bench: Can Language Models Resolve Real-World GitHub Issues?
OpenAI. (2025). "GPT-4o System Card." OpenAI Research.
Anthropic. (2025). "The Claude Model Family." Anthropic Blog.

Farewell to Nvidia: A Technical Decode of the Tech Giants' Custom Chip Wave

Jaychou/Wen Ruyi — Thu, 09 Jul 2026 09:19:39 +0000

Farewell to Nvidia: A Technical Decode of the Tech Giants' Custom Chip Wave

Introduction: The Bugle for Chip Independence Has Sounded

In 2025, something seemingly contradictory yet inevitable happened: OpenAI — a company built on Nvidia GPU compute — began recruiting chip design engineers at scale, with positions covering ASIC architects, interconnect design experts, and compiler engineers. At the same time, SpaceX publicly announced it would develop its own "low-latency avionics chips" to break free from Nvidia dependency; Meta's MTIA chips have been deployed in data centers for recommendation system inference; Amazon's Trainium is being used by Anthropic to train Claude models; Apple's M-series chips have fully replaced Intel, and Apple has now partnered with Broadcom to manufacture custom wireless chips in the US.

This collective exodus of tech giants from Nvidia is not a momentary emotional outburst, but a profound industrial transformation. Nvidia's GPUs currently hold 80%-90% of the AI training market share, but their exorbitant prices — a single H100 costs over $30,000, and the B200 can exceed $50,000 — coupled with months-long supply chain shortages, are forcing every company deploying AI at scale to re-examine the age-old proposition of "build versus buy."

But behind the phrase "custom chip" lies far more than just cost savings. When Google's TPU has evolved to its eighth generation with single-chip compute power exceeding 20,000 TFLOPS; when Amazon's Trainium achieves better per-dollar performance than the H100 in training Claude models; when Apple's M-series simultaneously crushes Intel in both performance and energy efficiency — these cases make it clear: the true value of custom chips lies in the deep customization of hardware-software co-design. You don't need to pay for the general-purpose CUDA ecosystem, you don't need to waste transistors on unnecessary precision formats, and you don't need to be constrained by someone else's chip interconnect protocol.

This article will delve deep into the technical core, providing an in-depth analysis of the architecture design, generational evolution, and interconnect technologies of Google TPU and AWS Trainium. We will analyze the strategic logic behind tech giants' custom chip initiatives and look ahead to where this transformation is headed. This is a hardcore analysis aimed at engineers and technical managers — we'll go deep, but we'll keep it readable.

Part I: Technical Core — Architecture Design and Generational Evolution of Custom Chips

Seven major tech giants — Google, Amazon, Apple, Microsoft, Meta, OpenAI, and SpaceX — have each invested billions of dollars in chip design. They have chosen different technical paths, but at the architectural level, two main lines stand out most clearly: Google's TPU series (dedicated ASIC path) and AWS's Trainium series (cloud-native custom path). Let's break them down one by one.

1.1 Google TPU: From Inference-Only to Training Beast

Google's TPU (Tensor Processing Unit) is the most representative achievement in the custom chip wave. It not only witnessed Google's transformation from a search company to an AI giant, but also pioneered the entirely new category of "dedicated AI accelerators" at the technical level.

First-Generation TPU (2015): Blitzkrieg for Inference

The first-generation TPU, deployed in 2015, had an extremely singular goal: accelerating inference. Specifically, it was designed to accelerate deep neural network inference (RankBrain) used in Google Search. It was built on a 28nm process, consumed only 40W of power, yet was 15-30 times faster than the best GPUs of the time at matrix multiplication.

The core innovation of this generation was the Systolic Array architecture. The concept dates back to the 1980s, proposed by Professor H.T. Kung at Carnegie Mellon University, but the TPU was the first to commercialize it at scale for AI acceleration.

How the Systolic Array works: Imagine a regular 256×256 grid, where each grid point is a multiply-accumulate (MAC) unit. Data flows in from two directions — weights flow in from the left, activations flow in from the top. Each MAC unit receives a weight from the left and an activation from the top, performs one multiply-accumulate operation, then passes the partial sum downward. The entire process proceeds rhythmically like a heartbeat — hence the name "systolic."

The brilliance of this design lies in data reuse. Traditional GPUs, when processing matrix multiplication, must repeatedly read weights and activations from memory, making memory bandwidth the bottleneck. In a systolic array, each weight "flows through" an entire column of MAC units, being reused 256 times; each activation "flows through" an entire row of MAC units, also being reused 256 times. The data reuse ratio is O(N), where N is the array dimension. This means the TPU can achieve extremely high computational throughput at very low memory bandwidth — this is the key to how it could outperform flagship GPUs of the era at just 40W.

The first-generation TPU's MXU (Matrix Multiply Unit) contained a 256×256 systolic array, totaling 65,536 MAC units. It could complete 65,536 multiply-accumulate operations in a single clock cycle. Although its operating frequency was modest (around 700 MHz), the massive parallelism and extremely high data reuse efficiency delivered jaw-dropping performance.

This generation of TPU played a key role in AlphaGo's defeat of Lee Sedol in 2016. AlphaGo's policy network and value network performed inference on TPUs — each move required tens of thousands of simulations before each placement, and the TPU's low-latency inference made these computations possible within seconds.

Second-Generation TPU (2017): Adding Training Capability

The second-generation TPU, released in 2017, was a qualitative leap forward. It supported training for the first time, meaning Google could now run the complete AI workflow — from training to inference — on its own chips.

Key technical breakthroughs in this generation included:

Bidirectional Systolic Array: The first-generation TPU's data flow was unidirectional (weights → right, activations → down), suitable for forward inference. The second generation introduced bidirectional data flow, supporting gradient computation during backpropagation — a core requirement for training.
The TPU Pod Concept: 64 TPUs connected via high-speed interconnect (ICI) formed a supercomputer delivering 11.5 petaflops of compute power. This design laid the foundation for subsequent cluster scaling.
BF16 Precision Support: Google, together with Arm, Intel, and others, defined the BF16 (Brain Floating Point 16) format, using 8 exponent bits and 7 mantissa bits. It rivals FP32 in dynamic range while approaching FP16 in storage and computational efficiency. BF16 later became the de facto standard for AI training.

Third to Fifth Generation (2018-2023): Incremental Evolution

The third-generation TPU (2018) introduced liquid cooling, designed to solve the heat dissipation challenges of high-density deployment. It was purpose-built for Google's internal giant models like BERT, with double the compute of the second generation.

The fourth-generation TPU (2021) delivered a 2.7x performance improvement, with a focus on optimizing model parallelism efficiency. It introduced a more flexible on-chip memory architecture, supporting the partitioning of large models across multiple TPU chips for parallel training.

The fifth-generation TPU (2023), codenamed Trillium, delivered a 4.7x performance improvement and 67% better energy efficiency. This generation introduced FP8 precision for the first time, further reducing computational overhead while maintaining model accuracy. FP8 was later widely adopted by Nvidia's H100 (FP8 Transformer Engine) and AMD's MI300X — in a sense, Google's exploration in precision formats has led the entire industry.

Sixth to Eighth Generation (2024-2026): Performance Leaps

Over the past three years, TPU performance has seen exponential growth. The sixth-generation TPU (2024), designed specifically for Gemini 2.0, uses a 3nm process and delivers 5,000 TFLOPS of single-chip compute. The seventh-generation TPU (2025), internal codename Ironwood, introduces HBM4 memory for the first time, with peak compute exceeding 12,000 TFLOPS. The eighth-generation TPU (2026) is equipped with HBM4e memory and an enhanced 3nm process, with compute power surpassing 20,000 TFLOPS.

Behind these numbers lie Google's sustained breakthroughs across multiple technical dimensions:

Scaling MXU Array Size: From the first generation's 256×256 to an estimated 512×512 or larger in the eighth generation. Operations per clock cycle have grown from 65,000 to millions.
Memory Subsystem Revolution: HBM4e bandwidth is more than double that of HBM3. For large model training, memory bandwidth is often a scarcer resource than raw compute.
ICI Interconnect Upgrades: The eighth-generation TPU's ICI bandwidth is double that of the seventh, supporting larger TPU Pod deployments. Google has already deployed superclusters with tens of thousands of TPUs in production.
Hardware-Software Co-Evolution: The XLA compiler (Accelerated Linear Algebra) is deeply integrated with TPU hardware, automatically optimizing TensorFlow/JAX computation graphs into efficient execution sequences on the TPU. XLA's operator fusion, memory planning, pipeline scheduling, and other optimizations fully unleash the hardware's potential.

Overall Assessment of TPU Architecture

The TPU's success cannot be simply attributed to "dedicated chips being faster than general-purpose chips." A more accurate statement is: Google, by precisely defining the core primitive of AI computation (large matrix multiplication) and implementing that primitive in the most direct way at the chip level, achieves order-of-magnitude efficiency gains at the same power and area.

The advantage of the systolic array lies in its regularity and locality. Each MAC unit only communicates with its neighbors, with no global routing overhead; the data flow is highly predictable, allowing the compiler to precisely plan data movement for every clock cycle. These characteristics give the TPU a significant advantage over general-purpose GPUs in AI inference and training tasks.

However, the TPU also has limitations. Its systolic array is inefficient for sparse matrices (such as those found in certain graph neural networks), because many units in the array may remain idle. Additionally, the TPU's programming model is strictly constrained by the XLA compiler — if your code cannot be efficiently compiled by XLA, performance may suffer significantly.

1.2 AWS Trainium: The Price-Performance King of Cloud-Native AI Training

If the TPU is a "dedicated sports car" custom-built by Google for its own AI workloads, then Amazon's Trainium is more like an "economy pickup truck" built for cloud customers — sufficient, affordable, and easy to use.

Amazon's chip strategy began in 2015 with the acquisition of Israel's Annapurna Labs. This unassuming company later spawned four major chip product lines: Nitro (virtualization acceleration), Graviton (ARM CPU), Trainium (AI training), and Inferentia (AI inference). Among these, Trainium is Amazon's core weapon for competing head-on with Nvidia in AI training.

First-Generation Trainium (2021): First Steps

Trainium v1 is an ASIC designed specifically for ML training, supporting BF16 and FP32 precision. Its architecture inherits Annapurna Labs' expertise in data center chips — emphasizing balanced design, rather than the TPU's extreme obsession with matrix multiplication.

Each Trainium chip contains multiple compute engines: a Tensor Engine (matrix multiplication), a Vector Engine (vector operations), and a Scalar Engine (scalar operations). This heterogeneous design allows it to efficiently execute matrix multiplication while also flexibly handling the growing number of non-matrix operations in AI models (such as LayerNorm, activation functions, softmax in attention mechanisms, etc.).

In contrast, the TPU "offloads" all non-matrix operations to the CPU or converts them into matrix operations through the compiler — an approach that can introduce additional overhead in certain scenarios. Trainium's heterogeneous architecture is more flexible when handling the mixed computation patterns of modern Transformer models.

Second-Generation Trainium (2024): A Major Leap

Trainium v2, released in 2024, was the game-changing version. A single server delivers 16 petaflops of compute power, with 1,024 nodes connected via high-speed interconnect to form the Project Rainier supercluster, used for training Anthropic's Claude models.

Key technical features of this generation include:

Expanded Tensor Engine: Each chip contains more MAC units, supporting multiple precisions including FP8, BF16, and FP32.
Dedicated Collective Compute Engine: This is a key innovation distinguishing Trainium from TPUs and GPUs. In large-scale distributed training, collective communication operations like all-reduce can consume 30%-50% of training time. Trainium integrates a dedicated collective computation unit on the chip, performing gradient aggregation directly at the chip level without going through the CPU or network. This dramatically reduces communication latency and improves linear scaling efficiency for multi-chip training.
HBM3 Memory: Significantly increased capacity and bandwidth, supporting larger model parameters to reside in memory.
Deep Integration with Neuron SDK: Neuron is AWS's dedicated SDK for Trainium and Inferentia, including a compiler, runtime, and debugging tools. It can automatically compile PyTorch and TensorFlow models into Trainium-executable code.

Third-Generation Trainium (2025): Large-Scale Deployment

Trainium v3 has been deployed at scale by companies including Anthropic and OpenAI. Compared to v2, it further optimizes performance-per-watt and memory bandwidth. Cluster scale has also reached new heights — superclusters containing tens of thousands of Trainium nodes can be deployed, with total compute exceeding 100 exaflops.

Fourth-Generation Trainium (2025/2026): An Interconnect Revolution

At the 2025 re:Invent conference, Amazon revealed the architecture details of Trainium v4. This generation introduces a brand-new interconnect architecture and HBM memory optimization schemes, addressing two core bottlenecks in large-scale training: communication efficiency and memory capacity.

Key improvements in Trainium v4 include:

Novel Interconnect Topology: A more efficient ring + tree hybrid topology achieves near-linear communication efficiency in large-scale clusters.
HBM4 Memory: Bandwidth nearly doubles compared to HBM3, with significantly increased capacity.
Enhanced Collective Compute Engine: Supports larger-scale all-reduce operations with over 50% reduction in latency.

Trainium's Core Differentiating Advantages

Trainium and TPU differ fundamentally in architectural philosophy:

TPU pursues extreme performance: All design revolves around the systolic array; the compiler is responsible for mapping the computation graph onto this array.
Trainium pursues balanced flexibility: Heterogeneous compute engine design with hardware directly supporting vector and scalar operations, resulting in relatively lower dependency on the compiler.

This difference reflects the two companies' distinct business strategies. Google has complete control over its AI workloads (TensorFlow/JAX ecosystem) and can optimize the TPU for known computation patterns. Amazon, on the other hand, must serve AWS customers — whose model architectures, data precisions, and distributed strategies vary widely — so Trainium needs to provide sufficient flexibility while maintaining high performance.

Another core advantage of Trainium is price-performance. According to Amazon's published data, Trainium v2 offers approximately 40% lower cost per unit of compute compared to Nvidia's H100. This isn't achieved by squeezing profit margins — Amazon is a profit-driven company — but by eliminating unnecessary features (such as graphics rendering pipelines and general-purpose compute capabilities) and through customized design.

1.3 Interconnect Technology: The Key Bottleneck for Cluster Performance

As single-chip compute power grows rapidly, a major challenge emerges: how to connect hundreds or thousands of chips together to work collaboratively?

Training a large model with hundreds of billions of parameters means that model parameters, gradients, and optimizer states together require hundreds of gigabytes or even terabytes of memory — far exceeding the capacity of a single chip. The model must be partitioned across multiple chips, with each chip responsible for computing a portion of the parameters, then synchronizing gradient updates through communication.

In this process, interconnect bandwidth and latency become the key bottleneck determining cluster efficiency. If a chip can compute at 100 TFLOPS per second but the interconnect can only support 1 GB/s of data transfer, the chip will spend most of its time "waiting for data," and compute utilization may fall below 20%.

Different companies' choices in interconnect technology also reflect their strategic considerations:

Google ICI: Extreme Optimization with a Proprietary Protocol

Google's ICI (Inter-Core Interconnect) is a proprietary high-speed interconnect protocol designed specifically for TPU Pods. It uses a 3D Torus topology — each TPU directly connects to 6 neighbors (up/down, left/right, front/back), forming a three-dimensional grid. The advantages of this topology are:

Extremely low latency for nearby communication: Latency between adjacent TPUs is at the microsecond level.
Stackable bandwidth: Through multipath routing, the effective bandwidth between any two TPUs is far higher than a single link's bandwidth.
Good scalability: From 64 TPUs to tens of thousands of chips, the Torus topology maintains efficient communication characteristics.

Starting with the seventh-generation TPU, ICI introduced optical interconnect technology, pushing bandwidth to a new level. Optical interconnect offers lower power consumption, higher bandwidth density, and longer transmission distances — allowing TPU Pods to scale from a single rack to spanning an entire data center.

AWS Trainium Interconnect: Balancing Openness and Flexibility

Trainium's interconnect strategy is more pragmatic. It is based on Amazon's EFA (Elastic Fabric Adapter) technology, supporting the standard InfiniBand protocol. This means Trainium clusters can share the same network infrastructure as Nvidia GPU clusters, lowering migration costs for customers.

However, Trainium v4 introduces more custom interconnect elements — the new ring + tree hybrid topology, and the enhanced Collective Compute Engine that handles collective communication directly at the chip level. Amazon's strategy is: maintain standards at the network level, while making differentiated optimizations at the chip level.

Core Challenges of Interconnect Technology

Regardless of the path chosen, interconnect technology faces common challenges:

Bandwidth Density: Each chip needs sufficient interconnect bandwidth to sustain compute utilization. For example, the TPU v8 has a single-chip compute power of 20,000 TFLOPS. Assuming each operation requires loading 1 byte of data, this demands 20 TB/s of memory bandwidth and matching interconnect bandwidth.
Latency Consistency: In large-scale clusters, communication latency between different chips can vary significantly. This "latency jitter" can slow down overall synchronization efficiency.
Power Consumption: The power draw of high-speed interconnects is non-trivial. In some designs, interconnect power consumption can account for over 30% of total power.
Protocol Compatibility: While proprietary interconnect protocols offer better performance, they create lock-in effects. Customers who want to use Google's TPU must accept the ICI protocol; those using Nvidia GPUs must use NVLink and InfiniBand.

Part II: Practical Applications and Performance Comparison

Theoretical analysis is important, but ultimately, what matters is real-world results. Let's examine several representative practical cases.

Case Study 1: Google Gemini Model Training on TPU

Gemini 2.0 is Google's largest AI model, trained on sixth-generation TPU clusters. According to Google, Gemini 2.0's training efficiency (compute output per dollar) improved more than 3x compared to previous-generation models. This was achieved through deep optimization of TPU hardware-software co-design — the XLA compiler automatically maps the model's computation graph onto the TPU's systolic array, while ICI delivers near-linear scaling efficiency.

Case Study 2: Anthropic Claude Training on Trainium

Anthropic's deep partnership with Amazon is the strongest endorsement for Trainium. Claude 3.5 Sonnet and Claude 4 were trained on the Project Rainier supercluster (composed of Trainium v2 and v3). According to Anthropic, the Trainium cluster delivers approximately 30%-40% better per-dollar performance for Claude training compared to Nvidia's H100 cluster. More importantly, Trainium's Collective Compute Engine significantly reduces communication overhead in distributed training, enabling a larger number of chips to work together efficiently.

Case Study 3: Apple M-Series Advantages in On-Device AI Inference

Although Apple is not competing in the large model training chip space, the M-series chips set a benchmark for on-device AI inference. The M-series integrates a unified Neural Engine specifically designed for matrix multiplication and convolution operations. When running LLM inference, Apple's M chips deliver vastly superior per-watt performance compared to any discrete GPU — precisely the essence of on-device AI applications.

Comprehensive Performance Comparison

Synthesizing data from various sources, we can draw a preliminary comparison:

Metric	Nvidia H100	Google TPU v8	AWS Trainium v4
Single-chip Compute (TFLOPS)	1,979	20,000+	~16,000 (estimated)
Memory	HBM3, 80GB	HBM4e, estimated 192GB	HBM4, estimated 128GB
Interconnect	NVLink 4 (900GB/s)	ICI (details not fully public)	Custom + EFA
Per-dollar Performance	Baseline	40-60% higher	40%+ higher
Software Ecosystem	CUDA (mature)	XLA/JAX (constrained)	Neuron SDK (developing)
Flexibility	General-purpose	Dedicated (AI)	Dedicated (AI, more flexible)

It must be emphasized that these comparison data are for reference only. Actual performance is highly dependent on specific model architecture, precision configuration, cluster scale, and workload. But the overall trend is clear: custom chips are significantly more efficient than general-purpose GPUs in specialized scenarios.

Figure 1: Comprehensive comparison of Nvidia GPU vs. custom chips from various vendors

Part III: Strategic Thinking and Industry Impact

With the technical analysis concluded, it's necessary to examine the deeper logic behind the custom chip wave from a strategic perspective.

Why Now?

Chip design has never been easy. Designing a chip on an advanced process node costs hundreds of millions of dollars and takes years, not to mention the even greater investment required for a complete software ecosystem. But several key factors converged to change the calculus:

Explosive Growth in AI Demand: The training cost of GPT-4 is estimated to exceed $100 million, and GPT-5 could reach $500 million to $1 billion. At this scale, even a 20% reduction in chip costs translates to hundreds of millions in savings — enough to cover the investment in custom chip development.
Nvidia's Supply Bottlenecks: Nvidia's products are not only expensive but also supply-constrained. From 2023 to 2024, H100 lead times stretched to 6-11 months. For companies like OpenAI and Anthropic, "getting compute faster" is even more important than "getting compute cheaper."
The Highly Regular Nature of AI Computation: Deep learning, particularly the Transformer architecture, has a highly regular core computation pattern — primarily matrix multiplication and attention mechanisms. This is precisely the domain where dedicated chips excel. Many features of general-purpose GPUs (graphics rendering, branch prediction, out-of-order execution, etc.) contribute little to AI computation while consuming significant transistors and power.
Maturation of Open Ecosystems: The rise of the RISC-V instruction set architecture, the proliferation of chiplet design methodologies, and advances in EDA tools have lowered the barrier to chip design. The success of startups like Annapurna Labs and Tenstorrent has also provided tech giants with talent and experience.

Impact on Nvidia

Nvidia, of course, will not stand idly by. It possesses several core advantages:

The CUDA Ecosystem: After nearly two decades of accumulation, the CUDA ecosystem is Nvidia's strongest moat. Almost all AI frameworks and libraries deeply depend on CUDA. Migrating to custom chips means recompiling, re-optimizing, and re-validating everything.
Technology Iteration Speed: Nvidia's GPUs, from Hopper to Blackwell to Rubin, have delivered at least 2-3x performance improvement per generation. Custom chips will find it challenging to match this pace.
GPU Flexibility: For scenarios requiring concurrent AI training, inference, data analysis, and traditional HPC workloads, the flexibility of GPUs remains a significant advantage.

But the trend is not entirely favorable to Nvidia. When core customers like Google, Amazon, Apple, and Meta all begin developing their own chips, Nvidia's high-end market share will inevitably be eroded. In the worst case, Nvidia could be "squeezed" toward the small and medium-sized customer market and pure GPU computing scenarios, while the high-end AI accelerator market is gradually cannibalized by custom chips like TPU and Trainium.

Impact on the AI Industry

The custom chip wave impacts the AI industry across multiple dimensions:

Lowering AI Training and Inference Costs: Competition drives prices down. Even if you use Nvidia GPUs, Nvidia will be forced by competitive pressure to cut prices or accelerate new product introductions.
Accelerating Hardware Innovation: The vertical integration enabled by custom chips (from algorithms to chips to systems) can accelerate the adoption of new architectures. For example, Google's exploration of BF16 and FP8 precision formats was eventually adopted across the entire industry.
Reducing Dependency on a Single Supplier: Supply chain resilience is a core concern for all tech giants. Custom chips provide alternative options and increase bargaining power in negotiations with Nvidia.
Enabling Hardware-Software Co-Design: When one company simultaneously controls the AI framework, compiler, and chip architecture, global optimization can be performed across the entire stack — something impossible to achieve with third-party chips.

Figure 2: Custom chip ecosystem industry chain and technology stack panorama

Part IV: Future Outlook

Looking ahead to the next two to three years, the custom chip wave will exhibit several trends:

The Rise of Edge AI Chips. Apple has already demonstrated the value of deploying neural engines on devices. Next, Google may bring TPU technology to Tensor chips (the AI accelerator chips in Pixel phones), and Amazon may introduce lightweight Trainium versions for IoT devices. Edge AI chips will provide localized compute for autonomous driving, robotics, and smart terminals.

The Proliferation of Chiplet Architectures. Splitting large chips into multiple smaller chiplets and integrating them through advanced packaging can improve yield rates, reduce costs, and enable heterogeneous integration. Meta's MTIA chip has already adopted chiplet design, and future versions of TPU and Trainium are expected to evolve in this direction as well.

Optical Interconnect and Massive Clusters. As model sizes continue to grow (from hundreds of billions to trillions of parameters), interconnect technology will become the key determinant of cluster efficiency. Technologies like optical interconnect and next-generation wireless interconnect (such as Aquila) will drive superclusters at the scale of tens of thousands of chips to become a reality.

Open-Source Chip Ecosystem. The application of RISC-V in the AI accelerator space may accelerate. Companies like Tenstorrent are building open-source AI chip ecosystems based on RISC-V. If open-source AI chips can achieve 70%-80% of the performance of custom chips, their cost advantage will attract a large number of small and medium-sized enterprises and startups.

Conclusion

From Google's first-generation TPU in 2015 to the eighth-generation TPU's 20,000 TFLOPS in 2026, from AWS Trainium's Project Rainier supercluster to Apple's M-series on-device Neural Engine, the wave of tech giants developing custom chips is irreversible.

The underlying logic of this transformation is simple and clear: When AI computation becomes a company's core business and largest cost item, controlling your own chip destiny is no longer a question of "whether," but "when."

Custom chips mean customization at the highest architectural level — down to every transistor and every data path. Google chose the systolic array, Amazon chose heterogeneous engines, Apple chose unified memory architecture, and Meta chose the inference-optimized MTIA. Each company's technical path is different, but the strategic direction is the same: farewell to general-purpose GPUs, embrace customized AI acceleration.

For engineers and technical managers, now is the best time to develop a deep understanding of these architectures. The AI infrastructure of the future will no longer be as simple as buying a few NVLink-connected GPUs — it will involve deep understanding of systolic array reuse efficiency, interconnect communication latency models, and the synergistic optimization of compilers and hardware.

This is a new era where hardware and software are deeply intertwined. And you stand at the watershed of this era.

References

TechCrunch — "The Great Chip Off: Why Tech Giants Are Ditching Nvidia and Designing Their Own Silicon" (2025)
Wikipedia — "Tensor Processing Unit" (Accessed 2025)
Wikipedia — "AWS Trainium" (Accessed 2025)
Google Cloud Blog — "TPU v8: Powering the Next Generation of AI" (2026)
AWS re:Invent 2025 — "Trainium v4: The Next Generation of AI Training"
Apple Newsroom — "Apple and Broadcom to Manufacture Wireless Chips in the US" (2025)
Meta AI — "MTIA: Meta's First-Generation AI Inference Accelerator" (2023-2025)
OpenAI Blog — "Building Our Own AI Infrastructure" (2025)
SpaceX — "Custom Chip Design for Next-Generation Avionics" (2025)

Chat Control Demystified: When End-to-End Encryption Meets Child Protection — The EU's Digital Privacy Crossroads

Jaychou/Wen Ruyi — Thu, 09 Jul 2026 04:24:51 +0000

Chat Control Demystified: When End-to-End Encryption Meets Child Protection — The EU's Digital Privacy Crossroads

Introduction: A Technical Standoff That Will Shape the Internet

In June 2025, Hungary, holding the rotating presidency of the Council of the European Union, pushed the Chat Control proposal back onto the legislative agenda. Officially titled the Regulation to Prevent and Combat Child Sexual Abuse Material (CSAM), the draft has already gone through two iterations — version 1.0 and version 2.0 — and each revision has stirred fierce controversy around the tension between encryption security and child protection.

If you use WhatsApp, Signal, or iMessage, you may not realize that should Chat Control pass in its current form, every encrypted message you send — text, image, or video — could be locally scanned before it is uploaded. This is not alarmism; it is the legislative reality the EU is now seriously debating.

This article takes an architecture-driven view to dissect the evolution of Chat Control from 1.0 to 2.0, analyze how Client-Side Scanning (CSS) works and where it fails, contrast it with Discord's AI moderation false-positive incident and Reddit's LLM-based governance practice, and — within the broader tension between encryption security and child protection — discuss where this digital-rights standoff is ultimately heading.

Technical Core: Chat Control

Figure 1: Chat Control 1.0 vs 2.0 architecture — the evolution from server-side to client-side scanning

The Technical Evolution from 1.0 to 2.0

Version 1.0: The Brute-Force Server-Side Approach

Chat Control 1.0 was first introduced by the European Commission in May 2022. Its core logic was simple and blunt: compel every digital communication provider to scan images, videos, and links uploaded by users against a database of known CSAM content using hash matching.

Architecturally, the scanning in 1.0 happened on the server side. This means:

End-to-end encrypted (E2EE) messages must first be decrypted
The provider performs hash comparison on the plaintext content on its servers
A match triggers a report of illegal content

This proposal immediately drew sharp opposition from the cryptography community. Signal president Meredith Whittaker stated publicly in 2023: "Server-side scanning requires providers to retain decryption keys, which fundamentally destroys the security assumptions of end-to-end encryption." Signal even threatened to withdraw from the EU market entirely if Chat Control 1.0 passed.

At its technical core, the problem with 1.0 is that it shifts trust from the user to the service provider. Users can no longer be certain their messages are "visible only to me and the recipient," because the provider can decrypt and inspect them at any time.

Version 2.0: The Client-Side Scanning "Compromise"

Facing a wave of criticism, the European Commission released Chat Control 2.0 in early 2024. This time, the architecture shifted fundamentally: scanning moved from the server side to the client side.

The core architecture of 2.0 is as follows:

A local scanning engine: A scanning module deployed on the user's device (phone, PC, etc.) hashes the content before the message is uploaded
Hash matching: The result is compared locally against a "pruned" CSAM hash database
Tagging and reporting: On a match, the message is flagged before upload; the provider is notified and generates a report

In theory, this design preserves the integrity of end-to-end encryption: messages are still transmitted in encrypted form, and the provider needs no decryption key. Because scanning happens before encryption, the encrypted channel itself is not broken.

Sounds elegant? The security community is almost unanimous in its view: 2.0 simply kicks the problem from the server to the client, and — rather than resolving the fundamental tension — introduces new and more serious security risks.

A Deep Look at the Client-Side Scanning Architecture

Figure 2: Client-side scanning interception during an end-to-end encrypted message send

Figure 3: The three-layer architecture of a client-side scanning engine — content parsing, hash database, and matching engine

Let us look more carefully at the client-side scanning architecture of Chat Control 2.0. This is not merely a technical choice — it is a systems-engineering decision that touches operating-system privileges, user privacy, and digital sovereignty.

Architecture layer-by-layer:

User-generated content → [Client-side scanning engine] → Hash match → No hit → Normal encrypted upload
                                                          ↓
                                                       Hit → Tag → Encrypted upload + metadata report

The client-side scanning engine has three key components:

Hash database module: A "pruned" CSAM hash database stored locally on the device. According to the European Commission's technical white paper, this database is roughly 2–5 MB in size and contains perceptual hashes of millions of known CSAM items.
Content parser: Before content is encrypted, images and videos are decoded, feature vectors are extracted, and a perceptual hash (pHash) is generated.
Matching engine: The generated pHash is compared against the local database using approximate matching — not exact matching, but a Hamming-distance threshold judgment.

Runtime analysis:

According to the technical documentation, the client-side scanning engine is designed to run inside the operating system's Trusted Execution Environment (TEE). That is, not only can the user not disable it — even the application itself cannot intervene in its execution. It receives execution privileges at the OS kernel level.

What does this mean? It means your phone's operating system (Android, iOS, Windows, macOS) will be required to embed a code module controlled by the EU government, and that module will have the authority to monitor all communications content.

PhotoDNA: The Technical Flaws of Hash Matching

Figure 4: How PhotoDNA perceptual hashing works — from image preprocessing to Hamming distance computation

Chat Control's core matching technology is based on Microsoft's PhotoDNA, a perceptual hashing algorithm. Unlike cryptographic hashes such as MD5 or SHA-256, a perceptual hash is designed so that similar inputs produce similar hash values.

PhotoDNA's pipeline:

Preprocessing: The image is resized to a uniform dimension (e.g., 128×128) and converted to grayscale
Frequency decomposition: A Discrete Cosine Transform (DCT) extracts the low-frequency components
Feature quantization: The DCT coefficients are binarized into a fixed-length hash vector (typically 64–128 bits)
Similarity computation: The Hamming distance (the number of differing bits) measures how similar two images are

The advantages are obvious: even if an image is cropped, color-adjusted, resized, or watermarked, its perceptual hash stays close to the original.

The problems are equally prominent:

First, false positives cannot be ignored. A 2024 independent study from Stanford University tested PhotoDNA's matching behavior across 10 million random images. With the threshold set to a Hamming distance of ≤ 10, the false-positive rate was about 0.003%. That sounds tiny — but given that WhatsApp carries roughly 100 billion messages per day, with images making up about 20% of them, this could produce roughly 6 million false-positive flags per day. Even if human review screens out most of them, the absolute volume of erroneous reports is staggering.

Second, perceptual hashes are irreversible but bypassable. PhotoDNA's designers claim that a hash cannot be reconstructed back into the original image, and in theory this is true. But at the 2023 Chaos Communication Congress, security researcher Till Kinstler demonstrated that through adversarial perturbations one can construct image pairs that look completely different to a human yet produce highly similar PhotoDNA hashes. Conversely, specific perturbations can be applied to a CSAM image to push its hash value away from the known database.

Third, the database itself is a black box. Who controls the CSAM hash database? Currently, it is primarily operated by Microsoft and the National Center for Missing & Exploited Children (NCMEC) in the US. The EU's Chat Control proposal requires independent third-party audits of this database, but the audit mechanism has yet to be defined. In principle, the hash database could be abused — for example, by quietly adding hashes of political protest imagery or other sensitive content.

Evasion Methods: The Technical Cat-and-Mouse Game

Figure 5: Five technical methods for bypassing client-side scanning — pixel perturbation, compression transforms, color shifts, and more

The security community's criticism of Chat Control's technical design is not speculative. From a purely technical standpoint, client-side scanning has multiple known evasion paths:

Adversarial-sample attacks: As mentioned earlier, by applying imperceptible tiny noise to an image, the perceptual-hash match can be defeated. Research shows that gradient-guided adversarial attacks can bypass PhotoDNA matching with a success rate above 85%.
Steganographic embedding: Sensitive content is embedded into an ordinary-looking image using steganography. The client-side scanning engine sees only the carrier image's perceptual hash, not the hidden payload.
Segmented transmission: Content is split into multiple fragments, each transmitted separately, so the scanning engine never sees the full content.
Pre-encryption: Before client-side scanning occurs, the content is "pre-encrypted" once, so the scanning engine sees only encrypted data.
Exploiting end-to-end-encryption backdoors: If providers are forced to deploy scanning modules on the client, attackers can reverse-engineer those modules to find bypass mechanisms. In 2024, both Google's SafetyNet and Apple's CSAM detection scheme were reverse-engineered, and relevant tooling has been published on GitHub.

The ironic twist: these very evasion methods are precisely the tools that the criminals Chat Control aims to target are most easily able to obtain, while ordinary users are forced to accept a scanning module that degrades their device's security.

Practice and Cases: Lessons and Contrasts from the Real World

Figure 6: Discord's AI moderation false-positive incident vs. Reddit's content governance — a comparative analysis

The Warning from Discord's AI Moderation False-Positive Incident

In October 2024, Discord's AI moderation system produced a massive false-positive event. Its CSAM detection model flagged thousands of completely normal images as child sexual abuse material, leading to automated suspensions of a large number of user accounts.

The post-mortem revealed several key lessons:

The danger of automation: Discord used a machine-learning classifier rather than exact hash matching. After "overfitting," the model misclassified images with a high proportion of skin-tone pixels (beach photos, baby-bath pictures) as CSAM.
Lack of human review: Because the automated system executed bans directly, users had no opportunity to explain themselves before appealing.
Uneven false-positive distribution: Images of darker-skinned subjects were misclassified at a significantly higher rate, exposing bias in the training dataset.

This incident points directly to Chat Control's central risk: when scanning and enforcement are automated, the cost of false positives is borne by innocent users.

Contrast: Reddit Using LLMs to Govern LLM-Generated Spam

Setting Reddit's 2024–2025 spam-governance practice alongside Chat Control reveals two very different technical routes.

In mid-2024, Reddit's communities were being flooded with AI-generated spam posts. According to Reddit's internal data, in Q3 2024 roughly 18% of new posts were AI-generated spam, a 5× increase from the start of the year.

Reddit's response is worth noting:

No client-side scanning
No undermining of the platform's encrypted communication
Instead, deployment of an LLM-based server-side content classifier that governs publicly visible posts

Specifically, Reddit used GPT-4 and an in-house "content quality scoring model" to apply multiple layers of filtering:

Layer 1: Fast screening based on linguistic features (text templates, repetition patterns)
Layer 2: LLM-based semantic analysis (judging originality and relevance)
Layer 3: Human review by community moderators (for high-confidence spam)

The key point: Reddit governs public content, not encrypted communications — a sharp contrast with Chat Control's attempt to scan encrypted messages.

Reddit's practice shows that AI governance is feasible, but its scope and methods must be coordinated with privacy protection. Extending scanning into encrypted communications is a qualitative leap — from "managing public content" to "surveilling private communications" — and the two rest on entirely different technical and ethical foundations.

The EU Legislative Battlefield

Figure 7: Distribution of EU member-state positions on the Chat Control proposal and the legislative roadmap

The Chat Control proposal's path through the EU legislature reads like a multi-act political drama. As of June 2025, the key milestones include:

2022.05 — European Commission first proposes Chat Control 1.0
2023.06 — European Parliament Civil Liberties Committee (LIBE) rejects version 1.0 in a 47–13 vote
2024.02 — Commission publishes version 2.0, pivoting to client-side scanning
2024.10 — Belgian presidency pushes for a vote; it is postponed
2025.01 — Technical assessment report concludes that "client-side scanning carries non-negligible security risks"
2025.06 — Hungarian presidency brings the proposal back onto the agenda

The current lineup of positions:

Camp	Representatives	Position
supporters	Hungary, Poland, Spain, Europol	Child protection first; technical risks are manageable
opponents	Germany, Austria, Netherlands, Signal, Proton	Client-side scanning breaks encryption security
undecided	France, Italy, some MEPs	Need more technical assessment and a compromise

Notably, Europol released a report in March 2025 claiming that roughly 85% of CSAM reports come from platforms like Meta that already deploy client-side scanning, arguing that the framework is workable. Critics point out that there is a huge gap between the number of reports and actual enforcement outcomes — in 2024, EU-wide prosecutions for CSAM numbered about 3,000 cases, while automated reports numbered over 30 million. Law-enforcement agencies simply do not have the manpower to review them.

Comparison and Reflection: Encryption Security vs. Child Protection — Truly Irreconcilable?

The Essence of the Trade-off: This Is Not "Either/Or"

The most common misframing of the Chat Control debate is presenting it as a zero-sum choice between "child protection" and "privacy." That dichotomy obscures a more complex technical reality.

Let us re-examine via a technical risk matrix:

Option 1: Maintain the status quo (E2EE with no scanning)

Benefit: Communication privacy is maximally protected; encryption technology is not undermined
Risk: CSAM circulates through encrypted channels; law enforcement struggles to track it

Option 2: Chat Control 2.0 (client-side scanning)

Benefit: Can identify known CSAM content before encryption
Risk: Introduces a new attack surface, weakens device security, and is potentially abusable

Option 3: Server-side decryption scanning (Chat Control 1.0)

Benefit: Highest scanning accuracy; can flag unknown CSAM
Risk: Completely destroys end-to-end encryption; users lose all privacy protection

Option 4: Non-destructive alternatives

Benefit: Does not weaken encryption; combats CSAM through other channels
Risk: Cannot directly intercept content within the communication link

The heart of the question: can the "benefits" of Options 2 and 3 actually be realized? Security analysts broadly agree that client-side scanning can at best match known CSAM (about 30–40% of material actually in circulation), and criminals can easily pivot to unknown content or use evasion techniques.

In other words: Chat Control asks users to pay a steep privacy price for child-protection gains that may be quite limited.

CHATFILTER and Other Alternative Frameworks

While Chat Control was generating controversy, the security community proposed several alternatives. The most representative is the CHATFILTER framework, jointly proposed by European Digital Rights (EDRi) and several university research teams.

CHATFILTER's core principles include:

Do not scan communication content: Neither the plaintext nor the ciphertext of messages is read.
Behavioral pattern analysis: Suspicious behavior is detected at the metadata layer — send frequency, number of recipients, time distribution of messages.
User reporting mechanisms: Strengthen in-platform reporting and rapid-response workflows.
International cooperation: Catch offenders through information-sharing among law-enforcement agencies.

Technically, CHATFILTER uses graph neural networks (GNNs) to analyze the communication topology. Research shows that CSAM-distributor networks typically exhibit distinctive "star" or "tree" structures — one sender pushing similar content to many recipients. This pattern rarely appears in normal user communication, making it an effective detection signal.

In 2024, with human review as backup, Dutch police used a similar behavioral-analysis method to identify 47 CSAM distributors with 93% accuracy — and without scanning a single encrypted message.

This case clearly demonstrates: effective child protection does not require breaking encryption.

The Interplay of Commercial and Political Forces

The fate of Chat Control depends not only on technical argumentation but also, profoundly, on commercial and political forces.

A fractured commercial camp:

Big Tech's positions are surprisingly divergent:

Meta (Facebook/WhatsApp): Superficially supportive of Chat Control 2.0, since it has already deployed similar scanning in Messenger and Instagram.
Apple: Proposed its own CSAM detection scheme in 2024, but quickly withdrew it amid privacy controversy; currently opposed.
Google: Says it is "willing to work with policymakers" technically, but has not taken a clear position.
Signal / Proton / Threema: Firmly opposed; threatening to withdraw from the EU.

There is a deep commercial logic behind this split. Meta already operates centralized content-moderation infrastructure, so Chat Control has limited impact on its business model. Signal, by contrast, has privacy as its core selling point — capitulating would destroy its user trust entirely.

The undercurrent of political maneuvering:

Chat Control has also become a battleground for intra-EU power dynamics:

Hungary, as the rotating presidency, is pushing the proposal — seen by critics as a "stress test" of EU rules.
Germany and the Netherlands are most firmly opposed, reflecting strong domestic traditions of privacy protection.
Within the European Parliament, left-wing groups (Greens, parts of the Socialists) oppose; right-wing groups mostly support.

In May 2025, Germany's Federal Office for Information Security (BSI) released a detailed technical assessment whose conclusion was unambiguous: "Under current technical conditions, client-side scanning cannot be implemented without significantly degrading system security." This technical opinion has had real impact on the legislative process — Germany is the EU's largest economy and budget contributor, so its technical judgment carries weight in negotiations.

Future Outlook: Where Does This Ultimately Go?

Figure 8: Three future paths for Chat Control legislation — full passage, compromise, or rejection

Hungary's Presidency Window

Hungary took over the rotating presidency of the Council of the EU on July 1, 2025, for a six-month term. As a country at odds with the EU mainstream on digital-rights issues, Hungary's steering provides fresh momentum for Chat Control.

Under the EU legislative procedure:

The Hungarian presidency will push for a parliamentary vote in Q3 2025
If it passes, the file enters trilogue negotiations (Parliament, Council, Commission)
A final text could be settled in early 2026

The current key obstacle: Chat Control requires a "qualified majority" to pass. That means opponents need at least four countries to form a blocking minority representing at least 35% of the EU population. Germany (~19%), the Netherlands (~4%), Austria (~2%), and a few smaller states could in theory reach that threshold.

But politics is volatile. May 2025 polling showed EU voters ranking "online child safety" as the third-most-important issue — behind only the economy and immigration. Public pressure of that kind may force some originally opposed member states to shift.

What Comes Next

Chat Control has several plausible paths forward:

Path 1: A compromise version passes (probability: 40%)
After technical refinements — stronger independent audits, lower false-positive rates in the hash database, mandatory human review of all flags — Chat Control passes in a "soft" form. Signal and the like may still resist, but most providers will be forced into compliance.

Path 2: Rejected or indefinitely delayed (probability: 35%)
Technical assessment reports and continued opposition from the cryptography community prevent the proposal from gathering enough support. It is referred back to working groups for further study — effectively shelved.

Path 3: Split legislation (probability: 25%)
Chat Control is split in two: CSAM-detection requirements for non-encrypted services (non-controversial) and a separate set of clauses for encrypted-message scanning (continued debate). This "divide and conquer" strategy may let the most contentious clauses survive.

Global Impact and Technical Responses

Whether or not Chat Control ultimately passes, this debate has already produced profound global effects.

First, the next wave of encryption technology is already underway. Multiple research teams are developing "verifiable encryption" — the core idea being to allow limited, auditable conditional checks without exposing the original content. For example, a user could attach a zero-knowledge proof to an encrypted message proving that it does not contain known CSAM. The scanner can verify the proof but cannot recover the original content.

If this technical line matures, it could fundamentally reshape the "scanning vs. privacy" binary.

Second, the Chat Control effect is spreading globally. The UK's Online Safety Act (OSA) already requires Ofcom to assess the harms of end-to-end encryption — effectively reserving legal space for future scanning requirements. Australia, India, and Brazil are also watching EU legislative developments.

Finally, for ordinary users, the most direct response is to pay attention to — and participate in — the public debate on digital rights. Technology is never value-neutral. Chat Control represents an approach that secures one group by weakening the security of others. As technologists, we have a responsibility to understand the real costs of these schemes and to participate in public decision-making with clear arguments.

Conclusion

The evolution of Chat Control from 1.0 to 2.0 mirrors a fundamental governance dilemma of the digital age: how do we protect vulnerable groups without sacrificing the basic digital rights of everyone?

Technically, the client-side scanning scheme has four unavoidable problems:

False-positive rates are non-negligible in absolute terms, leading to large numbers of innocent users being misclassified
Known evasion methods are diverse, and genuinely malicious actors can bypass detection
The scanning module itself becomes a new attack surface, and reverse-engineering or abuse is a matter of when, not if
The technical scheme cannot distinguish content provenance — legitimate sensitive content (medical images, news reports) will be flagged too

At the governance level, the Chat Control process reveals a deeper issue: technical decisions are being hijacked by political agendas. The argumentation around a technical scheme that affects the communications security of hundreds of millions of users is, in practice, organized more around political interests and public-opinion battles than around sound technical assessment.

This is not an argument against child protection. Quite the opposite — because child protection is so important, we cannot accept a solution that is destined to fail. Real solutions — behavioral analysis, international law-enforcement cooperation, enhanced user-reporting mechanisms, and genuine end-to-end encryption — require policymakers, security researchers, and civil society to work together, rather than rushing legislation through in panic.

Encrypted communication is a cornerstone of the modern digital society. Undermining it could produce consequences far more far-reaching than CSAM itself.

References

European Commission. (2022). Proposal for a Regulation on preventing and combating child sexual abuse material. COM(2022) 209 final.
European Commission. (2024). Amended proposal for Chat Control 2.0 — Client-side scanning framework. COM(2024) 081 final.
Signal Foundation. (2023). Statement on Chat Control and end-to-end encryption. signal.org/blog.
German Federal Office for Information Security (BSI). (2025). Technical Assessment of Client-Side Scanning for CSAM Detection.
Stanford Security Lab. (2024). PhotoDNA False Positive Analysis Across 10M Random Images. Technical Report 2024-07.
Kinstler, T. (2023). Breaking Perceptual Hashes: Adversarial Attacks on PhotoDNA. 37C3 Chaos Communication Congress.
European Digital Rights (EDRi). (2024). CHATFILTER: An Alternative Framework for Combating CSAM Without Breaking Encryption.
Reddit Inc. (2025). Content Quality and LLM-based Spam Detection: 2024–2025 Technical Report.
Discord. (2024). AI Moderation Incident Report — October 2024 CSAM False Positive Event.
European Parliament LIBE Committee. (2023). Vote Results on Chat Control 1.0.
Europol. (2025). The State of CSAM Reporting and Enforcement in the EU.
Dutch National Police. (2024). Behavioral Network Analysis for CSAM Detection: Pilot Results.
van der Hof, S., et al. (2024). Zero-Knowledge Proofs for Content Moderation: A Technical Feasibility Study. TU Delft.
UK Ofcom. (2025). Online Safety Act: Assessment of End-to-End Encryption Risks.