Why Inference Matters 12x More Than Training

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Why Inference Matters 12x More Than Training를 중심으로, 추론 효율이 AI 서비스의 원가와 수익성을 좌우한다. DeepSeek V3의 학습 약 280만 H800 시간과 하루 추론를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

1. 추론 효율이 AI 서비스의 원가와 수익성을 좌우한다. DeepSeek V3의 학습 약 280만 H800 시간과 하루 추론 약 4만 3,000 H800 시간을 비교하면, 자료에서는 연간 추론량을 학습의 약 6배, 2년 누적을 약 12배로 설명한다. 이는 특정 공개 수치와 수명 가정에 따른 계산이며, 모든 모델에 적용되는 비율은 아니다.
2. 프리필과 디코드는 병목이 다르다. 입력을 처리하는 프리필은 계산 중심이고, 토큰을 생성하는 디코드는 메모리 중심이다. DeepSeek 사례의 입력 캐시 적중률 96%와 KV 캐시 72시간 보존은 재사용의 효과를 보여준다. 다만 같은 문맥이 반복되지 않으면 이 이점을 얻기 어렵고, 캐시를 포함한 처리량과 실제 신규 계산 처리량도 구분해야 한다.
3. 최적화는 커널뿐 아니라 라우팅·스케줄링·컴파일러를 함께 다뤄야 한다. 캐시가 남아 있는 GPU로 요청을 보내고, GPU 실행 중 다음 배치를 준비하며, 프리필과 디코드를 분리하는 방식이 효율을 높인다. Luminal은 동등성 포화로 여러 구현을 탐색하고 실제 하드웨어에서 시간을 측정한다. 컴파일 대상은 지정된 순전파 그래프이며, 추측 디코딩 등은 기존 추론 엔진의 기능을 활용한다.
4. 낮은 토큰 가격은 실제 작업 품질과 함께 평가해야 한다. 양자화는 메모리와 처리 비용을 줄이지만 도구 호출과 에이전트 수행 능력을 떨어뜨릴 수 있다. 같은 모델도 공급자의 가중치·커널·파싱·캐시 구현에 따라 동작이 달라진다. 공개 벤치마크, 회귀 테스트, 비공개 실사용 평가에 로그 확률과 도구 호출 실패율 감시를 결합해야 한다.
5. 긴 문맥과 에이전트 사용은 캐시·메모리 관리의 중요성을 높인다. RadixAttention은 공유 접두사를 재사용하고, 계층형 캐시는 GPU·호스트 메모리·스토리지로 보관 범위를 넓힌다. 하이브리드 모델에서는 전체 어텐션·슬라이딩 윈도·순환 상태를 함께 조율해야 하며, 통합 메모리 풀과 컴팩션으로 가변적인 문맥 길이와 단편화에 대응한다.

🧩 배경과 문제 정의

• AI 서비스를 대규모로 운영할 때 추론은 성능과 매출원가를 동시에 좌우하는 병목이다. 모델을 한 번 학습하는 비용뿐 아니라 반복해서 사용하는 동안 누적되는 연산량을 고려해야 한다.
• LLM 추론은 입력을 처리하는 프리필과 토큰을 생성하는 디코드로 나뉘며, 두 단계의 연산·메모리 특성이 달라 최적화 방식도 달라진다.
• 추론 효율은 모델 구조뿐 아니라 캐시 유지, 요청 라우팅, 스케줄링, GPU 커널, 병렬화가 함께 결정한다. 처리량을 높이면서 사용자에게 필요한 응답 속도와 운영 안정성도 충족해야 한다.

🕒 시간순 섹션별 상세정리

1. 모델의 생애주기에서는 학습보다 추론 연산량이 커진다

• DeepSeek가 공개한 수치에서 V3 학습에는 약 280만 H800 시간이 들었고, 추론에는 하루 약 4만 3,000 H800 시간이 사용됐다. 이미 오래된 자료여서 현재 추론 사용량은 더 많을 가능성이 있다. [01:53]
• 이 수치를 연간으로 환산하면 추론 연산량은 학습의 약 6배다. 가중치의 유효 수명을 2년으로 가정하면 약 12배가 되며, 사용자가 늘수록 추론의 비중도 커진다. 모델 비교에서도 학습 FLOPs와 함께 동일한 추론 FLOPs 조건을 중시해야 한다. [02:49]

2. 프리필 재사용과 디코드 효율이 추론 비용을 결정한다

• 입력 프롬프트는 프리필을 거치지만, 이미 처리한 부분이 캐시에 있으면 같은 계산을 반복할 필요가 없다. DRAM이나 Redis, SSD 등에 저장한 결과를 재사용하고 LRU 같은 캐시 정책을 적용하면 비용을 줄일 수 있다. [04:06]
• 학습과 프리필의 모델 FLOPs 활용률인 MFU는 약 50% 수준일 수 있지만, 디코드에서는 약 5%까지 낮아질 수 있다. GPU의 명목 연산 성능이 실제 서비스 성능으로 그대로 이어지지는 않는다. [04:40]

3. DeepSeek의 높은 처리량은 캐시 적중률과 보존 정책에 의존한다

• 공개 수치에서 GPU당 프리필 처리량은 캐시 적중을 제외하면 초당 6만 토큰이며, 입력 캐시 적중률은 96%다. 에이전트처럼 문맥을 재사용하는 작업은 적중률이 높지만, 서로 무관한 새 대화를 반복하면 프리필을 계속 수행해야 한다. [05:53]
• 캐시 적중을 포함한 GPU당 프리필 처리량은 초당 150만 토큰이고, 첫 토큰까지의 시간은 약 400밀리초, P99는 약 1초다. 디코드 처리량은 GPU당 초당 1만 4,000토큰으로, 디코드가 주요 병목으로 남는다. [06:25]

4. 연산 집약도와 루프라인으로 GPU 활용의 한계를 판단한다

