Meta Engineering Says GEM Doubled Training Efficiency as Its Ads Model Grew

Meta engineering has doubled GEM’s end-to-end training efficiency while increasing each run’s model computation fourfold, according to a new technical disclosure. GEM now reaches 20% to 25% Model FLOPs Utilization across several thousand current-generation GPUs.

That result matters because adding accelerators usually creates new bottlenecks. Communication expands, failures become more disruptive, and uneven workloads leave expensive hardware waiting. Meta says GEM improved efficiency while its training workload became substantially larger.

The conflict is therefore not Meta against another advertising company. It is systems engineering against brute-force GPU scaling. The company’s GEM training account presents the efficiency gain as a coordinated result across model architecture, data movement, parallelism, kernels, and reliability.

GEM, short for Generative Ads Recommendation Model, is the foundation model behind recommendations across Facebook and Instagram advertising surfaces. It learns shared patterns that smaller production models can apply when ranking ads under strict latency limits.

The model resembles a large language model in scale, but not in workload. Language models process relatively regular token sequences. Advertising systems combine irregular behavioral histories, enormous embedding tables, diverse objectives, and continuously changing data.

Meta has not released enough information for outsiders to reproduce the new result. It has not disclosed GEM’s exact GPU count, training duration, energy consumption, or absolute cost. The reported 20% to 25% MFU is therefore useful, but it is not a complete efficiency audit.

Still, the disclosure reveals an important change in recommendation engineering. Meta is treating ads ranking as a foundation-model problem, then rebuilding the training system around that decision.

Meta Engineering Moved GEM Into a New Training Class

The central change is not simply a larger GPU cluster. Meta says GEM now performs four times more model computation while using its allocated hardware about twice as efficiently.

Model FLOPs Utilization, or MFU, measures the share of theoretical accelerator throughput spent on the mathematical operations defined by a model. A 25% MFU does not mean the GPUs are idle 75% of the time. Some capacity supports communication, memory movement, data preparation, synchronization, and other necessary work.

The distinction matters at GEM’s scale. Meta describes a model containing trillions of sparse parameters and billions of dense parameters. Sparse parameters include large embedding structures, where only a relevant subset participates in each example. Dense parameters participate much more consistently.

A parameter count alone therefore says little about training cost. Two models with similar totals can have very different active computation, memory traffic, and communication patterns. GEM’s fourfold increase in training FLOPs provides a more useful indication that Meta expanded the work performed during a run.

Meta says the current system trains on several thousand latest-generation GPUs. That places GEM’s distributed training problem closer to frontier language-model infrastructure than to conventional recommendation jobs running on smaller clusters.

The company has been moving toward this point for several years. Traditional deep learning recommendation models relied heavily on manually designed features and compressed representations. Meta’s earlier sequence learning work shifted attention toward complete behavioral event streams.

That approach preserves more information about what a person did before and after an interaction. It can capture the order, timing, and context of events rather than treating behavior as a fixed collection of summary statistics.

However, longer and more varied sequences increase computational pressure. Different users produce histories with different lengths. Some examples demand far more processing than others, which creates imbalance inside batches and across GPUs.

GEM also learns across multiple surfaces and objectives. An Instagram video interaction can carry information that improves a Facebook Feed prediction. Advertiser goals can range from awareness to clicks, messages, purchases, or other conversions.

That shared learning is central to the foundation-model strategy. Instead of training every ranking system as an isolated intelligence, Meta uses GEM to develop reusable representations and predictions. Smaller value models can then absorb that knowledge for specialized production tasks.

Meta previously reported that GEM’s architecture delivered four times more advertising-performance gain for a given amount of data and compute than earlier ranking models. That is a model-quality claim, not the fourfold training-compute increase in the latest disclosure.

Keeping those figures separate is essential. One describes claimed effectiveness per unit of training input. The other describes how much mathematical work the newer training run performs.

The new efficiency result means Meta says it expanded GEM without allowing infrastructure overhead to consume the added capacity. That is the event’s real technical significance.

