4대의 Mac에서 로컬 AI 구동: MLX 용량, 속도 및 신뢰 경계

로컬 AI는 리더보드 질문을 받기 전에 하드웨어 질문을 받습니다. 즉, 모델과 그 작업 메모리가 기기에 들어갈 수 있는가 하는 문제입니다. Apple의 분산된 MLX 데모는 여러 Mac Studio를 사용하여 매우 큰 Meta 모델을 책상에서 사용 가능하게 만드는 방법을 보여줍니다. 자체 측정 결과 또한 두 번째 컴퓨터를 추가해도 생성 속도가 거의 변하지 않는 이유를 보여줍니다.

이것은 10월 17일자 에디션이며, 10월 18일에 게시되었습니다. 하드웨어 출처는 10월 15일에 게시되었고, 아래의 OpenCode Console 공지는 명시적으로 10월 18일 GMT+7 자정 업데이트입니다. 날짜가 중요한 이유는 흥미로운 결과가 며칠 동안 순환할 수 있는 반면, 진행 중인 보안 공지는 몇 시간 만에 변경될 수 있기 때문입니다.

요약 (TL;DR)

• Apple은 네 대의 M5 Ultra Mac Studio에서 Muse Spark Open이 인간 독서 속도보다 빠르게 생성됨을 보고했습니다. 이는 명시된 모델, 정밀도 및 컨텍스트를 가진 공급업체 벤치마크입니다.
• 더 많은 기기는 용량을 제공합니다. 파이프라인 병렬 처리(Pipeline parallelism)와 텐서 병렬 처리(Tensor parallelism)는 이 용량을 다르게 사용하며, 이는 응답의 지연 시간(latency)에 다른 영향을 미칩니다.
• 첫 토큰까지 걸리는 시간(time to first token)은 프롬프트 처리 및 대기 시간을 나타냅니다. 초당 토큰 수(Tokens per second)는 생성을 나타냅니다. 이 두 가지 시계를 분리하여 유지해야 합니다.
• 구매하기 전에 대표적인 작업을 테스트하고 프롬프트와 자격 증명(credentials)을 처리하는 서비스를 검사하십시오. 선택된 벤치마크 지도는 많은 작업들을 측정하지 못합니다.

네 대의 Mac이 가능하게 만든 것

Apple's article은 하나의 Mac Studio에서 시작하여 MLX와 RDMA-over-Thunderbolt 드라이버를 사용하여 확장됩니다. MLX는 Apple silicon용 머신러닝 오픈 소스 배열 프레임워크입니다. Mac 내부에서는 통합 메모리(unified-memory) 구조 덕분에 CPU와 GPU가 공유 메모리를 사용하여 작업할 수 있습니다.

여러 대의 Mac에 걸쳐 통신은 여전히 실제적인 경계입니다. 개별 기기들은 자체 메모리와 실행 환경을 유지합니다. 소프트웨어는 모델을 분할하고 필요한 중간 결과를 그들 사이로 이동시킵니다. 네 대의 컴퓨터가 하나의 일반적인 공유 메모리 버스로 변한다고 상상해서는 안 됩니다.

본문에서 가장 큰 모델은 Meta의 Muse Spark Open입니다. Apple의 표는 전체 파라미터와 활성 파라미터를 분리합니다. 이는 Mixture-of-Experts (MoE) 아키텍처이므로, 추론 단계에서는 모델 전문가(expert)의 일부만을 사용합니다. 이로 인해 개별 단계의 컴퓨팅 부하는 줄어들지만, 저장해야 할 상당한 크기의 모델은 남아 있습니다.

Apple에 따르면 네이티브 정밀도에서 파라미터 저장 공간만 해도 1.6 TB를 초과할 것이라고 합니다. 이를 4비트 NVFP4로 평가하면 그 용량이 약 493 GB로 줄어듭니다. 단일 지원 Mac Studio 구성은 512 GB에 도달할 수 있지만, 추론 과정에서는 중간 계산을 위한 메모리도 필요합니다. 따라서 헤드라인의 가중치 크기만으로는 전체 작업 부하가 적합한지 판단하기 어렵습니다.

이것은 유용한 구매 구별점입니다. 구성 상한선(configuration ceiling)이 같은 제품명을 가진 모든 기기의 용량을 의미하는 것은 아닙니다. 가중치 저장 공간 역시 런타임 요구 사항의 일부일 뿐입니다. 추가적인 작업 공간(workspace)이 거의 가득 찬 메모리 구성마저도 부적절하게 만들 수 있습니다. 심지어 초기 모델 파일이 들어맞는 것처럼 보이더라도 말입니다.

