🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Stanford CS336 Language Modeling from Scratch의 Dan Fu 강의는 언어모델의 다음 병목이 모델 학습 자체보다 추론 엔진, GPU 커널, KV 캐시, 프리필·디코드 분리, 반복 구조 설계에 있다는 점을 보여준다.

📌 핵심 요점

1. 언어모델 학습이 끝난 뒤의 핵심 과제는 사용자 요청을 실제 서비스 환경에서 안정적으로 토큰 출력으로 바꾸는 추론 시스템을 설계하는 것이다.
2. 추론은 전기와 GPU 계산을 토큰과 지능형 응답으로 바꾸는 실행 계층이며, GPU 투자와 인퍼런스 엔진의 발전이 모델 능력 확장과 직접 연결된다.
3. 실제 서비스 워크로드는 단순한 평균 요청이 아니라 입력 길이, 출력 길이, 세션 지속 시간, 캐시 재사용 가능성, 반복 호출 패턴에 따라 병목이 크게 달라진다.
4. 프리필은 compute-bound, 디코드는 memory bandwidth-bound 성격이 강하므로, 두 단계를 분리하고 KV 캐시를 효율적으로 관리하는 것이 지연시간과 처리량 개선의 핵심이다.
5. 메가 커널, Thunderkittens, Parse 같은 접근은 하드웨어 수준 최적화와 모델 아키텍처 설계를 함께 다룰 때 언어모델 품질과 서빙 효율을 동시에 개선할 수 있음을 시사한다.

🧩 배경과 문제 정의

• 언어모델 학습 이후의 핵심 과제는 모델을 실제 서비스 환경에서 어떻게 추론으로 실행하고, 사용자 요청을 안정적인 토큰 출력으로 연결하느냐에 있다.
• 모델 능력의 확장은 스케일, GPU 투자, 추론 엔진의 발전과 맞물려 있으며, 연구 성능을 넘어 산업 구조의 변화로 이어지고 있다.
• 추론은 전기를 토큰과 지능으로 바꾸는 실행 계층으로, GPU 커널과 인퍼런스 엔진을 이해해야 모델 알고리즘과 시스템을 함께 개선할 수 있다.
• 실제 서비스 트래픽은 학습 데이터나 단순한 가정과 달리 입력·출력 길이, 워크로드 유형, 에이전트식 반복 호출에 따라 크게 달라진다.
• 강의는 추론 시스템의 병목, KV 캐시, 프리필·디코드 분리, 대규모 GPU 서빙, 메가 커널, 반복 트랜스포머와 스케일링 법칙을 연결해 설명한다.

🕒 시간순 섹션별 상세정리

1. 학습 이후의 문제: 모델을 실제로 서비스하는 추론

• 수업의 중심은 언어모델 학습이지만, 학습이 끝난 뒤에는 모델이 사용자 요청에 응답하도록 실제 서비스 환경에서 운영하는 문제가 남는다 [00:16]
• 추론은 전기와 GPU 연산을 토큰 출력과 지능형 응답으로 바꾸는 과정이며, 모델의 능력을 현실 시스템에서 사용 가능하게 만드는 핵심 연결고리다 [00:31]

2. 모델 능력 확장과 스케일의 역할

• 언어모델은 텍스트·코드 생성, 이미지·비디오 이해, 과학·바이오·헬스 응용으로 확장되며 새로운 산업혁명에 가까운 변화를 만들고 있다 [00:55]
• 이런 능력 향상의 주요 동력은 스케일이며, 2018년 최대급 모델이 약 1억 파라미터 수준이었던 데 비해 이후 모델 규모는 급격히 커졌다 [01:54]

3. 말에서 자동차로 바뀐 속도와 언어모델 전환의 비유

• 언어모델로의 전환은 예상보다 빠르게 진행되고 있으며, 몇 년 전 박사과정 초기에 상상했던 변화 속도보다 훨씬 앞당겨졌다 [02:49]
• 1902년 맨해튼에는 일하는 말이 13만 마리 있었고, 이들이 만들어내는 대량의 분뇨는 도시 운영의 현실적 문제였다 [03:08]

4. GPU 투자와 추론 엔진의 핵심성