• 연산 집약도는 메모리에서 옮긴 데이터에 대해 얼마나 많은 계산을 수행하는지를 나타낸다. 같은 가중치를 반복해서 활용하는 확산 모델과 비교하면 LLM의 연산 집약도는 낮으며, 확산 LLM과 넥스트 콘셉트 모델은 이를 높이는 접근으로 연결된다. [07:43]
• MFU는 실제 연산 성능이 최고 성능에 얼마나 가까운지, 모델 대역폭 활용률은 실제 메모리 대역폭이 최고 대역폭에 얼마나 가까운지를 나타낸다. 루프라인 분석에서는 최고 연산 성능과 ‘메모리 대역폭 × 연산 집약도’ 중 작은 값이 달성 가능한 성능을 제한한다. [08:29]

5. 모델 구조와 크기를 바꾸면 추론에 필요한 자원이 줄어든다

• MoE는 전문가 구조를 활용해 추론 연산량을 줄이고, SSM은 모든 층에 완전한 어텐션을 적용하는 대신 일부 층에만 적용하는 방식으로 계산을 줄일 수 있다. 잠재 어텐션은 압축을 통해 추론 부담을 낮추는 접근이다. [09:16]
• 양자화는 모델의 표현 정밀도를 낮추고, 증류는 큰 모델의 능력을 더 작은 모델로 옮긴다. 서비스에 필요한 능력을 작은 모델로 충족할 수 있다면 큰 모델을 그대로 제공할 필요가 줄어든다. [09:35]

6. 커널·런타임과 하네스에서 계산과 문맥의 낭비를 줄인다

• RadixAttention은 접두사·기수 트리를 통한 재사용, FlashAttention은 GPU 타일링, PagedAttention은 가상 메모리 페이징과 버퍼 풀에 연결되는 접근이다. 운영체제와 데이터베이스의 자원 관리 기법이 추론 최적화에도 활용된다. [10:22]
• 요청을 모두 큰 모델로 보내는 대신 작은 모델에서 시작해 필요할 때 더 큰 모델을 호출하면 연산량을 줄일 수 있다. 추측 디코딩은 초안 모델이 만든 토큰을 검증하는 방식이다. [10:41]

7. 공개 모델의 사용량과 가격 경쟁력이 추론 수요를 키운다

• Together는 몇 달 전 기준 월 400조 토큰을 처리했으며, 비슷한 시기에 공개된 Google Gemini 트래픽의 약 8분의 1에 해당했다. 해당 수치는 발표 시점의 최신 자료는 아니다. [13:29]
• 그해 초 OpenRouter를 통과한 토큰의 절반 이상은 공개 모델에서 발생했다. 공개 모델은 비슷하거나 경우에 따라 같거나 더 나은 품질을 제공하면서 비용은 최대 10배 저렴할 수 있어 사용 확대의 동력이 된다. [14:02]

8. 워크로드별 응답 요구가 최적화 목표를 바꾼다

• 코딩 작업에서는 캐시 적중률뿐 아니라 사용자가 다음 요청을 보내기까지의 간격, 필요한 반응 속도, 코드 생성 속도가 중요하다. 같은 모델을 사용하더라도 실제 사용 패턴에 따라 최적화 조건이 달라진다. [15:59]
• 첫 응답이 얼마나 빨라야 하는지와 전체 작업이 언제 끝나야 하는지 등의 SLA를 기준으로 시스템을 조정해야 한다. 처리량만 높이는 것으로 모든 사용자의 요구를 충족할 수는 없다. [16:08]

9. 요청 라우팅은 부하와 KV 캐시 위치를 함께 고려한다

• API 요청은 인터넷과 데이터센터를 거쳐 GPU 복제본에 배정되고, 토큰화와 배치 처리, 프리필·디코드를 거친 뒤 텍스트로 반환된다. 어느 GPU로 보낼지가 이후 처리 효율에 영향을 준다. [17:04]
• 코드베이스를 처음 처리한 GPU에는 후속 요청에서 재사용할 KV 캐시가 남을 수 있다. 따라서 단순한 라운드로빈 분산보다 데이터센터·GPU 사이의 부하 균형과 캐시가 상주하는 위치를 함께 고려해야 한다. [18:16]

10. 도구 호출을 포함한 입력 처리는 정확성 문제까지 다룬다

• 모델 자체는 행렬곱과 어텐션 등의 계산으로 구성되며, 인터넷 검색이나 명령 실행을 직접 수행하는 능력은 없다. 요청에 사용 가능한 도구 목록을 전달하고, 모델이 필요한 도구 호출을 선택하도록 해야 한다. [19:12]
• 검색·파일 탐색·빌드·테스트 같은 도구 정보를 모델 입력으로 올바르게 구성해야 하므로, 토큰화 주변의 처리는 단순한 문자 변환보다 복잡하다. 도구 호출이 정확하게 작동하도록 보장하는 과정이 필요하다. [19:31]

11. 스케줄러는 총처리량과 빠른 응답 사이의 균형을 정한다

• 들어오는 요청은 배치로 묶이거나 GPU 자원과 이전 요청의 완료를 기다린다. 스케줄링 선택에 따라 같은 GPU로 더 많은 사용자를 처리할지, 개별 요청에 더 빠르게 응답할지가 달라진다. [20:02]
• Google 검색의 Gemini 첫 응답은 빠르지만 후속 대화는 느린 사례는 서로 다른 스케줄링의 결과일 수 있다. 다만 백엔드 모델 자체가 다를 가능성도 있어 원인을 단정할 수는 없다. [20:17]

12. 프리필과 디코드는 서로 다른 하드웨어 병목을 가진다

• 프리필은 코드베이스와 질문처럼 입력된 문맥을 처리하는 단계로, 연산 집약도와 MFU가 높은 계산 중심 작업이다. [20:51]
• 디코드는 한 번에 하나 또는 소수의 토큰을 생성하며, 매 단계 모델 가중치를 GPU 메모리에서 연산 장치로 읽어야 하는 메모리 중심 작업이다. 두 단계를 분리하고 각각 다른 병렬화나 커널을 적용하면 효율을 높일 여지가 있다. [21:28]

