2026-08-28

1. X 4세대+9 드랍 — 체크포인트 저장/복원 스택 정리 + trainer_recsys valid_step 통일 + grox reply_spam LM 프롬프트 확장 + VF media cache 제거 + PIXEL_FIRE 광고 헤드 3종

이 절은 서브시스템별로 나눠서 설명한다 — 여섯 갈래 변경이 서로 독립적이라 한 흐름으로 엮이지 않기 때문이다.

1-A. Phoenix 체크포인트 저장·복원 스택 재정리

phoenix/xrex/utils/checkpointing.py(+215/−6)와 phoenix/python/training/xai-checkpointing/xai_checkpointing/load.py(+311/−88)이 저장·복원 양방향에서 RSS(resident set size, 호스트 메모리 실 점유량) 상한을 명시적으로 도입했다. 4세대+7 (2026-08-24)의 restore-side 하드닝 후속 — 그때는 복원만 concurrent_gb throttle + node-lock으로 잘랐는데, 이번엔 저장도 같은 원리로 자르고 복원엔 streamed 변형이 하나 더 붙었다.

저장 측: ThrottledD2HArrayHandler 신설 [확인] — phoenix/xrex/utils/checkpointing.py:88-181:

• Orbax의 ocp.type_handlers.ArrayHandler를 상속해서 serialize(values, infos, args)를 오버라이드. 텐서 리스트를 순회하면서 각 tensor의 addressable_nbytes(현재 프로세스가 담당하는 shard의 실 바이트)를 누적해 concurrent_bytes 한도 넘으면 배치 flush. 배치마다 super().serialize() 호출 + future.result()로 D2H+write 완료 대기 후 다음 배치 진입. 즉 텐서를 한 번에 다 stage해서 pinned-host를 폭발시키는 대신, 한 배치의 D2H와 저장이 끝나야 다음 배치를 stage한다.
• 압축 여부에 따라 ThrottledD2HArrayHandler(compressed) 또는 ThrottledNoCompressionArrayHandler(non-compressed) 다중 상속으로 분기. save_checkpoint(..., save_concurrent_gb=<N>) 인자로 크기 지정. 지정 안 하면 이전과 동일한 stock Orbax handler(전량 stage) 유지 — 하위 호환.
• 노드 레벨 flock — XAI_SAVE_NODE_SERIALIZE=1 env가 켜지면 /dev/shm/xai_save_node_lock(없으면 /tmp/...)에 fcntl.LOCK_EX를 걸어 같은 노드 여러 프로세스가 동시에 저장하지 못하게 한다. restore 측과 동일 패턴(XAI_RESTORE_NODE_SERIALIZE).
• 로그: 배치별 leaves count·GiB, max_leaf가 예산 초과하면 명시적 경고("that leaf still D2Hs in one shot") — 스로틀이 텐서보다 작을 때 사용자에게 튜닝 여지 알림.
• 의미: Muon+GB300 세대에서 checkpoint save가 다중 워커 저장 시 wait_until_finished 밖 D2H 스테이지에서 host OOM을 유발하는 관찰이 있었을 것 [추정] — restore 측 4세대+7 도입 논리와 완전히 대칭적. 4세대+6이 flagship Muon 학습을 export에 정식 포함한 이후 큰 모델 저장의 오래된 stock Orbax 설정("write-limiter default 96GB, D2H 전량")이 실제로는 부족하다는 것을 실측한 결과로 해석 가능.

"save node-serialize ACTIVE (flock per batch) lock=%s pid=%d num_batches=%d" — phoenix/xrex/utils/checkpointing.py, 2026-08-26

복원 측: load_checkpoint_streamed 신설 [확인] — phoenix/python/training/xai-checkpointing/xai_checkpointing/load.py:365-528:

