M5 Ultra vs 2 DGX Sparks…The Number You''re Not Looking At

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

M5 Ultra와 DGX Spark 두 대를 비교할 때 놓치기 쉬운 숫자는 첫 토큰까지의 대기시간이며, 입력 길이·출력 길이·동시 사용자 수에 따라 유리한 구성이 달라진다.

📌 핵심 요점

1. 두 구성 모두 메모리는 합계 256GB지만 작동 방식은 다르다. Mac은 한 장비에 모델을 올리고, Spark 두 대는 모델을 나누어 처리하며 노드 사이에서 결과를 교환한다.
2. 짧은 입력과 단일 사용자 조건에서는 출력 속도가 비슷하다. DeepSeek는 양쪽이 약 38토큰/초였고, ‘Quen’ 모델은 Mac 45토큰/초, Spark 두 대 38토큰/초로 Mac이 앞섰다.
3. 긴 입력에서는 첫 응답 대기시간 차이가 커진다. 32K 입력 차트에서 DeepSeek는 Mac 44초, Spark 두 대 16.5초였고, ‘Quen’은 각각 26초와 11.2초였다.
4. 추론 엔진과 캐시가 실제 체감을 바꾼다. Mac의 DeepSeek 출력은 llama.cpp 약 40토큰/초에서 MLX 53토큰/초로 높아졌지만 측정 경로가 달랐고, 16K 문맥을 재사용한 후속 질문에서는 양쪽의 대기시간이 크게 줄었다.
5. 다중 사용자 환경에서는 전체 처리량과 개인별 속도를 구분해야 한다. 영상은 Mac을 주로 1~2명, Spark 두 대를 약 4명 규모에 적합한 구성으로 평가하며, 큰 모델을 8명이 공유하는 상황에는 부담이 크다고 설명한다.

🧩 배경과 문제 정의

영상은 큰 모델을 로컬에서 실행하는 개발자와 소규모 팀을 위해 M5 Ultra 기반 Mac Studio 한 대와 DGX Spark 두 대를 비교한다. Mac은 메모리 256GB를 한 장비에 갖추고, Spark는 각 128GB를 연결해 합계 256GB를 구성한다. 저장공간도 합계 8TB로 맞췄지만, 모델을 처리하는 구조와 소프트웨어 환경은 다르다.

핵심 문제는 같은 메모리 용량과 비슷한 출력 속도가 같은 사용 경험을 뜻하는지다. 발표자는 입력 전체를 읽는 단계와 토큰을 차례로 출력하는 단계를 구분하고, 긴 입력·캐시 재사용·다중 사용자 조건을 통해 첫 응답 대기시간의 중요성을 보여준다. 영상의 수치는 해당 장비 구성과 측정 조건에서 나온 결과이며, 일부 비교는 추정 또는 미완료 상태다.

🕒 시간순 섹션별 상세정리

1. 첫 출력 대결과 비교 장비 소개

• 두 장비가 각각 800토큰을 출력한 첫 시연에서 M5 Ultra는 38.7토큰/초, Spark 두 대는 34.3토큰/초를 기록한다. 발표자는 이후 조건에서는 차이가 더 커진다고 예고한다. [00:34]
• Mac은 256GB 단일 장비, Spark는 128GB 장비 두 대를 연결한 구성이다. 노드 간 직접 메모리 접근을 설명하며 RDMA 기반 연결을 보여준다. [01:10]
• 영상 기준 Mac 구성은 약 1만4천 달러, Spark 두 대는 약 1만 달러에 케이블 비용이 추가된다. 양쪽 저장공간은 합계 8TB이며, 큰 로컬 모델과 소규모 팀 운영이 비교 대상이다. [01:40]

2. Merlin AI 협찬 소개

• 협찬 구간에서는 여러 AI 모델을 한곳에서 선택하고 웹페이지 요약·심층 조사·검색을 수행하는 Merlin AI를 보여준다. 발표자는 할인 적용 시 연 60달러라고 안내하며, 할인 유지 기간은 모른다고 드러낸다. [02:54]