13. 추론 가속은 커널부터 모델 표현까지 여러 층에서 가능하다

• GPU 프로그램인 커널을 최적화하면 어텐션·MoE 등의 실행을 빠르게 만들 수 있다. 프리필과 디코드를 다른 GPU에 배치하는 분리 방식도 사용자 경험과 총처리량에 영향을 준다. [22:31]
• 3조 파라미터 모델을 파라미터당 반 바이트인 FP4로 저장하면 약 1.5TB가 필요하다. 280GB 메모리를 가진 GPU 한 장에 담을 수 없으므로 모델을 여러 GPU에 어떻게 나눌지가 중요하며, 데이터센터 내부 라우팅도 함께 설계해야 한다. [23:03]

14. 실제 트래픽을 활용한 에이전트가 커널 최적화를 자동화한다

• LayerNorm·RMSNorm·소프트맥스 같은 개별 연산은 연산 집약도가 낮아 각각 별도 커널로 실행하면 FLOPs 활용률이 낮다. 이런 연산들은 학습과 디코드의 전체 활용률을 제한하는 원인 중 하나다. [24:40]
• 기존에는 전문 엔지니어가 순전파 경로를 살펴보며 최적화 지점을 찾았다. Together의 내부 프로젝트는 목표 모델·하드웨어·트래픽을 조건으로 에이전트가 핵심 실행 루프를 자동으로 최적화하도록 한다. [25:41]

15. 병렬화의 이득은 고속 연결 규모와 장애 대응에 달려 있다

• 텐서 병렬화는 행렬곱을 나누고 결과를 합치며, 파이프라인 병렬화는 층을 나눠 GPU에 배치한다. 데이터 병렬화는 같은 모델 구성을 유지하면서 서로 다른 시퀀스를 다른 GPU로 보낸다. 선택은 GPU 메모리와 지원 커널 등의 제약을 받는다. [27:16]
• 기존에는 고대역폭으로 연결되는 GPU가 8개 수준이어서 그 이상으로 모델을 나누면 느린 통신 경로가 병목이 됐다. 72개 GPU를 고대역폭으로 연결하는 랙에서는 전문가를 GPU별로 배치할 수 있으며, 각 전문가에 많은 토큰을 모으면 GPU에 유리한 큰 행렬곱 형태가 되어 처리량을 높일 수 있다. [28:48]

16. 양자화는 알고리즘 선택만으로 단순하게 끝나지 않는다

• 양자화에는 수백·수천 편에 이를 만큼 많은 연구가 있어 알고리즘 하나를 골라 적용하는 문제처럼 보일 수 있다. 그러나 실제로는 상당히 복잡해질 수 있으며, 제공된 구간은 그 복잡성의 구체적인 이유가 이어지기 전에 끝난다. [29:57]

17. 양자화의 성패는 메모리 절감과 실제 사용 품질을 함께 만족하는 데 달려 있다

• BF16은 파라미터당 16비트, 즉 2바이트를 사용하므로 3조 파라미터 모델에는 6TB가 필요하다. 머신러닝 계산은 모든 비트의 정밀도를 반드시 요구하지 않아, 8비트나 4비트로 줄이면서도 상당한 품질을 유지할 수 있다 [30:44]
• 하드웨어에 맞는 양자화는 GPU당 토큰 처리량을 높이지만, 중요한 업무에 쓰이는 모델에서는 품질 검증이 함께 필요하다. Together는 배포 전 내부 사용으로 도구 호출 실패와 실제 수행 능력 저하를 확인한다 [31:56]

18. MiniMax의 NVFP4 양자화는 원본 성능 유지와 서빙 수익성을 연결했다

• MiniMax는 M3 모델을 NVFP4로 양자화하는 데 어려움을 겪었다. Together는 커널과 서빙 관점에서 NVFP4가 엔비디아 GPU에 적합하다고 판단했고, 자체 방식으로 기존 FP8 모델의 성능을 맞췄다 [33:38]
• 성능을 유지한 양자화로 더 많은 토큰을 제공하면서 모델 학습 이후 수익성 있는 서빙으로 이어지는 경로를 지원했다. 서빙 수익을 다음 모델 학습에 투입하는 선순환이 이 협업의 의미다 [33:54]

19. 공개 점수와 내부 동작, 에이전트 수행을 함께 검사해야 품질 저하를 찾을 수 있다

• 일부 공개 벤치마크는 점수가 90%를 넘어 포화되어 있지만, 이런 지표에서도 1포인트 이상의 변화는 실제 작업 능력에 문제가 생겼다는 경고로 본다. 레이어별 KL 발산으로 활성값이 얼마나 달라졌는지도 확인한다 [36:43]
• 과거 모델 문제를 수백 개의 회귀 테스트에 축적하고, Flappy Bird 같은 에이전트 평가를 병행한다. 모델이 자신의 커널을 최적화하는 작업도 검사해, 이전에 가능했던 최적화를 수행하지 못하면 원인을 조사한다 [37:15]

20. 대규모 GPU 연결은 스위치와 케이블을 통한 집단 통신에 의존한다

• 설명된 랙에서는 GPU 4개가 들어 있는 각 트레이가 굵은 케이블로 대형 스위치에 연결되며, 이를 통해 all-reduce 같은 통신을 수행한다. 다만 발표자는 8개 GPU 연결에서 72개 연결로 확장된 구체적인 하드웨어 기술 변화에는 익숙하지 않다고 밝혔다 [37:59]

21. 원본 학습 데이터가 없는 서빙 업체는 재학습 없는 양자화를 선호한다