• 기존 load_checkpoint는 처음에 host_state(모든 텐서의 pinned-host 사본)를 만들어 놓고 배치별로 read into shards 하는 방식이었다. streamed 버전은 device_state를 유지하고, 배치마다 그 배치의 텐서만 pinned-host로 stage → 파일 read → device로 device_put → device_state 갱신 → 배치 pinned-host 해제한다. 즉 임의 시점 pinned-host 상한 = 현재 배치 크기.
• auto-window — window_gb=None(기본) 시 _auto_window_bytes = min(max(max_leaf, total/16), 32GB). 즉 max_leaf보다 항상 크고, 전체를 최소 16개 배치로 나누되 32GB로 캡. 유저가 굳이 값을 안 정해도 합리적 window 자동 선택.
• on_replaced 콜백 — 배치가 완료돼 device_state의 참조가 새 array로 교체되면 old/new 페어 리스트를 콜백에 넘김. 호출자가 old array를 즉시 delete하거나 다른 자료구조에서 링크 교체하는 데 씀. 콜백 미지정 시 전체 목록을 반환.
• copy_aliased_arrays — jax tree에서 같은 array 객체를 두 번 참조하는 aliased 케이스에서 두 번째 참조 이후로는 may_alias=False device_put으로 실 사본을 만든다. streamed load가 배치 단위로 새 array로 교체하면서 aliased 참조가 원본을 놓치지 않도록 하는 사전 처리 헬퍼.
• plan.sort(key=lambda item: item[3], reverse=True) — 큰 텐서부터 처리. window packing 효율성 확보 (max_leaf 이상은 어차피 그 텐서 하나뿐인 배치가 되므로 앞으로 몰아 넣음).

load_checkpoint 자체도 리팩터링 — 헬퍼 함수 5개(_build_read_plan, _pack_read_batches, _convert_domains, _open_tensor, _drain_read_futures) 추출로 인라인 로직이 정리됐고 (streamed 버전이 그 헬퍼들을 재사용), 예외 로깅이 rank_logger 통일. 별도 logger = logging.getLogger("checkpointing") 인스턴스가 제거된 대신 rank_logger 단일 채널로 수렴.

Trainer.warm_start_staging_spec 신규 훅 (phoenix/xrex/train/trainer.py:1160-1165) — checkpoint에서 params만 복원하고 opt_state는 재초기화하려는 케이스에서 pinned-host에도 opt_state 사본을 만들지 않는다. 이전엔 restore용 staging sharding으로 device_put할 때 전체 state 구조가 pinned-host로 올라갔는데, 이제 warm_purge(self.state)로 opt_state를 미리 잘라내고 pinned-host stage 후 로드된 부분만 다시 device_put + 원래 opt_state field는 유지. RecsysTrainer.warm_start_staging_spec이 서브클래스 오버라이드로 keep_emb_opt_state=True 옵션 지원. 의미: warm start restore가 훨씬 가벼워짐 — flagship Muon 학습이 pretrained params에서 시작하고 optimizer는 fresh하게 시작하는 흐름이 표준화됐다는 방증 [추정].

admission.reset_estimates + request_metrics.reset_admission_estimates — Phoenix 서빙의 admission controller가 유지하는 service_time·pipeline_time EWMA를 zero로 리셋 가능. 대응 Prometheus gauge도 0으로. 회귀 테스트 두 개(reset_estimates_clears_s_and_p, reset_admission_estimates_clears_gauges_and_p). 왜 필요한지는 diff에 힌트가 없지만 hot-swap이나 트래픽 프로파일 급변 후 EWMA를 즉시 초기화하려는 용도 [추정]. 4세대+6의 _glibc_malloc_trim() swap 후처리와 결이 통한다.

copy_port_client 로깅 정리 — dense weights load와 emb_table load 완료 로그에 총 바이트·경과·GB/s 병기(divide-by-zero 가드 포함). "downloading dense weights prefix=... futures=..." 시작 로그는 삭제(끝 로그가 이제 요약 정보를 담아 시작 로그 불필요).

1-B. trainer_recsys의 valid_step 게이팅 통일

phoenix/xrex/train/trainer_recsys.py(+29/−19)의 두 학습 루프(dense sync + async_no_deferred)에서 param update 조건이 통일됐다. [확인] — phoenix/xrex/train/trainer_recsys.py:1331-1400.

이전 순서:

1. valid_step = is_valid_step(gradients) — dense grad-norm 검사
2. dense params update — jnp.where(valid_step, updated, original)
3. segment_sum + is_valid_step(emb_gradients) — emb grad-norm 검사
4. emb table update — sparse_update(..., valid_step=emb_valid_step)
5. metric valid_step = valid_step & emb_valid_step

변경 후:

1. dense grad-norm 검사 → valid_step
2. 먼저 segment_sum + emb grad-norm 검사 → emb_valid_step
3. keep_step = valid_step & emb_valid_step
4. dense params update — jnp.where(keep_step, updated, original)
5. emb table update — sparse_update(..., valid_step=keep_step)
6. metric valid_step = keep_step

