Oracle Kubernetes Engine 및 멀티클라우드 클러스터 전반에 걸쳐 대규모 언어 모델 (LLM)을 확장할 때, 피어 투 피어 (P2P) 네트워킹이 어떻게 26 TB 다운로드 문제를 해결하는지에 대하여.

참고: 이 기사는 원래 Oracle University Community (저자 배지)에 게시되었습니다. 이는 CNCF Dragonfly 커뮤니티 및 기타 사용자들이 로그인 없이 읽을 수 있도록 공개된 버전입니다. 또한 저의 Oracle ACE 프로필에서도 확인하실 수 있습니다.

아무도 예산을 책정하지 않는 문제

당신의 팀이 방금 대규모 파라미터 모델을 미세 조정 (Fine-tuning)했습니다. safetensors 체크포인트 (checkpoint) 용량은 100 GB를 훨씬 상회합니다. 월요일까지 귀하의 OKE 클러스터 전반에 걸쳐 200개의 GPU 노드에서 이 모델이 실행되어야 합니다.

계산을 해봅시다: 약 130 GB의 체크포인트에 200개의 노드를 곱하면, 단일 모델 허브로부터 약 26 TB의 네트워크 전송이 발생합니다. 모든 노드가 Hugging Face 또는 ModelScope로부터 동일한 거대 파일들을 독립적으로 가져옵니다. 공유 인터넷 출구 (egress)는 병목 지점 (chokepoint)으로 변합니다. 속도 제한 (Rate limits)이 적용됩니다. 동시에 다운로드를 시작한 노드들이 완료되는 시간은 몇 시간씩 차이가 납니다. 귀하의 GPU 플릿 (fleet)은 가중치 (weights)를 기다리며 아무것도 하지 못한 채 돈만 낭비하며 유휴 상태로 머물게 됩니다.

이것이 AI 모델 배포에서의 "천둥 치는 들소 (thundering herd)" 문제이며, 상황은 점점 더 악화되고 있습니다. 대규모 모델 체크포인트는 정밀도 (precision), 양자화 (quantization), 샤딩 (sharding) 및 리포지토리 버전에 따라 수십에서 수백 GB에 달할 수 있습니다. 이러한 것들은 작아지지 않고 있습니다. 그리고 기업들이 단일 프롬프트 상호작용에서 다단계 에이전트 AI (Agentic AI) 워크플로로 이동함에 따라, 인프라는 추론 포드 (inference pods)를 빠르게 생성해야 하며, 자율 에이전트 (autonomous agent)는 작업을 실행하기 전 모델이 다운로드될 때까지 몇 시간을 기다릴 수 없습니다. 도구, 리전 또는 클라우드 전반에 걸쳐 추론을 빠르게 확장해야 하는 에이전트 AI 시스템의 경우, 모델 배포는 신뢰성 아키텍처 (reliability architecture)의 일부가 됩니다.

멀티클라우드 Kubernetes 인프라를 구축하는 동안 저는 이 문제에 계속 부딪혔습니다. 일반적인 해결책들(NFS 마운트, 사전 빌드된 컨테이너 이미지, 오브젝트 스토리지 미러)은 모두 트레이드오프 (tradeoffs)가 존재합니다. NFS는 고가용성 (high availability)을 고려하여 설계되지 않으면 병목 현상이 되거나 단일 장애점 (single point of failure)이 될 수 있습니다. 모델을 컨테이너 이미지에 포함시키는 방식은 레지스트리 (registry)를 비대하게 만들고 모든 풀 (pull) 속도를 늦춥니다. 오브젝트 스토리지 미러는 유용하지만, 오래된 아티팩트 (stale artifacts)를 제공하는 것을 방지하려면 철저한 동기화 관리가 필요합니다.

더 나은 접근 방식이 있으며, 이는 이미 Alibaba 규모의 프로덕션 환경에서 실행되고 있습니다. 바로 피어 투 피어 (peer-to-peer, P2P) 배포입니다.

CNCF Dragonfly란 무엇인가?

