관리 메뉴

피터의 개발이야기

[AI Infra] 메모리는 용량이 아니라 채널이다 - Memory-bound 워크로드에서 놓치기 쉬운 서버 성능 포인트 본문

AI/AI실험 | 기록

[AI Infra] 메모리는 용량이 아니라 채널이다 - Memory-bound 워크로드에서 놓치기 쉬운 서버 성능 포인트

기록하는 백앤드개발자 2026. 1. 29. 15:47
반응형

 

 

[AI] Peterica의 AI공부와 비젼 정리

ㅁ 들어가며

 점심시간에 크루들과 서버 메모리 구조에 대한 이야기를 나누다가, 생각보다 중요한 인프라 포인트들이 많다는 걸 다시 느꼈다.

우리는 보통 서버 스펙을 볼 때

  • CPU 코어 수
  • 메모리 용량(GB)

정도만 확인한다.

하지만 Memory-bound 워크로드를 운영하는 입장에서는, 이것보다 더 중요한 요소가 있다.

바로 메모리 채널 구성이다.

 

결론부터 말하면:

  “메모리는 얼마나 많으냐보다, 어떻게 연결되어 있느냐가 더 중요할 수 있다.”

 

 

ㅁ CPU 소켓과 메모리 채널

일반적인 서버 CPU 하나(소켓)는 여러 개의 메모리 채널을 가진다.
최근 서버 기준으로는 보통 6~8채널이다.

 

중요한 포인트는 다음이다.

ㅇ 메모리는 채널 단위로 병렬 접근된다
채널 수 = 실질적인 메모리 대역폭
ㅇ 같은 용량이라도 채널 구성에 따라 성능이 달라진다

 

예를 들어,

  128GB를 8채널에 분산 배치한 서버와

  같은 128GB를 4채널만 사용한 서버는

  이론적으로 메모리 대역폭이 거의 2배 차이 날 수 있다.

 

하지만 우리는 보통 “128GB 서버”라고만 인지한다.
DIMM이 어떻게 꽂혀 있는지는 거의 보지 않는다.

 

ㅁ DIMM 배치와 NUMA 구조에 대한 보충 설명

 DIMM 배치

 DIMM은 그냥 메모리 모듈(RAM 한 장)이다.

  서버 메인보드에는 이런 DIMM을 꽂는 슬롯이 여러 개 있고,

  이 슬롯들은 메모리 채널(channel) 이라는 그룹으로 묶여 있다.

 

예를 들어,

   CPU가 8채널이면 8개의 고속도로가 있고,

   각 채널마다 DIMM 슬롯이 1~2개씩 달려 있다.

 

중요한 포인트는 CPU가 채널 단위로 병렬 접근이 가능하다는 점이다.

 

좋은 DIMM 배치는

  모든 채널에 골고루 DIMM이 있고, 
  CPU가 동시에 여러 채널을 사용 가능해야 한다.

 

ㅇ NUMA = Non-Uniform Memory Access

뜻 그대로 메모리 접근 속도가 균일하지 않은 구조이다.

 

멀티 소켓 서버를 생각해보면 이해가 쉬워진다.

CPU0 ── RAM0
CPU1 ── RAM1

각 CPU는 자기 옆에 붙은 메모리를 가장 빠르게 접근한다.

하지만,

   CPU0이 RAM1을 읽으려면
  → CPU 간 인터커넥트를 타고 넘어가야 합니다.

그래서:

  • Local memory (붙어있는 RAM): 빠름
  • Remote memory (다른 CPU 쪽 RAM): 느림

이 구조를 NUMA라고 한다.

 

비유적으로 표현하면, 

ㅇ DIMM 배치
DIMM은 “메모리로 가는 차선 수”다 — 여러 차선을 쓰면 빠르고, 한 차선만 쓰면 막힌다.

ㅇ NUMA 구조
NUMA는 “CPU가 자기 집 냉장고를 쓰느냐, 옆집 냉장고를 쓰느냐”의 차이다.

 

문제는 VM / 컨테이너 환경이다.

 

ㅁ VM 환경의 구조적 한계

대부분의 개발/운영 환경은 VM 기반이다.

VM에서는 보통 다음만 보인다.

  •  vCPU
  • 메모리 총량

 

반면 실제 물리 서버의

  • 메모리 채널 수
  • DIMM 배치
  • NUMA 구조

같은 정보는 거의 투명해진다.

 

결과적으로,

 - 슬롯이 절반만 채워진 서버
 - 채널 불균형이 있는 서버

 위에서 VM을 띄우고, 우리는 그 위에서 성능 튜닝을 한다.

이미 하드웨어 레벨에서 병목이 생긴 상태일 수 있다.

 

최악의 경우, VM 하나가

  • CPU는 node0
  • 메모리는 node1

이렇게 엇갈려 배치되면,

   CPU → 원격 메모리 → 인터커넥트 → RAM

경로가 된다. 

Memory-bound 서비스에서는 이게 치명적이다.

CPU는 놀고 있고, 메모리 접근만 계속 왕복하게 된다.

 

정리하면:
 ㅇ DIMM 배치
    메모리를 채널에 어떻게 나눠 꽂았는가
    메모리 “대역폭”을 결정
