[태그:] 로컬 LLM

맥 스튜디오 두 대. 메타가 파라미터 8,160억 개짜리 Muse Spark Open을 공개하면서 실행 환경으로 내세운 구성이야. 데이터센터가 아니라 책상 위에서 돌린다는 얘기고, 이번 발표에서 메타가 가장 힘을 준 대목도 바로 여기였어. 메타는 이 모델을 “미국 오픈웨이트 모델 가운데 가장 뛰어난 모델”이라고 소개했고, 같은 급 모델 중에서는 처음으로 “M5 Ultra 맥 스튜디오 두 대와 최신 MLX 프레임워크로 데스크톱에서 실행된다”고 강조했어.

더버지가 눈여겨본 건 기술보다 두 회사의 관계였어. 평소 경쟁자로 꼽히던 메타와 애플이 출시를 함께 준비했고, 양쪽 CEO가 X에서 공개적으로 서로를 추켜세웠다는 점이야. 마크 저커버그는 새 맥 스튜디오에서 모델이 아주 잘 돌아가는 건 존 터너스와 애플 덕분이라고 썼어. 애플 CEO 존 터너스의 답은 이 정도 급과 규모의 모델을 책상에서 이렇게 효율적으로 돌리는 게 놀랍다는 것. 개발자에게 쓸모가 큰 건 덕담보다 그 밑에 깔린 실무 질문 쪽이야. 맥은 어떻게 큰 모델을 감당하나. 내 맥으로는 어디까지 되나. 직접 돌리려면 무엇을 깔아야 하나. 이 세 질문을 차례로 풀어 볼게.

VRAM 벽을 통합 메모리로 넘는 애플 실리콘

일반 PC에서 LLM을 돌릴 때 가장 먼저 부딪히는 건 그래픽카드의 VRAM이야. 모델 가중치가 GPU 메모리에 통째로 올라가야 속도가 나오는데, GPU가 직접 쓰는 메모리는 그래픽카드에 달린 만큼으로 정해져 있거든. 시스템 RAM을 아무리 늘려도 이 숫자는 그대로야. VRAM을 넘친 가중치는 일부가 시스템 메모리로 밀려나고, 그 순간 속도가 뚝 떨어져.

애플 실리콘은 출발점부터 달라. CPU, GPU, 뉴럴 엔진이 칩 패키지 안의 메모리 하나를 나눠 쓰는 통합 메모리(Unified Memory) 구조라서, 맥에 달린 메모리 대부분이 그대로 GPU 연산에 쓰여. CPU 쪽 데이터를 GPU 쪽으로 복사하는 단계도 없고. 그 결과 메모리를 넉넉히 단 맥은, 같은 용량의 VRAM을 그래픽카드로 맞추기 어려운 크기의 모델까지 올리는 장비가 돼. 큰 모델이 맥에 올라가느냐 마느냐는 결국 이 구조가 가른다고 봐야 해.

올라간다고 빠른 건 아니야. 용량과 속도는 따로 노는 문제거든. LLM은 토큰을 하나 만들 때마다 가중치를 메모리에서 읽어 와야 해서, 생성 속도는 연산 성능보다 메모리 대역폭에 더 크게 좌우돼. 같은 세대 애플 실리콘 안에서는 상위 칩일수록 대역폭이 넓어. 메타가 데모에 Ultra 칩을 넣은 맥 스튜디오를 쓴 것도 같은 이유로 보여.

한 대가 아니라 두 대라는 점도 그냥 넘기기 아까운 대목이야. 모델 하나를 두 기기의 메모리에 나눠 올렸다는 뜻이고, 뒤집어 말하면 맥 스튜디오 한 대의 통합 메모리로는 이 규모를 담기 어렵다는 얘기로 읽혀. MLX에는 여러 대의 맥을 네트워크로 묶어 모델 하나를 나눠 돌리는 분산 실행 기능이 있어. 메타의 두 대 구성도 이 기능을 쓴 걸로 보이지만, 원문에는 연결 방식에 대한 설명이 없어. 구체적인 방법은 애플이 따로 공개한 MLX 기술 글에서 확인하는 게 정확해.

넘파이를 닮은 MLX, 실제 작업은 mlx-lm 몫

MLX는 애플이 만든 ‘배열 프레임워크(array framework)’야. 넘파이처럼 배열을 다루는 도구라고 생각하면 크게 틀리지 않아. 차이는 설계 전제에 있어. 처음부터 애플 실리콘과 통합 메모리를 깔고 만들었기 때문에, 배열이 CPU 쪽에 있는지 GPU 쪽에 있는지 신경 쓸 일이 없어. 연산은 결과가 실제로 필요해지는 시점까지 미뤄 뒀다가 한꺼번에 처리하는 지연 실행(lazy evaluation) 방식이고.

