DSv4F 0731 모델을 High 및 Low 추론 노력(Reasoning efforts, Max는 아님) 수준에서 실행한 저의 에이전트 기반 코딩(Agentic coding) 벤치마크 결과를 공유하고자 합니다... 저는 제가 가장 자주 사용하는 코딩 방식에 기반하여 Aider Polyglot(JS/C++/Python 언어)의 109개 질문 서브셋을 실행했습니다. 이 벤치마크는 하네스(Harness) 내에서 파일 편집 및 디프(Diffs)를 측정하며, 모델에게 작업을 완수할 기회를 두 번 제공합니다. 한 번은 보지 않고 시도하고, 실패할 경우 첫 번째 시도의 결과를 확인한 후 다시 한 번 기회를 얻습니다. 저는 첫 번째 시도 통과율(First try pass rate), 두 번째 시도 통과율(Second try pass rate), 잘 구성된 디프(Well-formed diffs)의 수, 잘못 구성된 디프(Malformed diffs)의 수, 컨텍스트 오버플로(Context overflows, 60k 토큰 제한) 횟수 및 타임아웃(Timeouts, 재시도 포함 1시간 제한)을 추적했습니다 [first image]. 또한 케이스당 초 단위 시간, 프롬프트 토큰(Prompt tokens), 완료 토큰(Completion tokens), 프리필(Prefill) 및 디코드(Decode) 토큰, 그리고 해결된 질문당 킬로토큰(Kilotokens/solved question)을 기준으로 비용을 추적했습니다 [second image]. 마지막으로, 각 모델별 언어에 따른 성공률을 세분화했습니다 [3rd image]. 전반적으로 예상했던 대로, High 설정에서의 Flash가 종합적인 승자였습니다. 하지만 격차가 그리 크지는 않았으며, 그 결과를 얻기 위해 다음으로 우수한 122B 모델보다 5배 이상의 토큰을 더 소비했습니다. 또한, Qwen 모델들이 DS4보다 첫 번째 시도에서 훨씬 더 많은 케이스를 해결했다는 점은 놀라운 발견이었습니다. 전반적으로 122B가 얼마나 잘 수행하는지에 대해 충격을 받았습니다. 저는 베이스(Base) 27B 모델이 벤치마크를 마치기 전에 제가 노인이 되어 죽고 싶지 않았기 때문에, 27B의 훌륭한 ThinkingCap 파인튜닝(Fine-tune) 버전을 사용했습니다. 제가 일상적으로 사용할 모델을 선택하기 위해 수행했던 이전의 코딩 및 지식 벤치마크 실행에서, 27B와 ThinkingCap은 항상 서로의 통계적 오차 범위 내에서 성능을 보였지만, ThinkingCap은 전체 토큰의 20~30%만을 사용하여 동일한 작업을 완료했습니다. 만약 27B가 과도하게 생각(Overthinks)한다고 느껴진다면 이를 사용해 보기를 강력히 추천합니다. 또는, 여유가 된다면 그냥 122B를 실행하십시오. 저의 모든 테스트에서 일관되게 기대 이상의 성능을 보여주었습니다. 설정: M5 Max 128GB, DeepSeek v4 Flash: antirez mixed Q2-Q4 imatrix K-quant, Dwarfstar 추론 엔진(Inference engine).

Qwen3.5-122B: Unsloth Q5_K_XL, llama.cpp [n=4]
Qwen3.6-27B-ThinkingCap: Unsloth Q8_0, llama.cpp [n=4]
Gemma4-31B-QAT: Unsloth Q4_K_XL (QAT 비압축) [n=4]

참고 사항: 제가 DSv4를 위해 사용하는 추론 엔진 (Inference engine)인 Dwarfstar의 현재 빌드에서 추론 노력 (Reasoning effort)을 전달하는 방식에 특이점이 있어, DSv4의 High 및 Low 추론 모드를 모두 실행했습니다. 기본적으로 DeepSeek은 프리뷰 버전과 0731 버전 사이에서 추론 노력의 인코딩을 변경했습니다. 따라서 프리뷰에서 Max 노력을 트리거하기 위해 사용되었던 문자열이 0731 버전에서는 High 노력을 트리거하게 되었고, 새로운 문자열이 Max를 트리거하며, 만약 아무 문자열도 전달되지 않으면 0731 버전은 High 대신 Low 노력을 기본값으로 설정합니다. 현재 Dwarfstar에서 코드를 수정하지 않고 Max 노력을 호출할 방법은 없으며, Low/High의 토큰 사용량을 확인한 후 실제 사용 시에는 Max를 사용할 가능성이 낮다고 판단하여 Max 실행에 필요한 수정을 진행하지 않았습니다. 이미 이 작업에 며칠간의 GPU 시간을 소모한 상태이기도 했습니다...
Aider Polyglot의 JS/C++/Python 세트는 107개가 아니라 109개 질문입니다. 하지만 2개의 질문이 제가 문제를 발견하기 전 여러 실행 과정에서 린터 (Linter) 버그를 유발했습니다. 린터가 빈 에러 메시지를 피드백하면서 제어되지 않는 생성 (Uncontrolled generation)이 발생했습니다. 특히 DS4F는 존재하지 않는 에러를 찾으려다 60k 토큰을 생성했는데, 실행이 멈춘 줄 알고 확인하다가 이 문제를 발견하게 되었습니다. 공정성을 위해 이 2개의 질문은 모든 지표에서 제외했습니다. llama.cpp 모델의 경우, n=4 (4개의 동시 스레드)로 실행했습니다. 이를 통해 벤치마크를 약 2.5배 더 빠르게 완료할 수 있었습니다. Dwarfstar는 이를 허용하지 않으므로, 공정성을 위해 각 모델에 대해 동일한 프롬프트/출력에 대해 전체 디코드 (Aggregate decode)와 단일 스트림 디코드 (Single-stream decode)를 모두 측정하였고, 수치들을 비교 가능하도록 관련 모든 지표를 해당 비율로 조정했습니다.

여러분이 수행한 벤치마크나 비교 결과가 있다면 공유해 주세요! /u/returnity 제출 [링크] [댓글]