DeepInfer란 무엇인가? DeepSeek의 추론 엔진, 그리고 그것이 공개하지 않은 부분들

DeepInfer는 DeepSeek가 2026년 10월 16일 Apache-2.0 라이선스로 공개한 추론 프레임워크이며, 단 하나의 모델인 DeepSeek-V4.1-Flash만을 서빙합니다. 기본 체크포인트는 DeepSeek-V4.1-Flash-1017입니다. 이러한 단일 모델 범위는 가장 먼저 이해해야 할 점인데, 그것이 이 저장소에 관한 거의 모든 다른 것들을 설명해 주기 때문입니다. 이것은 우연히 DeepSeek 구성을 포함하게 된 범용 서빙 프레임워크가 아닙니다. 이것은 DeepSeek가 프로덕션에서 실행하는 코드 경로에서 일반화되는 부분만 남기도록 축소한 것이며, 그 축소에 대해 솔직하게 밝히고 있습니다. README 자체에 나열된, 완전한 추론 서비스에 필요한 것들과 이 릴리스에 포함되지 않은 것들에는 KV 캐시 시스템, VE/Prefill/Decode 분리, 데이터 병렬 레플리카 간 로드 밸런싱이 언급되어 있습니다. 여러분이 얻는 것은 컴퓨트 경로, 즉 커널, 병렬화, 추측 디코딩, 스케줄링, 구조화된 출력입니다. 얻지 못하는 것은 컴퓨트 경로를 대규모에서 저렴하게 운영할 수 있게 해주는 스토리지 및 라우팅 계층입니다. DeepSeek는 그 이유를 밝힙니다. 해당 컴포넌트들은 내부 인프라와 긴밀하게 결합되어 있어 설계는 공개된 글에서 설명되지만 코드는 사내에 남아 있습니다.

저장소에 실제로 무엇이 들어 있나요?

공개된 기능 목록은 대규모 전문가 혼합(MoE) 모델을 서빙할 때의 병목 지점들을 둘러보는 듯하다. DeepSeek가 이전에 공개한 커널 라이브러리들—어텐션용 FlashMLA, 행렬 곱셈용 DeepGEMM, 전문가 병렬 통신용 DeepEP, 그리고 TileKernels와 DeepSelect—이 있다. 병렬화 방식도 있다: 어텐션은 균형 잡힌 컨텍스트 병렬 처리를 갖춘 데이터 병렬 처리로 실행되고, MoE 부분은 전문가 병렬 로드 밸런서를 갖춘 전문가 병렬 처리로 실행된다. 고정된 길이가 아니라 스케줄되는 검증 길이를 사용하는 추측 디코딩 스택인 DSpark가 있다. 슬라이딩 윈도 어텐션 캐시가 캐시 미스마다 전체 재계산을 강제하지 않도록 하는 메커니즘인 SWA 바운디드 리플레이가 있다. 비동기 배치 스케줄링, 결정론적 샘플링을 사용하는 배치 불변 추론, 그리고 정규식, JSON 스키마 또는 EBNF로 제약된 구조화 출력이 있다.

진입점은 의도적으로 작습니다. DEEPINFER_ACCELERATOR를 nvidia 또는 Ascend에 해당하는 값으로 설정하고 build.sh를 실행하면, 저장소에는 examples/offline_inference.py가 포함되어 있으며, 이는 기본 체크포인트를 엔드 투 엔드로 실행합니다. DEEPINFER_HF_MODEL_DIR는 다른 가중치 디렉터리를 가리키게 합니다. 공개된 벤치마크는 프리필에 SM100 GPU 4개, 디코드에 SM100 GPU 64개에서 측정되었는데, 이는 이 엔진이 염두에 두고 작성된 배포 규모이며, 노트북에서 돌리는 데모가 아닙니다.

README는 코드의 출처도 밝히고 있는데, 이는 코드를 읽기 전에 알아두면 좋은 정보입니다. 이 엔진은 원래 주로 vLLM을 기반으로 구축되었고, 설계 영감은 SGLang과 TensorRT-LLM에서 얻었습니다. 그 계보는 구조에 그대로 드러납니다 — 스케줄러, paged attention 인터페이스, 샘플링 경로는 해당 프로젝트들을 읽어본 사람이라면 익숙하게 느낄 것이며 — 이 릴리스가 처음부터 작성된 아키텍처가 아니라 서빙 스택의 포크인 이유도 설명해 줍니다. DeepSeek가 추가한 것은 자사 모델에 특화된 부분입니다: 분리형 배포, 밸런서를 갖춘 와이드 전문가 병렬 처리, 슬라이딩 윈도우 재생, 그리고 DSpark입니다.