• 모델 스케일의 상당 부분은 GPU가 뒷받침하며, GPU는 새로운 석유에 비유될 만큼 핵심 자원으로 취급된다 [04:31]
• GPU에는 수천억 달러 규모의 투자가 집중되고, 국가와 국부펀드까지 GPU 확보를 전략적 자산으로 보고 있다 [04:43]

5. 토큰 생애와 추론 시스템의 주요 구성요소

• 요청 하나가 들어오면 토큰은 인퍼런스 서비스 전체를 통과하며, 시스템은 어느 GPU에 배치하고 어떤 단계에서 계산할지 결정해야 한다 [07:34]
• 요청은 여러 GPU에 스케줄링될 수 있고, 프리필과 디코드를 서로 다른 머신에 나누는 구성도 가능해 시스템 설계에 따라 지연시간과 처리량이 달라진다 [08:21]

6. 실제 서비스 워크로드와 에이전트식 호출 패턴

• 프로덕션 트래픽은 학습 중의 토큰 분포나 단순 가정과 다르기 때문에, 실제 워크로드별 입력·출력 토큰 분포를 따로 봐야 한다 [09:38]
• 코딩 워크로드에서는 전체 코드베이스가 컨텍스트로 들어가 수만 개의 입력 토큰이 생기고, 모델 학습 방식에 따라 thinking 토큰이나 짧은 출력이 계속된다 [10:15]

7. 애플리케이션별 cadence가 workload와 latency 목표를 바꾼다

• 빠른 interactive chat이나 음성 모드에서는 짧은 응답 지연이 중요하지만, agentic workflow에서는 agent가 독립적으로 반복 작업을 수행하는 더 느린 cadence가 나타난다 [12:04]
• agent가 중간에 막혀 도움을 요청해도 사용자가 즉시 보지 못하면 턴 사이의 gap이 생기며, 이 간격까지 workload 정의에 포함된다 [12:24]

8. 요청 처리 경로는 프리필과 디코드로 갈라진다

• 요청이 들어오면 먼저 텍스트를 토큰화하고, 이미 본 토큰인지 확인해 cache의 activation을 재사용할 수 있는지 판단하는 scheduling 단계가 필요하다 [13:45]
• 프리필은 처음 보는 10,000개 토큰을 처리해 다음 1개 토큰을 만들기 위한 계산이며, training loop와 비슷하게 compute-bound 성격이 강하지만 backward pass는 없다 [14:24]

9. Continuous batching은 여러 요청의 compute와 memory를 동시에 관리한다

• inference engine은 request를 기다리며 scheduling, execution, token sampling loop를 반복하고, 여러 요청을 동시에 처리하는 과정에서 continuous batching이 중요해진다 [16:04]
• 긴 문서를 분석하는 long request가 여러 token을 생성하는 동안 다른 request가 들어오면, compute resource와 KV cache memory를 함께 점유하게 된다 [16:45]

10. KV 캐시는 prefix sharing으로 반복 계산을 줄인다

• 많은 사용자가 “hi ChatGPT”나 “hi Claude”처럼 같은 prefix를 입력하면, 매번 새 activation을 계산해야 할 필요가 줄어든다 [18:02]
• 사용자가 긴 책을 prompt로 넣은 뒤 다음 turn에서 addendum을 추가하면, 처음 책 전체에 대한 프리필 결과를 다시 계산하지 않고 이전 계산을 재사용할 수 있다 [18:26]

11. 모델 병렬화와 프리필·디코드 분리는 병목을 다르게 만든다

• trillion-parameter model은 80GB급 GPU 한 장에 전체 모델을 올릴 수 없기 때문에, tensor parallelism처럼 tensor를 여러 GPU로 나누는 분할 방식이 필요하다 [19:09]
• Mixture-of-Experts model에서는 token별로 선택적으로 활성화되는 expert를 서로 다른 GPU에 나눌 수 있으며, 이 선택이 필요한 GPU 수와 동시에 처리 가능한 session 수를 좌우한다 [19:30]

12. 대규모 inference에서는 희귀 오류가 반복 출력과 tool call 장애로 커진다

• 하루 trillions of tokens 이상을 serving하는 규모에서는 작은 scale에서 안정적으로 보이던 시스템도 0.001% 이하 확률의 희귀 event 때문에 깨질 수 있다 [21:52]
• 아주 드문 조건에서 kernel 오류가 발생하면 logits가 중간에 NaN으로 바뀌고, 모델 출력이 “hi”나 느낌표 같은 동일 token 반복 loop에 빠질 수 있다 [22:35]

