0x00

리서치 / 일일 리포트

  • 읽은 자료 4건
  • 정본 반영 4개 파일
  • 레이더 2건
  • 어제 인용 결함 3건 발견
한 줄 요약Netflix는 LLM 랭커 GenRec의 서빙 인프라를, Meta는 광고 파운데이션 모델 GEM의 훈련 인프라를 공개했다. 둘 다 모델이 무엇인지가 아니라 그 모델을 어떻게 돌리는지를 설명한다.

오늘 함께 본 다른 변화는 다음과 같다.

  • 어제 정본에 넣은 LLaTTE(Meta 광고의 유저 모델) 인용 4건 가운데 3건이 Meta 블로그 원문에 없었다.
  • arXiv cs.IR 신규 제출 30건 가운데 Yandex Music의 Gryphon-v2와 Twitch·Amazon의 라이브 스트리밍 다목적 랭킹 논문을 레이더에 올렸다.

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

자료 In-House LLM Serving at Netflix — netflixtechblog, 2026-07-17, 블로그. 관찰 2026-08-10에 원문 URL이 Medium 리다이렉트로 열리지 않아, archive.org의 2026-07-28 스냅샷으로 본문을 확보했다.

배경 GenRec은 Netflix가 쓰는 LLM 기반 랭커다(services/netflix.md GenRec 절). 오해하기 쉬운 점이 하나 있다. GenRec은 추천 결과를 문장으로 생성하지 않는다. LLM 백본이 유저 이력을 읽어 pooled hidden state(토큰별 은닉 상태를 하나로 모은 벡터)를 하나 만들고, 그 상태를 학습된 아이템 임베딩과 결합해 점수를 낸다. 결합 방식은 원문이 예시로만 적어 열어 두었다 확인: "(e.g., via dot product or small MLP)". 즉 LLM은 유저 표현을 만드는 인코더이고, 점수를 매기는 쪽은 여전히 임베딩 기반이다.

이 구조가 중요한 이유는 서빙 비용에 있다. GenRec은 후보마다 LLM을 한 번씩 돌리지 않고 후보 집합 전체를 1패스로 처리한다. 그래서 토큰을 생성하는 decode 단계가 사실상 필요 없고, 프롬프트를 읽어 내부 상태만 만드는 prefill 단계만 쓴다. 이번 글은 이 prefill 전용 워크로드를 위해 Netflix가 어떤 엔진을 골랐고, 그 엔진에서 무엇이 병목이었는지를 설명한다.

새로 알게 된 것A. GenRec은 실험적 부산물이 아니라 Netflix가 서빙 인프라를 채택한 이유 자체에 들어가 있다

  • GenRec은 Netflix가 서빙 스택을 고를 때 기준으로 삼은 4대 워크로드 가운데 하나로 명시되어 있다 확인.
    • 블로그는 이 워크로드가 Netflix를 TensorRT-LLM에서 vLLM으로 옮기게 만든 워크로드 확장의 한 축이라고 직접 밝힌다: "prefill-only inference for ranking and retrieval".
    • 엔진 전환은 2025년 여름에 이뤄졌고, V1 마이그레이션은 Q4 2025에 진행했다.

새로 알게 된 것B. V1에서 constrained decoding을 다시 만들어 배치가 커져도 logits 처리 시간이 늘지 않게 됐다

  • constrained decoding의 배치 스케일링이 GenRec 배치 서빙의 상한을 결정했다 확인. constrained decoding은 모델이 정해진 후보 목록 밖의 토큰을 고르지 못하게 막는 처리다.

    • vLLM V0에서는 이 처리를 커스텀 logits processor(모델이 낸 토큰별 점수를 샘플링 전에 고치는 함수)로 구현했는데, Python GIL 때문에 요청마다 순차적으로 실행됐다.

    • 그래서 logits 처리에 드는 CPU 시간이 배치 크기에 비례해 늘었다.

      "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 처리 시간이 늘지 않았다: "logits processing time staying flat as batch size grows".

    • 이 내용은 GenRec의 "후보 집합 전체 1패스" 채점이 배치 규모를 키워도 성립하는 이유를 하드웨어와 엔진 쪽에서 설명해 준다.

새로 알게 된 것C. LLM 서빙도 예외로 두지 않고 기존 스택에 통합한다

  • Netflix는 "special snowflake 없음" 원칙에 따라 LLM 서빙도 예외로 두지 않고 기존 스택에 통합한다 확인. XGBoost 앙상블이든 대형 LLM이든 모든 모델을 같은 gRPC 호출로 채점한다.

    "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)로 보낸다.

새로 알게 된 것D. 서빙 스택은 MSS, Triton, Java control plane을 쓰고 두 가지 방식으로 배포한다

  • 아키텍처 구성 요소를 확인했다 확인.
    • 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과 Versioned의 대비도 담았다.
  • topics/llm-in-recsys.md의 Netflix 사례에 각주 한 문단을 붙였다. GenRec이 vLLM 채택의 4대 워크로드에 명시적으로 열거된다는 내용이다.

의미 Meta와 Netflix는 서로 다른 축으로 통합하고 있다. Meta는 인덱스와 모델을 합쳤고(SilverTorch가 말하는 "index as model"로, topics/embedding-retrieval.md에 정리해 두었다), Netflix는 XGBoost와 PyTorch와 LLM을 하나의 호출 인터페이스로 합쳤다 추정. 두 회사가 서로를 언급하지 않으므로 이 대비는 우리 쪽 해석이다.

