antirez가 만든 DeepSeek V4 Flash 전용 로컬 추론 엔진 ds4

• Redis 만든 antirez가 DeepSeek V4 Flash 전용 로컬 추론 엔진 ds4를 공개함

  • 프로젝트 이름은 DrawfStar 4이고, 코드는 GitHub에 올라와 있음
  • 범용 GGUF 러너도 아니고, 다른 런타임 래퍼도 아니고, 프레임워크도 아님
  • 목표는 딱 하나임. DeepSeek V4 Flash를 로컬 고사양 머신에서 “그럭저럭 실행”이 아니라 “에이전트까지 붙여 쓸 만하게” 만드는 것

• 왜 굳이 DeepSeek V4 Flash 하나에 꽂혔냐면, 작성자는 이 모델이 로컬 추론용으로 특이하게 좋다고 봄

  • 활성 파라미터가 적어서 더 빠르다고 설명함
  • thinking mode에서도 생각 구간이 다른 모델보다 훨씬 짧고, 많은 경우 1/5 수준이라고 주장함
  • 컨텍스트 윈도는 100만 토큰
  • 284B 파라미터급이라 27B·35B급 dense 모델보다 지식 범위가 넓고, 영어와 이탈리아어 품질도 “준 프론티어 모델”처럼 느껴진다고 평가함

• 하드웨어 타깃도 명확함. 96GB·128GB 메모리급 맥북이나 Mac Studio, 또는 로컬 CUDA 머신임

  • 2비트 양자화 모델은 128GB RAM 맥북에서 돌릴 수 있고, 사용자 제보로는 96GB에서도 25만 토큰 컨텍스트까지 돌아간 사례가 있다고 함
  • 4비트 양자화는 256GB 이상 메모리급 머신을 권장함
  • 전체 100만 토큰 컨텍스트는 압축 인덱서만 약 22GB, 전체로는 약 26GB 메모리를 더 먹는다고 설명함

• 2비트 양자화가 꽤 공격적인데, 무작정 다 줄이는 방식은 아님

  • routed MoE 전문가 부분만 양자화함
  • up/gate는 IQ2_XXS, down은 Q2_K를 쓰고, shared experts·projection·routing 같은 부분은 품질 보존을 위해 그대로 둠
  • 작성자는 이 2비트 quant가 농담 수준이 아니라 코딩 에이전트에서 도구 호출도 안정적으로 된다고 주장함

• KV cache를 디스크에 올리는 관점이 이 프로젝트의 큰 포인트임

  • 보통 긴 컨텍스트 LLM에서 KV cache는 RAM을 잡아먹는 골칫거리인데, ds4는 DeepSeek V4의 압축 KV와 최신 SSD를 전제로 “KV cache는 디스크의 1급 시민”이라고 봄
  • 서버 실행 예시는 --kv-disk-dir /tmp/ds4-kv --kv-disk-space-mb 8192처럼 디스크 캐시를 켜는 흐름을 기본 사용법처럼 제시함
  • 캐시 파일은 렌더링된 프롬프트 prefix의 SHA1을 키로 쓰고, 토큰 ID와 그래프 상태까지 함께 저장함

sequenceDiagram
    participant 클라이언트
    participant 서버
    participant 렌더러
    participant 캐시
    participant 모델
    클라이언트->>서버: 대화 기록과 도구 결과 전송
    서버->>렌더러: OpenAI/Anthropic 형식 렌더링 요청
    렌더러->>캐시: 저장된 prefix와 도구 ID 조회
    캐시-->>렌더러: KV 체크포인트와 DSML 원문 반환
    렌더러->>모델: byte-for-byte로 맞춘 프롬프트 전달
    모델-->>서버: 이어서 생성 또는 도구 호출 반환

• ds4-server는 로컬 에이전트 붙이는 걸 꽤 진지하게 다룸

  • OpenAI 호환 엔드포인트로 /v1/chat/completions, /v1/completions, /v1/models를 제공함
  • Anthropic 호환 /v1/messages도 제공해서 Claude Code류 클라이언트 연결을 염두에 둠
  • SSE streaming, thinking stream, tool call streaming까지 지원한다고 되어 있음

