추론의 최전선: 10배 빠른 모델에서 스스로 최적화하는 AI까지 — Philip Kiely & Ali Taha, Baseten

Chapter 1: 전용 배포, Speculative Decoding, 도구 호출 (03:16-11:18)

[03:16] 요청 라우팅의 이상은 먼저 가용한 프리필 워커를 확인하고, 가능하면 이미 입력이 캐시된 위치로 보내는 것 — 20만 토큰 중 일부라도 프리필을 건너뛸 수 있다
[03:27] 20만 토큰 규모 입력은 대체로 코딩이나 멀티턴 에이전트 작업이므로 캐시가 존재할 것이라고 기대할 만하다
[03:39] 일부 모델은 프리필과 디코드를 분리해 운영한다: 한 GPU 세트는 입력 처리·KV 캐시 생성·첫 토큰만 담당하고, 이후 별도 GPU 세트가 디코드를 수행한다
[04:03] 코딩에 특화된 추측 모델은 코딩 작업에서 드래프트 토큰 수락률이 높지만, 사용자가 다른 작업을 하면 오히려 느려질 수 있다

“[04:12] 제가 틀렸고 당신이 해리 포터 책 전체를 요약해 달라고 하는 것이라면, 더 느려질 것입니다.”

[04:43] Baseten의 차별점 중 하나는 사용량이 아주 높은 고객이 장비 단위로 임대해 직접 활용률을 최적화할 수 있다는 점
[04:56] 시간당 수백만 토큰을 처리하는 경우 토큰당 과금보다 시간당 과금이 훨씬 저렴할 수 있다
[05:03] 오픈 모델을 시험해 보려는 수요로 토큰당 과금 API 관심이 커지고, 사용 사례가 맞으면 전용 배포로 이동하는 흐름이 일반적
[05:41] speculative decoding: 작은 드래프트 모델이 후보 토큰 몇 개를 예측하면, 원본 모델이 한 번의 포워드 단계로 검증해 수락/거부한다
[06:00] 드래프트 모델은 고객의 실제 트래픽에 특화될 수 있어, 세 토큰씩 높은 확률로 수락되도록 훈련하는 것도 가능하다
[06:15] 공유 엔드포인트에서는 사용자의 작업 성격을 알 수 없기 때문에 이런 맞춤형 speculative decoding을 제공하기 어렵다
[06:30] 전용 배포에서는 처리량 최적화냐 지연 시간 최적화냐에 따라 배치 크기와 병렬화 전략을 직접 설정할 수 있다

“[06:57] 다른 사람이 엔드포인트에 1억 토큰 규모의 벤치마킹 트래픽을 던지는 일을 겪지 않아도 된다는 점입니다.”

[07:36] 사후 훈련 품질이 낮거나 속도를 위한 양자화 품질이 낮으면 모델이 JSON이나 도구 호출 형식을 읽는 데 어려움을 겪는다
[08:04] JSON 출력에서 요청의 끝을 정확히 닫지 못하면 모델이 도구 호출과 사고 과정을 섞어 버리고, 실제 실행 결과를 보지 못한 채 결과를 환각할 수 있다
[08:16] 도구 호출에서 가장 어려운 부분은 샌드박스가 아니라 훈련과 출력 형식 문제에 가깝다
[08:30] Baseten은 약 2년 전 구조화된 출력 해법을 발표했으며, 핵심은 상태 머신을 만들어 출력을 특정 형식으로 제약하는 것
[09:11] 추론 시스템에 출력 형식을 지정하면 출력이 그 형식에 맞춰진다는 보장을 받을 수 있지만, 잘못된 도구를 호출하거나 아무 도구도 호출하지 않는 문제까지 해결하지는 못한다

“[09:43] LLM은 실제로 아무것도 할 수 없다는 점입니다.”

[09:49] LLM은 행동의 주체가 아니라 제안을 생성하는 시스템이며, 그 제안이 형식화되어 처리 가능한 시스템에 전달될 때 실제 동작이 발생한다
[10:28] JSON은 여는 괄호와 닫는 괄호가 모두 있어야 완결되므로 스트리밍 중간에 파싱하거나 검증하기 어렵다
[10:43] TOML이나 YAML 유사 형식이 대안으로 시도되었지만 여전히 JSON이 지배적이다
[11:12] speculative decoding은 JSON처럼 형식이 정해진 출력에서 꽤 잘 작동하므로, 도구 호출의 디코드는 빠르고 스트리밍의 가치는 상대적으로 작다

