길리랩blog

R 병렬 처리와 CUDA GPU 가속의 워크로드 선택 기준

R parallel 기반 CPU 병렬 처리와 CUDA GPU 가속의 실행 모델, 데이터 배치, 성능 병목 및 운영 기준을 정리한다.

2026-08-14 · 최초 발행 2024-04-29

병목의 위치가 CPU 병렬과 GPU 가속을 가른다

통계·머신러닝 작업은 데이터가 커지고 연산이 복잡해질수록 처리 시간이 한 구간에 몰린다. R에서는 parallel 패키지로 CPU 작업을 여러 프로세스에 나눌 수 있고, NVIDIA CUDA는 대량의 경량 스레드로 데이터 병렬 연산을 수행한다.

두 방법은 대체 관계가 아니다. 독립적인 작업을 많이 실행하는 경우에는 R 병렬 처리가 자연스럽고, 대형 벡터·행렬을 반복적으로 계산하는 경우에는 CUDA가 후보가 된다. 선택 기준은 연산 자체뿐 아니라 직렬화, 프로세스 간 통신, Host와 Device 사이의 전송 비용까지 포함한다.

R 워커를 구성할 때 확인할 지점

R의 병렬 처리는 멀티프로세스 기반이다. Unix에서는 FORK 방식과 mclapply를 쓸 수 있으며, PSOCK은 크로스플랫폼 클러스터 방식이다. Windows에서는 PSOCK 사용을 권장하고, Unix 환경에서는 mclapply로 간단히 적용할 수 있다.

mclapply, parLapply, parSapply, clusterApply 같은 함수군은 태스크 또는 데이터를 분산한다. 워커 사이에 공유 메모리가 없으므로 객체를 직렬화하고 전송하는 비용을 함께 봐야 한다.

병렬 난수는 L'Ecuyer-CMRG와 clusterSetRNGStream으로 재현성을 확보할 수 있다. 작업별 오류는 tryCatch로 다루고, 실행 시간이 고르지 않은 작업에는 parLapplyLB 같은 로드 밸런싱 방식을 적용한다.

작업을 나누는 방식은 워크로드에 따라 달라진다.

  • 시뮬레이션이나 부트스트랩처럼 서로 독립적인 작업은 리스트 또는 인덱스 단위의 태스크 분할에 적합하다. 작업 시간이 불균등하면 LB(Load Balancing)를 적용한다.
  • 큰 벡터와 행렬은 청크로 나누어 워커에 배치한다. 청크 크기는 직렬화 비용, 코어 수, 메모리 압력 사이의 균형 문제다.
  • 변경되지 않는 객체는 워커 초기화 때 clusterExport로 배포하고, 큰 객체는 파일 또는 메모리맵 사용을 고려한다.

CUDA에서는 메모리 이동도 연산의 일부다

CUDA는 grid–block–thread 계층에서 커널을 실행한다. 수학 연산, 행렬 연산, 이미지 처리처럼 같은 연산을 대량 데이터에 반복 적용하는 작업을 병렬화하는 모델이다. 워프는 32-thread 단위로 발행되므로 이 단위에 맞춘 최적화가 필요하다.

메모리는 글로벌, 공유, 레지스터, 상수, 텍스처 계층으로 나뉜다. 공유 메모리를 활용하면 DRAM 대역폭 병목을 완화할 수 있다. 다만 Host↔Device PCIe 전송 오버헤드는 계속 존재하므로, 커널의 연산량/바이트(Compute Intensity)가 클수록 GPU 활용이 유리해진다.

CPU에서는 system.time, microbenchmark, Rprof, profvis로 핫스팟과 직렬화 비용을 확인하고 Amdahl/Gustafson 법칙으로 상한을 추정한다. GPU에서는 Nsight Systems/Compute로 커널 점유율, 메모리 코얼레싱, 점유율(occupancy)을 확인한다. 전송–연산–전송 단계를 스트림으로 겹치면 latency hiding을 노릴 수 있다.

운영 환경에서는 고정 스레드 또는 워커 수, NUMA, 핀드 메모리, 고정 시드를 함께 조정해 결정론을 확보한다.

워크로드에서 처리 경로를 고르는 흐름

⤢✕독립 태스크·가벼운 연산대규모벡터/행렬·고연산/바이트예아니오입력 데이터 준비워크로드 특성 판단CPU 병렬 (R parallel)GPU 가속 (CUDA)작업 분할 (태스크/데이터)워커 초기화·데이터 배치병렬 실행(parLapply/mclapply)결과 수집·집계Host→Device 전송CUDA 커널 실행Device→Host 전송에러/불균등 부하?LB 적용, 재시도, 체크포인트결과 검증·저장

