DGX Spark 한 대에 Qwen3 모델 두 개 올리기 — 메모리 계산법 뜯어보기

무슨 일이 있었냐면요

엔비디아가 내놓은 DGX Spark는 책상 위에 올려놓고 쓰는 작은 AI 컴퓨터예요. 한 블로거가 이 한 대에 알리바바의 오픈 모델 Qwen3 두 개를 동시에 올려서 돌릴 수 있는지, 메모리 계산을 직접 해본 글을 정리했어요. "로컬에서 큰 모델 여러 개를 동시에 굴리고 싶은데 메모리가 될까?"라는, 요즘 LLM을 직접 돌려보는 분들이 한 번쯤 부딪히는 현실적인 고민을 정면으로 다룬 글이에요.

DGX Spark가 뭔데요

이게 뭐냐면, 엔비디아의 GB10 Grace Blackwell 칩을 얹은 미니 PC 같은 기기예요. 가장 큰 특징은 128GB의 통합 메모리(unified memory)예요. 보통 PC는 CPU용 램과 그래픽카드용 VRAM이 따로 떨어져 있어서 데이터를 왔다 갔다 복사해야 하는데, 이건 CPU와 GPU가 같은 메모리 풀을 통째로 공유해요. 덕분에 큰 모델을 통째로 메모리에 올리기가 수월하죠. 애플 실리콘 맥의 통합 메모리랑 비슷한 발상이에요.

'레지던시 계산'이 핵심이에요

여기서 레지던시(residency)라는 말이 나오는데, 이게 뭐냐면 "모델을 메모리에 상주시켜 둔다"는 뜻이에요. 모델을 쓸 때마다 디스크에서 새로 불러오면 너무 느리니까, 메모리에 계속 올려둬야 빠르게 응답할 수 있거든요. 문제는 메모리 예산이 한정돼 있다는 거예요. 모델 두 개를 동시에 상주시키려면 다음 세 가지를 다 더해서 128GB 안에 욱여넣어야 해요.

모델 가중치(weights): 모델의 본체예요. 예를 들어 320억(32B) 파라미터 모델을 16비트로 올리면 약 64GB, 8비트로 양자화하면 절반인 32GB, 4비트면 또 절반인 16GB 정도로 줄어요. 양자화(quantization)가 바로 이렇게 숫자의 정밀도를 낮춰서 모델 용량을 줄이는 기술이에요.
KV 캐시: 모델이 긴 문맥을 기억하기 위해 쓰는 임시 메모리인데, 다루는 문맥(컨텍스트)이 길어질수록 이게 쭉쭉 커져요. 의외로 여기서 메모리가 많이 새 나가요.
실행 오버헤드: 추론 엔진 자체가 쓰는 여유 공간도 남겨둬야 하고요.

그래서 글에서는 "32B 모델 하나를 16비트로 올리면 다른 모델 자리가 안 남는다, 그럼 양자화로 눌러서 두 모델을 4비트나 8비트로 올리자" 식의 줄다리기 계산을 보여줘요. 결국 두 모델을 동시에 올리려면 정밀도를 일부 희생해야 한다는 현실적인 트레이드오프가 나오는 거죠.

왜 두 개를 동시에 올릴까요

궁금할 수 있어요. 모델 하나도 큰데 왜 두 개를? 실무에선 역할을 나누는 경우가 많거든요. 예를 들어 코딩 전용 모델 하나와 일반 대화 모델 하나를 띄워두고 요청 종류에 따라 골라 쓰거나, 작은 모델이 먼저 받아서 "이건 큰 모델한테 넘겨야겠다"고 판단하는 라우팅 구조를 짤 수도 있어요. 이럴 때 매번 모델을 바꿔 끼우면 느리니까, 둘 다 상주시켜 두는 게 유리한 거예요.

업계 흐름에서 보면

이건 엔비디아가 밀고 있는 "AI를 클라우드 말고 내 책상에서"라는 흐름의 한 장면이에요. 애플의 맥 스튜디오(통합 메모리로 큰 모델 돌리기), AMD의 통합 메모리 APU 등도 같은 시장을 노리고 있죠. 여기에 Qwen3가 등장하는 건 의미가 있어요. 라마(Llama) 계열과 더불어 가중치를 공개한 오픈 모델이라, 이렇게 로컬 기기에 자유롭게 올려 실험할 수 있거든요.

한국 개발자에게는

회사 데이터를 외부 API에 보내기 부담스러운 한국 기업 환경에선 이런 로컬 LLM 구성이 점점 매력적이에요. 보안 때문에 망분리된 환경에서 LLM을 써야 하는 금융·공공 쪽이 특히 그렇고요. 직접 DGX Spark를 사지 않더라도, 이 글이 보여주는 메모리 = 가중치 + KV 캐시 + 오버헤드라는 계산 감각은 어떤 GPU에서 모델을 굴리든 똑같이 적용되니 익혀두면 두고두고 써먹어요.