저희 영상은 그 작업 공간을 추가적인 정량화되지 않은 요구 사항으로 표현합니다. 저희는 추가적인 메모리 측정값을 발명하거나 개념적 다이어그램이 하드웨어 추적(hardware trace)이라고 가장하지 않습니다. Apple의 텍스트가 적합성 문제를 확립하고, 다이어그램이 그 관계를 설명해 줍니다.

파이프라인 병렬 처리: 레이어 분할

파이프라인 병렬 처리(Pipeline parallelism)는 모델을 계층(layer) 순서에 따라 나눕니다. Apple의 두 대 기기 설명에서는, 첫 번째 Mac이 초기 레이어를 평가하고 그 출력을 두 번째 Mac으로 보내고, 두 번째 Mac은 후반부 레이어를 평가합니다.

단일 생성 토큰의 경우, 나중에 생성되는 작업은 이전에 나온 결과에 의존합니다. 동일한 토큰이 계산의 양쪽 절반을 동시에 받는 것은 아닙니다. 따라서 Apple은 계층(layer)들이 여전히 순차적으로 평가되기 때문에 파이프라인 병렬 처리(pipeline parallelism)를 사용한 디코딩 속도가 일반적으로 단일 머신과 매우 유사하다고 보고합니다.

단일 머신 비교에는 하나의 Mac에 맞는 모델을 사용했습니다. Qwen과 Mistral이 이러한 기준선(baseline)을 제공합니다. 이 기사는 단일 Mac Muse 생성 기준선을 확립하지 못했는데, 이는 대규모 Muse 구성이 여러 대의 머신보다 더 많은 자원을 필요로 하기 때문입니다. 가상의 기준선을 설정하는 것은 아키텍처 설명을 오해를 불러일으키는 경주(race)로 만들 것입니다.

프롬프트 처리(Prompt processing)는 다른 결과를 가져올 수 있습니다. Apple은 또한 대규모 컨텍스트에서 파이프라인 프리필(pipeline prefill)의 이점을 보고합니다. 파이프라인이 절대 도움이 될 수 없다는 일반적인 주장은 그 연구 결과 중 일부를 무시하는 것입니다. 유용한 질문은 귀하의 애플리케이션이 어떤 단계와 워크로드를 가속화해야 하는지입니다.

이것이 바로 첫 번째 응답의 토큰 속도 변화가 적더라도 두 번째 머신이 여전히 가치가 있을 수 있는 이유입니다. 이는 이전에 사용 가능한 메모리에서 실행할 수 없었던 모델을 가능하게 할 수 있습니다. 용량 결과는 여전히 가치 있습니다. 그것은 단순히 두 배의 속도를 약속하는 것과는 다른 구매 질문에 답하기 때문입니다.

텐서 병렬 처리 (Tensor parallelism): 각 계층 공유

텐서 병렬 처리는 하나의 계층(layer)을 가로질러 작업을 분할합니다. 여러 대의 머신이 해당 계층의 조각들을 계산하고, 그 결과를 결합한 다음 계속 진행합니다. 이는 단일 토큰에 필요한 단계 내에서 병렬 작업을 도입하여 향상된 생성 속도로 가는 경로를 제공합니다.

또한 반복적인 통신을 유발합니다. 부분적인 결과들을 결합하는 것은 계산으로 절약되는 양이 조정 비용을 초과할 만큼 충분히 저렴해야 합니다. 상호 연결(interconnect)과 그 구현은 측정 없이 대체할 수 있는 사후 고려 사항이라기보다는 추론 시스템의 일부가 됩니다.

Apple은 이 구성을 위해 Thunderbolt를 통해 낮은 지연 시간의 RDMA(Remote Direct Memory Access)를 사용합니다. 출처는 드라이버와 MLX 백엔드 버전을 식별하며, 일반적인 이더넷이 성능 주장에서 테스트된 배열을 조용히 대체해서는 안 됩니다. 하드웨어, 운영체제 지원 및 실제 소프트웨어 백엔드가 모두 중요합니다.

개념 애니메이션에서는 동일한 모델 ID가 순차적 분할에서 같은 레이어의 조각들로 이동하는 것을 보여줍니다. 커넥터들은 필요한 관계들을 보여줍니다. 이들의 펄스는 측정된 패킷 트래픽이나 정확한 하드웨어 타이밍을 재현한다고 주장하지 않습니다.

