Mac 4대의 Muse Spark Open, 속도보다 조건을 읽어야

책상 위 대형 모델에도 시스템 설계가 필요하다

Apple은 10월 15일 MLX 분산 추론 연구 글에서 Mac Studio 여러 대를 연결해 대형 언어모델을 실행하는 방법과 측정치를 공개했다. 중심 사례는 총 816B, 토큰 처리 시 활성 42B 파라미터를 갖는 Muse Spark Open이다. Apple은 M5 Ultra Mac Studio 4대에서 초당 36토큰 이상의 생성 속도를 보고했다.

이 수치는 모델 품질 점수가 아니라 정해진 조건에서의 생성 처리량이다. 표에 나온 36.73토큰/초는 8,192토큰 문맥, 128개 생성 토큰, NVFP4 정밀도의 모델과 4대 텐서 병렬 구성에 해당한다. 한 대의 기본 사양 Mac이 같은 성능을 낸다는 뜻도, 여러 사용자가 동시에 요청할 때 같은 지연을 보장한다는 뜻도 아니다. 이번 기사에서는 공개된 Apple 측 측정을 분석하며 직접 장비를 재측정하지 않았다.

활성 파라미터와 필요한 메모리는 다르다

MoE 모델은 일부 전문가만 활성화해 토큰당 연산량을 줄인다. 하지만 활성 파라미터가 42B라는 이유로 전체 모델 가중치도 42B만 저장하면 된다고 생각하면 메모리 계획이 틀어진다. Apple은 Muse Spark Open의 BF16 가중치만으로 1.6TB 이상이 필요하고, NVFP4로 줄여도 약 493GB라고 설명한다.

단일 Mac Studio의 512GB 통합 메모리와 숫자가 비슷해 보이지만 실행 중간값과 문맥용 메모리도 필요하다. 원문은 이 모델이 단일 장비에 들어가지 않아 분산이 필요하다고 명시한다. 모델 파일 크기와 실제 서비스의 최고 메모리 사용량을 분리해서 보는 것이 중요한 이유다.

MLX 공식 사이트와 MLX LM 저장소는 이 실행 환경의 배경을 제공한다. 공개 가중치를 로컬에서 실행할 수 있다는 것과 특정 양자화 버전이 모든 업무에서 같은 품질을 유지한다는 것은 별개의 검증 항목이다. 한국어 문서 분석과 코딩 도구 호출은 실제 사용할 형식으로 시험해야 한다.

두 대를 연결해도 속도가 두 배가 되지 않는 이유

Apple은 파이프라인 병렬과 텐서 병렬을 나눠 설명한다. 파이프라인 병렬은 모델의 앞쪽 층을 한 장비, 뒤쪽 층을 다른 장비가 담당한다. 큰 모델을 메모리에 담기는 쉬워지지만 한 토큰이 층을 순서대로 지나가는 구조여서 생성 속도가 곧바로 두 배가 되지는 않는다. 긴 입력을 여러 조각으로 나눠 처리할 때에는 일부 작업을 겹쳐 수행할 수 있다.

텐서 병렬은 각 층의 연산을 여러 장비에 나눈다. 계산을 함께 수행하는 대신 층마다 자주 통신하므로 짧은 지연의 연결이 중요하다. MLX 분산 실행 문서는 지원 방식과 구성 조건을 설명한다. Apple의 실험은 Thunderbolt RDMA와 jaccl 백엔드를 사용하며, 장비 쌍 사이에 케이블 두 개를 연결하는 구성도 포함한다.

Apple이 제시한 8,192토큰 문맥의 Muse Spark Open 생성 속도는 2대 파이프라인에서 15.74토큰/초, 2대 텐서 병렬에서 24.99, 4대 텐서 병렬에서 36.73이다. 장비를 늘리는 것만큼 어떻게 나누는지가 중요하다는 것을 보여 준다. 다만 이는 같은 문맥과 모델 조건의 비교이지 다른 GPU 서버나 클라우드보다 항상 저렴하다는 증거는 아니다.