즉 dense와 embedding 어느 한 쪽이라도 grad-norm 검사가 실패하면 양쪽 다 원본으로 유지된다. 이전엔 dense가 통과하고 emb만 실패하면 dense params는 새 값으로 갱신되고 emb만 롤백되는 비대칭 상태가 몇 스텝 발생할 수 있었다. 이제 파라미터·embedding table이 lock-step으로 움직인다.

async 경로(update_async_deferred)도 같은 통일 — pending=jnp.asarray(True)에서 pending=keep_step으로 바뀌면서, 비동기 emb gradient update가 이번 스텝의 gate 결과를 반영해 다음 스텝에 실제로 반영될지가 결정된다. 그리고 _create_async_emb_executables의 assert self.grad_norm_keep_threshold is None 제거 — 이전엔 async deferred 경로가 grad-norm 게이팅과 호환되지 않는다는 가정이었는데, 이제 async에서도 그 threshold를 실제로 소비.

1-C. grox reply_spam LM 프롬프트에 팔로워 카운트/bio 주입 옵션 + Manhattan write monotone-only

두 축 — LM 판정 컨텍스트가 확장되고, Manhattan write가 monotone-only 게이트 획득. 답글 스팸/랭킹 판정 신뢰도와 서빙 안정성 양쪽을 건드림.

LM 컨텍스트 확장 [확인] — grox/core/lm/post.py (+18/−6), grox/core/lm/thread.py (+25/−4):

이전 PostRenderer.render()가 유저 메타를 Metadata: <name> @<handle> 한 줄로 뽑던 것을 셋으로 분리:

User Handle: @<handle>
[User Follower Count: <N>]     # include_follower_count=True일 때
User Name: "<name>"
[User Bio: "<bio>"]              # include_bio=True일 때

ThreadRenderer._render_thread가 include_follower_count 인자 신설 → 스레드의 모든 포스트는 팔로워 카운트 포함, 오직 post 0(원본, 스레드 root)만 bio 포함. 답글 대상(마지막 post — reply-under-eval)도 팔로워 카운트 포함. 그리고 메시지 앞에 # Reply Author Info 헤더가 추가돼 LLM에게 "이 정보는 evaluate하려는 reply 작성자에 관한 것"이라고 명시적 컨텍스트 힌트를 준다.

Manhattan write monotone-only [확인] — grox/flows/reply_spam/task_write.py:113-138 (+22):

_publish_to_reply_ranking_manhattan 안에서 ReplyRankingScoreStratoLoader.fetch_reply_ranking_score(post.id)로 기존 스코어를 조회 → 새 스코어가 기존보다 크면 쓰기 스킵(Metrics.counter("task.write_reply_ranking_manhattan.skipped.count", reason="higher_than_existing") 증가), 낮으면 그대로 쓰기. 즉 이 채널로 나가는 답글 랭킹 스코어는 시간에 따라 낮아지기만 하고 오르지 않는다.

1-D. VF TesHydrator media fallback cache 통째 제거

visibility-filtering/hydration/tes_hydrator.rs(+4/−292)에서 1M-entry LRU 기반 fallback cache가 통째로 삭제됐다. 관련 config env 두 개(VF_MEDIA_FALLBACK_CACHE_SERVE_STALE_ENABLED, VF_MEDIA_FALLBACK_CACHE_POPULATE_ENABLED)도 visibility-filtering/config.rs (0+/20−)에서 제거. server_deps.rs의 배선(9줄)과 hydration/mod.rs의 인자(2줄), HydrationPipeline::new의 media_fallback_cache_mode 파라미터도 삭제.

이전 로직:

• TES(Tweet Entity Service, X 내부 트윗 메타데이터 서비스)에서 media entity를 조회하는데, TES가 실패해서 media feature가 안 나오면 이전 성공한 조회의 캐시를 유지하고 서브shequent 조회 실패 시 stale하지만 유효한 media feature로 대체(FallbackCacheMode::ServeStale). 또는 캐시만 채우고 서빙엔 안 씀(FallbackCacheMode::Shadow).
• 크기는 1,000,000 (CACHE_CAPACITY = 1_000_000). LRU 축출. 292줄 중 상당 부분이 MediaFailingAfterFirstClient mock을 이용한 회귀 테스트 두 개(media_stale_recovery_respects_cache_mode, no_media_tweets_cache_default_entries_that_serve_stale).