실제 프로덕션 결정을 위해서는 구성 세부 정보를 유지해야 합니다. 실제로 소유하고 있는 머신과 메모리, 운영체제 요구 사항, 통신 토폴로지, 모델 형식 및 컨텍스트 길이를 확인하십시오. 유사하게 이름 붙여진 시스템이라도 다른 병목 현상을 가질 수 있습니다.

보고된 결과의 두 가지 클럭

Apple은 4대의 Mac 클러스터에서 Muse Spark Open이 초당 36 토큰을 초과한다고 보고합니다. 관련 생성 수치는 8,192 토큰 컨텍스트를 사용합니다. 이는 M5 Ultra 시스템 및 출처에 명시된 평가 형식을 사용한 공급업체 측정값입니다.

추가 실험에서는 더 큰 컨텍스트에서 첫 번째 토큰을 기다리는 시간을 연구했습니다. 보고된 값은 다음과 같습니다:

이 실험은 65,536 토큰 컨텍스트를 사용합니다. 여기서의 대략 10초 감소는 대기 시간 결과입니다. 이는 새로운 디코드 처리량 수치가 아니며, 작은 컨텍스트 생성 차트에 혼합되어서는 안 됩니다.

이 클럭들은 서로 다른 사용자 경험을 설명합니다. 큰 프롬프트는 답변이 이후 편안한 속도로 스트리밍하더라도 상당한 초기 대기 시간을 유발할 수 있습니다. 짧은 코딩 상호 작용은 지속적인 벤치마크 실행보다 시작 및 도구 지연 시간에 더 신경 쓸 수 있습니다.

정밀도 경계(precision boundary) 또한 존재합니다. Apple의 표는 Muse를 NVFP4에서, 그리고 더 작은 비교 모델들을 각자의 네이티브 형식으로 평가했습니다. 한 Hacker News 반응은 그 비교에 의문을 제기했으며, 표 자체에 형식적 사실들이 제공됩니다. 이것이 형식 간 측정된 품질 차이를 확립하는 것은 아닙니다. 단지 어떤 비교가 실제로 실행되었는지 알려줄 뿐입니다.

저희는 이 Mac 클러스터를 소유하거나 재현하지 않았습니다. 연구 기록에는 다른 모델에 대한 비공식 독자 주장이 남아 있지만, 이를 검증할 통제된 동일 모델 아티팩트는 없었습니다. 따라서 저희는 Apple의 수치를 공급업체 보고(vendor-reported) 자료로 제시하고, 비교 불가능한 결과로부터 독립적인 패배를 구성하는 것을 피합니다.

로컬 AI 구매에는 자체 워크로드 분석이 필요합니다

스스로 판단할 수 있는 작업부터 시작하세요. 프롬프트 길이, 도구 호출(tool calls), 완성 요구사항(completion requirements) 및 승인 확인(acceptance checks)을 유지해야 합니다. 모델이 적합한지, 상호작용 대기 시간이 얼마나 되는지, 유용한 출력이 얼마나 빨리 도착하는지, 그리고 전체 작업이 성공하는지를 측정하세요.

실행 중인 프로세스는 콜드 스타트업(cold startup)과는 다르게 작동할 수 있습니다. 가중치(weights)를 편안하게 저장할 수 있는 모델이라도 프롬프트와 중간 상태가 커질 때 어려움을 겪을 수 있습니다. 더 높은 토큰 속도(token rate)는 다른 단계에 의해 지배되는 상호작용에는 거의 영향을 미치지 않을 수 있습니다. 이것들이 전체 경로를 기록해야 하는 이유들입니다.

활용률 또한 경제성 측면에서 중요합니다. Apple은 모든 워크로드에 대해 호스팅된 API와 비교할 보편적인 손익분기점 가격을 제공하지 않았습니다. 모델, 사용 빈도 및 필요한 구성이 그 계산에 영향을 미칩니다. 가끔 사용하는 비서가 가장 많은 시간을 책상을 장식하는 데 소비하며 값비싼 기계를 남겨둘 수 있습니다.

로컬 추론(Local inference)은 실제 설정이 프롬프트를 로컬로 유지할 때, 프롬프트 주변에 유용한 관리적 경계(administrative boundary)를 제공할 수 있습니다. 클라이언트, 외부 서비스, 인증 및 모든 공급자 연결과 같은 주변 구성 요소들도 검사해야 합니다. 모델의 물리적 위치가 워크플로우가 사용하는 모든 서비스를 설명하는 것은 아닙니다.

Mercor의 지도: 누락된 커버리지는 의문을 남깁니다

