DGX Spark(ASUS 변종) 128GB 통합 메모리로 대형 LLM 사용하기
안녕하세요! 이번에 좋은 기회로 일명 'ASUS 변종'이라 불리는 ASUS Ascent GX10 을 영입하게 되어, 요 며칠간 가혹하게 구동해보며 느낀 점들과 셋팅 과정을 공유해보려고 합니다.
제가 가져온 모델은 GB10 칩셋을 탑재하고, LPDDR5 128GB 통합 메모리가 구성된 사양입니다.
평소에는 24GB VRAM을 장착한 스레드리퍼 시스템이나, M4 맥미니로 LLM을 장착하며 놀곤 했는데, 완전히 새로운 AI 가속 플랫폼에 적응하기 위해 다양한 실험을 진행해 보았습니다.
1. 원격 관리부터 도커 기반 vLLM까지
가장 먼저 진행한 것은 역시 원격 제어 환경과 AI 코딩 어시스턴트 셋팅이었습니다.
-
RustDesk 설치: 언제 어디서나 원격으로 머신을 관리하기 위해 가장 먼저 RustDesk를 올렸습니다.
-
AI 코딩 도구 연동: 인프라가 갖춰진 후에는 AI 코딩 도구를 연동하여, 이후의 복잡한 프롬프트 및 인프라 구축 작업을 AI에게 위임하며 생산성을 극대화했습니다.
-
vLLM 구동: 이 머신의 핵심 목적은 대형 모델 구동입니다.
Docker 기반으로 vLLM을 올리고, 최종 목표로 Nemotron-3 Super 120B 모델을 구동하기로 결정했습니다.
2. LM-Studio나 Ollama는 사치? vLLM과 NVFP4 양자화를 선택한 이유
통합 메모리가 128GB로 제한되어 있다 보니, 100B가 넘어가는 고성능 대형 모델을 올리려면 말 그대로 메모리를 '영혼까지 끌어모아야' 합니다.
Ollama나 LM-Studio 같은 범용 런타임은 편하긴 하지만 오버헤드가 커서 이 환경에서는 사치에 가깝습니다.
그렇지 않으면 40B 이하의 모델만 겨우 돌릴 수 있죠.
이 머신에서 영끌로 버틸 수 있는 한계 모델 라인업은 다음과 같습니다.
- Qwen3-Coder-Next 80B
- Nemotron-3 Super 120B
- Qwen3.5 122B 및 그 변형 튜닝 모델들
- Mistral-4 Small 119B
적어도 200k 이상의 컨텍스트 윈도우를 확보하면서 실사용 가능한 수준의 Tokens Per Second를 뽑아내려면, 단일 모델 전용으로 빡빡하게 튜닝된 vLLM을 쓸 수밖에 없습니다.
특히 DGX 플랫폼은 양자화 포맷 중 엔비디아 전용인 NVIDIA Floating Point 4를 사용해야만 제대로 된 속도가 나옵니다.
다른 대안이 사실상 없는 셈이죠.
다행히 이 NVFP4 포맷 양자화 모델들은 vLLM 플러그인으로 최적화가 잘 되어 있어 효율적으로 구동할 수 있었습니다.
3. vLLM의 API 제약과 커스텀 프록시제작기
결국 이 모델을 외부 앱이나 개발 환경에서 활용하려면 API 형태로 호출해야 합니다.
OpenAI 호환 API를 통해 호출하게 되는데, vLLM도 이 엔드포인트를 기본적으로 제공하긴 합니다.
하지만 vLLM의 OpenAI 호환 API는 생각보다 기능이 축소되어 있는 경우가 많습니다.
가장 대표적인 문제가 바로 Reasoning 제어를 위한 effort 파라미터였습니다.
120B 급의 대형 모델들은 간혹 혼자 깊은 생각에 빠져 대답이 느려지거나 무한 루프에 빠지기 쉽습니다.
그래서 상황에 따라 리즈닝을 켜고 끌 수 있어야 하는데, 현재 API 표준상으로는 effort: low나 effort: none 같은 방식으로 의도를 전달할 수밖에 없습니다.
문제는 vLLM 내부적으로 이를 받아 <think></think> 싱킹 블록을 제거하거나 프롬프트를 적절히 번역해주는 기능이 부족하다는 점입니다.
-
LM-Studio의 경우: 모델 프록시 YAML 파일을 만들고 Jinja 템플릿을 별도로 지정해 대응할 수 있음.
-
vLLM의 경우: 그런 세부 기능이 부족하여 별도의 커스텀 프록시 서버를 앞에 두어야 함.
다행히 흐름과 로직만 명확히 알고 있다면, 연동해 둔 AI 코딩 도구에게 시켜서 프록시 백엔드 코드는 뚝딱 만들어낼 수 있었습니다.
4. 모니터링 환경 및 편의 기능 구축
GUI가 없는 리눅스 서버 환경이다 보니 관리를 위한 모니터링 셋팅도 몇 가지 추가했습니다.
-
Portainer: Docker 컨테이너들을 시각적으로 편하게 관리하기 위해 필수 설치.
-
Mission Center : CPU, GPU, 메모리 등의 자원 상태를 실시간으로 파악하기 위한 모니터링 툴 설치.
-
vLLM Log Monitor: vLLM에서 뿜어져 나오는 로그와 추론 상태를 한눈에 볼 수 있는 자체 모니터링 스크립트를 따로 작성해 구동.
처음 셋팅할 때는 손이 좀 가고 귀찮지만, 관련 키워드들을 조합해 AI 조수에게 던져주면 필요한 Docker Compose 파일이나 스크립트를 깔끔하게 짜주니 구축 자체는 금방 끝납니다.
5. 파인튜닝 조용하지만 강하다
보통 엔비디아 엔터프라이즈 GPU로 파인튜닝을 걸면 서버실이 떠나가라 미친 듯한 비행기 이륙 굉음이 나기 마련인데, 이 녀석은 의외로 매우 평화롭고 조용하게 동작합니다.
수랭식 계열이거나 전력 효율이 좋아서 그런지 소음 스트레스가 전혀 없습니다.
속도가 서버급 하이엔드보다 좀 느리면 어떤가요? 걸어두고 잊어버리면 그만입니다.
현재 Unsloth Studio를 설치해서 Qwen3.6 8B 모델 튜닝을 테스트해 보았는데, 사뿐하게 잘 돌아갑니다.
개인적인 견해로, 그 이상의 거대 모델을 직접 파인튜닝하는 건 리소스나 비용 면에서 개인의 영역이 아니라고 생각합니다.
요즘은 모델 자체가 워낙 빠르게 발전하고 있어서, 특정 목적의 라우터나 도메인 마스터리 용도로 쓰기에는 8B 모델만으로도 충분히 차고 넘친다고 봅니다.
다행히 8B 모델 기준으로는 LoRA와 QLoRA 모두 안정적으로 소화해냅니다.
참고로 Unsloth Studio는 도커보다는 네이티브 설치를 권장하여 호스트 환경에 직접 셋팅했습니다.
향후 계획
이제 겨우 며칠 써봤지만, 집에서 Nemotron 120B 모델을 500k 컨텍스트로 띄워두고 상시 15 TPS 수준으로 뽑아주는 머신이 있다는 것 자체만으로도 만족도가 엄청납니다.
참고로 네모트론을 500k 컨텍스트로 확보해두면 대기 메모리만 약 95GB를 선점하더군요.
앞으로 이 녀석을 더 굴려보면서 종종 사용기를 공유하겠습니다.
다음 목표는 이 머신에 쿠버네티스를 깔고 엔비디아 패브릭 플러그인 실습을 해볼 계획입니다.
아키텍처 상 어디까지 지원될지는 직접 부딪혀봐야 알겠지만, 어떻게든 답이 나오지 않을까 싶습니다.