Chapter 2: 양자화와 상쇄되는 오차 (28:21-32:14)

[28:27] 추론 최적화에서의 품질은 원본 모델의 100% 충실도에 얼마나 근접하느냐로 정의된다
[28:52] Baseten 내부 기준은 사용자가 Baseten API와 공식 API의 차이를 구분하지 못해야 한다는 것
[29:06] Kimi는 벤더 벤치마크를 공개해 특정 제공자가 나쁜 결과를 냈다는 점을 지적한 사례로 언급된다
[29:30] 소비자는 제공자가 모델을 잘못 양자화했다고 생각하기보다 모델 자체가 나쁘다고 판단하기 때문에, 모델 제작사는 벤더의 서빙 품질에 신경 쓸 수밖에 없다
[29:54] 양자화는 기술적으로 손실 양자화이며, 개선하는 것은 품질이 아니라 속도다
[30:11] 모델은 비결정적이라 FP4 양자화가 벤치마크에서 2베이시스포인트 더 높게 나오는 경우도 있지만, 이는 노이즈로 해석해야 한다

“[30:22] 저는 ‘그건 오차 범위 안이야’라고 하죠.”

[30:59] Baseten 리서치 인턴 Joshua의 연구에서 NVIDIA보다 20% 더 나은 GLM-5.2 양자화를 달성했다는 내용이 언급된다
[31:14] 양자화는 16비트 데이터를 4비트로 압축하는 과정이므로 정보 손실은 필연적이며, 엔지니어링의 목표는 이 손실을 최소화하는 것
[31:23] 핵심 업무는 어떤 레이어를 양자화할 수 있고 어떤 레이어는 하면 안 되는지 찾는 것 — 이미지 모델에서는 모듈레이션 레이어와 아웃 프로젝션을 양자화하지 않는다
[31:53] 연구의 반직관적 요지: 모델의 더 많은 부분을 양자화하는 것이 오히려 결과를 더 좋게 만들 수도 있다
[32:14] Joshua는 수학적 증명에서 양자화 오차가 서로 상쇄될 수 있음을 보여주었다

“[32:08] 더 많은 정보를 양자화한 모델이 더 잘 작동할 가능성이 있습니다. 양자화 오차가 서로 상쇄되었기 때문입니다.”

Chapter 3: Dynamo, 추측 디코딩, 로컬 vs 데이터센터 AI (40:48-50:10)

[40:48] 양자화된 가중치를 만드는 일, speculator를 만드는 일, disaggregated 설정 모두 아는 사람에게도 몇 시간에서 며칠이 걸리는 작업이다
[41:14] B200에 접근 가능한 일반 소비자라면 모델을 직접 양자화할 필요는 없다 — 오픈소스 양자화 체크포인트는 보통 공개되고, 아무도 안 내면 NVIDIA가 낸다
[41:33] Kimi나 GLM-5.2 같은 모델에는 자체 MTP(멀티 토큰 예측)가 있어 사용자가 직접 spec tech를 학습시킬 필요가 줄어든다
[42:19] Dynamo는 즉시 쓰는 완성형 시스템이 아니라 무언가를 구축하기 위한 툴킷에 가깝다
[42:27] KV 인식 라우팅, KV 오프로딩, PD disaggregation이 Dynamo가 다루는 핵심 범주
[42:50] Dynamo는 다중 하드웨어를 지원하지만 옵티마이저라기보다 라우터에 가까우며, 클러스터 내부에서 정보를 이동시키는 라이브러리 역할을 잘한다

“[43:15] 그냥, 예를 들어 pip install Dynamo를 하고 그러면 엄청난 성능 향상을 얻게 된다는 뜻은 아닙니다.”