LLM을 돌리는 입장이라면 아래 두 층만 구분해 두면 충분해.

• MLX 본체: 배열 연산과 GPU 가속을 맡는 기반 라이브러리. 파이썬 말고도 C++, 스위프트 API가 있어서 앱에 바로 넣기에도 좋아.
• mlx-lm: MLX 위에서 언어 모델을 내려받고, 실행하고, 양자화하고, 미세조정까지 하는 패키지야. 터미널 명령 몇 줄로 모델을 돌린다고 할 때 실제로 손에 쥐는 도구는 이쪽이야.

메타가 ‘최신 MLX’를 조건으로 붙였다는 점도 기억해 둬. 새로운 모델 구조는 프레임워크 쪽 업데이트가 함께 나와야 돌아가는 경우가 많아. 예전에 깔아 둔 버전을 그대로 쓰면 모델을 불러오는 단계에서 막히기 쉽다는 얘기야. 애플이 Muse Spark Open과 다른 오픈 모델 두 종을 다룬 MLX 기술 글을 같이 내놓은 것도 이런 지원 작업과 맞물린 걸로 보여.

816B 모델은 4비트로 줄여도 가중치만 약 408GB

장비를 고르기 전에 계산이 먼저야. 공식은 단순해. 가중치가 차지하는 메모리는 대략 ‘파라미터 수 × 파라미터 하나당 바이트 수’. 16비트 정밀도면 파라미터 하나에 2바이트, 8비트 양자화면 1바이트, 4비트 양자화면 0.5바이트가 들어. 여기에 Muse Spark Open의 총 파라미터 816B를 대입하면 이렇게 나와.

정밀도	파라미터당 용량	816B 모델 가중치(단순 계산)	특징
16비트	2바이트	약 1,632GB	원본에 가까운 품질, 메모리 부담이 가장 큼
8비트 양자화	1바이트	약 816GB	품질 손실이 적은 편, 용량은 절반
4비트 양자화	0.5바이트	약 408GB	로컬 실행에서 흔히 고르는 타협점, 품질 저하 정도는 모델마다 다름

표의 숫자는 가중치만 곱해 본 값이라, 실제로 돌릴 때는 메모리가 더 들어. 대화가 길어질수록 커지는 KV 캐시가 붙고, 운영체제와 다른 앱이 쓰는 몫도 따로 남겨 둬야 하거든. 그래서 기준은 ‘가중치 용량 + 여유분’으로 잡아야 해. 메타가 맥 두 대 구성에서 어떤 정밀도를 썼는지는 원문에 없어. 이 표를 메타의 실제 구성으로 받아들이면 안 돼.

용어 하나도 그냥 지나치기 어려워. 메타는 816B를 ‘총(total) 파라미터’라고 불렀어. 이 표현은 주로 전문가 혼합(MoE) 구조 모델에 붙어. 전체 파라미터와, 토큰마다 실제 계산에 쓰이는 활성 파라미터가 따로 있는 구조지. MoE 모델도 메모리에는 전체를 올려야 해. 대신 토큰당 연산량은 활성 파라미터만큼이라 덩치에 비해 생성이 빠른 편이야. 어느 쪽이든 위 표의 메모리 요구량이 줄어드는 건 아니라는 점은 같아. Muse Spark Open이 MoE인지는 원문만으로는 판단이 안 서니, 모델 카드를 직접 확인해 봐.

작은 양자화 모델로 시작하는 mlx-lm 설치와 점검

816B는 맥이 두 대 필요한 규모야. 개인 맥이라면 훨씬 작은 모델로 전체 흐름부터 익히는 게 순서고. 아래 경로는 ‘시스템 환경설정’이 ‘시스템 설정’으로 이름이 바뀐 뒤의 macOS 기준이야. 그 전 버전은 화면 표기가 조금 다르게 나와.

1. 칩과 메모리 확인: 화면 왼쪽 위 Apple 메뉴(사과 아이콘) → 이 Mac에 관하여에서 ‘칩’과 ‘메모리’ 항목을 봐. 시스템 설정 → 일반 → 정보에도 같은 내용이 있어. MLX는 애플 실리콘 전용이라, ‘프로세서’ 항목에 인텔 칩이 찍혀 있으면 여기서 멈춰야 해.
2. 터미널 열기: Finder → 응용 프로그램 → 유틸리티 → 터미널.
3. 파이썬 아키텍처 확인: 아래 명령의 결과로 arm64가 나와야 해. x86_64가 찍히면 로제타(Rosetta)로 돌아가는 인텔용 파이썬이라 MLX가 안 깔려. 이 경우엔 애플 실리콘용 파이썬을 새로 설치해.

   python3 -c 'import platform; print(platform.machine())'

