NVIDIA, It''s Happening Again

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

NVIDIA DGX Spark에 맞선 GMKtec Evo X5 Pro는 대형 모델과 긴 컨텍스트에서 메모리 용량의 이점을 보이지만, 같은 모델의 작업 완료 속도와 이미지·영상 생성에서는 Spark가 대체로 앞선다.

📌 핵심 요점

1. 192GB 메모리는 매력적이지만 GPU 할당량을 확인해야 한다. Evo X5 Pro의 4TB 구성은 약 7,000달러로 Spark 두 대 약 14,000달러보다 저렴하다. 다만 Windows 출고 설정은 GPU에 128GB만 배정하므로 157GB GLM 5.3을 바로 실행할 수 없다. GPU 할당을 160GB로 늘린 뒤에는 실행됐다.
2. 토큰 생성 속도만으로 작업 성능을 판단하기 어렵다. 초기 비교에서 GMKtec의 생성 속도는 Spark와 대체로 ±9% 범위였지만, 프롬프트 처리는 1.5~3배 느렸다. 10,000토큰 코드를 입력한 27B 모델의 첫 토큰 대기시간은 약 30초와 12초로 차이가 났다.
3. 추가 메모리는 긴 컨텍스트와 모델 상주에서 실익을 만든다. Flash Next는 GMKtec에서 약 26만 2,000토큰 컨텍스트를 활용했지만 Spark는 약 61,000토큰에서 메모리가 부족해졌다. 네 모델을 번갈아 사용하는 작업에서는 GMKtec이 모두 상주시켜 재로딩을 피했고, 지속 작업량이 약 17% 높았다.
4. GPU 메모리 확대는 도구 실행용 시스템 메모리와 맞바꾸는 선택이다. GPU에 160GB를 고정 배정하면 시스템에는 약 32GB가 남는다. 이 조건에서 GMKtec은 실제 Docker 도구를 쓰는 에이전트 두 개까지 안정적으로 실행했지만 네 개에서는 일부가 실패했다. Linux의 동적 메모리 차용 구성은 여유를 늘리는 방법으로 제시됐다.
5. 운영체제와 추론 엔진이 결과를 크게 바꾼다. 테스트 당시 WSL에서는 해당 AMD GPU를 활용하지 못했고, 네이티브 Linux와 백엔드 조정이 필요했다. 동일한 86GB·2비트 DeepSeek 파일을 DS4 엔진으로 비교하면 Spark가 더 빨랐다. Halogen의 특정 모델 성능 향상도 자체 가중치와 제한된 실행 조건을 함께 봐야 한다.

🧩 배경과 문제 정의

• 대형 로컬 AI 모델을 실행하기 위해 DGX Spark 여러 대를 연결하면 비용이 크게 늘어난다. 두 대가 약 14,000달러인 상황에서, 192GB 메모리를 갖춘 약 7,000달러의 GMKtec Evo X5 Pro가 대안이 될 수 있는지가 핵심 문제다.
• 총메모리가 많아도 GPU에 실제로 할당되는 용량, 운영체제와 드라이버 지원, 추론 엔진에 따라 실행 가능한 모델과 성능이 달라진다.
• 비교 기준은 단순한 토큰 생성 속도를 넘어 긴 프롬프트 처리, 여러 모델의 동시 상주, 실제 도구를 사용하는 에이전트, 이미지·영상 생성까지 포함한다.

🕒 시간순 섹션별 상세정리

1. Spark 두 대 대신 192GB 미니 PC로 대형 모델을 실행할 수 있는가

• Evo X5 Pro는 192GB 메모리와 4TB 저장장치 구성에서 7,000달러, 2TB 구성에서 6,800달러다. Spark 두 대의 가격은 약 14,000달러까지 올라 대형 모델을 한 대로 실행할 수 있다면 비용 차이가 크다. [00:24]
• 우선 목표는 Spark 한 대에 들어가지 않는 157GB GLM 5.3 실행이다. 여러 모델과 도구를 사용하는 에이전트, 약 25만 토큰의 컨텍스트도 시험하지만 출고 상태의 GPU 메모리에는 목표 모델이 들어가지 않는다. [00:55]

