1. 문제 정리: “누가 더 빠른가”보다 계약이 먼저다
(1) 엔진과 패키징 혼동: 같은 GGUF라도 llama.cpp와 MLX에서 메모리 곡선이 다르다. MetalRT 계열은 직접 Metal 커널에 가깝고, Python MLX 서비스와 튜닝 축이 다르다.(2) 피크 tok/s만 추적: prefill과 decode 병목은 다르며, 다중 사용자에서는 락 경쟁이 수치를 깎는다.(3) 통합 메모리 경쟁: swap이 지배하면 엔진이 무엇이든 느려 보인다. 먼저 토폴로지를 바꿔야 한다.
2. 세 런타임의 역할
| 런타임 | 2026년 관점 | 적합/비용 |
|---|---|---|
| MetalRT 계열 | Apple Silicon에서 직접 Metal 추론, decode 처리량·멀티모달 확장 | decode 극한 추구층, 툴체인이 새로워 버전 고정 필수 |
| MLX | 통합 메모리와 잘 맞고 Python/Swift와 같은 레포에서 서비스화 용이 | 엔지니어링 부담, 원클릭 UI보다 학습 비용 큼 |
| llama.cpp | GGUF 생태계가 넓고 CLI/서버 예제가 많음 | Mac에서 실용적이나 기본값은 만능이 아님, 기종별 재프로파일 |
2b. prefill과 decode를 분리해 측정
Prefill은 KV 기록, Decode는 토큰 생성이다. 커뮤니티 decode 수치에 컨텍스트 길이·배치 전략이 없으면 긴 문서 RAG에는 무의미하다.
| 단계 | 우선 지표 | 흔한 실수 |
|---|---|---|
| Prefill/TTFT | 첫 토큰 시간, 8K 이상에서 비선형 폭증 여부 | 짧은 프롬프트만 측정해 실제 RAG에서 붕괴 |
| Decode | 안정 tok/s, 길이에 따른 감속, CPU/GPU 경합 | 배치를 과도하게 올려 스래싱 유발 |
| 혼합 부하 | 메모리 압력, swap, IDE 프레임 드랍 | 다른 앱을 닫은 “청정 벤치”만 신뢰 |
3. 다섯 단계: 실행에서 재현으로
- 부하 유형 고정: 채팅·RAG·야간 배치 목표가 다르다. 지연과 배치 작업은 엔드포인트를 나눈다.
- 모델·양자화 고정: 대표 GGUF/MLX와 양자화 한 벌을 정한 뒤 엔진을 가로질러 비교한다. Q8 vs Q4 바꿔 끼우기는 비교가 아니다.
- 측정 통일: 동일 프롬프트·컨텍스트·배치로 TTFT·decode·긴 세션 감속을 표로 남기고 SoC 세대와 엔진 버전을 명시한다.
- 단계적 튜닝: 1라운드 스레드·ctx/배치, 2라운드 KV·동시성, 3라운드에서 모델 교체. 다섯 변수를 동시에 돌리지 않는다.
- 1주 혼합 재생: IDE·브라우저·내보내기를 켠 상태에서 추론을 겹친다. 창작 시간대에 메모리 경고가 반복되면 오프로드를 검토한다.
4. 기획 자료에 인용 가능한 수치(벤더 수치 아님)
검토 자료용 가이드:
- 대화형 세션은 OS와 상주 앱에 최소 8GB를 남긴 뒤 가중치·KV를 추정한다.
- 무거운 IDE+긴 컨텍스트+타임라인이 겹치면 동시 추론 스트림은 1~2개가 현실적이다.
- 주 20시간 이상 노트북을 고부하로 쓰면서 이동이 필요하면 전용 원격 노드의 TCO가 유리해지기 쉽다.
5. 원격 Mac으로 보낼지 판단표
| 신호 | 권장 |
|---|---|
| 감사 로그가 필요한 공유 OpenAI 호환 엔드포인트 | 원격에서 쿼터, 노트북은 가벼운 실험·튜닝 |
| 메모리 압력으로 편집·IDE가 끊김 | 추론을 밖으로 보내거나 컨텍스트·양자화를 줄인다 |
| MetalRT/MLX/llama.cpp 장기 A/B를 하되 주력기를 오염시키고 싶지 않음 | 고정 이미지 원격 Mac을 실험 샌드박스로 |
| 24/7 서비스 | 고정 토폴로지·모니터링에는 원격 Mac이 유리 |
6. FAQ
셋을 동시에? 가능하지만 포트와 바인딩을 문서화한다. 중복 다운로드로 디스크가 마르는 경우가 많다.커뮤니티 수치 재사용? 불가, 고정 프롬프트로 재측정.언제 멈출까? 주 3회 이상 창작이 추론과 충돌하면 부하 이전.
7. 심화: 엔진 선택은 팀 자산
2026년 마찰은 토크나이저보다 재현 가능한 추론 계약에 있다. 개발·스테이징·데모에서 같은 런타임 버전·포트·인증을 유지할 수 있는가. 엔진 선택과 버전을 README·CI 이미지에 고정하는 것은 Node나 Python 버전을 고정하는 것과 같은 난이도의 기본 훈련이다.
무거운 추론을 노트에서 빼는 것은 CI에서 빌드를 빼는 것과 같은 역할 분리이다. MLX OpenAI 호환 API 글을 읽은 뒤에도 피로하다면 서비스 계층을 원격에 두는 것이 다음 합리적 단계다.
8. 정리: 단일 Mac 다중 엔진의 한계와 MACGPU
(1) 한계: 동시에 여러 엔진을 시험하면 가중치·포트·의존성이 복제되고 통합 메모리는 중복 캐시로 채워진다. 수면·OS 업데이트도 24/7을 깨뜨린다.
(2) 원격의 이점: 재현 이미지에 추론을 고정하고 단말은 얇은 클라이언트로 둔다. 호스트는 발열·배터리 걱정 없이 모니터링하기 쉽다.
(3) MACGPU: 예측 가능한 OpenAI 호환 엔드포인트와 공유 쿼터가 필요할 때 시간제 원격 Apple Silicon은 반복적인 본체 업그레이드보다 빨리 ROI에 도달하기 쉽다. MLX·llama.cpp 상주와 장시간 작업·API는 원격으로. 아래 CTA는 공개 요금·도움말(로그인 불필요).