[44:31] 책의 목표는 이 분야 전체에 대한 실용적인 어휘를 제공하고 각 기법의 직관을 주는 것이었다
[44:55] Medusa는 최신 기법이라기보다 분야가 어떻게 발전해 왔는지 이해하기 위한 역사적 맥락으로 포함되었다
[45:19] Tri Dao의 논문으로 “speculative decoding에 대한 speculative decoding”이 언급되며, 속도 향상은 크지만 학습 복잡성이 GAN 학습만큼 까다롭다고 평가된다

“[45:44] 말 그대로 추측적 디코딩 위의 추측적 디코딩입니다.”

[46:04] speculative decoding은 일반 모델을 위한 아이폰 자동완성 같은 개념 — 작은 모델이 토큰을 먼저 생성하고 큰 모델이 prefill로 검증해 여러 autoregressive 실행을 절약한다
[46:22] speculator 크기: GLM은 약 10억 파라미터, Minimax는 원래 모델의 약 60분의 1(한 레이어 정도) 규모
[46:44] 재귀적 speculation의 역설 — 작은 모델이 중간 speculator의 예측을 정확히 맞힐 수 있다면 애초에 가장 작은 모델을 직접 쓰면 되지 않느냐는 질문이 남는다
[47:01] 현실적 제약은 큰 모델을 실행하는 동일한 하드웨어에서 작은 모델도 실행해야 한다는 점이며, 여기서 오케스트레이션과 리소스 경쟁 문제가 발생한다
[48:08] 데이터센터 추론 엔지니어링과 로컬 AI 추론 엔지니어링은 비슷해 보이지만 근본적으로 다른 제약과 목표에서 출발한다

“[48:28] 로컬 AI에서는 이 모델을 내 하드웨어에 어떻게 올리고, 그다음 덜 멍청하게 만들 수 있을까가 문제입니다.”

[48:37] 반면 데이터센터 추론의 핵심 질문은 “이 모델을 로드한 뒤 어떻게 덜 느리게 만들 것인가”이다
[48:52] 로컬 AI 분야는 다양한 양자화, 특히 데이터센터 쪽에서 거의 건드리지 않는 동적 양자화에 강하다
[49:39] TurboQuantum은 메모리 대역폭이 매우 느린 MacBook 같은 로컬 기기에서 효과적이지만, B200에서는 같은 방식으로 유용하지 않다
[50:10] B200에서는 커널 내부 비양자화/양자화의 토큰당 오버헤드가 대역폭 절감으로 아끼는 시간보다 크기 때문이다

Chapter 4: 모델 병렬화, 오토튜닝, 메가 커널 (50:17-60:47)

[50:17] B200은 초당 약 3.5TB 대역폭이 있어 저장량을 극단적으로 줄일 필요가 적고, FB4·KV 캐시 양자화 같은 최적화가 반드시 필요하지 않을 수 있다
[50:45] ExoLabs 같은 로컬/이기종 토폴로지 환경에서는 모델 병렬화, 특히 머신 간 인터커넥트 문제가 중요해진다
[51:19] Baseten은 8개 GPU 전체로 모델을 샤딩하는 텐서 병렬화를 많이 사용하며, 이는 NVLink급 고대역폭 인터커넥트를 전제로 한다

“[51:27] 텐서 병렬화는 로컬 AI에는 잘 맞지 않습니다.”