또 "LLM 랭커를 넣었다"는 진술 뒤에는 엔진 층의 재구현이 놓여 있다 추정. 근거는 배치 규모를 키워도 성능을 유지하려면 logits 처리를 batch-level로 다시 작성하는 작업이 먼저 필요했다는 점이다. 다만 블로그는 그 재구현을 vLLM 업스트림과 Netflix 가운데 누가 했는지 밝히지 않으므로, "Netflix가 엔진을 고쳤다"고까지는 쓰지 않는다.

↑ 목차

2GEM 훈련에는 LLM 훈련 스택을 그대로 쓸 수 없었다 — Meta (광고)

자료 Training GEM at LLM Scale — engineering.fb.com, 2026-08-03, 블로그

배경 GEM은 Meta 광고 랭킹의 파운데이션 모델이고, 계보상 DHEN → Wukong → InterFormer의 후속이다(topics/sequence-transformer-ranking.md 계보 B). 지금까지 우리 정본은 GEM을 모델 구조로만 다뤘다.

MFU(Model FLOPs Utilization)는 GPU가 이론 성능 대비 실제로 몇 %를 쓰고 있는지 나타내는 지표다. 대규모 훈련에서 이 값이 낮으면 사 둔 GPU를 놀리는 셈이므로, MFU를 올리는 일이 인프라 팀의 1차 목표가 된다. 이번 글은 GEM을 어떻게 학습시키는지, 그리고 왜 LLM 훈련 스택을 재사용할 수 없었는지를 설명한다.

새로 알게 된 것A. 12개월 동안 MFU가 2배가 됐다

  • 12개월 동안 MFU는 2배, 총 FLOPs는 4배가 됐다 확인.
  • 현재 E2E MFU는 20~25%다 확인.

새로 알게 된 것B. Meta는 LLM용 훈련 인프라가 추천에 그대로 통하지 않는다고 밝히고, 커널과 저정밀 학습과 병렬화를 새로 만들었다

  • Meta는 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 훈련 스택과 근본적으로 다르다는 뜻이다.

새로 알게 된 것C. DHEN도 GEM 안에 expert 모듈로 흡수되어 있다

  • 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로 남아 있다는 점을 담았다.

의미 "추천 모델도 LLM처럼 스케일한다"는 주장(radar.md 스케일링 법칙 스레드)은 그대로 유지되지만, 스케일의 비용 구조가 다르다는 반례가 붙었다. 스케일링 법칙이 성립하더라도 LLM 훈련 스택을 그대로 재사용할 수 없다면, 진입 장벽은 모델 설계가 아니라 커널과 병렬화 쪽에 남는다 추정.

또 계보 표의 정확도가 한 단계 올라갔다. "Wukong·InterFormer 통합"이라는 이해는 그대로 유효하고, 여기에 DHEN도 그 안에 들어 있다는 사실이 더해졌다.

↑ 목차

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

자료 From User Sequences to Scaling Laws — engineering.fb.com, 2026-08-05, 블로그. 어제 이미 반영한 자료를 인용 재검증 목적으로 다시 읽었다.

관찰 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 절에 재검증 실패 표시를 붙이고, 블로그가 실제로 밝힌 A/B 수치(6% / 3% / 3.5%, cumulative)로 교체했다. dense tokenization과 target-aware attention의 정식화는 원문 인용으로 다시 실었다.

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

이번 일에서 얻은 교훈은 두 가지다.

  1. 적대적 검증과 원문 재수집은 서로 다른 검사다. 어제 적대적 검증 2판을 통과한 인용이 오늘 원문 재수집에서 결함을 드러냈다. 적대적 검증은 "쓰여 있는 내용끼리 서로 맞는가"를 보고, 원문 재수집은 "원문에 실제로 있는가"를 본다.
  2. 앞으로 모든 인용 옆에 (블로그) / (논문)을 명시한다. 이 규칙은 CLAUDE.md 링크 규칙에 넣어 두었다. 이유는 두 가지다.
    • Meta 블로그는 URL이 같아도 편집될 수 있다 추정. 근거는 발표한 뒤에 문구를 조정하는 관행이 있어 보인다는 점이다.
    • 논문과 블로그를 함께 적는 계보 절에서는 인용 출처가 섞이기 쉽다.

↑ 목차

레이더

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

  • Yandex Music의 Gryphon-v2는 retrieval과 rerank와 rank를 단일 모델로 대체한다(arXiv 2608.06213, 2026-08-06).
    • 유저 이력을 1회 인코딩하고 Semantic-ID(아이템을 계층 코드로 표현한 토큰 열)로 후보를 생성한 다음, 공유 인코더 상태를 재사용하는 item-level 랭커로 이어지는 구조다.
    • 프로덕션 A/B에서 기존 cascade를 대체한다고 밝혔고, active users는 +1.41% 늘었다 확인. 원문 표현은 이렇다: "replaces the production cascade of 15+ candidate generators, pre-ranking and final ranking".
    • GenRec과 정면으로 대응하는 두 번째 프로덕션 진술이다. GenRec은 랭킹 경로만 LLM으로 처리하는 반면, 이쪽은 retrieval까지 통합했다.
  • Twitch·Amazon의 Multi-Objective Ranking for Live-Streaming(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건은 순수 학술 증분이거나 도메인이 한정되어 탈락했다.

↑ 목차

다음에 볼 것

↑ 목차