그것이 담고 있지 않은 것, 그리고 그것이 더 중요한 이유

빠진 세 가지는 사소한 누락이 아닙니다. 각각은 엔진이 프로덕션 트래픽을 처리하기 전에 반드시 존재해야 하는 시스템이며, 저마다 다른 방식으로 비용이 많이 듭니다.

• KV 캐시 시스템. 접두사 재사용은 채팅 워크로드에서 비용 절감 효과가 가장 큰 부분입니다. 캐시 적중이 프리필을 대체하기 때문입니다. 캐시 저장소가 없으면 모든 요청이 프롬프트를 다시 계산합니다. DeepSeek의 자체 문서는 사용하는 저장소를 설명합니다. 바로 로컬 호스트 메모리가 아닌 전용 3FS 클러스터로, 어떤 프리필 머신이든 어떤 접두사에든 적중할 수 있고 캐시 용량을 컴퓨팅과 독립적으로 확장할 수 있도록 하기 위해서입니다.

• VE/Prefill/Decode 분리. README에서는 엔진 측 기능 대부분이 이미 릴리스에 존재하며, 빠진 것은 배포라고 언급합니다. 비전 인코더, 프리필, 디코드를 분리하면 각 단계를 자체 병목에 맞춰 크기를 조정하고, 최초 토큰까지의 시간을 토큰 간 시간과 별도로 제어할 수 있습니다. 이는 플래그가 아니라 인프라 결정입니다.

• 데이터 병렬 복제본 전반의 로드 밸런싱. DeepSeek는 프리필, 디코드, 비전 인코더, 전문가 병렬의 네 가지 밸런서를 운영하며, 네 가지 모두를 문서에서 설명한다. 라우팅 로직은 전혀 공개되지 않는다. 그것 없이는 복제본 플릿이 앞단에 놓는 라우터만큼만 성능을 내며, 단순한 라운드 로빈 라우터는 스토어가 보호하려고 구축된 캐시 적중률을 망칠 것이다.

함께 읽어 보면, 이 누락은 이것이 어떤 종류의 산출물인지 알려줍니다. DeepInfer는 연산 경로의 참조 구현으로, 커널과 스케줄링 작업을 검토하고 재사용할 수 있도록 공개된 것이지, 설치해서 트래픽을 연결하는 배포판이 아닙니다.

진짜 필터는 하드웨어 게이트다

DeepInfer는 NVIDIA SM100과 Huawei Ascend 950을 대상으로 합니다. Ampere 경로도 Hopper 경로도 없어서, 오늘날 대부분 클러스터에 있는 대부분의 GPU가 제외됩니다. 나머지 툴체인도 마찬가지로 특정되어 있습니다. Linux 전용이며 GCC 13 이상, Python 3.12, NVIDIA용 CUDA 13 또는 Ascend용 CANN 9.2가 필요합니다. 그리고 공개된 릴리스가 전혀 없습니다. 2026년 10월 21일에 해당 저장소를 확인했을 당시 게시된 릴리스가 0개였으므로, 다운로드할 것도 고정할 것도 없습니다. 저장소를 클론한 뒤 자신의 툴체인에 맞춰 빌드해야 합니다.

그런 조합은 이만큼 많은 주목을 받는 오픈소스 릴리스에서는 이례적인 일이며, 이를 간과가 아니라 범위에 대한 정확한 설명으로 읽는 것이 가장 좋습니다. 저장소의 커널은 특정 명령어 집합과 특정 인터커넥트를 위해 작성되었고, README의 수치는 그 하드웨어에서 나온 것입니다. 연산 경로를 한 세대 아래로 포팅하는 일은 커뮤니티는 빠르게 해내지만 엔지니어링 조직은 약속할 수 없는 바로 그런 종류의 작업입니다. 릴리스 후 며칠 안에 구형 NVIDIA 부품을 대상으로 한 서드파티 포팅이 GitHub에 나타났는데, 이는 수요에 대한 유용한 신호이지만 공개된 처리량 수치가 그 포팅에서도 유지되는지에 대해서는 전혀 신호가 되지 않습니다.

