요약(TL;DR): 저는 매우 다른 두 가지 로컬 환경에서 동일한 89개 태스크의 Terminal-Bench 2.1 스위트를 통해 DeepSeek-V4-Flash를 실행했습니다. 한쪽은 128GB M5 Max MacBook에서 공격적으로 양자화(Quantized)된 80.8 GiB GGUF 모델을 사용했고, 다른 한쪽은 2× DGX Spark에서 DSpark 추측적 디코딩(Speculative decoding)을 적용한 네이티브 혼합 FP8/FP4 체크포인트를 사용했습니다. Mac은 채점된 87개 태스크 중 47개(54%)를 완료했습니다. 두 대의 Spark 설정은 86개 중 45개(52%)를 완료했습니다. 양쪽 모두에서 채점된 86개 태스크 중, 두 설정은 66개에서 일치했으며 나머지 20개는 거의 균등하게 갈렸습니다: Mac 빌드 11승, Spark 빌드 9승. 저는 이것이 2비트 양자화(2-bit quantization)가 공짜라는 것을 증명한다고 생각하지는 않습니다. 이는 단 한 번의 실행이었으며, 깨끗한 양자화 절제 실험(Ablation study)이 아닌 엔드투엔드(End-to-end) 비교였습니다. 하지만 두 설정 사이의 격차가 매우 적다는 점에 놀랐습니다.

두 설정 상세 정보:

네, 두 설정 모두 동일한 DeepSeek-V4-Flash 타겟 모델 계보를 사용합니다. 하지만 스택(Stack)이 동일하지는 않습니다. 양자화, 런타임, KV 형식, 컨텍스트 용량 및 하드웨어가 모두 다릅니다. 또한, Mac 빌드를 단순히 "2비트"라고 부르는 것은 약칭입니다. 대부분의 라우팅된 전문가(Routed-expert) 가중치는 약 2비트이지만, 어텐션(Attention), 공유 전문가(Shared experts), 라우팅 및 기타 민감한 텐서들은 더 높은 정밀도로 유지됩니다. 전체 파일은 가중치당 대략 2.45비트(bits per weight)로 계산됩니다.

실행 내용:
벤치마크는 Terminus-2 에이전트를 사용한 Terminal-Bench 2.1이었습니다.

이 벤치마크는 에이전트가 실제 셸 (shell)을 할당받고, 저장소 복구, 데이터베이스 복구, 확장 기능 컴파일, 데이터 처리, 소규모 모델 학습, 해시 크래킹 (crack hashes) 등 검증기 (verifier)를 통과하는 상태로 환경을 종료해야 하는 89개의 태스크 (tasks)를 포함하고 있습니다. Harbor는 --agent-timeout-multiplier 6 옵션과 재시도 (retries) 기능 (-r 2)을 활성화하여 한 번에 하나의 태스크만 실행 (-n 1)했습니다. 여기서 재시도는 실행 또는 API 실패를 위한 것이며, 이는 pass@2 방식이나 태스크당 두 번의 독립적인 깨끗한 시도를 의미하는 것이 아닙니다. 또한 temperature=0을 강제하지 않았으므로, 이 실행 결과들은 결정론적 (deterministic)이지 않았습니다. 에이전트와 태스크 스위트 (task suite)는 동일했으나, 선언된 입력 제한 (input limit)은 Mac 엔드포인트에서 100K, Spark 엔드포인트에서 200K였습니다. 이는 이 실험을 양자화 (quantization)만을 다룬 통제된 연구가 아니라, 두 개의 완전한 시스템 간의 비교로 취급해야 하는 또 다른 이유입니다.

두 인프라 오류는 양쪽 모두 qemu-alpine-ssh와 qemu-startup으로 동일했습니다. feal-linear-cryptanalysis는 별도의 언급이 필요합니다. Mac 실행에서는 이를 실패로 채점했습니다. Spark 실행에서는 제어되지 않는 생성 (runaway generation)이 발생하여 결국 서비스가 다운되었으므로, 해당 측면에서는 깨끗한 검증 결과가 없습니다. 이 항목은 Mac의 분모인 47/87에는 포함되지만, 아래의 86개 태스크 쌍 비교에서는 당연히 제외됩니다.

| 양측 모두 채점한 86개 태스크에 대한 정면 대결 |
| :--- | :--- | :--- |
| Spark 통과 / Spark 실패 | Mac 통과 | Mac 실패 |
| 36 | 11 | 9 |
| 30 |

66/86개 태스크 (76.7%)에 대해 동일한 판정: 36개는 둘 다 해결, 30개는 둘 다 실패. 20개 태스크에 대해서는 판정이 달랐습니다: Mac 단독 승리는 11개, Spark 단독 승리는 9개였습니다. Mac 단독 승리 사례로는 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 등이 있었습니다. 이러한 불일치에서 명확한 테마를 찾을 수는 없었습니다.