2. Merlin AI의 통합 구독과 할인 조건

• 협찬 서비스 Merlin AI는 여러 AI 모델을 한곳에서 선택하고, 웹페이지 요약과 다중 출처 심층 조사, 웹·학술·Reddit 검색을 제공한다. 여러 서비스를 따로 구독하는 비용과 탭을 오가는 부담을 줄이는 구상이다. [01:45]
• 저렴한 가격의 근거로 API 접근권의 대량 구매와 일반적인 사용자의 낮은 API 소비량을 제시한다. 프로모션 적용 가격은 연 60달러, 월 환산 약 5달러이며 할인 종료 시점은 확실하지 않다. [02:13]

3. Evo X5 Pro의 가격 경쟁력과 개발 작업 성능

• Evo X5 Pro는 Ryzen AI Max+ Pro 495와 Radeon 865S 그래픽을 탑재한다. 전후면 USB4 계열 포트와 USB-A, HDMI, 듀얼 10Gb 이더넷 등 전문가용 연결 구성을 갖춘다. [03:19]
• 당시 Spark 한 대보다 약 150달러 비싸면서 메모리는 64GB 더 많다. 메모리 1GB당 가격은 GMKtec 약 37달러, Spark 약 54달러로, 구매상의 핵심 이점은 메모리 용량이다. [03:33]

4. 비슷한 메모리 대역폭과 출고 상태의 GPU 할당 제한

• 두 장치의 명목 메모리 대역폭은 모두 초당 273GB다. GPU 측 실측도 초당 246GB와 248GB로 거의 같아, 메모리에서 가중치를 읽는 토큰 생성에서는 비슷한 성능이 예상된다. [04:46]
• Windows 11 출고 설정에서는 전체 192GB 중 GPU에 128GB, 시스템에 64GB가 배정된다. 통합 메모리라도 BIOS가 부팅 시 사용 영역을 나누므로 GPU가 전체 용량을 자유롭게 쓰는 상태는 아니다. [05:53]

5. 토큰 생성은 비슷하지만 프롬프트 처리는 Spark가 빠르다

• Windows의 llama.cpp·Vulkan 조합에서 Qwen3 Coder 30B는 초당 96토큰, 밀집형 Qwen 27B는 초당 11.8토큰을 생성했다. 밀집형은 매 토큰마다 전체 매개변수를 계산하지만, MoE 모델은 일부만 활성화하므로 전체 모델 크기만으로 속도를 비교하기 어렵다. [06:58]
• 토큰 생성 속도는 Spark와 대체로 ±9% 범위였다. 반면 입력 전체를 병렬로 계산하는 프롬프트 처리는 GMKtec이 1.5~3배 느려, GPU 연산 능력과 소프트웨어 차이가 드러났다. [07:58]

6. 이미지·영상 생성과 대형 모델에서 드러나는 출고 설정의 한계

• 같은 프롬프트로 Stable Diffusion XL의 1024×1024 이미지를 생성하는 데 GMKtec은 25초, Spark는 13초가 걸렸다. 5초짜리 LTX 2.3 영상은 각각 196초와 40초로, 연산량이 큰 생성 작업에서 Spark의 우위가 더 컸다. [08:58]
• 157GB GLM 5.3은 GPU 할당량 128GB를 넘으므로 로드되지 않는다. 출고 상태에서는 총메모리 192GB의 이점을 목표 모델에 활용할 수 없으며, Linux 중심의 AI 도구를 사용하려면 운영체제 선택도 검토해야 한다. [09:28]

7. WSL은 설치되지만 해당 AMD GPU를 활용하지 못한다

• WSL의 Ubuntu는 쉽게 설치되지만 Vulkan이 실제 GPU 대신 CPU 기반 소프트웨어 렌더러인 LLVMpipe를 사용한다. ROCm도 이 칩의 WSL 환경을 지원하지 않아 실행에 실패한다. [10:07]
• 예시 모델의 생성 속도는 WSL CPU에서 초당 약 25토큰, Windows GPU에서 82토큰이었다. 프롬프트 처리도 초당 328토큰과 1,800토큰으로 차이가 커, 이 장치에서 Linux GPU 작업을 하려면 듀얼 부팅이 필요했다. [11:02]

