MacBook 1대 vs DGX Spark 2대: DeepSeek-V4-Flash의 Terminal-Bench 2.1 결과는 54% 대 52%

테스트 내용

벤치마크는 Terminal-Bench 2.1에 Terminus-2 에이전트를 사용함. 에이전트가 실제 셸 환경에서 리포지토리 복구, 데이터베이스 복구, 확장 모듈 컴파일, 데이터 처리, 소형 모델 학습, 해시 크래킹 같은 89개 작업을 수행하고 검증기를 통과해야 함.

Harbor로 한 번에 하나씩(-n 1) 돌렸고, --agent-timeout-multiplier 6 옵션에 재시도(-r 2)를 켰음. 재시도는 실행이나 API 오류 때문이지, pass@2나 독립적인 두 번의 시도를 의미하는 건 아님. temperature=0으로 고정하지도 않아서 결과가 결정론적이지도 않음.

에이전트랑 작업 세트는 같았지만, 입력 제한은 맥북이 100K, Spark가 200K였음. 이것도 양자화만 비교한 게 아니라 시스템 전체를 비교한 걸로 봐야 하는 이유임.

결과

인프라 오류는 양쪽 다 qemu-alpine-ssh랑 qemu-startup으로 똑같이 발생함.

feal-linear-cryptanalysis는 따로 언급할 게 있음. 맥북에서는 실패로 떴는데, Spark에서는 생성 루프가 돌면서 서비스가 뻗어버림. 그래서 Spark 쪽은 깔끔한 검증 결과가 없음. 맥북의 47/87 분모에는 포함되지만, 아래에 나올 86개 작업 비교에서는 당연히 빠짐.

86개 작업 맞대결 결과

• 66/86개 작업(76.7%) 결과 동일: 둘 다 성공 36개, 둘 다 실패 30개.
• 20개 작업에서 결과 갈림: 맥북만 성공 11개, Spark만 성공 9개.

맥북만 성공한 것 중에는 feal-differential-cryptanalysis, torch-tensor-parallelism, build-cython-ext, code-from-image, kv-store-grpc 등이 있었음.

Spark만 성공한 것 중에는 schemelike-metacircular-eval, sam-cell-seg, extract-elf, mailman, regex-log 등이 있었음.

딱히 어떤 유형이 더 잘 풀린다는 경향성은 안 보임. 암호학, PyTorch, 파싱, ML 작업들이 양쪽 다 섞여 있거든. 이 정도 차이면 그냥 에이전트 돌릴 때 나오는 일반적인 오차 범위 수준인데, 한 번 돌린 걸로 오차 때문이라고 단정 짓기는 좀 부족함.

통계적으로 따져보면, 11대 9로 갈린 걸 맥니마 검정(McNemar test) 돌려보면 p = 0.82 정도 나옴. 쉽게 말해서, 이번 테스트 결과로는 어느 쪽이 더 정확하다고 말할 근거가 전혀 없음. 그렇다고 둘이 완전히 똑같다는 걸 증명한 것도 아님. 표본이 너무 적어서 그런 결론을 내리기엔 무리가 있음.

Spark 환경을 쓰는 이유

확실한 장점은 속도랑 여유 공간임.

이 DSpark 프로필에서 짧은 단일 스트림 디코딩은 대략 54–58 tok/s 정도 나옴. 동시성 8로 돌렸을 때는 합쳐서 253 tok/s, 즉 스트림당 31.6 tok/s 정도 측정됨. 서버는 262K 컨텍스트 윈도우를 지원하는데, 벤치마크는 200K로 제한해서 돌렸음.

맥 설정은 "느리긴 한데 어쨌든 돌아는 가는" 버전임. 모델이 돌아가는 이유는 전문가 가중치 대부분을 빡세게 압축했고 KV 캐시를 디스크에 박아놨기 때문임. 에이전트 세션을 길게 돌리면 확실히 쾌적함은 떨어지는데, 최종 작업 점수는 생각보다 훨씬 잘 나옴.

디스크 용량 절감 효과도 4배가 아니라 2배에 가까움: 네이티브 DSpark 체크포인트는 대략 167GB인데, 혼합 GGUF는 80.8GiB 정도임. 여전히 차이는 크지만, 라벨에 적힌 8비트에서 2비트로 줄어드는 산술적인 수치만큼 깔끔하게 떨어지진 않음.

누가 뭐라 하기 전에 미리 깔아두는 주의사항

• 이건 벤치마크 하나 돌린 거고, 작업당 사실상 궤적 하나씩만 뽑은 거임. 인프라나 API 터졌을 때 재시도한 거 빼고는 없음. 멀티 시드 오차 범위 같은 거 없음.
• 두 시스템은 추론 엔진, KV 포맷, 컨텍스트 제한이 다름. 양자화만 바뀐 게 아님.
• 결과는 그냥 성공/실패 이분법임. 부분적인 진척도, 해결 시간, 출력 품질, 얼마나 고통받았는지는 측정 안 함.
• 추측 디코딩(Speculative decoding)은 제대로 구현만 되면 타겟 모델의 출력값을 그대로 유지해야 하지만, 어쨌든 서빙 스택이 달라지는 건 맞음.
• 여기서 2% 포인트 차이는 그냥 두 번 더 성공했다는 뜻이지, 압도적인 성능 차이를 증명하는 건 아님.

내 결론

조심스럽게 말하자면:

이번 Terminal-Bench 2.1 테스트에서, 맥북 한 대에서 빡세게 양자화한 DeepSeek-V4-Flash GGUF랑 DGX Spark 두 대에서 돌린 네이티브 혼합 정밀도 체크포인트 사이에 작업 해결 능력 차이는 딱히 못 느꼈음.

이것만 해도 나한테는 꽤 충격적인 결과임. 쪼끄만 GGUF가 훨씬 더 처참하게 깨질 줄 알았거든. 오히려 비싼 장비는 서빙 환경을 훨씬 쾌적하게 만들어주는 게 주 목적이었음. 속도 빠르고, 동시성 높고, 실질적인 컨텍스트 윈도우도 더 크고.

지연 시간이나 장기 실행 에이전트가 중요하다면 무조건 Spark 두 대 쓸 거임. 근데 128GB 맥북 한 대밖에 없고 인내심만 충분하다면, 빡세게 양자화한 빌드도 비트 수치로 보이는 것보다 훨씬 쓸만함.

이건 더 큰 홈랩 프로젝트의 일부임. 지금 GLM-5.2, MiniMax-M3, Qwen3.6, Hunyuan-3, Ornith, 그리고 3진법 27B 모델도 똑같은 TB2.1 하네스에 돌리고 있음. 다들 관심 있으면 작업별 히트맵이랑 개판인 배포 세부 사항도 공유해드림.

이번 프로젝트에 쓴 하드웨어: 4× DGX Spark/GX10 노드(각각 GB10, 128GB 통합 메모리)랑 M5 Max 맥북 한 대. 이 비교에는 Spark 두 대랑 맥북 한 대 썼음.