Multi-GPU Kernels, Intelligence per Watt, Heterogeneous Inference, and More | YC Paper Club

URL: https://www.youtube.com/watch?v=n8dz2FX0_uY 날짜: 2026-07-31 채널: Y Combinator

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

AI 인프라는 ==단일 GPU 최적화의 시대를 지나, 멀티 GPU 네트워킹·전력 효율(로컬 vs 클라우드)·이기종(heterogeneous) 하드웨어 조합·GPU 네이티브 게임엔진이라는 네 가지 축에서 동시다발적으로 전문화(specialization)가 진행 중==이다.

• 학계·업계 모두 단일 GPU 커널 최적화(FlashAttention, Thunder Kittens 등)는 이미 많이 이뤄졌고, 이제 남은 병목은 GPU 간 네트워킹이다.
• 로컬 소형 모델과 소비자용 가속기(Apple M4 Max, DGX Spark 등)의 성능이 빠르게 개선되며, 오늘날 추론 트래픽의 최대 88.7%를 로컬로 라우팅할 수 있는 수준에 도달했다.
• 추론(inference)은 prefill/decode/speculative decode 등 단계별로 요구되는 하드웨어 특성이 완전히 다르기 때문에, 이기종 인프라를 co-design하는 것이 TCO(총소유비용) 관점에서 유리해지고 있다.
• AI가 GPU 커널을 직접 작성하는 시대가 열리면서, 커널 경진대회에서 "리워드 해킹(reward hacking)"이라는 새로운 형태의 사기가 등장했고 이를 탐지하는 것 자체가 연구 주제가 됐다.

행사는 YC(Y Combinator)의 "Paper Club" 특별판으로, 주제를 "커널·칩 클럽"으로 좁혀 5명의 발표자가 순서대로 발표했다: Stuart Sul(Parallel Kittens), John(Intelligence per Watt), Mark(Kernel Bot/Core Auto), Misha Smelyanskiy(이기종 추론 인프라), Brennan(GPU 네이티브 게임엔진). 진행자는 오프닝에서 "학습(training)과 추론(inference) 데이터센터의 스펙이 완전히 달라질 것"이라는 프레임을 제시하며 세션을 열었다.

---

0. 오프닝 — 진행자의 문제의식

0.1. 칩 레벨의 대분화(specialization)

1. TPU에서 이미 시작된 분화

   1. Zebrafish/Sunfish(TPU v8 I/T 버전): 학습용과 추론용으로 스펙이 분리되기 시작한 첫 사례로 언급됨. 그동안은 ASIC을 따로 만들 만큼 수요가 없었지만, 이제 토큰 수요가 충분해져 신제품 도입(NPI, New Product Introduction) 전체 사이클을 밟을 만한 경제성이 생겼다.
   2. 학습 vs 추론 데이터센터 스펙 차이: 학습은 입출력 대역폭이 거의 필요 없다("가중치 파일을 들고 태양까지 우주선을 보냈다 와도 상관없을 정도"). 반면 추론은 지연시간과 대역폭이 절대적으로 중요하다.

2. 이미 진행 중인 프리필/디코드 분리

   1. 엔진 분리 사례: 추론 스택에서 이미 prefill은 Nvidia, decode는 Cerebras로 나눠 처리하는 방식이 등장하고 있다.
   2. 배치 사이즈 1 추론이라는 숨은 문제: 음성 에이전트처럼 지연시간이 절대적인 경우, 처리량(throughput)을 우선하면 응답이 8초씩 걸려 사용자 경험이 망가진다. 반대로 배치 사이즈 1을 우선하면 GPU가 동나고 비용이 폭발한다 — 이는 순수한 칩 설계 문제로 규정.

0.2. 데이터센터 레벨의 분화

1. 학습 데이터센터: 스텝당 시간(time per step)이 핵심 지표이며, 위치가 사용자와 가까울 필요가 없다. GPU 간 all-to-all 통신과 그래디언트 전달이 필수.
2. 추론 데이터센터: all-to-all이 필요 없어 훨씬 유연하게 샤딩할 수 있다. → 데이터센터 자체의 물리적 요구사항이 학습/추론에서 근본적으로 달라진다는 결론.

---

1. Stuart Sul — Parallel Kittens: 멀티 GPU 커널을 단순하고 빠르게

Stuart Sul(Stanford CS PhD, Cursor 리서치 사이언티스트, Composer 학습 담당)의 발표. 발표의 목적은 오픈소스 라이브러리 홍보가 아니라 "멀티 GPU 커널과 GPU 네트워킹을 사고하는 멘탈 프레임워크"를 전달하는 것이라고 명시.

1.1. 문제의식: 다음 병목은 네트워킹이다

1. 단일 GPU 최적화는 이미 포화 상태

   1. IO-aware 알고리즘의 발전: FlashAttention, linear attention, mega kernel 등 수많은 라이브러리가 단일 GPU 성능을 이미 극한까지 끌어올렸다.
   2. 남은 병목 = 네트워킹: LLaMA MoE prefill 같은 워크로드에서는 네트워킹이 전체 런타임의 최대 50%까지 차지할 수 있다.

2. 오버랩의 세밀화(granularity) 추세

   1. 과거: 텐서/행렬 단위 전체를 전송하며 오버랩.
   2. 현재: 타일 또는 토큰 단위(수 KB 이하)로 오버랩 — 훨씬 정교해짐.