CPU 병렬과 CUDA의 운영상 차이

항목 R parallel (멀티코어/멀티노드) CUDA GPU
성능 독립 작업·중간 크기 데이터에 효율. 직렬화/IPC 비용 영향 큼 높은 연산/바이트 비율에서 대규모 가속. 전송 오버헤드 중요
확장성 코어/노드 수에 선형 근사. Amdahl 상한 존재 스레드 수 대규모 확장. 커널/메모리 최적화 필요
일관성 L’Ecuyer-CMRG로 재현성 확보 용이 부동소수점 비결정성 가능, 결정론 모드·정밀도 관리 필요
안정성 운영 편의 높음, R 생태계 통합 드라이버/툴킷 의존, 하드웨어 제약
운영 편의 설치·배포 용이, 코드 변경 적음 빌드 체인·프로파일링 복잡, 컨테이너 권장

시뮬레이션부터 이미지 처리까지의 적용 범위

몬테카를로와 부트스트랩은 시뮬레이션 횟수 N, 모델, 파라미터를 입력으로 받아 태스크 병렬로 처리할 수 있다. parLapply 또는 mclapply로 실행하고 RNG 스트림을 분리한 뒤 통계량과 신뢰구간을 집계한다.

수천만 행 테이블의 수치 변환처럼 대규모 피처 엔지니어링은 CPU 청크 병렬 또는 GPU 커널 벡터화로 처리한다. 결과는 변환 컬럼으로 만들고 캐시 또는 파일에 저장한다.

대형 행렬 작업은 CPU OpenBLAS/Intel MKL 병렬과 R parallel 태스크화를 조합하거나 CUDA/cuBLAS를 호출할 수 있다. 모델 학습 가속과 배치 추론이 출력 대상이다. 대량 이미지나 시계열에서는 GPU 커널이 컨볼루션과 FFT를 처리하고 CPU가 파이프라인을 제어해 전처리 결과와 특성 맵을 만든다.

PSOCK 클러스터에서 재현성을 유지하는 방법

환경/전제: R ≥ 4.2, cross-platform. Windows/macOS/Unix 모두 PSOCK 사용 가능.

# R 4.2+, parallel 패키지 내장
library(parallel)

# 1) 클러스터 구성
n_workers <- max(1, detectCores() - 1)
cl <- makeCluster(n_workers, type = "PSOCK", timeout = 60)

# 2) 패키지/객체 배포
clusterEvalQ(cl, { library(stats) })
important_const <- 3.14
clusterExport(cl, c("important_const"))

# 3) 재현 가능한 RNG 설정
RNGkind("L'Ecuyer-CMRG")
set.seed(123)
clusterSetRNGStream(cl, 123)

# 4) 태스크 정의
tasks <- as.list(1:1000)
simulate_task <- function(i) {
  # 에러 견고성
  tryCatch({
    n <- 1e5
    x <- rnorm(n)
    mean(x) * important_const + i
  }, error = function(e) NA_real_)
}

# 5) 로드 밸런싱 적용 실행
res <- parLapplyLB(cl, tasks, simulate_task)

# 6) 결과 집계
res_vec <- unlist(res, use.names = FALSE)
summary(res_vec)

stopCluster(cl)

Unix 계열에서는 mclapply를 간단히 적용할 수 있으며 Windows는 지원하지 않는다.

library(parallel)
RNGkind("L'Ecuyer-CMRG"); set.seed(123)
res <- mclapply(1:1000, function(i) mean(rnorm(1e5)) + i,
                mc.cores = max(1, detectCores() - 1))

CUDA 벡터 합을 외부 실행으로 R에 연결하기

환경/전제: CUDA Toolkit ≥ 12.x, NVIDIA GPU(Compute Capability ≥ 7.0), g++.

CUDA C++ (vec_add.cu):

// nvcc -O3 -arch=sm_70 vec_add.cu -o vec_add
#include <cuda_runtime.h>
#include <stdio.h>

__global__ void vec_add(const float* a, const float* b, float* c, int n){
    int i = blockIdx.x * blockDim.x + threadIdx.x;
    if (i < n) c[i] = a[i] + b[i];
}

