DeepInfer의 프로덕션 격차: KV cache, PD, 로드 밸런싱

DeepInfer는 DeepSeek의 V4.1-Flash 추론 엔진이며 완전한 서빙 스택이 아닙니다. README의 “미포함” 목록은 짧습니다. KV cache 시스템, VE/프리필/디코드 분리, 데이터 병렬 복제본 간 로드 밸런싱입니다. 각 항목은 기능 플래그가 아니라 하나의 서브시스템입니다. 이 셋을 합치면 모델을 돌리는 것과 서비스를 운영하는 것의 차이가 됩니다.

엔진과 서비스

엔진은 토큰화된 요청 묶음을 받아 생성된 토큰을 돌려줍니다. 서비스는 여러 사용자의 HTTP 요청을 받아 인증하고, 라우팅하고, 컨텍스트를 따뜻하게 유지하고, 할당량을 적용하고, 장애를 처리하고, 과금합니다. 엔진은 비싼 연산이고, 서비스는 비싼 운영입니다.

DeepInfer는 엔진입니다. DeepSeek의 Q&A는 그 주변의 서비스를 이례적으로 자세히 설명해 빈틈을 쉽게 볼 수 있게 합니다. 이 노트의 나머지는 가장 큰 세 조각을 짚어 갑니다.

KV cache: 긴 컨텍스트를 감당 가능하게 만드는 기억

모델이 프롬프트를 읽으면 토큰과 레이어마다 키와 값을 저장합니다. 이 캐시 덕분에 디코드는 프롬프트 전체를 다시 읽지 않고 다음 토큰을 생성할 수 있습니다. 요청 간에 프리픽스를 재사용하는 것은 서빙에서 가장 큰 비용 레버 중 하나입니다. 긴 시스템 프롬프트, 공유 문서, 여러 턴의 에이전트 이력을 한 번 계산해 여러 번 재사용할 수 있습니다.

단순한 방식 — GPU 메모리에 딕셔너리를 두는 것 — 은 규모가 커지면 무너집니다. GPU 메모리는 수요에 비해 작고, 캐시 항목이 다른 머신에서 필요할 수 있으며, 컴퓨트 노드는 스토리지 노드보다 자주 고장 납니다. DeepSeek의 프로덕션 설계는 세 계층으로 나눕니다.

프로덕션 수치는 문제를 바라보는 방식을 바꿀 만큼 큽니다.

• KV cache용 SSD 약 100 PiB.
• GPU당 논리 KV 약 14.4 TB. 물리 용량은 더 큽니다.
• 8개 GPU당 인터커넥트 약 400 Gbps.
• 10+2 이레이저 코딩을 쓰는 3FS. EC 그룹마다 동시 노드 장애 두 개까지 견딥니다.
• 최대 집계 읽기 약 10 TiB/s, 쓰기 약 850 GiB/s.

로컬 메모리나 계층형 캐시 대신 전용 스토리지 클러스터를 쓰는 이유는 무엇일까요? Q&A에 나온 세 가지 이유입니다.

1. 어떤 프리필 머신이든 어떤 프리픽스에도 적중할 수 있습니다. 캐시가 로컬이라면 라우팅에 프리픽스 선호가 필요해지고, 이는 로드 밸런싱과 충돌합니다.
2. 스토리지와 컴퓨트가 독립적으로 확장됩니다. GPU를 늘리지 않고 캐시 용량을 늘릴 수 있고, 그 반대도 가능합니다.
3. 컴퓨트 장애가 캐시를 잃게 하지 않습니다. DeepSeek에 따르면 컴퓨트 노드는 스토리지 노드보다 한 자릿수 더 자주 고장 납니다.

캐시 적중은 매치, 페치, 스왑인의 세 단계로 이루어집니다. 임계 경로에 있는 것은 매치뿐입니다. 3FS에서 호스트 공유 메모리로 가져오는 페치는 별도 프로세스에서 비동기로 일어나고, 공유 메모리에서 HBM으로의 스왑인은 레이어마다 포워드 연산과 겹쳐 실행됩니다. DeepSeek는 세밀한 KV 블록 복사에 CUDA 복사 엔진이 비효율적이어서 스왑인에 GDR/RDMA를 사용합니다.

이것을 직접 만든다면 프리픽스 매칭, 메타데이터 서비스, 분산 저장소, 축출/TTL, 머신 간 전송, 장애 허용, 그리고 로드 밸런싱과 협력하는 라우팅 정책이 필요합니다. 주말 프로젝트가 아니라 스토리지 팀 하나 분량의 일입니다.

프리필/디코드 분리: 두 워크로드, 두 풀

프리필과 디코드는 병목이 다릅니다. 프리필은 연산 바운드입니다. 프롬프트 토큰을 한꺼번에 많이 처리하며 큰 행렬 곱셈의 이점을 봅니다. 디코드는 메모리 대역폭 바운드입니다. 스텝마다 요청당 토큰 하나를 생성하고 KV cache를 읽습니다. 둘을 같은 풀에 두면 하드웨어, 병렬화, 배치 크기에서 타협이 강제됩니다.

분리는 둘을 별도 풀로 나눕니다.

