- Sources read: 2
- Canon files updated: 1
- Radar entries: 1
Other changes reviewed today:
- Meta researchers stated in a profiling tool paper that their recommendation models are TB-scale, run on thousands of GPUs, and receive 100B examples per day.
1KuaFu's item-level compression replaced a profiling pipeline for 10 months — Radar
Source KuaFu: Compressing Long User Behavior into Understanding at Billion Scale — arXiv, 2026-09-25 v1, paper. The authors are 11 (Jiahao Hui, Lin Zhu, Yishen Hu, Jingdong Shu, Zetai Jiang, Xining Ran, Ben Tan, Yeshou Cai, Gong Chen, Haijie Gu, Jie Jiang). The author affiliations are not rendered in the HTML version, but the body states "deployed on the Tencent advertising and recommendation platform for ten months, with a 1.37% lift in overall GMV", and one author, Jie Jiang, overlaps with the author list of ChronicleRec (Tencent PCG Weixin Moments Ads), so we infer a Tencent advertising and recommendation team inferred.
Background In industrial-scale recommendation systems, it is hard to work directly with raw behavior logs (clicks, views, purchases, and so on) to capture each user's tastes. So a user profile that summarizes the logs is used as an input feature of the ranking model. A profile is split into several tasks, such as "content-interest summarization" (which content the user likes), life stage estimation, and purchase intent prediction. The usual practice is that a separate small model per task cuts out and processes part of the logs.
This practice has two bottlenecks.
- First, even after splitting by task, the sequences are still long. Content-interest summarization alone requires reading several hundred behavior items per user on average and thousands in the tail. Serialized as prompt text, this becomes tens of thousands of tokens. For LLM-based profiling, that is hard to fit into the context window.
- Second, profiles must be refreshed often. At Tencent's scale this means weekly recomputation of 1 billion user profiles, which requires aggregate throughput of about 100K QPM (Query Per Minute). With a fixed GPU budget at this scale, the throughput of per-task models sets a lower bound.
Compression is the natural alternative. Compressing the sequence into short tokens and feeding it to an LLM, or letting several tasks share one compressed representation instead of feeding each task its own slice, can ease the budget problem. However, compression itself creates a new problem. The authors state four hallucination types:
- fabrication: inventing interests that do not exist.
- omission: dropping signals.
- date misattribution: attributing an event to the wrong point in time.
- broken logic: reasoning wrongly from the remaining evidence.
These hallucinations are observable only through downstream business metrics (CTR, GMV). Those metrics are diffuse, and pinning down the root cause requires a month of data, which slows the training loop severely.
KuaFu in this paper is a compressed representation layer that addresses both problems together. It takes a single behavior item, not a sequence, as the smallest unit of compression, compresses each item independently, and proposes a structure that stacks the results as a cache shared by downstream tasks.
What we learnedA. Compress each item separately, stack the results as a cache, and cut both token count and width
- An item compressor encodes each behavior item (one click, one view, one ad context, and so on) independently, and a two-axis projector on top of it reduces both axes together verified.
- The output of the item compressor is an embedding of shape
m × d. - The token axis is lowered by
m → k(about 10×) and the width axis byd → d′(about 20×). - As a result, the final compressed representation
z_ihas shape 2–4 tokens × width 128–256.
- The output of the item compressor is an embedding of shape
- Quantitatively, the per-item cache shrank from 10 KB to 0.5 KB verified.
- Because compression is per item, the cache is linear in sequence length, and a user's new events only need to be appended without recomputing the existing cache verified.
- Instruction-token embeddings are not compressed verified.
"A two-axis projector compresses each item into 2–4 tokens of width 128–256—about 10× compression along the token axis and 20× along the width axis, cutting the per-item cache from 10 KB to 0.5 KB." — KuaFu abstract, 2026-09-25
What we learnedB. Compression is trained by stacking four stages in sequence
- The authors train the compression by stacking four stages in sequence, called a fidelity-oriented four-stage recipe verified.
- Understanding: a decoder that takes the compressed representation as input is trained to reconstruct the original sequence. Both the compressor and the decoder are updated.
- Post-training: learns composite understanding from layered-difficulty data of 42 task types. This includes 4 profiling tasks.
- Co-training: targets compression and generation (per-task responses) at the same time. A sequence-length curriculum (short sequences → long sequences) in the reconstruction stage stabilizes convergence.
- Hallucination-aware RL: with the compressor and projector frozen, only the decoder is updated with DAPO (Decoupled Clip and Dynamic sAmpling Policy Optimization, arXiv 2503.14476). The reward sums the verdicts for the four hallucination types with harm weights.
What we learnedC. The RL reward penalizes fabrication most heavily, and fabrication fell from 33.5 to 4.5 after RL
- The reward model judges each of the four types as present or absent in a response and applies a penalty per type with a harm weight verified.
- fabrication 0.45 (heaviest), date misattribution 0.24, broken logic 0.24, missed detection 0.07 (lightest)
- Completeness is computed as a separate bonus.
- The authors explicitly note the side effect that penalizing fabrication most heavily can push the model to escape into refusing to answer, and state that refusal is counteracted separately verified.
- After hallucination-aware RL, the fabrication hit rate fell from 33.5 to 4.5, about 29 pp, and the fully-correct answer rate rose by +34.0 pp verified.
- Date and logic errors fell together, and missed detection and missing answers rose slightly verified.
- In other words, the expected side effect that "a heavy penalty on fabrication causes drift toward refusal" is actually observed.
"Fabrication carries the heaviest weight (0.45) and missed detection the lightest (0.07), with completeness as a separate bonus. After DAPO fabrication falls from 33.5 to 4.5 and the fully-correct rate rises by 34.0 pp." — KuaFu §3.4 / §4.6, 2026-09-25
What we learnedD. Offline, the compressed model matches or beats the uncompressed existing models on all 5 headline metrics across the 4 tasks
- For each of the 4 production profiling tasks (content-interest summarization and others), the compressed KuaFu model matches or exceeds the uncompressed single-task production model verified.
- The authors state that this is quantitative evidence that it "can replace per-task models even under a shared serving budget".
- The same abstract states that per-GPU throughput rose by +37–350% and 190 GPUs were saved verified.
"Across four production profiling tasks, the compressed model matches or exceeds the uncompressed single-task production models on all five headline metrics, increases per-GPU throughput by 37%–350%, and saves 190 GPUs." — KuaFu abstract
What we learnedE. On the public MRQA out-of-domain benchmark it gained up to +17.7 EM, and on RecBench the 4B model leads the 8B model by 1.90 points
- On the public MRQA benchmark it improved by up to +17.7 EM (exact match, the share of answers that match the ground truth exactly) over existing prompt compressors verified.
- 6 in-domain sets: SQuAD, NewsQA, TriviaQA, SearchQA, HotpotQA, NaturalQuestions
- 6 out-of-domain sets: BioASQ, DROP, DuoRC, RACE, RelationExtraction, TextbookQA
- On RecBench, KuaFu's 4B model leads the KuaFu 8B model by 1.90 points verified.
- The authors cite this as evidence that "because the compression structure itself fits the task well, performance holds even when the parameter budget is reduced".
What we learnedF. In the online A/B test, GMV rose +1.37% against a 5% holdout over 10 months
- The online verification is an A/B experiment that randomly splits traffic by unique visitor verified.
- The resources both arms use for profile mining are kept identical, and the control keeps the existing profile features of the "one year of behavior, monthly refresh" approach verified.
- Rollout went from 0% → 100% within a 4-week observation window verified.
- After full rollout, a 5% holdout (a comparison group left without the new approach) was retained and observed for 10 more months verified.
- Over the 10 months after deployment, GMV against the holdout was +1.37% (95% CI [0.71%, 2.03%]), and the confidence interval excludes 0 verified.
- The authors state that "since both arms consume GPU and storage equally, the source of the gain is the two kinds of headroom that compression secured (a representation shareable across tasks, and a longer time window)".
"After full rollout a 5% holdout was retained and observed for a further ten months, over which overall GMV rose by 1.37% against that holdout (95% CI [0.71%, 2.03%])." — KuaFu §4.8, 2026-09-25
What we learnedG. KuaFu compresses and unifies the profiling layer in front of the ranking backbone, not the backbone itself
- If Meta HSTU (the sequence Transformer ranking model for Meta organic recommendation) and the Netflix Foundation Model scaled the ranking backbone itself, KuaFu is the angle that compresses and unifies the profiling layer in front of ranking.
- ChronicleRec (Tencent PCG) pre-compressed the lifelong representation (a representation holding a very long user behavior history) fed into the ranker into target-independent Chronicle Tokens. KuaFu has a different role because it reconstructs the profiling task itself on top of a shared compression.
- ChronicleRec handles the ranking backbone input of the conversion rate prediction (pCVR) surface, while KuaFu handles the whole profiling pipeline.
- Both sources were deployed on the Tencent advertising and recommendation platform (Jie Jiang recurs in the author lists), which strengthens the indication that Tencent is pushing lifelong user modeling on two fronts together: ranker input and the profiling pipeline.
What we learnedH. This is the first production claim in the repository that constrains LLM profiling with harm weights
- The harm-weight structure of hallucination-aware RL is itself a new data point. This is the first production claim in the repository corpus that constrains LLM-based profiling with a loss function entirely different from offline A/B.
- Meta AMBER centers on offline metrics, and Comcast LLM profiling stated only aggregate offline comparisons.
- The weighting itself, with fabrication heaviest and missed detection lightest, is a production judgment that the harm of false positives to user trust is greater than that of false negatives. So it is a form other companies can reference when they adopt LLM profiling.
Canon update Added KuaFu (presumably Tencent) at the top of "new this month" in radar.md. Tencent is not a service this repository tracks in the canon, so no services canon is created.
Why it matters The repository gets its first quantitative evidence that LLM-based user profiling has moved from an idea to production deployment at a scale of 1 billion users weekly. One more role is added to the list of roles in which the repository has tracked LLM and recommendation combined: compressing and unifying the profiling pipeline itself. However, it is not included in the numbering of the role list; only a statement is added to the thread.
- Existing role list:
- Netflix GenRec: scoring function
- Yandex Gryphon: generative retrieval and ranking
- Alibaba MetaStrategy: offline policy compiler
- Meta ConnectionMind: graph path reasoner
- Meta AMBER: input tokenization
- Spotify GLIDE: SID (semantic ID, which represents an item as hierarchical codes) candidate generator
- LinkedIn Follows: LLM embedding retrieval
- Comcast LLM profiling: offline experiment
2A profiling paper disclosed Meta's model hardware and data scale — Meta
Source Component Benchmark: Hierarchical Model Profiling for Large-scale Recommendation Systems — arXiv, 2026-09-25 v1, paper. All 14 authors are affiliated with Meta Platforms Inc., Sunnyvale. We confirmed the domain @meta.com in the affiliation block of the HTML version.
Background Industrial-scale recommendation models are hard to profile because they mix memory-bandwidth-bound operations (embedding lookup), small compute-bound dense layers, and dynamic shapes that come from jagged categorical features. Existing tools look only at end-to-end throughput or extract operator-level traces. They do not directly show "per-submodule performance", the unit in which practitioners who assemble models think. The Component Benchmark (CB) in this paper is a profiling framework that provides a hierarchical tree visualization at the submodule level.
What we learnedA. Meta recommendation models are TB-scale, run on thousands of GPUs, and ingest 100B examples per day
- The Meta recommendation stack runs TB-scale models on thousands of GPUs and consumes 100B examples per day verified.
- This statement gives hardware and training data scale explicitly as aggregates.
- The statements the repository has tracked on Meta HSTU/Wukong, ConnectionMind, and AMBER, in contrast, covered the following three axes:
- parameter axis (HSTU experiments)
- surface axis (hot path 5-10%)
- event axis (billions of events per day)
"These large-scale recommendation models are TB-scale, run on thousands of GPUs and ingest 100B examples per day." — Component Benchmark abstract, 2026-09-25
What we learnedB. CB is a profiling tool, not a model
- The paper body applies CB to an open-source DLRM (the recommendation model implementation released by Meta) and a NanoGPT example. It shows an architecture that gathers kernel-level traces, memory snapshots, and Perfetto visualization links into one tree view.
- It is not a new ranking or retrieval mechanism.
Canon update None. Component Benchmark is a profiling tool paper, and there is no directly corresponding place among the ranking and retrieval sections of the services/facebook.md canon. The scale figures TB-scale, thousands of GPUs, and 100B examples/day stay only in this daily. They are a data point to consult if a "Scale" section is opened in facebook.md later.
Why it matters The quantitative statement that the Meta ranking stack trains TB-scale models on thousands of GPUs with 100B examples per day is itself new (the existing canon centered on parameter scale and per-surface statements). However, this source is an aggregate figure from the justification context of a profiling framework, so it does not specify which layer of the production pipeline it corresponds to. Whether it is the scale of a single recommendation model or the sum of several surface models needs confirmation in follow-up sources.
Radar
Added KuaFu (Tencent) to radar.md. KuaFu replaced the profiling pipeline with two-axis compression at the behavior-item level and was deployed for 10 months at a scale of 1 billion users weekly and 100K QPM verified — arXiv 2609.31045.
- Figures: GMV +1.37% (95% CI [0.71%, 2.03%]), 190 GPUs saved, 4B > 8B by 1.90pt (RecBench), MRQA OOD +17.7 EM verified
- The author affiliation is inferred from Jie Jiang matching a ChronicleRec author inferred.
What to check next
- Watch for a KuaFu v2, a company blog post, or a Tencent Tech Blog post — if one appears, promote the author affiliation from [inferred] to [verified].
- Check in follow-up Meta sources which surface the "TB-scale model" mentioned by Meta Component Benchmark belongs to — it is still unclear whether it is a Facebook Feed ranker, an Ads ranker, or a Reels ranker.
- The arXiv cs.IR triage parsed 30 items and passed 1 (KuaFu). The other 29 are either leftovers from yesterday's 09-28 triage or academic RAG/QA/retrieval methodology. Component Benchmark was folded into the daily because it contains production statements, but it is not promoted to the radar because it is a profiling tool, not on the ranking and retrieval mechanism axis.