메인 콘텐츠로 건너뛰기
A 70B model at FP16 needs ~140 GB of VRAM. No single consumer GPU holds that. Sharding is how inference engines split a model across multiple GPUs — or multiple machines — so you can serve models that physically cannot fit on 1 device, or serve more users than 1 device handles. 이 대시보드에서는 4 샤딩 전략들의 작동 방식과 각각이 작업을 어떻게 분배하는지, 그리고 어떤 전략이 사용자의 하드웨어에 적합한지 설명합니다. TP와 PP 중 어떤 것을 선택해야 할지 빠르게 알아보려면 텐서 병렬 처리와 파이프라인 병렬 처리를 참고하세요.

​
왜 샤딩을 사용해야 하는가?

You reach for sharding when 1 of 4 things is true:
  1. The model is too large for 1 GPU. A 70B dense model at FP16 needs ~140 GB. Even at Q4 quantization (~35 GB), it fills a single RTX 4090 (24 GB). You need at least 2 GPUs to hold the weights.
  2. 토큰당 지연 시간을 줄여야 할 때. 모든 GPU가 각 토큰 처리에 동시에 참여하면 토큰당 소요 시간이 단축됩니다.
  3. 처리량을 높여야 할 때. GPU 개수가 많을수록 더 많은 사용자에게 동시에 서비스를 제공할 수 있습니다.
  4. 중복성 확보가 필요할 때. 로드 밸런서 뒤에 2 개의 복제본을 운영하면 1 GPU 중 하나가 고장 나더라도 서비스 중단 없이 작동할 수 있습니다.
만약 업스트림 모델 ID가 1 GPU에 이미 적합하고 처리량 측면에서도 문제가 없다면 1 GPU를 그대로 사용하시기 바랍니다. 샤딩을 사용하면 복잡성이 증가하고 통신 오버헤드도 발생합니다.

​
GPU 메모리가 실제로 어디에 사용되는가

샤딩 전략을 선택하기에 앞서 VRAM을 차지하는 요소들이 무엇인지 파악해야 합니다. 단순히 모델 가중치만이 아닙니다: A 24 GB RTX 4090 running a 70B Q4 model has ~35 GB of weights — it does not fit on 1 GPU at all. With TP=2, each GPU holds ~17.5 GB of weights and has ~6.5 GB left for KV cache and overhead. That is enough for short contexts and a few concurrent users, but not much more.
실제 사용 가능한 메모리는 총 VRAM 용량보다 적습니다. DGX Spark (통합 메모리 128 GB)에서는 운영체제와 런타임이 차지하는 영역을 제외하고 모델 및 KV 캐시용으로 약 110 GB만 활용 가능합니다. 개별 GPU 환경에서는 vLLM의 --gpu-memory-utilization 값(기본값 0.90)이 이를 결정합니다. 메모리 부족 현상이 발생한다면 이 값을 낮춰주시기 바랍니다.
MoE 모델의 경우 구성 요소별 분포가 다르며, 전문가용 레이어가 대부분을 차지합니다: 이런 이유로 전문가 병렬 처리가 존재합니다. 모든 231 기가바이트 분량의 전문가들을 각 GPU에 모두 로드하는 대신, 각 GPU는 자신에게 할당된 전문가들만 보유하게 됩니다. 아래의 전문가 병렬 처리 항목을 참고하세요.

​
2가지 결정 사항: 우선 용량에 맞게 조정한 뒤 속도까지 최적화하기

샤딩 방식은 2가지 질문에 순차적으로 답해줍니다: 용량에 맞게 조정하기 — 가중치 데이터와 KV 캐시를 위한 여유 공간을 GPU 메모리 예산 내에 수용해야 합니다:
  • 먼저 양자화를 수행하세요. FP16 방식에서 Q4 방식으로 전환하면 가중치 데이터에 필요한 메모리 용량이 ~4배가 줄어듭니다. 이는 가장 저렴하게 얻을 수 있는 이득입니다. 양자화 가이드를 확인해보세요.
  • GPU들 간에 모델을 분할하세요. 양자화만으로는 부족할 경우 TP, PP, EP 방식을 활용해 모델을 분할해야 합니다.
  • 전문가 수 감축 (MoE 전용). 256개의 전문가가 존재하는 MoE 모델에서는 각 토큰당 6개의 전문가만 활성화되는데, REAP 방식의 전문가 감축 기법을 적용하면 활성화된 전문가의 가중치만 대략 절반 수준으로 줄여주어 실제 연산 부하에는 영향을 주지 않습니다.