3. Spark 두 대가 모델을 나누는 방식

• 추론·서빙 엔진이 텐서 병렬 방식으로 각 모델 레이어를 두 노드에 나누며, 토큰을 처리할 때마다 다음 레이어로 넘어가기 전에 결과를 교환한다고 보여준다. [03:42]
• DeepSeek V4 Flash는 영상에서 약 150~160GB 규모로 설명되어 128GB Spark 한 대에는 들어가지 않는다. 모델 외에 문맥을 위한 공간도 필요하다. [04:03]
• 두 노드에 모델을 나누어 올린 상태에서 한 노드의 사용량은 약 111GB로 표시된다. Mac은 전체 모델을 한 장비에 적재한다. [04:22]

4. 모델 파일과 추론 엔진의 비교 조건

• 양쪽은 같은 모델을 사용하지만 파일은 다르며, 각각 4비트로 양자화된 파일을 사용한다. 따라서 동일한 파일을 동일한 엔진으로 실행한 비교는 아니다. [04:32]
• Spark는 전사에서 ‘VLM’으로 표기된 엔진을 사용하고, Mac은 llama.cpp와 MLX를 시험한다. 비교 모델로 DeepSeek V4 Flash와 전사상 ‘Quen 3.8 Flash Next’를 보여준다. [04:59]

5. 입력 처리와 출력 생성은 다른 단계

• 먼저 모델이 프롬프트 전체를 읽으며 행렬 연산을 수행한다. 발표자는 이 단계가 GPU 연산 성능과 첫 토큰까지의 대기시간에 연결된다고 보여준다. [05:29]
• 이후에는 토큰을 하나씩 생성하며 모델 가중치를 메모리에서 읽는다. 영상은 이 출력 단계의 주요 변수로 메모리 대역폭을 제시한다. [05:55]

6. 단일 사용자 출력 속도와 소프트웨어 효과

• 짧은 입력에서 DeepSeek 출력은 양쪽 모두 약 38토큰/초로 비슷했고, ‘Quen’은 Mac 45토큰/초, Spark 두 대 38토큰/초였다. [06:32]
• 발표자는 Mac의 메모리 대역폭과 노드 간 통신을 차이의 가능한 원인으로 든다. 다만 케이블이 실제로 얼마나 성능을 늦추는지는 따로 시험하지 않았다고 드러낸다. [06:59]
• Mac의 DeepSeek 출력은 llama.cpp 약 40토큰/초, MLX 53토큰/초로 엔진에 따라 달랐다. MLX 결과는 HTTP 서버를 거치지 않은 직접 호출 측정이어서 서비스 결과와 비교할 때 조건 차이가 남는다. [07:44]

7. 입력이 길어질수록 커지는 첫 응답 차이

• 토큰과 문맥 길이를 설명한 뒤 입력 처리 시간을 비교한다. DeepSeek의 8K 입력에서는 Spark 약 4초, Mac 약 10초였고, Mac은 16K 입력에서 약 21초를 기다렸다. [09:19]
• Python 파일 14개를 담은 32K 코드베이스 시연에서는 Spark 약 17초, Mac 약 50초의 대기시간을 제시한다. 별도 차트에서는 DeepSeek 16.5초 대 44초, ‘Quen’ 11.2초 대 26초로 Spark가 앞선다. [10:35]
• Spark는 128K 입력에서 72초를 기록했다. Mac은 같은 길이로 시험하지 않았으며, 3분 이상 걸릴 수 있다는 언급은 32K 결과의 패턴을 바탕으로 한 추정이다. [10:57]

8. 긴 입력과 긴 출력의 손익분기점

