ASUS Ascent GX10 — 128GB unified memory를 갖춘 ARM64 기반 로컬 AI 서버 하드웨어

ASUS Ascent GX10 4개월 사용기: vLLM 서버, 128GB unified memory, 성능과 디코딩 속도

마지막 수정일

구매 정보: 2026년 2월, 1TB, 550만원

  • 구매 시점: 2026년 2월
  • 구매 가격: 1TB 모델 550만원
  • 사용 기간: 글 작성 시점 기준 4개월째
  • 사용 목적: 24시간 돌아가는 vLLM 로컬 LLM 서버

구매 배경: Mac mini 품귀 속 GX10을 산 이유

2월, 로컬 AI 에이전트 도구에 대한 관심이 급격히 커졌다. 파일을 읽고 앱을 조작하는 자동화 도구가 주목받았고, 이를 24시간 돌릴 전용 머신 수요도 함께 늘었다. Ollama나 Mistral 같은 로컬 모델을 연결하면 개인 비서처럼 쓸 수 있다. 파일을 읽고, 앱을 컨트롤하고, 메신저와 연동하고, 백그라운드에서 연구 작업을 돌린다. 클라우드 API 키도, 토큰 비용도 필요없다.

이게 어떤 파장을 일으켰느냐면, Mac mini가 품귀 현상까지 일어났다는 거다. Apple 공식 배송 기간도 길어졌고, 중고 시장에서는 Mac mini 사재기 현상까지 생겼다. Apple Silicon의 unified memory 아키텍처가 로컬 LLM 추론에 잘 맞았고, 저전력이 24시간 구동에 유리했기 때문이다. 24GB unified memory면 30B 파라미터급 모델을 어느 정도 돌릴 수 있었다.

나도 그때 Mac mini 구매를 진지하게 고민했다. 24GB 모델은 가격 대비 메모리가 아쉬웠지만, 저전력이 24시간 구동에 유리하고 크기도 작았다. 그리고 로컬 에이전트 자동화의 보안성 문제도 있었다. 파일, 앱, 메신저에 접근하는 에이전트라서 중요한 파일이 유출되거나 악성 작업이 실행될 위험이 있었다. 따라서 격리된 PC에서 운영하는 것이 권장되는데, Mac mini 하나를 전용 에이전트 머신으로 돌리려는 사람이 많았다.

하지만 막상 스펙을 깊게 들여다보니, 24GB unified memory로는 내가 쓰려던 에이전트급 모델을 충분히 돌리기 어려웠다. 2월 당시 로컬 LLM 생태계에서 에이전트로 역할을 어느 정도 수행하려면 GPT-OSS-120B나 Qwen3.5 122B 정도가 필요하다고 봤다.

둘 다 MoE(Mixture of Experts) 아키텍처다. GPT-OSS-120B는 OpenAI가 2026년 초 공개한 120B 파라미터 모델로, 총 파라미터 중 일부만 활성화된다. 추론 성능이 비슷한 크기의 오픈 모델보다 뛰어나다는 평가를 받았다. Qwen3.5 122B-A10B도 MoE로, 총 122B 중 일부만 활성화된다. 262K 컨텍스트를 지원하고, tool use와 function calling을 공식 지원한다. 에이전트에 필요한 핵심 기능이다.

Mac mini 24GB로는 이 모델들을 돌릴 수 없었다. 48GB 구성은 가격이 크게 뛰었다. 양자화 모델을 쓰면 어정쩡한 수준일 뿐, KV cache를 충분히 주지 못하면 context가 길어질수록 성능이 떨어진다. GX10의 128GB unified memory라면 양자화 모델을 썼을 때 GPT-OSS-120B나 Qwen3.5 122B도 어느 정도 돌릴 수 있다는 판단이었다.

결국 나는 Mac mini를 포기하고 거의 2~3배 비싼 GX10을 샀다. 조금이나마 저렴하게 구매하고자 1TB 모델을 당시 550만원에 샀다 (할부금 내는 동안 너무 힘들었다… ㅠㅠ). 다행히(?) 글을 작성하는 현재는 다나와 기준 가격이 많이 올라, 그나마 덜 속이 쓰린 편이다.