속도 최적화 – 모델 배포가 완료되면 토큰당 사용되는 바이트 수와 디코딩 단계를 줄여보세요.
  • 적절한 병렬 처리 방식 선택. TP 방식이 토큰당 지연 시간을 최소화합니다. PP 방식은 네트워크 속도가 느릴 때도 안정적이며 DP 방식은 처리량을 크게 높여줍니다.
  • 모델에서 공식적으로 제시하는 스펙큘레이티브 디코딩 경로 활용. DeepSeek-V4-Flash-0731 모델의 경우 공식 vLLM 또는 SGLang 설정값을 이용해 기본 제공되는 DSpark 모듈을 활성화하세요. 별도의 드래프트 체크포인트를 따로 설정할 필요는 없습니다. 자세한 내용은 모델 서비스 및 확장성을 참고하시기 바랍니다.
  • KV 캐시와 배치 크기 조정. KV 캐시 여유 공간이 많을수록 동시 접속 가능한 사용자 수가 늘어납니다. 자세한 내용은 DGX Spark 메모리 튜닝을 참고하시기 바랍니다.

​
The 4 sharding strategies at a glance

DeepSeek-V4-Flash-0731 is a practical sharding case: 13B active parameters lower per-token compute, but all 284B parameters still need resident weight memory. See DeepSeek V4 Flash local hardware for the memory floor and the maturity of each 2-device route.

​
텐서 병렬화: 여러 GPU에 레이어를 분할하는 방식

텐서 병렬화(TP)는 각 레이어의 가중치 행렬을 여러 GPU에 나누어 저장합니다. 각 GPU는 모든 레이어의 일부분만을 보유하며, 모든 GPU가 동시에 동일한 토큰을 처리합니다.
각 레이어 처리 후 GPU들은 AllReduce 연산을 수행하여 각자의 부분 결과를 합쳐 최종 출력값을 만들어냅니다. 이 방식으로 개별 토큰 처리 지연 시간이 낮게 유지되지만 GPU 간 고대역폭 통신이 필수적입니다. Memory: each GPU holds 1/N of the model weights, where N is the TP degree. A 70B model at Q4 (~35 GB) with TP=2 puts ~17.5 GB of weights per GPU. 지연 시간: 개별 토큰 처리 시 가장 낮은 지연 시간을 보입니다. 모든 GPU가 각 토큰을 계산하므로 실제 소요 시간은 연산 시간과 AllReduce 동기화 시간의 합이 됩니다. Best for: 2–4 GPUs connected by NVLink or a fast PCIe bus. The 200Gb/s QSFP link between 2 DGX Sparks is ideal. vLLM 설정값: --tensor-parallel-size 2
PCIe delivers 3–5× less bandwidth than NVLink for AllReduce operations. Tensor parallelism over PCIe still works — 2× RTX 4090 at TP=2 is a common setup — but expect 20–30% lower decode throughput than the same model on NVLink-connected GPUs.

​
Example: 70B on 2× RTX 4090

각 GPU는 약 17.5 GB 분량의 Q4 가중치 데이터를 보유합니다. 나머지 약 6.5 GB는 각 GPU에서 KV 캐시와 CUDA 그래프를 저장하는 데 사용됩니다.

​
파이프라인 병렬화: 레이어들을 순차적으로 분배하는 방식입니다.