• 양자화 이후 모델을 다시 학습하는 방법도 있지만, 원래 학습 데이터 전체가 없으면 기존 지식을 잊을 수 있다는 이유로 Together는 재학습 없는 접근을 사용한다 [39:36]
• 보정 데이터와 자체 공개한 Scale Search 등을 조합하며, 여러 재학습 없는 양자화 기법 중 무엇을 선택하고 어떻게 결합하는지에 주의를 기울인다. 개별 기법만큼이나 조합 방식과 꼼꼼한 평가가 중요하다 [40:12]

22. 새로운 아키텍처는 기존 모델의 구성 요소로 빠르게 흡수되고 있다

• 한때 활용 가능성이 낮게 평가되던 SSM과 희소 어텐션이 대형 모델에 들어가고 있다. Kimi K3의 KDA는 SSM·선형 어텐션 계열 레이어로 해석할 수 있으며, 확산 언어 모델은 추측 디코딩의 제안 모델에 활용된다는 설명이다 [41:24]
• 루프 모델은 같은 레이어에 토큰을 여러 번 통과시켜 가중치를 늘리지 않고 학습 연산량을 높이는 방식이다. 발표자는 OpenAI와 Anthropic도 이미 이를 사용하고 있다고 말했다 [41:51]

23. Ollama의 클라우드 확장은 대형 모델 접근성과 공급자 통합 문제로 이어졌다

• Ollama는 2023년 로컬에서 오픈 모델을 실행하는 프로젝트로 출발했다. 목표는 오픈 모델에서도 OpenAI·Anthropic 수준의 개발자 경험을 제공하는 것이었으며, 5,000억~1조 파라미터 모델들이 등장하면서 로컬 경험을 클라우드로 확장했다 [43:50]
• 클라우드에서는 최신 모델 접근, 속도, 안정성을 중시한다. 공급자마다 잘 서빙하는 모델이 달라 여러 공급자를 라우팅으로 결합하면 각자의 장점을 활용할 수 있다 [45:15]

24. 같은 모델 이름이 같은 추론 품질을 보장하지 않는다

• 사용자는 비용, 지능, 속도, 지역과 개인정보 보호를 함께 고려한다. 통합된 공급자 중 하나라도 기준에 못 미치면 전체 사용자 경험이 그 취약한 공급자의 수준으로 떨어질 수 있다 [46:30]
• 과도한 양자화, 하드웨어 결함, 다른 가중치 버전뿐 아니라 도구 호출 복구, 스키마 적용, 토크나이저 수준의 파싱도 오류 원인이 된다. 샘플링, 커널, 캐시 정밀도의 차이는 긴 문맥 같은 특정 조건에서만 드러날 수도 있으며, 잘못된 모델 이름으로 서비스되는 경우도 있다 [47:39]

25. 에이전트의 연속 호출은 작은 편차를 큰 실패 확률로 증폭한다

• 코딩 에이전트는 긴 문맥과 여러 차례의 연속 호출을 사용하므로 부정확한 응답의 영향이 누적된다. 매 단계에 10%의 편차 가능성이 있다는 예에서는 15단계 작업의 누적 오류 가능성이 약 79%에 이를 수 있으며, 작업이 복잡해질수록 문제가 커진다 [50:25]

26. 전체 평가와 도구 호출 검증기는 유용하지만 운영 비용이 다르다

• 공급자별 벤치마크를 반복하면 잘못된 양자화 등 여러 문제를 찾을 수 있다. 다만 실행 비용이 높고 시간이 오래 걸려 지속적인 감시 수단으로 사용하기 어렵다 [51:36]
• Moonshot이 공개한 도구 호출 검증기와 공급자 점수표는 정확도를 높이려는 경쟁을 유도했다. 모델 개발사가 검증 도구를 함께 제공하면 다른 업체가 모델을 올바르게 서빙하는지 확인하는 데 도움이 된다 [52:12]

27. 출력 분포 비교는 저렴하지만 문제 원인까지 설명하지는 못한다

• 기준 모델과 공급자 API의 출력 분포를 비교하면 두 결과가 얼마나 다른지 측정할 수 있다. Ollama는 이를 라우팅과 모델 통합에 도입하는 방안을 검토하고 있으며, 테스트당 약 1달러 수준으로 벤치마크보다 저렴할 수 있다 [52:44]
• 이 방식은 부적절한 양자화 같은 세밀한 문제를 놓칠 수 있고, 차이가 발생한 이유도 직접 알려주지 않는다. 기준 모델을 별도로 실행해야 하는 비용도 필요하다 [53:11]

28. 로그 확률은 서빙 스택의 조용한 변화를 감지하는 저비용 신호다

• 다음 토큰의 로그 확률을 과거 기준값과 비교하면 배포 위치나 추론 엔진 변경에 따른 편차를 감지할 수 있다. 단일 토큰 요청에 가까운 비용으로, 공개적으로 드러나지 않은 서빙 스택 변경을 추적하는 데 활용할 수 있다 [54:14]
• 로그 확률을 제공하지 않는 API가 많다는 제약이 있다. 과거와의 변화만 측정하는 방식에서는 최초 상태부터 잘못 서빙되고 있었다면 그 오류 자체를 판별하기 어렵다 [54:36]

29. 요청의 형태만 관찰해도 도구 오류와 무한 반복을 포착할 수 있다

• 데이터 보관 없이도 도구 호출 성공·실패 수, 오류 발생, 요청 형태와 출력 길이의 변화를 감시할 수 있다. 출력 길이 같은 신호는 모델의 무한 반복을 조기에 발견하는 데 도움이 된다 [55:18]
• 요청마다 관측값을 누적해 점수를 유지하면 공급자 품질을 계속 추적할 수 있다. Ollama가 현재 활용하는 접근이며, OpenRouter의 Exacto 방식도 유사한 사례로 나온다 [55:30]

30. 일관된 서빙에는 가중치 공개를 넘어 실행 스택과 검증 수단이 필요하다