초기 세팅: vLLM 구동과 ARM64 호환성 문제

NGC 공식 이미지의 문제

지금은 많이 나아졌지만, 처음 vLLM을 올릴 때는 문제투성이였다.

처음에는 NVIDIA 공식 채널을 찾았다. NGC(NVIDIA GPU Cloud) Catalog다. NGC는 NVIDIA가 운영하는 GPU 최적화 AI/ML/HPC 소프트웨어 플랫폼으로, 검증된 컨테이너 이미지, 사전 훈련된 모델, 도구 등을 한 곳에서 제공한다. vLLM 공식 이미지(nvcr.io/nvidia/vllm)도 여기에 있었다.

공식 문서대로 docker run하면 끝날 줄 알았는데, 현실은 전혀 아니었다.

GB10의 Blackwell GPU는 CUDA 13.0이 필요하다. 그런데 vLLM, PyTorch, flash-attn 같은 주요 ML 패키지들이 아직 CUDA 13 기반 ARM64 wheel을 충분히 내지 않고 있었다. 대부분은 CUDA 12.x 기반 x86_64 wheel이었다.

NGC의 공식 이미지도 ARM64 빌드가 불안정했다. 일부 버전에서는 GPU 메모리 감지가 Not Supported로 떴다. unified memory 풀에서 VRAM을 독립적으로 report하지 못해서 생긴 문제였는데, 실제 모델은 돌아가도 모니터링 도구가 오작동했다.

당시에는 진짜 환불이나 중고로 방출을 심각하게 고민했다. NGC 이미지도 안 되고, 공식 vLLM Docker 이미지(vllm/vllm-openai:latest-arm64)도 초반에는 안정적이지 않았다. 마치 미완성된 것을 판 것처럼 이래도 안 되고 저래도 안 되는 상황이었다.

spark-vllm-docker로 버틴 과정

그때 구세주처럼 등장한 게 eugr 아저씨의 spark-vllm-docker다. DGX Spark의 호환성 문제를 거의(?) 정리해 준 프로젝트였고, 실제로 따라 하기 쉬운 도커 레시피를 제공했다. 12.1a 아키텍처(GB10/SM121)에 맞춰 커스텀 빌드한 vLLM 컨테이너를 제공해 ARM64 + CUDA 13 + Blackwell 조합을 겨우 굴릴 수 있게 해줬다.

덕분에 이 프로젝트에 기대어 몇 달을 버텼다. 지금도 새 모델이 나오면 spark-vllm-docker 쪽 레시피를 먼저 참고해보고, 내 환경에 맞게 조금씩 변형해서 써본다. 여러 모델을 돌려봤고, 몇 번의 크래시도 겪었다.

nightly-aarch64로 정착

그리고 최근 드디어 상황이 달라졌다. 아직 nightly 버전이긴 하지만 vllm/vllm-openai:nightly-aarch64 이미지에서 여러 모델이 어느 정도 안정적으로 구동되기 시작했다. 공식 vLLM 팀이 ARM64 + CUDA 13 지원에 본격적으로 나서면서 nightly 빌드가 현실이 된 거다.

이제는 eugr의 이미지에서 nightly-aarch64로 넘어왔고, 현재는 이 쪽에 정착했다. eugr가 이 공로를 인정받아 NVIDIA에 합류했다는 소식도 들었다. 그동안 신세 많았습니다.

4개월 사용 후기: 업데이트·성능·발열·메모리

업데이트 빈도: DGX OS는 거의 매달 바뀐다

구매 후 DGX OS는 거의 매달 업데이트를 한다. 성능 개선 패치가 들어오고, USB-C PD 컨트롤러 안정화가 되고, idle 전력을 낮추었다고 한다.

Dashboard에서 업데이트를 돌리면 재부팅이 되는데, 실제로 무엇이 얼마나 바뀌었는지는 체감하기 어렵다. 그래도 버그가 조금이라도 덜 터진다면 괜찮다 싶어서, 생각날 때마다 그냥 업데이트해 두는 편이다.

성능: Qwen3.6 35B 기준 40~60 tok/s