• 프리필 풀: 8-GPU 머신, EP2–8 / DP2–8, 비캐시 토큰 기준으로 규모 산정.
• 디코드 풀: 64–128 GPU 슈퍼노드, EP64–128 / DP64–128(Wide-EP), 실행 중인 요청 기준으로 규모 산정.
• 비전 인코더: 인스턴스당 GPU 1개, 대개 더 저렴한 카드.
• 스토리지: 컴퓨트와 분리된 전용 KV cache 노드.

DeepSeek는 P:D 비율이 대략 1:1이라고 말하며, 프리필 64개 + 디코드 64개 GPU를 가장 작은 효율적 단위라고 부릅니다. 1P + 1D 구성도 배포는 가능하지만 권장 디코드 배치는 EP64 이상입니다.

어려운 부분은 인계입니다. 요청이 도착해 프리필을 거치고 KV cache를 만든 뒤, 그 캐시를 볼 수 있는 디코드 엔진으로 라우팅되어야 합니다. 이를 위해서는 전송 경로, 캐시 위치를 알려 주는 디렉터리, 캐시 위치와 디코드 부하를 모두 고려하는 라우팅 결정이 필요합니다. DeepSeek는 8개 GPU당 약 400 Gbps 인터커넥트를 배정하고, P와 D가 인접 데이터센터에 있을 수 있다고 언급합니다. 안정성 측면의 비용이 따릅니다.

릴리스는 분리와 관련해 “필요한 엔진 기능 대부분이 이미 구현되어 있다”고 말하지만, 완전한 방식은 포함되어 있지 않습니다. 프로덕션 형태를 원한다면 오케스트레이션 계층을 직접 만드는 것입니다.

로드 밸런싱: 두 차원, 네 개의 밸런서

DeepSeek는 프리필, 디코드, 비전 인코더, 전문가 병렬이라는 네 개의 밸런서를 설명합니다.

프리필 로드 밸런서

요청은 전체 컨텍스트 길이에 따라 네 구간으로 나뉩니다. <16K, 16–64K, 64–256K, ≥256K입니다. 각 구간에 배정되는 엔진 수는 이전 라운드의 연산 할당량 수요에 따라 재분배됩니다. DP 그룹 안에서는 현재 할당량 부하가 가장 낮은 랭크로 요청이 갑니다. GPU 안에서는 요청을 FIFO로 꺼내며, 청크 크기는 적합된 이차 비용 모델을 사용해 시간 예산에서 역산합니다.

프리필 비용은 요청 수에 비례하지 않기 때문에 이 방식은 라운드 로빈보다 정교합니다. 256K 토큰 프롬프트 하나가 짧은 요청 여러 개로 이루어진 배치를 압도할 수 있습니다.

디코드 로드 밸런서

디코드 라우팅은 두 차원의 균형을 맞춥니다. 요청 수(스텝당 배치 크기를 결정)와 전체 KV cache 길이(어텐션 비용을 결정)입니다. 휴리스틱은 짧은 요청을 동시성은 낮지만 KV 길이가 큰 GPU로 보내고, 긴 요청은 KV 길이가 작은 GPU로 보냅니다. 목표는 배치와 어텐션 작업을 모두 균형 있게 유지하는 것입니다.

전문가 병렬 로드 밸런서

EPLB는 중복 전문가를 추가하고 최근 부하를 기준으로 전문가를 GPU에 주기적으로 재배치합니다. DeepSeek는 디코드 moe_lb가 약 1.090이라고 보고합니다. 가장 느린 랭크가 평균보다 약 9% 더 많은 일을 한다는 뜻입니다. 프리필 수치는 영문 Q&A와 중국어 글에서 조금 다르지만 방식은 같습니다.

80% 현실 점검

Q&A에서 가장 유용한 문장은 아마 이것일 것입니다. 프로덕션 로드 밸런싱은 완벽하게 균형 잡힌 오프라인 벤치마크의 약 80%에 도달합니다.

맞춤 밸런서와 스택 전체에 대한 통제력을 갖춘 DeepSeek조차 오프라인 벤치마크 처리량의 약 80%에만 도달한다는 뜻입니다. DeepInfer에 단순한 라우터를 붙인 팀이 더 나은 결과를 기대해서는 안 됩니다. 동시에 오프라인 파레토 차트가 상한이라는 뜻이기도 합니다. 통제된 환경에서 측정한 것이지, 프로덕션 라우팅 편차 아래에서 측정한 것이 아닙니다.

비판이 아닙니다. 보정입니다. 분산 서빙은 지저분하고, 마지막 20%에 엔지니어링의 상당 부분이 있습니다.

직접 구축인가 도입인가

서빙 API가 필요하다면 크게 세 가지 경로가 있습니다.

대부분의 팀에는 첫 번째 경로가 현실적입니다. DeepInfer는 하드웨어, 워크로드, 그리고 서비스 계층을 직접 소유할 엔지니어링 역량을 갖춘 팀을 위한 것입니다. 또는 DeepSeek가 어떻게 하는지 배우고 싶은 엔지니어를 위해서입니다.

돌아가려면 한계 페이지를 보거나, 엔진의 작동 방식을 읽어 보세요.