Crypto, PyTorch, 파싱 (parsing) 및 ML 작업들이 양쪽 모두에서 나타납니다. 이 정도로 근소한 차이는 일반적인 에이전트 실행 변동성 (variance)과 일치하지만, 단 한 번의 실행만으로는 변동성이 원인임을 증명하기에 충분하지 않습니다. 통계에 익숙한 분들을 위해 설명하자면: 11 대 9의 불일치에 대해 정확한 대응 쌍 맥네마 검정 (paired McNemar test)을 실시한 결과 p = 0.82 정도가 나옵니다. 쉬운 말로 표현하자면, 이번 실행 결과는 어느 쪽 설정이 더 정확하다는 증거를 제시하지 못합니다. 또한 두 시스템이 진정으로 동등하다는 점을 확립하지도 못합니다. 그러한 더 강력한 주장을 하기에는 샘플 크기가 너무 작습니다.

Spark 쌍이 실제로 제공하는 것
명백한 이점은 속도와 여유 공간 (headroom)입니다. 이 DSpark 프로필에서 짧은 단일 스트림 디코딩 (single-stream decode)은 대략 54~58 tok/s입니다. 동시성 (concurrency) 8 환경에서 총합 약 253 tok/s, 즉 스트림당 약 31.6 tok/s를 측정했습니다. 서버는 262K 컨텍스트 윈도우 (context window)를 제공하지만, 벤치마크 하네스 (benchmark harness)를 200K로 제한했습니다. Mac 설정은 "느리지만 어떻게든 해내는" 버전입니다. 대부분의 전문가 가중치 (expert weights)가 강력하게 압축되어 있고 KV가 디스크에 존재할 수 있기 때문에 모델이 겨우 들어갑니다. 긴 에이전트 세션은 훨씬 덜 쾌적하지만, 최종 작업 점수는 예상보다 훨씬 잘 유지되었습니다. 디스크 상의 용량 감소 또한 4배보다는 2배에 가깝습니다. 네이티브 DSpark 체크포인트가 약 167 GB인 것에 비해 혼합 GGUF는 80.8 GiB였습니다. 여전히 큰 차이지만, 라벨이 시사하는 것처럼 깔끔한 8-bit에서 2-bit로의 산술적 차이는 아닙니다.

누군가 합리적으로 저에게 항의하기 전에 주의사항
이것은 하나의 벤치마크이며, 기본적으로 인프라/API 실패 후 재시도를 포함하여 작업당 하나의 완료된 궤적 (trajectory)뿐입니다. 멀티 시드 (multi-seed) 오차 막대 (error bars)는 없습니다. 두 시스템은 서로 다른 추론 엔진 (inference engines), KV 형식 및 컨텍스트 제한을 사용했습니다. 양자화 (Quantization)가 유일하게 변경된 변수는 아닙니다. 결과는 이진적인 합격/불합격 (pass/fail)입니다. 이는 부분적인 진행 상황, 해결 시간, 출력 품질 또는 실행 과정이 얼마나 고통스러웠는지는 측정하지 않습니다. 투기적 디코딩 (Speculative decoding)은 올바르게 구현될 경우 타겟 모델의 수락된 출력을 보존해야 하지만, 그럼에도 불구하고 서빙 스택 (serving stacks)을 다르게 만듭니다.

여기서의 2% 차이는 관찰된 통과(pass) 횟수가 2회 더 많다는 것을 의미할 뿐, 유의미한 성능 우위를 입증하는 것은 아닙니다. 저의 결론을 조심스럽게 말씀드리자면 다음과 같습니다. 이번 Terminal-Bench 2.1 실행 결과, 한 대의 MacBook에서 실행된 공격적으로 양자화된 (quantized) DeepSeek-V4-Flash GGUF와 두 대의 DGX Spark에서 실행된 네이티브 혼합 정밀도 (mixed-precision) 체크포인트 사이의 작업 해결 능력 차이를 감지할 수 없었습니다. 이는 저에게 이미 상당히 놀라운 결과입니다. 저는 작은 GGUF 모델이 훨씬 더 명확하게 뒤처질 것이라고 예상했습니다. 대신, 고가의 설정은 주로 훨씬 더 나은 서빙 경험을 제공했습니다: 더 높은 속도, 더 높은 동시성 (concurrency), 그리고 더 큰 실질적 컨텍스트 창 (context window)입니다. 만약 제가 지연 시간 (latency)이나 장기 실행 에이전트 (long-running agents)를 중요하게 생각했다면, 언제든 Spark 쌍을 선택했을 것입니다. 만약 저에게 128GB Mac 한 대와 충분한 인내심만 있다면, 심하게 양자화된 빌드는 그 비트 수(bit count)가 보여주는 것보다 훨씬 더 유능합니다. 이것은 더 큰 홈랩 (home-lab) 실험의 일부입니다. 저는 또한 GLM-5.2, MiniMax-M3, Qwen3.6, Hunyuan-3, Ornith 그리고 ternary 27B 모델을 동일한 TB2.1 하네스 (harness)를 통해 테스트하고 있습니다. 관심 있는 분들이 계신다면 작업별 히트맵 (heatmap)과 복잡한 배포 세부 사항을 공유할 수 있습니다. 더 넓은 프로젝트에 사용된 하드웨어: 4× DGX Spark/GX10 노드 (각각 GB10, 128GB 통합 메모리) 및 M5 Max MacBook 1대. 이 비교에는 Spark 2대와 Mac 1대가 사용되었습니다. submitted by /u/anvarazizov [link] [comments]