파이프라인 병렬화(PP)에서는 인접한 레이어 그룹들을 각기 다른 GPU에 할당합니다. GPU 0은 레이어 0부터 19까지를, GPU 1은 레이어 20부터 39까지를 담당합니다. 토큰들은 마치 조립 라인처럼 파이프라인을 따라 흐르게 됩니다.
각 GPU는 자신에게 할당된 레이어들을 처리한 뒤 활성화값을 다음 단계로 전달합니다. GPU 간에 주고받는 데이터는 단일 레이어 경계에 해당하는 활성화 텐서이며, 이는 TP 방식에서 교환되는 전체 가중치 행렬에 비해 훨씬 작은 크기입니다. 메모리: 각 GPU는 자신에게 할당된 레이어들만을 저장합니다. PP=2 설정 시 GPU 0은 모델의 전반부를, GPU 1은 후반부를 보유하게 됩니다. 지연 시간: 각 단계의 지연 시간이 합산됩니다. 하나의 토큰은 모든 단계를 순차적으로 거쳐야 하므로, PP=2일 때 지연 시간은 각 단계의 지연 시간을 모두 더한 값과 거의 같습니다. 통신: 인접한 단계 간에만 일대일 통신이 이루어집니다. 이웃 GPU들끼리만 데이터를 주고받으므로 대역폭 요구량이 낮습니다. 따라서 PP는 PCIe, 이더넷 혹은 기기 간 네트워크 링크와 같이 속도가 느린 상호연결망에도 적합합니다. 버블 문제: 배치 크기가 작을 경우 앞단 GPU들이 레이어 처리를 마치면 뒤단 GPU들은 대기 상태가 됩니다. PP=2이고 배치 크기가 1일 때 GPU 1은 GPU 0이 모든 레이어 경계 처리를 마칠 때까지 기다려야 합니다. 배치 크기가 커지면 이 현상이 완화되는데, vLLM의 연속 배치 처리 기능이 파이프라인 가동률을 높이는 데 기여합니다. vLLM 플래그: --pipeline-parallel-size 2

​
PP가 TP보다 유리한 경우

다음과 같은 상황에서는 텐서 병렬화 대신 파이프라인 병렬화를 사용하는 것이 좋습니다.
  • GPU들이 서로 다른 기기에 위치하며 네트워크로 연결된 경우(10GbE부터 100GbE까지).
  • GPU들은 PCIe를 통해 연결되며 모델 크기가 충분히 작아서 병렬화 배포 시 발생하는 버블 오버헤드가 TP의 AllReduce 대역폭 비용보다 낮습니다.
  • 모든 노드에서 TP를 적용하면 인터커넥트 대역폭이 포화 상태가 되므로 3+ 노드들을 연쇄적으로 연결합니다.

​
데이터 병렬화란 여러 GPU에서 동일한 모델을 실행하는 방식입니다.

데이터 병렬화(DP)는 각 GPU마다 모델 전체 사본을 실행하고 들어오는 요청들을 분배합니다. 추론 시 GPU 간 통신은 전혀 없으며 각 GPU는 자체 요청 배치만 독립적으로 처리합니다.
Memory: N copies of the full model. A 7B model at Q4 (~4 GB) with DP=4 uses 16 GB total across 4 GPUs. This is the expensive part — you trade memory for throughput. 지연 시간: 단일 GPU 추론 시와 동일합니다. 각 GPU는 토큰들을 독립적으로 처리합니다. 처리량: 선형적으로 증가합니다. 4 개의 복제본을 사용하면 동시 접속 사용자 수가 약 4배로 늘어납니다. 적합한 경우: 다수의 사용자에게 동시에 서비스를 제공해야 할 때, 1 GPU에 적재 가능한 모델들(7B, 14B, 때로는 강력한 양자화 수준에서 32B까지)에 가장 적합합니다. vLLM 설정법: 여러 vLLM 인스턴스를 실행한 뒤 그 앞단에 로드 밸런서를 배치합니다.
이후 nginx나 HAProxy, 혹은 기타 라운드로빈 방식의 밸런서를 활용해 /v1/chat/completions 개의 요청을 두 포트에 골고루 분배합니다.

​
전문가 병렬화는 혼합형 전문가 모델용 기법입니다.