Why More GPUs Usually Make Efficiency Worse

Distributed training becomes a coordination problem long before it runs out of arithmetic. Every added GPU creates more opportunities for waiting, imbalance, and failure.

A training step requires accelerators to process data, exchange intermediate results, combine gradients, and update model state. If one worker falls behind, the others can reach a synchronization point and wait.

This problem becomes more severe with irregular recommendation data. User histories vary in length, while sparse feature access varies by example. Equal numbers of examples do not guarantee equal quantities of work.

Dense transformers already require careful parallelism. Recommendation models add huge sparse components whose communication behavior differs from dense layers. A single strategy cannot efficiently distribute both.

Meta uses Hybrid Sharded Data Parallelism for dense model components. HSDP divides model state within groups of GPUs while replicating selected state across groups. The goal is to control memory consumption without sending every communication operation across the entire cluster.

GEM’s sparse components require another arrangement. Meta has described a two-dimensional combination of data parallelism and model parallelism, organized around synchronization costs and memory locality.

Data parallelism gives workers different examples while maintaining model copies or shards. Model parallelism divides a model itself across devices. Combining them allows the system to place large embedding structures where they fit while preserving enough parallel work.

The design introduces a difficult tradeoff. More sharding reduces memory pressure on each accelerator, but it also increases communication. More replication can reduce some communication, but it consumes scarce high-bandwidth memory.

This is where brute-force scaling breaks down. Doubling a cluster does not automatically double useful computation. A larger job can spend more time exchanging data, waiting for stragglers, or rebuilding lost state after failures.

Google illustrated the other side of this problem in its PaLM research. The 540-billion-parameter PaLM system reported 46.2% MFU on 6,144 TPU v4 chips, using a dense language-model architecture and a highly optimized software stack.

That figure does not establish that PaLM’s system is better than GEM’s. Their architectures, hardware, data, and MFU calculations differ. GEM’s sparse recommendation workload carries communication and memory-access patterns that make direct ranking misleading.

The comparison still gives readers a useful coordinate. An MFU result only makes sense in the context of the workload producing it. A dense transformer benchmark cannot serve as a universal target for a sparse advertising model.

Meta’s 20% to 25% range becomes more informative when paired with the claimed twofold end-to-end improvement. The key result is the movement from GEM’s prior baseline while training computation grew fourfold.

End-to-end efficiency also reaches beyond kernel speed. A fast matrix multiplication does not help when the input pipeline stalls, checkpointing pauses the cluster, or workers repeatedly restart.

Meta has previously said that GEM required a complete overhaul of its training recipes. Its earlier generation increased effective training FLOPs by 23 times while using 16 times more GPUs, alongside a 1.43-times increase in MFU.

The August 2026 result represents another stage of that scaling program. It suggests the company found additional gains after the easier benefits of adding hardware and basic parallelism had already been captured.

That puts pressure on infrastructure teams inside every large recommendation business. Access to GPUs remains important, but access alone cannot turn theoretical throughput into model progress.

The Efficiency Gain Came From Model-System Co-Design

Meta did not identify one optimization that doubled GEM’s efficiency. The gain came from making the model and training stack behave as one system.

A recommendation model creates work that standard language-model kernels do not always handle efficiently. Behavioral histories have variable lengths, often called jagged sequences. Padding every sequence to the same maximum length wastes computation on empty positions.

Meta developed custom GPU kernels for those irregular inputs. Kernel fusion combines multiple operations so data spends less time moving between accelerator memory and separate processing stages.

This approach follows a broad lesson from large-model training. Peak hardware specifications describe ideal arithmetic throughput, but real jobs often become limited by memory bandwidth, launch overhead, or communication.

GEM’s attention mechanisms also differ from the familiar transformer recipe. Generalized dot-product attention replaces the standard softmax operation with alternative activation functions suited to different feature-interaction tasks.