1-E. Dark traffic canary opt-out

visibility-filtering/dark_traffic_setup.rs(+40/−17)의 should_enable(ordinal, max_ordinal) 함수가 should_mirror(workload, ordinal, max_ordinal)로 확장 [확인] — 다음 규칙 추가:

• workload=None(env WORKLOAD_NAME 미설정): fail-closed, mirror 안 함.
• workload.ends_with("-canary"): mirror 안 함. 즉 canary 워크로드는 절대 dark traffic 미러링 안 됨.
• 그 외: 기존 ordinal < max_ordinal 판단.

새 테스트 두 개: canary_never_mirrors, missing_workload_name_fails_closed. 로그 메시지도 "disabled (ordinal >= max)"에서 "disabled (not a mirror host)"로 일반화.

1-F. 광고 conversion 헤드 3종 신설 + conv_asset_ids 배선

phoenix/python/common/xai-proto/proto/recsys.proto (+12) [확인]:

새 ActionName 3종:

• 191 ADS_PIXEL_FIRE — 광고주가 자기 사이트에 심어둔 전환 픽셀이 발화. 웹 컨버전 이벤트.
• 192 ADS_LONG_DWELL_AND_PIXEL_FIRE — 픽셀 발화 AND long dwell(랜딩 페이지에 오래 머무름) 결합 이벤트. LONG_DWELL_AFTER_CLICK(158)과 ADS_PIXEL_FIRE(191)의 AND.
• 193 P_LONG_DWELL_AND_PIXEL_FIRE — 접두 P_는 "primary" 또는 "predicted"의 뜻 [추정] — 4세대+6의 광고 conversion 20개 확장에서 관찰된 명명 관행상 primary conversion 라벨의 predicted target을 시사.

같은 커밋에서 SlateContext에 reconCosMilli = 13 필드 배선(proto 측). home-mixer의 SlateContext에도 이 문서에서 볼 수 있듯 어제 4세대+8까지 recon_cos_milli가 있었는데, 이번엔 recon_count_above: Option<u32>, recon_gap_above: Option<u32> 두 개가 추가돼 slate context 재구성 계산이 세분화됐다. proto 반영은 아직 없음 (proto엔 reconCosMilli만) — home-mixer 로컬 배선이 proto 이관 대기 상태.

PredictNextActionsRequest.conv_asset_ids — 새 message ConvAssetIds가 repeated int64 impressed_time_ms / author_id / asset_id 3배열 구조로 신설. Phoenix 서빙에게 유저가 이전에 노출된 conversion asset(광고 크리에이티브)의 이력을 전달. 광고 창작물 attribution — 같은 asset이 여러 광고주에 재사용되거나 유저가 같은 asset을 여러 번 봤을 때 컨버전 예측에 이 이력을 참조 [추정].

1-G. Retrieval 유저 타워에 use_history_segment_ids 플래그

phoenix/xrex/models/recsys_two_tower_model.py (+12/−1) [확인] — user tower에서 attention의 segment id를 zeros가 아니라 히스토리 토큰에 대해 별도 HISTORY_SEGMENT_ID(from xrex.pallas.ranker_attention_utils)로 부여할 수 있게. RecsysTwoTowerModelConfig.use_history_segment_ids: bool = False config 플래그(기본 off).

새 함수 user_tower_segment_ids(batch, seq_len, use_history_segment_ids) — 플래그 켜면 shape (B, T) 전체를 HISTORY_SEGMENT_ID로 채움 (즉 유저 히스토리 토큰이 하나의 segment로 묶임), 끄면 이전과 같이 zeros. xrecsys_two_tower.py config에 관련 default 세팅. 의미: pallas flash-attention의 varlen 커널이 segment mask로 attention scope를 자를 때, 유저 히스토리 시퀀스 안에서 세그먼트 경계를 명시할 수 있게 준비. 이전엔 zeros 하나로 전체가 한 세그먼트라 세그먼트 mask 자체가 의미 없었지만, 이제 다른 segment id를 가진 특수 토큰(예: user_features 토큰)과 히스토리 토큰이 attention을 넘나들지 않게 격리 가능. varlen packing 정확도 향상.

정본 반영 정리

• ../services/x.md — 위 서브섹션 각각에 subsection 추가·확장 (구체 위치는 각 절 끝의 "정본 반영" 지시)
• ../services/x.md — 4세대+9 열린 질문 항목 추가

