2026-08-10

1. GenRec의 서빙 층이 별도 블로그로 공개됐다 — Netflix

이 구조가 중요한 이유는 서빙 비용이다. 후보 하나당 LLM을 한 번씩 돌리는 게 아니라 후보 집합 전체를 1패스로 처리하므로 생성 단계(decode)가 사실상 필요 없다 — 프롬프트를 읽어 내부 상태만 만드는 prefill 단계만 쓴다. 오늘 자료는 그 prefill 전용 워크로드를 위해 Netflix가 어떤 엔진을 골랐고, 그 엔진에서 무엇이 병목이었는지에 대한 글이다.

• GenRec이 서빙 스택 선정 기준의 4대 워크로드 중 하나로 명시 열거된다 [확인] — "prefill-only inference for ranking and retrieval" 가 Netflix가 TensorRT-LLM에서 vLLM으로 옮기게 만든 워크로드 확장의 한 축이라고 블로그가 직접 쓴다. 전환은 2025년 여름, V1 마이그레이션은 Q4 2025. GenRec이 실험적 부산물이 아니라 인프라 채택 이유 자체에 들어가 있다.

• constrained decoding의 배치 스케일링이 GenRec 배치 서빙의 상한을 결정한 사건이었다 [확인] — constrained decoding은 모델이 정해진 후보 목록 밖의 토큰을 못 고르게 막는 처리다. vLLM V0에서는 이걸 커스텀 logits processor로 구현했는데 Python GIL 때문에 요청별 순차 실행이 됐다.

  "CPU time in logit processing therefore grows linearly with batch size" — In-House LLM Serving at Netflix (블로그), 2026-07-17

  V1에서 batch-level 처리 + hot path를 C++로 + multi-threading으로 재구현해 "logits processing time staying flat as batch size grows" 를 얻었다. GenRec의 "후보 집합 전체 1패스" 채점이 배치 스케일에서 왜 성립하는지에 대한 하드웨어·엔진 쪽 답이다.

• "special snowflake 없음" 원칙으로 LLM 서빙을 기존 스택에 통합한다 [확인]

  "Every model — XGBoost ensemble or large-scale LLMs — is scored via the same gRPC call" — 같은 블로그, 2026-07-17

  OpenAI-compatible API는 추가 프론트엔드로만 얹었다. 소형 모델은 CPU in-process, 대형은 원격 MSS(Model Scoring Service)로 보낸다.

• 아키텍처 구성요소 확인 [확인] — MSS · Triton · Java control plane, FSx pre-materialization(모델 가중치를 미리 파일시스템에 풀어 두는 것), 배포는 Red-Black과 Versioned 두 방식.

• services/netflix.md — GenRec 절 아래 "GenRec의 서빙 층 — 별도 블로그로 공개 (2026-07)" 소절 신규. 엔진 전환 시점, 4대 워크로드 열거, MSS·Triton·Java control plane, "no special snowflakes" 원칙, FSx pre-materialization, constrained decoding batch-level 재구조, Red-Black vs Versioned. 출처 절에 이 블로그 추가
• topics/llm-in-recsys.md — Netflix 케이스에 각주 한 문단: GenRec이 vLLM 채택의 4대 워크로드에 명시 열거된다는 사실

그리고 "LLM 랭커를 넣었다"는 진술 뒤에 엔진 층의 재구현이 깔려 있다 [추정] — 배치 스케일이 성립하려면 logits 처리를 batch-level로 다시 쓰는 작업이 선행돼야 했다는 게 근거다. 단 블로그는 그 재구현을 누가 했는지(vLLM 업스트림인지 Netflix인지) 밝히지 않으므로 "Netflix가 엔진을 고쳤다"고까지는 쓰지 않는다.

2. GEM의 훈련 인프라 — LLM 스택이 추천으로 그대로 넘어오지 않는다 — Meta (광고)

MFU(Model FLOPs Utilization)는 GPU가 이론 성능 대비 실제로 몇 %를 쓰고 있는지의 지표다. 대규모 훈련에서 이 숫자가 낮으면 GPU를 사놓고 노는 것이므로 인프라 팀의 1차 목표가 된다.

• 12개월간 MFU 2배 · 총 FLOPs 4배, 현재 E2E MFU 20~25% [확인]

• LLM용 인프라가 추천으로 직접 이전되지 않는다는 자기 진술 [확인]

  "AI infrastructure optimized for LLM training ... does not directly transfer, requiring significant innovation and hardware/software co-design" — Training GEM at LLM Scale (블로그), 2026-08-03

  실제로 새로 만든 것들: 커스텀 커널(JFA · GDPA · BlockAttention), MXFP8 저정밀 학습, 5D 병렬화, SM-free collectives. 추천 워크로드의 sparse embedding · jagged tensor(길이가 제각각인 시퀀스 텐서) · 이질적 attention이 LLM 훈련 스택과 근본적으로 다르다는 뜻이다.

• DHEN이 GEM 안에 expert 모듈로 살아있다는 게 처음 명시됐다 [확인] — 본문에 "Deep Hierarchical Ensemble Network experts". 지금까지 계보 표의 GEM 항목을 "Wukong + InterFormer 통합"으로만 이해하고 있었는데, 실은 DHEN도 그 안에 흡수돼 있다.

