실행 프로그램과 확장
DGX Spark 두 대를 연결하면 무엇이 실제로 좋아질까
Spark 한 대로 모델을 띄웠습니다. 그런데 답변이 기대보다 느립니다. 같은 장비를 한 대 더 연결하면 해결될까요? 두 번째 장비가 나눠 맡을 일이 무엇인지에 따라 답이 달라집니다. 더 큰 모델을 담는 것부터 한 사람의 기다림을 줄이는 것까지, 각각 나누어 보겠습니다.
한 대에 들어가지 않는 모델이라면
첫 번째 이유는 비교적 명확합니다. 원하는 모델과 대화용 캐시가 한 대의 메모리에 들어가지 않는 경우입니다. 실행 프로그램이 모델을 두 노드에 나눠 담을 수 있다면, 두 번째 장비의 공간으로 실행 가능 범위를 넓힐 수 있습니다.
총 256GB라는 표기는 128GB 메모리 두 개의 합입니다. 아무 프로그램에서나 256GB 한 덩어리처럼 쓰는 것은 아닙니다. 모델을 어떻게 나누고 각 장비에 캐시를 얼마나 남길지 정하는 분산 실행 경로가 필요합니다.
이미 한 대에 들어간다면 질문이 바뀝니다
이번에는 같은 모델이 한 대에 여유 있게 들어간다고 해봅시다. 두 대로 나누면 각 장비가 맡는 계산은 줄어들 수 있습니다. 대신 중간 결과를 네트워크로 주고받고 서로 기다리는 시간이 생깁니다. 이 추가 시간을 넘게 계산을 줄여야 한 답변이 빨라집니다.
분할 방식에 따라 차이도 납니다. 모델의 앞뒤를 나누는 경우와 한 층의 계산을 함께 나누는 경우는 통신 시점이 다릅니다. 두 장비의 대역폭 수치를 더한 값만으로 디코드 속도를 계산할 수 없는 이유입니다.
최적 설정이라는 말에 무엇이 들어 있나요?
빠른 결과를 봤다면 장비 수뿐 아니라 모델 파일, 양자화, MTP, 입력 길이와 동시 요청 수도 함께 봐야 합니다. 한 대는 기본 설정이고 두 대는 MTP와 다른 압축본을 썼다면, 그 차이 전부를 두 번째 장비의 효과라고 할 수는 없습니다.
비교 순서는 한 대에서 사용할 수 있는 설정을 먼저 정하고, 같은 모델의 두 대 경로와 나란히 보는 것입니다. 한 대에 없는 기능을 두 대에서만 쓸 수 있다면 그것도 중요한 장점이지만, 무엇이 달라졌는지를 남겨야 다음 업데이트 뒤에도 결과를 이해할 수 있습니다.
여러 일을 동시에 시키면 이야기가 달라집니다
채팅 하나가 아니라 문서 처리와 코딩 에이전트가 동시에 요청하는 서버라면 전체 처리량이 중요해집니다. 모델을 각각 복제해 서로 다른 요청을 맡기거나, 분산 모델이 더 많은 요청을 처리하게 구성할 수 있습니다. 어느 쪽이 맞는지는 모델 크기와 런타임에 달려 있습니다.
이때 총 토큰 수가 늘어도 개별 요청은 늦어질 수 있습니다. 한 요청의 첫 토큰 시간과 디코드 속도, 같은 시간 동안 완료한 요청 수를 나누어 기록해야 합니다. 가족이나 팀이 함께 쓰는 환경이라면 가장 오래 기다린 사람의 경험도 빼놓지 마세요.
두 번째 장비의 가격에 무엇을 기대할지
큰 모델이 꼭 필요해서 한 대로는 실행할 수 없다면 용량 확대 자체가 구매 이유입니다. 반면 혼자 짧은 대화를 빠르게 하려는 목적이라면, 두 대를 관리하고 연결하는 비용까지 내면서 얼마나 기다림을 줄이는지 확인해야 합니다.
사이트에서 한 대와 두 대의 예상 체감을 비교해보세요. 다만 특정 패치와 런타임의 최고 기록을 모든 모델에 적용한 실측 화면은 아닙니다. 차이가 작다면 한 대의 설정을 다듬는 쪽을, 두 대에서만 가능한 일이 있다면 그 작업을 중심으로 판단하면 됩니다. 두 번째 장비가 반드시 할 일이 있어야 합니다.