• 연구소가 가중치와 예제 코드뿐 아니라 실제 추론 스택과 공식 양자화 모델을 제공하면 공급자 간 차이를 줄일 수 있다. DeepSeek의 자체 스택 공개와 출시 전 전문 업체와의 양자화 협업은, 모델 공개 후 제3자가 별도로 양자화하던 방식에서 벗어나는 사례다 [57:19]
• 낮은 수준의 API를 사용해 도구 호출 처리와 추론·사고 내용 추출을 공통 하네스로 옮기면 공급자 간 일관성을 높일 수 있다. 핵심 애플리케이션에 들어가는 LLM의 품질 감시는 스타트업 기회가 될 수 있지만, 해당 서비스가 이미 존재하는지는 확신하지 않았다 [57:50]

31. 긴 문맥에서의 품질 변화도 로그 확률 비교로 탐색할 수 있다

• 로그 확률 감시는 단일 토큰 프롬프트의 결과를 기준값과 비교하는 방식이며 특정 문맥 길이에 한정되지 않는다. 프롬프트를 점차 길게 만들면서 로그 확률의 편차가 어떻게 달라지는지 측정하는 방법도 가능하다는 제안이다 [1:00:01]

32. 긴 문맥 검증과 비공개 평가로 품질 저하를 가려낸다

• 일부 제공업체는 모델의 문맥 창을 제한한다. 특히 문맥이 20만 토큰을 넘어가면 다음 토큰 정확도가 기준 제공업체나 이전 결과와 일관되는지 확인하는 방식이 전체 평가를 수행하는 대안이 될 수 있다 [1:00:33]
• 최저 토큰 가격을 둘러싼 경쟁은 특정 트래픽이나 공개 평가에만 맞춘 최적화를 유도할 수 있다. 고객의 실제 데이터와 사용 사례로 비공개 테스트를 구성하면 제공업체가 평가에 맞춰 대응하기 어려워지고, 고객이 경험한 품질 문제도 검증에 반영할 수 있다 [1:01:42]

33. 로컬 추론에도 품질 검증이 필요하며 라우팅 범위가 넓어진다

• 로컬 실행에서도 모델을 제공하는 기술 스택을 신뢰성 있게 시험해야 한다. 직접 운영하는 추론 엔진이 계속 업데이트되고 오픈 모델의 양자화 변형도 많아, 실서비스에는 무거운 벤치마크보다 가벼운 검사가 필요하다 [1:03:45]
• 로컬 코딩 모델의 성능 향상으로 이전에 클라우드 모델에 의존하던 어려운 작업을 개인 기기에서 처리할 가능성이 커졌다. 이에 따라 라우팅은 클라우드 제공업체 사이의 선택에서 로컬과 클라우드를 함께 선택하는 문제로 확대될 전망이다 [1:04:21]

34. 컴파일러 효율이 GPU 자원을 토큰과 수익으로 바꾼다

• 컴파일러는 GPU 연산량이나 사용 시간을 토큰으로 전환하는 효율을 결정하며, 이 효율이 추론 사업의 손익에 큰 영향을 준다. Luminal은 여러 하드웨어에 모델을 효율적으로 매핑하는 방법으로 동등성 포화를 채택한다 [1:05:17]
• 컴파일 시점의 탐색을 활용하면 복잡한 변환 휴리스틱과 모델마다 수정해야 하는 대규모 커널 라이브러리의 유지 부담을 줄일 수 있다. 작은 공통 컴파일러 코어에 백엔드를 연결해 Nvidia·AMD GPU, TPU, Trainium 등 여러 하드웨어를 지원하는 접근이다 [1:06:20]

35. 작은 기본 연산 집합으로 모델과 하드웨어의 연결을 단순화한다

• 신경망의 핵심 계산을 밀집 선형대수로 보고, 덧셈·곱셈·합산 같은 약 14~15개의 기본 연산으로 분해한다. 이 설계는 튜링 완전성 대신 PyTorch로 표현한 모델을 지원 백엔드에 컴파일하는 범위를 지향한다 [1:08:03]
• 행렬곱도 별도 기본 연산으로 두지 않고 브로드캐스트 곱셈과 합산 리덕션으로 분해한다. 약 2,000개의 PyTorch 연산과 다양한 하드웨어 연산을 각각 직접 연결하는 대신, RISC 방식의 작은 중간 연산 집합을 공통 접점으로 사용한다 [1:08:47]

36. 변환 순서를 직접 설계하는 대신 동등한 프로그램을 탐색한다

• 슈퍼옵티마이제이션은 같은 프로그램의 여러 표현을 탐색하고 비용 기준으로 유리한 구현을 선택하는 접근이다. 모델 구조·백엔드·데이터형이 늘수록 구현 조합이 곱셈식으로 증가하므로, 사람이 각 변환 경로를 미리 설계하는 방식은 부담이 커진다 [1:09:52]
• 작은 재작성 규칙에는 어떤 표현들이 동등한지만 명시한다. 동등성 포화는 이 규칙으로 탐색 공간을 만들고, 어떤 규칙을 언제 적용할지는 탐색에 맡긴다 [1:10:20]

37. E-graph가 변환 전후 표현을 보존하고 빠른 구현을 추출한다

• 일반적인 재작성은 기존 표현을 교체하지만, E-graph는 변환 전후 표현을 함께 보존한다. 규칙이 더 이상 정보를 추가하지 못하는 포화 상태까지 확장한 뒤 여러 구체적 프로그램을 추출하고, 실제 하드웨어 실행 시간을 비교한다 [1:11:42]
• A × 2 ÷ 2의 예에서는 비트 시프트 같은 동등 표현을 추가하다가 원래 식과 A가 같은 동등성 집합에 들어간다. 전체 패턴을 미리 인식하는 전용 규칙 없이도 단순화 경로를 구성할 수 있다 [1:13:04]

38. 하드웨어별 연산과 실행 계층을 공통 IR에 연결한다

