Gemma 4 26B-A4B와 37 GB Qwen3.6 MoE를 24 GB Mac의 브라우저 탭에서 실행한 결과

이것은 업데이트입니다. 제가 예전에 다른 계정으로 LocalMind를 여기 게시했었는데, 당시에는 Gemma 채팅을 하는 탭 형태였습니다. LocalMind는 WebGPU를 통해 사용자의 GPU에서 모델을 구동하는 정적 웹 페이지입니다. 서버도 없고, 계정도 없고, 설치할 필요도 없습니다. 새로운 부분은 두 개의 엔진이 생성하는 동안 mixture-of-experts(MoE) 가중치를 디스크에서 스트리밍한다는 것입니다. 이 기능 덕분에 탭이 기기의 RAM보다 더 큰 모델을 구동할 수 있게 되었습니다.

실시간 시연: https://localmind.naklitechie.com · 코드 (MIT): https://github.com/NakliTechie/LocalMind

모든 숫자는 MacBook M4 Pro (24 GB) 한 대의 Chrome에서 측정되었습니다.

작동 방식: 처음 로드 시, GGUF 파일이 OPFS(브라우저의 사설 파일 시스템)로 복사됩니다. 밀집 가중치(Dense weights), 라우터(routers), 그리고 KV 캐시(KV cache)는 GPU로 전송됩니다. 라우팅된 전문가(Routed experts)들은 디스크에 남아 있습니다. 작업자 풀(pool of workers)이 필요할 때마다 동기 액세스 핸들(sync access handles)을 사용하여 GPU 슬롯 캐시(LRU, 두 단계의 프리페치)로 읽어옵니다. 트렁크 커널(trunk kernels)은 llama.cpp의 그래프를 따르도록 수동으로 작성된 WGSL입니다. 이를 통해 동일한 GGUF 파일에 대해 llama.cpp와 테스트할 수 있었습니다.

Gemma 4 26B-A4B (Google의 QAT Q4_0, 14.4 GB)
llama.cpp와 동일한 출력을 보였습니다. Metal: 실시간 사이트의 채팅 응답은 9/9 테스트 대화에서 문자 단위로 일치했습니다(최대 64 토큰 제한). 15/16개의 새로운 프롬프트는 토큰 단위로 일치했습니다. 16번째 분할에서는 0.00009-nat로 거의 동률이었으며, 이 경우 llama.cpp 자체의 두 가지 어텐션 경로도 의견이 달랐습니다.
메모리: Chrome GPU 프로세스는 4 GB 전문가 캐시와 함께 6.9 GB를 차지했습니다. 약 8.6 GB의 전문가가 디스크에 남아 있습니다.
속도: 디코드(decode) 시 23.6 tok/s, 프롬프트 처리(prompt processing) 시 55 tok/s입니다. llama.cpp Metal은 동일한 Mac에서 각각 70.6 및 204를 기록했으므로, 이 탭은 디코드 속도에서 약 3배 느립니다.
토큰당: GPU 컴퓨팅에 약 22.5 ms, 라우팅 왕복(routing round trips)에 약 11 ms, SSD 읽기에 약 8–13 ms가 소요됩니다.
사이트 첫 로드 시간: 11.5분 (14.4 GB 다운로드). 그 이후: 1.6초.

Qwen3.6 35B-A3B (unsloth Q8_0, 36.9 GB, 24 GB Mac에서) — 실험적
파일 크기가 기기 메모리보다 더 큽니다. GPU 프로세스는 4 GB 전문가 캐시와 함께 7.3 GB를 측정했습니다.
실시간 사이트: 디코드 시 9.9 tok/s, 첫 토큰까지 2.2초가 소요되었습니다.
첫 로드 시간은 36분(다운로드 및 OPFS 복사 포함)이었습니다.

출력 결과는 4개 및 16개 레이어 절단본에서 llama.cpp Metal 8/8과 일치합니다. 전체 모델의 경우 llama.cpp CPU 5/8과 일치하며, 나머지 3개의 스왑은 근접한 토큰을 보입니다. 이 Mac에서는 full-model parity를 위한 전체 파일을 llama.cpp Metal로 실행할 수 없으므로, 전체 모델 패리티는 아직 미정입니다. 토큰당(~99 ms): GPU 컴퓨팅 약 23 ms, 라우팅 왕복 시간 약 39 ms, SSD에서 전문가(expert) 읽기 약 35 ms가 소요됩니다. 라우팅을 GPU로 옮겨도 이득이 없었습니다 (10.3 vs 10.3 tok/s): 누락된 부분은 아무도 예측하지 못한 전문가들입니다. 또한 Gemma 4 E2B는 레이어당 1.2 GB의 임베딩 테이블을 디스크에 유지할 수 있습니다: GPU 프로세스 4.27 → 2.07 GB, 동일한 출력, 디코드 속도가 3–8% 느립니다. 이것은 설정이며 기본값으로는 꺼져 있습니다. 전체 앱은 다시 하나의 index.html입니다 (brotli 압축 시 854 KB). 엔진, 워커 및 디스크 계층이 여기에 통합되어 있으며, 탭은 이를 blob URL에서 구축합니다. 디스크 계층 또한 독립적인 라이브러리인 diskformer.js가 있습니다. 기존 기술(Prior art): 제가 아는 한 (2026년 10월 6일 검색 기준), 이전에 브라우저 엔진이 생성 과정 중 디스크에서 가중치(weights)를 읽어온 사례는 없습니다. wllama와 LlamaWeb은 로드 시 OPFS에서만 스트리밍합니다. Pooled는 시스템 RAM에서 전문가가 페이지 단위로 로드되는 방식으로 브라우저에서 Qwen3.6-35B-A3B를 실행합니다. 온디맨드 디스크 읽기는 네이티브 런타임에 존재합니다: llama.cpp의 --moe-stream PR (#25294) 및 Gemma의 레이어당 임베딩을 위한 Google의 LiteRT-LM입니다. 수정 사항은 환영합니다. Gemma 4 E2B 커널은 webml-community의 (Xenova 및 Transformers.js 팀) 것입니다. 제가 기여한 부분은 디스크 경로입니다. Chrome 또는 Edge를 WebGPU로 제한합니다. M4 Pro 24 GB 하나에서 테스트했으며, 8GB 및 16GB 장치는 미테스트입니다. 네이티브보다 빠르지 않습니다: llama.cpp는 Gemma 26B에서 약 3배 더 빠릅니다. 요점은 탭만으로도 동일한 출력으로 이러한 모델을 실행할 수 있다는 것입니다. 패리티는 그리디 디코딩, 위에 나열된 프롬프트, 그리고 각각 64개의 토큰을 포함합니다. 저는 비교를 위해 llama.cpp의 전문가 오프로드 플래그(-ot exps=CPU)를 시도하지 않았습니다. NVIDIA/AMD GPU 또는 32–64 GB Mac이 있다면 tok/s 수치를 알려주시면 감사하겠습니다. 더 큰 전문가 캐시가 Qwen3.6 숫자를 가장 많이 변화시킬 것입니다. submitted by /u/naklitechie [link] [comments]