Redis 창시자가 LLM 추론 엔진을 만든 이유
Redis를 써보셨다면 살바토레 산필리포(Salvatore Sanfilippo)라는 이름을 들어보셨을 거예요. 개발자들 사이에서는 antirez라는 닉네임으로 더 유명하죠. 2009년에 Redis를 만들었고, 2020년에 손을 뗐다가 2024년 말에 Redis로 돌아와서 벡터 검색 기능인 Vector Sets를 만든 개발자인데요. 이분이 이번에 ds4라는 로컬 LLM 추론 엔진을 공개했어요.
추론 엔진은 이미 학습이 끝난 AI 모델 파일을 불러와서, 질문을 넣으면 답을 만들어내는 프로그램이에요. 모델이 레시피라면 추론 엔진은 그 레시피대로 요리하는 주방이라고 보시면 돼요. ChatGPT 같은 서비스는 이 주방이 클라우드에 있는 거고, 로컬 LLM은 주방을 내 컴퓨터에 들여놓는 거예요.
antirez는 최근 몇 년 동안 LLM에 대한 글을 꾸준히 써왔어요. 이미지 생성 모델이나 음성 인식 모델을 다른 라이브러리 없이 순수 C로 구현해서 연달아 공개하기도 했고요. ds4도 그 흐름에서 나온 프로젝트예요.
ds4의 핵심: 한 모델만 제대로 돌리기
이름에서 짐작할 수 있듯이 ds4는 DeepSeek V4 계열 모델을 로컬에서 잘 돌리는 데 초점을 맞춘 엔진이고, 주로 Apple Silicon 맥을 겨냥하고 있어요.
이게 흥미로운 건 기존 로컬 LLM 도구들과 생각하는 방식이 정반대거든요. 대표 주자인 llama.cpp는 수백 가지 모델 구조를 지원하는 범용 엔진이에요. 공개된 모델은 거의 다 돌릴 수 있지만 그만큼 코드가 거대하고, 모델 하나만을 위해 끝까지 최적화하기는 어려워요. ds4는 반대로 한 모델만 제대로 돌리겠다는 전략이에요. 대상이 정해져 있으니 그 모델 구조에 딱 맞는 연산 경로를 짤 수 있고, 코드도 사람이 처음부터 끝까지 읽을 수 있는 크기로 유지할 수 있어요.
DeepSeek 모델의 특징인 MoE(Mixture of Experts, 전문가 혼합) 구조를 알면 왜 최적화할 여지가 큰지 보여요. 모델 안에 '전문가' 역할을 하는 작은 네트워크가 여러 개 있고, 토큰 하나를 처리할 때마다 그중 몇 개만 골라서 일을 시키는 방식이거든요. 큰 병원에 의사가 수백 명 있어도 환자 한 명은 그중 몇 명만 만나는 것과 비슷해요. 전체 파라미터는 엄청나게 많지만 한 번에 실제로 계산하는 건 일부라서, 메모리만 넉넉하면 생각보다 빠르게 돌아가요.
문제는 그 '메모리만 넉넉하면'이라는 조건이에요. 지금 당장 안 쓰는 전문가까지 전부 메모리에 올려둬야 하니까요. 그래서 양자화(quantization)를 써요. 모델 안의 숫자를 16비트 대신 4비트나 2비트처럼 더 적은 비트로 표현해서 용량을 줄이는 기술인데요, 고화질 사진을 JPEG로 압축하는 것과 비슷해요. 너무 세게 압축하면 품질이 떨어지니까 어느 부분을 얼마나 압축할지가 엔진의 실력을 가르는데, 모델 하나만 다루는 엔진은 이 판단을 그 모델 구조에 맞춰 세밀하게 할 수 있어요.
맥을 겨냥한 이유도 메모리에 있어요. Apple Silicon은 통합 메모리(Unified Memory) 구조라서 CPU와 GPU가 같은 메모리를 같이 써요. 일반 PC는 GPU 전용 메모리(VRAM)가 24GB 정도로 제한되는 경우가 많은데, 메모리를 크게 단 맥에서는 그 대부분을 GPU 연산에 쓸 수 있어요. 개인 장비로 거대한 MoE 모델을 돌리려면 지금은 꽤 현실적인 선택지예요.
업계 맥락: 범용이냐 특화냐
로컬 LLM 쪽 도구들을 간단히 정리해볼게요. llama.cpp는 범용성과 이식성에서 가장 앞서 있고, Ollama는 그 위에 쓰기 편한 인터페이스를 얹은 도구예요. Apple은 자체 머신러닝 프레임워크인 MLX로 맥 최적화를 밀고 있고, 서버 쪽에서는 vLLM 같은 엔진이 여러 사용자의 요청을 동시에 처리하는 데 집중하고 있어요.
ds4는 이 중에서 독특한 자리에 있어요. 범용성을 포기하고, 한 모델과 한 플랫폼에서 최대한 잘 돌아가는 걸 목표로 하거든요. 사실 antirez가 Redis 때부터 보여준 스타일이기도 해요. Redis도 처음엔 메모리에 자료구조를 올려놓고 빠르게 다룬다는 단순한 아이디어 하나를 끝까지 다듬어서 나온 결과물이었으니까요.
한국 개발자에게 주는 시사점
먼저 보안 규정 때문에 외부 AI API를 못 쓰는 환경이라면 눈여겨볼 만해요. 금융권, 공공기관, 사내 코드 유출을 걱정하는 회사에서는 데이터가 밖으로 나가지 않는 로컬 모델 말고는 선택지가 없을 때가 많거든요.
다음으로 공부할 교재로서의 가치가 커요. 거대한 프레임워크 코드는 따라가다 길을 잃기 쉬워요. 반면 모델 하나용 엔진은 어텐션 계산이나 전문가 라우팅이 실제 코드로 어떻게 짜여 있는지 한눈에 보여줘요. KV 캐시(앞에서 처리한 토큰의 계산 결과를 저장해두는 메모장 같은 것)도 마찬가지고요. 트랜스포머를 논문으로만 봤다면 이런 코드가 훨씬 잘 와닿을 거예요.
다만 한계도 분명해요. 대형 MoE 모델을 돌리려면 메모리가 아주 넉넉한 장비가 필요하고, 프로젝트도 아직 초기 단계예요. 업무 환경에 바로 넣기보다는 실험용으로 먼저 써보시는 게 좋아요.
마무리
ds4는 여러 모델을 두루 지원하는 대신 한 모델을 제대로 돌리는 쪽을 택했고, 로컬 LLM 엔진이 갈 수 있는 또 다른 방향을 보여줘요.
여러분은 로컬 LLM을 고를 때 범용 도구의 편리함과 특화 엔진의 성능 중 어느 쪽에 더 끌리세요? 회사에서 로컬 모델을 써보신 분이 있다면 어떤 장비로, 어떤 용도로 쓰고 계신지도 궁금해요.
🔗 출처: Hacker News