DeepSeek가 실제로 운영하는 배포 형태

아키텍처 설명문은 저장소의 가정이 명확히 드러나는 곳이다. 시스템은 비전 인코더, prefill 및 decode, 그리고 전용 스토리지 노드로 분리된다. Prefill은 2~8의 expert parallelism과 이에 맞는 data parallelism을 사용하며, HBM이 허용하는 가장 작은 구성을 선택한다. Decode는 반대다. expert parallelism과 data parallelism을 64~128로 사용하는데, DeepSeek는 이를 Wide-EP라고 부르며, 사용 가능한 GPU가 허용하는 가장 큰 구성을 사용한다. Tensor parallelism과 context parallelism은 전혀 사용되지 않는다. 비전 인코더는 인스턴스당 GPU 하나로 실행되며, 더 저렴한 GPU를 권장한다. 인코더는 비용이 많이 드는 부분이 아니기 때문이다.

해당 수치에서 도출되는 가장 작은 합리적 배포 구성은 다음과 같다. 프리필 GPU 1개와 디코드 GPU 1개가 실행되며, 실제로 두 풀 사이의 비율은 대략 1대1이다. 그러나 디코드가 전문가 병렬 이점을 얻으려면 GPU 64개 이상이 필요하므로, 가장 작은 효율적 단위는 프리필 GPU 64개에 디코드 GPU 64개를 더한 구성이다. DeepInfer의 효율성에 관한 어떤 주장을 읽을 때도 이 수치를 기억해야 한다. 해당 수치들은 128-GPU 배포를 설명하며, 그 절반이 하나의 단계에 해당한다.

prefill과 decode를 여러 데이터 센터에 나누어 배치하는 것은 기술적으로 가능하다. DeepSeek-V4.1-Flash가 KV cache를 상당히 압축하기 때문이며, DeepSeek 자체 배포에서도 추론 노드를 서로 다르지만 인접한 데이터 센터에 둔다. 예산은 8개 GPU당 약 400 Gbps의 interconnect이고, 이 글은 신뢰성 비용에 대해 솔직하다 — 건물 사이의 광섬유는 끊기기 쉽다.

왜 decode가 이렇게 넓게 퍼져 있나요?

광범위한 전문가 병렬성은 설계에서 가장 중대한 선택이며, 이를 단순한 스케일링 기법으로 오해하기 쉽다. 전문가 혼합(mixture-of-experts) 계층에서는 각 토큰이 소수의 전문가에만 닿으므로, 디코드 단계의 비용은 산술 집약도보다는 전문가 가중치와 활성값을 이동시키는 데서 대부분 발생한다. 전문가를 64개 또는 128개의 GPU에 분산하면 각 GPU가 기여하는 단계당 메모리 트래픽이 줄어들고, 이는 전문가 전반의 부하가 균등하게 유지될 경우에만 초당 토큰 수를 높인다. 바로 이 조건을 위해 전문가 병렬 부하 분산기가 존재한다.

DeepSeek의 설정은 그대로 복사할 수 있을 만큼 구체적이다. 프리필의 경우 각 GPU는 자신이 소유한 전문가 외에 네 개의 중복 전문가를 보유하고, 통계는 100스텝 윈도에 걸쳐 수집되며, 전문가는 1,000스텝마다 재할당되고, 가중치는 NVLink 공유 메모리를 통해 그룹 내에서 섞인다. 측정된 불균형—가장 느린 랭크를 평균으로 나눈 값—은 EP4/DP4 구성에서 1.074, EP2/DP2에서 1.045로 나타났다. 디코드의 경우 설정이 더 넓게 늘어난다. GPU당 중복 전문가 하나, 1,000스텝 통계 윈도, 10,000스텝마다 재할당, 그리고 측정된 불균형 1.090이다. 둘 사이의 차이가 핵심이다. 프리필은 버스트가 많고 이질적인 작업을 보므로 빠른 재균형이 필요하다. 디코드는 꾸준한 스트림을 보므로 긴 윈도를 감당할 수 있어, 드물게 재균형하고 그 대가로 거의 비용을 치르지 않는다.