eugr의 Spark Arena에서는 여러 사람들이 최적화해서 올려둔 레시피의 실제 벤치마크를 볼 수 있다. 다만 최근에는 꽤 과격한 최적화 레시피도 많아서, 수치만 그대로 믿기보다는 참고용으로 보는 편이 낫다.

내 경우 주력 모델인 Qwen3.6 35B NVFP4는 Hermes Agent 기준으로 약 40~60 tok/s 정도를 유지한다. 에이전트로 쓰기에는 충분한 속도라고 본다.

24시간 구동: 온도·소음·전력

24시간 계속 켜두고 돌리고 있다. 평상시엔 아주 약간 따뜻한 정도다. CPU도 GPU도 60도를 넘지 않는다. 소음은 거의 느껴지지 않는다. 팬이 돌아가는 소리도 거의 듣지 못할 정도로 조용하다.

전력 소비는 장비로 정확히 측정하진 못했지만, 최근 펌웨어 업데이트로 idle 전력이 개선된 것도 있고, 평소에는 전기세가 크게 체감되는 변화가 없었다. 열심히 써도 한 달 3,000원을 넘지 않을 것으로 예상된다.

메모리: 128GB unified memory의 여유

128GB unified memory가 장점이다. 개인용으로 쓰기에는 매우 널널한 용량이다. 앞서 언급한 122B 모델도 양자화 버전이면 충분히 돌아간다. 235B급도 양자화하면 128GB 안에서 올라가지만, KV cache를 넉넉히 주면 남는 공간이 없어서 70B 이하가 더 편하다. 그래도 128GB라는 용량 자체가 주는 여유는 크고, 여러 모델을 오가며 실험하기도 좋다.

디코딩 속도 한계: dense 모델이 실용적이지 않은 이유

하지만 가장 치명적인 문제가 있다. decoding 속도다.

LLM 속도는 크게 prefill(프롬프트 처리)와 decoding(응답 생성)으로 나뉜다. GX10은 prefill은 매우 빠르다. 하지만 decoding이 느리다. 일반적인 게임용 RTX 그래픽 카드보다 압도적으로 느리다.

20B가 넘어가는 dense 모델은 decoding 속도가 너무 느려서 실용적이지 않다. 그래서 필자는 dense 모델이 아닌 MoE 모델을 사용한다. MoE는 활성화되는 파라미터 수가 적어서 decoding 속도가 dense보다 낫다.

최근에는 Qwen3.6 35B 모델로 정착했다. 35B급 MoE로, dense 모델보다 decoding 속도가 실용적이고, 128GB 안에서 충분히 여유롭게 돌아간다. 에이전트에 필요한 기능도 충분하다.

현재 세팅: Qwen3.6 35B-A3B-NVFP4 docker-compose

도커 컴포즈로 Qwen3.6-35B-A3B-NVFP4를 돌리는 레시피를 공개한다. .env 파일에 HF_TOKEN 환경변수를 설정해야 한다.

name: llm

services:
  vllm:
    image: vllm/vllm-openai:nightly-aarch64
    container_name: vllm
    environment:
      - HF_HOME=/root/.cache/huggingface
      - FLASHINFER_DISABLE_VERSION_CHECK=1
      - CUTE_DSL_ARCH=sm_121a
    volumes:
      - ${HF_HOME}:/root/.cache/huggingface
    ports:
      - "8000:8000"
    networks:
      - ai-network
    ipc: "host"
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    restart: unless-stopped
    command: >
      nvidia/Qwen3.6-35B-A3B-NVFP4
      --host 0.0.0.0
      --port 8000
      --reasoning-parser qwen3
      --enable-auto-tool-choice
      --tool-call-parser qwen3_coder
      --tensor-parallel-size 1
      --trust-remote-code
      --dtype auto
      --quantization modelopt
      --kv-cache-dtype fp8
      --attention-backend flashinfer
      --moe-backend marlin
      --gpu-memory-utilization 0.85
      --max-model-len 262144
      --max-num-seqs 8
      --max-num-batched-tokens 16384
      --enable-chunked-prefill
      --async-scheduling
      --enable-prefix-caching
      --speculative-config '{"method":"mtp","num_speculative_tokens":3,"moe_backend":"triton"}'
      --default-chat-template-kwargs '{"preserve_thinking":true}'

