요약(TL;DR): Full GLM-5.2 (753B MoE)를 Int4-Int8Mix + NVFP4 4-bit KV cache로 양자화(quantized)하고, 4× DGX Spark (GB10)에서 TP=4(Tensor Parallelism=4)로 100K 컨텍스트(context) 환경에서 실행했습니다. 공식 수치와 동일한 에이전트 스캐폴드(agent scaffold, Terminus-2)를 사용하여 Terminal-Bench 2.1에서 구동했습니다. 결과: 63/89 = 70.8%로, 공식 Full-precision 모델의 81.0%와 비교됩니다. 미리 주의사항을 말씀드리자면, 저는 전체 모델을 제 파이프라인으로 실행해 본 적이 없습니다. 약 10포인트의 격차는 양자화(quantization)와 더불어 저의 100K vs 256K 컨텍스트 제한, 더 작은 토큰 예산, 그리고 일치하지 않는 샘플링(sampling)이 결합된 결과입니다. 따라서 제 4-bit/100K 데스크톱 설정은 공식 수치의 약 87% 수준에 도달한다고 이해해 주세요. 실행에는 72.5시간이 소요되었고, 엔진이 두 번 충돌했으며, 한 가지 레시피는 네 개의 노드를 모두 완전히 멈추게(hard-wedged) 만들었습니다 — 자세한 이야기는 아래에 있습니다.

장비 구성: 4× DGX Spark / GB10 (sm_121a, 각 노드당 128 GB 통합 메모리, ~273 GB/s), 100 G RoCE 패브릭(MikroTik CRS504) 상의 ConnectX-7, TP=4. 가중치(Weights): GLM-5.2 Int4-Int8Mix (전문가(experts) 4-bit → Marlin MoE, 어텐션(attention) 8-bit), 디스크 상 약 378 GB. KV 캐시(KV cache): sparse-MLA 경로를 위한 NVFP4 4-bit — 이것이 100K 컨텍스트를 가능하게 합니다 (이 환경에서 fp8 KV는 최대 ~64K까지만 가능). 디코딩(Decode): MTP 투기적 디코딩(speculative decode, 깊이 3) + FULL CUDA graphs → ~27.5 tok/s (eager 모드: ~17–21, 메모리 측면에서 더 안전함). 스택(Stack): sm_121a용으로 재빌드된 vLLM (Triton sparse-MLA + DeepGEMM 바이패스 — upstream DeepGEMM은 sm_121을 거부함), max-num-seqs 2, gmu 0.90.

벤치마크: Harbor + Terminus-2를 통한 Terminal-Bench 2.1 (89개 작업): pass@1, -n 1, 작업당 약 3시간 제한, Tailscale을 통해 저렴한 droplet에서 구동. 작업당 새로운 컨테이너 사용, 다단계 작업(multi-step jobs), 최종 컨테이너 상태로 채점 — 부분 점수 없음.

결과 비교:

솔직히 세부 사항을 말씀드리자면: 70.8% (63/89)가 직접적인 비교 수치입니다. 하네스(harness)가 물리적으로 시작할 수 없는 2개의 작업(qemu-* : "Failed to start tmux session", 재현 가능 — 모델이 시도조차 할 수 없음)을 제외하면

Single pass@1 실행 → 70.8%에 대한 95% 신뢰 구간 (CI)은 대략 ±9% pts (~62–80%)이므로, 격차는 실재하지만 단일 실행 노이즈(single-run noise)를 완전히 벗어난 수준은 아닙니다. "~87% 유지율" (또는 ~89% 클린)은 점 추정치(point estimate)입니다. 81.0%의 출처: Z.ai의 릴리스 블로그에 기재된 Terminus-2 @256K 수치입니다 (그들의 82.7%는 Claude Code를 5회 실행하여 평균을 낸 것으로, 스캐폴딩(scaffold)이 다르며 직접적인 비교 대상이 아닙니다). 격차가 발생하는 원인은 명확히 분리할 수 없습니다: 양자화 (quant) (수백 번의 에이전트 단계에 걸쳐 누적될 가능성이 있는 작은 토큰당 오차 — 가설이며, QA 절제 실험(ablation)은 수행하지 않음), 100K 컨텍스트 제한 (긴 작업 시 강제적인 히스토리 요약 — 모델 성능 저하가 아닌 의도적인 메모리 트레이드오프), 그리고 더 적은 토큰 예산 때문일 수 있습니다. 저의 더 짧은 타임아웃(timeout) 설정은 저에게 불리하게 작용하므로, 이 축은 보수적인 편입니다.