라우팅 측도 같은 성격을 지닌다. Prefill 요청은 전체 컨텍스트 길이에 따라 16K 미만, 16~64K, 64~256K, 256K 이상의 네 계층으로 버킷화되며, 엔진은 이전 라운드에서 각 계층이 차지한 컴퓨트 수요 비중에 따라 계층에 할당된다. GPU 내부에서 각 prefill 단계의 청크 크기는 고정되지 않는다. 피팅된 이차 비용 모델이 주어진 시퀀스 토큰 수와 이미 계산된 프리픽스를 바탕으로 한 단계가 얼마나 걸릴지 예측하고, 스케줄러는 남은 시간 안에 32,768토큰 예산에 맞는 가장 큰 청크를 구한다. Decode 밸런서는 요청 수와 총 KV 캐시 길이라는 두 차원을 동시에 균형 잡으며, 짧은 요청은 동시성이 낮고 캐시가 긴 GPU로, 긴 요청은 캐시가 작은 GPU로 보낸다. 이 모든 것이 얼마나 많은 이득을 주는지에 대한 DeepSeek 자체의 요약은 완벽하게 균형 잡힌 오프라인 벤치마크의 약 80퍼센트다.

캐시, 그리고 사흘에 걸친 질문

KV 캐시는 로컬 호스트 메모리가 아니라 전용 3FS 클러스터에 상주하며, 이 결정이 나머지 스토리지 설계를 이끈다. 데이터는 10+2 이레이저 코딩으로 저장되므로 각 코딩 그룹은 두 노드의 동시 장애를 견딘다. 읽기는 그룹 내 11개 노드 모두에 요청을 보내며, 10개 응답만으로도 디코딩할 수 있다. 가비지 컬렉션 워커는 모든 스토리지 노드에서 실행되며 워터마크를 넘으면 LRU 기준으로 제거한다. 권장 서버는 30.73TB 솔리드 스테이트 드라이브 20개를 갖추고 최소 40GB/s의 읽기와 5GB/s의 쓰기를 지속하며, 서버당 약 24시간 분량의 데이터를 보존하도록 크기가 산정된다. 실제로 클러스터는 온라인 GPU당 약 14.4TB의 논리 캐시로 운영되며, 물리 용량은 그보다 크다.

상주(residency)는 트레이드오프가 가시화되는 지점이다. 캐시 측에는 만료 로직이 없다. TTL은 스토리지 측에서 설정되며, 약 100페타바이트의 솔리드스테이트 스토리지를 보유한 클러스터에서 에이전트 트래픽은 3일, 챗봇 트래픽은 7일로 설정된다. 이 분리가 존재하는 이유는 챗봇 트래픽의 적중 롱테일이 훨씬 더 두껍기 때문이다. 소량의 캐시가 여러 번 반복해서 읽히므로, 이를 잃으면 그 양이 시사하는 것보다 전체 적중률에 더 큰 손실이 발생한다. DeepSeek가 챗봇 보존 기간을 3일로 줄였을 때 측정한 비용은 캐시 적중률의 0.5~1%였다. 이는 작은 숫자지만, 실상은 대량의 재계산된 프리필을 나타낸다.

슬라이딩 윈도 어텐션은 다른 규칙이 적용되는 별도 캐시를 사용합니다. SWA 캐시는 페이징 블록에 들어가지 않으며, 각 시퀀스는 호스트 메모리에서 고정 크기 슬롯 하나를 차지하고, DeepSeek-V4.1-Flash의 경우 저장되는 레이어는 처음 20개입니다. 해당 영역만 유지됩니다. 즉 20개 레이어 × 134개 토큰 × 528바이트로, MXFP8 형식에서 시퀀스당 1,415,040바이트입니다. 스토리지 클러스터로는 아무것도 전송되지 않고, 이를 생성한 머신의 메모리에 남아 있으며, 어느 머신이 무엇을 보관하는지 기록하는 인메모리 디렉터리가 있고, 머신 간 히트가 발생하면 400 Gbps VLAN을 통해 다시 가져옵니다.

헤드라인 수치를 만들어내는 두 가지 메커니즘