2. AMBER — Meta AI, "Event Tokenization"으로 이벤트를 단일 LLM 토큰으로 압축 (레이더)

• Event Tokenization — 한 상호작용 이벤트의 "temporal snapshot"(유저·아이템·컨텍스트·outcome 신호 전부)를 하나의 compact Event Token으로 압축 [확인]
• 이 Event Token이 LLM의 새 입력 유형으로 자리 잡음. 오프라인 산업 규모 랭킹·retrieval 벤치마크에서 "compute-quality Pareto frontier" 개선 [확인]
• Event Token이 non-LLM 랭커에 feature로 이식 가능 (transferability) — 통계적으로 유의한 개선 [확인]
• Facebook surface에서 하루 수십억 이벤트 인코딩 서빙 [확인] HTML에서 "supporting online encoding for billions of events per day" 언급

3. TransRetrieval — Alibaba Alimama, Transformer scaling law를 광고 retrieval에 적용 (레이더)

• Weighted average aggregation — heterogeneous field들의 token-norm divergence를 억제해 Transformer가 스케일링될 수 있게 하는 aggregator [확인]
• Target token compression — per-candidate compute 85% 절감 [확인]
• Position-style domain embedding — cross-domain 데이터를 최소 오버헤드로 통합 [확인]
• Alibaba 디스플레이 광고 플랫폼 프로덕션 A/B, 한 달 [확인]:

"lifts platform revenue by 2.53% under the same end-to-end latency constraint as the production baseline" — TransRetrieval HTML, 2026-08-26

• 정확한 수치: revenue +2.53% (95% CI [2.22%, 2.70%], p<0.0001), RPM +1.28% (CI [1.14%, 1.56%], p<0.0001), 4 도메인 분산: Domain A +1.72%, B +2.51%, C +5.39%, D +0.87%. P99 지연 ~40ms 유지 [확인].

4. SWIM — Kuaishou 메인 피드 재순위 evaluator (레이더)

• SWIM — 유저 행동을 finite-horizon prefix session-level survival process로 모델링 [확인]
• 현재 리스트가 세션 목표에 얼마나 기여하는지를 (a) recursive survival distribution + (b) reached-position conditional rewards로 factorize [확인]
• Kuaishou 메인 피드 재순위 프로덕션 배포 [확인]:

"Kuaishou short-video application (>400M DAU, >2 hours average daily engagement) ... 7 days, 5% traffic allocation" — SWIM HTML, 2026-08-25

• 정확한 수치: App stay time +0.351% (95% CI [0.27%, 0.42%]), 7-day retention +0.048% (CI [0.01%, 0.09%]) [확인]
• 배포는 CAVE(이전 evaluator)를 SWIM으로 교체 — upstream retrieval/generator는 유지.

레이더

radar.md 이번 달 신규 절에 AMBER(Meta)·TransRetrieval(Alibaba Alimama)·SWIM(Kuaishou) 3건 추가. 관찰 스레드는 (a) LLM-native 랭킹 확산에 Meta AMBER 유형(입력 인코더) 각도 추가, (b) 추천 모델 스케일링 법칙에 Alibaba 광고 라인 첫 진술 추가 (세 번째 회사).

다음에 볼 것

• 4세대+9 열린 질문: ThrottledD2HArrayHandler의 프로덕션 save_concurrent_gb 튜닝 값과 저장 시간 증가폭, load_checkpoint_streamed의 어느 조건에서 load_checkpoint(v1)를 대체하는지 (기본 restore가 아직 v1 유지), warm_start_staging_spec의 첫 활성 config (flagship에 이미 반영됐는지), Manhattan reply_ranking monotone-only write가 실제 label flap 관측을 뒤집는 데이터, VF media fallback cache 제거 후 TES 실패 시 media feature 실제 fail-close 비율, ADS_PIXEL_FIRE·ADS_LONG_DWELL_AND_PIXEL_FIRE의 학습·서빙 배선 (아직 recsys_model.py에는 등장 안 함), conv_asset_ids의 실 소비자, use_history_segment_ids의 프로덕션 승격 시점.
• AMBER의 A/B 수치 — abstract·HTML에 online lift가 명시 안 됨. 후속 블로그 또는 논문 개정판에서 나올지.
• TransRetrieval + Alimama 광고의 후속 회사 재현. 세 번째 회사의 retrieval 스택 스케일링 진술이 나오면 topics/embedding-retrieval.md 절 승격 검토.