Mercor는 선택된 AI 벤치마크 세트를 미국 업무 과제 분류 체계(US work-task taxonomy)에 매핑했습니다(https://www.mercor.com/research/labor-index/benchmark-map/). 이 지수는 근간이 되는 분류 체계의 거의 19,000개 과제 중 약 900개의 커버된 과제를 포함하고 있습니다.

이 지도는 근무 시간의 90%가 벤치마크 커버리지(benchmark coverage)가 적거나 없는 과제에 사용된다고 추정합니다. 이것은 커버리지 발견일 뿐입니다. 이 수치가 90% 실패율을 측정하거나 해당 직무가 자동화되었다는 것을 증명하는 것은 아닙니다. 미측정된 역량(Unmeasured capability)은 여전히 열려 있는 질문으로 남아 있습니다.

이 매핑 작업은 AI의 도움을 받아 수행되었으며, Mercor 자체 벤치마크 프롬프트의 일부에 대해 전문가 검토가 이루어졌습니다. 검토자들은 자신이 판단한 첫 번째 선택 매핑 중 약 4분의 3를 수용했습니다. 이 방법론의 검토 경계는 그 큰 헤드라인 비율과 함께 주목할 가치가 있습니다.

구매자 입장에서 실질적인 결과는 간단합니다. 일반적인 리더보드가 자체 업무에서 나온 대표 과제와 승인 확인을 대체할 수는 없습니다. 세련된 데모 이후의 어색한 부분들 역시 평가에 포함되어야 합니다.

심야 업데이트: OpenCode Console 범위

수정된 공식 OpenCode 공지는 콘솔 사용자 1.4%에 영향을 미친 보안 침해를 설명합니다. 이 범위는 외부 제공업체(external providers)가 연결된 하위 집합으로 좁혀졌으며, 해당 사용자는 이메일로 통보받았다고 합니다. 회사는 이를 대규모 증류 공격(large-scale distillation attack)이라고 부르며 사건이 진행 중이라고 설명합니다.

해당 진술은 공개적인 근본 원인이나 모든 로컬 OpenCode 설치에서의 침해 증거를 제공하지 않습니다. 답변에는 서비스 제공업체 크레딧 손실을 보고하는 사용자들의 글이 포함되어 있으며, 이러한 보고서들은 각각의 손실 또는 보상 약속을 독립적으로 확립하지는 못합니다.

Apple의 기사에서는 OpenCode를 로컬 MLX 서버에 연결할 수 있는 클라이언트로 명시적으로 언급합니다. 클라이언트 인터페이스와 호스팅되는 콘솔은 설정의 별개 부분입니다. 해당되는 경우 공식 공지 및 제공자 계정 복구 지침을 따르고, 자격 증명을 보유한 특정 서비스를 검사하십시오. 저희는 어떠한 추측성 공격 경로도 도출하지 않았습니다.

결론: 재검토 필요 (NEEDS REVIEW)

클러스터를 구매하기 전에 실제 워크로드를 테스트해 보시기 바랍니다. Apple의 결과는 대규모 로컬 추론을 더 실용적으로 만들었으며, 그 파이프라인 측정값은 용량만으로는 원하는 응답 속도를 예측할 수 없음을 보여줍니다. 작업 평가와 서비스 검토를 구매 주문서 옆에 두십시오.

FAQ

Mac 2대를 사용하면 답변을 두 배 빠르게 얻을 수 있나요?

Apple의 파이프라인 결과는 일반적으로 토큰의 레이어 평가가 순차적으로 이루어지도록 유지합니다. 텐서 병렬성(Tensor parallelism)은 각 레이어의 작업을 공유하고 결과를 반복적으로 결합합니다. 실제로 사용하는 방식과 워크로드를 측정하십시오.

Apple의 수치가 가장 큰 모델에서 더 나은 답변을 보장하나요?

인용된 수치는 추론 성능을 측정합니다. 표는 평가 정밀도를 공개합니다. 저희에게는 통제된 품질 재현이 없으므로, 필요한 작업에 대한 승인 검사를 사용하십시오.

로컬 모델을 사용하면 주변의 모든 서비스가 로컬이 되나요?

실제 클라이언트, 엔드포인트 및 자격 증명을 보유한 서비스를 추적하십시오. Apple은 로컬 MLX 서버를 설명하지만, Overnight OpenCode 공지는 호스팅되는 콘솔 사용자 중 특정 하위 집합에 명시적으로 관련된 것입니다. 이 범위들을 분리하여 유지하십시오.

출처