지난주 포스팅에 이어, 브라우저 탭에서 MoE 전문가를 디스크에서 스트리밍한 내용에 대한 후속 보고입니다. 당시에는 수작업으로 작성된 엔진을 사용하여 두 가지 모델에 대해 테스트했습니다. 이번 주에는 동일한 디스크 계층이 llama.cpp 자체 WebGPU 백엔드 아래에 놓여 있어, 별도의 모델별 엔진 없이도 llama.cpp가 이미 실행하는 MoE 모델들에 적용할 수 있습니다. 이 영상은 Chrome에서 녹화된 실제 기록입니다. 속도가 빨라진 부분에는 실시간 시계와 함께 화면에 표시되어 있습니다.
측정 결과 (MacBook Pro M4 Pro, 24 GB):
| Model (GGUF) File | On the GPU | Load from disk | Decode |
|---|
| Qwen3-Next 80B-A3B Q4_K_M 48.4 GB | 4.89 GB | 48 s | 2.9 tok/s (개념 증명) |
| OLMoE 1B-7B Q4_K_M 4.2 GB | 3.92 GB | 5.3 s | 22.4 tok/s |
| LFM2 8B-A1B Q4_K_M 5.0 GB | 3.89 GB | 6.2 s | 17.1 tok/s |
Qwen3-30B-A3B도 실행 가능합니다 (파일 크기 14.7 GB).
작동 방식.
The GGUF 파일은 브라우저의 개인 저장소(OPFS)에 한 번 다운로드됩니다. GPU는 밀집 레이어(dense layers), KV 캐시, 그리고 사용자가 지정한 GPU 메모리 예산 크기의 고정된 수의 전문가 슬롯을 유지합니다. 각 MoE 레이어에서 라우터가 선택한 값들이 읽혀지고, 슬롯에 없는 모든 전문가는 OPFS 파일에서 가장 최근에 사용되지 않은(least recently used) 슬롯으로 읽어옵니다. 이 페이징 기능은 ggml-webgpu의 작은 변경 사항입니다: 새로운 버퍼 유형, 슬롯 매핑된 MUL_MAT_ID 셰이더, 그리고 잔류성 로직(residency logic)을 추가했습니다.
정확성.
동일한 백엔드에서 페이징 기능을 켜고 끄는 경우, 응답은 동일합니다 (OLMoE와 LFM2의 9/9 대화; 비페이징 상태에서는 로드되지 않는 두 개의 큰 모델의 경우, 8개 vs 32개 또는 16개 vs 64개 슬롯을 사용해도 동일한 응답을 보입니다). llama.cpp의 Metal 백엔드와 비교했을 때, 9개의 응답 중 4~8개가 일치합니다. 불일치는 WebGPU 대 Metal에서의 반올림 오차이며, 거의 동률인 경우에 발생합니다. llama.cpp의 CPU 백엔드와 비교했을 때는 WebGPU 경로가 Metal만큼 근접합니다.
한계점.
The 80B 모델은 느립니다: 토큰당 약 359 MB를 디스크에서 읽어옵니다. 프롬프트 처리 속도는 여전히 느립니다 (지난주에 제기된 공정한 불만). Chrome 또는 Edge 137 이상 버전에서만 가능하며, Apple silicon에서만 테스트되었습니다. 첫 번째 로드는 전체 파일을 브라우저 저장소로 복사합니다. 80B 모델 자체의 답변은, 자신이 어떻게 브라우저 탭에서 실행될 수 있는지에 대해
사용해보기: https://diskformer.naklitechie.com · 코드: https://github.com/NakliTechie/diskformer.js · 제출자 /u/naklitechie [링크] [댓글]
