ds4.c(DwarfStar 4) + Deepseek-v4.1-flash 사용기
ds4.c 가 Deepseek 모델 외에도 Glm, Qwen 다양한 모델을 지원하기 시작하면서 부터는 기존에 같이 사용하던 omlx, llama.cpp, mlx-ml등 다른 추론엔진들은 전부 제거하고 ds4.c 하나만 local llm에 사용중입니다.
앞서 다른 글에서도 언급한적 있지만 Deepseek v4 flash 0731와 Dspark가 적용된 뒤로는 ds4.c에 남은 아쉬움 이라고는 모델 자체가 vision을 지원하지 않는다는 것, 별도로 나온 Deepseek v4 vision의 경우 기본적인 지능이 0731과 차이가 나서 코딩 작업에 사용하기 좀 아쉬웠다?
그래서 Qwen 3.8이 나온 뒤로는 Qwen 3.8 27b 모델을 llama.cpp 에 물려서 vision 전용의 서브에이전트로 구성해서 이미지 분석이 필요한 작업은 llama.cpp의 Qwen 3.8 27b 모델을 사용하도록 해서 쓰다가 .. ds4.c에 Qwen 지원이 추가 되면서는 llama.cpp 도 안쓰게 되긴 했습니다.
그런 와중에 Deepseek v4.1 flash가 출시되고 ds4.c에도 Deepseek v4.1 flash를 지원하게 되었습니다...만!!
2주 가까이 ds4.c 에서 Deepseek v4.1 flash를 사용해온 후기? 결론?을 간단히 작성해 보겠습니다.
우선 Deepseek v4.1 flash 모델은 기존 모델 대비 파라미터수가 거의 2배 커진 모델입니다. 비대칭 구성으로 입력, 출력시 사용되는 파라미터가 조금 다르고 MoE 모델이고 구조도 조금 변경되어서 정확히 v4 대비 얼마나 커졌다? 라고 말하긴 애매합니다만.
일단 Deepseek 에서 기존 Pro 자체도 flash 모델인 v4.1 flash로 교체해서 제공하겠다 할 정도로 하극상 제대로한 모델이기도 합니다.
개이적으로 Deepseek 의 API 서비스도 종종 사용하던 입장으론 v4 대비해서 v4.1 flash가 좀더 좋은 결과를 만들어 주는건 사실이어서 ds4.c 에서 Deepseek v4.1 flash사용도 매우 기대를 했습니다.
결론적으로 말씀 드리자면..
현재로써는 ds4c + Deepseek v4.1 flash 사용은 저는 포기합니다.
우선 DSpark 적용 전에 초기 Deepseek v4 flash 의 디코딩 속도는 1M 컨텍스트 기준 30% 이상 컨텍스트가 체워진 상태 기준으로 디코딩 15~19tps 선에서 동작 했습니다. 0731 모델 출시 후에 DSpark 적용후에는 같은 상황에서 25~35tps 사이로 DSpark 적용 전 대비 10~15tps 정도 개선된 속도를 보여줬고 기존 Deepseek v4 flash 대비 0731은 안그래도 쓸만 했던 놈이 더욱 더 쓸만해진 그런 느낌? ㅎㅎ
Deepseek v4.1 flash 의 경우도 DSpark를 지원하는 모델이지만 변겨된 구조를 적용하는데 시간이 걸리는 건지 몰라도 아직 ds4.c에 Deepseek v4.1 flash 에 대한 DSpark 사용은 아직 적용 전입니다. ds4.c 의 DSpark 가 아닌 mtp는 솔직히 없느니만 못한 놈이라 언급할 필요조차 없을 것 같구요.. DSpark 적용 전의 속도는 평균 15~18tps 정도 선으로 모델 크기가 엄청나게 커졌음에도 기본적인 속도는 v4 flash 초기와 비슷한 정도 속도가 나옵니다.
DSpark 적용되면 0731과 비슷한 속도가 나와주지 않을까? 라고 기대를 해봣습니다만.
현재로썬 ds4.c + deepseek v4.1 flash의 사용을 포기하려는 이유는 512gb 라는 넉넉한 메모리라 DeepSeek-V4.1-Flash-Q4.gguf 를 사용중인데 자체 gguf 포맷을 사용하는 ds4.c의 특성이고 모델 파일은 추후에도 새로 양자화 해서 제공될 가능성이 있긴 하겠습니다만, 양자화 과정에서의 문제인지 아직 v4.1관련 커널수정이 필요한건진 몰라도..
ds4.c 에서 Deepseek v4.1 flash Q4 모델은 정도의 차이는 있지만 Qwen 3.6의 MoE 모델 같이 컨텍스트가 어느정도 쌓이거나 조금 복잡한 추론이 들어가는 경우 Thinking 과정에서 계속 같은 추론을 반복하는 추론 무한루프에 빠지는 경우가 생깁니다.
개인적으로 ds4.c 를 찬양하고 애정하고 적극적으로 사용하게된 이유가 현실적으로 LocalLLM사용시 가장 쉽게 접근하는 Qwen 계열 모델들의 무한 추론 문제에 지쳐서 많은 고민과 시간을 허비하고 살아오다 감내할 만한 수준의 속도와 지능, Opencode 같은 cli와 붙였을때 대형 코드베이스에 복잡한 추론을 떠념겨도 느릴지언정 툴사용을 비롯해서 작업을 완료 하기 까지 그 어떠한 사용자의 개입 없이 작업을 끝내는 모델+추론엔진을 처음 만나 봐서인데 ..
아무리 vision이 가능하다 해도 .. 이런 오류 상황이 발생 된다면.. 전 못씁니다 ㅎㅎ
그리고 사실 이미지 분석은 정말 가끔 일어나는 일이라 굳이 기존에 코딩의 범주에서는 충분히 잘 사용하던 Deepseek v4 flash 0731이 있는데 굳이 조금 더 나은 지능을 위해 v4.1 flash를 쓸 이유가 없네요.
전 같이 이미지 분석을 실시간으로 동시에 해야 한다면 llama.cpp를 추가로 설치해도 될거고 아니면 ds4.c 를 조금 손봐서 동시에 다수의 실행이 가능하게 해서 qwen 3.8 flash next와 v4 flash 0731을 ds4.c로 둘다 돌려 놓고 쓰기에도 충분한 메모리를 가졌으니.. 오래 고민하지 않으려고 합니다.
향후 antirez가 Deepseek-v4.1-flash 모델의 양자화를 새로 하고 dspark 를 적용해서 업데이트를 해준다면 다시 테스트는 해보긴 하겠지만 실 사용은 기존과 같이 Deepseek v4 flash 0731모델을 사용하도록 하겠습니다.
맥에서 ds4.c와 deepseek 모델을 사용하고 계시거나 사용하려 하시는 경우 참고하세요.