DeepSeek V4.1 Flash를 4x DGX Spark에서 테스트: 나의 수치 vs Wccftech을 통한 Patrick

몇 주 전 Wccftech 기사에서 Patrick Moorhead의 4 Spark 설정을 읽었습니다. 원래는 며칠 전에 올릴 생각이었지만, 추가 테스트를 더 진행했고 이후 작업 스테이션에 커널 및 NVIDIA 드라이버 업데이트 문제가 생겼습니다. 이 게시물 자체가 이미 길기 때문에 그 내용은 다음 글로 다루겠습니다. 처음에는 Patrick Moorhead라는 사람이 이러한 벤치마크를 수행했으며 자신이 설정한 환경에 관심이 있는 줄 알았습니다. 저는 정보가 얼마나 많이 빠져 있는지에 놀랐습니다. 트윗이나 기사 어느 쪽에서도 서빙 엔진(serving engine), 레시피(recipe), 설정(settings) 또는 테스트 프롬프트(test prompts)에 대한 언급이 전혀 없었습니다. 더 나은 용어가 없어 (그리고 이 용어는 정말 싫지만), "스택(stack)"이라고 부를 수밖에 없습니다. 트윗 자체에는 첫 번째 이미지에서 69 t/s가 표시되어 있습니다. 세 번째 이미지는 Hermes 요약 카드이며, 여기에는 최대 494 tok/s와 기사에서 사용된 다른 숫자들만 있을 뿐입니다. 엔진, 레시피 또는 설정에 대한 정보는 전혀 없습니다. 답글에서 Moorhead는 다른 사람(NVIDIA 소속)에게 공을 돌리며 다음과 같이 작성했습니다: "이 설정을 해준 @Picomoorhead에게 찬사를 보냅니다. 전적으로 그 사람 덕분입니다. 제가 자금을 지원했는지 여부는 모르겠습니다." 그것이 무슨 의미인지는 중요하지 않습니다. 저는 정보 부족과 Wccftech 기사에서 잘못 보고된 메모리 요구 사항에 대해 심하게 실망했습니다. "메모리 사용량: 476 GB"라고 나열되어 있지만, 이 476은 디스크 상의 크기(GiB)일 뿐 모델을 실행하는 데 필요한 양이 아닙니다. 저는 그 수치들을 기록하고 제가 가진 4 Spark로 직접 실행하여 재현 가능한지 확인해 보려고 했습니다. 이 과정에서 정말 좌절감을 느낀 몇 가지 "짜증나는" 요소들이 있었습니다. (삶 자체가 저를 무너뜨리던 날들도 있었기에) 글을 쓰기 전에 며칠 동안 기다렸습니다. 저는 그게 다행이라고 생각합니다. 제 비판은 단순히 "실망했다"는 것보다 더 강했습니다. 메모리 문제: DeepSeek-V4.1-Flash 모델은 4x Spark에 편안하게 들어가지 않습니다. 가중치(weights)만 활성화(activations), KV 캐시 등 제외하고도 511 GB입니다. 제 경험상, 메모리 할당량이 0.92를 초과하는 모든 것은 충돌하거나 정지 상태에 빠집니다. 또한 실행 중에도 메모리 사용량은 변동하므로 이러한 변동을 위한 여유 메모리가 필요합니다. 제가 시작했을 때 NVIDIA DGX Spark / GB10 포럼에서 전용 스레드를 찾았습니다.

전체 과정은 여전히 골치 아팠지만, 적어도 knapcio의 레시피 덕분에 시도해 볼 수 있었습니다. 시작할 때 OOM(Out of Memory)이 발생했습니다 (ibv_reg_mr Cannot allocate memory or CUDA OOM). 가중치를 읽는 페이지 캐시가 공유 메모리를 채우고 드라이버가 이를 회수하지 못합니다. 시작 시 캐시를 제거하고 SGLang의 옵션 중 가중치 로드 후 캐시를 삭제하는 기능을 켜세요. NCCL init이 때때로 첫 분 동안 실패하는데, 이는 시작 경쟁(startup race) 문제입니다. 단순히 serve를 다시 실행하면 됩니다. 일종의 경쟁 조건 문제였습니다. 다시 실행하니 1~2번 시도 후에 사라졌습니다. ("껐다가 다시 켜보세요.") 설정 Wccftech 기사에는 '메모리 사용량: 476 GB'가 약 512 GB의 풀링된 메모리에 나열되어 있어, 여유 공간이 있는 것처럼 들립니다. 그렇지 않습니다. 현실적으로 각 Spark에서 메모리의 80%~92%만 사용할 수 있으므로, 512 GB 중 약 410 GB에서 470 GB를 사용하게 되는데, 가중치만으로도 511 GB에 달합니다. 여기서의 476은 디스크 상의 크기를 기준으로 한 실제 GiB입니다. 모델: deepseek-ai/DeepSeek-V4.1-Flash (Hugging Face에서 476 GiB / 디스크에 511 GB). 4x DGX Spark를 100 GbE 네트워크 스위치로 연결하여 사용했습니다. SGLang TP4는 knapcio의 레시피와 DSpark 추측 디코딩(speculative decoding) Engram 테이블(~196 GB)을 각 노드의 로컬 NVMe에서 ~4 GB 행 캐시(Mia / MiaAI-Lab의 행 스토어)를 통해 스트리밍합니다. 그렇지 않으면 모델이 메모리에 들어가지 않습니다. 262K 컨텍스트, 온도 0, 사고 과정 비활성화(thinking off), 256 출력 토큰, 콜드 프롬프트(캐시 미적중). 프롬프트: 맨 앞에 임의의 숫자를 넣고 (모든 프롬프트가 첫 번째 토큰부터 고유하므로 SGLang의 접두사 캐시는 재사용할 수 없음),

