llama-modchip v2.4.0: 64GB CPU 전용 머신에서 284B DeepSeek MoE 실행하기

llama-modchip v2.4.0은 패치된 llama.cpp 포크로, 64GB CPU 전용 머신에서 284.33B 파라미터의 DeepSeek-V4-Flash mixture-of-experts 모델을 GPU 없이 256K 컨텍스트와 약 9–15 tokens/s 속도로 완전히 RAM에서 실행한다고 주장합니다. 이 프로젝트의 핵심 주장은 표준 IQ2_XXS GGUF가 76.87 GiB인 모델(64GB Linux 박스에서 메모리 부족으로 크래시)을 디스크에서 56.56 GiB, 상주 메모리 약 57.61–58.9 GiB로 줄였다는 것입니다. Hacker News 토론(387점, 172개 댓글)은 엔지니어링에 감탄하는 사람들과 2비트급 모델을 실행할 가치가 있는지 회의적인 사람들로 sharply 나뉘었습니다.

llama-modchip v2.4.0이 한다고 주장하는 것

llama-modchip은 통합 CLI(./modchip)와 llama.cpp에 대한 패치 세트로 배포됩니다. 광고된 세 가지 핵심 기능은 64GB CPU 박스에서의 284B 프론티어 MoE, 순수 CPU에서 GPU급 속도로 실행되는 30B MoE, 그리고 API 없는 Claude Code 통합입니다.

프로젝트 자체 요약 표는 하드웨어를 권장 모델에 매핑합니다:

머신	RAM	권장 모델	주장 속도 (GPU 0개)
개발자 노트북 / 미니 PC	16–32 GB	Nemotron-3.5-30B-A3B (14.35 GiB)	25.0–60.4 tok/s
64GB 데스크톱 / 서버	64 GB	DeepSeek-V4-Flash 284B (56.56 GiB)	44.4 tok/s prefill, 9.1–14.7 tok/s decode
하이브리드 데스크톱 (CPU + 16GB GPU)	32–64 GB	Nemotron-30B / Qwen3-30B	80.80 tok/s
8채널 워크스테이션 (Threadripper)	128 GB+	DeepSeek-284B / Nemotron-30B	111.62 tok/s (30B)

이 모든 수치는 프로젝트가 자체 보고한 것으로 README와 벤치마크 표에 게시되었습니다.

284B 모델이 64GB RAM에 맞는 방법

핵심 메커니즘은 공격적인 양자화와 맞춤형 텐서 형식의 결합입니다. llama-modchip은 가중치당 3.75비트의 Fractal-64라는 블록-64, BF16 스케일, Gray-코딩 텐서 유형과 가중치당 4.25비트의 Fractal-MXFP4 변형을 도입합니다. 프로젝트는 또한 25% 순위 감소에서 99.82% 코사인 유사도를 유지한다고 주장하는 "Analytical SwiGLU-H2 Second-Order Hessian Compression" 단계와 "Exact SVD of wo_b * wo_a" 축소를 설명합니다.

DeepSeek-V4-Flash 빌드는 디스크에서 56.56 GiB로 보고되며, 76.87 GiB IQ2_XXS 기준선에서 약 20.31 GiB 감소입니다. 전체 256K 컨텍스트에서 프로젝트는 최대 VmRSS 57.61 GiB를 보고하며, 같은 README의 다른 곳에서는 58.9 GiB가 인용됩니다.

중요한 호환성 주의 사항: Fractal-64 모델은 사용자 정의 GGML 유형 ID(GGML_TYPE_Q2_0 = 40)와 사용자 정의 deepseek4 / Stockfish-PVS 커널을 사용합니다. README는 패치되지 않은 llama.cpp, Ollama 또는 LM Studio에서 이러한 파일을 열면 unknown tensor type 40 오류로 실패한다고 명확히 명시합니다. 사용자는 프로젝트 자체 바이너리 또는 패치된 빌드를 실행해야 합니다.

추측 디코딩 레이어: Stockfish-PVS 및 RouteCrack

llama-modchip의 디코드 속도 향상은 작은 드래프트 모델에 크게 의존합니다. 프로젝트는 RouteCrack 구성 요소가 포함된 1.64MB Stockfish-PVS v2 드래프터를 번들로 제공하며, L2/L3 Zobrist 트랜스포지션 테이블로 설명되며, Nemotron-30B 모델에서 96.4% 수락률, DeepSeek-284B에서 94.5% 수락률을 보고합니다.

DeepSeek-V4-Flash에서 프로젝트는 순수 CPU 디코드 9.06–10.74 tok/s를 보고하며, PVS 드래프터를 활성화하면 11.5–14.7 tok/s로 상승합니다. Nemotron-30B에서는 기본 디코드 25.02 tok/s와 드래프터 사용 시 평균 48.39 / 최대 60.40 tok/s를 보고합니다.

Claude Code 통합 및 웜 KV 복원