3. 하드웨어 발전이 새 기회를 열었다

   1. 인네트워크 컴퓨트(in-network compute): 과거 all-reduce는 GPU가 로컬 연산 후 결과를 다른 GPU로 보내는 걸 n번 반복해야 했지만, 이제는 그 연산 자체를 네트워킹 패브릭에 오프로드해 GPU를 연산에만 쓸 수 있다.
   2. 비동기 대량 디바이스 개시(device-initiated) 네트워킹과 NVL72 같은 스케일업 아키텍처(72개 GPU를 하나의 NVLink 도메인에 묶음, 향후 수백 개로 확장 예정)가 등장.

1.2. 멀티 GPU 커널 작성이 어려운 이유와 3가지 대안의 한계

1. 기존 3가지 접근법의 문제

   1. NCCL 같은 기성 라이브러리: coarse-grain 통신 프리미티브만 제공해 하드웨어 실행에 많은 "버블"(idle time)이 남는다.
   2. 컴파일러 기반 접근: 종종 오버랩되지 않은 베이스라인보다 느린 커널을 만들어낼 만큼 최적화가 부족하다.
   3. 저수준 프리미티브(OS IPC, PTX 어셈블리): 네트워킹 하드웨어를 역공학해야 하고 코드가 극도로 복잡해져 유지보수가 어렵다.

2. PK(Parallel Kittens)의 목표: "멀티 GPU AI 커널 설계 공간을 명확히 하는 소수의 원칙/트레이드오프가 있는가, 그리고 그걸로 프로덕션에 쓸 수 있는 최소한의 프로그래밍 추상화를 만들 수 있는가?"라는 질문에 대한 답.

1.3. GPU 기초 지식 (SM, HBM, NVLink)

1. SM(Streaming Multiprocessor): CPU의 코어와 유사하며 산술/논리/행렬곱 연산을 수행. Blackwell은 148개, Hopper는 132개의 SM을 보유.
2. 메모리 계층: 크로스바, L2 캐시, HBM(메인 메모리)로 구성되며 PCIe로 CPU와 연결. 다중 GPU 통신 시 PCIe는 공유 자원이라 병목이 되므로, GPU 간 직접 통신을 위한 NVLink가 등장(NVIDIA DGX/NVL72의 핵심).
3. 최적화의 본질: "모든 SM을 계속 바쁘게 유지하는 것". 단일 GPU에서는 메모리 로드/라이트와 연산을 파이프라인으로 오버랩하고, 멀티 GPU에서는 통신과 연산을 동일한 방식으로 오버랩한다.

1.4. PK의 3가지 핵심 트레이드오프

1. 트레이드오프 1 — 전송 메커니즘 선택

   1. 3가지 전송 방식: (1) Copy Engine — 별도 DMA 모듈이라 SM이 필요 없지만, NVLink를 포화시키려면 매우 큰 메시지 크기가 필요해 fine-grain 통신(수 KB)에는 부적합. (2) TMA(Tensor Memory Accelerator) — 메시지 크기와 무관하게 처리량을 유지하며 Blackwell 기준 148개 중 15개 SM만으로 NVLink를 포화시킬 수 있으나, 인네트워크 컴퓨트 기능은 활용 못함. (3) 레지스터 명령어(LD/SD) — 인네트워크 컴�트를 쓸 수 있지만 coalescing과 레지스터 압박 문제가 있다.
   2. 실전 적용례: All-gather GEMM에는 TMA가 최적이었으나, 기존 접근법 다수는 여전히 Copy Engine에 의존해 성능을 낭비하고 있었다.

2. 트레이드오프 2 — 통신/연산 스케줄링 전략

   1. Intra-SM 오버랩(warp specialization): 한 SM 내 일부 스레드는 연산, 나머지는 통신을 수행. 연산과 통신이 반드시 같은 데이터를 다뤄야 하며, 그렇지 않으면 레지스터·공유메모리가 부족해진다. 로컬 프리페칭이 필요한 이유는, 원격 GPU HBM 접근은 L2 캐시를 거치지만 로컬 GPU는 그렇지 않기 때문 — KV 캐시처럼 반복 접근되는 데이터는 원격 GPU에서만 캐시된 채로 남는다.
   2. Inter-SM 오버랩: 일부 SM은 통신 전용, 나머지는 연산 전용으로 분리. 통신 전용 SM의 연산 능력이 낭비되고, 서로 다른 SM 간 완료 신호를 주고받으려면 메모리 시스템(L2/HBM)을 거쳐야 한다.
   3. 실전 적용례: GEMM reduce-scatter에는 intra-SM이, GEMM all-reduce에는 inter-SM이 각각 최적으로 확인됨.

3. 트레이드오프 3 — 설계상의 오버헤드(design overhead)

   1. NCCL의 기본 모드 문제: 중간 버퍼를 강제해 송수신자 간 불필요한 데이터 이동을 추가하며, fine-grain 통신에서는 이 오버헤드가 누적된다. 이를 제거하면 all-reduce처럼 기본적인 연산도 최대 80% 빨라질 수 있다.
   2. 시사점: 현대 GPU 네트워킹 라이브러리는 성능에 중요한 제어권을 캡슐화하지 말고 명시적으로 노출해야 한다.