[52:11] 배치 크기가 1인 로컬 추론에서는 MoE의 “활성 파라미터” 수가 체감 성능에 큰 영향을 주지만, API 호스팅에서는 배치 전체에서 결국 모든 파라미터가 사용된다고 가정한다
[52:34] 텐서 병렬화는 어떤 모델에도 적용 가능하지만 전문가 병렬화는 MoE에만 적용 가능 — 다만 오늘날 다중 GPU가 필요한 모델은 대부분 MoE라 구분의 중요성은 줄었다
[52:55] 전문가 병렬화는 전체 expert를 하나의 GPU에 올리고 GPU마다 여러 expert를 배치하며, 라우터는 작아서 각 GPU에 복제할 수 있다
[53:29] 전문가 병렬화는 GPU 간 통신량이 적어 인터커넥트 중요도가 낮은 반면, 텐서 병렬화는 all-gather와 all-reduce가 필요해 인터커넥트 성능이 매우 중요하다
[54:01] 실제 모델에서는 텐서 병렬화와 전문가 병렬화를 조합해 사용하며, 둘은 상호 배타적이지 않다
[54:39] H100에서 1조 파라미터 모델을 배포하려면 여러 노드가 필요하고, 노드 간 인터커넥트가 느려 파이프라인 병렬화가 유일한 선택지가 될 수 있다
[55:07] B200은 GPU당 180GB, 8개 노드에서 약 1.44TB를 제공하며, FP4에서 1조 파라미터 모델은 약 800GB가 필요하다
[55:37] AI21의 Jamba는 특정 하드웨어를 먼저 고르고 그 하드웨어를 포화시키도록 아키텍처 차원을 설계한 드문 사례
[56:08] 추론에서는 최적 구성을 이론적으로 계산하기보다 오토튜닝에 가깝다 — TP1, TP2, EP1, EP2 같은 조합을 실제로 테스트한다
[56:24] 실제 프로덕션 트래픽을 섀도잉해 어떤 구성이 최고의 TPM과 TPS를 내는지 실험적으로 확인한다

“[56:40] 오토튜닝이 최선의 구성을 찾는 방식인 것 같습니다.”

[57:25] all-gather와 all-reduce는 비용이 크며, 이를 줄이려는 흐름 중 하나로 메가 커널이 언급된다
[57:49] 어텐션의 소프트맥스처럼 전체 행이 필요한 연산에서는 비선형성 때문에 GPU 간 통신을 피할 수 없다
[58:08] 발표자는 메가 커널에 대해 상당히 비관적이다 — 이론적으로는 매력적이지만 매우 최적화된 메가 커널을 작성하는 것은 극도로 어렵다
[58:49] Triton과 모듈식 커널이 각 구성요소를 개별 최적화·병렬화할 수 있어 더 빠른 경우가 많고, 메가 커널을 연구하는 회사조차 프로덕션에서는 자주 쓰지 않는다
[59:14] Rubin은 메가 커널의 필요성을 줄이는 방향으로 설계된 듯하며, 이 때문에 메가 커널 연구가 큰 흐름으로 남지 않을 수 있다
[60:40] 초기 vLLM과 SGLang은 Ampere를 목표로 작성되었고 이후 Hopper와 Blackwell에 맞춰 업데이트되어야 했다
[60:47] 하드웨어 세대가 바뀔수록 속도와 긴급성은 커지지만 동시에 추론 시스템의 복잡도도 훨씬 커진다

Chapter 5: Rubin, GPU vs ASIC, 커스텀 AI 칩 (60:53-69:58)

[60:56] Rubin에서 새로워질 요소를 볼 때 NVIDIA Dynamo가 어떤 작업이 가치 있어질지에 대한 기술적 힌트를 준다
[61:11] NVFP4는 여전히 중요하며, 그 뒤에 있는 연산량과 Tensor Core 성능은 매우 크다
[61:32] 더 큰 변화는 “시스템적 사고”에 있으며, 단일 커널 최적화보다 전체 시스템 설계와 CPU–GPU·GPU–GPU 인터커넥트가 더 중요해진다
[61:50] Rubin 시대에는 KV 캐시 오프로딩, KV 인식 라우팅, 디스어그리게이션이 훨씬 더 중요해질 것으로 예상된다

“[61:59] 이는 추론 엔지니어링이 단순히 CUDA 커널 문제가 아니라, 매우 전통적인 하드웨어 인프라 문제이기도 하다는 뜻입니다.”

