Model freshness — how often it is rebuilt, and why it differs by surface

Meta calls the speed from collecting a signal to training on it and using it for recommendations "freshness." It covers the whole path from data collection to serving, not only the training cadence verified (section 3).

Even within the same company, the regeneration cadence differs by four orders of magnitude, from weeks to minutes, depending on the component. This is not a difference in engineering maturity but a difference in the economics of freshness at each layer. The point of these notes is the reason, not the cadence table.

Observed cadences — one table

Even within one surface, the update cadence differs by component. As of the 2023 post, Instagram Explore fine-tunes its ranking model every 1 hour but regenerates item tower embeddings every 1 day verified (section 2).

Sources and quotes are given in each section below.

↑ Contents

Why it differs — four structures

This note names four structural reasons why the update cadence differs by component inferred (structure 1–structure 4).

• An item missing from the index is not shown at all, whereas a stale ranker only ranks slightly worse (structure 1).
• For a tower whose output is cached, the cost of rebuilding the cache sets the retraining cadence (structure 2).
• Even within one ranker, the tolerable latency differs by parameter type verified (structure 3).
• The update cadence of a graph depends on what the graph contains inferred (structure 4).

1. The index is a coverage problem and the ranker is an accuracy problem

An item that is not in the candidate generation index does not have a low score; it does not exist at all. Until a new item enters the index, its probability of being reached is exactly 0. This is a binary problem.

The ranking model is different. A ranker that is a day old still scores every candidate. Rankings get slightly worse, and this is graceful degradation.

This difference is the primary cause of the asymmetry "index updates take minutes or seconds, ranker retraining takes hours or days" inferred. There are two grounds.