첫 응답과 이후 생성은 병목이 다르다

원문은 첫 토큰 지연과 생성 속도를 별도 지표로 제시한다. 긴 입력을 읽는 프리필 단계는 연산 성능의 영향을 크게 받고, 이후 토큰 생성은 메모리 대역폭의 영향을 크게 받는다는 설명이다. M5 Ultra와 M3 Ultra 사이의 최대 4.6배 첫 토큰 개선도 특정 실험에서의 결과이지 모든 요청의 종단 간 가속률이 아니다.

문맥이 65,536토큰으로 길어지면 통신과 입력 분할의 영향도 달라진다. 원문은 Muse Spark Open에서 장비 2대의 텐서 병렬이 일부 긴 문맥 프리필 조건에서 파이프라인보다 느려질 수 있다고 설명한다. 빠른 방식 하나를 골라 모든 요청에 적용하는 전략보다 실제 요청 분포에 맞춘 측정이 필요하다.

Atticus의 로컬 라우팅 분석처럼 사용자가 체감하는 지연은 모델 외부의 처리 단계도 포함한다. 문서 읽기, 검색, 도구 실행과 재시도를 더하면 초당 생성 토큰만으로 작업 완료 시간을 설명할 수 없다.

한국 개발팀의 구매 판단은 총비용과 가동률

소스코드와 사내 문서를 로컬에서 처리하려는 팀에는 선택지가 넓어졌다는 점이 중요하다. 하지만 사내 설치 자체가 권한 관리·로그·백업을 해결하지는 않는다. Pluto의 에이전트 런타임 통제 분석에서 다룬 실행 권한의 문제는 모델의 위치가 바뀌어도 남는다. 로컬 모델이 외부 도구를 호출한다면 데이터 경로도 함께 확인해야 한다.

구매 비교에는 장비, 메모리 사양, 연결 장비, 전력, 유지보수와 유휴 시간을 포함하는 것이 합리적이다. 낮은 가동률에서는 장비를 소유하는 비용이 두드러지고, 높은 반복 사용에서는 요청당 비용 구조가 달라질 수 있다. Apple의 벤치마크는 이를 계산할 성능 자료 일부를 제공하지만 최종 손익분기점을 대신 계산해 주지는 않는다.

Cloudflare·Deno의 셀프호스팅 선택권 분석과 연결하면 경쟁은 단순한 클라우드 대 로컬의 대결이 아니다. 전환 가능한 인터페이스와 운영 역량이 선택권을 만든다. 작은 모델의 단일 장비 실행, 큰 모델의 분산 실행, 외부 서비스 사용을 같은 한국어 평가 세트와 실제 업무 완료 비용으로 비교하는 것이 출발점이다.

자주 묻는 질문

Muse Spark Open이 Mac 한 대에서 실행되나?

소개된 구성에서는 아니다. Apple은 양자화 가중치와 실행용 메모리를 고려하면 여러 장비가 필요하다고 설명한다.

42B 활성 파라미터만 메모리에 저장하면 되나?

아니다. 활성 연산량과 전체 가중치 저장량은 다른 개념이다.

장비를 두 배로 늘리면 생성 속도도 두 배인가?

보장되지 않는다. 병렬화 방식, 통신량과 문맥 길이에 따라 확장 효과가 달라진다.

초당 36.73토큰은 어떤 조건인가?

공개 표의 8,192토큰 문맥, NVFP4 모델, M5 Ultra 4대 텐서 병렬 조건이며 생성 속도는 128토큰 구간에서 측정됐다.

한국 기업이 먼저 비교할 지표는 무엇인가?

같은 업무의 품질, 첫 토큰 지연, 전체 완료 시간, 동시 요청 처리와 장비 운영을 포함한 총비용이다.