MIG가 p95를 절반으로

Lambda 1x A100 40GB SXM4에서 7개 테넌트를 두고, 공유 GPU와 7× 1g.5gb MIG 슬라이스를 비교했다.

• 모델: Qwen/Qwen2.5-1.5B-Instruct
• 서버: vLLM OpenAI-compatible server (vllm serve)
• 실행 모드: 양쪽 모두 **enforce-eager: true**로 통일
• 구성: Tenant A는 보호 대상, B~G는 noisy neighbor

핵심 결과는 분명하다. Tenant A의 quiet-phase p95는 공유 모드에서 약 2,499ms, MIG 모드에서 약 1,319ms였다. 즉 약 1,180ms, 비율로는 약 47% 낮아졌다.

노이즈가 커지는 burst 구간에서도 MIG 쪽 Tenant A는 거의 평평하게 유지됐고, 공유 모드에서는 이미 높은 지연이 깔린 상태에서 더 악화됐다. 이 실험에서는 단순히 burst가 문제라기보다, 공유 co-location 자체가 지속적인 latency penalty를 만들었다는 해석이 맞다.

재현 과정에서 중요한 이슈도 드러났다. CUDA_VISIBLE_DEVICES=MIG-<UUID>로 vLLM을 띄우자 device_id_to_physical_device_id()가 장치 ID를 정수로 파싱하려다 실패했다. 즉, 당시 릴리스 기준 vLLM은 MIG UUID를 1급 장치로 다루지 못했다. 저자는 이를 우회하기 위해 vLLM PR #35526 기반의 수정 버전을 부트스트랩 스크립트로 포함했다.

실험에서 시도했지만 제외한 것들도 정리했다.

• 2테넌트 구성은 압력을 충분히 만들지 못했다.
• 클라이언트 부하만 증가시키면 GPU 경합이 자동으로 늘지 않았다.
• 실행 모드를 섞는 방식은 비교 변수를 2개로 만들어 부적절했다.
• 7개를 동시에 시작하면 shared 모드에서 KV-cache allocation 오류가 났고, staggered startup이 필요했다.

결론적으로, 이 벤치마크에서는 MIG가 noisy-neighbor 격리를 실질적으로 개선했다. p95 SLA가 중요하고 이웃 워크로드의 변동성에 흔들리면 안 되는 환경이라면, 공유 GPU보다 MIG가 더 예측 가능한 선택이 될 수 있다.