• 32K DeepSeek 입력에서 Spark는 약 30초 먼저 시작하고 이후 llama.cpp 출력 속도는 비슷하다. ‘Quen’에서는 Mac이 출력 중 격차를 줄이지만, 따라잡는 데 수천 토큰이 필요하다는 계산은 실측하지 않은 추정이다. [11:45]
• 발표자는 큰 입력은 Spark, 긴 출력은 적어도 ‘Quen’에서 Mac에 유리하다고 정리한다. Spark가 입력 처리를, Mac이 출력을 맡는 분리 구성과 초기 프로젝트도 보여준다. [12:07]

9. 캐시가 초기 대기시간을 줄이는 조건

• 같은 세션에서 서버가 이미 읽은 문맥을 보관하면 전체 입력을 매번 다시 처리할 필요가 줄어든다. 16K 문맥의 첫 질문은 Mac 21초, Spark 8.3초였지만 후속 질문은 각각 3초와 1.4초였다. [12:53]
• 코딩 도구가 코드베이스를 먼저 보내고 후속 질문에 작은 내용을 추가하는 흐름을 보여준다. 긴 입력 처리 비용은 주로 첫 질문에 집중된다는 해석이다. [13:24]
• 새 저장소, 큰 파일 추가, 캐시 범위를 넘는 긴 세션에서는 초기 처리 부담이 다시 커질 수 있다. 모델을 바꿀 때 문맥을 재계산하는 사례도 언급한다. [13:52]

10. MLX의 입력 처리 개선과 남은 검증

• ‘Quen’의 32K 입력에서 MLX는 약 19초로 llama.cpp의 26초보다 빨랐지만, Spark의 약 11초에는 못 미쳤다. 반면 출력은 llama.cpp가 더 빨랐다고 보여준다. [14:10]
• DeepSeek의 MLX 32K 처리 시간은 최소 22초, 아마 30초에 가까울 것이라고 제시한다. 긴 입력과 여러 사용자 조건을 충분히 시험하지 않아 전체 응답 경쟁의 결과는 아직 모른다고 드러낸다. [14:34]

11. 동시 사용자 수와 개인별 체감 속도

• 동시성 수치는 모든 사용자의 토큰을 합친 처리량이다. DeepSeek에서 Mac은 4명일 때 66토큰/초로 정점을 찍고 8명에서 46토큰/초로 줄었으며, Spark는 8명에서 70토큰/초까지 증가했다. 16명 조건은 시험하지 않았다. [15:31]
• 각 사용자에게 8K 대화 이력을 준 8명 조건에서는 합산 처리량이 Mac 약 11토큰/초, Spark 약 25토큰/초였다. 첫 응답은 Mac 1분 이상, Spark 약 24초로, 큰 모델을 여러 사람이 공유하는 부담이 드러났다. [16:13]
• ‘Quen’의 8명 합산 출력은 Spark 120토큰/초, Mac은 llama.cpp 66토큰/초와 MLX 70토큰/초였다. 발표자는 Mac을 1~2명, Spark 두 대를 약 4명 규모에 더 적합하다고 보고 8명은 부담이 크다고 평가한다. [16:43]

12. 설치 부담·범용 활용·전력과 최종 선택

• Spark 두 대는 더 큰 클러스터보다 연결이 단순하지만, OS·커널·드라이버·펌웨어를 맞추고 다중 노드 설정과 RDMA 트래픽을 확인해야 한다. 그 대가로 클라우드와 유사한 CUDA 기반 추론 환경을 얻는다고 보여준다. [17:36]
• Mac은 큰 모델 실행 외에 영상 렌더링 등 일상 작업도 맡길 수 있다. 고부하 순간 전력은 Mac 434W, Spark 클러스터 410W였으며, 양쪽 모두 열과 소음이 발생했다. 표면과 후면 그릴의 온도 관찰도 제시한다. [19:42]
• Mac의 AI 실행에도 선택한 엔진에 따른 설치가 필요하다. 마지막에는 두 구성의 메모리 총량이 같아도 입력 처리 속도가 다르다고 정리하고, 큰돈을 쓰기 전에 자신의 프롬프트 길이와 답변 길이를 살펴보라고 권한다. [20:25]