Expert parallelism (EP) applies only to mixture-of-experts (MoE) models. In an MoE model, each token activates only a small subset of the model’s “experts” — for example, Qwen3-235B has 256 routed experts but only 6 fire per token (~22B active parameters out of 235B total). EP puts different experts on different GPUs so you do not waste memory storing inactive experts everywhere.
Memory: each GPU holds only its assigned experts. The dense stack (attention, embeddings, shared layers — ~14 GB at 4-bit for Qwen3-235B) is replicated on every GPU. The expert planes (~231 GB at 2-bit) are sharded. This is far more memory-efficient than TP, which would replicate all 256 experts on every GPU even though most sit idle for each token. 통신: GPU 간 모든 조합의 통신이 가능합니다. 특정 토큰에 대해 라우터가 다른 GPU에 있는 전문가를 선택할 경우, 해당 활성화 데이터가 그 GPU로 전송되어야 합니다. 이로 인해 일부 토큰은 로컬 GPU에서 처리되지만 다른 토큰들은 여러 GPU를 거치게 되는 등 다양한 통신 패턴이 발생합니다. vLLM flag: --enable-expert-parallel combined with --tensor-parallel-size
DGX Spark의 128 GB에 달하는 통합 메모리는 전문가 병렬 처리에 매우 적합합니다. 약 110 GB의 가용 메모리를 갖춘 단일 Spark 노드는 복잡한 모델 계층 구조와 다수의 전문가 모듈을 로컬에 수용할 수 있어, 전문가 병렬 처리 시 발생하는 GPU 간 데이터 전송 부하를 줄여줍니다. Qwen3-235B와 같은 모델의 경우 1 노드에서도 전문가 병렬 처리가 한계에 부딪힐 수 있으므로, 전문가 모듈 선별 기법과 2 비트 정밀도의 양자화 기법을 병행하여 각 노드에 필요한 메모리 용량을 예산 범위 내로 조절할 수 있습니다. 하드웨어 관련 세부 정보는 DGX Spark 활용 사례를 참고하시기 바랍니다.

​
전략의 조합: TP, PP, DP

다수의 GPU를 활용할 때는 전략들을 계층적으로 결합합니다.
  • 노드 내 TP: 상호 연결망 속도가 빠른 경우에 적용됩니다.
  • 노드 간 PP: 상호 연결망 속도가 느린 경우에 적용됩니다.
  • 처리량 확보를 위한 DP: TP와 PP가 결합된 설정을 여러 번 복제하여 실행하는 방식입니다.

​
4개의 GPU를 사용할 때: TP=2 + PP=2

이렇게 하면 2개의 파이프라인 단계가 생성되며 각 단계에서는 2방향 텐서 병렬 처리가 이루어집니다. 0번과 1번 GPU는 TP 방식으로 레이어의 전반부를 처리하고, 2번과 3번 GPU는 TP 방식으로 레이어의 후반부를 처리합니다.

​
8개의 GPU를 사용할 때: TP=4 + DP=2

Run 2 replicas of a 4-way tensor-parallel setup. Each replica uses 4 GPUs for TP, and a load balancer distributes requests between the 2 replicas. This gives you the low latency of TP=4 with 2× the throughput.

​
대략적인 지침

  1. 우선 TP — 가능한 가장 빠른 인터커넥트를 활용합니다(NVLink, QSFP, PCIe).
  2. 그 다음 PP — 속도가 느린 링크를 사용합니다(이더넷, 머신 간 네트워크).
  3. 마지막으로 DP — 처리량 증대가 필요하고 복제본용 여유 GPU가 있을 때 적용합니다.
vLLM은 TP × PP = total GPUs used for one replica을 요구합니다. --tensor-parallel-size 4 --pipeline-parallel-size 2 값을 지정하면 vLLM은 8 개의 GPU를 1 개 복제본에 할당합니다.

​
샤딩 결정 매트릭스

70B, 2개의 RTX 4090 GPU(PCIe 방식)

PP 방식입니다. PCIe 대역폭은 효율적인 AllReduce에 부족합니다. 파이프라인 병렬 처리가 병목 현상을 방지합니다.

70B, 2개의 A100 GPU(NVLink 방식)

TP 방식입니다. NVLink는 AllReduce에 충분한 대역폭을 제공하며 토큰당 지연 시간도 낮아집니다.

235B MoE, DGX Spark

EP. 네이티브 MoE 처리 방식 — 각 GPU는 전체 235B을 보유하는 대신 자체 전문가 모듈만 관리합니다.