• 새 하드웨어의 연산을 컴파일러가 이미 이해하는 기본 연산과 동등한 형태로 정의하면 기존 규칙과 연결할 수 있다. 이 방식은 구조가 다른 백엔드를 추가할 때 필요한 개별 변환 구현을 줄인다 [1:15:29]
• 하드웨어는 스레드·워프·스레드 블록·GPU·노드처럼 계층을 이룬다. 다중 수준 IR은 이 계층을 명시적으로 표현하고, 서로 다른 수준에서 구현된 커뮤니티·제조사 라이브러리 연산을 동등성 규칙으로 탐색에 포함한다 [1:16:22]

39. 일반 커널과 메가커널을 함께 선택한다

• CPU에서 호출하는 cuBLAS의 전체 행렬곱과 CUTLASS·cuBLAS DX·ThunderKittens 등의 스레드 블록 수준 연산을 서로 다른 구현 후보로 활용할 수 있다 [1:17:04]
• 낮은 수준의 연산 부분 그래프를 묶어 메가커널을 만들고, 한 번의 순전파 안에서 일반 커널과 메가커널을 혼합할 수 있다. 특히 큰 모델에서는 메가커널이 항상 최적의 선택은 아니다 [1:17:33]

40. 복잡한 비용 예측 대신 실제 하드웨어에서 실행 시간을 잰다

• 현대 GPU의 실행 시간을 실행 없이 정확히 예측하는 비용 모델은 만들기 어렵다. Luminal은 대상 하드웨어에서 후보를 직접 실행해 비교하며, 개발자의 직관으로는 불리해 보이는 변환이 실제로는 성능을 개선하는 경우도 활용한다 [1:18:49]
• 모든 후보를 실행하지는 않는다. 루프라인 분석상 최선의 경우에도 이미 측정한 동등 구현보다 느린 후보는 조기에 제외하고, 나머지는 가능한 한 실제 하드웨어에서 측정한다 [1:19:15]

41. 이기종 클라우드 운영으로 컴파일러를 사업화한다

• Luminal은 여러 종류의 하드웨어로 구성한 클라우드를 운영하며 수익화 문제를 해결했다고 주장한다. 처리 규모는 월 약 80조 토큰과 수백만 장의 이미지이며, 범용 컴파일러를 활용해 단백질 접힘·바이오·이미지 모델 등도 실행한다 [1:20:09]
• 다양한 하드웨어를 컴파일러로 활용해 연산 자원의 범용 상품화를 추진한다. 당시 인원은 8명이며, 빠른 성장에 맞춰 채용을 확대하고 있다 [1:20:24]

42. 연산 재배치는 토큰 품질에 영향을 주므로 수치 정확도를 명시해야 한다

• 트리 방식의 합산과 순차 합산은 서로 다른 결과를 낼 수 있다. 이러한 수치 오차가 출력 토큰 품질에도 영향을 주므로, ML 최적화에서도 수치 정확도를 명시적으로 모델링해야 한다 [1:21:34]
• 연산 순서를 바꾸는 규칙은 하드웨어 활용 측면에서 여전히 이점이 있다. 예를 들어 텐서 코어가 두 입력을 서로 다른 메모리 공간에서 읽도록 구현되어 있다면, 입력 배치를 바꾸는 것이 유리할 수 있다 [1:21:57]

43. 탐색 범위를 제한하고 컴파일 시간을 실행 성능과 교환한다

• 전체 모델 순전파를 포함한 프로파일링도 빠르게 반복할 수 있다는 설명이며, 한 번의 반복에 10밀리초 미만이라는 수치가 드러난다. 탐색에는 유전 알고리즘 등을 사용하고, MuZero 같은 학습 기반 탐색은 향후 개선 가능성으로 남겨 둔다 [1:23:22]
• 실제로 탐색하는 범위는 전체 공간의 약 1%의 1% 수준이다. 전역 최적해를 보장하기보다 전역 최적해에 가까운 지역 최적해를 찾는 목표이므로 탐색 부담을 줄일 수 있다는 입장이다 [1:23:37]

44. 실제 고객의 텐서 형상을 반영해 측정 정확도를 높인다

• 자체 클라우드를 운영하므로 고객이 실행할 텐서 형상과 데이터 분포를 파악하고, 가능한 한 실제 입력에 가까운 조건으로 성능을 측정한다 [1:24:52]
• 재작성 규칙이 올바르면 변환 결과도 올바르다는 전제 아래, 후보마다 정답 여부를 다시 확인하기보다 실제 사용에 맞는 텐서 형상으로 실행 시간을 측정하는 데 집중한다 [1:25:06]

45. 연산 메타데이터와 재작성 증명으로 오류를 추적한다

• PyTorch가 고수준 연산에 붙인 메타데이터를 컴파일러 내부 변환 과정에서도 추적한다. PyTorch 프로파일러도 활용해 병목과 문제 위치를 파악한다 [1:25:47]
• egglog는 출력 프로그램이 입력 프로그램에서 어떤 재작성 연쇄를 거쳐 만들어졌는지 증명을 제공할 수 있다. 잘못된 출력이 나오면 이 경로를 따라 유효하지 않은 규칙을 좁혀 간다 [1:26:13]

46. 기본 연산으로 분해한 뒤 실행 단계에서는 다시 융합한다

• 작은 기본 IR로의 분해가 최종 실행에서도 연산을 잘게 나눈다는 뜻은 아니다. 하드웨어 구현으로 낮추는 과정에서 여러 형태를 탐색하고 연산을 다시 융합한다 [1:26:56]
• DRAM을 오가는 데이터가 다른 후보보다 한 자릿수 규모 더 많은 커널은 불리하다고 판단하는 등 루프라인 휴리스틱을 활용한다. 중간 표현에서 펼쳐진 연산을 탐색으로 다시 묶어 융합된 구현을 만든다 [1:27:19]

47. 밀집 선형대수로 범위를 제한해 분석과 가지치기를 가능하게 한다