8. 네이티브 Linux의 이점과 영상 처리 병목을 해소한 수정

• Ubuntu 26.04와 Windows를 같은 llama.cpp 및 GPU 메모리 128GB 조건으로 비교하면, Linux의 프롬프트 처리가 7개 모델 중 5개에서 빠르고 최대 약 1.5배 개선됐다. 반면 토큰 생성은 Windows가 최대 5% 빨랐다. [11:56]
• 5초 영상 생성은 Windows 194초에 비해 Linux가 316초로 느렸다. 원인은 ComfyUI가 ROCm에 전달하는 어텐션 데이터 배치였고, 해당 단계가 약 15배 느려지는 문제를 contiguous() 호출 한 줄로 수정했다. 출력은 비트 단위로 같았다. [12:36]

9. GPU 메모리를 160GB로 늘리면 대형 모델이 실행된다

• BIOS의 프레임 버퍼 크기를 160GB로 설정할 수 있다. Windows에서는 페이지 파일 크기 관리에 따른 안정성 경고가 나오며, 관련 설정을 조정해야 한다. [13:45]
• 142GB Qwen3 235B, 155GB DeepSeek V4 Flash, 157GB GLM 5.3은 같은 파일로 Spark에서 로드되지 않았다. GPU 할당량을 늘린 GMKtec에서는 GLM 5.3이 실행되고, 160GB 중 142.8GB를 사용했다. [14:22]

10. 긴 컨텍스트와 여러 모델의 상주가 추가 메모리의 실익이다

• 약 120GB인 Flash Next 모델은 두 장치 모두 로드할 수 있지만, GMKtec은 전체 약 26만 2,000토큰 컨텍스트를 활용하고 Spark는 약 61,000토큰에서 메모리가 부족해진다. 긴 컨텍스트는 모델 가중치 외에도 토큰별 상태를 저장할 메모리를 요구한다. [15:45]
• 두 장치 모두 처리할 수 있는 58,000토큰 조건에서는 GMKtec이 초당 25토큰, Spark가 17.3토큰으로 GMKtec이 약 44% 빨랐다. [15:58]

11. DeepSeek 비교는 파일 크기와 실행 엔진을 구분해야 한다

• GMKtec은 DeepSeek V4 Flash로 168턴의 코딩 세션 재생을 41분에 완료하며 GPU 메모리 약 145GB를 사용했다. 다만 llama.cpp의 도구 호출 버그 때문에 실제 도구를 실행한 것이 아니라 호출을 재생했으므로, 다른 실작업 시간과 직접 비교할 수 없다. [17:24]
• “GMKtec만 실행할 수 있다”는 조건은 앞서 사용한 llama.cpp와 파일에 한정된다. DS4 엔진에서 양쪽에 들어가는 동일한 86GB·2비트 파일을 사용하면 프롬프트 처리는 Spark 초당 778토큰, GMKtec 302토큰이며, 생성도 각각 19.9토큰과 14.9토큰으로 Spark가 빨랐다. [18:32]

12. 160GB GPU 할당은 실제 도구를 쓰는 에이전트 수를 제한한다

• GPU에 160GB를 고정 배정하면 시스템 메모리는 약 32GB로 줄어든다. 실제 Docker 도구를 실행하는 에이전트는 각각 약 4GB를 추가로 사용했고, 시스템 사용량은 한 개에서 17.8GB, 두 개에서 약 22GB, 네 개에서 약 30GB에 도달했다. [19:38]
• 이 조건에서 GMKtec은 두 에이전트까지 안정적으로 실행하며 합계 초당 7.6토큰을 처리했다. 네 에이전트에서는 일부가 실패한 반면 Spark는 여덟 개를 정상 실행하며 합계 초당 17.4토큰을 처리했다. [20:14]

13. Linux에서는 메모리를 필요에 따라 빌리는 구성이 가능하다