바운디드 리플레이는 두 방식 중 더 흥미로운데, 무한한 비용을 상수로 만들기 때문입니다. 일반적으로 슬라이딩 윈도 캐시 미스는 윈도를 처음부터 다시 계산해야 하며, 비용은 컨텍스트 길이와 레이어 수에 따라 증가합니다. DeepSeek은 대신 가장 최근 128개 토큰만 다시 계산하고 어텐션 윈도를 해당 세그먼트로 잘라내어, 고정된 비용으로 근사 SWA 캐시를 생성합니다. 인코더 측에서 이는 프리픽스 캐시 적중 길이를 SWA 캐시와 완전히 분리합니다. SWA 캐시가 없으면 적중 프리픽스의 마지막 128개 토큰이 재실행되고 블록 캐시는 그대로 재사용됩니다.

디코더 쪽이 절감 효과가 큰 곳이다. 이 아키텍처에서는 디코더 레이어의 블록 캐시가 마지막 인코더 레이어의 은닉 상태에서 투영되므로, 레이어별로 계산해야 하는 것은 디코더 SWA 캐시뿐이다. 그리고 이를 정확히 재구성하려면 매 프리필마다 마지막 2,560개 토큰을 20개 디코더 레이어에 통과시켜야 한다. 대신 128개 토큰을 재생하고, 그 결과를 프리픽스 캐시에 들어가게 하지 않고 디코드에만 사용하면 총 프리필 연산량이 거의 절반으로 줄어든다. 이 단일 변경은 대부분의 커널 최적화보다 가치가 크며, 모델 아키텍처를 직접 소유한 팀만 할 수 있는 종류의 일이다.

DSpark의 기여는 더 작고 더 일반적입니다. 드래프트 토큰은 요청과 위치에 따라 수락 확률이 다르므로, 단계마다 고정된 다섯 개의 드래프트를 검증하는 것은 거부될 토큰에 연산을 낭비하는 일입니다. 신뢰도 헤드는 각 드래프트 토큰의 수락률을 예측하고, 스케줄러는 드래프트를 기대 수익 기준으로 정렬한 뒤 처리량을 최대화하는 접두사만 검증합니다. 프로덕션에서 드래프트 모델은 여전히 단계마다 다섯 개의 토큰을 생성하며, 검증되는 수는 5.00에서 3.2~4.4로 줄어 약 30퍼센트 감소하지만 수락 길이는 거의 변하지 않습니다 — 3.29 대 3.20입니다. EP64/DP64 벤치마크 데이터를 보면, 이는 랭크당 약 60개의 동시 시퀀스에서 처리량이 4~7퍼센트 더 높아지는 것으로 계산됩니다. 정확히 60일 때 랭크당 처리량은 초당 13,730개에서 14,466개 토큰으로 증가합니다. 약 16개의 동시 시퀀스 미만에서는 이 기법이 약간의 순손실이므로, 저트래픽 배포에 채택하기 전에 알아 둘 가치가 있습니다.

155조라는 수치가 의미하는 것

이번 릴리스와 관련해 가장 많이 인용되는 숫자는 단일 클러스터가 하루 155조 토큰을 처리하며, 밸리 프라이싱 기준 GPU-hour당 총매출 미화 38달러를 기록한다는 것입니다. 두 수치 모두 벤더가 보고한 것이고, 어느 쪽도 재현 가능한 벤치마크가 아닙니다. 그렇다고 해서 흥미롭지 않은 것은 아닙니다 — GPU-hour당 매출 수치는 처리량 수치와는 정말로 다른 종류의 주장인데, 활용률, 가격 책정, 캐시 적중률을 한 줄로 합쳐 보여주기 때문입니다. 또한 이 수치는 한정 조건 없이 인용될 가능성이 가장 높은 수치이므로, 그 한정 조건을 적어 둘 만합니다: 단일 클러스터, 밸리 프라이싱, 비용이 아닌 매출, 그리고 프리필, 디코드, 비전 인코더 전반에 걸친 집계.

더 작은 두 가지 공개 정보가 더 직접적으로 유용하다. 공개 저장소의 FlashMLA 디코딩 커널에는 내부 버전에 있는 수작업으로 튜닝된 어셈블리 최적화 하나가 빠져 있어, 단독 실행 시 5~10퍼센트 더 느리다. 그리고 DeepSeek은 엔드투엔드 성능 차이는 최대 5퍼센트라고 밝힌다. 또한 추측 디코딩용 내부 드래프트 모델은 공개된 것보다 최신이며, 성능 차이는 작다고 설명된다. 두 설명 모두 제3자가 코드를 복사해 공개된 성능 중 얼마나 달성할 수 있는지에 대한 기대치를 제시하며, 답은 하드웨어가 일치한다면 대부분이다.

