64GB RAM만으로 GPU 없이 DeepSeek V4 Flash 284B를 실제로 실행할 수 있을까요?

한 커뮤니티 프로젝트에서 64 GB 메모리의 Linux 머신에서 CPU만으로 DeepSeek V4 Flash 284B를 실행했다고 보고했습니다. 보고된 구성은 llama-modchip, 가중치당 약 1.71비트인 맞춤형 체크포인트, 그리고 메모리 대역폭이 상당한 데스크톱 CPU를 사용합니다. 이를 공식 체크포인트의 일반적인 하드웨어 사양 권장 사항이 아니라 특정 빌드를 사용한 문서화된 실험으로 받아들이세요.

이 결과가 유용한 이유는 보통 하나로 뭉뚱그려지는 세 가지 질문을 측정할 수 있게 해주기 때문입니다. 가중치 파일이 들어가는지, 생성 중 프로세스에 충분한 메모리를 확보할 수 있는지, 그리고 압축 수준이 그 정도일 때도 출력이 쓸 만한지 확인할 수 있습니다. 이 프로젝트는 11월 8일 커뮤니티 토론에서 소개되었습니다. 아래 측정값은 독립적인 테스트 결과가 아니라 llama-modchip 유지 관리자의 저장소에서 가져온 것입니다.

어떤 DeepSeek 모델과 런타임을 사용하나요?

이 프로젝트는 설명서에서 전체 매개변수 약 284B, 토큰당 활성 매개변수 약 13B로 소개된 DeepSeek V4 Flash를 대상으로 합니다. 전문가 혼합 모델에서는 라우터가 각 토큰에 사용할 전문가를 선택합니다. 따라서 토큰당 연산량은 제한되지만, 전체 전문가를 저장하고 접근할 수 있어야 합니다. 일반적인 배포 상황은 개발자의 모델 카드와 하드웨어 요구 사항 개요를 참조하세요.

이 실험에서는 특수한 트랜스코딩과 ggml/llama.cpp 생태계용 패치를 사용합니다. 같은 모델 계열을 내세우는 다른 파일이라도 텐서 레이아웃이나 정밀도가 다를 수 있습니다. 표준 llama.cpp 바이너리와 일반적인 GGUF는 별도의 경로로 봐야 합니다. 기존 llama.cpp 업데이트 가이드에서는 업스트림 릴리스 경로를 다룹니다.

2840억 개의 파라미터가 어떻게 64GB RAM에 들어가나요?

가중치당 평균 1.71비트에서 2840억 개의 가중치는 10진수 기준으로 약 61GB의 패킹된 데이터에 해당합니다. 프로젝트에서 보고한 256K 구성의 파일 크기는 56.56GiB, 프로세스 최대 상주 메모리는 57.61GiB입니다. GiB와 GB는 서로 다른 단위입니다. 여유 공간을 파악하려면 테스트 시점의 실제 호스트 가용 메모리를 사용하세요. 펌웨어 예약 메모리, 내장 그래픽 및 기타 프로세스가 얼마 남지 않은 여유 공간의 상당 부분을 차지할 수 있습니다.

상주 메모리와 가중치 파일 크기는 서로 관련된 측정값이지만, 어느 쪽도 시스템의 모든 할당 메모리를 포착하지는 못합니다. 로딩 중 커널이 파일시스템 캐시를 회수하거나 임시 버퍼를 보유할 수 있습니다. 실행 프로세스의 메모리와 시스템의 가용 메모리를 모두 확인하세요. 또한 한 번의 테스트에서 측정된 높은 상주 메모리 사용량만으로 모든 컨텍스트 길이와 입력 유형을 판단할 수는 없습니다.

프롬프트 속도와 생성 속도는 왜 차이가 나나요?

프롬프트 처리는 이미 알고 있는 입력을 다루므로 런타임에서 여러 토큰에 걸쳐 작업을 배치 처리할 수 있습니다. 생성은 순차적으로 이루어집니다. 다음 토큰이 앞서 생성된 토큰에 따라 결정되기 때문입니다. MoE 모델의 CPU 생성 속도는 선택된 전문가 가중치와 상태를 메모리에서 얼마나 빠르게 가져오는지에 민감합니다. 클럭 속도, 메모리 채널 수, 메모리 타이밍, 스레드 배치가 모두 결과를 바꿀 수 있습니다.

짧은 프롬프트 테스트와 긴 저장소 프롬프트를 분리하세요. 첫 토큰까지의 시간과 이후 생성 시간을 따로 측정하세요. 스트리밍이 시작된 뒤에는 반응이 빨라 보여도 더 긴 프리픽스가 전체 지연 시간의 대부분을 차지할 수 있습니다. 런타임이 캐시된 상태를 재사용했는지 기록하세요. 워밍업된 프리픽스와 콜드 실행은 서로 다른 질문에 답합니다. 업스트림 벤치마크 도구 문서에서 프롬프트 및 생성 측정 방법을 확인할 수 있습니다.

이 정밀도에서는 품질이 얼마나 떨어지나요?

가중치당 비트 수는 저장 공간을 요약할 뿐, 모델 품질을 나타내지는 않습니다. 텐서마다 서로 다른 정밀도가 적용될 수 있으며, 크기가 비슷한 두 변환 모델도 다르게 작동할 수 있습니다. 긴 추론, 정확한 구문, 도구 인수, 흔치 않은 어휘를 주의 깊게 확인하세요. 질문 하나에 읽기 쉬운 응답을 한다고 해서 생성이 작동한다는 점은 확인할 수 있습니다. 하지만 같은 빌드가 코딩 작업 흐름에서도 안정적이라는 뜻은 아닙니다.