• 도구 호출 처리에서 가장 집요한 부분은 “정확한 재현”임

  • DeepSeek V4 Flash는 도구 호출을 DSML 텍스트로 내보냄
  • 그런데 에이전트 클라이언트는 다음 요청에서 그 텍스트를 그대로 돌려주는 게 아니라 OpenAI·Anthropic JSON 객체로 정규화해서 보냄
  • 서버가 이 JSON을 조금이라도 다르게 렌더링하면 기존 KV checkpoint의 byte prefix와 어긋나고, 결국 긴 prefix를 처음부터 다시 prefill해야 함

• 그래서 ds4-server는 tool id -> 모델이 실제 샘플링한 DSML block을 기억함

  • 도구 호출마다 추측 불가능한 API tool ID를 붙임
  • 다음 요청에서 같은 ID가 오면 JSON을 새로 포맷하지 않고, 예전에 모델이 뱉은 DSML 바이트를 그대로 재사용함
  • 이 맵은 메모리에만 있는 게 아니라 KV cache 파일에도 저장될 수 있어서 서버 재시작 뒤에도 재현 가능성을 높임

• 빌드 경로는 macOS Metal과 Linux CUDA가 메인이고, CPU는 디버그·정확성 확인용임

  • macOS는 make로 Metal 빌드
  • Linux CUDA는 make cuda-spark 또는 make cuda-generic
  • CPU-only는 make cpu지만, macOS CPU 경로는 현재 가상 메모리 버그로 커널 크래시가 날 수 있다고 경고함. 표현이 꽤 antirez답게 거칠다

• 테스트와 검증도 “공식 구현과 맞는가” 쪽에 초점을 둠

  • 공식 DeepSeek V4 Flash API에서 얻은 continuation vector와 로컬 결과를 비교함
  • greedy decoding, thinking disabled, top logprobs를 이용해 토큰 바이트 단위 회귀를 잡음
  • make test, ./ds4_test --logprob-vectors, ./ds4_test --server 같은 C runner 기반 테스트가 있음

• 이 프로젝트는 alpha 품질이라고 분명히 선을 긋고 있음

  • 공개된 지 며칠 안 된 코드이고, 안정화까지는 몇 달 걸릴 수 있다고 말함
  • 문제가 생기면 --trace로 세션 로그를 남겨 이슈에 포함하라고 안내함
  • 그래도 방향은 선명함. “새 모델이 나올 때마다 따라가는 로컬 추론”이 아니라, “한 모델을 로컬에서 완성된 제품처럼 쓰게 만들기”임

기술 맥락

• ds4가 범용 GGUF 러너를 포기한 이유는 검증 범위를 좁히기 위해서예요. 아무 모델이나 읽게 만들면 기능은 넓어지지만, long context와 tool calling, logits 검증까지 끝까지 맞추기가 훨씬 어려워지거든요.

• KV cache를 디스크에 저장하는 선택은 RAM이 병목이라는 현실에서 나온 거예요. DeepSeek V4 Flash 자체도 크고 2비트 quant만 해도 81GB급이라, 100만 토큰 컨텍스트까지 RAM에 밀어 넣는 건 개인 장비에선 꽤 빡세요.

• 도구 호출을 byte-for-byte로 재현하려는 것도 에이전트 워크플로 때문에 중요해요. 클라이언트는 매 요청마다 전체 대화 기록을 다시 보내는데, 서버가 이전 도구 호출을 다르게 렌더링하면 저장해 둔 KV prefix를 못 쓰고 긴 프롬프트를 다시 계산해야 하거든요.

• Metal과 CUDA를 메인 경로로 둔 건 “로컬에서 실제로 쓸 수 있는 속도”를 맞추려는 선택이에요. CPU 경로는 모델·토크나이저·정확성 진단에는 쓸 수 있지만, 284B급 MoE 모델을 실사용 속도로 굴리는 경로는 아니에요.