프로젝트는 모든 40개 도구가 활성화된 Claude Code CLI를 로컬 엔진에 연결하는 ./modchip claude 명령을 제공합니다. 해결하려는 문제는 CPU 에이전트가 매 턴마다 겪는 약 45초의 프롬프트 재평가입니다. llama-modchip은 /dev/shm Slot-0 KV 웜 복원으로 이를 해결하며, Nemotron-30B에서 18.9ms, DeepSeek-284B에서 13.1–32.6ms로 보고됩니다.

지원 하드웨어

README는 AMD Zen 5(AVX-512 및 VPDPBUSD, VPRORVQ, VBMI, BF16), Zen 4 멀티-CCD Threadripper 및 EPYC(동적 L3 CCD 토폴로지 발견, 프로젝트가 -t 64보다 54% 빠르다고 주장하는 결정적 4-코어-퍼-CCD 스트라이드), AMD 3D V-Cache 및 Radeon Vulkan 하이브리드, Intel/NVIDIA Windows 하이브리드, Metal을 통한 Apple Silicon, ARM64 클라우드(AWS Graviton3 및 SDOT 및 256비트 SVE), Fedora 미니 PC 구성을 위한 아키텍처별 커널을 나열합니다.

README의 커뮤니티 제출 리더보드 항목에는 Threadripper PRO 7985WX(Nemotron-30B에서 111.62 tok/s 웜 디코드), Apple M4 Pro(47–48 tok/s), AWS Graviton3 m7g.2xlarge(44.97 tok/s), AVX2 전용 EPYC 7402P(27.29 tok/s)가 포함됩니다.

핵심 반대 의견: 2비트 양자화는 품질에 어떤 비용을 초래하는가?

Hacker News 스레드에서 가장 실질적인 비판은 속도가 아닌 양자화 품질에 관한 것입니다. 댓글 작성자 @armcat은 비트 폭과 모델 품질 간의 관계가 비선형이며 일반적으로 최적점은 약 4비트라고 주장했습니다:

"공격적인 양자화와 관련해 명심해야 할 점은 (1) 양자화가 비선형 성능 동작을 보이고, (2) 일반적으로 크기 대비 성능 비율의 최고점이 4비트에서 발생한다는 것이 경험적으로 입증되었다는 것입니다. 그보다 낮추면 성능이 크게 저하됩니다."

@armcat은 "Reliability Scaling Laws for Quantized Large Language Models"(TUM)을 인용하고, 음성 모델 작업 2년 동안 8비트 미만은 큰 품질 저하였다고 덧붙였습니다. 양자화 동작이 모달리티 간에 동일하지 않다는 점을 지적했습니다.

@walrus01은 더 직접적으로, 모델을 이렇게까지 줄이는 것은 목적을 무너뜨린다고 주장했습니다:

"그들이 줄이기 위해 하는 모든 것은 unsloth Q2XS 양자화 또는 그에 상응하는 것보다 더 나쁘게 만들 것입니다. 그 크기의 모델은 완전한 비양자화 KV 캐시로 제대로 실행하려면 약 150GB RAM이 필요합니다... 단지 하고 있다고 말하려고 로보토마이즈된 모델을 실행하는 것은 정말 특별한 것을 달성하는 것이 아닙니다."

@throw10920은 장르를 간결하게 요약했습니다: "'2-bit quant'는 '이 하드웨어에 얼마나 큰 모델을 맞출 수 있는지'의 'in mice'입니다." @GypsyKing716도 비슷한 점을 지적했습니다: "로드할 수 있다고 해서 로드해야 한다는 뜻은 아닙니다."

여러 댓글 작성자는 양자화 수준이 README에서 전혀 명확하지 않다고 말했습니다. @akie는 "어떤 양자화에서? 그것이 내가 알고 싶은 유일한 것입니다."라고 썼습니다. @boredatoms: "양자화가 아마 가장 중요한 정보인데, 빽빽한 단어 샐러드에서는 전혀 명확하지 않습니다."

두 번째 반대 의견: 실제로 일반 llama.cpp보다 나은가?

@aappleby는 Ryzen 7945HX(16코어 Zen 4, 96GB DDR5)에서 프로젝트를 테스트하고 Nemotron에서 성능이 CPU에서 스톡 llama.cpp와 거의 동일하다고 보고했습니다. prefill을 제외하고:

"바보 같은 질문인데, 이 AI 생성 저장소가 실제로 뭔가 하는 건가요? Nemotron에서 비교해 보면 CPU에서 일반 llama.cpp와 거의 동일하게 실행됩니다(prefill이 훨씬 빠른 것 제외). 'modchip setup'에서 DeepSeek을 설정하는 옵션이 없어서 아직 테스트하지 못했습니다."

@sparse-Matrix는 훨씬 약한 하드웨어에서 프로젝트가 작동한다고 보고하며 반박했습니다: "Ryzen 7 5700U/64GB DDR4에서 잘 작동합니다. 꾸준히 12~14 TPS... 15w 전력 소비로 의미 있는 개인 작업을 하기에 충분히 빠릅니다."

@robotswantdata는 별도의 성능 우려를 제기했습니다: "이 접근 방식의 prefill(프롬프트 처리)은 너무 느립니다."

README 가독성 문제