테스트 전에 소규모 기준 테스트 세트를 선택하세요. 정확한 형식의 출력을 요구하는 작업, 실패 테스트가 알려진 함수, 긴 컨텍스트에서의 정보 검색, 모델이 신중하게 처리해야 하는 요청을 포함하세요. 동일한 프롬프트를 사용해 더 높은 정밀도 또는 더 작은 지원 모델을 기준으로 비교하세요. 테스트 입력을 고정하고 불완전한 출력, 잘못된 도구 호출, 시간 초과를 기록하세요. 나중에 성능이 개선된 원인을 파악할 수 있도록 모델 및 런타임 리비전을 고정하세요.

결과를 책임감 있게 재현하려면 어떻게 해야 할까요?

충분한 SSD 공간이 있고 관리자가 제공한 정확한 체크포인트와 리비전을 갖춘, 격리된 Linux 테스트 머신에서 시작하세요. 프로젝트 빌드 및 빠른 시작 안내를 읽고, 스크립트를 실행하기 전에 살펴보세요. CPU, 메모리 구성, 커널도 기록하세요. 셸 도구를 활성화하지 않은 짧은 프롬프트가 유용한 첫 테스트입니다. 호스트가 계속 원활하게 작동하는지 확인한 뒤에만 컨텍스트를 늘리세요.

1. 로드하기 전에 여유 메모리와 스왑 활동을 측정하세요. 같은 머신에서 실행 중인 다른 부하가 큰 실험은 중지하세요.
2. 체크포인트의 정확한 파일 크기와 해시, 러너 버전, 특별한 트랜스코딩 또는 전문가 배치 설정을 기록하세요.
3. 최대 RSS, 첫 토큰까지 걸린 시간, 초당 출력 토큰 수, 스왑 사용 여부를 기록하세요. 콜드 스타트와 캐시 효과를 구분할 수 있도록 테스트를 두 번 실행하세요.
4. 더 긴 작업에서 모델을 사용하기 전에 출력의 정확성을 비교하세요. 나중에 에이전트를 연결한다면 데이터 노출과 파일 시스템 접근을 확인하세요.

저장소 작업에는 격리된 Git 워크트리를 사용하세요. 호스트가 가정의 저장소나 백업 서비스도 제공한다면, 첫 실험은 별도의 컴퓨팅 머신에서 진행하세요. RAM을 전부 사용하는 추론 프로세스는 메모리 부족으로 종료되기 훨씬 전에 해당 서비스에 지장을 줄 수 있습니다.

더 작은 모델을 선택해야 할 때는 언제인가요?

반복해서 안정적으로 쓸 수 있는 대화형 속도, 간편한 업데이트, 여러 세션을 위한 충분한 여유 공간이 필요하다면 더 작은 체크포인트를 선택하세요. 커뮤니티 실험은 맞춤형 코드와 낮은 정밀도를 감수하면서 신중하게 재현할 수 있을 때 가장 흥미롭습니다. 지원되는 런타임에서 실행되는 일상용 모델은 유지 관리가 더 쉬울 수 있으며 시간당 더 많은 유용한 작업을 완료할 수도 있습니다. 운영 환경을 변경하기 전에 동일한 작업으로 두 모델을 비교하세요.

FAQ

외장 GPU가 필요한가요?

유지 관리자는 지정된 284B 체크포인트를 CPU만으로 실행한 결과를 보고했습니다. 저장소의 다른 구성에는 GPU 지원 방식도 포함되어 있으므로 테스트 프로필을 구분하세요.

64GB PC라면 어떤 제품이든 보고된 속도를 낼 수 있나요?

설치된 메모리 용량만으로 일반적인 속도를 단정할 수는 없습니다. CPU 생성 속도는 메모리 대역폭, 커널, 스레드 배치에 따라 달라지며, 시스템에 사용 가능한 RAM이 충분해야 합니다.

채팅 스트리밍에서 44 tok/s의 속도가 나오나요?

인용된 설정의 약 44 tok/s는 프롬프트 처리 속도를 뜻합니다. 저장소에는 자기회귀 생성 속도가 별도의 더 낮은 범위로 보고되어 있습니다.

처음부터 256K 컨텍스트로 설정해야 하나요?

짧은 컨텍스트부터 시작해 측정하세요. 유지 관리자가 제시한 메모리 수치는 특정 실행기와 체크포인트 구성에 해당합니다.

이 방식이 게시된 하드웨어 가이드를 대체하나요?

표준 배포에는 공식 모델 가이드를 사용하세요. llama-modchip은 정밀도, 호환성, 성능 제약이 따르는 커뮤니티 방식으로 보세요.

결론

흥미로운 결과는 특정 CPU 런타임과 맞춤형 저비트 체크포인트를 사용하면 메모리 예산이 빠듯한 상황에서도 예상보다 큰 MoE 모델을 구동할 수 있다는 점입니다. 정확한 빌드를 재현하고, 프리필과 디코딩을 구분하며, 결과 품질을 테스트한 다음 사용하세요. 일상적인 지연 시간을 평가할 때는 더 작은 모델을 유용한 비교 대상으로 활용할 수 있습니다.