"책상 위 슈퍼컴퓨터"라는 말은 오래된 과장이었습니다. 10월 15일, 처음으로 그 말이 구체적인 숫자와 함께 나왔습니다.

메타가 816B 파라미터 모델 Muse Spark Open의 가중치를 공개했고, 같은 날 애플은 MLX와 Thunderbolt RDMA로 그 모델을 맥 스튜디오에서 돌린 측정을 발표했습니다. 결론부터 말하면 돌아갑니다. 대신 당신의 맥북은 아닙니다.

2026년 10월 15일, 같은 날 나온 두 발표

Meta  — Muse Spark Open 가중치 공개 (816B / 활성 42B, 1M 컨텍스트)
Apple — MLX + Thunderbolt RDMA로 맥 스튜디오 클러스터에서 돌린 측정
        최대 4대 구성에서 초당 36.73토큰 (8,192토큰 컨텍스트)

"돌아간다"와 "쓸 만하다" 사이의 거리를 오늘 숫자로 정리해 보겠습니다.

무엇이 공개됐나: 숫자보다 성격부터

Muse Spark Open은 메타 슈퍼인텔리전스 랩스의 Muse Spark 오픈웨이트 버전입니다.

- 816B 전체 파라미터 / 토큰당 약 42B만 활성화되는 sparse MoE
- 텍스트·이미지·영상·오디오 입력을 받는 네이티브 멀티모달
- 1M 토큰 컨텍스트
- 작업 지향: 코드베이스를 읽고 → 계획하고 → 도구를 호출하고
  → 결과를 확인하고 → 실패하면 스스로 고치는 장기 에이전트 작업
- 라이선스: Muse Model License (제한적 상용 조건)

가중치는 허깅페이스에서 받을 수 있고, 공개 첫날부터 SGLang·vLLM·TensorRT-LLM·Transformers·MLX·llama.cpp·Unsloth에서 실행됩니다. Baseten·Fireworks·Groq·Modal·Nebius·OpenRouter·Together 같은 호스팅 API로 먼저 써보고 로컬로 내려오는 경로도 열려 있습니다.

여기서 "오픈웨이트"의 실질적 의미는 다운로드·파인튜닝·자체 호스팅이 가능하다는 것입니다. 발표문의 "가장 성능 좋은 미국 오픈웨이트" 같은 표현은 평가 기관이 검증할 몫이지만, 적어도 이 클래스의 모델이 오픈으로 풀리는 흐름은 분명해졌습니다.

애플이 측정한 숫자: 8,192토큰 컨텍스트에서 초당 36.73토큰

애플 ML 리서치가 공개한 측정값입니다. M5 Ultra·512GB 맥 스튜디오 기준, 8,192토큰 컨텍스트입니다.

측정 항목 2대 파이프라인 2대 텐서 4대 텐서
생성 속도 (토큰/초) 15.74 24.99 36.73
첫 토큰까지 (초) 8.4 8.2 4.8

숫자를 읽는 배경도 함께 기억해 두세요.

- M5 Ultra: 최대 512GB 통합 메모리, 1.2TB/s 대역폭
  (이전 세대 M3 Ultra는 819GB/s)
- 같은 조건에서 M3 Ultra 대비 첫 토큰 4.6배, 생성 1.6배 향상
- 전력은 65,536토큰 컨텍스트에서 200~300W 수준
  — 토스터기보다 적게 쓰면서 "책상 위"가 가능해진 이유

왜 4대가 필요할까: 모델을 나누는 두 가지 방법

Muse Spark Open은 NVFP4 4비트 양자화로 약 493GB(애플 측정)~530GB(메타 표기)입니다. BF16 원본은 1.6TB가 넘어 단일 장비로는 불가능합니다. 그래서 512GB 맥 스튜디오 두 대, 또는 256GB 네 대가 기준 구성이 됩니다.

모델을 여러 대로 나누는 방법은 두 가지입니다.

Pipeline parallelization — 깊이로 나눔
  [Mac 1] 앞쪽 절반 레이어 → [Mac 2] 뒤쪽 절반 레이어
  · 한 대씩 순서대로 계산, 교환하는 건 중간 출력뿐
  · 구현이 단순하고, 디코드 속도는 단일 장비와 비슷
  · 긴 컨텍스트 prefill에서 최대 약 1.8배 (65,536토큰 기준)

Tensor parallelization — 폭으로 나눔
  [Mac 1] 모든 레이어의 절반 | [Mac 2] 모든 레이어의 절반
  · 매 토큰마다 두 대가 동시에 계산하고 중간 결과를 교환
  · 통신량이 많아 저지연 통신(Thunderbolt RDMA)이 필수
  · 디코드가 가장 잘 늘어남: 4대에서 36.73 토큰/초

이걸 가능하게 한 통신 계층이 macOS 26.2의 Thunderbolt 5 RDMA 드라이버와 MLX의 jaccl 백엔드입니다. 맥 두 대를 썬더볼트 케이블 2개로 묶어 대역폭을 두 배로 쓰고, 실행은 명령 한 줄이면 됩니다.

mlx.launch --hostfile hostfile.json --backend jaccl --env MLX_METAL_FAST_SYNCH=1 -- \
  mlx_lm.benchmark --model meta-models/Muse-Spark-Open-816B-A42B-NVFP4 -p 8192 -g 128 -b 1