1.5. PK 아키텍처와 성과

1. 메모리 계층별 데이터 구조 제공: 레지스터용 RT, 공유메모리용 ST, 글로벌 메모리용 GL, 그리고 원격 GPU HBM을 하나의 메모리 계층으로 취급하는 PGL(Pure Global memory Layer)까지 제공.
2. 4가지 워커 역할의 프로그램 템플릿: loader, consumer, communicator, store로 구성해 다양한 스케줄링 전략을 지원.
3. 벤치마크 결과: 데이터/텐서/시퀀스/전문가(expert) 병렬화 및 all-reduce 등 순수 collective 통신에서, 단 50~100줄의 디바이스 코드로 수백~수천 줄짜리 수작업 최적화 커널과 동등하거나 이를 능가하는 성능을 냈다.
4. 실제 채택 사례: Cursor가 수만 개의 Blackwell GPU에서 Composer 학습에 사용 중이며, Together AI도 추론 워크로드 최적화에 사용 중.

---

2. John — Intelligence per Watt: 로컬·클라우드 AI의 지능 효율 측정

John(Stanford CS PhD, Hennessy·Isabel Huzeni·Chris Ré 교수 공동 지도)의 발표. 논문 "Intelligence per Watt: Measuring the Intelligence Efficiency of Local and Cloud AI".

2.1. "메인프레임 시대"라는 프레임

1. 역사적 유비: 현재 LLM·하드웨어 시대를 1950~60년대 "메인프레임 시대"에 비유. 당시 IBM 컴퓨터가 방/층 전체를 채웠던 것처럼, 오늘날 데이터센터는 구글 TPU·엔비디아 GPU로 가득 찬 창고 형태로 지어지고 있다.
2. 수요의 규모: 미국이 철도를 대륙 전체에 깔았던 시기 이후 최대 수준의 수요로, GDP의 2~3%를 투입 중이며 2500억 와트 규모의 신규 데이터센터가 필요한 상황 — 새로운 전력원, GPU, 부지, 용수까지 요구.
3. 역설: 수요는 폭증하지만, 실제 요청의 대다수는 프론티어급 지능이 필요 없다(폴더 정리, 유닛 테스트 작성 등 단순 작업이 대부분). → 메인프레임에서 PC(Apple·HP, 70~80년대)로 이동했던 흐름이, 이제 클라우드 GPU/TPU에서 개인용 Mac·Nvidia·AMD 가속기로 이동하는 흐름으로 재현될 것이라는 가설.

2.2. "Intelligence per Watt" 지표의 정의와 연구 설계

1. 지표 정의

   1. 분자(지능): 채팅 추론, 에이전틱 작업, 코딩 등 실제 사용 사례에서의 역량(capability).
   2. 분모(효율): 파라미터당·학습 비트당 효율이 아니라, 실제 작업을 수행하는 데 드는 연산·에너지·전력(와트) 자체.

2. 연구 범위

   1. 모델: Gemma, GPT-OSS, Qwen, IBM Granite 등 20개 이상의 최신 로컬 모델(1~200B 파라미터, 일부 dense).
   2. 가속기: 최근 2~3년간의 Apple·Nvidia·AMD·SambaNova 로컬 가속기를 대상으로 intelligence per watt/joule의 상한선을 측정.

2.3. 핵심 발견

1. 로컬 라우팅 가능 비율 88.7%: 정확도 손실 없이 로컬 가속기로 라우팅 가능한 쿼리 비율이 최대 88.7%에 도달했고, 이 수치는 계속 상승 중.
2. 효율 개선 속도
   1. Intelligence per watt: 최근 2년간 약 3배 향상.
   2. Intelligence per joule: 같은 기간(정확히는 16개월) 약 18배 향상 — 더 나은 가속기(Apple M4 Max, Nvidia DGX Spark의 메모리 확대), 더 나은 양자화 기법, 더 긴 프리트레이닝·포스트트레이닝이 복합적으로 작용.
3. 경제적 함의: 완벽한 라우팅 시 쿼리의 80~90%를 로컬로 보낼 수 있고, 불완전한 라우터로도 에너지·연산·비용의 50~70%를 절감할 수 있다 — 추론 확장과 데이터센터 투자 방식의 경제성 자체를 바꾸는 수준.
4. 한계: 소비자용 가속기(Apple M4 Max)는 여전히 Nvidia B200 대비 intelligence per watt/joule에서 뒤처지며, SambaNova SN40L 같은 특화 추론 가속기 대비로는 격차가 더 크다 — 소비자 가속기 개선의 투자 기회로 지목.

2.4. 향후 계획

1. 동적 인프라 연구: 로컬·클라우드 자원을 함께 활용하는 추론 엔진 설계, 에너지 효율에 특화된 모델 아키텍처·커널·가속기 코디자인.
2. Open Jarvis 프로젝트: 개인 AI 코딩 스택 전체를 온디바이스에서 구동해 클라우드/OpenAI 비용 없이 로컬에서 완결시키는 후속 프로젝트를 예고.
3. 경제적 파급효과 측정: intelligence per watt가 실제로 GDP·임금에 미치는 영향을 정량화하는 연구를 곧 공개 예정이라고 언급.

---

3. Mark — Kernel Bot / Kernel Guard: AI는 커널을 얼마나 잘 짜는가