Dragonfly는 모든 다운로드 노드를 피어 (peer)를 위한 시드 (seed)로 전환하는 CNCF Graduated 프로젝트입니다. 원래 Alibaba의 컨테이너 이미지 배포를 위해 구축되었으며, 하루 수십억 건의 요청을 처리합니다. 이 방식은 대용량 파일을 작은 조각으로 나누고 이를 P2P 메시 (mesh) 전체에 분산하는 방식으로 작동합니다.

핵심 아이디어는 오리진 서버 (origin server, Hugging Face, ModelScope, 개인용 OCI 버킷 등 무엇이든)가 시드 피어 (seed peer)에 의해 단 한 번만 호출된다는 것입니다. 단 하나의 조각이라도 도착하는 즉시 클러스터 내의 다른 노드들이 사용할 수 있게 됩니다. 배포는 초기 페치 (fetch)와 병렬로 시작됩니다.

200개의 노드에 걸쳐 있는 약 130GB 규모의 모델의 경우, 캐시가 워밍업 (cache-warmed)되었거나 프리히트 (preheated)된 이상적인 시나리오에서는 반복적인 오리진 다운로드를 약 26TB에서 약 130GB의 단일 오리진 복사본 수준으로 극적으로 줄일 수 있습니다. 각 노드가 수십 개의 로컬 피어로부터 동시에 데이터를 가져오기 때문에, 더 많은 피어가 조각들을 로컬에 캐싱할수록 나중에 참여하는 노드들은 더 빠르고 일관되게 다운로드할 수 있습니다.