• Meta states directly that it sets freshness budgets differently per component (structure 3).
• SilverTorch (Meta's retrieval system that moves the index into tensors inside the model) built a separate streaming path solely for index freshness.

Meta itself redefines freshness as an index problem. If the index is one module of the model, keeping the index fresh amounts to updating the weights of a production model without taking serving offline.

"With index as a model module, maintaining index freshness equates to updating the model weights of a neural network in production, at scale, without taking the model offline."

verified — SilverTorch, engineering.fb.com, 2026-05-26

2. Once the output is cached, the cost of rebuilding the cache sets that tower's retraining cadence

The key advantage of a two-tower model (a structure in which the user tower and the item tower build user embeddings and item embeddings separately) is caching. Yet that same caching becomes the constraint.

"The main advantage of the Two Tower approach is that user and item embeddings can be cached, making inference for the Two Tower model extremely efficient." "we can use an item tower to generate embeddings for items that can be used as candidates during retrieval. And we can do this on a daily basis using an offline pipeline." "During online retrieval we use the user tower to generate user embedding on the fly by fetching the freshest user-side features."

verified — Scaling the Instagram Explore recommendations system, Vladislav Vorotilov·Ilnur Shugaepov, 2023-08-09

The two towers of the same model are updated at opposite cadences. The user tower runs on every request, so it can be changed at any time, but changing the item tower requires rebuilding the entire index. In other words, the item tower's retraining cadence is set not by model quality but by the cost of rebuilding the index.

The same blog sets a much shorter cadence on the ranking side. It says the model can be re-trained (fine-tuned) every hour as new data arrives.

"neural networks allow us to do this by utilizing continual online training, meaning we can re-train (fine-tune) our models every hour as soon as we have new data."

verified — same post

Within one surface, ranking updates every 1 hour and the item tower every 1 day, a 24× difference, and what creates the difference is whether the output is cached.

SilverTorch appears to be an attempt to break this coupling inferred. According to the blog, SilverTorch periodically publishes the full model as a snapshot. In between, a streaming service reads real-time signals and edits specific tensors of the in-memory model in place. It neither stops serving nor redeploys the model.

"SilverTorch decouples freshness from the full model publish cycle through streaming updates. As model parameters get updated based on the latest training, we periodically publish the full model as a complete snapshot. Between publishes, a continuous streaming service reads real-time signals — new items, updated engagement features, changed eligibility — and applies targeted updates in-place to the specific tensors in the in-memory model." "Updates land without interrupting serving and without redeploying the model."

verified — SilverTorch blog post, 2026

The publish itself also got faster. It uses GPUs to compute item embeddings and clustering, which cut the publish time for building the model snapshot from days to 1 hour verified — SilverTorch paper HTML, 2026.

"The publish leverages GPUs to compute item embeddings and clustering which reduce the publish time to build the model snapshot from days to 1 hour."

⚠ However, the paper has no figure for streaming update latency either verified — same paper. The paper deferred the details of the fresh index to future work: "We leave the details of fresh index for future work." It is an unusual combination in which the blog post explains the mechanism and the paper withholds the figure.

3. Each parameter type has a different freshness budget

Even within the same ranker, the update latency each parameter type can tolerate differs verified. The most mechanical statement of this is Meta's @Scale 2025 talk. In late-stage ranking (LSR in the table) models, item embeddings can yield large gains with zero-second update latency, and dense parameters can tolerate tens of minutes of latency without hurting performance verified.

"For instance, updates to item embeddings in late-stage ranking models can yield substantial gains with zero-second latency, whereas dense parameters can tolerate delays of tens of minutes without compromising performance."

verified — Model Freshness Systems at Scale, Xianzheng Dou·Lujia Zhang·Vahid Jazayeri·Vivek Khurana (Meta), @Scale 2025

The question "how often is the model retrained" is itself wrong. Even within one ranker, the embedding table and the dense layers have different freshness needs. The reason is an inference but a clear one: item embeddings hold new items and new popularity, so their distribution shifts quickly, while dense layers hold a slow function, "how to combine engagement" inferred.

The same talk presents both the definition of freshness and the improvements by generation.

• Freshness refers to how quickly signals are collected, trained on, and used for recommendations verified — same talk: "How quickly the signals can be ingested, trained on, and used for providing recommendations is referred to as 'freshness.'"
  • In other words, freshness covers the whole path from data collection to serving. It does not mean only the training cadence.
• Model update latency as of 2021–22 was about 3–6 hours verified: "At this stage, the model-update latency was approximately three to six hours."
• After the improvement techniques were applied, freshness became about 10–30 minutes verified: "By leveraging these techniques, we achieved freshness at approximately 10-30 minutes."
• As of @Scale 2025, current freshness is O(1 minute) verified: "This brings freshness down to O (one minute)."

4. What a graph contains sets its cadence

Community detection on X's follow graph runs every 7 days, and the rebuild of Meta's co-engagement (a relationship of engaging with the same target) graph runs every 3 hours verified — the code below and the RankGraph-2 paper. The reason for the 56× difference is that the two graphs contain different things inferred. Follow relationships are the social structure of people and change slowly, while co-engagement edges are attached to content, so they become invalid as quickly as content ages. Rebuilding a graph built on a 24-hour window every 3 hours means that more than half of the edges become meaningless within a day.

X's follow-graph community detection runs every 7 days. This cadence is set in the job that builds KnownFor, the per-account community membership in SimClusters (X's embedding that splits the follow graph into communities and uses degrees of membership as vectors).

override val firstTime: RichDate = RichDate("2020-10-04")
override val batchIncrement: Duration = Days(7)

verified — twitter/the-algorithm @ c54bec0, simclusters_v2/scalding/update_known_for/UpdateKnownFor20M145K2020.scala:44,46

This number is a constant that can be quoted. The hyperparameters in the same file take the form args.int(name, default), so the values written in code differ from the production run values. The maxNeighbors 400 vs 100 case summarized in embedding-retrieval.md is one such case. By contrast, batchIncrement is stated in the schedule itself with override val. It is not overridden by runtime arguments verified.