• BIOS의 GPU 고정 할당을 최소인 0.5GB로 낮추고 Linux의 GTT 한도를 높이면 GPU가 시스템 메모리를 필요에 따라 빌릴 수 있다. 이때 Linux에서 보이는 시스템 메모리는 약 183GB로 늘어난다. [21:13]
• Qwen 27B에서 토큰 생성은 약 8% 빨라지고 프롬프트 처리는 약 5% 느려졌다. 성능 차이는 비교적 작지만 메모리 활용 여유가 커지며, Windows에서는 확인한 범위상 고정 분할을 바꾸기 어렵다. [21:34]

14. 다중 사용자 서비스와 단일 에이전트 작업에서는 Spark가 유리하다

• 큰 모델을 여덟 사용자나 에이전트가 함께 쓰면 각자 초당 2.2~3.6토큰에 그치고, 긴 프롬프트 하나가 다른 요청도 기다리게 한다. GLM 5.3의 총처리량은 약 두 사용자에서 정점에 이르며, 작은 모델은 두 장치 모두 대체로 네 사용자 부근에서 정점에 도달했다. [22:09]
• 두 장치는 팀 공용 서버보다 개인용 장치에 가깝다. 두 장치에 모두 들어가는 Qwen 27B의 단일 에이전트 작업은 Spark 50분, GMKtec의 최선인 새 llama.cpp·ROCm 구성에서 56분이었고, Vulkan에서는 64.5분이 걸렸다. [22:47]

15. 영상 수정 후에도 이미지·영상 생성은 Spark가 빠르다

• 음성이 포함된 10초 영상은 수정 전 LTX 2.3에서 34분, LTX 2.5에서 37.5분이 걸렸다. 한 줄 수정 후 각각 7.2분과 8분으로 거의 5배 개선됐지만, Spark는 각각 약 3분과 4분이었다. [23:44]
• 1024×1024 Stable Diffusion 이미지는 GMKtec 11.7초, Spark 8.3초였고, Flux.1 Dev는 각각 47초와 27초였다. 영상 처리용 수정은 이미지 생성에는 효과가 없었다. [24:11]

16. 추측 디코딩과 백엔드 선택이 성능을 크게 바꾼다

• 작은 모델이 다음 토큰들을 예측하고 큰 모델이 검증하는 추측 디코딩은 코드 생성에서 약 1.5~4배의 속도 향상을 보였다. Qwen 27B는 초당 약 12토큰에서 44토큰으로 빨라졌으며, Spark도 더 큰 향상을 얻었다. [24:50]
• GPT-OSS 20B 생성은 llama.cpp에서 초당 73토큰이지만 vLLM에서는 15토큰이었다. vLLM의 프롬프트 처리는 더 빨라도 해당 AMD 칩에 맞춘 GPU 코드가 부족해 생성에서 손해를 보므로, 당시 GMKtec의 일반적인 선택으로는 llama.cpp가 적합하다. [26:07]

17. Halogen은 특정 모델의 성능을 끌어올리지만 적용 조건이 좁다

• Flash Next의 짧은 프롬프트 처리량은 llama.cpp에서 Vulkan 초당 488토큰, ROCm 493토큰, Spark 517토큰으로 가까웠다. AMD용 Halogen 엔진에서는 GMKtec이 초당 1,847토큰을 기록했고, 32,000토큰 프롬프트도 약 16초에 읽어 llama.cpp의 1분 이상 대기시간을 크게 줄였다. [27:38]
• Halogen의 생성 속도는 초당 약 39.8토큰이며, 내장 추측 디코딩인 MTP를 사용하면 최대 68.5토큰까지 높아졌다. 다만 이 성과는 해당 특정 모델에 한정된다. [27:56]

18. 구매 기준은 실행 가능한 모델 크기와 실제 작업 방식이다