[62:29] 다른 발표자는 이를 더 밀어붙여 추론 최적화가 거의 전적으로 인프라 문제로 가고 있다고 주장한다
[62:43] GPU가 점점 ASIC에 가까워지고 있어, 개별 스레드 제어보다 GPU에서 일어나는 일을 오케스트레이션하는 방향으로 이동한다 — CuTile, CuDSL처럼 데이터 타일 수준에서 작업하는 흐름이 보인다
[63:30] 컴퓨팅 하드웨어는 범용 컴퓨팅부터 특정 모델 가중치 집합에 맞춘 하드웨어까지 이어지는 스펙트럼으로 볼 수 있고, Talus 같은 예시는 그 극단에 가깝다
[64:09] 진행자는 “가중치를 칩에 새기는” 방식에 비관적이다 — 파인튜닝·양자화·새 체크포인트가 계속 나오면 칩에 고정된 가중치는 한두 달 안에 쓸모없어질 수 있다
[64:29] GPU는 원래 범용 컴퓨터였지만 세대가 지날수록 Tensor Core, MMA 같은 특수 명령이 늘어 GPU를 ASIC들의 집합처럼 제어하게 만든다
[65:00] Rubin을 Ampere나 T4와 비교하면 사실상 ASIC에 가까운 장치처럼 보이지만, 여전히 CUDA로 프로그래밍 가능하므로 GPU다
[65:31] Tensor Core 명령들이 현재 시장에 존재하는 모델들의 헤드 차원에 거의 맞춰져 있다는 점이 언급된다
[65:45] 하드웨어 개발 사이클은 매우 길어서, 오늘 출시되는 칩은 수년 전에 설계가 시작된 결과물이다
[66:15] Rubin은 오늘날 오픈 모델 아키텍처 세계에서 완전히 설계된 첫 번째 칩에 가까우며, 앞으로의 워크로드 형태에 대한 이해가 많이 반영되어 있다
[66:43] 반면 수직 통합된 모델 연구소의 ASIC은 말이 된다 — OpenAI와 Broadcom이 함께 만드는 맞춤형 칩 같은 경우

“[67:03] 그중 500억 달러를 써서 ASIC을 만드십시오. 괜찮습니다. 그러면 그 ASIC에서 10% 이상의 효율을 얻을 것입니다.”

[67:16] ASIC 회사들이 흥미로운 이유는 타일 수준 최적화보다 더 넓은 표면적 — 실제 메모리·하드웨어 할당, 칩 간 통신 — 을 다루기 때문이다
[67:54] 추론을 10배에서 1000배 빠르게 만드는 진짜 장애물은 기존 GPU 설계 안에서 재배치 가능한 요소가 아니라 상호 통신이다
[68:08] 일부 ASIC/커스텀 칩 업체는 초당 30만 토큰을 목표로 하고 있으며, 이는 매우 야심찬 수치다
[68:23] 커널 작업을 하면 할수록 병목이 커널 자체가 아니라는 점이 더 분명해진다
[69:18] 매년 아키텍처가 바뀌는 새 모델이 나온다면, 매년 500억 달러를 들여 새 ASIC을 만들고 전년도 ASIC을 버리는 셈이 될 수 있다
[69:38] 반론: Llama 3 워크로드는 아직도 관찰되며, 모델이 완성됐고 신뢰할 수 있다면 굳이 바꾸지 않는다 — 이것이 오픈소스 모델의 약속 중 하나다

Chapter 6: AI 비디오, 제곱 어텐션, 자기회귀 생성 (72:41-81:42)

[72:49] 전 세계적으로는 NVL72보다 8X 랙이 훨씬 많기 때문에, 추론 엔지니어링은 더 흔한 하드웨어 배치까지 고려해야 한다
[73:36] DeepSeek R1은 6,710억 파라미터 규모였고, 이런 대형 모델의 등장이 Baseten이 Blackwell을 빠르게 채택하도록 압박했다
[74:17] 비디오 디퓨전은 LLM과 구조적으로 다르며, LLM에서 자기회귀적으로 다루는 많은 요소가 그대로 적용되지 않는다
[74:28] 비디오 디퓨전은 일반적으로 배칭하지 않고 각 요청이 하나의 GPU로 들어가 서빙되며, 보통 샤딩이 필요 없다
[74:35] Wan 2.2는 약 200억 파라미터로 최신 대형 LLM보다 몇 자릿수 작다
[75:02] 오픈소스 LLM과 폐쇄형 LLM의 격차는 과거 6개월 정도에서 이제 거의 동등한 수준으로 좁혀졌지만, 비디오 모델에서는 격차가 여전히 크다

“[75:15] Wan 1.2와 Kling 또는 Veo 같은 것의 차이는 하늘과 땅 차이입니다.”

