284B 모델을 64GB RAM에 넣은 llama-modchip의 조건

284B 모델을 GPU 없이 64GB RAM에서 실행한다. llama-modchip 프로젝트가 내세운 DeepSeek-V4-Flash 실행 사례다. 프로젝트는 압축한 모델과 256K 문맥용 KV 캐시를 RAM에 올리고 스왑 없이 실행했다고 보고한다. 여기에는 모델을 메모리에 넣는 압축과, CPU에서 계산하는 시간을 줄이는 최적화가 함께 쓰였다.

먼저 284B라는 크기를 읽을 필요가 있다. 프로젝트가 다루는 모델은 여러 전문가 중 일부를 골라 계산하는 MoE 구조다. 전체 파라미터는 284.33B지만 토큰 하나를 처리할 때 활성화되는 규모는 13.17B다. 모든 가중치를 보관할 공간은 필요하되, 토큰마다 전체 가중치를 계산하는 구조는 아니라는 뜻이다. 기본 설정은 각 층에서 선택된 라우팅 전문가 6개와 공유 전문가 1개를 계산한다. 전문가 수를 더 줄이는 옵션은 별도로 제공한다.

파일을 줄여 실행 메모리까지 확보한다

출발점은 이미 양자화된 Unsloth UD-IQ1_S 체크포인트다. 가중치 값을 적은 비트로 표현한 이 파일도 76.87GiB(82.5GB)를 차지한다. 프로젝트는 이를 56.56GiB(60.73GB)로 줄였다고 설명한다. GiB와 GB는 용량을 세는 단위가 다르며, 괄호 안팎은 같은 파일 크기를 서로 다른 단위로 표시한 값이다.

파일 크기와 실행 중 메모리 점유도 구별해야 한다. 실행할 때는 가중치 외에 이전 토큰의 계산 정보를 보관하는 KV 캐시와 작업 공간이 필요하다. README가 보고한 256K 문맥 설정의 프로세스 상주 메모리인 VmRSS는 57.61~58.9GiB다. 프로젝트가 말하는 64GB Linux 환경의 무스왑 실행은 이 압축본과 메모리 사용량을 전제로 한다.

압축은 구성 요소마다 다르게 적용한다. 라우팅 전문가에는 주로 IQ1_S라는 저비트 형식을 쓰고, 민감한 일부 층에는 그보다 높은 정밀도를 남긴다. 임베딩과 공유 전문가 등에도 상대적으로 높은 정밀도를 유지하는 한편, 어텐션의 일부 행렬은 Fractal-64 형식으로 바꾼다. 전체 모델을 하나의 정밀도로 바꾸는 대신, 부분마다 다른 표현을 배정해 용량을 줄이는 방식이다.

RAM에 들어간 다음에는 재사용을 늘린다

모델이 메모리에 들어가도 CPU가 데이터를 가져오고 압축 표현을 풀어 계산하는 비용은 남는다. DeepSeek 상세 문서는 입력 프롬프트를 처리할 때 이 비용을 나눠 쓰는 방법을 설명한다. 압축된 가중치 블록을 한 번 풀어 여러 입력 토큰의 계산에 재사용한다. 계산을 캐시에 맞는 작은 묶음으로 배치해 같은 데이터를 반복해서 준비하는 일을 줄인다.

캐시에 무엇을 남길지도 조절한다. 자주 재사용하지 않는 전문가 가중치를 읽을 때, 계속 필요한 KV 캐시 데이터가 CPU의 L3 캐시에서 밀려나는 일을 줄이려는 접근이다. 저장 용량을 줄이는 작업에 더해, 실행 중 데이터가 CPU 가까이에 머무는 방식도 바꾼 셈이다.

속도는 처리 단계별로 봐야 한다. 상세 문서의 측정 장비는 GPU를 사용하지 않은 AMD Ryzen 9 9955HX다. 이 문서에서 Top-6 기본 실행의 단일 토큰 생성 속도는 초당 9.06토큰이다. README는 같은 기본 구성의 생성 속도를 초당 9.06~9.95토큰으로 요약한다.

입력 처리인 prefill은 이미 주어진 토큰을 읽는 단계이고, 생성인 decode는 다음 토큰을 만들어 가는 단계다. 약 44토큰이라는 입력 처리 속도를 답변 생성 속도로 읽어서는 안 된다. Stockfish-PVS는 토큰 후보를 미리 제안하고 검증하는 추가 가속 방식이므로, 이를 사용한 결과도 기본 생성 속도와 구별해야 한다.

여기서 256K는 문맥 창 설정이며, 256K 토큰 전체를 채운 입력의 처리 속도라는 뜻은 아니다. README에는 pp512라는 512토큰 입력 처리 항목이 있고, 상세 문서에는 위 표의 580토큰 입력처럼 실제 길이를 밝힌 측정 사례가 있다. 이 수치들은 해당 장비와 입력 조건에서 프로젝트가 보고한 결과다.

‘Lossless’는 무엇과 같은가

README는 기본 Top-6 실행에 ‘Lossless’라는 이름을 붙이고 출력 유사도를 제시한다. 비교 기준은 같은 56.56GiB Fractal 체크포인트를 패치하지 않은 런타임에서 Top-6로 실행한 결과다. 프로젝트는 이 기준에 대해 로짓 코사인 유사도 1.00000과 KL 발산 0.0000을 보고한다. 즉, 같은 압축본을 실행하는 런타임 최적화가 출력을 보존한다는 주장이다.

이 비교로 76.87GiB 체크포인트를 56.56GiB로 줄이는 과정의 품질 영향까지 판단할 수는 없다. 압축 이전 체크포인트나 원래 모델과의 품질 비교에는 그 대상을 기준으로 한 별도의 평가가 필요하다. 모델이 RAM에 들어간다는 결과, 생성 속도가 빨라졌다는 결과, 원래 모델의 품질을 보존한다는 평가는 각각 비교 조건이 다르다.

실행 도구에도 조건이 붙는다. 이 압축본은 전용 텐서 형식과 패치된 런타임을 요구한다. 프로젝트는 패치되지 않은 llama.cpp, Ollama, LM Studio 바이너리에서는 해당 형식을 인식하지 못한다고 안내한다. llama-modchip이 제시한 284B CPU 실행은 압축 파일과 이를 읽고 계산하는 런타임을 함께 바꿔 얻은 사례다.