올해 초, 저는 Hugging Face (hf://) 및 ModelScope (modelscope://)에 대한 네이티브 프로토콜 지원을 Dragonfly Rust 클라이언트에 직접 기여했습니다 (dragonflyoss/client 리포지토리의 PR #1665 및 #1673). 이러한 백엔드(Backends)를 통해 Dragonfly는 래퍼 스크립트(Wrapper scripts)나 URL 재작성(URL rewriting) 없이도 인증, 리비전 고정(Revision pinning), 리포지토리 구조를 포함한 모델 허브 URL을 네이티브하게 이해할 수 있습니다. CNCF는 https://www.cncf.io/blog/2026/04/06/peer-to-peer-acceleration-for-ai-model-distribution-with-dragonfly/에서 이 작업에 대한 가이드를 게시했습니다.

OCI에서 이것이 중요한 이유

OCI는 AI 워크로드(Workloads)를 위한 유능한 플랫폼이 되었습니다. OKE는 GPU 노드 풀(A10, A100, H100 셰이프)을 갖춘 관리형 Kubernetes를 제공하며, OCI는 지역, 셰이프(Shape), 약정 모델(Commitment model)에 따라 경쟁력 있는 GPU 가격을 제공할 수 있습니다. 선점형 인스턴스(Preemptible instances)를 사용하면 실험 비용을 더욱 낮출 수 있으므로, 해당 지역 및 셰이프에 대한 현재 OCI Compute 가격을 확인해 보시기 바랍니다.

하지만 네트워크 병목 현상(Network bottleneck)은 사용자가 어떤 클라우드에 있는지 상관하지 않습니다. 만약 50개의 OKE GPU 노드가 동시에 Hugging Face에서 약 130GB 크기의 모델을 가져오려 한다면, 여전히 수 테라바이트(TB)의 인터넷 이그레스(Egress), 속도 제한(Rate limiting), 그리고 GPU 유휴 상태(Idle GPUs) 문제를 마주하게 됩니다.

OKE 상의 Dragonfly는 단 한 가지의 아키텍처 변경으로 이 문제를 해결합니다. 바로 GPU 워크로드와 함께 DaemonSet으로 배포하는 것입니다. 시드 피어(Seed peer)가 오리진(Origin)으로부터 한 번 가져오면, 다른 모든 GPU 노드는 자신의 피어(Peers)로부터 조각들을 가져옵니다. 피어 투 피어(Peer-to-peer) 배포는 반복적인 인터넷 오리진 다운로드를 줄이고, 대부분의 전송을 클러스터 내부의 빠른 VCN 내부 네트워크(Intra-VCN network) 내에서 유지합니다.

OKE에 Dragonfly 배포하기

작동하는 설정을 위해서는 두 가지 단계가 필요합니다. 먼저 Dragonfly를 설치한 다음, 다운로드 경로 또는 컨테이너 런타임(Container runtime)이 이를 사용하도록 연결해야 합니다. Helm 설치부터 시작해 보겠습니다:

# Dragonfly Helm 저장소 추가
helm repo add dragonfly https://dragonflyoss.github.io/helm-charts/

...

Helm 차트(Helm chart)가 Dragonfly 구성 요소들을 설치하지만, 그것만으로는 Pull(가져오기) 요청을 P2P 메시(P2P mesh)를 통해 라우팅할 수 없습니다. 가속화하려는 대상에 따라 한 가지 단계가 더 필요합니다:

1. 차트 설치 (위 단계): 이를 통해 스케줄러(scheduler), 시드 피어(seed peer), 그리고 노드 상의 dfdaemon 데몬셋(DaemonSet)이 배포됩니다.
2. 모델 다운로드의 경우: 로컬 dfdaemon과 직접 통신하는 dfget을 사용합니다. 런타임(runtime) 변경은 필요하지 않습니다.
3. 컨테이너 이미지 Pull의 경우: containerd가 dfdaemon을 레지스트리 미러(registry mirror)로 가리키도록 설정하여 이미지 Pull이 P2P 경로를 통과하도록 합니다.

이미지 Pull 사례의 경우, 각 노드의 containerd 미러 설정은 대략 다음과 같습니다:

# /etc/containerd/certs.d/<registry-host>/hosts.toml
server = "https://<registry-host>"

...

여기서 127.0.0.1:65001은 로컬 dfdaemon 프록시(proxy)입니다. 설정을 적용한 후 containerd를 재시작하십시오. 클러스터 전반의 가속화를 기대하기 전에 이 단계를 미리 계획해야 합니다.

이 설정이 완료되면 모든 노드가 P2P 메시(P2P mesh)에 참여합니다. 모델의 경우, 네이티브 프로토콜(native protocols)을 사용하여 직접 Pull 하십시오:

# 모든 노드에 걸쳐 P2P 가속을 사용하여 DeepSeek-R1 다운로드
dfget hf://deepseek-ai/DeepSeek-R1 -O /models/DeepSeek-R1/ -r

...

참고: hf:// 및 modelscope:// 예제는 이러한 프로토콜 백엔드(protocol backends)를 포함하는 Dragonfly 클라이언트(및 Helm 차트) 버전이 필요합니다. 이 명령들을 사용하기 전에 설치된 버전에 Hugging Face 및 ModelScope 지원이 포함되어 있는지 확인하십시오.

멀티클라우드 관점

진정한 이점은 멀티클라우드(multicloud) 환경에서 나타납니다.

다음은 흔히 발생하는 패턴입니다: 학습(training)은 AWS(데이터 레이크가 있는 곳)에서 수행되지만, 추론(inference)은 OKE(더 나은 GPU 가격)에서 실행됩니다. 그 130GB 크기의 모델은 클라우드 간에 이동해야 합니다. 일반적인 방법은 무엇일까요? S3로 푸시(push)하고, 각 OKE 노드로 S3에서 풀(pull)하는 것입니다. 모든 노드가 독립적으로 다운로드하기 때문에, 각 OKE 노드에서 반복되는 Pull은 클라우드 간 이그레스(egress) 비용과 네트워크 오버헤드(network overhead)를 증가시킬 수 있습니다.

Dragonfly를 두 클러스터 모두에 배포하면, OKE 클러스터의 시드 피어(seed peer)가 오리진(origin, 또는 OCI Object Storage 미러)으로부터 모델을 단 한 번만 가져옵니다. 나머지 49개의 GPU 노드는 서로에게서 모델을 가져옵니다(pull). 이를 통해 크로스 클라우드 이그레스(cross-cloud egress)를 단일 복사본 수준으로 유지하고, 나머지 전송은 클러스터 내부로 전환할 수 있습니다.

여러 허브(hub)에서 가져올 때도 상황은 마찬가지입니다. 예를 들어, 팀에서 Hugging Face의 Llama와 ModelScope의 Qwen을 함께 사용할 수 있습니다. 두 프로토콜 모두 Dragonfly에 내장되어 있으므로, 동일한 P2P 메시(mesh)와 캐싱 레이어(caching layer)가 두 가지를 모두 처리합니다.

# 동일한 클러스터, 서로 다른 모델 허브, 동일한 P2P 메시
dfget hf://meta-llama/Llama-3.1-8B -O /models/llama/ -r
dfget modelscope://qwen/Qwen2-7B -O /models/qwen/ -r

이는 추가적인 운영 오버헤드(operational overhead) 없이 하나의 배포 레이어(distribution layer)가 여러 오리진을 처리하는 방식입니다.

OCI 서비스와의 통합

OCI에서 프로덕션(production) 환경을 구축할 때, 몇 가지 통합을 통해 아키텍처를 더욱 견고하게 만들 수 있습니다.

미러(mirror)로서의 OCI Object Storage. 네트워크가 제한되거나 규제가 있는 환경에서는 퍼블릭 인터넷 대신 프라이빗 Object Storage 버킷으로부터 Dragonfly에 시드(seed)를 공급할 수 있습니다. 액세스 패턴을 사전에 지정하십시오. Dragonfly는 사전 인증된 요청(PAR, pre-authenticated request)을 사용하여 HTTPS를 통해 가져오거나, 인터넷을 거치지 않고 프라이빗 액세스를 위해 서비스 게이트웨이(service gateway)를 통하거나, 또는 S3 호환 엔드포인트(S3-compatible endpoint)를 통해 가져올 수 있습니다. 모델 아티팩트(model artifacts)를 한 번 업로드하면, Dragonfly가 P2P를 통해 클러스터 전체로 이를 배포합니다.

모델 서빙 컨테이너를 위한 OCIR. Dragonfly는 OCI Container Registry(OCIR)로부터의 컨테이너 이미지 풀(pull) 속도도 높일 수 있습니다. CUDA 라이브러리를 포함하여 쉽게 15GB를 넘을 수 있고, CVE 노출 면적을 줄이기 위해 일반적으로 멀티 스테이지 Docker 빌드(multi-stage Docker builds)로 구축되는 vLLM 또는 Triton 추론 서버(inference server) 이미지들도 동일한 P2P 처리를 받을 수 있습니다. 이는 자동으로 이루어지는 것은 아닙니다. 컨테이너 런타임(container runtime)이 OCIR 풀을 Dragonfly의 레지스트리 미러/프록시(registry mirror/proxy)를 통해 라우팅하도록 구성하면, 그 이후부터 이미지 레이어(image layers)가 피어 투 피어(peer-to-peer) 방식으로 배포됩니다.

가시성을 위한 OCI Monitoring. Dragonfly는 P2P 전송 속도(transfer rates), 캐시 히트 비율(cache hit ratios), 피어 수(peer counts)에 대한 Prometheus 메트릭을 노출합니다. 이러한 메트릭은 OKE 상의 Prometheus/Grafana에서 스크래핑(scraping)할 수 있으며, 다른 OCI 텔레메트리(telemetry)와 함께 관리하고 싶다면 커스텀 메트릭 인제스션(custom metric ingestion) 경로를 통해 OCI Monitoring으로 전달할 수 있습니다.

실무에서의 교훈

실제로 이를 운영하며 얻은 몇 가지 사항은 다음과 같습니다:

시드 피어(Seed peer) 배치가 중요합니다. Dragonfly 시드 피어를 인터넷 대역폭이 좋은 노드에 배치하십시오. 이상적으로는 NAT 게이트웨이와 동일한 가용성 도메인(availability domain)에 두는 것이 좋습니다. 이렇게 하면 초기 오리진 페치(origin fetch)의 지연 시간(latency)을 줄일 수 있습니다.

스케일링 전 프리워밍(Pre-warm)을 수행하십시오. 새로운 모델 버전이 출시될 것을 알고 있다면, GPU 노드 풀(node pool)을 확장하기 전에 시드 피어에서 dfget을 실행하십시오. 새로운 노드가 온라인 상태가 될 때쯤이면 모델이 이미 P2P 메시(mesh)에 캐싱되어 있어 배포가 사실상 즉각적으로 이루어집니다.

리비전(Revision)을 고정하십시오. 프로덕션 추론(inference) 환경에서는 항상 모델 버전(--hf-revision 또는 --ms-revision)을 고정하십시오. 클러스터의 모든 노드는 정확히 동일한 가중치(weights)를 제공해야 하며, 새벽 2시에 버전 불일치 문제를 디버깅하고 싶지는 않을 것입니다.

Oracle University 교육과의 연관성

Oracle University에서 OCI 교육을 이수하고 있다면, 이 내용의 상당 부분은 여러분이 공부하고 있는 내용과 직접적으로 연결됩니다:

관련된 Oracle University 학습 경로(learning paths)는 OCI Architect Professional, OCI Architect Associate, OCI DevOps Professional, OCI Networking Professional, OCI Observability and Management Professional, OCI AI Foundations Associate, 그리고 OCI Generative AI Professional입니다. Architect 및 Networking 경로는 위에서 언급한 크로스 클라우드 이그레스(cross-cloud egress) 비용 절감 및 프라이빗 액세스 패턴의 기반이 되는 멀티클라우드 네트워킹 (multicloud networking), VCN, 서비스 게이트웨이 (service gateway) 개념을 다룹니다. DevOps 및 Observability 경로는 Dragonfly 실행의 기반이 되는 Kubernetes, Helm 및 모니터링 (monitoring) 패턴을 다룹니다. AI Foundations 및 Generative AI 경로는 이 모든 것의 대상 환경인 GPU 컴퓨트 쉐이프 (GPU compute shapes) 및 AI 워크로드 관리 (AI workload management)를 다룹니다.

OKE에 Dragonfly를 배포하는 것은 이러한 자격증 중 하나를 준비하고 있다면 매우 견고한 실습 과제가 될 것입니다. 왜냐하면 하나의 프로젝트 내에서 네트워킹, Kubernetes, 그리고 AI 인프라를 하나로 묶어주기 때문입니다. Oracle MyLearn에서 전체 카탈로그를 탐색하고 이러한 경로를 검색할 수 있습니다.

직접 시도해 보세요

1. GPU 노드 풀을 포함한 OKE 클러스터를 생성합니다 (테스트용으로는 단일 A10으로도 충분합니다).
2. Helm을 통해 Dragonfly를 설치합니다.
3. dfget hf://deepseek-ai/DeepSeek-R1/config.json -O /tmp/config.json을 실행하고 P2P 로그를 관찰합니다.
4. 두 번째 노드로 스케일 아웃(scale)한 후, 다운로드를 반복하여 캐시 히트 (cache hit)를 확인합니다.

모델 체크포인트와 클러스터 규모는 계속해서 커지고 있습니다. OKE에서 Dragonfly를 실행하면 이러한 변화 속에서도 배포 계층 (distribution layer)이 병목 현상이 되지 않도록 유지할 수 있습니다.

Pavan Madduri는 W.W. Grainger의 시니어 클라우드 플랫폼 엔지니어(Senior Cloud Platform Engineer)이자, CNCF Golden Kubestronaut, Oracle ACE Associate, 그리고 CNCF TAG Workloads Foundation의 테크 리드(Tech Lead)입니다. 그는 CNCF Dragonfly에서 네이티브 Hugging Face 및 ModelScope 프로토콜 지원을 구축했습니다. GitHub에서 그를 찾을 수 있습니다.

이 기사는 원래 Oracle University Community에 게시되었습니다. 더 자세한 내용은 저의 Oracle ACE 프로필을 참조하세요.