TECH 으로 돌아가기
TECH HACKER NEWS 오늘 8분 읽기 27 READS

DeepSeek이 추론 엔진 'DeepInfer'를 오픈소스로 공개했어요: LLM 서빙 경쟁의 무게가 모델에서 효율로

DeepSeek이 추론 엔진 'DeepInfer'를 오픈소스로 공개했어요: LLM 서빙 경쟁의 무게가 모델에서 효율로
SOURCE IMAGE · HACKER NEWS
DeepSeek이 추론 엔진 'DeepInfer'를 오픈소스로 공개했어요: LLM 서빙 경쟁의 무게가 모델에서 효율로

무슨 일이 있었나요?

DeepSeek이 자사 추론 엔진을 DeepInfer라는 이름으로 GitHub에 공개했어요. DeepSeek 하면 보통 V3나 R1 같은 모델을 먼저 떠올리시죠? 그런데 업계가 DeepSeek을 정말 무섭게 본 이유는 모델 자체보다 그 모델을 엄청 싸게 돌리는 능력이었거든요. 이번에 나온 게 바로 그 능력의 핵심 부품이라서 의미가 커요.

배경을 조금 짚어볼게요. DeepSeek은 2025년 2월 'Open Source Week'라는 이름으로 FlashMLA, DeepEP, DeepGEMM, DualPipe, 3FS 같은 인프라 부품을 하루에 하나씩 공개했어요. 같은 해 4월에는 내부 추론 엔진을 어떻게 공개할지에 대한 글도 올렸는데요. 엔진을 통째로 내놓기보다 vLLM이나 SGLang 같은 기존 오픈소스 프로젝트에 기여하는 쪽으로 가겠다는 내용이었어요. 예전에 vLLM에서 포크한 뒤로 너무 많이 고쳐 쓴 데다 내부 인프라에 단단히 묶여 있어서, 그대로 공개하기는 어렵다는 이유였죠. 그러니까 이번 공개는 부품만 내놓던 회사가 드디어 엔진 전체를 내놨다는 점에서 눈여겨볼 만해요.

추론 엔진이 뭐길래?

이게 뭐냐면, 학습이 끝난 모델 파일(가중치)을 받아서 실제 사용자 요청에 답을 만들어주는 서빙용 런타임이에요. 모델이 레시피라면 추론 엔진은 주방이라고 생각하시면 돼요. 같은 레시피라도 주방 동선이나 화구 개수, 재료 손질 순서에 따라 한 시간에 낼 수 있는 요리 수가 완전히 달라지잖아요.

LLM 추론은 크게 두 단계로 나뉘어요. 먼저 Prefill(프리필) 은 사용자가 보낸 프롬프트 전체를 한 번에 읽어 들이는 단계예요. 계산량이 많아서 GPU의 연산 능력을 꽉 채워 써요. 다음 Decode(디코드) 는 답변을 한 토큰씩 만들어내는 단계인데요, 여기서는 계산보다 메모리에서 데이터를 퍼오는 속도가 병목이에요. 성격이 이렇게 다른 두 작업을 한 GPU에서 섞어 돌리면 서로 발목을 잡게 돼요. 그래서 요즘 대규모 서빙에서는 두 단계를 아예 다른 GPU 그룹에 맡기는 PD 분리(Prefill-Decode Disaggregation) 가 대세고요. DeepSeek은 2025년 초에 공개한 추론 시스템 개요에서 이미 이 구조로 V3와 R1을 서빙하고 있다고 밝혔어요.

DeepSeek 추론 기술을 이해하는 핵심 키워드

저장소의 세부 구성은 README가 가장 정확해요. 그래도 DeepSeek이 그동안 공개해온 기술을 보면 이 엔진을 이해하는 데 필요한 키워드가 몇 개 있어요.

1. MLA(Multi-head Latent Attention): 모델은 앞에서 읽은 내용을 'KV 캐시'라는 형태로 기억해두는데, 대화가 길어질수록 이게 GPU 메모리를 엄청 잡아먹어요. MLA는 이 캐시를 작은 잠재 벡터로 압축해서 저장하는 방식이에요. 덕분에 같은 메모리로 훨씬 많은 요청을 동시에 받을 수 있어요.