현재 상태 그대로의 저장소

위 캡처는 2026년 10월 21일에 만들어졌으며 페이지에는 16.3k개의 스타가 표시되어 있습니다. 같은 날 조회한 GitHub API는 16,590개의 스타, 1,649개의 포크, 176개의 열린 이슈를 반환했고, 이슈 기능은 비활성화되어 있으며 토론은 대신 GitHub Discussions로 연결되어 있었습니다. 스타 수는 그 이후로 계속 증가해 왔으므로, 여기 있는 모든 수치는 코드의 속성이라기보다 타임스탬프로 읽어야 합니다. 일주일도 안 되어 발생한 그런 규모의 트래픽은 코드의 준비도보다 DeepSeek의 서빙 스택에 대한 관심을 더 많이 말해주며, 릴리스가 0이라는 점이 나머지를 설명합니다.

직접 실행해 볼 생각이라면

솔직히 요약하면 DeepInfer는 꼼꼼히 읽어볼 가치는 있지만 운영하기는 어렵습니다. 네 가지 질문을 통해 그것이 적합한지 알 수 있습니다.

• SM100 또는 Ascend 950이 있으신가요? 툴체인의 나머지 모든 것은 이 하나에서 비롯됩니다. 적합한 가속기가 없으면 공개된 수치는 그대로 적용되지 않으며, 커뮤니티 포팅은 프로덕션 규모에서 검증되지 않은 상태입니다.

• 하나의 통신 도메인에서 64개의 디코드 GPU를 실행할 수 있나요? 광범위한 전문가 병렬화는 건너뛸 수 있는 최적화가 아니라, 디코드 경로가 설계 기준으로 삼은 구성입니다. 그 규모 아래에서는 같은 이름을 가진 다른 시스템을 실행하고 있는 것입니다.

• 이미 프리픽스 캐시를 보유하고 계신가요? 그렇지 않다면, DeepInfer의 연산 경로를 프리픽스 캐시가 기본 제공되는 경쟁 스택과 비교하고 계신 것이며, 그 비교 결과는 설계가 마땅히 받아야 할 것보다 나쁘게 보일 것입니다.

• 라우팅 계층을 직접 작성할 여유가 있나요? 프리필 버킷팅, 디코드 밸런싱, expert 재할당은 재구현할 수 있을 만큼 충분히 자세히 설명되어 있으며, 이를 재구현하는 데는 저장소가 대신 처리해 주지 않는 몇 주간의 작업이 필요합니다.

위의 어느 것도 소유하고 싶지 않으시다면

대부분의 팀에게 실질적인 질문은 DeepSeek-V4.1-Flash를 어떻게 배포하느냐가 아니라 어디서 호출하느냐입니다. 이 모델은 128-GPU 클러스터를 구축하거나 로드 밸런서를 다시 구현하지 않고도 호환 API를 통해 사용할 수 있으며, 이 글에서 설명해 온 아키텍처와 동일한 모델입니다 — 동일한 컨텍스트 처리, 동일한 구조화 출력 동작을 디스어그리게이션 작업 없이 제공합니다.

비교해야 할 것은 추상적으로 어느 엔진이 더 빠른가가 아닙니다. 공개된 수치는 대부분의 독자가 갖고 있지 않은 하드웨어에서 공급업체가 보고한 측정치이기 때문입니다. 비교해야 할 것은 해당 워크로드가 3일 캐시 TTL과 64-GPU 디코드 풀이 가격을 바꾸는 유형인지, 아니면 API를 통해 몇 초마다 요청하는 편이 위에서 설명한 어떤 운영보다 단순히 더 저렴한 유형인지입니다. 두 번째 경우 — 대부분의 경우입니다 — 사용해야 할 DeepInfer의 적정량은 없음이고, 읽어야 할 적정량은 전부입니다. 시작하려면 DeepSeek V4.1 Flash 모델 페이지에서 엔드포인트를 확인하고, 엔드포인트가 무엇을 하는지 알고 싶다면 저장소의 README부터 시작하세요.