The public attention kernel design describes support for the InterFormer and Kunlun architectures used within GEM. It explains why a recommendation system needs more flexibility than a standard language-model attention kernel provides.

InterFormer alternates sequence learning with cross-feature interaction. That structure lets GEM retain detailed behavioral sequences while connecting them with advertiser, user, placement, and creative attributes.

Kunlun extends interaction modeling for non-sequence features. These features can include user or advertisement attributes that do not naturally form a chronological stream.

Supporting these architectures with generic kernels would create overhead. Supporting each variant with unrelated custom code would create maintenance problems. Generalized kernels seek a middle path, preserving flexibility while using optimized execution patterns.

Meta has also described changes to GPU communication. NCCLX, its extension of NVIDIA’s Collective Communications Library, can perform selected communications without consuming Streaming Multiprocessor resources.

Streaming Multiprocessors, or SMs, execute most GPU computation. If communication operations compete for the same resources, compute and networking overlap less effectively.

Removing that contention allows parts of the model to calculate while other data travels between devices. The benefit grows when a job spans thousands of accelerators and exchanges information at many points during each step.

Data loading presents another potential bottleneck. GEM must continuously ingest changing interaction data at a rate that keeps the training cluster occupied. Faster GPUs only magnify delays upstream.

Checkpointing also becomes a first-order concern. A checkpoint saves training state so a job can recover after interruption. Larger models create larger state snapshots, while larger clusters experience more aggregate opportunities for hardware or network faults.

Frequent checkpoints reduce lost work but consume more time and storage bandwidth. Infrequent checkpoints improve steady-state throughput but increase the amount of training repeated after a failure.

A complete efficiency program must balance both outcomes. It cannot optimize only the fastest uninterrupted interval and ignore startup, validation, checkpointing, or recovery.

Meta previously reported a fivefold reduction in GEM job-startup time after optimizing trainer initialization, data readers, checkpointing, and PyTorch compilation. Those tasks sit outside the headline model architecture, yet they determine how quickly expensive capacity begins productive work.

This explains why the new claim uses end-to-end efficiency. That wording implies a measurement spanning more of the training process than an isolated kernel benchmark.

The result also shows why Meta’s foundation-model strategy and infrastructure strategy are inseparable. A shared model can justify greater engineering investment because its representations benefit multiple advertising surfaces.

A small ranking model for one placement might not justify custom communication libraries and specialized kernels. A central model influencing Facebook and Instagram creates a larger return on each infrastructure improvement.

That feedback loop favors companies operating at enormous scale. More interactions support broader training, while a broader model makes efficiency investments useful across more products.

The same loop creates risk. Centralizing learning can spread model errors or data biases across surfaces. Meta must preserve domain-specific objectives so shared representations do not erase meaningful differences among products.

Its architecture addresses that challenge through multi-domain learning and specialized downstream models. The foundation model shares knowledge, while production systems retain surface-level constraints and objectives.

This is not one model directly selecting every ad in real time. GEM supplies learned information to a wider ranking and delivery stack, where latency-sensitive systems make production decisions.

GEM Pressures the Brute-Force Scaling Playbook

The result weakens the assumption that competitive advantage comes mainly from buying more accelerators. At this scale, coordination quality determines how much value the hardware produces.

Meta can afford very large GPU clusters, but the company also has a strong reason to use them efficiently. Advertising funds most of its business, and even modest improvements can influence outcomes across a vast number of ranking decisions.

GEM’s role connects infrastructure spending to that revenue engine. Better shared representations can improve the smaller models that predict engagement, conversion, and other advertiser outcomes.

The foundation-model approach also changes how model teams work. A fleet of isolated models can duplicate learning and infrastructure. GEM offers a central source of representations that downstream teams can adapt.

Meta calls those specialized systems value models. They operate within production constraints that a large foundation model cannot meet directly, including strict response times and different objectives across surfaces.

Knowledge distillation transfers behavior from a larger teacher model into smaller students. Meta says its newer transfer framework is twice as effective as standard distillation, although outsiders cannot verify that comparison from the disclosed material.