networks:
  ai-network:
    external: true

docker compose up -d로 시작하면 localhost:8000에서 OpenAI 호환 API로 접근할 수 있다.

실제 활용 범위: 코딩·에이전트 작업은 어디까지 가능한가

솔직히 말하면, 본격적으로 로컬 LLM으로 코딩을 하려면 Qwen3.6 27B dense 모델 정도는 되어야 한다고 생각한다. 그런데 GB10 칩셋의 디코딩 속도가 너무 느려서, 실제로는 실용성이 떨어졌다.

필자의 경우 약 17 tok/s로 측정됐고, 이 속도는 내 인내심이 버티기 어려운 수준이었다. 2대를 연결하면 Dense 모델을 더 빠르게 돌릴 수 있긴 하지만, 그때는 비용이 너무 커진다.

다시 말하지만, 2026년 6월 기준 1대에서 가장 좋은 모델은 Qwen3.6 35B-A3B-NVFP4라고 생각한다. MoE 모델이라 프리필과 디코딩 모두 비교적 쾌적하다.

활용 예시: 코딩·에이전트·루틴 작업

코딩 및 웹 프론트엔드 생성

GPT-4o 수준은 아니지만, 단순 HTML/CSS/JS 페이지는 어느 정도 생성할 수 있다. 1페이지짜리 랜딩 페이지라면 1~2 프롬프트면 충분하고, 15회 정도 반복하면 간단한 게임을 만들어내기도 했다.

에이전트 활용

로컬 에이전트 프레임워크를 연결하면 파일 읽기/쓰기, 코드 생성, 간단한 리서치 작업 등은 대부분 잘 돌아간다. 다만 복잡한 추론이 필요한 작업이나 창의적인 작업은 여전히 한계가 있다.

작업 스타일

필자는 이런 식으로 사용한다.

  • 창의적/복잡한 작업: Claude Code나 다른 강력한 에이전트에 맡기고 스펙과 주요 버그만 확인
  • 루틴한 작업: GX10에서 Qwen3.6 35B로 처리
  • 둘을 조합하면 24시간 구동 가능한 에이전트 파이프라인이 구축된다.

구매 전 체크: 리눅스·도커·ARM64 숙련도가 필요한 이유

이 글을 읽는 여러분에게 반드시 말하고 싶다. 만약 DGX Spark나 그 OEM 제품(GX10, Dell Pro Max 등) 구매를 고려 중이라면, 반드시 도커와 리눅스 사용에 어느 정도 익숙한 사람들만 사시길 바란다.

필자는 업무상 두 가지에 익숙하여 그나마 금방 적응할 수 있었지만, 만약 아무런 사전 지식이 없다면 상당한 진입장벽을 느끼게 될 것이다. Linux 커널, 도커 컨테이너, NVIDIA 드라이버, CUDA, ARM64 아키텍처, NGC 레지스트리, 패키지 호환성 문제 등… 평범한 PC 빌드나 일반 소프트웨어 설치와는 완전히 다른 차원의 문제들이 기다리고 있다.

하지만 리눅스와 도커가 익숙하고, 로컬 LLM을 진지하게 쓰고 싶은 사람이라면, 이 진입장벽을 넘어섰을 때 얻을 수 있는 경험이 꽤 의미 있다고 생각한다.

총평: 장점·단점·4개월 사용 결과

장점: 128GB unified memory, NVFP4, 조용한 24시간 구동

  1. 128GB memory. 가장 큰 장점이며 이 기기의 존재 이유다. 122B급 모델도 양자화 버전이면 충분히 사용 가능하다. 다만 이 용량을 제대로 살릴 70B~120B급 최신 MoE 오픈소스 모델이 아직 부족하다.
  2. 크기와 전력. 데스크탑 위에 올려놓고 24시간 돌릴 수 있는 몇 안 되는 LLM 장비다.
  3. NVFP4 하드웨어 지원. Blackwell GPU가 FP4 양자화를 하드웨어 레벨에서 처리해서, 4bit 양자화임에도 성능 손실이 적고 속도도 잘 나온다. 처음 출시되었을 때는 NVFP4 호환성 이슈가 있었지만, 최근 필자의 경험상 거의 해소된 것으로 보이며 Hugging Face에서 구할 수 있는 대부분의 NVFP4 모델이 별 이상 없이 동작한다.
  4. 조용함. 팬 소리는 나지만 소위 말하는 비행기 이륙하는 굉음은 들어본 적이 없다.