7B 환경에서 대량 트래픽 처리 가능

DP. 모델이 1 GPU에 적합합니다. 처리량 향상을 위해 복제해 사용할 수 있습니다.

70B, 4대의 A100 기기 (NVLink 연결)

TP=4 (지연 시간보다 처리량이 중요하다면 TP=2 + DP=2 방식도 가능합니다).

70B, 2 형태의 기기들

PP=2. 기기 간 네트워크 대역폭이 TP 구현에 부족합니다. 파이프라인 방식으로 대역폭 한계를 극복할 수 있습니다.

​
실제 사용 가능한 명령어들

​
샤딩 기능이 정상 작동하는지 확인하기

모든 GPU에서 nvidia-smi을 실행하세요. 참여한 GPU들 모두 모델을 위한 메모리가 할당된 것을 확인할 수 있습니다:
TP=2 설정 시 두 GPU의 메모리 사용량이 거의 동일해야 합니다. PP=2 방식에서는 모델의 앞부분 레이어 크기와 뒷부분 레이어 크기가 다를 경우 메모리 분배가 불균형해질 수 있습니다.

​
흔히 발생하는 실수들

느린 PCIe 환경에서 TP 활용하기. AllReduce는 각 레이어 처리 후 활성화 데이터를 전송합니다. PCIe 3.0 환경에서는 디코딩 처리량이 크게 저하됩니다. 만약 GPU에 NVLink가 없다면 PP 방식을 시험해보고 비교해보시기 바랍니다. 배치 크기 1으로 PP 사용하기. 한 번에 1개의 토큰만 처리될 경우 파이프라인 내부에 불필요한 공백이 생겨 연산 자원이 낭비됩니다. vLLM의 연속 배치 처리 기능이 이 문제를 완화해주므로, 파이프라인이 가득 차도록 충분한 동시 요청을 보내주어야 합니다. DP 방식에서는 모델 메모리 용량이 N배로 필요하다는 점을 간과해서는 안 됩니다. 4개의 70B Q4 모델 복제본(각각 약 35 GB 크기)을 운용하려면 총 140 GB의 메모리가 필요합니다. 복제본을 추가하기 전에 반드시 메모리 용량을 계획해두어야 합니다. KV 캐시를 간과하지 마세요. GPU 메모리에는 모델 가중치만 존재하는 것이 아닙니다. 활성화된 시퀀스들을 위한 KV 캐시가 나머지 공간을 차지합니다. 2개의 GPU에 가중치를 분산 배치하면 KV 캐시도 함께 분산되어 동시 사용자 수용 능력이 두 배로 증가합니다. 하지만 가중치만을 고려해 메모리를 계획한다면 메모리 부족 현상이 발생할 수 있습니다. 따라서 분산 배치 전략을 선택하기 전에 가중치, KV 캐시, 그리고 약 3 GB의 오버헤드까지 모두 고려해 메모리를 확보해야 합니다. TP와 PP의 적용 순서를 혼동하지 마세요. vLLM은 각 파이프라인 단계 내에서 TP를 적용합니다. --tensor-parallel-size 값에는 단일 노드 내 GPU 개수를, --pipeline-parallel-size 값에는 노드 개수를 입력해야 합니다. 순서를 바꿀 경우 PP가 노드 내부에서 적용되어 고속 인터커넥트가 낭비되고, TP는 노드 간에 적용되어 네트워크가 AllReduce 트래픽으로 과부하됩니다.

​
다음 단계

텐서 병렬 처리와 파이프라인 병렬 처리의 비교

성능 벤치마크를 통한 TP와 PP의 상세 비교

DGX Spark을 하나 사용할지 두 개 사용할지

두 번째 Spark을 언제 추가해야 하며 200Gb/s 링크를 어떻게 설정해야 하는지

DGX Spark의 메모리 튜닝 방법

분산 배치 환경에서의 KV 캐시 계산법 및 메모리 설정값.

모델 서비스 제공 및 확장 방법

추론 엔진들이 배칭, 정밀도, 병렬 처리를 어떻게 관리하는지에 대해 설명합니다.