128GB Mac에서 341GB DeepSeek 구동: 두 SSD 스트리밍 및 첫 토큰 생성 시간 단축

DeepSeek V4.1 Flash (Q2)는 디스크에 341 GB가 필요합니다. 이는 가중치(weights) 152 GB와 Engram 테이블 189 GB로 구성되어 있습니다. 제 Mac은 M5 Max이며 용량은 128 GB입니다. 그럼에도 불구하고 구동이 가능했는데, ds4가 전문가(experts)를 SSD에서 스트리밍하기 때문입니다. 기존의 ds4는 CLI 환경에서 약 12 tok/s 성능을 보여 사용 가능했습니다. 하지만 저는 SSD가 유일한 병목 지점은 아닐 것 같다는 느낌을 받았고, 코딩 에이전트(coding agent)를 이용해 이를 분석하기 시작했으며, 이것이 제가 계획했던 것보다 더 큰 작업으로 이어졌습니다.

제가 가장 먼저 알아차린 것은 모든 세션이 동일한 방식으로 시작한다는 것이었습니다. 즉, 에이전트가 ds4.c의 거대한 청크(85k 라인, 3개 모델 패밀리, 3개 GPU 백엔드)를 재읽으면서 제 모델이 실제로 어느 2%를 통과하는지 파악하려 했습니다. 읽은 내용 대부분은 제가 소유하지 않은 하드웨어와 구동하지 않는 모델에 관한 것이었습니다. 그래서 저는 그 모든 것을 삭제했습니다. #ifdef가 아니라, 완전히 삭제한 것입니다. ds4.c는 이제 34k 라인이며, 전체 트리는 278k에서 150k로 줄었습니다. 오직 DeepSeek V4.1 Flash만을 대상으로 하고, 오직 Metal만 사용하도록 제한했습니다. 이 변화는 시도하는 것들의 경제성을 바꿨습니다. 예전에는 에이전트가 돌아다니며 오후 시간을 소비하던 최적화 시도가 이제는 고작 몇 시간밖에 걸리지 않아, 제가 믿었던 세 가지 대신 훨씬 더 많은 것을 시도하고 각각을 측정할 수 있게 되었습니다.

하나의 원칙은 계속 유지되었습니다. 출력(output)은 변경되지 않아야 합니다. 모든 변경 사항은 동일한 GGUF (greedy, ten prompts)를 사용하여 상위 버전 ds4와 동일한 토큰을 생성해야 하며, 로짓(logits)을 비트 단위로 비교하여 이전 빌드 대비 A/B/B/A 벤치에 통과해야 했습니다. KV 양자화(KV quant)는 불가하고 근사 커널(approximate kernels)도 사용하지 않았습니다. 더 빠르지만 로짓이 움직인다면, 그것은 적용되지 않았습니다.

결과는 내부 SSD만 사용하고, 동일한 GGUF와 플래그를 유지하며, 상위 버전의 자체 벤치에 대한 비교표로 나타났습니다:

이 모든 것이 영리한 것은 아닙니다. 디코딩 레이어는 서로 기다리지 않고 GPU에 커밋됩니다.