Meta's co-engagement graph runs every 3 hours. According to the RankGraph-2 paper (Meta's system that uses a co-engagement graph as a retrieval index), the graph is built from 24 hours of engagement data and fully rebuilt every 3 hours. The whole pipeline finishes within 1 hour, which makes the 3-hour cadence possible. The paper adds that even a 3-hour refresh may be insufficient in extremely time-sensitive situations.

"The graph is constructed from 24 hours of engagement data and fully reconstructed every 3 hours" "The entire pipeline completes within one hour, enabling the 3-hour refresh cycle" "the 3-hour refresh may be insufficient for extremely time-sensitive scenarios"

verified — RankGraph-2: Lifecycle Co-Design for Billion-Node Graph Learning in Recommendation, Meta, 2026 (HTML version, not PDF)

The same paper applies a freshness condition once more at the serving stage. Narrowing the candidate pool to recently active users (e.g., the past 15 minutes) gave the best quality verified: "filtering the candidate pool to recently active users (e.g., past 15 minutes) yields the best quality"

The index refresh cadence of rebuilding every 3 hours and the serving-time filter on activity within 15 minutes are separate levers. When the index cannot be rebuilt more often, the lookup range is narrowed to compensate.

↑ Contents

X — freshness is managed through time decay instead of a retraining cadence

X's public code has almost no clues about the model retraining cadence verified. Instead, freshness is expressed through decay constants and TTLs verified.

On 2026-08-09, before the Gen4 release, the strings hourly / daily / retrain / continual appeared 0 times across the whole 2026 Rust repo verified — GitHub code search, xai-org/x-algorithm, 2026-08-09

In phoenix/ at HEAD (862a123, 2026-10-17), these strings appear only in multimodal embedding snapshot paths and proto fields, and no wording mentions a ranker retraining cadence verified — 2026-10-19 git grep.

The decay constants and TTLs are in the table below. Locations are as of twitter/the-algorithm @ c54bec0, except the Thunder row, which is xai-org.

Within the same system, two half-lives differ by 300× verified — InterestedInFromKnownFor.scala:291-292, summingbird/common/Configs.scala:38 (c54bec0). The half-life of taste is 100 days and the half-life of content is 8 hours, so 100 × 24 ÷ 8 = 300. Details are in embedding-retrieval.md.

X and Meta solve freshness at different layers inferred. Meta keeps updating model parameters, while the approach visible in X's public code is closer to "keep the model and communities for a long time and apply time decay to the inputs" inferred. However, X's ranker retraining cadence may simply be undisclosed, so this must not be settled as a comparison. What exists now is an absence of evidence, not a refutation.