int main(int argc, char** argv){
    if (argc != 2) { fprintf(stderr, "usage: %s N\n", argv[0]); return 1; }
    int n = atoi(argv[1]);
    size_t bytes = n * sizeof(float);

    float *h_a = (float*)malloc(bytes), *h_b = (float*)malloc(bytes), *h_c = (float*)malloc(bytes);
    for (int i=0;i<n;++i){ h_a[i]=i*0.1f; h_b[i]=i*0.2f; }

    float *d_a,*d_b,*d_c;
    cudaMalloc(&d_a, bytes); cudaMalloc(&d_b, bytes); cudaMalloc(&d_c, bytes);
    cudaMemcpy(d_a, h_a, bytes, cudaMemcpyHostToDevice);
    cudaMemcpy(d_b, h_b, bytes, cudaMemcpyHostToDevice);

    int block = 256;
    int grid = (n + block - 1) / block;
    vec_add<<<grid, block>>>(d_a, d_b, d_c, n);
    cudaError_t err = cudaDeviceSynchronize();
    if (err != cudaSuccess){ fprintf(stderr, "kernel error: %s\n", cudaGetErrorString(err)); return 2; }

    cudaMemcpy(h_c, d_c, bytes, cudaMemcpyDeviceToHost);

    // 검증: 몇 개 출력
    for (int i=0;i<5 && i<n;++i) printf("%.6f\n", h_c[i]);

    cudaFree(d_a); cudaFree(d_b); cudaFree(d_c);
    free(h_a); free(h_b); free(h_c);
    return 0;
}

컴파일과 실행은 다음과 같다.

nvcc -O3 -arch=sm_70 vec_add.cu -o vec_add
./vec_add 10000000

R에서는 시스템 호출로 외부 CUDA 실행 파일을 호출할 수 있다.

# R에서 시스템 호출로 CUDA 실행(간단 통합)
N <- 1e7
cmd <- sprintf("./vec_add %d", as.integer(N))
out <- system(cmd, intern = TRUE)  # 상위 5개 결과 문자열
head_vals <- as.numeric(out)
print(head_vals)

Rcpp와 CUDA를 통합하면 메모리 사본을 최소화하고 함수를 직접 호출할 수 있다. 행렬 연산에는 cuBLAS/cuSOLVER를 사용하고 build toolchain으로 CMake를 권장한다. 전송 경로는 pinned memory, batched kernel, 스트림을 이용해 최적화한다.

가속 상한을 해석하는 기준

Amdahl의 법칙에서 병렬화 가능한 비율을 p, 워커 수를 n이라고 하면 Speedup은 S = 1 / [(1 − p) + p/n]이다.

  • p=0.9, n=16 → S ≈ 1 / (0.1 + 0.05625) ≈ 6.4배
  • p=0.99, n=32 → S ≈ 1 / (0.01 + 0.0309) ≈ 24.4배

GPU 가속 상한은 전송과 연산을 함께 둔 모델로 추정한다. PCIe 4.0 x16 전송은 ~ 25 GB/s, GPU FP32는 10 TFLOPS를 가정한다. Compute intensity는 I = FLOPs/byte이고, 커널 시간은 max(연산시간, 전송시간)에 가깝다. I가 충분히 크면, 예를 들어 I > 40~50 FLOPs/byte이면 전송 은닉이 가능해져 10~100배 가속이 현실화된다.

가속은 대기시간을 줄여 실험과 튜닝 주기를 단축하고, 동일 비용으로 더 많은 실험을 수행하게 한다. 시드, 컨테이너, 프로파일링 체계를 갖추면 재현성과 운영 일관성도 강화된다.

운영에서 남는 트레이드오프

R parallel에서는 PSOCK 기본값, 최소한의 clusterExport, 불변 데이터의 초기 배포, parLapplyLB를 활용한 불균등 부하 완화가 기준이 된다. 대신 직렬화와 IPC 오버헤드, 청크 크기, 메모리 복제 비용을 조정해야 한다.

CUDA에서는 공유 메모리와 코얼레스드 접근, 스트림과 비동기 전송, cuBLAS/cuDNN 같은 라이브러리 활용이 중요하다. 개발 복잡도와 하드웨어 의존성이 커지고, 원자적 합산이나 감소 연산 순서에 따른 비결정성 부동소수점도 관리 대상이다.

컨테이너화는 Docker + nvidia-container-toolkit 조합을 사용하고, 드라이버와 툴킷 버전을 고정한다. CI에서는 커널과 성능 회귀를 검사하며, nvidia-smi, Nsight, Prometheus 모니터링 및 리소스 쿼터 설정을 운영 체계에 포함한다.

독립 태스크와 중간 데이터 규모에는 R parallel을 먼저 적용해 변경 비용을 낮출 수 있다. 대형 행렬, 컨볼루션, 대규모 시뮬레이션 핵심 루프처럼 고연산/바이트 워크로드는 CUDA 후보가 된다. 프로파일링, 병목 식별, CPU 병렬 적용, GPU 후보 선별, PoC, 컨테이너·모니터링·재현성 최적화 순서로 접근한다.

병렬 처리RCUDAGPU 가속성능 프로파일링