전문가(Expert) 읽기는 스레드 풀에 분산되며 캐시 슬랩은 Metal 거주지 세트(residency set)에 위치합니다. 디코드 토큰당 몇 개의 커널 퓨전이 발생합니다. 프리필(Prefill)은 현재 레이어가 계산하는 동안 다음 레이어의 전문가를 읽습니다. 개별적으로 보면 모두 몇 분 안에 이해할 수 있는 작은 차이점입니다. 하지만 이들을 합치면 속도가 두 배가 되며, 이를 위해 Mac을 그대로 사용하고 추가 구매할 것이 전혀 없습니다. 그러다가 저는 SSD 부분에 대해 궁금해졌습니다. 스트리밍은 읽기 대역폭(read bandwidth)에 의해 제한되는데, Mac에는 내부 드라이브가 단 하나뿐이므로, GGUF의 바이트 단위 복사본을 외부 Thunderbolt 5 SSD에 넣고 모든 레이어의 프리필 읽기 부분을 동시에 각 드라이브에서 수행해 보았습니다. 엔진은 시작할 때마다 이 복사본과 모델을 비교하고(약 7초 소요), 만약 내용이 다르다면 실행을 거부합니다. 왜냐하면 제가 직접 두 개의 341GB 파일을 동기화 상태로 유지하는 것을 신뢰하지 못하기 때문입니다. | | 내부 전용 | + 외부 복사본 | |---|---:|---:| | 3.5K 토큰 프롬프트, 첫 토큰까지 시간 | 13.2초 | 11.2초 | | 10K 토큰 프롬프트 | 29.0초 | 25.0초 | | +1.5K 토큰을 가진 5.3K 채팅 | 8.6초 | 7.0초 | | 8K 컨텍스트 이후 첫 토큰 | 1.38초 | 0.18초 | 디코드는 변하지 않으며, 복사본을 읽지 않습니다. 제가 사용한 인클로저(enclosure)는 드라이브를 PCIe 4.0 x4로 구동하므로, 더 좋은 인클로저라면 이보다 더 나은 성능을 보여줄 것입니다. 좋은 부가 효과도 있습니다: KV 캐시가 외부 드라이브에 쓸 수 있게 되어, 모델이 실행되는 동안 납땜된 내부 SSD는 쓰기 작업이 전혀 발생하지 않습니다. 다시 말하지만, 이 부분은 선택 사항이며, 위의 표가 대부분의 사람들에게 중요한 내용입니다. ds4와 동기화 상태를 유지하는 것에 대해 말씀드리자면, 포크(fork)는 ds4_* 파일을 이름을 변경하지 않으며, 모든 커트는 소스에서 정확한 지점에 표시되어 있고, git merge upstream/main에 rerere를 재생하면 충돌 해결이 이루어집니다. 매번 병합 후 패리티 검사(parity check)를 통해 토큰이 여전히 일치하는지 알려줍니다. 지금까지 antirez의 수정 사항들은 드라마 없이 계속 유입되고 있습니다. 모든 것이 작동한 것은 아닙니다.

저는 두 SSD 트릭을 upstream ds4의 mmap 경로를 통해 비트 단위로 정확하게(bit-exact) 되살리려고 시도했지만, prefill 속도가 13–38% 느려졌고 여전히 그 이유를 모르겠습니다. 그래서 당분간은 PR을 올리지 않기로 했습니다. 스무 개가 넘는 다른 아이디어가 측정되었으나 폐기되었습니다. 저는 이 모든 것을 저장소의 '거절된 아이디어(rejected ideas)' 표에 수치와 함께 보관하고 있습니다. 이는 주로 에이전트(그리고 저 자신)가 몇 주마다 같은 내용을 재제안하는 것을 막기 위함입니다. 단일 모델 추론 엔진(single-model inference engines)이라는 트렌드가 커지고 있으며, ds4 자체가 그렇게 시작되었습니다. 이것은 그 아이디어를 조금 더 발전시킨 것일 뿐이며, 하나의 모델과 하나의 백엔드만 있으면 됩니다. 적어도 여기서는 효과가 있습니다: 빠르고, 여전히 정확하며, upstream에 계속 통합되고 있습니다. 저는 이와 같은 포크(fork)를 네 개 만들었습니다. 각 모델별로 하나씩입니다. 절차는 별도의 저장소(StarForge)에 있으며 DeepSeek이나 Metal과 관련된 내용은 전혀 없습니다. 저장소: github.com/Chida82/sf-ds4-1flash. README와 speed-bench/perf-record.md에는 모든 수치 뒤에 숨겨진 조건들이 있습니다. 몇 가지 의견을 듣고 싶은 부분이 있습니다:

• 'upstream에 통합되는 모델별 포크'가 소수의 포크를 넘어서도 확장성이 있을까요, 아니면 추가 단계만 있는 파편화(fragmentation)일까요?
• 비트 단위 정확도가 적절한 기준일까요? KV 양자화(KV quant)를 거부함으로써 속도를 테이블에 남겨두었습니다. 약간 다른 토큰을 얻기 위해 10% 더 많은 것을 감수하시겠습니까?
• 만약 96–128 GB의 Apple Silicon Mac을 가지고 계시다면, 여러분의 기계에서 기본 ds4와 이 버전을 나란히 비교해 보고 싶습니다. 한 대의 기계는 일화에 불과합니다. /u/Chida82가 제출함 [링크] [댓글]