실전 경험담(War stories)

1. 통합 메모리(Unified memory)는 매우 까다롭습니다. "VRAM"은 시스템 RAM입니다: gpu-memory-utilization을 높이면 남은 RAM이 줄어들며, KV 캐시, 활성화 함수(activations), 그리고 OS가 동일한 128 GB를 두고 경쟁합니다. gmu 0.83 설정 시 → "캐시 블록을 위한 사용 가능한 메모리 없음(No available memory for cache blocks)"; 0.90은 작동하지만 약 2~2.5 GB의 여유 메모리만 남깁니다.

2. 클러스터를 마비시킨 레시피. "모든 것을 200K / fp8-KV로 원문 그대로" 시도했던 한 번의 시도가 4개의 노드를 모두 완전히 멈추게 했습니다 — SSH가 먹통이 되어 복구를 위해 전체 전원을 재시작해야 했습니다. 메모리가 제한적인 통합 메모리 박스에서는 참조 레시피(reference recipe)가 단순히 프로세스의 OOM(Out of Memory)을 일으키는 것을 넘어 클러스터 전체를 다운시킬 수 있습니다.

3. 실행 도중 두 번의 엔진 충돌 — OOM이나 NCCL 문제가 아닌, 요청에 의해 트리거된 vLLM 버그였습니다 (scheduler KeyError → EngineDeadError 발생; 이후 RuntimeError: cancelled 발생). 까다로운 점은: rank-0은 죽었지만 3개의 워커(worker)는 각각 약 115 GB를 점유한 채 살아있었다는 것입니다 — 이 상태에서 docker rm -f (SIGKILL)를 사용하면 재시작이 막힙니다. 각 워커에 SIGTERM을 보내고 메모리가 실제로 해제되는 것을 확인한 다음 재시작해야 합니다 (~9분 소요). 하나의 엔드포인트가 죽은 상태에서 제가 첫 번째 충돌을 감지하기 약 1시간 전부터 계속해서 요청이 몰렸습니다.

4. 정직한 수치를 위해서는 오류가 발생한 버킷(errored bucket)을 감사해야 합니다. TB2.1은 "errored"와 "failed"를 구분합니다. extract-elf는 연결 오류(제 시스템의 충돌이지 모델의 문제가 아님)로 인해 errored 처리되었습니다 — 깨끗하게 재실행했을 때 실제로 failed가 발생했습니다 → 모호한 오류가 실제 판정으로 전환된 것입니다. 2개의 qemu-* 오류는 매번 재현되므로 테스트 프레임워크(harness) 문제로 간주하여 제외했습니다.

Harbor의 주의사항: 변경된 설정(config)으로는 재개를 거부하므로, 실행 중인 작업에 -x 옵션을 사용할 수 없습니다. 대신 오류가 발생한 trial 디렉터리들을 삭제하고 원래의 설정으로 재개해야 합니다. 그러면 정확히 해당 부분들만 다시 실행됩니다 (먼저 원본 63/89개를 백업해 두십시오). 한 가지만 기억하세요: 통과율(pass-rate)을 인용하기 전에 '오류(errored)'와 '실패(failed)'를 반드시 구분하여 감사(audit)해야 합니다.

결론(Takeaways):

• 4-bit 양자화된 753B 오픈 웨이트 (open-weight) 모델을 약 4,000달러 상당의 데스크톱 4대에서 실행했을 때, 가장 어려운 에이전트 벤치마크 중 하나에서 공식 전정밀도 (full-precision) 점수의 약 87%(점 추정치, 1회 실행 기준)를 달성했습니다.
• 인프라 장애(Infra failures)는 모델의 실패로 조용히 위장하곤 합니다. 진실은 '오류(errored)' 범주 안에 숨어 있습니다.
• 장시간 방치되는 vLLM 실행에는 자동 재시작 계획과 재시작 전 깨끗한 종료(clean-shutdown) 절차가 필요합니다.

sm_121a 빌드 노트, 실행 스크립트, NVFP4-KV 플래그, 그리고 댓글에 링크된 감사/재실행(audit/re-run) 도구가 포함된 리포지토리(Repo)가 준비되어 있습니다.

/u/anvarazizov가 r/LocalLLaMA에 제출함 [link] [comments]