단점: 디코딩 속도, ARM64 생태계, unified memory 제약

  1. 디코딩 속도. prefill은 매우 빠르지만, decoding 속도가 느려서 일반적인 게임용 RTX 그래픽 카드보다 압도적으로 느리다. 그래서 치명적이게도 용량이 널널함에도 dense 모델 구동에는 상당한 제약이 따른다.
  2. ARM64 생태계가 아직 미성숙하다. pip 패키지가 ARM64 wheel을 안 내는 경우가 많고, Docker 이미지도 공식 빌드가 불안정하다.
  3. unified memory의 제약. 일반 그래픽 카드와 달리 VRAM 128GB를 모두 사용할 수 없다. unified memory이기 때문에 일반 RAM을 위한 공간도 여분을 남겨두어야 한다. GB10 칩셋 미니 PC는 GPU 메모리 활용률을 0.7 정도로 두는 것이 권장된다(필자는 조금 무리해서 0.85로 돌리고 있다).
  4. 최적 모델의 부재. 지금 가장 실용적인 모델이 35B급 MoE라서 128GB를 끝까지 활용하지 못한다. 그래서 용량은 충분한데, 그 용량을 진짜로 받아먹는 최신 오픈소스 모델이 아쉽다.

4개월 동안의 적응 결과: vLLM, MoE, GPU 메모리 활용률 0.85

  1. vLLM: NGC 공식 이미지 → eugr/spark-vllm-docker → 현재는 vllm/vllm-openai:nightly-aarch64 정착
  2. MoE 모델 채택 (dense 모델은 20B 넘으면 디코딩 속도가 너무 느림) → 현재 Qwen3.6 35B로 정착
  3. GPU 메모리 활용률 0.85로 설정 (권장 0.7, system RAM 여유 확보)

추천 대상: GX10이 맞는 사람과 아닌 사람

이 글의 본문을 기준으로 보면, GX10은 아무에게나 권할 수 있는 장비가 아니다. 대신 아래 조건에 맞는 사람에게는 꽤 분명한 선택지가 된다.

  • 로컬에서 35B~122B급 모델을 직접 굴려보며 성능과 제약을 체감하고 싶은 AI 개발자 또는 연구자
  • 폐쇄망, 보안 환경, 오프라인 환경처럼 인터넷 없이 LLM 서빙이 필요한 사람
  • 데스크탑 위에서 조용하게 24시간 돌아가는 서빙 머신이 필요한 사람
  • Docker, Linux, NVIDIA 드라이버, ARM64 호환성 문제를 직접 해결할 수 있는 사람
  • 전원과 소음을 줄이면서도 GPU 여러 장 대신 한 대로 정리하고 싶은 사람

이걸 사면 안 되는 사람:

  • 리눅스와 도커가 익숙하지 않은 초보자
  • “plug and play”를 원하는 사람. DGX Spark/GX10은 plug만 하면 바로 작동하는 장비가 아니다
  • dense 모델만 빠르게 돌리길 기대하는 사람
  • 최신 ML 패키지(CUDA 13 + ARM64)가 안정화되기를 기다릴 인내가 없는 사람

마무리: GX10은 조건부로 강력하다

아쉽게도 Dense 모델 구동의 제약 때문에 GX10만으로 A-Z 업무를 모두 일임할 수는 없다. 하지만 초기 세팅을 유료 상용 모델로 해두고, 이후 구조를 크게 바꾸지 않는 routine 작업을 추가 비용 없이 돌릴 수 있다는 점은 꽤 큰 메리트다.

최근 중국 쪽을 포함해 수준 높은 오픈소스 LLM이 계속 나오고 있다. 단일 GB10 칩셋(128GB)에 더 잘 맞는 모델이 많이 나와 준다면, 이 장비의 잠재력은 지금보다 더 커질 것이다.