5. 독립 노드와 2대 pair

pair는 메모리를 늘리는 방법이지만 장애 표면도 두 배로 넓히는 하나의 셀이다

이 장에서 처음 나오는 말4개

cell배치 셀

함께 예약하고 함께 실패한다고 보는 최소 장비 묶음. single cell은 Spark 한 대, pair cell은 두 대다.

worker selector

label 조건을 만족하는 worker만 deployment 후보로 남기는 scheduling 규칙이다.

tensor parallelismTP

한 layer의 tensor 연산과 weight를 여러 GPU로 나누는 방식. 통신이 매 layer 경로에 들어간다.

fallback target

주 target이 응답할 수 없을 때 route가 보내는 대체 deployment 또는 provider다.

topology를 자산 이름 밖으로 꺼낸다

spark-01  cell=pair-a  cell-role=member  fabric=cx7-a  workload=llm
spark-02  cell=pair-a  cell-role=member  fabric=cx7-a  workload=llm
spark-03  cell=pair-b  cell-role=member  fabric=cx7-b  workload=llm
spark-04  cell=pair-b  cell-role=member  fabric=cx7-b  workload=llm
spark-05  cell=single  workload=general
...
spark-NN  cell=single  workload=staging

label은 scheduler가 읽는 의도다. spark-01과 spark-02가 옆 번호라는 사실에 topology를 숨기지 않는다. pair를 실제 분산 instance에 쓸 때는 selector만 믿지 말고 배포 화면에서 두 GPU를 수동 선택해 엉뚱한 pair가 섞이지 않게 한다.

replica와 pair를 혼동하지 않는다

독립 replica 둘

같은 weight를 두 번 올린다.

각 worker가 요청 하나를 끝까지 처리한다.

처리량과 새 요청 가용성이 늘어난다.

노드 하나가 죽어도 다른 replica는 산다.

한 대에 들어가는 모델의 기본 선택이다.

2대 distributed instance

한 model instance가 두 worker를 함께 쓴다.

weight·연산을 TP/PP로 나누고 worker 간 통신한다.

한 대에 안 들어가는 모델을 실행할 수 있다.

둘 중 하나가 죽으면 instance 전체가 영향을 받는다.

고속 ConnectX-7 경로와 별도 검증이 필요하다.

GPUStack에서 multi-worker는 vLLM·SGLang·MindIE에만 켤 수 있다. FastAPI custom backend에는 쓰지 않는다. DGX Spark 두 대에서 vLLM을 함께 실행하면 기술적으로 분산 추론이므로, 평소 독립 노드 운영과 다른 실험·장애 기준을 적용한다.

여러 pair를 하나의 모델 이름으로 묶는다

고정 pair마다 deployment를 하나 만들면 장애와 변경 범위가 명확하다. GPUStack model route에 두 target을 넣고 weight를 조절한다. 새 backend image는 pair-b에 먼저 배포해 검증한 뒤 weight를 넘길 수 있다. LiteLLM에는 large-prod 하나만 보여 topology 변경을 숨긴다.

pair 하나만 있을 때

pair 하나는 대용량 실행 능력을 주지만 HA를 주지 않는다. 중요한 서비스라면 다음 중 하나가 필요하다.

• 같은 model을 올린 두 번째 pair
• 품질은 낮지만 한 Spark에 들어가는 quantized model fallback
• 정책상 허용되는 외부 provider fallback
• 명시적인 중단 허용과 복구 목표

네트워크는 pair 안쪽만 빠르면 되는가

NVIDIA는 여러 Spark를 QSFP switch의 200Gbps port에 연결하는 playbook을 제공한다. pair가 고정이면 각 pair를 직접 연결할 수도 있지만, 여러 pair 사이에 target을 옮기거나 향후 재구성하려면 switch fabric이 운영하기 쉽다. 어느 쪽이든 NCCL test와 실제 model benchmark 둘 다 통과해야 한다.

10GbE는 독립 replica의 API와 관리 트래픽에는 충분할 수 있지만 TP 통신의 대체품으로 가정하지 않는다. 한 대와 두 대를 다음 지표로 직접 비교한다.

지표	확인할 질문
model load 시간	pair가 두 곳의 download·load 때문에 얼마나 느려졌나
TTFT	통신 비용을 포함한 첫 token 시간이 개선됐나
decode tokens/s	긴 출력에서 실제 처리량이 나아졌나
동시 사용자 처리량	replica 둘보다 pair 하나가 유리한가
장애 감지·복구	member 하나를 재부팅하면 route에서 언제 빠지고 언제 돌아오나

선택 순서

single 1개 → single replica 여러 개 → 2대 pair → pair replica 순서로 올라간다. 앞 단계로 요구를 만족하면 다음 단계의 통신·장애 복잡도를 사지 않는다.

참고 자료

• GPUStack Scheduling — worker label, GPU selector와 multi-worker 대상 backend.
• GPUStack Distributed vLLM — leader/follower와 MP backend의 실험적 multi-worker 구성.
• GPUStack Model Route — 여러 target의 weight와 fallback.
• NVIDIA Multiple DGX Spark through a Switch — 200Gbps QSFP switch 구성과 NCCL 검증 전제.

6. 운영 — 메모리·파일·장애unified memory와 모델 artifact를 포함해 평상시 루틴, 변경 순서와 장애 진단 사다리를 만든다.