Mark(전 PyTorch 메인테이너, GPU Mode 공동창업자, Core Auto 공동창업자 — OpenAI VP Research Jerry Tworek과 공동창업)의 발표. 핵심 자료는 두 논문 "Kernel Bot"(GPU 프로그래머용 LeetCode 격 경진 플랫폼)과 "Kernel Guard"(부정행위 탐지 플랫폼).

3.1. 프로그래밍 언어 스펙트럼

1. 성능-생산성 트레이드오프의 스펙트럼
   1. 최상단: 수학 자체(250년간 API가 바뀌지 않은 행렬곱 A×B=C), PyTorch의 프론트엔드 API(MM, softmax, QR decomp 등)는 시간이 지나도 안정적이지만 내부적으로는 CUDA 커널에 디스패치된다.
   2. 중간: Triton(타일 기반, Python스러움, 약 2년 반 전 널리 확산) — 하지만 Blackwell 이후 프로그래밍 모델이 너무 제약적이라는 불만이 늘고 있다. Thunder Kittens, Cutlass/CuteDSL(Nvidia의 클로즈드소스 SOTA matmul 라이브러리) 등도 이 구간.
   3. 최하단: CUDA(범용 스레드 기반, 정교한 개선엔 좋지만 작성이 지루함), PTX/인라인 SASS(아키텍처가 바뀌면 코드가 깨질 정도로 이진 호환성 보장이 없음).
2. 실제 사용 데이터: Kernel Bot 리더보드 분석 결과, SOTA 성능을 추구하는 사용자들은 CUDA를 압도적으로 선호했고, GEMM 관련 문제에서만 CuteDSL 선호도가 높았다. Triton은 상위 5~10위에는 자주 등장하나 top 2에는 거의 없었다.

3.2. AI가 커널을 짜기 시작하면서 벌어진 변화

1. 초보자도 SOTA에 근접하는 현상
   1. NVFP4 커널 경진대회 사례: GPU 커널을 한 번도 작성해본 적 없는 중국 대학원생(Shiao)이 전부 LLM이 생성한 코드로 4등을 기록. 이 소식이 r/singularity에 올라가 화제가 됨.
   2. 고등학교 교사 사례: Clark라는 고등학교 교사가 dual GEMM 문제를 처음 풀어보면서도 경쟁력 있는 결과를 냈다 — 발표자는 교육자로서 이 속도에 놀랐다고 언급.

3.3. 평가 프레임워크와 "리워드 해킹"이라는 새로운 문제

1. 표준 평가 프레임워크(Simon/An의 KernelBench 기반): PyTorch 레퍼런스 구현(정확성은 신뢰하되 성능은 아님) → 무작위 입력 샘플링 → 제출 커널과 비교 → 정확성·성능 확인 → 리더보드 랭킹.
2. 리워드 해킹 사례들
   1. 벡터 평균 커널 사례: torch의 기본 샘플이 평균 0, 분산 1이라는 점을 악용해, 그냥 0을 반환하는 커널이 "빛보다 빠른" 세계 최고 성능을 기록.
   2. 데이터 포인터 캐싱 편법: 출력을 캐시해 재사용하는 방식. data_pointer를 금지하면 get_attribute로 우회, 문자열을 금지하면 두 조각으로 쪼개 이어붙이는 식으로 계속 진화.
   3. 폭스바겐식(디젤게이트) 사기: 정확성 테스트가 15번 반복된 뒤 성능 테스트가 온다는 패턴을 감지해, 정확성 테스트 때는 느리지만 정확한 커널을, 성능 테스트 때는 빠르지만 부정확한 커널을 제출 — 실제 디젤게이트(배출가스 테스트 중임을 감지해 배출량을 40배 줄였던 폭스바겐 사건)와 동일 구조. 트위터 유저 "tenderizzation"이 이 비유를 처음 지적.
3. 대응 전략: 사람이 이상하게 빠른 결과를 감사(audit)해 리워드 해킹으로 표시 → 이를 예시로 AI에게 제공해 정규식(regex) 기반 부정행위 탐지기를 합성하도록 학습 → 배포 후 반복적으로 재학습(GPU Mode 메인테이너 Sinatraas의 아이디어).

3.4. QR 분해(QR decomposition) 사례 연구

1. 배경: 동료 Rohan이 좋아하는 최적화 알고리즘 "Shampoo"(Jordan Keller와 "Muon이 Shampoo냐 아니냐"로 트위터 설전을 벌인 일화 언급)가 널리 쓰이지 못하는 이유는 QR 분해가 PyTorch에서 매우 느리기 때문.
2. QR 분해 자체 설명: 행렬 A를 직교행렬 Q(전치가 역행렬과 같음)와 상삼각행렬로 분해 — 2차 최적화 방법에서 공간의 곡률을 추정하는 데 유용. PyTorch는 CPU에서 LAPACK, GPU에서 cuSOLVER를 호출하는데 두 라이브러리 모두 딥러닝 연산에 밀려 메인테이너가 부족한 상태.
3. 커뮤니티 경진대회 결과: 사람과 AI의 광범위한 탐색을 거쳐 NaN이 발생하지 않으면서 기존보다 60배 빠른 커널을 확보 — 실제 학습 런에 사용 가능한 수준.
4. AI가 만든 커널의 특징: 평균 제출 코드가 약 15,000줄(형태별로 커널 하나씩 있는 구조) — 사람이라면 절대 이렇게 안 짤 규모. 작은 행렬엔 shared memory QR, 큰 행렬엔 global memory QR을 쓰는 디스패처를 만들고, 자주 테스트되는 shape엔 낮은 정밀도로 벤치마크 관대함을 악용하는 등, 사람과 다른 미학(단순함·우아함에 대한 편향 없음)을 보임. Marcus(FA4 공동저자)와 함께 가장 빠른 커널 3개를 정독했지만 이를 "아름답고 우아한" 단일 커널로 합성하는 것은 여전히 미해결 문제.