🧾 결론

• 메모리 총량과 출력 토큰 속도만으로 구매를 결정하면 긴 입력에서 발생하는 대기시간을 놓치기 쉽다.
• 긴 코드베이스나 문서를 자주 새로 읽히는 작업은 이번 측정에서 Spark 두 대가 유리했다. 긴 출력을 만드는 작업에서는 모델과 엔진에 따라 Mac의 출력 속도가 장점이 될 수 있다.
• 같은 문맥을 이어 쓰는 세션에서는 캐시가 초기 처리 비용을 줄이므로, 매번 새 입력으로 시작하는 시연과 실제 사용 경험이 달라질 수 있다.
• Mac의 범용 작업 활용도와 Spark의 CUDA 기반 서버 환경까지 포함해 자신의 작업에 맞는 구성을 판단해야 한다.

📈 투자·시사 포인트

• 영상의 구성 가격은 Mac 약 1만4천 달러, Spark 두 대 약 1만 달러에 케이블 비용이 추가되는 수준이다. 저장공간은 양쪽 모두 합계 8TB지만, 가격 차이를 성능 차이 하나로 설명하기는 어렵다.
• 하드웨어 구매 전 추론 엔진과 캐시 설정을 먼저 비교할 가치가 있다. 영상에서는 소프트웨어 변경만으로 Mac의 특정 출력 측정값이 약 34% 높아졌다.
• 소규모 팀의 장비 투자는 합산 처리량보다 사용자별 첫 응답 시간과 출력 속도를 기준으로 검토해야 한다. 긴 대화 이력을 가진 8명 조건에서는 양쪽 모두 사용성이 크게 떨어졌다.
• 고부하 순간 전력은 Mac 434W, Spark 클러스터 410W로 비슷했다. 이 수치만으로 장기 운영비를 판단할 수는 없으며, 영상에서 별도 수치를 제시하지 않은 유휴 상태도 확인해야 한다.

⚠️ 불확실하거나 확인이 필요한 부분

• 같은 모델을 비교했지만 동일한 파일은 아니며, 양쪽 모두 4비트 양자화 파일을 사용했다. 양자화 방식과 추론 엔진의 차이가 결과에 미친 영향은 분리되지 않았다.
• DeepSeek의 MLX 53토큰/초는 엔진을 직접 호출한 측정이다. HTTP 서버를 거친 Spark 결과와 그대로 비교하기에는 조건 차이가 있다.
• Mac의 128K 입력 대기시간과 ‘Quen’의 출력 추월 시점은 실측이 아니라 추정이다. MLX의 긴 입력·다중 사용자 성능과 Spark의 16명 조건도 충분히 검증되지 않았다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 실제 작업의 입력 토큰 수, 예상 출력 길이, 동시 사용자 수를 기록해 비교 조건을 정한다.
• 동일한 프롬프트·출력 길이·서비스 경로로 첫 토큰 대기시간과 출력 토큰 속도를 각각 측정한다.
• 새 세션과 캐시가 유지된 후속 질문을 나누어 시험하고, 코드베이스 변경 시 캐시 효과가 얼마나 줄어드는지 확인한다.
• Mac에서는 llama.cpp와 MLX를 실제 사용할 서버 구성으로 비교하고, 모델 파일과 양자화 설정을 함께 기록한다.

❓ 열린 질문

• 동일한 HTTP 서비스 조건에서 MLX를 사용하면 Mac의 전체 응답 완료시간은 Spark 두 대와 어떻게 달라질까?
• 입력이 길어지거나 여러 사용자가 동시에 접근할 때 MLX의 출력 속도 이점은 얼마나 유지될까?
• 실제 코딩 세션에서 문맥 재사용 비율이 높아지면 Spark의 초기 입력 처리 우위는 얼마나 중요하게 남을까?