추론의 시대, 핵심이 된 메모리 #2 : Agentic AI의 시대, NAND가 중요한 이유 'DualPath'

[원문 유형] 네이버 프리미엄 콘텐츠
[채널] 올바른 미국주식 by SAPIENS
[게시일] 2026.06.19. 오후 2:56
[원문 URL] https://contents.premium.naver.com/sapiens/sapiensasset/contents/260619145639559nl
[제목] 추론의 시대, 핵심이 된 메모리 #2 : Agentic AI의 시대, NAND가 중요한 이유 'DualPath'
[수집 기준] 승인된 구독 열람권으로 실제 본문을 보존했다. 이미지·첨부는 별도 미디어 원장에 보관하며 시각적 의미 검토 여부를 구분한다.

[구독 원문 본문]

안녕하세요 올바른입니다.

AI 심화편 of 심화편 세 번째 자료입니다. Agentic AI 워크로드 비중이 본격 늘어나기에 앞서서, 엔비디아가 새롭게 Context Memory Storage를 구상한 이유의 힌트를 얻을 수 있습니다.

대규모 온라인 서빙 시 Throughput을 높이는 건 엔지니어링 디테일이 아니라 자본 효율의 문제입니다. GPU 가동률을 40%에서 80%로 높인 DualPath에 대해 살펴봅니다.

2026년 1월 21일에 전해드린 <추론의 시대, 핵심이 된 메모리 : 메모리 쇼티지를 떠받치고 있는 힘>에 이은 두 번째 메모리 관련 심화편 자료입니다.