[75:23] 오픈소스로 3시간 영화를 10달러에, 폐쇄형은 1,000달러에 만들 수 있어도 미디어 회사는 여전히 Kling이나 Veo를 선택할 가능성이 높다
[75:40] 수요가 적으면 혁신이 줄고 공개되는 오픈소스 체크포인트도 줄어드는 닭과 달걀 문제가 생긴다 — Wan 2.7은 오픈소스가 아니다
[75:57] 비디오 모델의 핵심 과제는 토큰 수다
[76:35] 480p 720 해상도에서 5초 81프레임은 잠재 공간에서 대략 30 x 50 x 21 토큰이 된다
[76:48] 단 5초 분량에도 약 35,000개 토큰에 어텐션을 수행해야 하므로 어텐션이 매우 큰 병목이 된다
[76:55] 어텐션은 O(n²)이므로 10초, 20초, 30초로 늘리면 계산량이 제곱으로 증가한다
[77:31] 스파스 어텐션에서는 각 토큰이 상위 12.5% 정도에만 주의를 기울이게 할 수 있고, 이는 공간적·시간적 국소성을 반영한다
[77:44] 하지만 스파스 방식으로 훈련하고 여러 기법을 적용해도 비디오 품질 손상이 남는다
[78:04] 결국 선택지는 2분짜리 비디오를 위해 약 백만 토큰에 풀 어텐션을 수행하거나, 자기회귀 비디오로 이동하는 것

“[78:32] 수백만 토큰도 결국 제곱 복잡도입니다.”

[78:52] 자기회귀 디퓨전 모델에는 LLM에서 논의한 최적화 기법(예: speculative decoding)을 상당 부분 가져올 수 있다
[79:03] 충분히 고품질로 스케일업된 자기회귀 비디오 모델이라면 첫 프레임부터 스트리밍하지 못할 이유가 없다 — 2023년 GPT가 텍스트를 스트리밍하던 경험과 비슷하다
[79:27] 단점은 현재 모든 자기회귀 비디오 모델의 품질이 매우 낮다는 점이다
[79:55] 현실적 해법으로 Grok Imagine은 7초짜리 청크들을 이어 붙이는 방식을 잘 수행하며, 오픈소스에서 가장 가까운 방식은 마지막 프레임을 이미지-비디오 모델에 다시 넣는 것
[80:32] 문제는 드리프트다 — 청크가 이어질수록 품질이 누적적으로 저하되고, 조금씩 어두워져 25초쯤에는 검은 화면이 될 수 있다
[81:34] 자기회귀 모델과 확산 모델의 핵심 차이는 어텐션 방향성 — 확산은 양방향, 자기회귀는 시퀀스 안에서 앞으로만 흐르며 이 때문에 시간이 지나며 통제에서 벗어나는 행동이 나타난다

Chapter 7: 훈련, 자기 최적화 모델, 지속 학습 (87:31-100:01)

[87:31] 확산 기반 언어 모델의 아이디어 — 전체 출력에 걸친 일관성이 자연스럽게 나타나고 끝부분이 시작 부분에 자기회귀적으로 의존하지 않아도 된다는 점 — 은 원칙적으로 타당하다
[88:01] Diffusion Gemma는 약 25B 규모로, 크기 대비 품질은 좋지만 훨씬 큰 모델들과 비교되고 있어 평가가 불공평할 수 있다
[88:56] 과거의 추론 엔지니어링은 오픈 모델을 가져와 GPU에서 빠르게 돌리는 정도였다
[89:06] 이제는 추론이 사후 훈련과 밀접하게 연결되며, “추론을 위한 훈련”과 “훈련을 위한 추론”이 모두 중요한 주제가 되었다
[89:24] 훈련을 위한 추론의 대표 사례는 RL 롤아웃 — 롤아웃이 느려지면 전체 훈련 파이프라인이 병목에 걸린다
[89:42] 너무 오프폴리시인 롤아웃으로 훈련하고 싶지 않기 때문에, 느린 롤아웃은 단순한 지연이 아니라 훈련 품질에도 영향을 준다
[90:02] NVFP4 수준으로 양자화할 때 운이 좋으면 PTQ만으로 되지만, 그렇지 않으면 SFT나 양자화 인식 학습이 필요할 수 있다
[90:30] NVIDIA 방식처럼 NVFP4 버전과 풀 프리시전 버전의 로짓을 비교해 FP4 모델을 증류 학습시키는 접근이 늘고 있다