13. 커널 오류가 만든 중국어 출력과 추론 장애

• 일부 모델은 영어 질문에도 갑자기 중국어 문자를 출력했고, 여러 inference provider가 동시에 영향을 받으면서 초기에는 양자화 문제로 의심됐다 [24:11]
• 실제 원인은 커널의 off-by-one 오류였으며, GPU의 초기화되지 않은 메모리 일부가 attention을 거쳐 무작위 중국어 문자로 출력될 수 있었다 [24:48]

14. KV cache 확장과 CPU·SSD 병목

• 대규모 production inference에서는 여러 사용자와 세션의 요청을 최대한 재사용하기 위해 큰 KV cache가 필요하지만, 이를 GPU에만 저장하기에는 메모리 한계가 빠르게 온다 [25:37]
• KV cache가 CPU DRAM으로 내려가면 CPU 성능이 병목이 되고, 고가의 GPU 시스템이 상대적으로 저렴한 CPU 때문에 제 성능을 내지 못하는 비효율이 생긴다 [26:10]

15. 캐시 오프로딩은 운영체제식 스케줄링 문제로 계속된다

• CPU·SSD 오프로딩은 특정 연산을 따로 보내는 문제가 아니라, 메모리가 부족할 때 애플리케이션을 디스크로 밀어내던 고전 운영체제 스케줄링 문제와 같은 구조를 가진다 [27:51]
• least recently used 방식은 최근 쓰지 않은 항목을 먼저 내보내는 휴리스틱이고, 이상적인 방식은 미래 요청을 예측해 필요한 메모리를 미리 GPU로 가져오는 것이다 [28:36]

16. 초대형 GPU 묶음과 장문 컨텍스트가 만드는 장애 허용 문제

• Nvidia의 Grace Blackwell NVL72 같은 구성은 72개 GPU를 빠른 인터커넥트로 묶으며, 조 단위 파라미터 모델을 여러 GPU에 어떻게 나누고 어떤 이득을 얻을지가 핵심 문제가 된다 [29:56]
• 대규모 GPU 시스템은 커넥터와 NVLink 불안정성 같은 물리적 요인으로도 장애가 잦아질 수 있고, 플라스틱 커넥터의 변형처럼 작은 하드웨어 문제가 flaky link로 이어질 수 있다 [30:27]

17. cache-aware prefill/decode 분리로 얻는 serving 개선

• cache-aware prefill decode disaggregation은 routing layer의 단순한 최적화만으로도 큰 성능 차이를 만들 수 있으며, 요청의 cache hit rate에 따라 GPU 집합을 나누는 방식이다 [31:29]
• 평균 대화가 10턴 지속된다면 약 10%의 요청은 완전히 새로운 요청이고, 이런 신규 요청은 수천 토큰 prefill이 필요해 기존 대화 중간의 짧은 요청과 성격이 크게 다르다 [32:11]

18. decode 병목과 커널 단위 실행의 유휴 시간

• inference kernel의 흐름을 짚은 뒤 논의는 language model decode와 mega kernel로 넘어가며, Stanford와 Together의 협업 맥락에서 decode 속도 개선 문제가 계속된다 [34:03]
• decode는 prompt 처리가 끝난 뒤 토큰을 한 개씩 생성하는 단계이며, 단일 토큰 생성을 위해 전체 모델을 실행해야 하므로 training이나 prefill에서 활용하던 GPU 병렬성이 크게 줄어든다 [34:32]

19. GPU 추론 커널의 빈 시간과 tail effect

• GPU 타임라인에서 x축은 시간, y축은 H100 기준 132개 수준의 streaming multiprocessor이고, 막대는 실제 유용한 작업, 빈 공간은 다른 연산이 끝나기를 기다리는 대기 시간이다 [36:00]
• 커널을 잘 작성해도 kernel launch와 teardown 사이의 큰 공백, 짧은 프롬프트가 긴 프롬프트와 함께 처리될 때 생기는 tail effect 때문에 GPU downtime이 남는다 [36:45]

20. 메가 커널은 여러 연산을 하나의 GPU 스케줄링 문제로 묶는다