Parameter sharing provides another transfer route. A downstream model can reuse selected components instead of reproducing the entire foundation model. That reduces redundancy while preserving specialized execution.

This architecture competes with a more fragmented route, where teams keep improving separate rankers for each placement or objective. Fragmentation can provide control and easier debugging, but it limits shared learning.

The central approach can use evidence from one surface to improve another. It can also learn across sparse objectives, where any individual model would see too few meaningful outcomes.

Other major platforms face the same strategic question. Google combines large-scale recommendation research with advertising systems, while TikTok’s product depends heavily on sequence-based recommendation. Their internal measurements are not publicly comparable with Meta’s GEM disclosure.

The relevant pressure is therefore broader than a single benchmark. Meta is showing that LLM-scale infrastructure methods can move into revenue-critical recommendation training.

Its adaptive ranking system addresses the corresponding serving problem. Training a larger model has limited value if production systems cannot apply its learning within advertising latency and cost limits.

Meta’s stack divides the challenge. GEM performs expensive shared learning during training. Specialized ranking models and optimized runtimes carry that intelligence into live delivery.

Andromeda occupies another part of the pipeline. It retrieves a smaller set of candidate ads from a much larger pool before later ranking stages evaluate them more closely.

The distinction matters as generative tools increase the number of available advertisement variations. More creative options expand the candidate space, raising the value of effective retrieval and ranking.

GEM does not remove the need for advertisers to create relevant offers and credible messages. A better model can choose among available options, but it cannot guarantee demand or repair weak economics.

The system can also become harder to interpret. When a central model learns patterns across surfaces and passes them into downstream models, tracing one delivery outcome back to one factor becomes difficult.

Advertisers may experience performance changes without receiving a corresponding explanation. Meta can measure aggregate gains internally, while individual buyers see results shaped by budget, audience, creative, competition, and attribution.

That information gap should temper broad claims about campaign impact. Training efficiency is an infrastructure achievement. It does not guarantee a uniform conversion improvement for every advertiser.

What Meta’s 20% to 25% MFU Does Not Show

Meta’s headline metric establishes directional progress, but it does not reveal the full economic or environmental cost of training GEM.

MFU focuses on model computation relative to theoretical peak throughput. It does not automatically include every operation performed by the hardware. It also does not account for cluster availability before a job starts.

A system can improve MFU while consuming more total energy if the model grows substantially. GEM’s training FLOPs increased fourfold, so the absolute work performed during a run is much larger.

That expansion may still be economically rational. A larger model can deliver better predictions, and improved utilization can reduce the hardware required for a given amount of computation.

However, Meta has not disclosed the absolute energy per run. It has not provided a cost-per-training-FLOP figure, total accelerator hours, or a comparison using identical hardware.

The phrase “latest-generation GPUs” also leaves important details unstated. Accelerator model, numerical precision, network topology, and power limits can materially affect theoretical peak performance and measured MFU.

Changes in the MFU denominator matter too. Newer GPUs provide more theoretical FLOPs, but applications do not always use those capabilities equally. Comparing percentages across generations requires careful normalization.

The model itself changed while the system changed. Four times more training FLOPs can alter operation sizes, batch behavior, and the balance between computation and communication.

Larger matrix operations sometimes use GPUs more efficiently than smaller ones. Consequently, part of the MFU gain can come from workload shape rather than a universally reusable software improvement.

Meta’s end-to-end framing helps, but the public account still comes from the company operating the system. No independent party has reproduced GEM or audited the reported efficiency.

That limitation does not make the numbers uninformative. Internal production systems often contain proprietary data and architecture. Full reproduction would raise privacy, security, and competitive concerns.

It does mean readers should treat “doubled” as a reported comparison against Meta’s own earlier GEM stack. It is not evidence that GEM is twice as efficient as every competing recommendation model.

The model-quality claims require similar care. Meta has previously said GEM became four times more efficient at producing advertising-performance gains for a fixed amount of data and compute. The company has not released a public benchmark covering competing platforms.