“[90:47] 이제 학습 기법에 매우 익숙해야 하고”

[90:55] 훈련과 추론은 분리된 영역이라기보다 통합된 시스템으로 수렴하고 있다
[91:00] 궁극적 목표는 지속적 개선 시스템이며, 몇 달에서 몇 년 안에 선도적인 에이전트 개발자들이 이런 루프를 프로덕션에서 운영할 것으로 전망한다
[91:54] 제품에서 계속 생성되는 trace로 모델을 지속 post-training하고, 배포하고, A/B 테스트해 더 나은 신호·모델·제품을 얻는 루프가 유망하다
[92:37] 모델이 모델을 학습시키는 “파라미터 골프”가 언급되고, 다음 단계는 모델이 자기 자신의 추론을 최적화하는 것
[93:23] GLM 5.2는 GPU 커널 작성에 매우 뛰어난 모델로 소개된다
[93:31] Baseten 내부에서는 GLM 5.2 엔드포인트를 클라우드 코드 하네스에 연결해, GLM 5.2로 GLM 5.2 인스턴스의 포워드 패스를 프로파일링했다
[93:49] GLM 5.2는 profile trace를 분석해 SGLang의 병목 커널을 찾고, 새 커널을 작성한 뒤 다시 trace를 돌리는 사이클을 수행했다

“[94:08] 저희 인퍼런스 엔진에서 GLM 5.2에 쓰이는 GPU 커널 중 일부는 GLM 5.2가 작성한 것입니다.”

[94:20] 다만 모델은 아직 한계가 많아, 매우 똑똑해도 가장 싼 방향으로 무차별 대입하려 하거나 의사결정을 잘 못하는 경우가 있다
[95:23] 큰 흐름: 모델은 더 커지고 하드웨어는 더 강력해지며, 사용자는 일정 속도에 익숙해진 뒤 더 높은 속도를 요구한다
[95:44] 음성 에이전트는 3~5개 모델이 관여하고 모델 간 통신까지 필요하기 때문에 복합 시스템 최적화가 중요해진다
[96:31] 전 세계 AI 사용량은 더 성숙한 기술들과 비교하면 아직 몇 배의 10배까지 늘어날 수 있다
[97:19] 대규모 서빙에서는 메모리가 병목처럼 보이며, 특히 더 큰 모델과 KV 캐시 이동이 문제다
[97:40] KV 캐시를 다른 노드 메모리에 올렸다가 다시 GPU로 전송하는 2단계 전송이 대규모 환경에서 심각한 병목이 된다
[98:00] 이론적으로 극도로 빠른 NIC가 있다면 HBM 단계를 건너뛰고 KV 캐시를 노드 간 직접 전송할 수 있다

“[98:13] 거의 100배의 속도 향상을 얻게 되죠.”

[98:40] 또 다른 트렌드로 “지속 학습을 위한 인퍼런스 엔지니어링”이 제시된다
[98:57] memory.md 같은 곳에 정보를 넣고 KV 캐시를 활용하는 단순한 접근은 동작하지만 근본적으로 새로운 구조는 아니다
[99:06] 더 근본적인 질문은 추론을 재구성해서 추론하는 동안 학습하게 만들 수 있는가이며, 여기서 KV 압축이 중요하게 언급된다
[99:30] 지속 학습의 첫 번째 경로는 새로운 지식을 가중치에 밀어 넣는 방식으로, 추론 시스템이 계속 새 가중치의 쓰기와 읽기를 처리해야 한다
[99:47] 두 번째 경로는 KV 캐시 압축과 LoRA 레이어 업데이트이며, 이는 이전에 다룬 Engram 접근법으로 연결된다
[99:56] 그래디언트를 밀어 넣는 방식에 대한 반론은 한 번에 원홉 지식 하나만 고칠 수 있다는 점이다