URL: https://www.youtube.com/watch?v=7PSXtru6mmY 날짜(업로드 추정): 2026-08-03 채널: Latent Space 처리일: 2026-08-04 분량: 1시간 42분 54초(6174초) 출연: Philip Kiely(Baseten, 『Inference Engineering』 저자), Ali Taha(Baseten, 前 "Waterloo Intern" — 현재는 정식 엔지니어)
📌 핵심 질문 / 이 영상이 다루는 핵심 논점
이 인터뷰는 ==추론(inference) 엔지니어링이 더 이상 "오픈모델 받아서 GPU 돌리기"가 아니라, 트레이닝-인퍼런스가 융합되고 모델이 자기 자신의 추론 스택을 최적화하기 시작하는 단계로 진입했다==는 것을 실제 Baseten 내부 사례로 보여준다.
- Baseten은 실제로 GLM-5.2 모델을 자사 코드 하네스에 연결해, GLM-5.2가 자기 자신을 서빙하는 추론 엔진(SGLang 기반)의 GPU 커널을 직접 작성·프로파일링·수정하게 하는 순환 루프를 운영 중이다(오프닝에서 소개, 후반부에서 상세 설명).
- 단일 최적화 하나로 10배 속도 향상을 노리는 게 아니라, 양자화(NVFP4)·스펙큘레이티브 디코딩·PD(prefill-decode) 분리·최신 커널이라는 여러 개별 최적화(각 1.3~2배)를 곱해서 30~40 tok/s 베이스라인을 300~400 tok/s까지 끌어올리는 "스태킹" 전략이 업계 표준이 되고 있다.
- 하드웨어(Blackwell→Rubin)가 점점 GPU라기보다 ASIC에 가까워지는 방향으로 진화하면서, 인퍼런스 엔지니어링의 본질이 "CUDA 커널 최적화"에서 "KV 캐시를 언제 어디로 옮길지 결정하는 시스템/인프라 문제"로 이동하고 있다.
전체적으로 이 대화는 롱 쿼리 하나가 실제로 어떤 파이프라인을 거치는지에서 시작해, 신규 모델 온보딩의 숨은 노동, 프로덕션 사고(모드 붕괴·레이스 컨디션), 품질과 양자화의 관계, 하드웨어 진화 방향, 비디오/오디오 모달리티의 추론 난이도, 그리고 트레이닝과 추론이 하나로 수렴하는 미래까지 인퍼런스 엔지니어링의 전 영역을 촘촘하게 훑는다.
1. 롱 쿼리(20만 토큰) 하나가 실제로 거치는 파이프라인
이 섹션은 진행자의 "20만 토큰짜리 쿼리를 Baseten에 보내면 실제로 무슨 일이 일어나는가"라는 질문에 대한 답이다.
1.1. 캐시 인지 라우팅(Cache-aware Routing)
- 첫 질문은 항상 "이 쿼리를 전에 보낸 적 있는가"
- 이유: 캐시가 히트하면 처리 비용이 훨씬 싸고 빨라짐. 20만 토큰 요청은 대부분 코딩이나 멀티턴 에이전트 워크로드라 프리필 재사용 가능성이 높음
- 라우팅 기준: (1) 사용 가능한 프리필 워커가 있는가, (2) 이미 캐시된 입력이 있어 프리필 일부를 스킵할 수 있는가
1.2. PD 분리(Prefill-Decode Disaggregation)
- 디코딩과 프리필을 별도 GPU 세트에서 처리
- 프리필 전담 GPU 세트가 입력을 처리해 KV 캐시를 생성하고 첫 토큰을 만든 뒤, 별도의 디코드 GPU 세트로 전달해 이후 토큰을 반복 생성
- 이 분리는 특정 모델에 한해 이미 도입돼 있음
1.3. 스펙큘레이티브 디코딩과 스트리밍
- 코딩 워크로드를 가정한 스펙큘레이터 모델이 앞단에 배치돼 있어 드래프트 토큰 수락률이 높음. 만약 "해리포터 요약" 같은 워크로드라면 수락률이 낮아 느려짐
- 결과를 스트리밍하고 소액(몇 센트) 과금 후 다음 요청을 유도
2. 배포 방식 선택: Pay-per-token API vs 전용(Dedicated) 배포
2.1. 두 모델의 경제성 차이
- 박스 단위 렌탈이 유리한 경우: 시간당 수백만 토큰을 처리하는 초고볼륨 사용자는 토큰당 과금보다 시간당 과금(박스 단위 렌탈)이 훨씬 저렴 — 단, 박스를 얼마나 포화시키는지는 사용자 책임
- 관측된 트렌드: 토큰당 과금 API 수요가 늘고 있는 건 다들 오픈모델을 "일단 써보고" 싶어하기 때문. 사용 사례가 확실해지면(sticky) 전용 배포로 이전
2.2. 전용 배포로 전환하는 이유(신뢰성 외 4가지)
- 신뢰성(Reliability): 특정 트래픽 전용 스펙큘레이티브 디코더를 학습시킬 수 있음 — 예: 해리포터 요약만 하는 트래픽이면 드래프트 모델을 그 데이터로만 학습시켜 매번 3토큰 수락을 보장 가능. 공유 엔드포인트에서는 트래픽 성격을 알 수 없어 이런 최적화 불가능
- 파라미터 튜닝 자유도: 배치 사이즈, 병렬화 전략(처리량 vs 지연시간 최적화), 벤치마크 통과를 위한 더 높은 정밀도의 NVFP4 미사용 등을 직접 선택 가능
- 노이즈 트래픽 차단: 타인이 1억 토큰 규모의 벤치마킹 트래픽을 같은 엔드포인트에 쏟아붓는 상황을 피할 수 있음
- 커스텀 툴콜링 지원: 자체 포스트트레이닝된 모델을 쓰는 고객은 일반적인 "날씨 찾기" 수준이 아닌 매우 특수한 툴콜링 포맷을 요구하는 경우가 많아, 포스트트레이닝 품질이나 양자화 품질이 나쁘면 JSON을 제대로 못 읽음
3. 툴콜링과 구조화된 출력(Structured Output)
3.1. 툴콜링에서 실제로 어려운 부분
- 훈련(training) 측 난제: JSON 출력을 제대로 닫지 않으면(요청을 특정 방식으로 종료하지 않으면) 모델이 툴콜링과 사고(thinking)를 했음에도 결과를 못 보고 결과를 환각(hallucinate)하며 디코딩하는 문제가 발생 — 이는 "샌드박스 탈출" 같은 보안 문제가 아니라 순수 학습/포맷 문제
- 추론(inference) 측 해법: Baseten은 약 2년 전 상태 머신(state machine)을 이용해 출력을 특정 포맷으로 제약하는 구조화된 출력 문제 해법을 발표함 — 과거의 "무조건 JSON만 반환해" 프롬프트 지시나 OpenAI의 BNF 문법 제약 방식과 비교되는 접근. 이는 툴콜링 정확도의 "불확실성 문제"는 못 풀지만(여전히 잘못된 툴을 부를 수 있음) 최소한 "출력 구조화 문제"는 해결
3.2. MCP와 LLM의 한계
- MCP는 그냥 또 다른 형태의 툴: 특별할 것 없음
- 핵심 통찰: LLM은 실제로 아무것도 "할 수" 없다. 오직 무엇을 할지 제안(suggestion)만 할 수 있고, 그 제안이 특정 포맷으로 정리돼 그것을 처리할 줄 아는 시스템에 전달됐을 때 비로소 행동(action)이 발생한다
3.3. JSON 대안 논의
- 스트리밍 문제: JSON은 완전해야 하고 괄호가 열리고 닫혀야 하므로, 스트리밍 중 파싱·검증이 어려움. 그래서 YAML류의 대안들이 등장했지만 JSON이 여전히 압도적으로 지배적
- 반론: 툴콜의 JSON 출력 자체는 그리 길지 않은 경우가 많아(중간값 기준) 스펙큘레이터가 JSON 형태를 잘 예측하므로 스트리밍의 이점이 생각보다 크지 않을 수 있음
- 고객사 종속성: 결국 모델이 통합될 소프트웨어가 JSON 기반이면 그에 맞춰야 하며, 트레이닝 자체는 포맷과 무관하게 큰 차이가 없음. 오히려 출력 토큰이 많을수록 (비즈니스 모델에 따라) 더 수익성이 높을 수 있다는 언급도 나옴
4. 새 모델이 나올 때 "프로덕션 레디 API"까지 가는 숨은 노동
4.1. "토큰을 뽑아낼 수 있다" ≠ "프로덕션 레디 API가 있다"
- 토큰 뽑기(비교적 쉬움): vLLM, SGLang 같은 오픈소스 추론 엔진은 종종 모델 공개 전에 가중치를 미리 받고, 모델 제작사·유지관리자가 직접 지원 PR을 머지하기 때문에 표준 스택에서 큰 고통 없이 작동시키는 것 자체는 어렵지 않음
- 프로덕션 API(어려움): 모든 추론 회사는 오픈소스 컴포넌트+자체 인하우스 스택이 섞인 독자 스택을 가지므로, 임의의 모델마다 새로운 작업이 발생
4.2. 신규 모델 지원에 실제로 들어가는 작업 목록
- 양자화 재작업: 모델은 보통 NVFP4로 공개되지 않으므로, Blackwell 호환성 극대화를 위해 NVFP4로 양자화하고 지능 저하가 없도록 캘리브레이션
- 스펙큘레이터 학습: Zero Data Retention 정책상 실제 트래픽은 모를 수 있지만, 코딩·에이전틱 유스케이스가 인기 있다는 건 알기에 공개 데이터셋으로 대표성 있는 스펙큘레이터를 학습. 스펙큘레이터 학습에는 베이스 모델 자체(히든 스테이트 추출)가 반드시 필요
- 인프라 구축: 전체 인프라를 세우고, 로딩하고, 테스트
- 신규 아키텍처 대응: DeepSeek 계열 모델이 가장 새로운 아키텍처 요소가 많아 난이도가 높음. GLM-5.2에는 DeepSeek에서 가져온 DSA(DeepSeek Sparse Attention)가 포함돼 있어 런타임에 새로 지원을 구축해야 했음 — 오픈소스 랩들이 서로의 아이디어를 "복붙"하듯 빌려 쓰는 것이 실제로 확인됨
4.3. 출시 이후에도 계속되는 작업(Day 0 이후)
- 실서비스 노출 후 발견되는 문제: 모델을 실제 트래픽에 노출하면 테스트에서 못 잡은 다양한 문제(예: 모드 붕괴)가 드러나며, 이는 하루짜리 프로세스가 아니라 첫 주·첫 달 내내 버그 수정과 성능 개선을 병행하는 지속적 과정
5. 비전 인코더 이식 사례: Kimi Vision + GLM-5.2
5.1. 왜 이런 이식을 하는가
- GLM-5.2는 원래 비전이 없음: Baseten 팀원 "Harry"가 Kimi의 비전 인코더를 GLM-5.2에 접목하는 실험을 진행
- 모델 구조 3단계: (1) 인코더 — 이미지를 잠재 정보로 변환, (2) 프로젝터 — 그 정보를 모델이 이해할 수 있는 공간으로 매핑, (3) 모델 가중치 자체
- 가중치는 건드리지 않는 이유: 비전을 주려다 다른 능력(모델의 원래 지능)을 퇴화시킬 위험이 있으므로, 오직 수백만 파라미터에 불과한 프로젝터만 학습
5.2. 학습 과정(Progressive Training)
- 1단계 — 단순 캡셔닝: "이 산 사진에 뭐가 보이나요?" 같은 질문으로 학습을 시작했으나, 이 방식만으로는 완전한 이해에 도달하지 못함
- 2단계 — 질의응답 데이터셋으로 전환: 모든 이미지에 "이 이미지에 백인 남성이 있는가?", "상단 코너에 새가 있는가?", "과학자가 있는가?" 등 질문 세트를 연결해 정답을 맞히도록 훈련
- 결과: 그로킹(groking) 현상이 관찰됨 — 거대 LLM에 시각을 나중에 접목해도 이 정도까지 학습될 수 있다는 것이 "정말 미친(genuinely insane)" 수준이라고 평가. 모델이 못 맞히는 이미지(예: 스티븐 호킹을 아인슈타인으로 착각)에서도 최소한 "과학자, 남성, 업적 있는 인물"이라는 카테고리적 이해는 유지함
- 원조 연구 언급: LLaVA 논문 저자, CLIP/MetaCLIP의 캡셔닝→질의응답 전환 접근이 이 작업의 기초가 됨
5.3. 실용적 함의
- 성능 저하 없음: 이미지 입력이 없으면 인코더 자체를 건너뛰므로 GLM-5.2 원래 품질에 손실이 전혀 없음
- 경량성: 비전 인코더는 보통 10억 파라미터 미만으로 전체 추론 부담에 미치는 영향이 작음(다만 비전 인코더 생태계의 표준화 수준은 언어모델보다 낮아 지원 매트릭스가 더 산발적)
- 오픈소스의 힘: 결과적으로 하나의 모델 안에 Kimi의 비전, GLM의 가중치, DeepSeek의 어텐션이 공존하는 조합이 탄생 — 이것이 오픈소스의 힘과 아름다움이라고 평가
6. 레이어 이식(Franken-merge)과 아키텍처 스와핑
6.1. Minimax M3 사례
- 문제: Minimax M3 헤드는 풀 어텐션을 사용해 오토레그레시브 토큰 생성 시 시퀀스 전체에 대해 n² 연산이 발생하는 심각한 병목이 생기고, KV 캐시가 sparse/top-k가 아니라서 매우 커짐
- 해법: 문제 레이어를 GQA(Grouped Query Attention) 같은 다른 모델의 레이어로 교체하고, 적절한 재학습으로 동일한 수락률을 확보
- 결론: 레이어가 비효율적이면 다른 모델의 레이어를 이식하는 것이 가능하고 실제로 필요하다. 다만 이를 제대로 학습시키는 것 자체가 난제이며, 이는 "훈련과 추론이 점점 더 밀접하게 얽힌다(mesh)"는 흐름의 일부
7. 프로덕션 안정성: 모드 붕괴와 레이스 컨디션
7.1. 반복 토큰 출력(모드 붕괴) 사고
- 현상: GLM에서 특정 프롬프트·특정 온도에서 동일 토큰을 계속 반복 출력하는 모드 붕괴가 발생. 특히 "S" 토큰이 가장 흔한 문제 토큰이며 GLM-5.2, DeepSeek-V4에서도 관찰됨
- 대응: 동일 토큰이 4회 이상 연속 출력되면 생성을 중단하고 재시도(요청 재처리)하는 로직을 엔드포인트에 내장. 단, 테이블처럼 대시(-)를 12개 연속 그리는 등 정상적으로 토큰 반복이 필요한 케이스를 위해 특정 특수문자는 이 로직에서 제외
- 원인 규명의 어려움: 이 문제는 모델 가중치(양자화 오류) 문제가 아니라 소프트웨어/추론 엔진 문제로 보임 — 동일 가중치를 다른 추론 엔진(SGLang→vLLM)에서 돌리면 재현되지 않는 경우가 많음. Nvidia가 새 이미지를 릴리즈하고 그 변경분을 스택에 업스트림하면 해결되기도 함
7.2. 클러스터 간 레이스 컨디션
- 현상: 같은 모델을 클러스터 A에서 호스팅하면 문제가 없는데 클러스터 B에서는 발생 — 원인은 클러스터 간 노드-노드 KV 캐시 전송에 쓰이는 인터커넥트 속도 차이가 커널의 미묘한 레이스 컨디션(예: 누락된 배리어)을 노출시키기 때문
- 결과: 문제를 노출시키는 클러스터에는 해당 모델을 호스팅하지 않는 방식으로 우회. 이것이 소프트웨어 문제인지 모델 가중치 문제인지 하드웨어 문제인지 규명이 매우 까다로움을 보여주는 사례
- 일반화: 온도=0에서도 항상 같은 출력이 나오지 않는 비결정성은 대체로 하드웨어(부동소수점 연산 순서 등) 때문으로 알려져 있으며, PDL(Programmatic Dependent Launch) 같은 커널 오버랩 최적화가 이런 미묘한 레이스의 원인이 될 수 있음(Rust의 borrow checker 같은 메모리 안전 도구가 CUDA에는 없다는 지적도 나옴)
8. 품질과 양자화의 관계
8.1. 손실 없는 최적화 vs 손실 있는 최적화
- 무손실(Lossless): KV 캐싱(같은 값 재계산 방지), 스펙큘레이션(틀린 드래프트 토큰은 거부됨)
- 손실(Lossy): 양자화가 유일한 주요 손실 최적화 — 품질은 (1) 데이터 포맷, (2) 어느 레이어를 양자화할지 선택, (3) 아웃라이어 보존을 위한 캘리브레이션, 세 가지에 좌우됨
- 품질의 정의: "원본 모델을 얼마나 충실하게(fidelity) 서빙하는가"이며, Baseten의 내부 기준은 "자사 API와 공식 API를 구별할 수 없어야 한다"는 것
8.2. Kimi 벤더 벤치마킹 사고(3~5개월 전)
- 사건: Kimi가 특정 벤더(Amazon으로 추정)의 자사 모델 서빙 품질이 낮다는 것을 자체 벤치마크로 공개 지적("Kimi vendor verifier")
- 의미: 소비자가 Amazon 엔드포인트에서 나쁜 결과를 받으면 "Amazon이 양자화를 잘못했다"가 아니라 "Kimi가 별로다"라고 오해하기 쉽기 때문에, 모델 제공사 입장에서 벤더의 서빙 품질 관리에 정당하게 신경 쓸 수밖에 없음
8.3. 롱컨텍스트와 짧은 컨텍스트 API 분리
- 20만 토큰 요청을 처리하려면 더 많은 정보를 저장·처리해야 하므로, 모델이 지원하는 최대 컨텍스트가 있어도 추론 제공자는 짧은 컨텍스트 API와 풀 컨텍스트 API를 별도로 만들어 필요 없는 사용자에게 더 나은 성능을 제공하는 선택을 할 수 있음
8.4. 양자화가 "결과를 개선"할 수 있는가 — Joshua의 KL Divergence 연구
- 역스케일링 법칙(Inverse Scaling Law): 벤치마크가 비결정적이라 NVFP4 양자화 모델이 원본보다 몇 bp 높게 나오는 경우가 있지만 이는 노이즈일 뿐, 원본보다 "더 나아지는" 것은 아님
- 핵심 발견(72페이지 연구, 최종 39페이지로 축약된 논문): 레이어 1·5·10을 양자화한 모델이 레이어 1·2만 양자화한 모델보다 오히려 더 좋은 성능을 낼 수 있다 — 양자화 오류가 서로 상쇄(cancel out)되기 때문. 리서치 인턴 Joshua가 수학적 증명을 통해 어떤 레이어들의 양자화 오류가 서로 상쇄될지 예측하는 검증기(verifier)를 개발
- 결과: 이 기법으로 다른 프로바이더 대비 20% 더 많은 레이어를 NVFP4로 양자화하면서도(=처리량 20% 증가) 품질은 오히려 더 나은 결과를 달성. 벤치마크 점수 대신 양자화 모델과 원본 풀프리시전 모델의 로짓 분포 간 KL 발산(divergence)을 측정해 이를 증명
- 결론: "양자화를 더 많이 하면 항상 더 나빠진다"는 업계 통념은 정확하지 않음. 양자화가 결과를 개선하진 않지만, 서로 다른 레이어의 오류를 상쇄시켜 품질 손실을 최소화하는 것은 가능
9. 속도 지표(TPS)와 10배 개선 방법론
9.1. 지표 정의 문제
- TPS(Tokens Per Second)는 사실 두 가지: (1) GPU 전체 처리량(throughput) 관점의 TPS, (2) 사용자가 체감하는 지연시간(latency) 관점의 TPS — 후자는 정확히는 ITL(Inter-Token Latency)이라 불러야 하는데 업계가 관행적으로 TPS라고 부르는 것은 "업계의 잘못된 네이밍"이라고 지적
9.2. 금융과의 비교 — 왜 인퍼런스는 아직 최적화 여지가 크다고 말하는가
- 비유: 고도로 최적화된 금융 분야에서는 5bp(0.05%p) 개선도 대단한 뉴스지만, 인퍼런스 최적화는 여전히 20%, 100%, 200% 단위로 발표됨 — Philip 본인이 70년대 금융 분야에서 20%대였던 마진이 지금은 미미해진 것을 비유로 듦(Andrew Lo의 정량 재정거래(stat arb) 마진 축소 논문 언급)
- 함의: 인퍼런스가 "거의 다 풀렸다"고 말할 수 있는 시점은 연구자들이 "1% 더 빨라졌다"는 걸 발표하기 시작할 때다
9.3. 실제 10배 달성 사례 — GLM-5.2
- 베이스라인: 양자화 없이 Hopper 등에서 오프더셸프 추론 엔진(스펙큘레이터·KV 라우팅·디스어그리게이션 없음)으로 돌리면 대략 30~40 tok/s
- 최적화 스택 후: 300~400 tok/s 범위까지 달성 가능 — 최고급 하드웨어, 최적화된 스펙큘레이터, 완전한 양자화 작업, 높은 캐시 히트율, 지연시간에 맞춰 튜닝된 작은 배치사이즈와 병렬화 설정이 모두 결합돼야 함
- 현실적 범위: 10배는 매우 공격적인 수치이며 실무적으로는 4~6배 개선이 더 흔함. Artificial Analysis나 OpenRouter에서 최악의 프로바이더 대비 최고의 프로바이더 간 스프레드가 이 정도 범위를 보임
9.4. 개별 최적화의 곱셈 스태킹(단일 노드 기준)
- BF16→NVFP4: 정확히 2배는 아니고, 16→8bit에서 약 30~40%, 8→4bit에서 다시 약 30~40% 개선(곱해짐)
- 스펙큘레이터: 약 2배
- PD 분리(디스어그리게이션): 하드웨어가 충분하고 트래픽이 충분하면 약 2배
- 최신 커널/런타임: 추가로 두 자릿수 % 개선
- 소요 시간: 숙련자 기준 양자화 가중치 구축은 몇 시간~며칠, 스펙큘레이터 학습도 몇 시간~며칠, 디스어그리게이션은 최초 구축은 매우 어렵지만 이후 한계 구현은 비교적 쉬움
- 일반 사용자를 위한 팁: 본인이 직접 양자화하거나 스펙큘레이터를 학습할 필요 없이, 오픈소스 커뮤니티나 Nvidia가 공개한 체크포인트·프로바이더가 이미 학습해둔 스펙 덱(spec deck)을 그대로 가져다 쓸 수 있음. 예: GLM-5.2, Kimi는 자체 MTP(Multi-Token Prediction)를 갖고 있어 셀프 스펙큘레이티브 디코딩에 활용 가능(다만 이 대화에서는 화자들도 100% 확신하지 못하고 "누가 확인해달라"고 언급)
- 하드웨어로 얻는 이득: 동일 최적화 조건에서 H100 노드 1개→B200 노드 4개로 확장하면 2~4배 개선 가능. "무엇을 타는지"와 "누가 운전하는지" 둘 다 중요
9.5. Dynamo(Nvidia 오픈소스)의 위상
- 정체성: Dynamo는 "즉시 쓰는 최적화 시스템"이 아니라 클러스터 내에서 정보(특히 KV 캐시)를 이동시키는 개발자 툴킷(라이브러리)에 가까움. pip install만으로 대규모 성능 향상이 나오지 않으며, 여러 추론 프레임워크와 여러 하드웨어를 지원하는 라우터/코디네이터 역할
- 벤치마크 기준으로서의 한계: 업계 전체가 표준적으로 Dynamo 기반 배포를 쓴다면 신뢰할 만한 베이스라인이 되겠지만, 현재는 "실제로 필드에서 보는 것"과 비교하는 방식을 씀
10. 스펙큘레이티브 디코딩의 계보와 한계
10.1. Medusa → EAGLE → "스펙 온 스펙"
- 책에 수록된 이유: Philip의 책은 Medusa(오래된 기법)를 포함시켰는데, 이는 "가장 최신 기법"이라서가 아니라 이 분야가 어떻게 진화했는지 이해할 수 있는 어휘와 직관을 제공하기 위함. 스펙큘레이션 분야는 다른 어떤 영역보다 빠르게 진화해왔음
- EAGLE: 여전히 매우 흔히 쓰이는 기법
- 디플래시/디스파크 등 더 신기술: EAGLE보다도 최신인 기법들이 존재
- "스펙큘레이티브 스펙큘레이티브 디코딩" 논문: 트리(tree) 기반 접근으로 스펙큘레이터 자체를 스펙큘레이팅 — 유의미한 속도 향상은 있었으나 훈련 복잡도가 원 모델 훈련에 맞먹을 정도로 까다로움. 재귀적으로 스펙큘레이터를 계속 작게 만들면(스펙 오브 스펙 오브 스펙) 자원 경합·오케스트레이션·소프트웨어 복잡도가 계속 늘어나는 실질적 한계에 부딪힘 — 결국 "왜 그냥 더 작은 모델을 직접 안 쓰나"라는 라우팅 문제로 수렴한다는 지적
11. 로컬 AI 추론 vs 데이터센터 추론
11.1. 근본적으로 다른 제약과 목표
- 로컬 AI: "이 모델을 내 하드웨어에 어떻게 맞추고(fit), 어떻게 덜 멍청하게(less dumb) 만들까"가 목표
- 데이터센터: "이 모델을 어떻게 로드하고 덜 느리게(less slow) 만들까"가 목표 — 데이터센터도 "덜 멍청함"을, 로컬도 "덜 느림"을 신경 쓰지만 우선순위가 다름
11.2. 배울 점
- 로컬 AI 생태계의 강점: 동적 양자화를 포함한 다양한 양자화 기법, 프루닝, 디스틸레이션, 레이어 제거(layer removal) 분야에서 데이터센터보다 훨씬 전문적 — 다만 데이터센터에서는 레이어 제거는 크게 중요하지 않다고 평가됨
- Turbo 양자화 사례: 로컬(MacBook 등 메모리 대역폭이 느린 환경)에서는 큰 화제였던 최적화(turbo quant)가, B200처럼 3.5TB/s급 메모리 대역폭을 가진 GPU에서는 커널 자체의 오버헤드가 대역폭 절감분보다 커서 오히려 더 느려짐 — Nvidia도 이 최적화가 데이터센터에 부적합하다고 명확히 밝힘
- 엣지 특유의 병렬화 연구: 이기종 토폴로지(Mac mini 여러 대를 이더넷으로 연결하는 Exo 등)에서의 모델 병렬화 연구가 활발 — 다만 텐서 병렬화는 NVLink 같은 초고대역폭 인터커넥트를 전제하므로 로컬 환경에는 적합하지 않아, 로컬에서는 파이프라인 병렬화를 강제로 써야 하는 경우가 많음
12. 병렬화 전략: 텐서/엑스퍼트/파이프라인
12.1. 텐서 병렬화(Tensor Parallelism, TP)
- 원리: 모델을 여러 GPU에 완전히 샤딩하고, 각 스텝마다 각 GPU의 결과를 all-gather/all-reduce로 결합 — 이 때문에 인터커넥트 성능이 매우 중요
- 적용 범위: 어떤 모델에나 적용 가능하며 일반적으로 지연시간(latency)에 유리
12.2. 엑스퍼트 병렬화(Expert Parallelism, EP)
- 원리: MoE 전문가를 GPU당 통째로 배치(GPU당 8개 전문가 등), 라우터(매우 작음)는 모든 GPU에 복제. 각 전문가가 GPU 내부에서 자원 경합 없이 처리되므로 처리량이 크게 증가하고 GPU 간 통신량이 적어 인터커넥트 의존도가 낮음
- 적용 범위: MoE 모델에만 적용 가능(오늘날 병렬화가 필요할 만큼 큰 모델은 대부분 MoE라 이 구분의 실무적 의미는 약해짐)
- 활성 파라미터의 중요성: 로컬 추론(배치 사이즈=1)에서는 활성 파라미터 수만 계산에 반영되지만, API 서빙에서는 배치가 크므로 모든 파라미터가 활성화된다고 가정
12.3. 파이프라인 병렬화(Pipeline Parallelism, PP)
- 원리: 레이어를 나눠 서로 다른 하드웨어에 배치(레이어 절반은 이 장비, 절반은 저 장비)
- 쓰는 경우: 모델이 너무 커서 멀티노드 인퍼런스를 강제당할 때만 사용 — 예: 1조 파라미터 모델을 인터커넥트가 느린 H100 여러 노드에 올려야 한다면, 노드 간에는 파이프라인 병렬화, 각 노드 내부에서는 엑스퍼트+텐서 병렬화를 씀
- H100의 병목: HBM 용량 부족(H100=80GB/GPU) — B200은 GPU당 180GB, 노드 전체(8장)로 1440GB, NVFP4에서 파라미터당 0.5바이트이므로 2.8조 파라미터 모델(최신 Kimi)이 NVFP4로 1.4TB가 되어 GB300 8장(장당 288GB) 노드 하나에 겨우 들어감(단 KV 캐시 공간은 컨텍스트 길이에 따라 별도로 확보 필요)
12.4. 하드웨어 타겟팅 학습
- Jamba(AI21) 사례: 특정 하드웨어를 먼저 정하고 그에 맞춰 아키텍처 차원을 설계해 하드웨어를 포화시키는 접근 — 이렇게 하는 게 합리적임에도 대부분의 모델이 이렇게 하지 않는다는 게 화자들에게는 의외
- 오토튜닝: 훈련 단계는 플롭스 계산으로 수학적으로 최적 설정을 추론할 수 있지만, 추론 단계는 GPU 커널 오토튜닝처럼 (TP1/TP2/EP1/EP2 등) 조합을 실제 트래픽으로 스윕(sweep)해 경험적으로 최고 성능 설정을 찾는 방식에 가까움
- 일부 하드웨어 특화 학습 존재: Nvidia Nemotron 모델은 Blackwell에서 특히 잘 돌아가도록 설계됨. 다만 대부분의 오픈랩은 단일 칩보다는 최대한 넓은 하드웨어 호환성을 노리는 경향
13. 하드웨어의 ASIC화와 Rubin을 둘러싼 논쟁
13.1. 메가커널(Mega Kernel)에 대한 회의론
- 이론상 매력: 커널 실행을 하나로 융합하면 커널 실행 오버헤드를 줄일 수 있다는 발상
- 실전 회의론: 텐서 병렬화에서는 행렬의 절반이 GPU1, 절반이 GPU2에 있고, 소프트맥스 같은 비선형 연산은 전체 행(row)이 필요하므로 GPU끼리 반드시 통신해야 함 — 융합 커널이어도 각 스테이지의 비선형성 때문에 통신이 불가피. 게다가 최적화된 메가커널을 만드는 것 자체가 극히 어렵고, 실제로 메가커널을 만든 팀들조차 프로덕션에서는 개별 최적화된 컴포넌트를 병렬로 돌리는 TRT-LLM/modular 커널이 더 빠르기 때문에 실사용을 포기하는 경우가 많다고 언급
13.2. Rubin GPU와 "GPU가 점점 ASIC이 되어간다"는 관측
- 관측: Nvidia 테크리드가 트위터에 공개한 Rubin 스펙 티저에 따르면, Rubin의 설계 방향 자체가 "메가커널을 죽인다" — 즉 스레드 단위로 통제하지 않아도 되는 방향으로, systolic array·tensor core·TMA(Tensor Memory Accelerator) 등 모델 가중치 로딩과 특정 헤드 차원에 거의 전용된 구조가 계속 강화됨
- 비판적 시각(Ali): GPU가 사실상 "런치만 시키면 되는 ASIC들의 집합"이 되어가는 추세라면, 이는 CUDA로 스레드를 직접 제어하는 범용 컴퓨팅에서 점점 멀어지는 것 아니냐는 문제 제기 — QL/QDSL 같은 타일(tile) 단위 추상화가 이미 스레드 단위 제어를 대신해주고 있음을 근거로 듦
- 반론(Philip): 가중치를 아예 칩에 태워버리는(burn into the chip) 방식은 파인튜닝·양자화·새 체크포인트 대응이 불가능해져 칩이 한두 달 만에 무용지물이 될 수 있어 비현실적. 하드웨어 사이클이 워낙 길기 때문에(칩 설계는 출시 몇 년 전 시작) Nvidia가 시장 방향을 매우 잘 예측해온 것뿐이며, Rubin은 "공개된 오픈소스 아키텍처가 오늘날 것과 크게 다르지 않은 세계에서 처음부터 완전히 설계된 첫 칩"이라 워크로드 형태를 잘 반영한다고 평가
- 모델 특화 ASIC에 대한 입장: 수직 통합된 모델랩의 자체 ASIC(OpenAI-Broadcom 등)은 말이 됨 — Martin Casado가 팟캐스트에서 언급한 논리대로, 5000억 달러 규모 트레이닝 런을 한다면 그중 500억을 ASIC에 투자해 10% 남짓의 효율을 얻는 것도 합리적. 다만 범용 ASIC 스타트업들의 "타일 단위" 접근에 과도하게 집중하는 건 Rubin이 이미 처리할 것으로 예상되는 것보다 오히려 오더 오브 매그니튜드가 낮은 영역일 수 있다는 회의도 표함
- 모델 세대 교체 속도 논쟁: 반년마다 아키텍처가 바뀌는 오픈모델(GLM/Kimi/DeepSeek/Minimax)과 달리, GPT-5 계열이나 Claude 5 계열은 상당 기간 같은 체크포인트를 서빙 — "매년 5백억 달러씩 들여 새 ASIC을 만들고 작년 것을 버릴 것"이라는 시나리오에 회의적. Llama 3, GPT-4o를 여전히 쓰는 사례가 있듯, "작동하면 안 바꾼다"(if it works, don't change it)는 엔터프라이즈 관성이 존재하며, 신뢰성·예측가능성이 검증된 모델은 계속 쓰인다는 반론
14. 비디오/오디오 디퓨전 추론
14.1. 비디오 디퓨전의 근본적 난제 — 어텐션의 이차 스케일링
- 비교적 작은 모델 크기: 비디오 확산 모델은 언어모델보다 훨씬 작음(예: 1.2 모델은 200억 파라미터). 배치 처리도 하지 않고, 요청 하나당 GPU 하나가 배정되며 샤딩도 불필요
- 품질 격차는 오히려 훨씬 큼: 오픈 LLM과 최고 폐쇄형 LLM(GPT-5.5급) 사이의 격차는 6개월 전보다 훨씬 좁혀졌지만, 오픈 비디오 모델(Qwen 계열 등)과 Kling/Veo 같은 폐쇄형 사이의 격차는 여전히 매우 큼
- 토큰 폭발 문제: 16fps·480p·5초짜리 영상만 해도 잠재공간으로 압축한 뒤에도 (30×50×21) 토큰 규모가 되며, 5초 분량에 어텐션을 걸면 3만5000 토큰 규모의 어텐션 연산이 필요. 이게 제곱(quadratic)으로 늘어나므로 10초·20초·30초로 늘리면 연산량이 폭증해 1분짜리 컷신 생성조차 현재 컴퓨트로는 사실상 불가능
- 두 가지 해법 방향: (1) 전체 비디오에 풀 어텐션을 걸되 막대한 컴퓨트를 감수, (2) 스파스 어텐션(sparse attention)으로 토큰별 상위 12.5%(top-k) 관련 토큰(공간적·시간적 근접성)만 어텐션 — 다만 스파스 어텐션은 비디오 품질을 눈에 띄게 떨어뜨림
14.2. 오토레그레시브 비디오 vs 디퓨전
- 오토레그레시브의 장점: LLM에서 쓰던 최적화(스펙큘레이티브 디코딩 등)를 그대로 적용 가능하고, 프레임을 실시간 스트리밍하며 생성할 수 있음(2023년 GPT가 텍스트를 실시간 스트리밍하며 생성하던 것과 유사한 경험을 비디오로 구현 가능)
- 오토레그레시브의 치명적 단점: 현존하는 모든 오픈소스 오토레그레시브 비디오 모델의 품질이 형편없음 — 예를 들어 1.2 같은 디퓨전 모델의 "고양이와 개가 싸우는" 영상 품질과 비교하면 오토레그레시브 모델은 열화된 톰과 제리 수준
- 업계의 임시방편 — 청크 이어붙이기: Grok Imagine/Grok Video 같은 폐쇄형 모델은 7초 단위 청크를 이어 붙이는 방식으로 장편을 만드는 것으로 추정(비공개라 정확한 방식은 불명). 오픈소스는 마지막 프레임을 다음 청크의 텍스트+이미지-투-비디오 입력으로 넘겨 5초씩 이어붙이는 방식이 최선이지만, 이 방식은 각 청크마다 품질이 점점 열화되는 "드리프트(drift)" 문제가 있음 — 예: 색감이 점점 어두워지다가 25초 즈음엔 완전히 검은 화면이 되는 현상을 실제 데모에서 목격했고 너무 민망해서 공개를 포기했다고 언급
- 오토레그레시브가 가진 근본적 한계: 오토레그레시브는 시퀀스 앞으로만 진행되므로 한 번 생성된 과거로 되돌아가 전체 일관성을 맞추는 수정(correction)이 불가능 — 이것이 선로 이탈(going off the rails) 현상의 원인. 반면 디퓨전은 전체 잠재 토큰을 메모리에 유지한 채 시퀀스 전체를 반복 정제(iterate)할 수 있어 미래에 맞춰 과거를 조정 가능
- 텍스트가 왼쪽→오른쪽으로 잘 통하는 이유와 비디오가 다른 이유: 텍스트(언어)는 자연스럽게 좌→우 순차 구조를 갖지만, 비디오는 좌상단 픽셀과 우하단 픽셀이 동등한 수준으로 서로 어텐션해야 품질이 나오므로 순차성이 훨씬 덜 유효함
- 향후 전망: 오토레그레시브와 디퓨전을 결합한 하이브리드 아키텍처가 장기적으로 필요할 것으로 예상. 최근 이미지 모델(나노바나나, GPT 이미지)은 이미 오토레그레시브라는 게 확인된 것으로 보이지만, 이 접근이 아직 비디오 오픈소스 영역까지는 넘어오지 않음(Qwen Image 팀이 시도 중이라는 언급, Qwen Image 3 오픈소스화에 대한 기대감 표출)
14.3. 오디오/스피치와 텍스트 디퓨전
- 스피치는 오토레그레시브: 약 1년 반 전 Orpheus 아키텍처처럼, 어휘(vocabulary)에 파형(waveform) 토큰들을 추가해 LLM이 그 파형을 나타내는 토큰을 출력하도록 하는 방식으로 스트리밍 스피치를 구현. 오디오는 텍스트만큼 어려운 문제가 아닌데, 그 이유는 결국 오디오 모델도 텍스트 트랜스크립트를 LLM으로 생성한 뒤 스피치로 변환하는 구조이기 때문
- 음악은 아직 디퓨전과 오토레그레시브가 경합 중: 과거 한 시기에 두 접근이 대등한 성능을 보였음(명확한 결론 없음)
- 텍스트 디퓨전은 아직 초기 단계: Mercury(Baseten이 직접 호스팅), Diffusion Gemma(오픈소스) 등이 존재하지만 "빠르고 싼 토큰" 시장에 갇혀 있는 게 잘못된 포지셔닝이라는 지적 — 텍스트 디퓨전의 진짜 강점은 기존 LLM과 속도로 경쟁하는 게 아니라, "시(poem)나 플롯 구조처럼 처음부터 끝까지의 일관성(예: 음절 수 맞추기, 라임 스킴)을 확산시키듯 생성하는" 전혀 다른 API/유스케이스여야 한다는 주장(Midjourney의 David Holtz가 텍스트 디퓨전에 투자했었다는 언급, 결과물은 아직 안 나옴)
15. 트레이닝과 추론의 융합
15.1. 두 방향의 융합
- 트레이닝을 위한 추론(Inference for Training): RL 훈련에서 롤아웃(rollout)이 느리면(예: SGLang/vLLM 대신 구식 추론 엔진을 써야 하거나 신모델이 아직 최신 추론엔진에서 지원 안 될 때) 전체 트레이닝 파이프라인이 병목되고, 정책에서 너무 벗어난(off-policy) 롤아웃으로 훈련하지 않기 위해 대기해야 함
- 추론을 위한 트레이닝(Training for Inference): 스펙 학습, EAGLE 헤드 학습, 그리고 특히 양자화를 위한 포스트트레이닝 — PTQ(Post-Training Quantization)만으로 되는 경우도 있지만, NVFP4로 내렸을 때 품질이 심각하게 나빠지면 SFT나 양자화 인지 학습(QAT)을 거쳐야 함. Nvidia가 발표한 양자화 디스틸레이션 논문처럼, NVFP4 버전과 풀프리시전 버전 두 모델의 로짓을 비교해 디스틸레이션 훈련을 하는 최신 기법도 언급됨
- 결과: 요즘 추론 엔지니어는 훈련 기법에도 능숙해야 하고 훈련 파이프라인을 직접 작성할 수 있어야 함 — 두 영역이 실제로 "합쳐지고 있다(coming together)"
15.2. GLM-5.2의 자기 최적화 사례 (오프닝 인용 상세)
- 구조: Baseten의 클라우드 코드 하네스에 GLM-5.2 엔드포인트가 연결돼 있어, 모든 엔지니어링 팀이 그 엔드포인트를 사용. GLM-5.2는 자신이 서빙되는 SGLang 노드 인스턴스에서 포워드 패스를 수행하고, 프로파일 트레이스를 얻어 병목이 되는 커널을 분석하고, 새 커널을 작성하고, 다시 프로파일링 트레이스를 실행 — 완료되면 이미지를 업로드해 팀이 그 이미지를 받아 사이클을 반복
- 결과: Baseten 추론 엔진 안의 일부 GPU 커널은 실제로 GLM-5.2가 작성한 것이며, 프로파일링 트레이스와 커널 개선 과정을 GLM-5.2가 주도(driver)함
- 한계 인정: 아직 모델이 못하는 것이 많음 — 예를 들어 가장 값싸거나 쉬운 길로 "리워드 해킹(reward hack)"하려는 경향이 있고, 의사결정 자체를 잘 못하는 경우가 많음. 다만 모델이 자신의 추론을 최적화하는 현상 자체는 이미 실재하는 일
- 미해결 질문: GLM-5.2가 유독 자기 최적화에 능한 것인지, 아니면 단순히 접근 가능한 최고의 코딩 모델이라 이 역할을 잘한 것뿐이고 DeepSeek이나 Kimi를 최적화해도 똑같이 잘할지는 불확실 — "온폴리시(on-policy)가 아니면 오히려 성능이 나빠질 수도 있다"는 추측이 나옴
15.3. "RSI(Recursive Self-Improvement) until AGI"
- 연결: AI Engineer World's Fair의 화두였던 "AGI까지 재귀적 자기개선"이라는 태그라인과 연결지어, 모델이 모델을 훈련시키는 단계를 지나 이제 모델이 자기 자신의 추론을 최적화하는 단계로 가고 있다는 관측이 나옴 — "농담 같지만 실제로 벌어지고 있는 일"
- 과거와의 대비: 몇 년 전에는 허깅페이스에 새 모델이 나올 때마다 수작업으로 설정 파일을 작성해 돌리는 게 업무의 큰 부분이었지만, 이제는 "설정 파일 작성"이 원샷으로 자동화됨(단, 이는 모델이 자기 추론을 최적화하는 것이라기보다 모델이 SGLang 문서를 읽고 이해할 수 있게 된 것에 가깝다는 재정의)
- 연속 개선 루프(Continuous Improvement Loop)의 미래: 향후 몇 개월~몇 년 내로 주요 에이전트 빌더들이 "추론 → 추론에서 학습 → 제품에서 생성된 트레이스로 지속적 포스트트레이닝 → 롤아웃 A/B 테스트 → 더 나은 신호 확보 → 더 나은 모델 → 더 나은 제품"이라는 루프를 실제 프로덕션에서 가동할 것으로 전망. 동적 조정(dynamic adjustment)은 항상 정적 설정(static config)을 능가한다는 원칙이 스펙큘레이터 구성 등 전반에 적용될 것으로 봄
16. 지속학습(Continual Learning)을 둘러싼 논쟁
16.1. 두 가지 접근 경로
- 경로 A — 가중치 갱신: 모델이 처리한 모든 것으로부터 계속 학습해 새 지식을 가중치에 지속적으로 밀어넣는 방식 — 이 경우 추론은 단지 계속 새 가중치를 읽고 쓰기만 하면 됨
- 경로 B — KV 캐시 압축(Compaction): LoRA 레이어만 업데이트하는 방식이나, KV 캐시를 사실상 무한대로 만들면서도 지식 손실 없이 압축하는 방식("Still" 논문에서 다룸)
16.2. Charlie와의 트위터 논쟁 — 가중치 갱신 방식의 근본적 결함
- 문제 제시: "세계 최고 대학은 워털루다"라는 새 사실을 모델 가중치에 주입했다고 가정. 이 사실 자체("최고 대학이 무엇인가")를 물으면 정답을 맞히지만, 이를 활용해 추론이 필요한 2차 질문("어느 대학에서 인턴을 뽑아야 하는가")을 물으면 모델이 방금 주입된 사실을 추론에 활용하지 못하고 "둘 다 좋다"는 식으로 답함
- 근본 원인: MLP 내부의 특정 사실 하나를 바꾸는 것과, 그 사실을 활용한 추론(reasoning)을 연결하는 것은 전혀 다른 문제
- KV 캐시 압축이 이 문제를 푸는 방식: "Still" 논문에서처럼 지식을 손실 없이 압축한 거의 무한한 KV를 유지하면, 모델이 실제로 지속학습을 할 수 있고 이 논쟁에서 제기된 추론 연결 문제를 해결할 수 있음
- 최종 입장(Ali): Charlie와의 논쟁에서 Charlie의 주장이 옳았다는 것을 인정 — KV 캐시가 정답이며, 이 경우 추론 시스템 자체는 크게 달라지지 않는다(여전히 KV 캐시를 쓰되 갱신 방식만 추가되는 것뿐, 가중치도 스펙큘레이터도 바뀌지 않음)
17. 향후 트렌드 전망 (마무리 라운드)
17.1. Ali의 전망 — 인터커넥트가 다음 병목
- KV 캐시 전송의 2단계 병목: 한 노드에서 다른 노드로 KV 캐시를 옮길 때, (1) 캐시를 찾아 다른 노드로 전송, (2) 그 노드의 메모리에서 다시 GPU 텐서 코어로 전송 — 이 2단계 구조가 디코드와 PD 분리 시간의 병목
- HBM은 이미 매우 빠름(4.5TB/s급): 문제는 네트워크(인터커넥트) 통신 속도가 HBM 대비 몇 자릿수나 느리다는 것
- 이론적 가능성: 만약 인터커넥트가 극단적으로 빨라진다면, HBM을 거치지 않고 노드 간에 KV 캐시를 직접 전송할 수 있어 노드 간 분리 서빙(disaggregated serving)에서 거의 100배 속도 향상이 가능할 수 있음 — 왜 인터커넥트가 HBM보다 몇 자릿수 느린지 기술적 이유는 본인도 완전히 알지 못하지만, 이를 해결하면 디코드 속도가 2자릿수(orders of magnitude) 빨라질 것이라는 전망
17.2. Philip의 전망 — 지속적 학습을 위한 추론 엔지니어링과 규모의 10배 반복
- 지속학습 아키텍처 문제: "모든 처리한 것으로부터 학습해야 한다"는 전제를 받아들이면 추론 방식을 근본적으로 다르게 설계해야 하는가, 아니면 기존처럼 메모리 MD에 저장하고 KV 캐시로 소비되는 현재 패러다임이 이미 "깨지지 않았으니" 그대로 가도 되는가라는 질문 제기
- 시스템 레벨 사고의 부상: 보이스 에이전트처럼 3~5개 모델이 결합되는 멀티모델 구성(composition)과 그 사이의 통신을 다루는 문제가 더 커질 것 — 코스모스(Cosmos) 같은 새 월드모델을 포함해 새로운 모달리티가 계속 등장할 것이며, 스피치-투-스피치(speech-to-speech)는 아직 완전히 실현되지 않았지만 점점 가까워지고 있음
- 10배 스케일의 반복: AI의 전세계 사용량은 성숙한 기존 기술 대비 여전히 낮은 수준이며, 앞으로 여러 차례의 10배 수요 증가가 있을 수 있음. 업계 인프라는 전례 없는 수요 급증에 맞춰 매우 빠르게 구축돼 왔고 이 흐름은 멈추지 않을 것 — 롱테일 신뢰성 문제, 다음 10배·100배 토큰 물량을 어디서 확보할지가 계속 풀어야 할 숙제로 남아 있음
주요 발언 모음
"GLM-5.2 is very very good at writing GPU kernels. ... some of the GPU kernels that we're on GLM-5.2 within our inference engine is written by GLM-5.2." — Philip/Ali (오프닝)
"The LLM is actually not capable of doing anything. It's only capable of making suggestions of what to do and then if those suggestions are formatted in a certain way and applied to a system that knows what to do with them, then an action occurs." — Philip
"What's cool about working in inference... the reason that I think inference is going to be a useful place to do engineering for a long time is that if you look at highly optimized domains like say finance... when we publish optimizations, it's 20%, it's 100%, it's 200%." — Philip
"Auto reggressive video model will give you like degraded Tom and Jerry quality." — Ali (오토레그레시브 비디오 모델의 현재 품질 수준을 묘사)
"The key thing to understand between autoregression [and diffusion]... diffusion goes in both directions while auto regression it only goes forward in the sequence." — Philip
"I don't think inference is going to change that much because we still use KV cache... nothing changes in the weight so nothing changes in inference time." — Ali (지속학습 논쟁 결론)
핵심 데이터 & 수치
- 10배 목표 베이스라인: 무최적화 30~40 tok/s → 최적화 스택 적용 시 300~400 tok/s (현실적으로는 4~6배가 더 흔함)
- 양자화 단계별 개선폭: BF16→8bit 약 30~40%, 8bit→NVFP4(4bit) 추가 약 30~40% (곱연산이라 정확히 2배는 아님)
- 스펙큘레이터: 약 2배, PD 분리: 약 2배, 최신 커널/런타임: 추가 두 자릿수 %
- 하드웨어 스왑 단독 효과: 동일 최적화 조건에서 H100→B200(노드 수 확장) 시 2~4배
- 최신 Kimi 모델: NVFP4 기준 약 2.8조 파라미터, 1.4TB 용량 → GB300(장당 288GB) 8장 노드 하나에 탑재 가능
- HBM 대역폭: B200 기준 GPU당 약 3.5~4.5TB/s, H100 80GB vs B200 180GB(GPU당)
- Joshua의 양자화 연구: KL 발산 기반 레이어 선택 기법으로 Nvidia 대비 20% 더 많은 레이어를 양자화하면서도 더 나은 충실도(fidelity) 달성 — 원 논문 72페이지에서 39페이지로 축약
- 비디오 토큰 규모: 480p·16fps·5초 영상이 잠재공간 압축 후에도 (30×50×21) 토큰 → 어텐션 연산량 약 3만5000 토큰 규모, 시퀀스 길이 제곱에 비례해 폭증
- 비디오 모델 크기: 대표 오픈모델(1.2)이 약 200억 파라미터 — 최고 LLM 대비 훨씬 작음에도 폐쇄형과의 품질 격차는 LLM보다 훨씬 큼
- 오픈-폐쇄 LLM 격차: 6개월 전 대비 크게 좁혀져 현재는 거의 대등한 수준(Kimi K3 vs GPT-5.5급 비유), 반면 비디오는 여전히 큰 격차 존재
- 모드 붕괴 임계값: 동일 토큰 4회 이상 연속 출력 시 Baseten이 자동으로 요청을 재처리
결론 및 시사점
- 인퍼런스 최적화는 단일 묘책이 아니라 곱셈 스태킹이다: 양자화·스펙큘레이션·PD 분리·커널 개선을 개별적으로 1.3~2배씩 쌓아 10배에 근접시키는 것이 현재의 방법론이며, 각 요소는 이미 오픈소스 생태계(양자화 체크포인트, 스펙 덱)에서 상당 부분 재사용 가능해지고 있다.
- 양자화는 "손실"이지만 "더 손실 없이 만드는" 여지가 있다: KL 발산 기반으로 어느 레이어를 양자화할지 선택하면 양자화 오류를 상쇄시켜 더 많이 양자화하고도 더 나은 충실도를 얻을 수 있다는 반직관적 결과가 실증됐다 — 단순히 "얼마나 압축했는가"가 아니라 "어디를 압축했는가"가 관건이다.
- 프로덕션 신뢰성 문제는 모델 문제가 아니라 시스템 문제인 경우가 많다: 모드 붕괴, 클러스터 간 레이스 컨디션 등은 가중치가 아니라 추론 엔진·인터커넥트·커널 동기화 레벨의 소프트웨어 결함으로 드러난 사례가 많아, 문제의 원인을 진단할 때 모델·소프트웨어·하드웨어 삼자를 모두 의심해야 한다.
- 하드웨어의 ASIC화는 진행형이지만 논쟁적이다: Rubin 세대로 갈수록 GPU가 특정 워크로드(모델 가중치 로딩, 특정 헤드 차원)에 최적화된 구조로 수렴하고 있지만, 파인튜닝·양자화·체크포인트 갱신의 유연성을 위해 완전한 ASIC화(가중치를 칩에 굽는 것)는 비현실적이라는 균형점이 존재한다.
- 비디오/오디오 모달리티는 아직 LLM 수준의 성숙도에 도달하지 못했다: 어텐션의 이차 스케일링 문제로 인해 장편 고품질 비디오 생성은 오토레그레시브-디퓨전 하이브리드 아키텍처의 돌파구를 기다리고 있으며, 현재의 청크 이어붙이기 방식은 품질 드리프트라는 명백한 한계를 갖는다.
- 트레이닝과 추론의 경계가 사라지고 있다: 추론 엔지니어가 훈련 기법(QAT, 디스틸레이션, RL 롤아웃 최적화)에 능숙해야 하는 시대가 됐고, GLM-5.2가 자신이 실행되는 추론 엔진의 GPU 커널을 직접 작성하는 사례처럼 "모델이 자기 자신의 서빙 인프라를 최적화하는" 초기 형태의 재귀적 자기개선이 이미 프로덕션에서 관찰되고 있다.
- 지속학습의 정답은 가중치 갱신이 아니라 KV 캐시 압축일 가능성이 크다: 사실 하나를 가중치에 주입해도 그 사실을 활용한 2차 추론에는 연결되지 않는다는 한계가 실증됐으며, KV 캐시를 손실 없이 거의 무한히 압축하는 접근이 이 문제를 실질적으로 해결할 잠재력을 가진 것으로 평가된다.