소비자용 장치에서도 Qwen 3.5 397B를 실행할 수 있는 다른 방법이 있음
약 2.5 BPW 양자화(quant) 버전이 있어 128GB 메모리 장치에서도 충분히 가능함
나는 M1 Ultra에서 약 20 tok/s 속도로, 256k 컨텍스트를 유지하며 잘 돌렸음 lm-evaluation-harness 결과는 mmlu 87.86%, gpqa diamond 82.32%, gsm8k 86.43%, ifeval 75.90% 정도였음
자세한 경험은 Hugging Face 토론 링크1과 링크2에 정리했음
오프라인 추론용으로 훌륭한 모델임
링크의 방법도 이미 2-bit quantization을 사용하고 있음
토큰당 전문가 수를 10명에서 4명으로 줄여 품질이 더 떨어짐
짧은 프롬프트에는 괜찮지만 긴 세션에서는 쓸모가 없음
JSON 출력에서 "name" 대신 \name\을 생성해 도구 호출이 불안정해지는 문제도 있음
요즘 tok/s는 얼마나 나오는지 궁금함
긴 컨텍스트에서도 잘 작동하는지 알고 싶음
그리고 오랜만에 닉네임을 보니 반갑음 — Neovim을 만든 사람이라니, 정말 대단한 성공임
나도 매일 쓰고 있음
세부 내용을 보면 2-bit 양자화와 전문가 수를 10명에서 4명으로 줄여 5 tok/s 정도를 얻은 것 같음
흥미로운 개념 증명(proof of concept)이지만, 원래의 397B 모델 품질과는 거리가 큼
이런 극단적인 최적화는 모델의 지능 손실을 초래함
JSON 출력에서 "name" 대신 \name\을 생성하는 문제도 있어서 실사용에는 부적합함
이런 실험이 기술적으로 가능함을 보여주는 시도라는 점은 인정하지만, 실제로 쓸 수 있는 수준은 아님
요즘 이런 AI 작성 논문들이 너무 많아 피로감을 느낌
JSON 출력 문제를 보고, 샘플링을 유효한 JSON 토큰으로만 제한하면 되지 않을까 생각했음
하지만 실제로는 상용 LLM조차 도구 호출 정확도가 낮다는 얘기를 들었음
아마 구현이 어렵거나 구조적으로 불가능한 부분이 있을 것 같음
전문가를 시스템 메모리에 로드하는 기능은 이미 대부분의 로컬 AI 프레임워크에서 지원함
다만 디코드 단계는 GPU보다 CPU 전송 오버헤드가 커서 이득이 적음
GPU는 공유 부분 가속에만 쓰는 게 효율적임
GPU 메모리에 안 맞는 일부 레이어를 CPU로 돌리는 것도 가능하지만
모델이 시스템 RAM이나 디스크로 넘어가면 성능이 급격히 하락함
이런 접근이 된다면 3090 두 개와 충분한 RAM으로도 개인 연구실 수준의 대형 추론이 가능할 것 같음
SSD가 병목이라는 설명이 있었는데, 저자는 15GB/s를 얻었다고 함
하지만 내가 알기로는 최대 대역폭이 8GB/s 정도였음. 뭘 놓친 걸까?
이런 구조에서는 IO가 매우 버스트성임
라우터 결과가 나오면 SSD에서 전문가를 불러오는데, 그 순간 SSD가 포화됨
평균 IO는 2970MB/s 정도로 SSD 한계보다 훨씬 낮음
일부 텐서를 비동기 읽기로 병렬화하면 더 나을 수도 있음
나는 Linux에서 io_uring으로 실험했을 때 약 20%의 읽기가 연산 중 병렬로 완료됨
Hacker News 의견들
소비자용 장치에서도 Qwen 3.5 397B를 실행할 수 있는 다른 방법이 있음
약 2.5 BPW 양자화(quant) 버전이 있어 128GB 메모리 장치에서도 충분히 가능함
나는 M1 Ultra에서 약 20 tok/s 속도로, 256k 컨텍스트를 유지하며 잘 돌렸음
lm-evaluation-harness 결과는 mmlu 87.86%, gpqa diamond 82.32%, gsm8k 86.43%, ifeval 75.90% 정도였음
자세한 경험은 Hugging Face 토론 링크1과 링크2에 정리했음
오프라인 추론용으로 훌륭한 모델임
토큰당 전문가 수를 10명에서 4명으로 줄여 품질이 더 떨어짐
짧은 프롬프트에는 괜찮지만 긴 세션에서는 쓸모가 없음
JSON 출력에서
"name"대신\name\을 생성해 도구 호출이 불안정해지는 문제도 있음긴 컨텍스트에서도 잘 작동하는지 알고 싶음
그리고 오랜만에 닉네임을 보니 반갑음 — Neovim을 만든 사람이라니, 정말 대단한 성공임
나도 매일 쓰고 있음
CoconutBattery로 추정할 수 있을지도 모름
세부 내용을 보면 2-bit 양자화와 전문가 수를 10명에서 4명으로 줄여 5 tok/s 정도를 얻은 것 같음
흥미로운 개념 증명(proof of concept)이지만, 원래의 397B 모델 품질과는 거리가 큼
이런 극단적인 최적화는 모델의 지능 손실을 초래함
JSON 출력에서
"name"대신\name\을 생성하는 문제도 있어서 실사용에는 부적합함이런 실험이 기술적으로 가능함을 보여주는 시도라는 점은 인정하지만, 실제로 쓸 수 있는 수준은 아님
요즘 이런 AI 작성 논문들이 너무 많아 피로감을 느낌
하지만 실제로는 상용 LLM조차 도구 호출 정확도가 낮다는 얘기를 들었음
아마 구현이 어렵거나 구조적으로 불가능한 부분이 있을 것 같음
r/LocalLLaMA 토론에서도 관련 논의가 있었음
GitHub 페이지에 따르면 단순 mmap 접근은 페이지 단위 오버헤드로 병목이 생김
macOS에서 huge page를 설정하거나
posix_fadvise로 프리패칭을 하면 개선될 수 있을지 궁금함2-bit 양자화의 품질 저하는 실제로 심각한 문제임
실제 작업에서는 잘 튜닝된 30B 4-bit 모델이 70B+ 2-bit보다 낫다는 경험이 있음
전문가 수를 줄이면 사실상 다른 모델이 되어버림
그래도 소비자 하드웨어의 한계를 시험해본다는 점은 흥미로움
“노트북에서 실행”이라는 제목이 매번 $3000짜리 MacBook을 의미하는 게 피곤함
압축 기술은 인상적이지만, 일반 사용자에게 현실적인 옵션은 아님
하지만 제목을 보고 아무 노트북에서도 돌아갈 거라 기대하지는 않음
지나친 냉소보다는 이런 실험을 즐기는 편임
영상 편집 등으로 이미 이런 고성능 맥북을 가진 사람도 많음
별도 장비 없이 기존 노트북으로 실험할 수 있다는 점이 장점임
약 20 tok/s 속도였고, 개인에게도 충분히 접근 가능한 수준이라 생각함
업무용으로도 투자 가치가 있었음
“No Python. No frameworks. Just C, Objective-C, and hand-tuned Metal shaders.”
이 문장을 보고 토큰이 어디서 나왔는지 바로 감이 왔음
“Hand-written Metal kernels”이라는데, 혹시 GPT가 직접 쓴 건 아닐까? 😉
정말 인상적인 결과임
Linux에서도 SSD 대신 시스템 메모리 기반 접근으로 비슷한 방법이 가능할지 궁금함
혹은 가중치를 ROM 형태로 저장하는 아이디어도 흥미로움
다만 이 프로젝트는 Metal을 사용하므로 macOS 전용일 뿐임
하지만 MoE 모델은 여전히 대역폭 제약이 큼
다만 디코드 단계는 GPU보다 CPU 전송 오버헤드가 커서 이득이 적음
GPU는 공유 부분 가속에만 쓰는 게 효율적임
모델이 시스템 RAM이나 디스크로 넘어가면 성능이 급격히 하락함
SSD가 병목이라는 설명이 있었는데, 저자는 15GB/s를 얻었다고 함
하지만 내가 알기로는 최대 대역폭이 8GB/s 정도였음. 뭘 놓친 걸까?
라우터 결과가 나오면 SSD에서 전문가를 불러오는데, 그 순간 SSD가 포화됨
평균 IO는 2970MB/s 정도로 SSD 한계보다 훨씬 낮음
일부 텐서를 비동기 읽기로 병렬화하면 더 나을 수도 있음
나는 Linux에서 io_uring으로 실험했을 때 약 20%의 읽기가 연산 중 병렬로 완료됨