• 메가 커널은 모델의 각 연산을 개별 커널로 나누지 않고 여러 연산을 하나의 커널이 덮도록 만들며, flash attention의 fusion보다 더 넓은 범위에서 공격적으로 결합한다 [37:32]
• GPU는 단일 연산 장치가 아니라 거대한 분산 시스템처럼 다뤄지며, 의존성이 있는 작업들을 어떻게 배치해 GPU utilization을 최대화할지가 핵심 문제가 된다 [37:56]

21. 세밀한 GPU 제어로 attention 내부 작업을 겹친다

• modern LM의 attention layer에서는 QKV projection과 RoPE scaling이 먼저 일어나고, decode 중에는 QKV plus RoPE가 아직 실행 중인 동안 KV cache load를 attention 쪽에서 미리 시작할 수 있다 [39:02]
• QKV가 끝나면 새 query token을 사용할 수 있어 attention의 나머지 연산이 이어지고, 세밀한 GPU 제어가 있으면 한 연산이 완전히 끝나기 전에 다른 연산을 시작하는 구조가 가능해진다 [39:34]

22. Thunderkittens와 near speed-of-light decoding

• Thunderkittens는 Triton과 비슷한 kernel writing library지만 더 low-level이며, GPU 작업을 훨씬 더 fine-grained하게 제어할 수 있는 방향을 갖는다 [40:40]
• 메가 커널은 decoding inference에서 다른 state-of-the-art engine보다 빠르게 동작하고, H100에서 72% bandwidth utilization을 달성해 물리적 한계에 가까운 처리량에 접근한다 [40:56]

23. PERS는 파라미터 증가 대신 반복 사용으로 품질을 노린다

• PERS는 모델의 capabilities가 parameters와 data scaling에서만 나오는지, 아니면 다른 scaling 방식으로도 비슷한 quality를 얻을 수 있는지 묻는 문제에서 출발한다 [41:50]
• loop transformer 방식에서는 transformer block 일부를 loop로 만들고, token activation이 모델을 한 층씩만 통과하는 대신 특정 recurrent block을 여러 번 반복 통과한다 [42:12]

24. 반복 모델의 불안정성과 residual dynamics 분석

• 초기 연구에서는 ARC task 결과를 근거로 looped model이 transformer보다 나을 가능성이 나왔고, Claude Mythos가 recurrent 또는 looped language model이라는 잘못된 온라인 speculation도 관심을 키웠다 [44:44]
• looped model은 learning rate를 조금만 바꿔도 10번 중 9번 수준으로 converge하지 못하고, NaN과 큰 loss spike가 발생해 training process 자체에 구조적 문제가 있음을 드러낸다 [45:38]

25. 반복 트랜스포머를 A/B 행렬 중심으로 단순화

• attention, gate, 큰 feed-forward network와 activation intermediate 같은 비선형 요소는 하나의 복잡한 항 r로 묶이고, 반복 구조의 핵심은 A와 B 행렬로 남는다 [48:17]
• B 행렬은 루프 시작 전 초기 벡터를 변환하고, A 행렬은 각 반복 단계에서 residual을 어떻게 바꿀지 결정한다 [48:32]

26. spectral radius가 반복 루프의 폭주를 만든다

• 닫힌 해는 A 행렬의 거듭제곱 항에 크게 좌우되며, 반복 횟수가 늘수록 A가 학습한 크기와 방향성이 activation 전체를 지배한다 [50:00]
• spectral radius는 norm과 비슷한 역할을 하며, 행렬이 스칼라 2처럼 행동하고 16번 거듭제곱되면 activation이 2^16 규모로 커진다 [50:39]

27. Parse의 제약은 activation 폭주와 loss spike를 줄인다

• A와 B가 자유롭게 학습되면 수학적으로 폭주하는 항이 생기므로, Parse는 반복 실행해도 폭발하지 않도록 두 행렬을 제약한다 [51:10]
• A 행렬은 사실상 negative diagonal matrix가 되어 거듭제곱할수록 항이 0으로 수렴하고, B 행렬은 한 번만 적용되므로 단순한 linear norm 제약을 받는다 [51:29]

28. 안정화된 반복 구조는 품질도 개선한다