Production advertising outcomes also shift over time. Auction conditions, creative supply, user behavior, privacy rules, and measurement methods can influence observed gains.

Centralization introduces operational risk as well. A foundation model used across multiple products becomes an important dependency. Training delays or flawed updates can affect more teams than a problem inside one isolated model.

Meta mitigates this through checkpoints, validation, specialized value models, and controlled knowledge transfer. The new scale nevertheless raises the cost of mistakes.

Privacy remains another boundary. GEM learns from advertising and organic engagement signals across Meta’s applications. More extensive sequence modeling can extract richer patterns from behavior, even when the system is designed around internal controls.

The technical disclosure does not provide a new privacy-policy analysis. Readers should not infer that greater training efficiency changes what data Meta collects or which protections govern its use.

For engineers, the lesson is narrower and more concrete. MFU should be one diagnostic among several, alongside job completion rate, recovery time, data throughput, energy use, and model-quality improvement.

Teams documenting complicated systems can preserve those distinctions in a searchable engineering knowledge base. That practice helps prevent one attractive metric from becoming a substitute for the complete operating picture.

Three Signals Will Test the Meta Engineering Story

The next test is whether GEM’s infrastructure gains translate into repeatable model improvements without proportional growth in training cost or operational risk.

The first signal is Meta’s next disclosure about model quality per unit of compute. The fourfold increase in training FLOPs establishes scale, while the higher MFU establishes better utilization. Neither alone shows the marginal advertising value produced by the larger run.

A future comparison should separate gains from additional data, architecture changes, training duration, and hardware improvements. If Meta reports better outcomes under a controlled compute budget, the foundation-model case becomes stronger.

If quality gains flatten while computation continues climbing, the efficiency result will look more defensive. Meta would be using hardware better, but each additional unit of training could deliver less business value.

The second signal is broader deployment of GEM-derived learning across Facebook and Instagram surfaces. Meta has positioned GEM as a central model that transfers knowledge to production systems rather than replacing them.

Successful expansion should appear as more downstream models adopting shared components or improved transfer methods. It should also preserve the specialized behavior required by different placements and advertiser objectives.

Watch for evidence that deployment remains stable as the foundation model grows. Faster training loses value when teams cannot validate, distill, or serve the result quickly enough.

The third signal is the next infrastructure bottleneck Meta chooses to disclose. A twofold efficiency gain rarely ends a scaling problem. It usually moves the limiting factor somewhere else.

That constraint might appear in network communication, checkpoint storage, data ingestion, compilation, reliability, or production inference. Meta’s earlier work has already moved across most of those layers.

A new bottleneck would not invalidate the current achievement. It would show that GEM remains a system under active reconstruction rather than a finished platform.

The strongest confirmation would combine three outcomes: higher advertising quality, stable downstream deployment, and slower growth in cost per useful improvement. Missing one of those results would weaken the broader claim.

Developers should also watch whether Meta contributes more of the underlying work to PyTorch or related open-source infrastructure. Generalized attention kernels provide one example of an internal requirement becoming reusable engineering.

Reusable components matter because most organizations cannot copy GEM’s cluster. They can still benefit from better handling of irregular sequences, communication overlap, fused operations, or distributed checkpoints.

For advertisers, the relevant question is different. Watch whether campaign performance becomes more consistent across placements and objectives, especially when an account provides limited historical data.

For infrastructure leaders, GEM offers a more immediate challenge. Measure how much allocated accelerator capacity advances the model, then trace every remaining loss through the entire training lifecycle.

Meta engineering has supplied a striking number: 20% to 25% MFU after doubling end-to-end efficiency. The deeper message is that accelerator count has become an incomplete measure of AI capacity.

The next advantage will come from turning more purchased computation into reliable learning. GEM shows how much engineering that conversion now requires. Which metric would reveal the biggest loss inside your own training system, and can your team measure it before buying the next cluster?