4. 가상환경을 만들고 mlx-lm 설치: 업데이트가 잦은 패키지라 -U를 붙여 최신 버전을 받는 습관을 들이자. 앞에서 본 ‘최신 MLX’ 조건과도 맞닿는 부분이야.

   python3 -m venv ~/mlx-env
   source ~/mlx-env/bin/activate
   pip install -U mlx-lm

5. 첫 실행: 허깅페이스의 mlx-community 같은 계정에는 MLX 형식으로 변환하고 양자화까지 마친 모델이 많이 올라와 있어. 저장소 이름만 넣으면 처음 실행할 때 알아서 내려받아.

   mlx_lm.generate --model 저장소/모델이름 --prompt '통합 메모리를 한 문단으로 설명해줘'

6. 대화형·서버형으로 넓히기: 대화를 이어 가려면 mlx_lm.chat, 다른 앱에서 API로 부르려면 mlx_lm.server. 서버는 OpenAI 호환 형식으로 엔드포인트를 띄워 주니까, 기존 코드에서 주소만 바꿔 붙이면 돼. 터미널이 부담스럽다면 MLX 엔진을 지원하는 LM Studio 같은 GUI 앱도 있어.

   mlx_lm.chat --model 저장소/모델이름
   mlx_lm.server --model 저장소/모델이름

7. 원하는 모델의 MLX 버전이 없을 때: 직접 변환하면 돼. -q를 붙이면 양자화까지 한 번에 끝나고, –q-bits로 4비트나 8비트를 골라.

   mlx_lm.convert --hf-path 원본저장소/모델이름 -q --q-bits 4

생성이 유난히 느리거나 맥 전체가 버벅인다면 메모리부터 의심해. Finder → 응용 프로그램 → 유틸리티 → 활성 상태 보기 → 위쪽 ‘메모리’ 탭으로 가면, 창 아래쪽에 ‘메모리 압력’ 그래프가 있어. 초록색이면 여유가 있다는 뜻. 그래프가 노란색이나 빨간색으로 바뀌거나 ‘사용된 스왑’이 빠르게 불어나면, 모델이 메모리에 다 들어가지 못해 디스크까지 끌어다 쓰는 중이야. 이때는 비트를 더 낮춰 양자화한 모델로 바꾸고, 그래도 안 되면 더 작은 모델로 내려가. 브라우저처럼 메모리를 많이 먹는 앱을 닫는 것도 도움이 돼.

저장 공간도 따로 봐야 해. 내려받은 모델 파일은 기본적으로 홈 폴더의 .cache/huggingface 아래에 쌓이는데, 이름이 점으로 시작하는 숨김 폴더라 Finder에서 평소엔 잘 안 보여. 공간이 모자라면 시스템 설정 → 일반 → 저장 공간과 함께 이 폴더도 열어 봐.

코드는 맥 밖으로 안 나가지만, 한국어 성능은 직접 확인해야

가장 크게 달라지는 건 데이터가 가는 곳이야. 클라우드 AI 서비스에 넣은 코드와 문서는 외부 서버로 넘어가지만, 로컬에서 돌리면 맥 밖으로 나가지 않아. 사내 소스코드나 고객 정보 때문에 외부 AI를 막아 둔 회사, 망분리로 인터넷 연결 자체가 제한된 곳이라면 이 차이 하나로 도입 여부가 갈려. 걸리는 점이 하나 있긴 해. 모델 파일을 처음 받을 때는 인터넷이 필요하다는 것. 망분리 환경이라면 파일 반입 절차부터 확인해 둬.

한국어 품질은 별도 검증 대상이야. 메타가 내세운 Muse Spark Open의 강점은 긴 호흡의 작업, 복잡한 소프트웨어 엔지니어링, 여러 단계에 걸친 추론이고, 한국어 성능 얘기는 원문에 없어. 영어 성적이 좋다고 해서 한국어 문서 요약이나 존댓말 처리까지 같은 수준이라고 보긴 어려워(일반적인 다국어 모델 경향을 근거로 한 추측이야). 실제 업무 문서를 넣어 직접 돌려 보는 게 유일한 확인 방법이야.