재미있는 뉘앙스 하나. 2대 텐서 구성은 65,536토큰 같은 초장문에서 prefill 통신 오버헤드 때문에 2대 파이프라인보다 오히려 느릴 수 있습니다. 4대로 가면 뒤집힙니다. "무조건 텐서가 낫다"가 아니라 기기 수와 컨텍스트 길이에 따라 답이 달라지는 것. MoE 서빙 커널 글에서 봤던 것처럼, 결국 병목은 계산이 아니라 데이터가 오가는 길에 있습니다.

모델이 책상에 오면: 로컬 에이전트까지 이어지는 흐름

애플은 추론 성능만 측정한 게 아니라, 로컬 모델 서버를 코딩 에이전트에 연결하는 방법도 함께 공개했습니다. mlx_lm.server로 모델을 띄우고, OpenCode 같은 도구를 그 서버에 붙이는 구성입니다.

{
  "$schema": "https://opencode.ai/config.json",
  "model": "meta-models/Muse-Spark-Open-816B-A42B-NVFP4",
  "provider": {
    "mlx": {
      "baseURL": "http://127.0.0.1:8080/v1"
    }
  }
}

(원문은 애플 ML 리서치 포스트에서 확인할 수 있습니다. 위는 핵심만 줄인 설정입니다.)

메타 측정 사례도 같은 방향입니다. Muse Code가 오픈소스 Mastodon 클라이언트 Ice Cubes에 실제 iOS 변경(버그 수정, 기능 추가, 전체 빌드)을 전부 로컬에서 해냈고, DaVinci Resolve를 처음부터 끝까지 몰고 가며 영상을 프레임 단위로 검토해 세로 크롭까지 만들었습니다. 로컬 모델이 장난감을 넘어 실제 작업 루프에 들어오는지 시험하는 단계라는 뜻입니다.

현실 체크: 발표문에서 크게 강조되지 않은 조건들

① 36.73토큰/초는 8,192토큰 컨텍스트의 디코드 측정이다.
   "맥북 한 대에서 돌아간다"는 뜻이 아니다.
   NVFP4 기준 최소 2대(512GB×2) 또는 4대(256GB×4)가 전제다.
② 첫 토큰은 4.8초(4대 텐서, 8k). 대화형 체감은 생성 속도보다
   이 숫자가 좌우한다.
③ 속도 수치는 NVFP4 양자화 기준이다. 전문가(expert) 층만
   양자화했다고 표기돼 있어, 정밀도 민감 작업은 별도 검증이 필요하다.
④ 4대 구성의 65k 컨텍스트 TTFT 40.6초는 케이블 2개 매쉬 기준.
   1개면 약 50.5초였다 (애플 추가 실험).
⑤ Unsloth의 2비트 GGUF라면 256GB급 워크스테이션 1대로도 가능(약 300GB).
   대신 품질 저하를 감수해야 한다. "돌아간다"와 "제대로 돌아간다"는 다르다.
⑥ 속도 보정 장치들: 초안 모델로 여러 토큰을 한 번에 제안하는 추측 디코딩
   (SGLang DFlash V2: MI355X 단일 요청 3.7배), Helion 커널
   (커널 레벨 1.03~3.95배, MI350 종단 3% 개선)

CodeBridge Mini Lab: 로컬과 클라우드, 같은 질문으로 재보기

① 고정 질문 세트 10개를 만든다 (코드 이해 3, 로그 요약 3, 문서 검색 4)
② 로컬(Muse Spark Open)과 클라우드 API로 같은 질문을 돌린다
③ 기록한다:
   [ ] 첫 토큰 시간 / 초당 생성 속도
   [ ] 답 품질 (블라인드 비교, 같은 채점 기준)
   [ ] 1회 비용 (전기·감가 포함 로컬 vs API 단가)
   [ ] 데이터가 기기를 떠났는가 (규제·기밀 관점)
④ 판단 기준: "밖으로 나가면 안 되는 작업"에 로컬이 값을 하는가

포인트는 816B를 사야 하나가 아닙니다. 대부분은 아닙니다. 다만 "이 작업만은 내 장비에서"라는 리스트가 생기기 시작하면, 그때 필요한 건 하드웨어 결정이 아니라 작업 분류입니다. DGX Spark 로컬 AI 경제학에서 다룬 계산이 여기에도 그대로 적용됩니다.

결론: 모델의 위치가 바뀌어도, 설계할 것은 남는다

오늘의 진짜 변화는 "816B를 살 수 있다"가 아니라
"모델이 내 책상 위에 있을 수도 있다"가 선택지가 된 것이다.

그리고 모델이 어디에 있든, 에이전트가 실제로 일을 하려면 실행과 검증이 반복되는 루프, 도구 호출, 역할 분담을 설계해야 합니다. 하드웨어는 몇 년마다 바뀌지만, 그 구조는 오래갑니다. 816B를 당장 사지 않더라도 오늘 배울 수 있는 부분입니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

모델이 책상으로 내려와도, 에이전트가 실제로 일하게 만드는 건 실행과 검증의 구조입니다. 하네스·루프·그래프를 직접 설계하며 "어디서 실행하고, 어디서 확인할지"를 연습해 보세요.