• Parse는 안정성만 높이는 구조가 아니라 recurrent depth model 같은 이전 loop transformer보다 높은 품질을 낸다 [53:26]
• 여러 application에서 Parse는 기존 loop model을 앞서고, 강한 transformer baseline보다도 더 나은 성능을 보인다 [53:41]

29. 스케일링 법칙의 질문은 데이터·파라미터에서 recurrence까지 확장된다

• 기본 scaling law 질문은 모델을 키울지, 데이터를 더 쓸지, 두 요소를 어떤 비율로 함께 늘릴지에 관한 문제에서 출발한다 [54:35]
• 곡선이 아래와 오른쪽으로 이동하면 데이터와 파라미터를 동시에 늘려야 하고, 수직 또는 수평 이동만 있다면 한쪽만 늘리는 전략이 유리하다 [55:04]

30. 고정 파라미터에서도 데이터와 recurrence를 함께 늘리는 쪽이 유리하다

• 고정 파라미터 조건에서도 곡선은 다시 아래·오른쪽으로 이동하며, 데이터가 늘어날수록 recurrence 수를 함께 늘리는 편이 유리하다는 신호가 나타난다 [56:40]
• recurrence는 고전적인 power law를 따르며, recurrence 수와 token 수를 함께 스케일할 때 품질을 예측할 수 있는 형태가 만들어진다 [57:00]

31. 루프 구조의 연구 문제와 사전학습 모델 적용 가능성

• 새로운 커널과 아키텍처 연구는 시스템의 특정 병목을 더 빠르게 만들거나 GPU 간 통신량을 줄이는 방향으로 압축된다 [1:00:00]
• 핵심 질문은 루프 구조를 사전학습 모델에도 적용할 수 있는지이며, 처음부터 학습하지 않고 일부 레이어를 반복해 품질을 높인 사례가 있다 [1:00:57]

32. 작은 루프 모델이 추론 메모리와 통신 비용을 바꾸는 방식

• 루프 모델에 대한 관심은 추론 서빙에서 GPU 메모리가 큰 병목이라는 문제의식에서 나온다 [1:02:09]
• 파라미터가 적으면 더 많은 KV cache를 담거나 더 적은 GPU로 모델을 나눌 수 있어, 통신 비용과 배치 운용 제약이 줄어든다 [1:02:17]

33. 메가 커널의 속도 이점과 구현 비용

• 메가 커널의 가장 큰 비용은 실행 시간이 아니라 사람의 시간과 노력이며, 속도 이점과 별개로 구현 난도가 매우 높다 [1:03:37]
• 숙련된 커널 엔지니어 한 명이 1년 동안 한 하드웨어에서 2~3개 모델과 배치 크기 1~16 정도만 겨우 커버할 수 있고, 배치 크기가 17로 바뀌면 다시 작업이 필요해진다 [1:03:51]

34. 서빙 하드웨어가 모델 크기와 양자화 형식을 결정하는 방식

• 특정 하드웨어에서 서빙할 계획이라면 먼저 메모리 용량을 기준으로 모델 크기와 KV cache 여유분을 맞춰야 한다 [1:05:06]
• Cerebras wafer 같은 플랫폼에서는 사용 가능한 메모리가 첫 번째 제약이 되며, 모델이 그 안에 들어가도록 아키텍처를 조정해야 한다 [1:05:17]

35. 루프 반복, 파라미터 증가, FLOP 예산의 선택 기준

• compute optimal 논의는 대체로 고정된 FLOP 예산 안에서 어떤 모델 크기와 학습 방식을 선택할지의 문제로 좁혀진다 [1:06:29]
• 더 높은 품질이 목표라면 FLOP 예산을 늘리거나, 모델 크기를 정한 뒤 더 오래 학습하는 선택이 가장 직접적인 해법이 된다 [1:06:50]

36. 사용 사례별 아키텍처와 다중 GPU 메가 커널의 부분 적용

• agentic loop workflow에서는 같은 문맥을 반복적으로 활용하므로 KV cache를 최대한 뜨겁게 유지하는 것이 중요하지만, 단발성 batch processing에서는 그 중요도가 상대적으로 낮다 [1:08:25]
• DeepSeek MLA attention과 FP8·FP4 KV cache 처리는 KV cache 크기를 크게 줄이는 선택지이며, 특히 agentic workflow에 민감한 시스템에서 차이를 만든다 [1:08:47]