큰 흐름 읽기 (Bird's-eye view)

2026-06-12

AI 사이클의 모든 것, 게빈 베이커 인터뷰 : 버블의 역사는 반복되지 않지만, 운율은 반복된다 (바로가기)

2026-04-22

엔비디아 CEO 젠슨황 인터뷰 : 'TPU도 Trainium도, 그렇게 자신 있으면 공개적으로 붙자' (바로가기)

2026-03-27

앤스로픽 CEO 다리오 아모데이 인터뷰 : "Extremely fast, but not infinitely fast" (바로가기)

2026-03-05

AI 사이클 한 눈에 보기, SemiAnalysis 인터뷰 : "거품은 없다. ARR $100B가 온다" (바로가기)

2025-10-08

오픈AI 퇴사자의 글 #1 : 2027년 AGI가 온다 (바로가기)

AI 심화편 of 심화편

2026-06-05

AI 가속기 심화편 : GPU vs TPU, 무엇이 칩을 다르게 만드나 (feat.

CPU, ASIC, FPGA) (바로가기)

2026-05-27

LLM 추론 토큰 가격의 비밀 : MoE의 시대, 엔비디아 NVL72가 중요한 이유 (바로가기)

IPO 분석

2026-06-17

스페이스X IPO 분석 #2 : 화성으로 가는 길에서, 지구를 손에 넣다 (바로가기)

2026-05-29

스페이스X IPO 분석 : 머스크 제국의 심장, 스타링크가 떠받치는 스타십과 AGI (바로가기)

2026-05-14

세레브라스 IPO 분석 : 엔비디아 킬러인가? (바로가기) / 요약 (바로가기)

엔비디아 (NVDA)

2026-06-03

엔비디아 컴퓨텍스 2026 : 사람 위한 CPU 시대 넘어, GPU 굶기지 않는 CPU 'Vera' (바로가기)

2026-05-21

엔비디아 1Q26 실적발표 : 젠슨황, "하이퍼스케일러 CapEx보다 '더' 빠르게 성장" (바로가기)

2026-03-17

엔비디아 GTC 2026 : 7개의 칩, 5개의 랙 시스템, 그리고 하나의 AI 슈퍼컴퓨터 (바로가기)

2026-01-02

엔비디아가 $20B를 주고 데려온 남자 : Groq 창업자 조나단 로스의 통찰 (바로가기)

광학 (Optics)

2026-05-07

루멘텀 1Q26 실적발표 : 3Q OCS, 4Q CPO, 차례로 점화를 기다리는 고성능 엔진들 (바로가기)

2026-04-30

비아비 솔루션스 1Q26 실적발표 : 본격 개화하는 빛의 시대, 물만난 테스트 수요 (바로가기)

2026-04-17

'빛💡'의 시대 : 광학 밸류체인 한 눈에 보기 (바로가기)

2026-03-20

OFC 2026 : 광학이 중요해지고 있는 이유들, 태풍의 눈에 있는 두 가지 기업 분석 (바로가기)

메모리 (Memory)

2026-03-19

마이크론 1Q26 실적발표 : 흔들릴 이유가 없는 어닝서프라이즈, 구조적 성장주로 거듭나기 (바로가기)

2026-01-21

추론의 시대, 핵심이 된 메모리 : 메모리 쇼티지를 떠받치고 있는 힘 (바로가기)

2026-01-07

엔비디아 CES 2026 : Vera Rubin의 시대, ICMS가 불러올 메모리 지각변동 (바로가기)

네오클라우드 (Neocloud)

2026-05-08

코어위브 1Q26 실적발표 : 적자만 보면 놓치는 코어위브의 진짜 변화 (바로가기)

2026-02-22

네오클라우드 뜯어보기 #2 : 새로운 시대의 AI 계급도, 전력을 돈으로 바꾼 Powered Shell (바로가기)

2026-02-10

네오클라우드 뜯어보기 : GPU 임대의 경제학, 네오클라우드 BIG 4 비교분석 (바로가기)

투자자문 서비스에 따른 투자 시 원금 손실이 발생할 수 있으며, 투자 손익에 대한 책임은 전적으로 고객에게 귀속됩니다. 또한 과거의 투자수익이 미래의 수익률을 보장하지 않습니다.

신규 구독 전에, 아래 투자자문계약 권유문서의 계약 관련 제반 사항을 반드시 읽으시고 충분히 검토하시기 바랍니다.

*투자자문계약 권유문서 : https://naver.me/5ZST47Qf

목차

GPU가 놀고 있다? : 문제와 배경 이해하기

에이전트의 병목 : 병목의 정체, 하드웨어는 반대로 진화했다, 스토리지 대역폭

DualPath의 핵심 아이디어 : Decode Engine으로 차선 뚫기, 난관 → 이를 해결하기 위한 방법

연구 결과와 함의점 : 검증 ⓐⓑⓒ, InfiniBand, Agent와 함께 올 SSD 수요

GPU가 놀고 있다?

문제와 배경 이해하기

Agentic AI 시대에 앞서 해결할 것들

딥시크가 베이징대와 칭화대 컴퓨터 공학과와 함께 연구하여, 2026년 2월 26일 DualPath를 발표했습니다. 전체는 <DualPath: Breaking the Storage Bandwidth Bottleneck in Agentic LLM Inference>입니다.

올해 초부터 계속해서 MoE 모델을 가지고 Agentic AI 워크로드를 추론할 때 어떻게 하면 KV Cache 처리를 더 잘 할 수 있을 것인가에 대해서 연구하는 자료가 많습니다. 엔비디아 CES 2026에서 처음 공개된 Context Memory Storage(2026. 01. 06), DeepSeek의 Engram(2026. 01. 12), 엔비디아 KVTC(2026. 02. 06), DeepSeek의 DualPath(2026. 02. 26), 애플의 AFM 3에서 NAND를 활용한 MoE 추론구조(2026. 06.

08)도 같은 맥락입니다. Agentic AI로 가면서 Reasoning보다 훨씬 더 컨텍스트 윈도우를 키워야 하기에 더 많은 메모리 용량을 필요로 하다보니 NAND를 어떻게 하면 더 잘 활용할 수 있을 것인가에 대해서 고민하고 있음을 전해드렸었습니다.

Agent LLM 추론의 성능을 좌우하는 것 : FLOPS → KV Cache I/O

기본적인 LLM 호출은 매번 독립적입니다. 이전에 뭐라고 말했는지에 대한 대화 히스토리를 모릅니다. 사실 이건 생각해보면 지능이 아무리 높아서 맥락을 모르면 일을 할 수 있는 수준이 될 수가 없습니다. 아무리 똑똑해도 1일차 신입사원은 한계가 있는 것과 비슷하고, 마치 단기 기억상실증이 있는 메멘토 상황 같습니다.

하지만 Multi-turn은 대화 히스토리를 직접 관리함으로써 LLM이 이전 맥락을 참조하도록 합니다. 에이전트는 거기서 한 단계 더 나아간 방식입니다. 대표적인 동작 패턴 중 하나가 ReAct(Reasoning + Acting)입니다.

*더 깊게 보시려면, <ReAct: Synergizing Reasoning and Acting in Language Models (2022.

10. 06)>

예를 들어, 아주 간단하게 보면 이렇습니다:

사용자의 질문 → "1+3이 얼마야?"

Thought : 덧셈이 필요하다. add_sum 도구를 써야겠다.

Action : add_sum(a=1, b=3) 호출

Observation : 결과 = 4

답변 : 1+3 = 4입니다.

생각 → 행동 → 관찰 → 다시 생각을 반복합니다.

<LLM 추론 토큰 가격의 비밀>에서 컨텍스트 윈도우가 길어질수록 한 사용자의 KV Cache가 커진다는 것을 전해드렸었습니다. 이 모든 작업들이 결과적으로는 단순 LLM 호출 → Reasoning → Agentic AI로 가면 갈수록 한 사용자의 요청당 KV Cache를 훨씬 더 키우는 쪽으로 작용합니다.

그 결과, multi-turn 방식의 에이전트 기반 LLM 추론 성능은 FLOPS(연산)보다는 KV Cache Storage I/O에 의해 좌우됩니다. 그런데 지금 널리 쓰이는 분산형 추론 아키텍처(Prefill 엔진과 Decode 엔진 분리)상 외부 스토리지로부터 대용량 KV Cache를 로드하는 과정이 근본적인 불균형을 초래합니다.

Prefill Engine("PE")의 스토리지 NIC는 대역폭이 금방 차버리는데, Decode Engine("DE")의 스토리지 NIC는 유휴 상태가 됩니다. 이러한 비대칭성으로 인해 시스템의 전체 throughput(기준마다 다르지만, 많이 쓰는 건 단위시간당 토큰 생성량)이 심각하게 저해된다는 것이 문제입니다.

*더 깊게 보시려면 #2, <Splitwise: Efficient generative LLM inference using phase splitting(2023. 11. 30)>

Splitwise는 중요하지만, 3월 6일 일간보고에서만 짧게 전해드렸던 내용이라 다시 핵심만 정리해보면:

입력된 프롬프트 전체를 계산하여 첫 토큰을 만드는 Prefill은 컴퓨팅/FLOPS가 가장 중요하므로 H100과 같은 고성능 GPU에 할당합니다. 반면, 이후 토큰을 하나씩 생성하는 Decode 단계는 연산량보다 메모리 대역폭이 중요하므로 A100이나 그보다 낮은 전력의 이전 세대 GPU에 할당하여 처리합니다. 이렇게 LLM 추론 요청의 Prefill, Decode를 서로 다른 머신으로 분리하여서 Prefill은 H100으로 추론하고(PE, Prefill Engine), Decode는 A100으로 추론할 경우(DE, Decode Engine), 기존 설계 대비 1.4배 높은 Throughput을 20% 낮은 비용을 달성할 수 있고, 동일한 비용 및 전력으로 2.35배 높은 Throughput을 낼 수 있다는 논문이었습니다.

*더 깊게 보시려면 #3, PD 분리에 대해서는 Splitwise와 함께 널리 알려진 'DistServe'도 있긴 합니다. <DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving(2024. 01. 18)>

하드웨어는 반대 방향으로 진화해왔다

생각해보면 하드웨어가 KV Cache를 잘 다루는쪽으로 발전해오지 않았던 것도 병목을 만드는 구조적 요인입니다. 엔비디아의 Ampere에서 Blackwell로 오는 동안 GPU 연산능력은 28.8배 개선됐는데, 네트워크(PCIe) 대역폭은 2.0배, 메모리(HBM)은 2.4배 밖에 늘지 않았습니다. 결과적으로는 I/O 대비 연산 비율이 14.4배까지 벌어지는 효과로 나왔습니다. GPU는 빠르지만 데이터 대역폭은 생각보다 많이 바뀌지 않은 상태라서 여전히 가장 비싼 GPU의 가동률을 높이기 위해서 각종 주변 장비들의 업그레이드 및 용량 확대가 나오는 것입니다.

병목은 곧 자본 효율의 문제

논문에 나와있는 대표적인 그림입니다. 현 상태를 대표하는 그림인 왼쪽의 구조를 보시면 PE쪽 스토리지 NIC는 100% 포화되어 있고 GPU 활용률은 40%입니다. 반면, DE쪽 스토리지 NIC는 유휴 상태입니다.

그런데 오른쪽의 DualPath를 적용한 후의 구조를 보시면 DE쪽 스토리지 NIC까지 동원하면서 GPU 활용률이 80%로 올라가는 그림입니다. DualPath가 어떻게 KV Cache를 읽어들이는 병목을 해결하겠다는 것인지를 보여주는 가장 직관적인 도식입니다.

Agentic AI에서 토큰을 생성할 때에는 KV Cache가 워낙 커지다보니 GPU에 데이터를 먹이는 경로가 매우 좁고 그 좁은 길이 한쪽 엔진(PE)에만 몰려있다는 게 문제입니다. 이는 모델을 서빙하는 AI Labs와 기업들 입장에서 엔지니어링 디테일이 아닌 자본효율의 문제입니다. 같은 매출을 위해 하드웨어가 2배 필요하기 때문입니다.

에이전트의 병목

병목의 정체, 하드웨어는 반대로 진화했다, 스토리지 대역폭

배경을 이해하기 위해 : ⓐⓑⓒⓓ

LLM 추론과 관련해서 지나가며 말씀은 많이 드렸던 부분들이지만 DualPath를 풀어내기 위해서 다시금 정리해봅니다.

LLM 추론 환경을 이해하기 위해서는 네 가지 개념이 중요합니다. ⓐKV Cache, ⓑPrefill과 Decode 그리고 PD 분리, ⓒLayer-wise Prefill, ⓓCompute Network와 Storage Network입니다.

1. KV Cache : 과거 맥락을 다시 계산하지 않기 위한 것

KV Cache는 LLM 추론에서 가장 중요한 개념 중 하나입니다.

Transformer 기반 LLM은 다음 토큰을 생성할 때 이전 토큰들을 참고합니다. 이때 Attention 연산에서는 각 토큰마다 Key와 Value라는 중간 계산값이 만들어집니다. 이 Key와 Value를 매번 다시 계산하지 않고 저장해두는 것이 KV Cache입니다. 간단하게 생각해보자면, KV Cache는 '과거 컨텍스트를 다시 계산하지 않기 위해 저장해둔 계산 결과'입니다. 모델이 이전 대화 내용을 기억하는 것처럼 보이려면 과거 토큰들에 대한 Attention 정보를 다시 사용할 수 있어야 하기에 그 역할을 하는 것이 KV Cache입니다.

예를 들어서, 사용자가 30,000토큰짜리 컨텍스트를 이미 갖고 있는데 이번 턴에서 새로 추가된 내용은 300토큰이라고 가정해봅니다.

그러면 모델 입장에서는 처음부터 3만 토큰을 계산하는 것보다 이미 계산한 3만 토큰은 KV Cache로 불러오고(메모리에 저장해놨던 것을 불러옵니다. memory hierarchy를 따라서 HBM > CPU DRAM > SSD > HDD로 저장) 새로 추가한 300토큰만 계산하는 게 훨씬 효율적입니다.

이 KV cache를 저장하는 메모리 계층을 어디에 둘 것이냐에 따라 용량별 비용과 접근속도가 달라집니다.

HBM → DDR → NAND Flash/SSD → HDD입니다.

Cache hit는 이전에 저장된 KV cache를 재사용하는 경우를 의미하며 Cache miss보다 10배 저렴합니다. 이 덕에 AI Labs는 API 가격을 책정할 때부터 cache hit 시 비용을 크게 낮춰서 사용자가 Cache를 효율적으로 사용하도록 유도합니다. 그리고 저장 기간에 따른 가격도 차등화합니다. 5분 저장, 1시간 저장 등 시간마다 다른 가격을 책정합니다.

AI Labs의 모델 가격표를 보고서 생각해보자면, 이것에 맞춰서 처음 KV Cache를 저장할 때부터 SSD에 저장하게 할 것인지, HDD에 저장하게 할 것인지 등등 각각 다른 메모리 계층을 사용하는 것을 시사합니다.

각기 다른 메모리 계층은 Memory Drain Time으로 구분됩니다. 어디에 저장할 것이냐에 따라서 메모리 계층의 데이터를 모두 읽어들이는 데 드는 시간이 차이가 큽니다. HBM의 drain time은 20ms > DDR은 수 초 > Flash/SSD는 1분 > HDD는 1시간 정도입니다. Memory hierarchy를 따라갑니다.

Agentic AI로 갈수록 KV Cache가 커지는 것도 중요하지만, 생각해보면 이 구조에서는 대부분의 토큰이 이미 과거에 계산한 토큰입니다. 따라서 KV Cache hit rate가 매우 높습니다.

딥시크 연구진이 실제 에이전트를 통한 코딩 작업에서 썼던 컨텍스트들을 쭉 모아서 분석해봤더니 평균 턴 수는 157회, 평균 컨텍스트 길이는 32.7K 토큰, 평균적으로 한 턴에 새로 덧붙는 양은 429토큰이었습니다. 계산해보자면 KV Cache hit rate가 98.7%에 달합니다.

시스템 입장에서는 hit rate가 높으니 계산은 덜해도 되는데, 문제는 저장해뒀던 KV Cache를 많이 불러와야 한다는 게 문제입니다.

병목이 FLOPS에서 KV Cache 스토리지 I/O로 바뀌는 이유입니다.

연구진은 이를 Cache-compute Ratio로 정의했습니다. '1PFLOP(페타플롭)의 연산을 하기 위해서 몇 GB의 KV Cache를 읽어야 하는가'로 측정하는 것입니다. Qwen2.5-32B 기준 117~267GB/PFLOP, GPT-oss-120B 기준 47~95GB/PFLOP, DeepSeek-V3.2 기준 22GB/PFLOP입니다. 연산을 하기 위해서 엄청난 스토리지 대역폭의 부담을 줍니다.

그리고 모델이 sparse attention이나 MoE처럼 실제 활성 연산량을 줄이는 방향으로 진화할수록 FLOPS 부담은 줄어듭니다. 그러나 KV Cache를 읽어와야 하는 I/O 부담은 그대로 남거나 상대적으로 커질 수 있습니다. 그래서 연산을 아낄수록 오히려 KV Cache 이동이 더 두드러진 병목이 됩니다. Cache-compute Ratio는 오히려 상승하는 것이고, 연산을 아낀 만큼 AI Labs 입장에서는 더욱 더 KV Cache I/O에서 병목을 느끼는 것입니다.

2. Prefill과 Decode, 그리고 PD 분리

LLM 추론은 성격이 전혀 다른 두 단계로 나뉩니다.

Prefill : 사용자가 입력한 프롬프트을 한꺼번에 읽어 들이는 단계입니다. 많은 데이터를 한 번에 병렬로 처리하므로 GPU의 컴퓨팅 성능(FLOPS)을 최대로 활용할 수 있어 효율이 좋습니다. *compute-bound*

Decode : 질문을 이해한 뒤 답변을 한 토큰씩 생성하는 단계입니다. 첫 토큰이 나와야 두 번째 토큰을 만들 수 있는 자기회귀(Autoregressive = Transformer도 일부) 방식입니다. 계산 속도보다 메모리에서 데이터를 가져오는 속도가 핵심입니다. 칩 스피드를 키우고, 데이터 I/O 통로를 더 많이 뚫어 HBM 대역폭을 키우는 것이 중요한 이유입니다. 우리가 느끼는 답변 속도를 결정하는 것이 이 부분입니다. *memory-bandwidth-bound*

두 단계의 성격이 다르기 때문에, 최신 LLM 추론 시스템에서는 이 둘을 아예 다른 엔진으로 분리하는 구조가 널리 쓰입니다. 이것이 PD 분리, 즉 Prefill-Decode Disaggregation입니다.

Prefill을 담당하는 서버 또는 GPU 그룹을 Prefill Engine, 줄여서 PE라고 부릅니다. Decode를 담당하는 서버 또는 GPU 그룹을 Decode Engine, 줄여서 DE라고 부릅니다.

흐름은 이렇습니다:

1. 사용자 요청이 들어오면 PE는 외부 스토리지에서 KV Cache를 읽어들이고, 새로 추가된 토큰은 Prefill 계산을 합니다.

2. PE는 완성된 KV Cache를 DE로 넘깁니다.

3. DE는 KV Cache를 기반으로 실제 답변할 토큰을 하나씩 생성합니다.

4. 생성한 새 토큰의 KV Cache는 이후 재사용을 위해 다시 외부 스토리지에 저장합니다.

이 구조는 원래는 매우 합리적입니다. Prefill과 Decode는 필요한 자원이 다르니 서로 다른 GPU 또는 서로 다른 서버에서 처리하면 throughput이 올라갑니다. 예를 들어 Prefill은 강력한 최신 GPU에 맡기고, Decode는 메모리 대역폭 중심으로 최적화된 다른 자원에 맡기는 식의 구성이 가능합니다.

그러나 Agentic AI에서는 새로운 병목이 됩니다.

기존 PD 분리 구조에서는 이미 연산해뒀던 KV Cache를 외부 스토리지에서 가져오는 일은 오직 PE만 하기 때문입니다. 스토리지에서 KV Cache를 가져오는 부담이 PE쪽 스토리지 NIC에 집중되고, DE도 자체 스토리지 NIC를 갖고는 있지만 기존 구조에서는 이 경로가 충분히 활용되지 않았었습니다.

결과적으로는 PE쪽 스토리지 NIC는 포화, DE쪽 스토리지 NIC는 유휴상태가 됩니다. GPU는 계산할 준비가 되어 있지만 PE쪽으로 KV Cache가 충분히 빨리 들어오지 않으니 대기 상태인 시간이 길어집니다. DualPath가 해결하려는 건 PD 분리 구조 내에서 KV Cache를 읽어오는 경로를 DE쪽으로도 만들려는 것입니다.

3. Layer-wise Prefill : 컨텍스트가 길어질 때 GPU-HBM 부족을 해결하기 위한 방식

LLM은 여러 개의 Transformer Layer로 구성되어 있고, 여러 층을 순서대로 통과하면서 계산이 진행됩니다. 일반적으로 Prefill에서 긴 컨텍스트를 읽어들일 때는 activation과 KV Cache 전체를 GPU HBM에 올려야 합니다.

컨텍스트가 짧을 때는 괜찮은데 길이가 길어지면 HBM 용량이 금방 부족해집니다. <LLM 추론 토큰 가격의 비밀>에서 추론 시 토큰 비용과 관련해 가장 중요한 Batch size에 대해서 다뤘던 바 있습니다.

KV cache는 두 가지 상황에서 빠르게 커집니다.

- 컨텍스트 윈도우가 길어질수록(incl. Chain-of-Thought용 토큰) → 한 사용자의 KV cache가 커집니다.

- 동시에 처리하는 사용자가 많아질수록(batch size 키울수록) → 전체 KV cache가 커집니다.

이 구조를 그대로 반대로 생각해보면, HBM 용량이 부족해질 경우 한 번에 처리하는 batch size를 줄여야 한다는 의미입니다. batch size를 줄이면 GPU를 충분히 활용하지 못하니 이 경우에도 가동률이 낮아집니다.

Layer-wise Prefill의 핵심 아이디어는 '모든 Layer의 KV Cache를 한 번에 GPU에 올릴 필요는 없다'는 것입니다. 특정 Layer를 계산할 때는 그 Layer에 해당하는 KV Cache만 HBM에 담으면 됩니다.

필요한 Layer의 KV Cache만 올리고 계산이 끝나면 비우고, 다음 Layer의 KV Cache를 올리는 방식으로 처리할 수 있습니다. 그만큼 더 많은 요청을 하나의 batch에 채울 수 있으니 Prefill 단계의 throughput이 향상됩니다.

하지만 문제는 Layer 단위로 KV Cache를 쪼개놓으니까 데이터 이동도 굉장히 자잘하게 해야 합니다. 원래는 큰 KV Cache 덩어리로 읽고 쓰면 됐는데 Layer-wise Prefill은 Layer 수 만큼 많은 작은 블록들을 빠르게 옮겨야 합니다. 이 과정에서 KV Cache가 옮겨다닐 때 GPU HBM~DRAM~SSD 사이의 데이터 이동을 더 잘 구성해야 합니다.

DualPath에서도 HBM 용량 병목을 줄이는 기술인 Layer-wise Prefill이 중요하다고 보고 있습니다.

하지만 더 잘게 쪼개진 KV Cache를 더 잘 관리해야 하는 기술이 필요하다는 것도 있어서, 이것도 아래에서 한 번 더 정리해봅니다.

4. Compute Network(CNIC) & Storage Network(SNIC) : GPU-GPU 통신, GPU-스토리지 통신

가장 중요한 개념이 CNIC과 SNIC입니다.

우선 여기도 개념부터 잡아보자면, AI 데이터센터는 네트워크가 하나로 구성되어 있지 않습니다. 두 종류의 네트워크가 있습니다. 하나는 Comute Network이고, 다른 하나는 Storage Network입니다.

Compute Network는 서버-to-서버끼리 모델 실행을 위해 서로 통신하는 네트워크입니다. 여기에 붙어있는 NIC를 Compute NIC인 "CNIC"라고 부릅니다. 동서 방향의 트래픽이라는 점에서 East-West 트래픽이라고도 부릅니다. 모델 실행에 매우 중요한 네트워크입니다. MoE에서는 전문가들끼리 통신을 위한 all-to-all 통신이 중요합니다. 지연시간에 매우 민감한 워크로드들이고 조금만 느려져도 전체 초당 토큰 생산량이 크게 흔들리는 트래픽 성격입니다. 여기는 GPU 하나당 400Gbps짜리 NIC가 붙어있으니 8-GPU 노드 기준 8 x 400Gbp로 총 3.2Tbps 대역폭이 가능합니다.

엔비디아 NIC 스펙 정리

ConnectX-7 SuperNIC : Hopper부터 생산, GPU 하나당 400Gbps

ConnectX-8 SuperNIC : Blackwell Ultra부터 생산, GPU 하나당 800Gbps

ConnectX-9 SuperNIC : Rubin부터 생산, GPU 하나당 1.6Tbps

Storage Network는 외부 스토리지에서 데이터를 읽고 쓰는 네트워크입니다. 여기에 붙은 NIC를 Storage NIC인 "SNIC"이라고 부릅니다. 남북 방향의 트래픽이라는 점에서 North-South 트래픽이라고도 부릅니다. 데이터셋을 불러오고 저장하고, KV Cache를 읽어오는 통로이기도 합니다. 8-GPU 노드 기준 1개의 NIC가 있고 최대 400Gbps입니다.

AI 데이터센터에서는 두 네트워크를 분리하는 것이 원칙입니다. 스토리지에서 대용량 데이터를 읽어오는 작업이 GPU 간 모델 실행 통신을 방해하면 안되기에 그렇습니다. GPU끼리 매우 빠르게 작업해야 하는 것들이 있는데 스토리지 트래픽까지 섞이면 지연시간이 튀고 모델 실행이 불안정해집니다.

그런데 Agentic AI로 인한 KV Cache 증가와 PD 분리 구조가 맞물리면서 새로운 비효율을 만들어냅니다.

원래 PD 분리를 하면 PE가 외부 스토리지에서 KV Cache를 읽습니다. 따라서 PE의 SNIC에는 KV Cache 읽기 트래픽이 몰립니다. 반면 DE의 SNIC는 상대적으로 놀고 있습니다. 그런데 DE도 역할만 Prefill/Decode로 나누느라 그랬을 뿐 같은 엔비디아 서버이고, DE도 Storage NIC를 가지고 있습니다. 시스템 전체로 보면 사용할 수 있는 Storage NIC 대역폭이 남아 있는데 기존 구조는 이를 충분히 쓰지 못하는 구조였습니다.

DualPath의 핵심 아이디어

Decode Engine으로 차선 뚫기, 난관 → 이를 해결하기 위한 방법

Decode Engine쪽 SNIC → CNIC → Prefill Engine으로 넘기는 차선을 새로 뚫는다

그래서 DualPath는 아예 KV Cache를 DE가 먼저 스토리지에서 읽은 뒤에 CNIC로 PE로 넘깁니다.

구조를 보시면,

기존:

PE의 KV Cache 읽기 경로 : 스토리지 → PE의 SNIC → PE = ⓐ

DE의 KV Cache 읽기 경로 : 없음

DualPath:

PE의 KV Cache 읽기 경로 : 기존의 ⓐ 경로 + DE를 통해 CNIC로 전달받는 ⓑ 경로

DE의 KV Cache 읽기 경로 : DE의 SNIC → PE랑 DE를 잇는 CNIC를 통해 → PE에 전달 = ⓑ

이렇게 DE를 통해 읽는 경로가 추가되면, PE 쪽에만 몰려 있던 스토리지 I/O 부담이 PE와 DE로 분산됩니다.

풀어야 할 문제가 생긴다

물론 여기에는 주의할 점이 있습니다. DE가 읽은 KV Cache를 PE로 넘기려면 Compute Network를 써야 합니다. 그런데 Compute Network는 모델 실행 통신에도 사용됩니다. KV Cache 전송이 All-to-All 같은 중요한 모델 통신을 방해하면 안 됩니다. 이걸 어떻게 푸느냐가 DualPath 논문의 핵심입니다.

그래서 DualPath는 KV Cache 트래픽을 낮은 우선순위로 두고 모델 실행 통신을 높은 우선순위로 보호하는 방식의 트래픽 관리를 사용합니다. 쉽게 말하면, GPU끼리 꼭 해야 하는 모델 실행 통신이 먼저 지나가고, 그리고 KV Cache 전송은 남는 대역폭을 활용하는 구조입니다.

차분하게 다시 하나씩 짚어보면:

SNIC는 스토리지에서 KV Cache를 읽는 길입니다.

CNIC는 GPU와 GPU, 서버와 서버 사이에서 KV Cache를 옮기거나 모델 실행 통신을 하는 길입니다.

DualPath는 놀고 있는 DE의 SNIC를 활용하고, 남는 CNIC 대역폭을 이용해 PE로 KV Cache를 넘깁니다.

그런데 실제 시스템에서는 새로운 데이터 이동 경로를 추가하는 순간, 또 다른 병목과 간섭이 생길 수 있습니다. 논문은 DualPath를 실제로 구현하려면 세 가지 문제를 풀어야 한다고 말합니다.

첫 번째 난관, 잘게 쪼개진 KV Cache를 어떻게 효율적으로 옮길까?

앞에서 Layer-wise Prefill을 설명드렸습니다. 그리고 단점도 같이 전해드렸었습니다. 문제는 KV Cache가 훨씬 잘게 쪼개진다는 점입니다. 원래라면 큰 KV Cache 덩어리를 한 번에 읽고 쓰면 됩니다. 그런데 Layer-wise Prefill은 각 Layer에 필요한 KV Cache를 Layer 단위로 계속 불러와야 합니다.

결과적으로는 큰 화물 하나를 옮기는 게 아니라 작은 박스 수천 개를 빠르게 옮기는 문제가 됩니다. ⓐKV Cache를 스토리지 → DRAM → GPU HBM으로 옮기는 과정, 그리고 ⓑDE에서 PE로 데이터를 옮기는 과정에서 이것이 느려지면 결국은 DualPath의 장점이 사라집니다. 이것을 어떻게 하느냐가 첫 번째입니다.

두 번째 난관, 모델 실행 통신을 방해하지 않아야 한다

DualPath는 DE가 읽은 KV Cache를 PE로 넘기기 위해 Compute Network를 사용합니다. 그런데 Compute Network는 원래 GPU들이 모델 실행을 위해 서로 통신하는 핵심 네트워크입니다. 어떻게 정말 놀고 있는 대역폭만 써야 합니다. 모델 실행이 필요할 때는 그 통신이 먼저 지나가게 하고, KV Cache는 뒤로 미뤄야 하니 우선순위 관리를 잘해야 합니다. 이걸 어떻게 하느냐가 두 번째입니다.

세 번쨰 난관, PE와 DE 중 어떤 길이 더 빠를 것인가?

DualPath에는 두 개의 KV Cache 읽기 경로가 생깁니다.

하나는 PE가 직접 스토리지에서 KV Cache를 읽습니다. 다른 하나는 새로 추가된 경로입니다. DE가 스토리지에서 KV Cache를 읽고 이를 PE로 넘깁니다.

그러면 매번 요청마다 판단해야 합니다.

이번 요청은 PE가 직접 읽는 게 빠른가?

아니면 DE가 읽어서 PE로 넘기는 게 빠른가?

어느 PE가 덜 바쁜가?

어느 DE가 여유가 있는가?

어느 노드의 스토리지 읽기 대기열이 짧은가?

GPU 쪽 부하는 어느 정도인가?

예를 들어서, DE쪽 SNIC가 좋다고 해서 DE로 다 몰아버리면 DE쪽 SNIC가 병목이 됩니다. PE를 많이 쓰면 원래랑 똑같습니다. 그래서 동적 스케줄러가 중요합니다. PE와 DE에 배정하고 KV Cache를 어느 쪽 경로로 읽게 할 것인지를 결정해야 합니다.

해결법 #1 - 두 가지 블록 형식을 택하다

첫 번째 문제는 잘게 쪼개진 KV Cache를 어떻게 효율적으로 저장하고 전송할 것이냐입니다.

딥시크는 이 문제를 풀기 위해 두 가지 블록 형식을 사용했습니다.

하나는 Layer Block입니다. Layer Block은 하나의 Layer에 해당하는 KV Cache만 담습니다. 지금 계산할 Layer에 필요한 만큼만 GPU HBM으로 흘려보낼 때 사용합니다.

다른 하나는 Full Block입니다. Full Block은 모든 Layer의 KV Cache를 한꺼번에 담습니다. 스토리지에 저장하거나 스토리지에서 읽어올 때 사용합니다.

스토리지 입장에서는 너무 잘게 쪼개진 데이터를 계속 읽고 쓰는 것이 비효율적입니다. 그래서 스토리지에는 큰 덩어리인 Full Block 형태로 저장합니다. 반면 GPU 계산 입장에서는 지금 계산할 Layer에 해당하는 KV Cache만 필요합니다. 그래서 계산 중에는 Layer Block 형태로 흘려보냅니다.

그리고 Layer Block을 모델 Layer의 수만큼 N개 이어 붙이면 Full Block이 되도록 설계해서 추론 중에 메모리 레이아웃을 일일히 바꾸는 게 필요없게끔 만들었습니다.

해결법 #2 - CNIC 중심의 트래픽 관리

두 번째 문제는 모델 실행 통신과 KV Cache 전송의 우선순위를 잘 설정해야 한다는 것이었습니다.

그런데 여기서는 좀 하드웨어적으로 중요한 것이 있습니다. 원래 GPU 안팎으로 오가는 데이터는 PCIe 경로를 사용합니다. 그런데 현재 GPU는 PCIe 단계에서 트래픽 우선순위 제어, 즉 QoS를 제대로 지원하지 않습니다. 통신 우선순위를 매기는 작업은 PCIe에서 지원하지 않습니다. 그리고 모델 통신은 워낙 짧은 시간에 폭발적으로 발생하는 것이라서 소프트웨어적으로 제어하면 throughput 로스가 꽤 커집니다.

그래서 나름의 역발상으로 딥시크는 GPU를 드나드는 모든 데이터를 CNIC를 거치게 만들었습니다. 일단 CNIC로 들어갔다가 나오게끔 만든 것입니다. 이유는 엔비디아의 Compute Network를 담당하는 InfiniBand에 하드웨어 수준의 우선순위 제어 기능(QoS)인 VL(Virtual Lane)이 있기 때문입니다. 모든 트래픽을 InfiniBand를 통하게끔 만들면 자체 QoS를 가지고 우선순위를 매길 수 있습니다.

모델 실행 통신을 고우선순위 레인에 배정하고, KV Cache 전송은 저우선순위 레인에 배정합니다. 그리고 고우선순위 레인에 대부분의 대역폭을 할당했습니다. 논문에는 전체 대역폭의 99%를 모델 실행용 고우선순위 차선에 배정하고, 나머지 1%를 KV Cache 전송용 저우선순위 차선에 배정했습니다. 이러면 모델 실행 통신이 필요한 때에는 거의 영향을 받지 않고, 통신이 없는 빈틈을 이용해서 전송을 하는 구조를 만들 수 있다는 것입니다.

RoCE에서도 가능하기 때문에 아마 이것을 엔비디아가 하드웨어로 제품화 한 것이 CES 2026에서 발표한 Vera Rubin Pod의 G3.5 Context Memory Storage 구조가 아닐까 싶습니다. SSD와 GPU를 직접 Spectrum-6 + ConnectX-9 SuperNIC로 연결하는 것입니다.

해결법 #3 - 적응형 요청 스케줄러 (Adaptive Request Scheduler)

세 번째 문제는 요청마다 어느 경로로 보내는 게 제일 나을지의 균형을 맞추는 게 중요하다는 것이었습니다.

두 가지 균형을 동시에 봐야 합니다.

네트워크 트래픽 균형 : 어느 SNIC가 바쁜지, 어느 쪽 읽기 대기열이 짧은지 봐야 합니다.

GPU 연산 부하 균형 : 어느 GPU가 이미 많은 요청을 맡고 있는지, 앞으로 처리해야 할 토큰 수가 얼마나 되는지 봐야 합니다.

종류는 두 가지이지만, 둘 다 토큰 수와 강하게 연동되므로 연구진은 토큰 수를 부하의 대리지표로 삼아서 엔진 간에 고르게 분배하는 것으로 기준을 잡았습니다.

스케줄링은 네 가지 단계로 나뉩니다.

PE 배정

DE 배정

읽기 경로 선택

GPU 내부의 균형 맞추기

이걸 하나씩 분해해보자자면,

PE 배정에서, 스케줄러는 PE를 세 그룹으로 나눕니다.

이미 너무 바쁜 PE → 여기는 새 요청을 배정하지 않습니다.

스토리지 대기열이 짧고 아직 과부하가 아닌 PE → 우선적으로 사용합니다.

과부하는 아니지만 스토리지 읽기 대기열이 긴 PE → 두 번째 그룹이 없을 때만 사용합니다.

DE 배정은 ⓐ그룹 간 배정과 ⓑ그룹 내 배정으로 나눕니다.

ⓐ그룹 간 배정 : 전체 토큰 수가 가장 적은 DE 그룹을 택합니다. 그러면 그룹 단위로 GPU 부하와 네트워크 부하를 고르게 나눌 수 있습니다.

ⓑ그룹 내 배정 : 각 DE의 HBM 여유와 토큰 수를 같이 판단합니다. 남은 HBM 용량이 부족한 DE에는 새 요청을 넣지 않습니다. HBM이 충분한 DE들 중에서는 토큰 수가 지나치게 높아지지 않도록 조정합니다. 요청 수, 토큰 수를 함께 보면서 특정 DE로 부하가 몰리는 것을 막습니다.

읽기 경로는 PE와 DE가 정해지면, 이제 KV Cache를 어느 쪽에서 읽을지 결정해야 합니다. PE가 직접 읽을지, DE가 읽어서 PE로 넘길지 선택하는 것입니다. PE쪽 읽기 대기열과 DE쪽 읽기 대기열을 보고, 더 짧은 쪽에서 읽습니다. 논문에서는 향후에는 요청 하나를 둘로 나눠서 양쪽에서 읽도록 하는 것도 생각할 수는 있다며 향후 과제로 남겼습니다.

GPU 내부 균형도 맞춥니다. 어떤 요청을 같은 batch에 넣을지를 결정하는 것입니다. 데이터를 병렬로 처리하다보면 GPU마다 서로 다른 요청을 맡을 수 있습니다.

그런데 Attention 단계가 끝나면 GPU들이 함께 FFN 단계로 넘어가야 합니다. 이때 한 GPU가 늦으면 나머지 GPU들이 기다리는 bubble이 생깁니다. 그래서 DualPath는 연산 쿼터(compute quota) 상한을 두고 각 batch의 실행 시간이 비슷해지도록 조정시킵니다.

*GPU 내부 균형을 맞추는 방법에 대한 그림

연구 결과와 함의점

검증 ⓐⓑⓒ, InfiniBand, Agent와 함께 올 SSD 수요

DualPath 적용 시 실제로 얼마나 좋아지는가?

'얼마나 좋아지는가'를 판단하려면 Before와 After를 비교해봐야 합니다.

딥시크 연구진이 DualPath를 검증에 사용한 모델은 세 가지입니다. ⓐDeepSeek-V3.2 660B, ⓑ이 모델을 줄인 DeepSeek-V3.2 27B 내부 실험 모델, 그리고 ⓒQwen2.5-32B입니다. 실험 데이터는 실제 에이전트 RL 학습에서 나온 트레이스를 사용했습니다. 단순한 합성 벤치마크가 아니라 코딩 에이전트가 여러 턴을 거치며 작업하는 형태에 가까운 워크로드로 실험한 것입니다.

비교 대상도 세 가지입니다.

아래의 표시를 보시면:

Ours : DualPath

비교군 : ① Ours(Basic), ② Ours(Oracle), ③ SGL(MC)

Ours(Basic) → 딥시크가 DualPath를 적용하기 전 내부 추론 시스템 성능입니다.

Ours(Oracle) → 각종 I/O가 0이라고 가정한(디스크 읽기, H2D/D2H 복사, PE-DE간 KV Cache 전송) 이론적인 상한입니다.

SGL(MC) → 오픈소스 비교군입니다. SGLang + HiCache + Mooncake + 3FS 등을 조합하여 오픈소스에서 추론할 경우 이정도의 퍼포먼스가 나오겠다고 추정할 수 있는 값입니다.

핵심 비교 기준은 딥시크가 DualPath를 적용하기 이전("Ours(Basic)")에 비해서 → DualPath를 적용하고 나서 얼마나 퍼포먼스가 좋아졌는가("Ours")입니다.

실험결과 #1 - 오프라인 추론 환경 시 1.87배 개선

오프라인 추론이란 RL 훈련과 비슷합니다.

엄밀히 말하면 파라미터를 업데이트하는 훈련 자체는 아니고, 학습에 사용할 agent trajectory를 만들기 위해 여러 에이전트가 동시에 추론을 수행하는 단계입니다. 모델이 여러 턴에 걸쳐 reasoning과 tool use를 반복하면서 작업을 수행하고, 이렇게 생성된 결과는 이후 reward model 평가와 학습 업데이트에 활용됩니다. *RL sandbox*

이번 실험에서는 여러 에이전트가 동시에 작업을 시작한 뒤, 모든 작업이 끝날 때까지 걸린 시간인 JCT(Job Completion Time)를 측정했습니다. 결과는 매우 좋았습니다. 동시에 돌리는 에이전트 수가 많아질수록, 그리고 에이전트의 최대 컨텍스트 길이가 길어질수록 DualPath의 이점이 더 커졌습니다.

우선, DeepSeek-V3.2 660B에서는 Basic 대비 최대 1.87배 빨라졌습니다. 특히 이 경우 DualPath의 성능이 Oracle에 거의 가까워졌습니다. Oracle은 I/O 오버헤드가 0이라고 가정한 이론적 상한입니다.

따라서 DS 660B 오프라인 실험에서는 DualPath가 KV Cache I/O 병목을 거의 전부 제거했다는 뜻입니다.

DS 27B에서도 Basic 대비 최대 1.78배 개선됐습니다. 다만 DS 27B는 1P1D(Prefill 노드 1개와 Decode 노드 1개)를 쓰는 매우 작은 구성이라 스토리지 대역폭 자체가 제한적이었습니다. 그래서 Oracle에는 미치지 못했습니다. KV Cache 부담이 크지 않으니 1.78배 개선된 것입니다. 그럼에도 불구하고 1.78배 개선이니 좋았습니다.

Qwen2.5-32B도 DS 27B와 비슷한 방향의 개선을 보였습니다. 다만 Qwen 32B는 KV Cache가 더 크기 때문에 DRAM 설정도 달랐던지라 조심해서 봐야 합니다.

실험결과 #2 - P/D Ratio 실험, 병목이 스토리지 대역폭임을 확인하다

가장 중요한 실험은 Prefill-Decode 비율별로 JCT를 비교하는 실험입니다.

Figure 8에서 보실 수 있는데, 연구진은 DS 27B 모델에서 1P1D, 2P1D, 1P2D 구성을 비교했습니다.

결과적으로 DualPath는 모든 비율에서 Basic보다 우월했습니다. 평균 1.64배의 성능 개선이고, 최대 2.46배 성능 개선을 보였습니다.

이것만 보고도 굉장히 직관적인데,

Basic 1P1D와 Basic 1P2D는 비슷했습니다.

DualPath 1P1D와 Basic 2P1D도 비슷했습니다.

DualPath 2P1D와 DualPath 1P2D도 비슷했습니다.

Basic은 PE 노드의 스토리지 대역폭만 쓸 수 있습니다. DualPath 설정에서는 PE뿐만 아니라 DE 노드의 스토리지 대역폭도 활용합니다. 따라서 Basic에서 Prefill 노드를 2개로 늘린 것과, DualPath에서 Prefill 1개 + Decode 1개의 스토리지 대역폭을 모두 활용한 것이 비슷한 효과를 낸 것입니다.

병목이 GPU 연산이면 이런 패턴이 안 나올텐데, Agentic AI 워크로드 성능이 '사용 가능한 스토리지 대역폭'에 따라서 달라짐을 가장 직관적으로 보여주는 실험 결과입니다.

KV Cache I/O가 중요할수록 DualPath의 강점이 극대화된다

그리고 Figure 9에서 보실 수 있는 것처럼 DualPath는 기존 KV Cache를 불러오는 양이 많고, 추가로 생성한 토큰이 짧을수록 더 유리했습니다. 추가 길이가 길어지면 Prefill 시간이 길어지면서 KV Cache보다는 FLOPS가 중요해져서 그렇습니다.

실험결과 #3 - 온라인 지연시간

여기도 비교는 Ours와 Ours(basic) 비교인데, 지표를 먼저 정리하면:

TTFT(Time-to-First-Token) : 첫 토큰 생성까지 걸린 시간, Prefill + KV Cache 로딩이 대부분

TTST(Time-to-Second-Token) : 두 번째 토큰 생성까지 걸린 시간

TPOT(Time-Per-Output-Token)* : 스트리밍 속도, decode 타이핑 속도랑 비슷

APS(Agent Arrival Rate) : 초당 새로 들어오는 에이전트 작업 수

*TPOT는 사용자 1명 입장에서의 체감 속도이니 낮을수록 좋고, Throughput은 주로 TPS(Tokens Per Second)를 의미하는데 '서버' 입장에서의 총 처리량이라 높을수록 좋습니다.

오프라인 추론에서는 '에이전트 1,024개를 한꺼번에 시작해서 전부 끝날 때까지 얼마나 걸리나?'를 봅니다. 그래서 지표가 JCT(Job Completion Time)입니다. 그런데 온라인 서빙에서는 사용자가 계속 들어옵니다. 어떤 에이전트는 이미 작업 중이고, 그 와중에 새 에이전트가 계속 도착합니다. 이때 1초에 몇 개의 새 에이전트 세션이 들어오느냐가 agent arrival rate입니다. 0.1 APS면 10초당 에이전트 1개가 새로 들어온다, 0.5 APS면 2초에 에이전트 1개, 1.0 APS면 1초에 에이전트 1개가 새로 들어온다입니다. 그래서 APS가 높을수록 시스템에 들어오는 부하가 커지고, 좋은 시스템일수록 TTFT와 TPOT 같은 지연시간 SLO를 지키면서 더 높은 APS를 감당할 수 있습니다.

다시 차트를 보고 정리하면,

맨 왼쪽 차트에서 TTFT 선이 크게 튀기 시작하는 지점이 DualPath를 적용한 환경에서 훨씬 오른쪽입니다. 같은 SLO(Service Level Objective, 풀어서 보면 '이 정도 지연시간 안에는 응답해야 정상 서비스로 본다'는 기준)를 충족하면서도 받아낼 수 있는 부하가 DS 27B에서는 1.67배, DS 660B에서는 2.25배 큽니다.

*논문 실험 환경에서의 SLO는 ⓐTTFT ≤ 4초 ⓑTPOT ≤ 50ms입니다.

맨 오른쪽 차트에서 TPOT 선은 0.3 APS까지 같습니다. 그렇다는 건 Prefill 및 KV Cache 로딩에 영향을 받는 TTFT는 개선하지만, Decode 속도이자 토큰이 스트리밍되는 속도인 TPOT에는 추가 부담을 주지 않는다는 뜻입니다. Throughput을 높였지만 사용자 체감 속도는 달라진 게 없다는 것을 보여주는 것이라서 두 가지를 같이 보시면 전체를 보실 수 있습니다.

실험결과 #4 - 실험결과 #3의 TTFT 성능 개선을 분해하다

딥시크가 역시 굉장히 자세하게 올려줘서 좋습니다. Figure 12는 위 실험결과 #3에서 있었던 온라인 서빙 환경에서의 TTFT 성능 개선이 어디서 나왔는지를 분해한 것입니다. 왼쪽 차트를 보시면 APS마다 막대가 두 개인데 왼쪽이 DualPath를 적용한 추론 시스템, 오른쪽이 기존 딥시크의 추론 시스템입니다.

그리고 TTFT를 구성하는 요소를 네 가지로 분해했습니다:

Sch. (빨강, 맨 아래) : 스케줄링/대기, 요청이 들어와서 배치까지 기다린 시간

A. (살구색) : 할당, HBM 등 자원을 확보하기까지의 시간

R. (연주황) : KV Cache를 읽는 시간, 스토리지에서 KV Cache를 읽어들이기 위한 전체 시간

PF. (맨 위) : Prefill 연산 시간

핵심은 부하가 올라가면(APS를 0.15 → 0.25로 높이더라도) Basic은 대기시간(Sch)이 커지는데, DualPath는 TTFT 구성요소가 상대적으로 안정적으로 유지된다는 것입니다.

Basic은 스토리지 대역폭이 부족하니 배치를 기다리는 시간이 급격히 커지지만 DualPath는 굉장히 안정적인 모습을 보실 수 있습니다.

그리고 오른쪽 차트도 중요합니다. 오른쪽은 기술을 하나씩 추가했을 때 성능이 얼마나 개선되더라를 보여주는 차트입니다. Basic에서 출발해서 Layer-wise Prefill(Layer), DualPath Loading(DPL), Scheduling(Sched)을 순서대로 더했을 때 얼마나 좋아지는지를 봤습니다.

Layer-wise Prefill만 추가하면 평균 JCT가 17.21% 개선됩니다.

DualPath Loading을 추가하면 JCT 감소폭이 38.19%로 커집니다. 가장 큰 도약입니다.

Scheduling까지 더하면 JCT 감소폭이 45.62%가 됩니다.

그리고 JCT 감소 이득은 1024 에이전트 추론 환경보다 2048에서 더 컸습니다. KV Cache I/O 압력이 커지는 지점에서 DualPath의 이점이 극대화된다는 것을 여러 실험으로 확인할 수 있습니다.

마지막으로는 Figure 15에서 이것이 1,152 GPU 규모에서도 DualPath 구조를 하면 이로 인해 생기는 병목은 거의 없고 KV Cache I/O를 해결함으로써 이득을 보는 부분에 대해서도 48P96D 환경에서 입증했습니다.

DualPath의 함의점들

딥시크만 거의 웬만한 주요 연구 내용들도 오픈소스로 공개하기 때문에 그럴뿐, 당연히 미국과 중국의 프론티어 AI Labs들은 해당 기능과 유사한 작업을 하고 있다고 보는 것이 합리적인 추론입니다. 딥시크가 어떻게 하고 있다를 파악하려는 것을 넘어서 현재 주요 하이퍼스케일러들과 AI Labs들이 어떤 방향으로 연구하고 있는지를 파악할 수 있기에 중요합니다.

소프트웨어적인 하드웨어 성능 개선의 또 다른 사례입니다. 딥시크는 DualPath 구현이 내부 추론 프레임워크 위에 5천 줄 정도의 코드를 수정했더니 에이전트 워크로드에서 오프라인 추론은 ~1.87배, 온라인 서빙은 평균 1.96배 개선했다고 말했습니다.

추론으로 넘겨가면서 기존의 로직과 완전히 달라졌음을 더 자세하게 확인할 수 있었습니다. 메모리가 중요한 이유들에 대해서도 조금 더 정확히 포인트를 잡으실 수 있으실 것 같습니다.

여기서 중요한 건 QoS이기도 합니다. InfiniBand, Spectrum-X 등 RDMA와 QoS를 제대로 다룰 수 있는 컴퓨트 패브릭의 전략적 가치가 더욱 커집니다. 세부 구현은 AI Labs들마다 다르다고 가정하더라도 HW~SW~네트워킹의 전체적인 관리가 중요한 이유를 이해하시는 데 도움이 되실 거라 생각합니다.

DualPath는 Agentic AI에서 KV Cache가 커질수록 HBM/DRAM만으로는 부족해지고, SSD 기반 외부 스토리지를 얼마나 효율적으로 활용하느냐가 중요해진다는 점에서 NAND 수요와 직간접적으로 연결되는 논문입니다. 대용량 DRAM 풀을 넘어서 SSD를 더 많이 활용할 수 있도록 하는 선택입니다. KV Cache를 빠르게 재사용하려면 가장 쉬운 방법은 DRAM을 많이 두는 것입니다.

DRAM에 KV Cache를 캐싱해두면 SSD보다 빠르게 읽을 수 있습니다. Mooncake 계열 접근이 이런 방향입니다. 하지만 온라인 서빙처럼 거대한 추론 환경에서는 모든 KV Cache를 DRAM에 올려두면 너무 비쌉니다. 오프라인 RL 환경에서도 그렇습니다. DualPath는 대신 SSD 기반 외부 스토리지를 직접 활용하고, PE와 DE의 SNIC를 모두 동원해 읽기 대역폭을 균형 있게 씁니다. 실험에서 DeepSeek 기준 DualPath는 노드당 80GB DRAM을 사용했고, Qwen 32B처럼 KV Cache가 더 큰 모델에서는 320GB를 사용했습니다. 반면 SGL(MC)는 노드당 약 1.5TB DRAM을 사용했습니다. 상대적으로 GB당 훨씬 저렴한 SSD를 다루면서 NIC와 스케줄러로 병목을 줄이는 것이 핵심입니다.