댓글에서 반복되는 주제는 문서 자체였습니다. 여러 독자가 README가 AI 생성이고 파싱하기 어렵다고 설명했습니다. @superkickstart: "사람들이 GitHub README에서 AI가 뿌린 이모지를 정리했으면 좋겠습니다. 가독성이 정말 끔찍합니다." @intoXbox는 "꽤 불쾌한 Readme.md에 AI 슬롭이 가득하다"고 말하고 "llama.cpp를 감싸고 있지만 어떤 플랫폼 가정을 하는지 보지 않으면 다른 독자들이 테스트할 가치가 있는지 불분명하다"고 지적했습니다. @gtirloni은 "사람들이 README.md 파일도 인간이 읽는다는 것을 기억하는지, 아니면 우리 모두 기본적으로 AI 슬롭에서 TL;DR을 요구하는 것인지"라고 물었습니다.

llama.cpp의 포크 생태계 문제

@SillyUsername은 llama-modchip을 특수화된 llama.cpp 포크의 더 넓은 패턴(Bonsai Qwen 3.8 27B, Strata, Pulsar)에 두고 업스트림 검토 프로세스가 병목이라고 주장했습니다:

"업스트림 Llama.cpp가 PR을 더 빨리 수락했으면 좋겠습니다. 하루에 여러 번 빌드하지만, 마지막으로 확인했을 때 PR 백로그가 1.7K였는데, 소수의 자원봉사자로 검토하기에는 터무니없이 비현실적인 숫자입니다. Qwen 3.8 Bonsai 기능을 지켜봤는데 생성 후 검토까지 3주 이상 걸렸고, 그 후에도 하류에서 수정한 버그 패치가 포함되지 않았습니다. 프로세스가 너무 힘들어서 업스트림에 푸시하는 것을 포기했습니다."

토론이 로컬 추론의 방향에 대해 말하는 것

여러 댓글 작성자는 이 프로젝트를 사용 가능한 로컬 추론의 하드웨어 최소 요구치가 계속 낮아지고 있다는 증거로 읽었습니다. @kennywinker는 $800 미만 빌드를 설명했습니다: "스레드가 많은 E5 워크스테이션, $300 RAM, 최소 $100 GPU로 >100tok/s+ 프롬프트 처리와 Qwen3.8-flash-next:IQ3_S로 ~20tok/s 출력을 얻을 수 있습니다. $500 GPU를 추가하면 간신히 사용 가능한 수준에서 만족스러운 성능으로 바뀝니다."

@antirez는 더 높은 사양의 데이터 포인트를 제공했습니다: 128GB 통합 RAM으로 모델이 "심지어 빠르게 실행될 수 있습니다... 코딩 에이전트가 수용할 수 있을 정도로 빠르게," prefill 약 300 tok/s를 인용했습니다.

@nickdothutton은 역사적 유사점을 그렸습니다: "1980년대 데모신 사람들 중 상당수는 하드웨어가 부족하고 비쌌던 나라 출신이었고, 그것이 많은 기술적 창의성을 이끌었습니다." @aussiegreenie은 경제성을 "데이터 주권과 함께 유용한 작업을 위한 충분한 처리 능력에 대해 1인당 월 약 $10"로 계산했습니다.

시도하기 전 실용적 주의 사항

• 284B DeepSeek 수치는 프로젝트 작성자가 자체 보고한 것이며 스레드에서 독립적으로 재현되지 않았습니다.
• Fractal-64 GGUF 파일은 프로젝트의 패치된 바이너리가 필요합니다. 스톡 llama.cpp, Ollama 및 LM Studio는 unknown tensor type 40으로 거부합니다.
• 가중치당 3.75비트의 품질은 열린 질문입니다. README는 Nemotron에서 "100/100 품질 게이트"와 DeepSeek 프로필 전반에 걸쳐 코사인 유사도 0.99126–1.00000을 보고하지만, 독립 댓글 작성자는 이러한 지표가 실제 세계의 성능 저하를 포착하는지 회의적입니다.
• 최소 한 명의 테스터(@aappleby)는 Nemotron에서 prefill 외에는 스톡 llama.cpp보다 의미 있는 속도 향상을 찾지 못했지만, 다른 테스터(@sparse-Matrix)는 오래된 하드웨어에서 사용 가능한 처리량을 보고했습니다.
• 프로젝트는 Apache 2.0 라이선스이며 paper/ 디렉토리에 arXiv 스타일 사전 인쇄 PDF가 포함되어 있습니다.

SUMMARY: llama-modchip v2.4.0은 패치된 llama.cpp 포크로, 공격적인 2비트 양자화와 추측 디코딩을 사용하여 순수 CPU에서 256K 컨텍스트로 59GiB 미만의 RAM에서 284B DeepSeek-V4-Flash MoE를 실행한다고 주장하지만, Hacker News 댓글 작성자들은 품질 트레이드오프와 README의 가독성에 의문을 제기합니다.

TITLE: llama-modchip v2.4.0: 64GB CPU 전용 머신에서 284B DeepSeek MoE 실행하기