• GMKtec의 강점은 약 150GB급 모델, 약 26만 2,000토큰 컨텍스트, 네 모델의 동시 상주다. 다만 GPU에 메모리를 크게 배정한 상태에서 Docker 에이전트 여덟 개까지 안정적으로 실행하는 것은 별개의 문제이며, WSL GPU 지원과 일부 커널·자료형 지원에도 제약이 남아 있다. [28:59]
• 집에서 2,000억 매개변수급 모델이나 긴 컨텍스트를 원하고 BIOS 조정, Linux 듀얼 부팅과 설정상의 불편을 감수할 수 있다면 GMKtec이 후보가 된다. 모델이 128GB 안에 들어가고 프롬프트 처리, 여러 요청 처리, 이미지·영상 생성 속도가 중요하면 비슷한 가격의 Spark가 더 빠르다. [29:30]

🧾 결론

• 약 150GB급 모델, 긴 컨텍스트, 여러 모델의 동시 상주가 목적이라면 GMKtec의 추가 메모리가 구매 이유가 된다.
• 모델이 128GB 안에 들어가고 프롬프트 처리와 작업 완료 시간이 중요하다면 비교 결과는 대체로 Spark에 유리하다. 이미지·영상 생성도 수정 이후까지 Spark가 빨랐다.
• 두 장치는 개인용 작업에 더 가깝다. 모델을 로드할 수 있다는 사실과 여러 사용자가 도구까지 실행하며 안정적으로 사용하는 능력은 따로 검증해야 한다.
• 구매 판단은 총메모리나 초당 생성 토큰 하나보다 실제 모델 파일, 컨텍스트 길이, 동시 작업 수, 설정 부담을 기준으로 내려야 한다.

📈 투자·시사 포인트

• 로컬 AI 장치의 경쟁력에는 연산 성능뿐 아니라 실행 가능한 모델 크기도 포함된다. 추가 메모리가 모델 재로딩을 없애면 지속 작업량에서 이점이 생긴다.
• 메모리 1GB당 가격은 GMKtec이 유리했지만, 처리시간이 중요한 작업에서는 Spark의 빠른 프롬프트 처리와 생성 연산이 구매 가치를 높인다.
• 소프트웨어 최적화는 하드웨어 평가를 바꿀 수 있다. 영상 처리의 데이터 배치 수정과 추측 디코딩 사례는 구매 전 사용할 엔진과 지원 상태를 확인해야 하는 이유다.
• 장비 예산에는 BIOS 조정, Linux 듀얼 부팅, 드라이버와 엔진 관리에 드는 시간도 함께 반영필요가 있다.

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

• “GMKtec만 실행할 수 있다”는 주장은 특정 모델 파일과 llama.cpp 조건에 한정된다. 더 작은 양자화 파일과 다른 엔진에서는 Spark도 실행했고 성능 우위를 보였다.
• DeepSeek V4 Flash의 168턴·41분 결과는 도구 호출 재생이다. 실제 도구를 실행하는 에이전트의 완료 시간과 직접 비교할 수 없다.
• GPU 128GB 배정에서 에이전트 여덟 개가 가능하다는 설명은 메모리 계산에 따른 추정이며 직접 시험한 결과가 아니다. 동적 메모리 차용 구성에서도 해당 부하의 안정성을 별도로 확인해야 한다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 사용할 모델의 정확한 파일과 양자화 방식, 목표 컨텍스트 길이, 동시에 상주시킬 모델 수를 먼저 정리한다.
• 모델 가중치와 컨텍스트용 메모리 외에 운영체제와 Docker 도구가 사용할 시스템 메모리까지 계산한다.
• 같은 모델 파일·엔진·컨텍스트 조건에서 첫 토큰 대기시간, 생성 속도, 실제 작업 완료 시간을 비교한다.
• GMKtec 구매 전 BIOS 메모리 설정, 네이티브 Linux 설치, GPU 드라이버와 필요한 커널·자료형 지원을 확인한다.

❓ 열린 질문

• GMKtec의 동적 메모리 차용 구성에서 대형 모델과 여러 Docker 에이전트를 함께 실행하면 어느 수준까지 안정적으로 작동할까?
• 양쪽 장치에 적합한 엔진을 각각 사용하면서 모델 품질과 작업 조건도 맞추면 완료 시간 차이는 얼마나 달라질까?
• 긴 컨텍스트와 여러 모델의 상주로 줄어드는 대기시간이, 실제 개인 작업에서 느린 프롬프트 처리를 얼마나 상쇄할까?