제가 튜닝한 빌드는 RoCEnante RDMA all reduce, b12x MoE kernels, EP 1 및 많은 튜닝이 적용된 SGLang dsv4.1 브랜치입니다. 단일 요청의 경우, 디코딩(decode)은 대략 1.4배에서 1.9배 빠르고 프리필(prefill)은 약 1.2배에서 1.6배 빠릅니다 (아래 표 참조). 결과는 프롬프트 크기별(1개 요청 기준)로 정리했습니다.

• **기본값(Base)**은 각 크기별 3회 실행의 중앙값입니다. **튜닝된 값(Tuned)**은 각 크기별 단일 실행 결과입니다. 디코딩 시간은 추측적 디코딩(speculative decoding)이 몇 개의 초안 토큰을 수용하는지에 따라 변동하므로, 특정 행에 너무 의존하지 마십시오. 튜닝된 값이 모든 크기에서 더 빠릅니다. 프리필과 TTFT는 더 안정적입니다.

동시성(Concurrency) (16 슬롯)

Moorhead의 장비 대비 비교 (Vs Moorhead's rig)

제가 재현하지 못한 부분: 1M 컨텍스트, 32 슬롯 및 494 / 280 피크와 ~96 tok/s의 단일 요청 코드

제 실제 코딩 트래픽은 자체 Hermes 에이전트를 통해 처리되며, 중앙값으로 32K 이하에서 0.2초에 근접하고 100 토큰 이상을 처리합니다.

링(Ring) 대 스위치(Switch): 트윗/기사에서 언급된 설정은 링 구조이며, 저의 장비는 QNAP QSW-M7308R-4X를 통해 연결됩니다. 이것이 격차를 설명한다고 생각하지 않습니다.

스위치 호핑은 1 µs보다 훨씬 적게 소요되므로, 메시지당 RDMA 오버헤드에 비하면 작은 수치입니다. 4 노드 링의 경우, 이웃과는 직접적인 200 Gb 링크를 얻지만, 맞은편 노드는 2 호핑 거리에 있어 소프트웨어로 포워딩됩니다. NCCL의 링 올 리듀스(all reduce)는 이웃과만 통신하므로 링 구조에 적합합니다. RoCEnante의 원샷 올 리듀스는 모든 3개 피어에게 쓰기 작업을 수행하므로 부적합할 것입니다. 제 추측으로는 링 대 스위치 구조가 여기서는 크게 중요하지 않은 것 같습니다. AI는 제가 GB와 GiB 혼란을 푸는 데 도움을 주었습니다. Wccftech 기사에서는 디스크에 저장된 크기를 GiB 단위로 사용하면서 이를 GB라고 불렀습니다. 제가 포착한 데이터를 바탕으로 제 수치를 검증했습니다. Hermes + DeepSeek: 벤치마크 모니터링과 실제 코드 개발 작업 수행. 문법, 형식 지정, 관련 없는 것 찾기 및 제거, 그리고 저의 장황함을 줄였습니다. 테스트에 충분히 좋은 프롬프트를 작성하는 것. 많은 설정 문제, 혼란스러운 문서, 그리고 수많은 오류를 해독하는 것. 제 여러 초안을 교정하고 편집하며, 이 게시물을 작성하는 데 4시간이 걸린다고 해서 제가 느리고(그리고 바보가) 아니라는 것을 안심시켜 주었습니다. 전반적인 치료 과정이었고, 제가 우울할 때 격려해주었으며, 제가 느리거나, 바보이거나, 그리고/또는 어리석지 않다는 것을 알려주었습니다. 이 정보가 가치 있기를 바랍니다. 제 ADHD가 사악한 것 대신 좋은 데 쓰였음을 의미할 것입니다 (...대부분은 헛소리입니다.) /u/Aroochacha에 의해 제출됨 [링크] [댓글]