2. MoE와 전문가 병렬화: DeepSeek-V3는 파라미터가 6,710억 개지만 토큰 하나를 처리할 때는 370억 개만 써요. 수백 명의 전문가 가운데 몇 명만 불러서 일을 시키는 구조라고 보면 돼요. 문제는 이 전문가들이 여러 GPU, 여러 서버에 흩어져 있다는 거예요. 그래서 GPU끼리 얼마나 효율적으로 통신하느냐가 성능을 좌우하는데, DeepEP가 바로 이 통신을 맡는 라이브러리였어요.

3. 부하 분산과 통신-계산 겹치기: 인기 많은 전문가는 여러 GPU에 복제해서 특정 GPU만 과로하지 않게 해요. 또 요청 묶음을 둘로 쪼개서 한쪽이 데이터를 주고받는 동안 다른 쪽은 계산하게 만들어요. GPU가 멍하니 기다리는 시간을 줄이는 거죠.

이 부품들이 따로 있을 때는 '좋은 건 알겠는데 이걸 어떻게 조립하지?'가 숙제였어요. 엔진 전체가 공개되면 그 조립도까지 볼 수 있다는 게 핵심이에요.

업계 지형에서 보면

오픈소스 LLM 서빙에는 이미 강자들이 있어요. vLLM은 PagedAttention(KV 캐시를 운영체제의 가상 메모리처럼 페이지 단위로 관리하는 기법)으로 사실상 표준이 됐어요. SGLang은 RadixAttention으로, 앞부분이 겹치는 프롬프트끼리 캐시를 재사용하는 데 강하고요. NVIDIA는 TensorRT-LLM과 분산 서빙 프레임워크 Dynamo를 밀고 있고, Red Hat과 구글 등은 쿠버네티스 기반의 llm-d를 만들고 있어요. 문샷AI처럼 KV 캐시 중심의 분산 구조인 Mooncake를 공개한 곳도 있죠.

DeepInfer가 이들과 다른 점은 자기 모델을 실제 대규모 상용 트래픽으로 돌려본 회사가 직접 만든 엔진이라는 거예요. 다만 범용성은 따져봐야 해요. 자사 모델 구조(MLA, 대규모 MoE)와 특정 GPU 환경에 깊게 맞춰져 있을수록 다른 모델이나 하드웨어에서는 이점이 줄어들 수 있거든요.

한국 개발자에게 주는 시사점

솔직히 대부분의 팀은 V3급 초대형 모델을 GPU 수십 장으로 직접 서빙할 일이 없을 거예요. 그래도 이번 공개는 챙겨볼 가치가 충분해요. 사내 LLM 서빙을 운영하고 있다면 PD 분리나 전문가 병렬화, KV 캐시 압축이 실제 코드로 어떻게 구현되는지 볼 수 있는 최고의 교재예요. 지금 쓰는 vLLM이나 SGLang 옵션을 튜닝할 때도 '이 설정이 왜 있는지' 훨씬 깊이 이해하게 될 거예요. GPU 비용이 고민인 스타트업이라면, 같은 하드웨어로 처리량을 끌어올리는 게 곧 원가 경쟁력이라는 점을 다시 확인하는 계기가 될 거고요.

도입을 검토한다면 라이선스, 지원 모델 목록, 필요한 하드웨어, 유지보수 계획은 꼭 저장소에서 직접 확인하세요. 특정 GPU 아키텍처 전용 커널이 많을 수 있고, 큰 회사의 오픈소스라도 공개만 하고 관리는 뜸해지는 경우가 있으니까요.

마무리

한 줄 정리: DeepSeek이 '싸게 잘 돌리는 비법'의 조립도까지 공개하면서, LLM 경쟁의 무게가 모델에서 서빙 효율 쪽으로 더 확실하게 옮겨가고 있어요.

여러분 팀은 지금 어떤 추론 엔진을 쓰고 계신가요? DeepInfer로 갈아탈 이유가 생길지, 아니면 좋은 아이디어만 결국 vLLM이나 SGLang에 흡수될지 의견이 궁금해요!


🔗 출처: Hacker News

SOURCE · HACKER NEWS
원문 전체 보기 → https://github.com/deepseek-ai/DeepInfer
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기 →
처리 중...