Llama-3-70B 파인튜닝 작업을 대형 하이퍼스케일러에서 CoreWeave로 처음 이전했을 때, 가장 즉각적으로 체감된 변화는 단순히 더 저렴한 시간당 요금만이 아니었습니다. 하이퍼바이저 계층이 없어서 에포크(epoch)당 소요 시간이 18%나 단축된 점이었습니다. 일반적인 가상화 환경에서 하이퍼바이저는 베어메탈 성능과 비교하기 전까지는 흔히 간과되곤 하는 "스틸 타임(steal time)" 오버헤드를 발생시킵니다. 멀티 노드 클러스터를 관리하는 개발자에게 이 18%는 단순한 수치가 아닙니다. 주말 사이에 모델 수렴을 완료하느냐, 아니면 월요일 아침까지 예산을 낭비하며 붙들고 있느냐의 차이를 만듭니다.
특화된 AI 클라우드는 이제 틈새 대안을 넘어 대규모 머신러닝을 위한 주요 인프라로 자리 잡았습니다. NVIDIA의 H100 및 H200 GPU가 학습과 추론의 표준이 됨에 따라, 병목 현상은 단순한 연산 능력(TFLOPS)에서 인터커넥트 속도와 오케스트레이션 효율성으로 옮겨갔습니다. 개발자들은 이제 단순히 모델 코드만 작성하는 것이 아니라, 워크로드가 I/O에서 멈추지 않도록 인피니밴드 패브릭(InfiniBand fabrics)과 쿠버네티스 리소스 할당량을 관리해야 합니다. 이러한 변화는 범용 컴퓨팅 인스턴스에서 벗어나 하드웨어 인식형(hardware-aware) 배포로의 전환을 요구합니다.
1. 오케스트레이션: 베어메탈 쿠버네티스와 노드 어피니티
CoreWeave는 거대한 쿠버네티스 네이티브(Kubernetes-native) 클라우드로 운영됩니다. 쿠버네티스가 가상 머신 위의 추상화 계층으로 존재하는 기존 클라우드와 달리, 이곳에서는 컨테이너가 베어메탈에서 직접 실행됩니다. 이를 통해 PCIe 버스와 NVLink 브리지에 직접 접근할 수 있습니다. 이를 올바르게 처리하려면 배포 매니페스트에서 하드웨어 요구 사항을 명시적으로 정의해야 합니다. 필자는 GPU 노드의 물리적 토폴로지를 고려하지 않아 할당이 파편화되고 노드 간 지연 시간이 높아져 프로덕션 단계에서 실패하는 팀들을 보아왔습니다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: llama3-inference
spec:
replicas: 4
template:
spec:
# 포드가 H100 GPU가 있는 노드에만 배치되도록 보장
nodeSelector:
gpu.nvidia.com/model: H100_NVL
containers:
- name: inference-server
image: vllm/vllm-openai:latest
resources:
limits:
# 텐서 병렬 처리를 위해 2개의 GPU 요청
nvidia.com/gpu: 2
memory: "128Gi"
cpu: "16"
requests:
nvidia.com/gpu: 2
memory: "128Gi"
cpu: "16"
# 멀티 노드에 필수: 포드가 동일한 물리적 랙에 배치되도록 보장
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- llama3-inference
topologyKey: "topology.kubernetes.io/zone"
limits 섹션에서 nvidia.com/gpu를 사용하는 것은 필수적이지만, 진정한 최적화는 podAffinity에서 이루어집니다. topologyKey를 특정 존(zone)이나 랙 식별자로 설정함으로써 분산 작업자들이 서로 물리적으로 가깝게 유지되도록 할 수 있습니다. 이는 3200 Gbps 인피니밴드 네트워크를 통해 모델 가중치가 동기화될 때 스위치 패브릭을 거치는 홉(hop) 수를 줄여주므로 매우 중요합니다.
2. 추론 최적화: vLLM을 활용한 고처리량 달성
H100에서 추론을 실행할 때 처리량(throughput)을 극대화하지 못하면 비용 낭비가 심합니다. Hugging Face Transformers를 단순한 Flask 래퍼로 감싸 사용하는 표준 방식은 성능 병목의 원인이 됩니다. 대신, PagedAttention을 지원하는 vLLM과 같은 엔진을 사용하면 KV 캐시 메모리를 더 효율적으로 관리하여 훨씬 더 높은 동시 요청을 처리할 수 있습니다. CoreWeave의 H100 인스턴스에서 표준 Transformers를 vLLM으로 전환했을 때 달러당 초당 토큰 수가 4배 증가하는 것을 확인했습니다.
import vllm
from vllm import SamplingParams
# 80GB VRAM을 갖춘 H100을 위한 설정
# 모델을 두 개의 GPU로 나누기 위해 tensor_parallel_size=2 사용
llm = vllm.LLM(
model="meta-llama/Meta-Llama-3-70B-Instruct",
tensor_parallel_size=2,
gpu_memory_utilization=0.90, # 시스템 오버헤드를 위해 10% 남겨둠
max_model_len=4096,
enforce_eager=True # 정적 그래프 실행을 위한 오버헤드 감소
)
sampling_params = SamplingParams(
temperature=0.7,
top_p=0.95,
max_tokens=512,
presence_penalty=1.1
)
# 여러 프롬프트를 동시에 배치 처리
prompts = [
"양자 얽힘을 세 문장으로 설명해 주세요.",
"웹사이트를 스크래핑하는 파이썬 스크립트를 작성해 주세요.",
"베어메탈 클라우드의 장점을 요약해 주세요."
]
outputs = llm.generate(prompts, sampling_params)
for output in outputs:
print(f"프롬프트: {output.prompt}")
print(f"생성 결과: {output.outputs[0].text}")
한 가지 주의할 점(Gotcha)은 gpu_memory_utilization입니다. 이 값을 0.95 이상으로 설정하고 싶겠지만, 안정성 측면에서는 0.90이 가장 적당하다는 것을 발견했습니다. 값을 너무 높게 잡으면 KV 캐시가 확장되는 피크 타임에 리눅스 OOM 킬러가 프로세스를 강제 종료할 수 있습니다. 하드웨어에 직접 접근하는 CoreWeave 환경에서는 가상화 인스턴스보다 메모리 압박이 더 예측 가능하지만, 여전히 운영체제의 커널 작업을 위한 여유 공간이 필요합니다.
3. 분산 학습: FSDP(Fully Sharded Data Parallelism)
단일 GPU에 담기지 않는 모델을 학습시킬 때는 데이터 병렬 처리(DP), 모델 병렬 처리(MP), 또는 FSDP 중에서 선택해야 합니다. CoreWeave와 같은 고대역폭 환경에서는 모델 파라미터, 그래디언트, 옵티마이저 상태를 가용 GPU 전체에 샤딩하는 FSDP가 대개 최상의 선택입니다. 이를 통해 수동 파이프라인 병렬 처리의 복잡함 없이 훨씬 더 큰 모델을 학습시킬 수 있습니다.
import torch
import torch.nn as nn
from torch.distributed.fsdp import FullyShardedDataParallel as FSDP
from torch.distributed.fsdp.fully_sharded_data_parallel import ShardingStrategy
def setup_fsdp_model(model, device_id):
# 특정 샤딩 전략으로 FSDP 초기화
# SHARD_GRAD_OP는 그래디언트와 옵티마이저 상태를 샤딩함
fsdp_model = FSDP(
model,
device_id=torch.cuda.current_device(),
sharding_strategy=ShardingStrategy.SHARD_GRAD_OP,
mixed_precision=torch.distributed.fsdp.MixedPrecision(
param_dtype=torch.bfloat16, # H100/A100에 최적화됨
reduce_dtype=torch.bfloat16,
buffer_dtype=torch.bfloat16,
),
sync_module_states=True,
limit_all_gathers=True, # 버퍼 크기를 제한하여 OOM 방지
)
return fsdp_model
# 표준 PyTorch 학습 루프는 거의 동일하게 유지되지만,
# 텐서 코어를 활용하기 위해 bfloat16을 사용함
model = MyLargeLanguageModel().to(f"cuda:{device_id}")
fsdp_model = setup_fsdp_model(model, device_id)
optimizer = torch.optim.AdamW(fsdp_model.parameters(), lr=1e-5)
for batch in dataloader:
optimizer.zero_grad()
outputs = fsdp_model(batch['input_ids'])
loss = criterion(outputs, batch['labels'])
loss.backward()
optimizer.step()
limit_all_gathers=True 플래그는 구세주와 같습니다. 이 설정이 없으면 FSDP가 다음 레이어의 샤드를 너무 공격적으로 미리 가져오려(pre-fetch) 하다가 메모리 사용량이 급증하여 노드가 다운될 수 있습니다. 인피니밴드로 연결된 CoreWeave 노드에서는 이러한 샤드를 모으는 지연 시간이 매우 낮기(마이크로초 미만) 때문에, 프리페칭을 제한함으로써 얻는 안정성 이득에 비해 성능 손실은 미미합니다.
4. 서버리스 GPU 스케일링: KServe InferenceService
모든 워크로드에 24시간 내내 전용 클러스터가 필요한 것은 아닙니다. 내부 도구나 비동기 처리를 위해 '스케일 투 제로(scale to zero)'를 활용하면 수천 달러를 절약할 수 있습니다. CoreWeave는 복잡한 쿠버네티스 기저 구조를 InferenceService로 추상화하는 KServe를 지원합니다. 이를 통해 모델을 정의하고, 들어오는 요청량에 따라 오토스케일러가 GPU 프로비저닝을 처리하도록 맡길 수 있습니다.
apiVersion: "serving.k
