"당신의 Mac으로는 그걸 실행할 수 없습니다"라는 말에 질려서, 저는 llama.cpp를 포크(fork)하여 모델 전체를 RAM에 강제로 밀어넣는 대신 SSD에서 MoE (Mixture of Experts) 모델의 전문가(expert) 가중치를 스트리밍하도록 만들었습니다. MoE는 토큰당 몇 개의 전문가만 활성화되므로 대부분의 가중치는 유휴 상태로 머뭅니다. Slipstream은 항상 필요한 가중치는 상주시키고, 라우팅된 전문가들을 요청 시에만 Mac의 스왑(swap)을 유발하지 않는 제한된 RAM 캐시로 스트리밍합니다. 이 소프트웨어는 엔진이 포함된 네이티브 macOS 앱으로 제공됩니다 — .dmg를 다운로드하여 Applications 폴더로 드래그하고 열기만 하면 됩니다. 컴파일할 필요가 없습니다. Kilo/Cline/Cursor/OpenCode를 localhost:8080으로 지정하세요. (아직 공증(notarized)되지 않았으므로, 첫 실행 시에는 우클릭 → 열기를 선택하세요.) 이 서브레딧은 실제 수치를 누릴 자격이 있기에, 증거 중심의 데이터를 공개합니다:

• Qwen3.6-35B-A3B (Q4), 내부 NVMe에서 스트리밍: 10 GiB 캐시(적중률 78%)에서 약 13 tok/s, 14 GiB에서 약 19 tok/s. 35B 모델은 대화형 작업의 핵심 동력입니다.
• 36 GB에 들어가지 않는 Laguna 118B-A8B: 약 2.8 tok/s. 채팅용이 아닌 배치 코딩(batch coding)용으로 사용 가능합니다.
• 가장 큰 성능 향상 요인은 영리한 커널(kernel)이 아니었습니다 — 저는 단 하나의 파일(스트리밍되는 전문가 가중치)을 더 빠른 디스크로 옮겼고, 그 결과 2.7배의 성능 향상을 얻었습니다. 저장 장치 배치(Storage placement)가 그 무엇보다 중요합니다.
• 아주 작은 캐시에서는 잘못 판단하여 포기했던 제로 카피(zero-copy) 경로가 실제 캐시 크기에서는 +13~24%의 성능 향상을 가져오는 것으로 나타났으며, 현재 기본적으로 활성화되어 있습니다.

그리고 정직함을 위해, 작동하지 않았던 부분들도 공개합니다:

• Dual-SSD 스트라이핑(striping): 내부 NVMe + 느린 USB(공유 버스) 조합에서는 부정적인 결과가 나왔습니다.
• 투기적 프리페치 예측기 (Speculative prefetch predictors, 정적 + 온라인 방식): -8%. 예측이 읽기 비용(read cost)을 이길 수 없습니다.
• HOT-expert 예약: -1% ~ -6% (일반 캐시 크기를 줄입니다).

부정적인 결과를 포함한 전체 보고서는 BENCHMARKS.md를 참조하세요. 저장소(Repo)와 독립형 .dmg는 링크에 있습니다. MIT 라이선스이며, 100% 온디바이스(on-device)로 실행됩니다. JustVugg/colibri(CPU/CUDA용으로 이 기능을 수행함)에서 영감을 얻었으며, 저는 이를 Apple Silicon + Metal에 맞게 조정했습니다. 벤치마크 질문은 언제든 환영합니다. 만약 두 개의 빠른 NVMe 드라이브를 가진 분이 Dual-SSD 경로를 테스트하고 싶다면(그 환경에서는 승리할 것입니다), 수치를 공유해 주시면 감사하겠습니다.