• topics/sequence-transformer-ranking.md — 계보 B 표에 "2026-08 GEM training" 행 추가 / GEM training 인프라 절 신규(커스텀 커널 · MXFP8 · 5D 병렬 · DHEN이 GEM 내부 expert로 잔존) / 출처에 이 블로그 추가

검증에서 뒤집힌 것 — 어제 반영한 LLaTTE 인용 3건이 블로그 원문에 없다

[관찰] 2026-08-10 원문을 다시 받아 /tmp/llatte-blog.html에 저장하고 grep으로 대조했다. 어제 정본에 넣은 인용 4건 중 3건이 블로그 본문에 없다.

• ❌ "Deployed as the largest user model at Meta" — 원문에 없음

• ❌ "4.3% conversion uplift on Facebook Feed and Reels" — 원문에 없음. 블로그의 실제 A/B 진술은 "a cumulative lift of 6% in conversions on Instagram, 3% in conversions on Facebook and 3.5% in ad clicks on Facebook" 이고, "cumulative" 와 "our broader model innovations" 가 붙어 있어 LLaTTE 단독 효과가 아니다

• ❌ "semantic features bend the scaling curve: they are a prerequisite for scaling" — 원문에 "prerequisite" 이라는 단어가 없다. 대응 문장은 훨씬 완화된 표현이다:

  "Semantic content features from foundation models complement traditional collaborative filtering... especially helpful in cold-start scenarios" — From User Sequences to Scaling Laws (블로그), 2026-08-05

• ✓ "a two-stage architecture that offloads the heavy computation..." — 이 한 건은 원문에 존재 확인

어떻게 처리했나 topics/sequence-transformer-ranking.md LLaTTE 절에 재검증 실패 flag를 붙이고, 블로그의 실측 A/B(6% / 3% / 3.5%, cumulative)로 교체했다. dense tokenization과 target-aware attention의 정식화는 원문 인용으로 다시 실었다.

[추정] 위 3건은 LLaTTE 논문(arXiv 2601.20083)에서 나왔을 가능성이 높다. 어제 정본이 논문 문장을 블로그 인용으로 표기했을 것으로 본다. 확정하려면 논문 원문 대조가 필요하다 — 심층 분석 필요로 남긴다.

교훈 두 개

1. 어제의 적대적 검증 2판을 통과했던 인용이 오늘 원문 재수집에서 결함이 나왔다. 적대 검증은 "쓰여 있는 게 서로 맞는가"를 보고, 원문 재수집은 "원문에 실제로 있는가"를 본다 — 다른 검사다.
2. Meta 블로그는 URL이 같아도 편집될 수 있다 [추정](발표 후 문구를 조정하는 관행이 있어 보인다). 그리고 논문과 블로그를 병기하는 계보 절에서는 인용 출처가 섞이기 쉽다. → 앞으로 모든 인용 옆에 (블로그) / (논문)을 명시한다. 이 규칙은 CLAUDE.md 링크 규칙에 넣었다.

레이더

arXiv cs.IR 신규 제출 30건을 triage해서 2건이 수용 기준을 통과했다. 둘 다 radar.md "이번 달 신규"에 추가하고 최종 갱신을 2026-08-10으로 올렸다.

• Gryphon-v2 (Yandex Music) — arXiv 2608.06213, 2026-08-06. 유저 이력 1회 인코딩 → Semantic-ID 후보 생성 → 공유 인코더 상태를 재사용하는 item-level 랭커로, retrieval + rerank + rank를 단일 모델로 대체한다. 프로덕션 A/B에서 "replaces the production cascade of 15+ candidate generators, pre-ranking and final ranking", active users +1.41% [확인]. GenRec과 정면으로 대응하는 두 번째 프로덕션 진술이다 — GenRec은 랭킹 경로만 LLM인 반면 이쪽은 retrieval까지 통합했다.
• Multi-Objective Ranking for Live-Streaming (Twitch, Amazon) — arXiv 2608.04455, 2026-08-05. 라이브 스트리밍에서 즉시 신호(click, initial watch)와 지연 신호(session length, retention)의 시간 스케일이 다른 문제를 delayed window collection + multi-model architecture로 나눠 학습한 뒤 결합한다. mobile live feed 온라인 A/B에서 DAV·ARPU 유의미 개선 진술 [확인]. Netflix 라이브 콜드스타트(RecSys 2025)와 인접하지만 이쪽은 일반 라이브 피드 다목적 랭킹이다.

나머지 28건은 순수 학술 증분 또는 도메인 한정으로 탈락했다.

다음에 볼 것

• LLaTTE 논문 원문 대조 — 위 3건이 arXiv 2601.20083 본문에 있는지 확인해 등급을 정정한다. [관찰] 2026-08-10 시점 미해소 (심층 분석 필요)
• Meta GEM training 후속 — 광고 파운데이션 모델의 훈련 스택이 사실상 별도 문서 계열이 됐다. topics/training-infra.md 신설이 필요할 수 있으나 X·Netflix에 대응 자료가 없어 지금은 YAGNI로 대기
• Gryphon-v2 vs Netflix GenRec — 두 프로덕션 진술이 generate-and-rank의 두 극단(retrieval 통합 vs 랭킹만)을 보여준다. 세 번째 회사의 진술이 나오면 topics/llm-in-recsys.md에 새 절
• GenRec 실시간 지면 적용 여부 — 어제 열린 질문. 오늘도 후속 글 없음. 유지