라이선스는 이름만 보고 판단하면 곤란해. ‘오픈웨이트’는 학습이 끝난 가중치 파일을 공개했다는 뜻이야. 학습 데이터와 코드까지 모두 내놓는 오픈소스와는 다른 개념이지. 상업적 이용 범위, 사용자 수 제한, 파생 모델 배포 조건도 모델마다 다르고. 회사 서비스에 붙일 생각이라면 Muse Spark Open의 라이선스 문서를 법무 담당자와 같이 읽어 보길 권해.

물리적인 벽도 있어. 앞의 단순 계산대로라면 이 급 모델은 4비트로 줄여도 가중치만 약 408GB, 수백 GB 단위야. 메모리를 따지기 전에 내려받는 시간과 저장 공간부터 만만치 않을 거야. 그렇게 보면 개인 개발자에게 Muse Spark Open은 당장 쓸 도구라기보다 맥과 MLX로 어디까지 가능한지 보여 주는 기준점에 가까워. 일상 업무에는 같은 MLX 환경에서 돌아가는 작은 오픈 모델이 당장 쓰기 좋은 선택지로 보여.

확인된 것과 아직 불확실한 것

확인된 것

• 메타는 Muse Spark Open을 총 816B 파라미터의 네이티브 멀티모달 모델로 소개하고 가중치를 공개했다.
• 메타는 M5 Ultra 맥 스튜디오 두 대와 최신 MLX 프레임워크로 이 모델을 데스크톱에서 실행한다고 밝혔다.
• 메타와 애플은 이 출시를 함께 준비했고, 저커버그와 터너스는 X에서 공개적으로 서로를 지지했다.
• 애플은 MLX와 Muse Spark Open, 그 밖의 오픈 모델 두 종을 다룬 기술 글을 공개했다.

아직 불확실한 것

• 맥 두 대 구성에서 쓴 정밀도(양자화 비트)와 두 기기를 연결한 방식
• 모델이 MoE 구조인지, 활성 파라미터는 얼마인지
• MLX 환경에서 이미지 같은 멀티모달 입력까지 지원하는지, 텍스트만 되는지
• 한국어 성능과 라이선스의 상업적 이용 조건
• M5 Ultra를 단 맥 스튜디오의 국내 판매 가격과 메모리 구성(이 글의 근거 자료에 없는 정보라 다루지 않았다)

로컬 LLM용 맥은 돌릴 모델 크기에서 거꾸로 고른다

816B 데모를 보고 고사양 맥부터 장바구니에 넣는 건 순서가 틀렸어. 결제하기 전에 기준 세 가지부터 세워 두자.

• 용도: 코드 자동완성이나 대화처럼 응답 속도가 바로 체감되는 작업이면 메모리 대역폭이 넓은 상위 칩이 유리해. 밤새 문서를 요약하는 배치 작업이라면 우선순위가 뒤집혀. 속도보다 용량이 먼저.
• 호환성: MLX는 애플 실리콘에서만 돌아가. 게다가 애플 실리콘 맥은 메모리가 칩과 한 패키지로 묶여 있어서 사고 나서 늘릴 방법이 없어. 돌리고 싶은 모델 크기를 앞의 공식으로 계산하고, 여유분을 더한 용량을 처음부터 골라야 하는 이유가 여기 있어.
• 예산: 맥 가격은 칩 등급보다 메모리 옵션에서 크게 갈리는 경우가 많아. 예산이 빠듯하면 칩을 한 단계 낮추고 메모리를 올리는 쪽이 로컬 LLM에는 대체로 더 효과적이야. 모델이 아예 안 올라가면 대역폭이 넓어 봐야 쓸 데가 없으니까. 반대로 쓰고 싶은 모델이 어떤 구성으로도 한 대에 안 들어간다면, 맥 여러 대를 묶는 비용과 클라우드 API 비용을 나란히 놓고 비교해야 해.

순서는 이렇게 잡으면 돼. 먼저 지금 가진 맥에서 작은 양자화 모델로 mlx-lm을 돌려 봐. 활성 상태 보기를 띄워 두고 메모리 압력을 지켜보면, 어느 크기에서 한계가 오는지 감이 잡혀. 그다음 실제로 쓰고 싶은 모델의 파라미터 수와 정밀도로 필요한 메모리를 계산하고, 그 숫자에 맞는 구성을 고르면 돼. 메타와 애플의 협업이 보여 준 건 ‘맥 두 대면 816B 모델도 돌아간다’는 상한선이야. 모두가 그 구성을 사야 한다는 신호로 읽을 이유는 없어.

출처: The Verge