• 범용 언어의 거의 무한한 컴파일 가능성과 달리, 밀집 선형대수 프로그램은 훨씬 좁은 공간을 이룬다. 튜링 완전성을 추구하지 않는 제한이 프로그램의 성질을 분석하고 슈퍼옵티마이제이션을 적용하는 데 유리하다는 설명이다 [1:28:34]
• 메모리 공간 사이에서 이동하는 바이트 수를 분석적으로 계산해 실행 전에도 루프라인 성능 한계를 구할 수 있다. 이를 조기 가지치기에 활용하므로 전체 탐색 공간에 비해 적은 프로파일링으로 후보를 평가한다 [1:28:58]

48. 순전파 컴파일과 추론 엔진의 역할 분담

• 컴파일 대상은 사용자가 지정한 순전파 그래프이며, 최적화 범위도 순전파 내부다. 추측 디코딩은 vLLM과 SGLang이 제공하는 기능을 활용한다 [1:29:34]
• 주요 최적화 기회는 복잡한 병렬화 토폴로지와 순전파의 복잡성을 처리하는 데 있다는 판단이다. 그 밖의 추론 기법은 기존 엔진의 발전에 맡긴다 [1:30:00]

49. 에이전트의 공유 문맥에서 출발한 RadixAttention

• 2023년 말에는 도구 호출과 병렬 하위 에이전트가 미래의 주요 워크로드가 될 것으로 예상했다. 하위 에이전트들은 큰 문맥을 공유하고, 짧은 요청으로 추론 엔진에 반복 진입하는 형태를 가정했다 [1:31:23]
• 당시 엔진은 이런 공유 접두사를 효율적으로 재사용하기 어려웠다. RadixAttention은 공통 접두사의 계산 결과를 자동으로 재사용하고 새로운 접미사만 계산하도록 설계됐다 [1:32:19]

50. Radix 트리와 캐시를 고려한 요청 순서

• 에이전트 문맥을 Radix 트리로 관리하면 긴 시스템 프롬프트를 공유하면서 서로 다른 작업을 수행할 수 있다. 메모리가 부족할 때는 개별 에이전트의 접미사가 퇴거될 수 있으며, 스케줄링을 포함한 핵심 설계가 이 구조를 중심으로 구성된다 [1:32:42]
• 메모리가 필요하면 사용하지 않는 리프 노드를 퇴거한다. 스케줄링과 퇴거 정책은 워크로드에 맞게 조정할 수 있다 [1:34:13]

51. 범용 추론 엔진으로 확장하면서 드러난 CPU 병목

• 초기 논문의 핵심은 메모리 관리 시스템 내부에 Radix 트리를 도입하는 것이었다. 이후 2024년 중반 0.2 버전에서 온라인·오프라인 서빙을 지원하는 범용 언어모델 추론 엔진으로 확장됐다 [1:35:12]
• 배치 구성, 캐시 매칭, 퇴거, 대기 요청의 우선순위 결정에는 CPU 작업이 필요하다. GPU 추론이 빨라지는 동안 CPU 처리 효율은 같은 속도로 개선되지 않아 스케줄링 부담이 커졌다 [1:35:45]

52. 동기화 지연과 중첩 스케줄링으로 GPU 공백 축소

• 중첩 스케줄링은 디바이스에서 호스트로의 동기화를 다음 라운드로 미뤄 핵심 실행 경로의 블로킹을 줄인다. GPU가 현재 배치를 실행하는 동안 다음 배치를 미리 준비해 연속 실행을 가능하게 한다 [1:36:53]
• 기존 스케줄링 대비 처리량 개선은 Hopper에서 약 1.1~1.5배로 제시됐다. Blackwell의 GB 설정에서는 경우에 따라 약 2배에 이를 수 있다고 보여준다 [1:38:03]

53. 긴 대화 간격을 지원하는 계층형 캐시

• 긴 문맥을 사용하는 요청은 다음 대화까지 수분·수시간, 길게는 수일이 걸릴 수 있다. 제한된 GPU 메모리만으로는 이전 접두사를 계속 보관하기 어려워 다른 저장 계층이 필요하다 [1:38:26]
• 계층형 캐시는 Radix 트리를 GPU 메모리, 호스트 메모리, 스토리지에 연결하고 각각 L1·L2·L3로 관리한다. 계층별 배치와 전송 정책은 캐시 적중률과 로딩 시간에 영향을 준다 [1:38:58]

54. 하이브리드 모델마다 달라지는 캐시 적중 조건

• 긴 문맥의 효율적인 처리를 위해 슬라이딩 윈도와 고정 크기의 순환 상태를 사용하는 구조가 늘어난다. 구조별 메모리 풀을 추가하는 것만으로는 접두사 공유 문제를 해결하기 어렵다 [1:39:59]
• 위치 10에서 캐시를 재사용하려면 전체 어텐션의 KV가 일치해야 한다. 윈도 크기가 4라면 위치 7~10의 토큰이 필요하고, 순환 상태도 정확히 위치 10의 상태가 있어야 한다 [101:10] [1:41:02]

55. 통합 Radix 트리로 캐시 정책과 구성 요소 조율

• 하위 메모리 풀의 차이를 고려하지 않은 독립적인 Radix 트리는 호환성과 유연성 문제를 낳는다. 접두사 노드를 보호하려면 전체 어텐션·슬라이딩 윈도·순환 계층 사이의 추가 조율도 필요하다 [102:40] [1:43:10]
• 통합 Radix 트리는 전체 토큰의 의미적 ID를 기준으로 공통 구조를 만들고, 개별 구성 요소를 제어·조정한다. 모델 구조가 달라져도 전체 토큰은 존재한다는 점을 공통 기준으로 삼는다 [103:37] [1:43:48]

56. 문맥 길이에 따라 달라지는 메모리 수요와 동적 배분