Thunder (the in-network index in X's 2026 code that holds the latest posts of followed accounts in memory) has one side effect from its 2-day retention. When a thread root expires, all replies under it disappear. This is a case where the index retention period determines product behavior verified — x.md

↑ Contents

Case: Netflix — the most concretely disclosed retraining cadence, and why freshness pressure is low

Netflix is the case that discloses its retraining cadence most precisely among big-tech recommendation models. The Foundation Model (FM, Netflix's recommendation model pretrained on interaction data) is pretrained from scratch every month and fine-tuned every day.

"pre-trained from scratch every month on interaction data, then fine-tuned everyday"

verified — Integrating Netflix's Foundation Model, 2025-11

It is a dual cadence of monthly pretraining that rebuilds everything and daily fine-tuning that folds in updates incrementally. This moves the per-parameter-type freshness budget of structure 3 to the level of the whole model. The overall representation space is updated slowly while the latest data is reflected quickly.

GenRec (Netflix's LLM ranker) repeats the same pattern. The Netflix-adapted LLM is updated rarely, and ranking post-training is performed frequently verified — GenRec blog post 2026.

However, there is a structural reason this cadence can be looser than at X or Meta inferred.

• New items arrive on a schedule. UGC (user-uploaded content) appears at thousands per second at random, but the release dates of a programmed catalog are known in advance. The coverage pressure of structure 1, "if it is not in the index, reach is 0," is weak. So the new-title problem shifts from a freshness problem to a promotion problem (the billboard bandit). Details are in netflix.md.
• Content lives long. Unlike a world where the tweet embedding half-life is 8 hours, movies and series are consumed for months. There is no reason to rebuild a co-engagement graph every 3 hours.

Netflix precomputes and caches the recommendation results themselves. This is an extreme case of structure 2.

• Since the 2013 three-layer (offline/nearline/online) structure, precomputing results has been the default verified — 2013 blog post
• For live events, it builds recommendations before the start and pushes them to devices in advance (100 million devices within 1 minute) verified — live delivery blog post 2025

In light of the claim of structure 2, "if the output is cached, the cost of rebuilding the cache sets the retraining cadence," the cached object here is not the embedding but the entire recommendation list.

Calibrate with classic-generation figures. The TMIS 2015 paper gives "data up to two days before" as an example of an offline experiment protocol verified. It is not a production training cadence claim, but because it assumes latency of a day or more as normal operation, it is valid as indirect evidence that freshness had low priority at the time inferred.

↑ Contents

Ads — the oldest case of treating freshness as a "measurable cost"

On the ads side, the abstract of the 2014 Facebook ad click prediction paper already lists freshness as a tunable factor verified. According to the abstract, choosing the optimal handling of data freshness, learning rate schema, and data sampling improves the model slightly. However, the effect is much smaller than adding a high-value feature or picking the right model to begin with verified.

"Picking the optimal handling for data freshness, learning rate schema and data sampling improve the model slightly, though much less than adding a high-value feature, or picking the right model to begin with."

— Practical Lessons from Predicting Clicks on Ads at Facebook, He et al., ADKDD 2014

⚠ The figure in this paper for "how much NE worsens as the training–test gap widens" is only in the body PDF, so we did not verify it. NE (normalized entropy) is the prediction loss metric this paper uses. Under this repository's rule, figures obtained from a PDF are not quoted. Only the qualitative statement in the abstract is verified.

The current statements on the ads side are qualitative verified — Meta's Generative Ads Model (GEM), 2025-11-10. GEM is the foundation model (FM) for Meta ads. It is a structure that distills knowledge from this FM into per-surface vertical models (VM).

• It says VMs often suffer from stale supervision caused by delays in FM training and evaluation verified — same post. The same sentence also lists the mismatch between GEM or FM predictions and the VMs' surface-specific objectives.
  • "VMs often suffer from stale supervision caused by delays in FM training and evaluation as well as domain mismatches between GEM or FM predictions and the VMs' surface-specific objectives."
• The countermeasure is the student adapter verified. It is a lightweight component that refines the teacher model's outputs with the latest ground-truth data: "a lightweight component that refines the teacher's outputs using the most recent ground-truth data"
• The FM itself is also kept updated through continuous online training verified: "we also perform continuous online training to refresh the FMs"

Here the freshness problem becomes one step more complicated. In a structure that distills from a foundation model to a vertical model, the teacher's staleness propagates as bias in the student. So a layer that corrects with the latest labels is added separately on the student side. It is a form of staleness that did not exist in the single-model era.

⚠ We could not find a primary source for the time figure "ad models go stale within hours." The closest evidence is this phrase from @Scale 2025 inferred: "three to six hours". However, it is a statement about recommendation models overall and is not limited to ads inferred. It must not be quoted as an ads figure.

↑ Contents

Freshness was promoted from an infrastructure metric to a product metric

Since 2025, Meta has reported the "share of same-day posts" directly in earnings calls verified. The IR transcript sources are in facebook.md.

The SilverTorch blog post (2026) links the same metric to its own results verified.

"The result shows up in the recency of recommended content. Same-day posts now represent a significant portion of recommendations..."

Infrastructure freshness and the product recency metric were placed on the same footing inferred. That it is reported as a separate metric for 3 consecutive quarters means recency was promoted to an explicit ranking objective, and if so, the freshness investment is part of the objective function rather than latency optimization inferred.

↑ Contents

What generalizes from this case

The update cadence is not fixed to one value per model and differs by component even within one model verified (structure 2, structure 3). The factors this section's generalization names as separating cadences are whether output is cached, the parameter type, what the graph contains, and the form in which items arrive inferred (structure 2, structure 3, structure 4, Netflix case).

• "How often is the model retrained" is a singular question and has no answer. Even on one surface, IG Explore, the ranker updates every 1 hour and the item tower every 1 day. Looking at other systems, the RankGraph-2 graph is 3 hours, the X cache is 600 seconds, and the SilverTorch index is updated by streaming. A cadence figure that does not say which component it applies to is meaningless.
• Freshness is end-to-end latency, not the training cadence. Meta's definition includes everything from collection through training to use in recommendations: "ingested, trained on, and used". Even if you write "trained hourly," if data collection is 3 hours late, freshness is 3 hours.
• The freshness budget differs by parameter type. Zero-second latency is a gain for item embeddings, while dense layers tolerate tens of minutes. Publishing the whole model frequently all at once is both expensive and unnecessary.
• A dual cadence of "full rebuild + incremental update" is a recurring pattern. The three cases below all follow this structure. The larger the representation, the slower the cadence it is placed on, and recency is left to the fast cadence.
  • SilverTorch: snapshot publish (cadence undisclosed), streaming in-place updates in between
  • Netflix FM: monthly pretraining, daily fine-tuning
  • GenRec: the adapted LLM rarely, post-training frequently
• If output is cached, the cost of rebuilding the cache sets that component's retraining cadence. The item tower of a two-tower model is the textbook case. To raise freshness, you should not train the model more often but change how the cache is updated, and SilverTorch's in-place tensor update is exactly that answer.
• Index freshness and the serving-time filter are separate levers. RankGraph-2 rebuilds the graph every 3 hours while narrowing candidates at serving to users active within 15 minutes. When the index cannot be rebuilt more often, the lookup range can compensate.
• A graph's update cadence follows the lifetime of what the graph contains. The follow graph is 7 days and the co-engagement graph is 3 hours, a 56× difference.
• Freshness pressure is set by the form in which items arrive. With random bulk inflow (UGC), index coverage becomes a problem of minutes and seconds. With scheduled small-volume inflow (a programmed catalog), freshness turns into a promotion problem. What Netflix handles with a monthly and daily dual cadence is a difference in problem shape, not a technology gap.
• In a distillation structure, the teacher's staleness becomes a new kind of staleness. GEM's student adapter is the response to it.
• When checking a cadence figure in code, look at the kind of constant. X's batchIncrement = Days(7) can be quoted because it is an override val, but the args.int(name, default) values in the same file are not production run values (embedding-retrieval.md).

↑ Contents

Who uses this

Meta disclosed the most detail on freshness infrastructure, and Netflix disclosed the most concrete retraining cadence verified. For X, we confirmed the decay constants and TTLs but could not find the ranker retraining cadence inferred.

• Meta / Facebook: disclosed the most detail on freshness infrastructure verified. Cold start and retrieval context are in facebook.md.
  • @Scale 2025: from 3–6 hours to O(1 minute)
  • SilverTorch: index as model, snapshot publish takes 1 hour, plus streaming in-place updates
  • RankGraph-2: 3 hours
  • GEM: continuous online training and student adapter
• Instagram Explore: the ranking model is fine-tuned every 1 hour and the item tower runs on a 1-day cadence verified. This repository does not yet have a service note.
• X: we confirmed the decay constants and TTLs and could not find the ranker retraining cadence. Evidence is in x.md and embedding-retrieval.md.
  • Decay and TTL verified: SimClusters KnownFor is 7 days, tweet embeddings accumulate in real time, half-lives are 100 days and 8 hours, Thunder is 2 days, and the cache TTL is 600 seconds.
  • Retraining cadence inferred: the public repo Gen2 has no training scheduler, and the official X blog post has no statement either. This is not evidence that the undisclosed internal pipeline has none.
• Netflix: the FM is monthly pretraining plus daily fine-tuning, and this is the most concrete disclosed cadence verified — netflix.md. The embedding store is daily, and precomputing recommendation results is the default verified — same file. It appears to be a structure with low freshness pressure itself inferred (Netflix case).
• Others: not yet investigated. They remain an open question.

↑ Contents

Not yet verified

The remaining questions mostly concern undisclosed retraining cadences, releases missing figures or scope, and old evidence that may no longer hold.

• Retraining cadence of X's ranker (Phoenix/Navi). The Phoenix training code has been in the repo since the Gen4 release (47c1bcd), but no wording mentions a retraining cadence even at HEAD (862a123) verified (x.md Phoenix training section).
• Actual latency of SilverTorch streaming updates. The paper withheld this part ("future work"), and the blog post gives no figure either.
• Hour-level staleness cost of Meta ads models. We could not secure a primary source. The 2014 paper has an experiment in its body, but it is a PDF and cannot be quoted under this repository's rule. Finding an HTML or ACM version would resolve it.
• Ranker retraining cadence for the Facebook Feed core (non-Reels). It appears in neither the system card nor the 2021 blog post.
• Which surface and which parameters the "O(1 minute)" in @Scale 2025 applies to. We confirmed only the talk summary and do not know the detailed scope.
• Whether the Instagram Explore 1-hour fine-tune is still valid in 2026. The only evidence is a single 2023 post.
• Whether X's simclusters_v2 batch jobs (KnownFor, 7-day cycle) still run. Not a single byte in simclusters_v2/ has changed since 2023-04. The 2026 repo had no SimClusters references through Gen3, and Gen4 (47c1bcd) brought back a SimClusters candidate source in home-mixer verified — home-mixer/sources/simclusters_source.rs. Code being present does not mean it is running.

↑ Contents

Sources

• Model Freshness Systems at Scale — 2025, talk (@Scale, Meta). Xianzheng Dou, Lujia Zhang, Vahid Jazayeri, Vivek Khurana. The primary source for the freshness definition and the per-generation figures.
• SilverTorch: Index as Model — A New Retrieval Paradigm for Recommendation Systems — 2026, blog post.
• SilverTorch: A Unified Model-based System to Democratize Large-Scale Recommendation on GPUs — 2026, paper. HTML version. Publish time dropped to "days to 1 hour".
• RankGraph-2: Lifecycle Co-Design for Billion-Node Graph Learning in Recommendation — 2026, paper (Meta). HTML version. 3-hour rebuild, 24-hour window, 15-minute active-user filter.
• Scaling the Instagram Explore recommendations system — 2023, blog post. Hourly fine-tune, daily item tower.
• Meta's Generative Ads Model (GEM) — 2025, blog post. Stale supervision, student adapter.
• Practical Lessons from Predicting Clicks on Ads at Facebook — 2014, paper (ADKDD). We confirmed only the abstract and did not quote figures from the body.
• twitter/the-algorithm — 2025-09-03 commit c54bec0, public source code. UpdateKnownFor20M145K2020.scala:44,46, InterestedInFromKnownFor.scala:286-301, summingbird/common/Configs.scala:38, Utils.scala:47-49.
• xai-org/x-algorithm — 2026, public source code. thunder/posts/post_store.rs:521-526.
• Meta IR transcripts (Q3 2025 / Q4 2025 / Q1 2026) — same-day share figures. The links are in the Sources section of facebook.md.
• Integrating Netflix's Foundation Model — 2025, blog post. The primary source for monthly pretraining and daily fine-tuning.
• System Architectures for Personalization and Recommendation — 2013, blog post. Three layers: offline/nearline/online.
• The Netflix Recommender System (TMIS) — 2015, paper. Training data is "up to two days old".
• Behind the Streams: Real-Time Recommendations for Live Events — 2025, blog post. Precompute and delivery to 100 million devices within 1 minute.

↑ Contents