🧾 결론

• 이 강의의 중심 메시지는 언어모델 성능 경쟁이 더 이상 파라미터 수나 학습 데이터만의 문제가 아니라, 추론 시스템 전체 스택의 문제로 확장됐다는 것이다.
• 대규모 서비스에서는 아주 낮은 확률의 커널 오류, 캐시 미스, tool call 처리 실패도 반복 출력이나 언어 혼선처럼 사용자에게 보이는 장애로 커질 수 있다.
• KV 캐시는 긴 컨텍스트와 반복 요청을 다루는 핵심 자산이며, GPU 메모리 한계를 넘어서면 CPU DRAM, SSD, 글로벌 스토어까지 포함한 운영체제식 스케줄링 문제가 된다.
• 프리필·디코드 분리, cache-aware routing, continuous batching은 단순한 구현 세부사항이 아니라 실제 서비스 비용과 응답 품질을 좌우하는 구조적 설계 요소다.
• Parse와 반복 트랜스포머 논의는 파라미터를 계속 늘리는 방식 외에도 같은 파라미터를 반복 사용해 품질을 끌어올리는 새로운 스케일링 축이 가능함을 보여준다.

📈 투자·시사 포인트

• GPU는 단순한 연산 장비가 아니라 추론 경제의 핵심 인프라로 다뤄지며, GPU 확보 경쟁은 모델 학습뿐 아니라 대규모 inference serving 수요와도 연결된다.
• 메모리 대역폭, KV 캐시 용량, CPU·SSD 오프로딩 성능은 대형 모델 서비스의 비용 구조를 바꾸는 병목이므로, 추론 최적화 인프라와 메모리 계층 기술의 중요성이 커진다.
• 프리필과 디코드의 병목이 다르기 때문에, 향후 서빙 하드웨어는 범용 GPU만이 아니라 decode 친화 칩, 고속 메모리 구조, 저지연 인터커넥트 중심으로 더 세분화될 수 있다.
• 메가 커널은 높은 성능을 낼 수 있지만 구현 비용이 매우 크므로, 자동화된 커널 생성·컴파일러·하드웨어 특화 런타임의 가치가 커질 가능성이 있다.
• 검증 필요: 강의에서는 프런티어 모델 규모가 5조~10조 파라미터 수준으로 추정된다고 언급되지만, 이는 공개적으로 확정된 수치가 아니라 추정치로 분리해 봐야 한다.

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

• 프런티어 모델이 5조~10조 파라미터 수준으로 추정된다는 언급은 강연 내 추정에 가깝기 때문에, 공개 자료나 신뢰 가능한 외부 분석으로 별도 확인이 필요하다.
• 오픈소스 모델이 1조 파라미터 이상에 이르렀다는 설명은 모델 범위와 “오픈소스”의 정의에 따라 달라질 수 있어, 구체적인 모델명과 공개 조건을 확인해야 한다.
• GPU에 수천억 달러 규모의 투자가 몰리고 국가·국부펀드가 전략 자산으로 본다는 주장은 방향성은 강연에 포함되지만, 정확한 규모와 시점은 외부 데이터 검증이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 실제 서비스의 요청 로그를 workload별로 나누어 입력 토큰 길이, 출력 토큰 길이, 세션 길이, turn 간 간격을 측정한다.
• interactive chat, coding agent, long-document 요약, batch processing처럼 사용 사례별 latency 목표와 병목을 따로 정의한다.
• 프리필과 디코드의 GPU 사용률, memory bandwidth, KV cache 점유량을 분리해서 관측할 수 있는 메트릭을 마련한다.
• KV cache hit rate를 기준으로 cold request와 warm request를 구분하고, cache-aware routing을 적용할 수 있는지 검토한다.

❓ 열린 질문

• 실제 production traffic에서 prefill과 decode를 분리하는 최적의 기준은 cache hit rate, prompt length, user cadence 중 무엇을 가장 크게 반영해야 하는가?
• KV cache를 GPU, CPU DRAM, SSD, 글로벌 스토어 사이에서 이동할 때 SLA를 깨지 않으면서 어떤 eviction·prefetch 정책을 쓸 수 있는가?
• agentic workflow가 늘어날수록 inference engine은 단일 요청 최적화보다 세션 전체 최적화를 우선해야 하는가?