• 사용자와 워크로드에 따라 문맥 길이는 4K에서 100만 토큰까지 크게 달라질 수 있지만, 슬라이딩 윈도는 마지막 128개 토큰만 유지할 수도 있다. 따라서 전체 토큰과 윈도·순환 상태에 필요한 메모리 비율은 고정되지 않는다 [105:14] [1:45:05]
• 통합 메모리 풀은 종류별 크기를 미리 고정하는 대신 하나의 물리 메모리 공간을 공유한다. 각 풀이 사용량에 따라 커지도록 해 다양한 문맥 길이를 같은 엔진에서 처리한다 [106:39] [1:45:43]

57. 메모리 압축과 페이지 재매핑으로 단편화 해소

• 많은 커널과 백엔드는 연속된 물리 메모리를 요구한다. 할당과 퇴거로 생긴 빈 공간은 서로 다른 풀의 경계에 걸리면 재사용하기 어려워진다 [107:59] [1:46:59]
• 컴팩션은 저지연 메모리 복사 커널로 조각난 데이터를 재배치해 밀집시킨다. 이후 가상 페이지 ID는 유지하고 하위 매핑만 바꿔 서빙 워크로드의 메모리 운용 유연성을 높인다 [108:40] [1:47:57]

58. 학습 루프와 오픈소스 인프라로의 확장

• Miles는 학습 루프 안에 추론을 통합하고, 완전 비동기 실행으로 생성과 학습이 계속 진행되도록 지원한다. 추론 엔진은 강화학습에 필요한 롤아웃의 백엔드 역할을 한다 [109:24] [1:48:54]
• 개발 범위는 RadixAttention에서 오픈소스 추론 엔진으로, 다시 Miles와 확산 모델 관련 작업으로 넓어졌다. 공통 방향은 오픈소스 AI 인프라의 성능과 기능을 확장하는 것이다 [109:56] [1:49:32]

🧾 결론

• 모델 평가는 학습 규모뿐 아니라 동일한 추론 연산 예산에서의 품질과 반복 사용 비용까지 포함해야 한다.
• 운영 목표는 최대 토큰 처리량만으로 정하기 어렵다. 첫 토큰 지연, 토큰당 생성 시간, 작업 완료 시간과 품질 기준을 충족하는 굿풋을 함께 봐야 한다.
• 양자화·컴파일·캐시 최적화의 성과는 실제 트래픽에서 검증해야 한다. 수치 연산 순서의 변화나 작은 공급자 편차도 긴 문맥과 연속 호출에서 작업 실패로 이어질 수 있다.
• 공개 가중치에 공식 양자화 모델, 실행 스택과 검증 도구가 더해질수록 공급자 간 일관성을 높일 여지가 커진다.

📈 투자·시사 포인트

• 서빙 효율은 사업의 핵심 변수다. 커널·컴파일러·캐시 개선으로 같은 GPU 시간에 더 많은 유효 토큰을 제공하면 수익성 개선 여지가 생긴다. 발표된 마진과 처리 규모는 비용 범위와 측정 시점을 확인해야 한다.
• GPU 연결과 메모리 운용을 함께 봐야 한다. 대규모 전문가 병렬화는 고속 통신으로 처리량을 높일 수 있지만, GPU 장애에 대한 복구와 회복력도 요구한다.
• 공급자 통합과 품질 감시는 사업 기회로 제시된다. 여러 클라우드와 로컬 모델을 선택하는 환경에서는 가격·속도에 더해 도구 호출 정확성과 긴 문맥 품질을 지속적으로 확인하는 기능이 중요해진다. 발표자는 관련 서비스의 기존 존재 여부를 확신하지 않았다.
• 이기종 하드웨어 지원은 연산 자원의 활용 범위를 넓힐 수 있다. Luminal의 접근을 평가할 때는 지원 하드웨어 수뿐 아니라 실제 고객 입력에서의 성능, 컴파일 탐색 비용, 품질 유지와 운영 수익성을 함께 확인해야 한다.

⚠️ 불확실하거나 확인이 필요한 부분

• ‘12배’는 과거 DeepSeek 사용량과 가중치 유효 수명 2년을 적용한 추정이다. 사용량 증가, 모델 교체 주기와 실제 운영 기간에 따라 비율이 달라진다.
• DeepSeek의 약 80% 마진, Together·Luminal의 처리 규모, 공개 모델의 가격 우위는 자료에서 인용하거나 발표자가 제시한 수치다. 최신성, 비용 포함 범위와 비교 조건이 충분히 확인되지는 않는다.
• MFU, 캐시 적중률, 중첩 스케줄링의 처리량 개선과 계층형 캐시의 지연 감소는 특정 조건의 결과다. 모델·하드웨어·문맥 길이·요청 간격이 다르면 재현되지 않을 수 있다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 예상 요청량과 모델 교체 주기를 기준으로 누적 추론 연산량을 계산하고, ‘12배’가 자신의 서비스에도 성립하는지 확인한다.
• 실제 워크로드에서 프리필·디코드 처리량, 첫 토큰 지연, 출력 토큰당 시간, 캐시 적중률과 SLA를 충족하는 굿풋을 함께 측정한다.
• 공유 접두사 비율과 요청 간격을 확인하고, 캐시 위치를 고려한 라우팅·계층형 보관·퇴거 정책의 비용과 지연 효과를 비교한다.
• 양자화나 공급자 변경 전후에 도구 호출, 긴 문맥, 다단계 에이전트 작업을 포함한 비공개 회귀 평가를 수행한다.

❓ 열린 질문

• 최신 사용량과 실제 가중치 수명을 적용하면 모델별 추론 대 학습 연산량 비율은 얼마나 달라지는가?
• 캐시 보관과 데이터 이동 비용까지 포함할 때, 워크로드별로 가장 경제적인 캐시 적중률과 보존 기간은 무엇인가?
• 저비용 품질 감시는 긴 문맥과 연속 도구 호출의 실패를 얼마나 일찍 발견하며, 무거운 전체 평가를 어느 정도 보완할 수 있는가?