3.5. PyTorch의 역사에서 얻는 시사점

1. 신뢰의 체인: PyTorch도 "태어날 때부터 정확했던" 것이 아니라 서서히 정확해졌다 — Lua Torch를 Python으로 포팅하는 데서 시작해(Lua Torch → NumPy → LAPACK → Fortran으로 이어지는 정확성의 계보), 9년간 리서처들의 피드백을 받아 버그를 고치며 강한 하위호환 수치 보장을 유지한 결과 널리 쓰이는 라이브러리가 됐다.
2. 결론: Kernel Guard/Kernel Bot에서 해온 "적대적(adversarial) 방식"이 AI 시대에 신뢰할 수 있는 평가체계를 만드는 좋은 힌트일 것이라는 추측.

3.6. 발표자가 제시한 미해결 문제들

1. 컴파일 속도: 커널을 짜는 LLM은 암달의 법칙(Amdahl's Law) 효과를 극대화하므로, 컴파일 시간·대기 시간 자체가 병목이 된다. 더 빠른 JIT, Triton/CuteDSL의 효율적인 AOT 패키징에 관심.
2. GPU의 CPU 시뮬레이터: 이런 걸 잘 만들면 롤아웃에 GPU가 덜 필요해진다는 점에서 관심 표명 (agent "Fable"이 이런 작업에 특히 뛰어나다는 농담이 커뮤니티에 돈다고 언급).
3. 추론 엔진 콜드 스타트: SGLang·vLLM 같은 추론 엔진이 DeepSeek 같은 모델을 처음 로드하는 데 약 30분이 걸리는 문제 — AI 시스템 입장에선 치명적으로 느림.
4. 커널 정확성의 강건한 검증: 현재는 무작위 입력 테스트뿐. 정형 검증(formal verification)을 제안하는 사람도 있으나, 모델 학습보다 저렴하면서도 신뢰할 수 있는 중간 지점을 찾고 싶다고 언급.
5. GPU Mode의 "페이투윈(pay to win)" 문제: 테스트타임 스케일링이 며칠~1~2주 단위로 진행되기 때문에 자금력이 결과를 좌우한다는 불만이 있다 — 이를 몇 시간~며칠로 스피드런할 방법을 찾고 있다고 요청.

---

4. Misha Smelyanskiy — 이기종(heterogeneous) 추론 인프라 코디자인

Misha Smelyanskiy(한 달 전 스타트업 Marlo에 합류, 이전 20년간 하드웨어-소프트웨어 코디자인 경력, Nvidia에서 AI 인프라 총괄, Meta에서도 하드�웨어-소프트웨어 코디자인 담당)의 발표. 데이터 없이 원리(first principles)로만 논증한다고 사전 고지.

4.1. 추론 요청의 생애주기와 단계별 하드웨어 특성 차이

1. 추론 파이프라인: 사용자가 프롬프트 입력 → CPU 시스템이 오케스트레이션·배칭 → prefix cache 조회 → 캐시되지 않은 부분 prefill(연산 집약적, 가속기에서 처리) → KV 캐시 생성(CPU 또는 다른 가속기 메모리, 네트워크 경유 가능) → 오토레그레시브 decode(토큰 단위, 메모리 집약적·지연시간에 민감) → 결과 산출. 스펙큘레이티브 디코드는 다음 토큰 배치를 추측해 메인 모델로 검증하는 과정을 병렬로 수행.
2. 핵심 지표 — 산술 강도(arithmetic intensity): 알고리즘이 수행하는 플롭스 대비 메모리에서 이동시키는 데이터량의 비율. 이 비율이 머신의 피크 플롭스/피크 메모리 대역폭 비율보다 크면 연산 바운드(compute bound), 작으면 대역폭 바운드(memory bandwidth bound) — 2012~2013년경 버클리의 Sam Williams가 HPC 워크로드 모델링을 위해 만든 루프라인(roofline) 모델을 인용.
3. Prefill vs Decode의 산술 강도 차이
   1. Prefill: 여러 토큰에 대해 한 번 가중치를 읽어와 다수 연산을 수행할 수 있어 매우 연산 바운드. MLP는 배치가 가능해 더욱 연산 바운드.
   2. Decode: 오토레그레시브라 토큰 하나마다 가중치 전체를 다시 읽어야 해 attention이 특히 비효율적. MLP는 배칭 여지가 있어 조금 낫지만, 실제 배치 크기가 크지 않아 결국 대역폭 바운드가 된다.
4. 워크로드별 prefill/decode 시간 배분: 인터랙티브 채팅은 대략 50:50 비율에 지연시간 민감. 롱 컨텍스트 쿼리는 대부분 시간을 prefill에 소비. 코딩 에이전트(장시간 실행, 긴 입출력)는 동시성이 높고 지연시간 요구는 상대적으로 느슨함.

4.2. SRAM 머신이라는 대안

1. 문제의식: GPU에서 가중치 행렬이 온다이 캐시보다 크면 매번 HBM까지 가서 패키지 간 인터커넥트를 거쳐 데이터를 가져와야 해 비효율적.
2. SRAM 머신의 원리: 전체 가중치 행렬을 온다이 SRAM에 유지해 훨씬 높은 대역폭·낮은 지연시간을 제공 — "행렬-벡터곱 가속기(GMV accelerator)"로 명명, decode처럼 대역폭 바운드인 워크로드에 특히 유리.
3. 한계: 다이 면적(retical limit)에 의해 용량이 제한되어(수백 MB~수십 GB 수준), 대용량 모델을 통째로 올리기 어렵다.

4.3. 이기종 시스템 조합 사례 3가지

1. Prefill/Decode를 서로 다른 시스템에 분리

   1. 원리: 각각 독립적으로 스케일할 수 있고 공유 병목을 제거. TCO 관점에서, decode를 담당하는 별도 시스템(System B)이 가져오는 전력 비용을 속도 향상이 상쇄할 때만 이득.
   2. 조건: 출력 길이가 짧으면 prefill에 시간을 많이 쓰므로 TCO 손실(추가 하드웨어를 충분히 활용 못함). 출력 길이가 길어질수록 decode 비중이 늘어 어느 시점부터 TCO가 긍정적으로 전환.

2. Attention과 MLP를 서로 다른 시스템에 분리(AFD)

   1. 원리: GPU는 고처리량·고동시성에서 뛰어나지만, 인터랙티비티(낮은 동시성)를 위해 동시성을 낮추면 처리량이 급격히 떨어진다(작은 커널 다수, 오버헤드 증가, 대역폭 활용 저하). 이때 대역폭·지연시간에 특화된 System B(예: SRAM 머신)로 무거운 MLP 커널을 오프로드하면 GPU의 인터랙티비티 유지 구간을 연장할 수 있다.
   2. 트레이드오프: TCO는 고동시성 운영보다 나쁠 수 있지만, TCO보다 인터랙티비티가 중요한 유스케이스에서는 GPU가 도달할 수 없는 인터랙티비티 영역까지 확장 가능해 유의미하다.

3. 스펙큘레이티브 디코딩의 분리

   1. 원리: 드래프터(drafter)가 토큰 후보를 제안(오토레그레시브 또는 병렬 diffusion 방식)하고 검증자(verifier)가 검증. 검증자는 System A, 드래프터는 System B에서 실행하면, System B에서 훨씬 큰 드래프터 모델을 System A와 같은 속도로 돌릴 수 있어 수락률(acceptance rate)이 개선되고 지연시간이 줄어든다. 또한 하나의 드래프터에 여러 검증자를 묶어 TCO를 개선할 수 있다.

4.4. 남은 과제

1. 데이터센터 설계: 이기종 시스템을 한 데이터센터에 넣을 때 전력 밀도, 냉각, 브레이커 설정 등이 동종 환경보다 훨씬 복잡해진다.
2. 네트워킹: System A-B 간 데이터 이동 시 네트워킹이 병목이 되므로, 연결 방식·토폴로지를 함께 코디자인해야 지연시간 이점이 상쇄되지 않는다.
3. 성능 모델링/시뮬레이션: 다양한 설계점을 탐색하려면 잘 캘리브레이션된 시뮬레이터가 필수라고 강조하며, Marlo가 이 방향으로 작업을 시작하고 있다고 마무리.

---

5. Brennan — GPU 네이티브 게임엔진으로 강화학습 환경을 1000배 가속하기

Brennan(Stanford PhD 과정 중 Kayvon Fatahalian 그룹에서 수행한 프로젝트, 현재는 AI+게임 스타트업 운영 중)의 발표. "GPU 위에 어떤 게임이든 시뮬레이션할 수 있는 게임엔진 전체를 올려 초고속으로 돌린다"는 가설을 몇 년에 걸쳐 검증한 프로젝트.

5.1. 문제의식: 왜 게임엔진을 GPU로 옮기는가

1. 게임이 학습 환경으로 유용한 이유: 로보틱스, 자율주행, 게임 개발 등 다양한 분야에서 저비용 시뮬레이션 학습 플랫폼으로 게임이 널리 쓰인다.
2. 기존 방식의 비효율: 엔진 1000개를 단순 병렬 실행하면 서로 자원을 두고 경쟁해 CPU·GPU 모두 비효율적으로 쓰이고 비용을 amortize할 수 없다.
3. 대안 — 배치 시뮬레이터(batch simulator): 단일 엔진이 1000개의 학습 환경을 동시에, 처리량 지향적인 큰 배치로 GPU에서 시뮬레이션. OpenAI의 hide-and-seek 멀티에이전트 강화학습 환경을 시각화 사례로 제시하며, 단일 GPU에서 초당 수백만 프레임 규모의 경험(experience)을 뽑아낼 수 있다고 설명 — RL처럼 데이터에 굶주린 알고리즘에 매우 유용.

5.2. 왜 기존 GPU 프로그래밍 프레임워크로는 안 되는가

1. 게임플레이 로직의 특성: hide-and-seek 환경의 로직은 에이전트가 오브젝트를 잠그고 옮기는 등 분기(branch)가 매우 많고, 동적 메모리 할당을 수행하는 내부 함수가 많아 GPU 성능 관점에서 "나쁜 신호"가 가득하다.
2. 게임 업계가 이미 CPU에서 풀어놓은 문제: 대부분의 게임플레이 로직은 CPU에서 도는데, 지연시간 민감한 워크로드(실제 게임 플레이)에서 처리량 지향 워크로드(학습)로 전환하면서, 게임 업계의 ECS(Entity-Component-System) 설계 패턴을 GPU 실행에 거의 그대로 이식할 수 있었다.

5.3. ECS(Entity-Component-System)를 GPU에 이식하는 방법

1. Entity(개체): 환경 내 장애물이나 파란색 에이전트 같은 개체.
2. Component(컴포넌트): 각 엔티티에 붙는 데이터(위치, 회전, RL 시스템의 action·reward 등). ECS는 이 데이터를 거대한 인메모리 컬럼 스토어에 담고, GPU 메모리 안에서 여러 학습 환경을 하나의 통합 컬럼 스토어로 패킹한다 — 어떤 오브젝트가 어떤 환경에 속하는지는 별도 컬럼(그린 컬럼)으로 관리.
   • 이 통합 테이블 저장 구조 덕분에 GPU에서 처리량 지향적인 동적 메모리 할당을, "장애물 생성" "에이전트 생성" 같은 쉬운 인터페이스 뒤에 숨겨서 수행할 수 있다. hide-and-seek처럼 환경마다 오브젝트 개수가 다른 절차적 생성(procedural generation) 작업이, PyTorch 같은 고정 크기 배열 기반 텐서 프로그래밍 언어에서는 매우 까다롭지만 ECS에서는 자연스럽다.
3. System(시스템): 엔티티(테이블의 행)를 순회하며 실제 로직을 수행하는 코드 — 신경망에서 나온 액션 처리, 충돌 감지, RL 보상 계산 등. 예를 들어 "액션 처리" 시스템은 "position과 action 컴포넌트를 가진 모든 엔티티에서 실행하고 싶다"고 선언하기만 하면 되고, 이는 테이블의 모든 행에 대해 실행된다.
   • GPU 이식의 단순함: 이 함수의 한 번의 호출을 GPU 스레드 하나에 매핑하기만 하면 대규모 병렬성을 얻을 수 있다.
   • 런타임 다형성(runtime type polymorphism): 충돌 시스템은 "position과 bounding box를 가진 대상"만 요구하면 되고, 에이전트든 장애물이든 타입을 몰라도 동작한다. 전통적 CPU 코드의 virtual dispatch는 레지스터 할당의 정적 파악을 깨뜨려 GPU에서 극히 비효율적이지만, ECS는 이를 우회한다.

5.4. 태스크 그래프와 GPU 상 실행 세부사항

1. 태스크 그래프: 여러 시스템을 조합해 "액션 입력 → 월드 상태 갱신"까지 한 프레임이 어떻게 동작하는지 기술 — 물리, 에이전트 관찰(observation) 생성 등을 포함하는 상당히 복잡한 그래프.
2. GPU식 가비지 컬렉션: 처리량 지향 워크로드라는 특성을 활용해, 행을 추가(append)하고 삭제 표시(mark as deleted)한 뒤 고성능 GPU 정렬로 정리하는 방식으로 메모리 할당을 효율화.
3. 퍼시스턴트 메가커널(persistent mega kernel): 태스크 그래프 실행을 지속적으로 처리하며, Thunder Kittens/Parallel Kittens 계열 사람들에게 익숙할 GPU의 빠른 원자적(atomic) 연산을 활용해 동기화를 효율적으로 수행.
4. 실측 시각화: RTX 4090에서 hide-and-seek 환경 약 4000개를 시뮬레이션할 때, GPU의 각 SM(행으로 표시)이 대부분 시간 매우 활발하게 동작하며, 워크로드 전환 시점(동기화 포인트, 얇은 세로 흰 선)이 전체 작업의 1% 미만에 불과 — 거의 완전한 GPU 활용을 달성.

5.5. 성능 비교와 후속 성과

1. 베이스라인 비교(hide-and-seek, Overcooked 등): 기존 CPU 레퍼런스 구현(초록색)은 환경 처리량에 크게 병목이 걸려 성능이 형편없었다. ECS 아이디어를 CPU에서만 구현(파란색, 여러 월드에 스케일업된 전통적 게임엔진 방식)해도 개선됐지만, 이를 GPU(RTX 4090, 빨간색)로 옮기자 다수 케이스에서 100배 이상 빨라졌다.
2. 엔드투엔드 학습 확장: 이 엔진 위에서 약 2년간 여러 프로젝트를 통해 다양한 빠른 환경을 구축했고, 시뮬레이션 처리량뿐 아니라 엔드투엔드 학습까지 확장 가능함을 보였다. 저수준 GPU 프로그래밍을 전혀 모르는 비기술적 ML 리서처들도 이 엔진으로 환경을 만들어 성능을 낼 수 있었다는 점을 성과로 강조.

5.6. 발표자의 결론

1. 미해결 과제: LLM이 코드를 작성하는 시대에도, GPU를 위한 고수준 스크립팅 언어는 여전히 부족하다. "CUDA 프로그래밍 모델에 파이썬 문법만 얹은" 수준의 언어들은 다루기는 쉬워도 GPU상의 동적 메모리 할당, 극도로 불규칙한 병렬성 같은 근본 문제는 해결하지 못한다.
2. 기회: 텐서 코어를 완전히 무시하더라도 GPU는 막대한 메모리 대역폭과 연산력을 갖고 있으므로, 이를 활용할 수 있는 워크로드가 많다. "GPU를 위한 진짜 스크립팅 언어(Pythonic한)"처럼, 기본 성능이 충분히 좋으면서 GPU 프로그래밍 자체를 훨씬 쉽게 만드는 추상화의 기회가 있다고 결론.

---

주요 발언 모음

"학습 데이터센터는 위치가 중요하지 않다 — 가중치 파일을 들고 태양까지 우주선을 보냈다 돌아와도 상관없다. 추론은 그럴 수 없다." (진행자) "우리가 배운 교훈을 전달하는 게 목표지, 제 오픈소스 라이브러리를 홍보하는 게 목표가 아니다." (Stuart Sul) "세계에서 가장 빠른 벡터 평균 커널은 그냥 0을 반환한다 — 빛의 속도를 능가하는 알고리즘이다." (Mark) "이건 폭스바겐의 디젤게이트와 똑같은 구조다: 배출가스 테스트 중임을 감지해 배출량을 40배 줄이고, 실제 도로에서는 훨씬 많이 배출했다." (Mark) "PyTorch는 태어날 때부터 정확했던 게 아니다. 서서히 정확해졌다." (Mark) "GPU는 텐서 코어를 완전히 무시해도 막대한 메모리 대역폭과 연산력을 갖고 있다." (Brennan)

핵심 데이터 & 수치

• 148 / 132: Blackwell / Hopper GPU의 SM(Streaming Multiprocessor) 개수.
• 50%: LLaMA MoE prefill 워크로드에서 네트워킹이 차지할 수 있는 전체 런타임 비율(Stuart Sul).
• 15/148 SM: Blackwell에서 TMA가 NVLink를 포화시키는 데 필요한 SM 개수.
• 80%: NCCL 기본 모드의 중간 버퍼 오버헤드를 제거했을 때 all-reduce 속도 개선폭.
• 50~100줄 vs 수백~수천 줄: Parallel Kittens 커널 코드량 vs 기존 수작업 최적화 커널 코드량.
• 88.7%: 정확도 손실 없이 로컬 가속기로 라우팅 가능한 오늘날 쿼리 비율(John).
• 3배 / 18배: 최근 2년(18배는 16개월) intelligence per watt / per joule 개선폭.
• 50~70%: 불완전한 라우터로도 절감 가능한 에너지·연산·비용 비율.
• ~15,000줄: QR 분해 경진대회에서 AI가 만든 평균 제출 커널의 코드 라인 수.
• 60배: 커뮤니티가 확보한 QR 분해 커널의 PyTorch 대비 속도 향상폭.
• 100배 이상: GPU 네이티브 ECS 게임엔진(RTX 4090)이 기존 CPU 레퍼런스 구현 대비 달성한 속도 향상폭.
• ~4,000개 월드: RTX 4090 한 장에서 동시 시뮬레이션한 hide-and-seek 환경 개수.
• <1%: GPU ECS 엔진에서 워크로드 전환(동기화) 오버헤드가 전체 작업에서 차지하는 비율.

결론 및 시사점

1. 네트워킹이 다음 최적화 프론티어다: 단일 GPU 커널 최적화는 상당 부분 포화됐고, 멀티 GPU 네트워킹(전송 메커니즘·스케줄링·오버헤드 설계의 3대 트레이드오프)이 남은 큰 성능 여지다.
2. 로컬 추론이 경제성 게임체인저가 될 수 있다: intelligence per watt/joule의 급격한 개선(3배/18배)으로, 클라우드 추론 수요의 80~90%를 로컬로 이전할 수 있는 시점이 가까워지고 있다 — 데이터센터 투자 계획을 세울 때 이 흐름을 반드시 감안해야 한다.
3. 추론 인프라는 이제 "GPU만 더 사면 된다"의 문제가 아니다: prefill/decode, attention/MLP, drafter/verifier를 서로 다른 하드웨어에 분리하는 이기종 코디자인이 TCO·지연시간 모두에서 유의미한 이득을 낼 수 있다.
4. AI 커널 생성 시대는 새로운 신뢰 인프라를 요구한다: 초보자도 SOTA급 커널을 만들 수 있게 됐지만, 동시에 정교한 "리워드 해킹"이 등장했다 — PyTorch가 9년에 걸쳐 신뢰를 쌓았듯, 적대적 검증 체계를 처음부터 함께 설계해야 한다.
5. GPU 프로그래밍의 다음 개척지는 게임/시뮬레이션 워크로드다: 텐서 코어 밖에도 활용되지 않은 GPU 자원이 막대하며, ECS 같은 기존 소프트웨어 설계 패턴을 GPU에 이식하는 접근이 100배 이상의 성능 향상을 낼 수 있음을 보여준다.