From the creator of Redis; run LLM locally with ds4
Redis 창시자가 만든 ds4, 대형 언어 모델을 로컬에서 실행합니다
Redis 창시자 antirez가 고메모리 Mac과 CUDA·ROCm 장비용 C 추론 엔진 DwarfStar 4(ds4)를 공개했습니다. 비대칭 2비트 양자화와 SSD 기반 처리를 활용해 DeepSeek V4 계열 등 일부 대형 MoE 모델을 로컬에서 실행하며, 채팅·API·코딩 에이전트를 한 도구 묶음으로 제공합니다.
- 주제
AI 요약
DwarfStar 4(ds4)는 고메모리 Mac과 CUDA·ROCm 장비에서 대형 언어 모델을 로컬로 실행하도록 만든 C 추론 엔진입니다. DeepSeek V4와 V4.1 Flash, GLM 5.x, Qwen3.8 Flash Next 등 정해진 모델을 지원하며, 텍스트와 비전 모델, 로컬 API, 명령줄 인터페이스(CLI), 지속형 코딩 에이전트를 한 프로젝트에 묶었습니다. MIT 라이선스로 공개했습니다.
메모리를 줄이는 비대칭 양자화
기본 설계는 대형 Mixture-of-Experts(MoE) 모델을 일반적인 원격 서버 대신 고메모리 개인용 장비에서 돌리는 데 초점을 둡니다. ds4는 라우팅되는 전문가(expert) 가중치를 비대칭 2비트로 양자화하고, 중요한 공유 경로는 정밀도를 유지합니다. 프로젝트 설명에 따르면 이 방식으로 지원하는 MoE 모델을 목표 장비 메모리에 맞춥니다.
모델 가중치뿐 아니라 긴 프롬프트 접두부(prefix)를 SSD에 저장하는 기능도 제공합니다. 프롬프트 해시를 기준으로 저장 상태를 다시 불러와, 프로그램을 재시작할 때 전체 입력을 다시 처리하는 과정을 줄이는 방식입니다. 실행 도구는 대화용 ./ds4, 로컬 API 서버용 ./ds4-server, 지속형 코딩 세션용 ./ds4-agent로 나뉩니다.
장비별 실행과 공개 수치
프로젝트는 M5 Max 128GB와 DGX Spark 128GB의 벤치마크를 공개했습니다. M5 Max에서 Q2 모델은 입력 길이 2,048토큰일 때 프리필 790.2토큰/초, 생성 39.4토큰/초를 기록했습니다. 65,536토큰 입력에서는 각각 398.5토큰/초와 27.6토큰/초입니다. DGX Spark에서는 2,048토큰 입력 기준 프리필 825.8토큰/초, 생성 18.1토큰/초를 보였고, 65,536토큰 입력에서는 823.0토큰/초와 13.8토큰/초를 기록했습니다. 벤치마크 표는 해당 수치가 ds4의 측정 결과라고 설명합니다.
설치 과정은 가중치 다운로드, 실행 백엔드에 맞춘 빌드, 모델 실행 순서입니다. 안내문은 V4 Flash Q2를 기본 구성으로 들며, 128GB 장비에서는 GLM 5.3 Q2와 Qwen Q4도 실행할 수 있다고 적었습니다. V4.1 Q2는 SSD에서 스트리밍한다고 설명합니다.
Hacker News 반응
- @doctorpangloss — 문제는 DSV4 체크포인트라서 양자화 품질이 그리 좋지 않다는 점입니다.
- @c0rruptbytes — 제 경험은 다릅니다. ds4 양자화 모델은 아주 좋았고 Unsloth 양자화 모델보다 성능이 나았습니다.
- @dotancohen — 꽤 강한 주장이네요. Unsloth 양자화 모델은 훌륭합니다.
- @ilaksh — 정확히 어떤 모델의 어떤 ds4 체크포인트를 시험하셨나요? 버전과 양자화 단계가 여러 가지 아닌가요?
- @vlowther — 지난 주말에 Qwen 3.8 Flash Next를 M5 Max 128GB MacBook에서 100만 토큰 컨텍스트 길이로 실행하도록 fused TQ를 구현했습니다. 관심 있으면 제 PR을 확인해 보세요. 시간이 나면 oMLX의 Metal 커널도 옮겨 보고 싶습니다. oMLX 0.7.0에서 속도가 크게 올랐습니다.
- @ttoinou — 같은 모델과 장비로 이미 100만 토큰 컨텍스트를 쓰고 있습니다. 이상하네요.
- @vlowther — 네, 제가 한 작업의 대부분은 다른 용도로 메모리를 더 남기려고 fused TQ 지원을 추가한 것입니다.
- @darkwater — 지금 128GB RAM을 넣은 MacBook Pro M5 Max가 7,800유로네요. 말도 안 됩니다.
- @pulkitsh1234 — antirez는 왜 Rust 같은 언어 대신 C를 선택했는지 궁금합니다.
- @GTP — 저자의 개인 취향입니다. Rust를 왜 싫어하는지 설명한 유튜브 영상도 하나 이상 있습니다. 제가 기억하기로는 보안이 중요한 소프트웨어가 아니라면 Rust는 번거롭고 그만한 가치가 없다고 보는 것 같습니다. 동의한다는 뜻은 아니고, 제가 기억하는 입장을 전하는 것입니다.
- @ilaksh — Antirez는 C를 아주 오래 써서 Rust보다 익숙합니다. 프로젝트 목표는 B200 클러스터와 비교해 제한된 장비에서 성능과 기능을 최대한 끌어내는 것입니다. Rust로 여러 플랫폼의 저수준 코드에 잘 접근할 수 있는지, 컴파일러를 만족시키려면 일이 얼마나 늘어나는지, 성능이 목표일 때 그만한 가치가 있는지는 실제로 따져볼 질문입니다.
- @Aeolos — Rust도 SIMD를 포함해 여러 플랫폼의 저수준 코드에 잘 접근합니다. 별칭을 기본적으로 막고, 컴파일 시점에 정확성을 확인하는 멀티스레드 코드 원시 기능도 제공합니다. zlib-rs 같은 프로젝트가 C 구현보다 훨씬 빠른 결과를 낸 사례도 있습니다. 이런 코드에 Rust는 꽤 잘 맞습니다.
- @zozbot234 — 이 프로젝트는 AI가 작성한 코드라는 점도 명시적으로 언급됩니다. Antirez는 학습 데이터에 sendmail 같은 고품질 시스템 코드가 많다는 점을 들어 LLM이 Rust보다 C를 더 잘 쓴다고 주장합니다. Rust의 더 복잡한 문법과 컴파일러 피드백이 LLM 작업에는 오히려 불리하다는 주장도 있습니다. 물론 의견이 갈릴 수 있습니다. C는 간접 참조 같은 부분에서 Rust의 강한 타입 검사를 제공하지 않으므로, 안전성과 정확성을 프로그램 전체 수준에서 보장해야 합니다. LLM은 그런 전역적인 속성을 추론하는 데 약합니다. 모듈 경계를 더 잘 지키도록 다른 문법을 쓰게 하는 편이 실수를 줄일 수 있다는 반론도 있습니다.
- @cuttothechase — 네, AI가 코드를 작성합니다. 하지만 한 번에 뚝딱 만든 것은 아닙니다. 본인이 가장 익숙한 언어로 작업하는 편이 더 쉽지 않을까요?
- @HoldOnAMinute — 다른 LLM 실행 도구와 무엇이 다른가요?
- @pydry — README를 읽고 든 첫 느낌은 차이가 없다는 것입니다. llama.cpp를 분위기 코딩으로 베낀 것처럼 보입니다.
- @ilaksh — 소비자용 AI 장비에서 성능과 코딩·에이전트 사용성을 강조합니다. 모든 모델과 하드웨어를 다루려 하지 않고, 그 장비 범주에 가장 적합한 선택지를 최적화합니다.
- @simonw — 오히려 더 잘 작동할 가능성이 있습니다. 대부분의 LLM 실행 도구는 어떤 모델이든 지원하려 합니다. 그러다 도구 호출이 작동하지 않거나 성능이 기대보다 낮게 설정될 수 있습니다. DwarfStar는 지원 모델을 적게 정하고 그 모델을 잘 지원하는 쪽을 택했습니다.
- @locknitpicker — 무슨 말인지 이해하기 어렵습니다. 기존 실행 도구는 모든 모델을 실행하지만 설정이 잘못될 수 있고, DS4는 모든 모델을 실행하지 못해서 더 낫다는 뜻인가요?
- @simonw — 기본 설정이 더 낫다는 뜻입니다.
- @ttoinou — 자잘한 부분을 많이 처리해 실행이 매끄럽습니다. 예를 들면 ds4-agent는 대화 이력을 다시 쓰지 않고 뒤에만 추가합니다. 그래서 KV 캐시 접두부를 재사용할 수 있습니다.
- @twoodfin — HN 독자에게는 프로젝트 GitHub 페이지가 훨씬 나은 소개 자료입니다.
- @cuttothechase — 도구 호출 성능이 궁금합니다. 사용 수치나 영상이 있나요? GitHub 저장소를 보면 RAM이 아주 많은 Mac 없이도 SSD로 실행할 수 있을 것 같습니다. 초당 50토큰에 가까운 속도가 나온다면 개인용 LLM 분야에 큰 변화가 되겠네요.
- @xlayn — KV를 디스크에 저장해 재개하는 기능을 좋아한다면, 같은 기능을 포함한 제 llama.cpp 브랜치도 있습니다.
- @jasonjmcghee — 제가 마지막으로 llama.cpp를 쓸 때는
llama_state_save_file이나llama_state_seq_save_file, 그리고 불러오기 함수가 있었습니다. 다만 1년쯤 전 이야기입니다.
- @jasonjmcghee — 제가 마지막으로 llama.cpp를 쓸 때는
- @neomantra — 저는 ds4를 공유 라이브러리로 만든 포크를 유지보수합니다. FFI로 다른 언어에서 쓸 수 있고 공개 빌드와 바이너리도 제공합니다. ds4를 바탕으로 yzma에서 영감을 얻은 ds4go를 만들었습니다. 라이브러리 바인딩 외에도 작업공간 보기·편집 도구와 지속성 있는 스크래치패드를 제공하며, Go 함수를 등록해 도구를 만들 수 있습니다. 최근 ds4에 추가된 비전과 Qwen 지원도 넣었습니다.
- @wg0 — Redis 창시자가 AI로 진지한 소프트웨어를 만든다면, 평범한 개발자도 생각을 다시 해봐야 합니다.
- @wg0 — 이런 모델별 추론 엔진을 만들려면 어떤 전문 지식이 필요한가요? 다른 추론 엔진도 모델마다 어떤 부분을 불러올지 큰 switch 문으로 정하나요, 아니면 더 일반적인 구조인가요?
- @epolanski — Antirez는 LLM 작동 원리의 기본을 이해했고 추론 코드를 읽었거나 AI가 정리한 내용을 읽었습니다. 차이를 만든 것은 하드웨어와 시스템 프로그래밍 전반, 그리고 저수준·아키텍처 최적화에 대한 이해였다고 봅니다.
원문: Hacker News / 번역·요약: Trawling