ㅇ NUMA 구조
   CPU와 메모리가 어느 노드에 속해 있는가
   메모리 “지연시간”을 결정

둘 다 애플리케이션에서는 안 보이지만,
성능에는 직접적인 영향을 준다.

 

ㅁ CPU-bound vs Memory-bound

여기서 중요한 구분이 나온다.

CPU-bound workload

  • 연산이 병목
  • 메모리 접근 비중이 낮음
  • 인프라 차원에서 메모리를 타이트하게 잡아 집적도를 높이기도 함

Memory-bound workload

  • 메모리 대역폭이 병목
  • CPU는 놀고 있는데 메모리가 막힘
  • 채널 수와 DIMM 배치가 성능에 직접적인 영향

Memory-bound 서비스에서 채널을 절반만 쓰고 있다면,
  CPU 내부 메모리 컨트롤러 단계에서 이미 병목이 시작된다.

  이건 애플리케이션 최적화로 해결할 수 있는 문제가 아니다.

 

ㅁ 실제 운영에서 확인한 사례

같은 “128GB 서버”인데도,

  어떤 장비는 6채널

  어떤 장비는 4채널

  로 구성된 사례를 직접 확인할 수 있다.

스펙상 동일해 보여도, 실제 메모리 대역폭은 다르다.

 

그래서 인프라 팀에 다음을 명시적으로 요청해야 한다.

 - 메모리 풀 채널 구성
 - DIMM 균등 배치

 

“메모리 많이 주세요”가 아니라 “채널을 다 써 주세요”라는 요구다.
Memory-bound 서비스에서는 이 차이가 꽤 크다.

 

ㅁ DDR4 vs DDR5 이야기

ㅇ DDR5는 단순히 클럭이 올라간 메모리가 아니다.

 - 내부 구조가 더 잘게 분리되고
 - 병렬성이 강화되었으며
 - 채널 활용 방식도 달라졌다

 

앞으로는 “메모리를 얼마나 쓰느냐”보다 “채널을 어떻게 쓰느냐”가 더 중요해진다.

 

ㅁ Memory-bound 서비스 운영 체크리스트

ㅇ Memory-bound 워크로드를 다룬다면 최소한 아래는 확인하는 게 좋다.

 - 물리 서버 메모리 채널 수
 - DIMM 균등 배치 여부
 - NUMA 구조
 - VM이 어느 노드에 올라가 있는지
- 단순 용량이 아닌 실제 메모리 대역폭

 

가능하다면 인프라 요구사항에 다음을 포함시키자.

 - “메모리 용량”이 아니라
 - “메모리 채널 구성”

 

ㅁ 왜 로컬 LLM은 맥북 M 시리즈에서 유독 잘 돌아 가는가

앞에서 DIMM 배치와 NUMA 구조 이야기를 했는데,

  이 관점에서 보면 Apple Silicon(M 시리즈)은 꽤 독특한 구조를 가진다.

 

기존 서버나 PC는 보통 다음과 같은 형태다.

  CPU → 메모리 컨트롤러 → DIMM 슬롯 → RAM

 

이 구조에서는 자연스럽게

  - 채널 불균형
  - DIMM 배치 문제
  - NUMA로 인한 원격 메모리 접근

같은 병목이 생긴다.

즉, 차선도 복잡하고, 냉장고도 멀리 있는 구조다.

 

반면 M 시리즈는Unified Memory Architecture(UMA)를 사용한다.

CPU, GPU, Neural Engine이 모두 하나의 메모리 풀을 직접 공유하는 구조다.

DIMM도 없고, NUMA도 없다.

 

모든 연산 유닛이 동일한 메모리 레이턴시로 접근한다.

 

비유하면,

  집 한가운데 큰 냉장고 하나 두고, 모든 방이 바로 연결된 구조다.

 

그래서 로컬 LLM 환경에서 다음 같은 체감이 나온다.

  - 모델 로딩이 빠르고
  - GPU/CPU 간 복사 오버헤드가 없으며
  - 대용량 컨텍스트에서도 상대적으로 안정적이다.

 

이건 단순히 “CPU가 빠르기 때문”이 아니라,

  메모리 구조 자체가 다르기 때문이다.

 

Memory-bound 관점에서 보면 Apple Silicon은

  DIMM과 NUMA를 구조적으로 제거해 버린 첫 대중적 플랫폼에 가깝다.

그래서 로컬 LLM, 벡터 검색, 멀티모달 파이프라인 같은 작업이 맥북에서 생각보다 부드럽게 돌아간다.

 

ㅁ 마무리

우리는 종종 애플리케이션만 바라본다.

하지만 성능의 시작점은 생각보다 훨씬 아래, 하드웨어에 있다.

특히 Memory-bound 시스템에서는 더더욱 그렇다.

다음번 서버 스펙을 볼 때는,
  RAM 숫자 옆의 GB만 보지 말고 그 뒤에 숨은 채널 구조도 함께 보자.

  작은 차이 같지만, 실제 서비스에서는 꽤 큰 차이가 된다.

 

이것이 오늘 함께 성장하는 크루의 점심식사에서 얻은 인사이트다.

반응형
Comments