[Lobsters 요약] AI At Home Part 2: 멀티 GPU 환경에서의 LLM 성능 최적화
0
설명
2026년 8월 20일, 개인 서버 환경에서 AI 언어 모델의 성능을 극대화하기 위한 두 번째 여정이 시작됩니다.
이전 챕터에서 폐기된 GPU를 활용하여 구축한 홈 서버의 성능을 끌어올리기 위한 구체적인 방법론을 탐구합니다.
본문은 llama.cpp 설정 조정 및 멀티 GPU 병렬 처리 기법에 초점을 맞춥니다.
### 배경 설명
최근 AI 기술의 발전은 대규모 언어 모델(LLM)의 등장과 함께 개인용 하드웨어에서의 활용 가능성을 높이고 있습니다. 'Attention Is All You Need' 논문(2017)에서 제시된 트랜스포머 아키텍처는 LLM의 핵심으로 자리 잡았으며, 이는 '토큰' 단위로 언어를 처리하고 '어텐션 메커니즘'을 통해 문맥을 이해하는 방식으로 작동합니다. 모델의 크기가 커질수록 필요한 연산량과 메모리 대역폭이 기하급수적으로 증가하여, 개인용 하드웨어에서 이를 효율적으로 구동하는 것은 큰 도전 과제입니다. 특히, 310억 개의 파라미터를 가진 Gemma4-31B와 같은 모델은 수십 GB의 VRAM을 요구하며, 이는 단일 GPU로는 감당하기 어려운 수준입니다. 이러한 문제를 해결하기 위해 'Mixture of Experts(MoE)'와 같은 모델 아키텍처가 등장했으며, 이는 전체 파라미터 중 일부만 활성화하여 연산량을 줄이는 방식입니다. 예를 들어, Deepseek V4 Flash 모델은 2840억 개의 파라미터를 가지지만, 각 토큰 생성 시에는 130억 개만 활성화됩니다. 그러나 이러한 MoE 모델은 여전히 모든 파라미터를 빠르게 접근 가능한 메모리에 로드해야 하므로, 고용량 VRAM을 갖춘 다중 GPU 환경이 필수적입니다.
개인 서버에서 LLM을 효과적으로 구동하기 위해서는 단순히 고성능 하드웨어를 갖추는 것을 넘어, 하드웨어의 특성과 모델의 작동 방식을 깊이 이해하고 최적의 병렬 처리 전략을 적용하는 것이 중요합니다. GPU 간의 통신 속도, 메모리 대역폭, 그리고 모델 아키텍처의 특성을 고려한 설정 조정은 성능 향상의 핵심 요소입니다. 본문은 이러한 배경 하에, 저자가 직접 구축한 멀티 GPU 환경에서 다양한 실험을 통해 얻은 실질적인 결과와 인사이트를 공유합니다.
### 섹션 1: 트랜스포머 모델의 작동 원리
모든 AI 텍스트 생성 소프트웨어는 '트랜스포머 모델' 또는 '대규모 언어 모델(LLM)'의 일종입니다. 이 모델의 기본 설계는 2017년 발표된 'Attention Is All You Need' 논문에서 소개되었으며, 이는 지난 20년간 컴퓨터 과학 분야에서 가장 중요한 논문 중 하나로 평가받습니다. LLM은 '토큰'이라는 단어 조각을 처리하며, 각 토큰은 모델의 여러 계층을 순차적으로 거치면서 연산됩니다. '어텐션 메커니즘'은 모델이 입력 전체를 동시에 고려하고 토큰 간의 관계를 파악하는 핵심 요소입니다. 이는 마르코프 체인과 달리 이전 토큰뿐만 아니라 전체 문맥을 기반으로 다음 토큰을 생성할 수 있게 합니다. 모델이 토큰을 생성할 때마다, 기존 문맥과 모델의 모든 가중치를 읽어와 행렬 곱셈을 수행해야 합니다. Gemma4-31B 모델의 경우 310억 개의 가중치를 GPU VRAM에 로드해야 하며, 이는 종종 메모리 대역폭이 병목 현상을 일으키는 주요 원인이 됩니다. 이러한 문제를 완화하기 위해 'Mixture of Experts(MoE)' 모델 아키텍처가 등장했으며, 이는 각 토큰마다 일부 가중치만 활성화하여 필요한 메모리 로딩을 줄입니다. 예를 들어, Deepseek V4 Flash 모델은 2840억 개의 파라미터를 가지지만, 각 토큰 생성 시에는 130억 개만 활성화됩니다. 하지만 모든 파라미터는 여전히 빠른 메모리에 저장되어야 하므로, MoE 모델은 더 많은 VRAM을 요구합니다.
### 섹션 2: 멀티 GPU 병렬 처리 기법
여러 개의 GPU를 사용할 때, 모델을 분산시키는 다양한 병렬 처리 기법이 존재합니다. 본문에서는 개인 서버 환경에 적합한 두 가지 기법에 집중합니다. 첫째, '레이어 병렬(Layer Parallel)'은 모델의 각 계층을 서로 다른 GPU에 할당하는 방식입니다. 토큰 생성 시, GPU 1에서 일부 계층을 처리한 후 중간 결과를 GPU 2로 전달하여 다음 계층을 처리하는 식입니다. 이 방식은 모델 가중치 전체를 VRAM에 로드할 수 있다는 장점이 있지만, 각 계층이 순차적으로 처리되므로 GPU 하나가 전체 모델을 처리하는 것과 유사한 속도를 보입니다. 둘째, '텐서 병렬(Tensor Parallel)'은 각 계층의 행렬 곱셈 연산을 여러 GPU로 분산시키는 방식입니다. 각 GPU는 행렬의 일부를 계산한 후 결과를 동기화하여 최종 결과를 얻습니다. 이론적으로는 메모리 대역폭을 병렬화하여 총 대역폭을 크게 늘릴 수 있지만, 각 계층마다 여러 번의 데이터 이동이 발생하여 GPU 간 통신 오버헤드가 커질 수 있습니다. 이 외에도 여러 사용자를 동시에 처리하는 데 적합한 '데이터 병렬(Data Parallel)'과 '전문가 병렬(Expert Parallel)' 기법이 있지만, 개인 사용 환경에서는 레이어 병렬과 텐서 병렬이 주로 고려됩니다.
### 섹션 3: 실험 및 성능 측정
저자는 4개의 AMD Radeon Pro V620 GPU를 갖춘 서버에서 Gemma4-31B와 Deepseek V4 Flash 모델을 대상으로 다양한 실험을 수행했습니다. 초기 레이어 병렬 설정에서 Deepseek V4 Flash는 초당 9~10 토큰의 속도를 보였습니다. Gemma4-31B 모델을 사용하여 레이어 병렬화에 따른 성능 저하를 측정한 결과, 단일 GPU에서 초당 19~20 토큰을 처리하는 반면, 4개의 GPU를 레이어 병렬로 사용할 경우 12~13 토큰으로 감소했습니다. 이는 GPU 간 동기화 오버헤드 때문이며, 고속 인터커넥트가 없는 환경에서는 레이어 병렬화가 성능에 부정적인 영향을 미칠 수 있음을 시사합니다. 또한, GPU 활용률이 낮고 전력 소비가 예상보다 적다는 점도 관찰되었습니다. 이러한 문제를 해결하기 위해 '추측적 디코딩(speculative decoding)' 기법을 도입했습니다. 이는 더 작은 '드래프트 모델'을 사용하여 여러 토큰을 미리 예측하고, 메인 모델이 이를 검증하는 방식입니다. Gemma4-31B 모델에 MTP(Multi-Token Prediction) 드래프트 모델을 적용하자 단일 GPU에서 초당 40 토큰, 2개 GPU 레이어 병렬에서 20 토큰의 속도를 달성했습니다. Deepseek V4 Flash 모델에는 DSpark 드래프트 모델을 적용하여 4개 GPU에서 초당 13 토큰의 성능을 얻었으나, GPU 간 통신 문제로 인해 성능이 불안정했습니다.
### 섹션 4: PCIe P2P 문제 해결 및 텐서 병렬 최적화
저자는 GPU 간 통신 속도 저하의 원인을 파악하기 위해 ROCm 벤치마크를 실행한 결과, PCIe P2P(Peer-to-Peer) 전송이 제대로 작동하지 않고 CPU를 경유하는 심각한 문제가 있음을 발견했습니다. BIOS 설정을 조정하고 'iommu=pt' 커널 옵션을 적용한 후, PCIe P2P 통신이 정상적으로 작동하게 되었습니다. 이로 인해 Gemma4 모델을 텐서 병렬로 두 개의 GPU에 분산했을 때 초당 20 토큰에서 47 토큰으로, 네 개의 GPU에 분산했을 때는 0.5 토큰에서 37 토큰으로 성능이 크게 향상되었습니다. Qwen3.8-27B 모델에서도 유사한 결과를 얻어, 단일 GPU 대비 2개 GPU 텐서 병렬에서 약 30%의 성능 향상을 확인했습니다. 이러한 최적화를 통해 GPU들이 동시에 활발하게 작동하며 전력 소비도 증가하는 것을 관찰했습니다. 최종적으로 Deepseek V4 Flash 모델은 레이어 병렬과 드래프트 모델을 활용하여 초당 약 22 토큰의 성능을 달성했으며, Gemma 4 31B는 텐서 병렬과 드래프트 모델을 통해 초당 약 45 토큰, Qwen 3.8 27B는 텐서 병렬을 통해 초당 약 35 토큰의 성능을 기록했습니다.
### 가치와 인사이트
본문은 개인용 하드웨어에서 대규모 언어 모델(LLM)의 성능을 최적화하는 데 있어 실질적인 방법론과 깊이 있는 기술적 통찰을 제공합니다. 특히, GPU 간의 통신 병목 현상을 진단하고 해결하는 과정은 많은 사용자에게 유용할 것입니다. 저자는 PCIe P2P 통신 문제 해결을 위해 BIOS 설정 및 커널 옵션 조정을 시도했으며, 이를 통해 텐서 병렬 처리 시 성능을 극적으로 향상시켰습니다. 또한, 추측적 디코딩(speculative decoding) 기법과 드래프트 모델의 효과적인 활용은 토큰 생성 속도를 크게 높이는 데 기여했습니다. Gemma4-31B 모델의 경우 단일 GPU에서 초당 40 토큰, Deepseek V4 Flash 모델은 최적화 후 초당 약 22 토큰의 성능을 달성했습니다. 이러한 실험 결과는 GPU의 수, 모델의 크기, 아키텍처 특성, 그리고 하드웨어 구성에 따라 최적의 병렬 처리 전략이 달라짐을 보여줍니다. 특히, 레이어 병렬과 텐서 병렬의 장단점을 명확히 비교하고, 실제 환경에서의 성능 변화를 구체적인 수치로 제시함으로써 독자들에게 실질적인 가이드라인을 제공합니다. 또한, 'Mixture of Experts(MoE)' 모델의 특성과 이에 따른 메모리 요구사항, 그리고 'spill into system RAM'의 비효율성에 대한 지적은 LLM 운영 시 흔히 발생하는 문제에 대한 현실적인 조언을 담고 있습니다.
### 기술·메타
- llama.cpp
- ROCm
- AMD Radeon Pro V620
- Gemma4-31B
- Deepseek V4 Flash
- Qwen3.8-27B
- PCIe 3.0
- MMIO High Base
- iommu=pt
### 향후 전망
향후 LLM의 발전은 모델 크기 증가와 함께 더욱 복잡한 아키텍처의 등장으로 이어질 것입니다. 본문에서 다룬 멀티 GPU 환경에서의 최적화는 이러한 추세를 따라가기 위한 필수적인 과정이 될 것입니다. 특히, 'Mixture of Experts(MoE)' 모델의 발전과 함께, 각 전문가(expert)를 효율적으로 분산하고 관리하는 기술이 중요해질 것입니다. 또한, LLM 제공업체들은 '데이터 병렬' 및 '전문가 병렬'과 같은 기법을 활용하여 대규모 서비스 환경을 구축하고 있으며, 개인 사용자들도 이러한 기술적 흐름을 이해하고 자신의 환경에 맞게 적용하는 것이 필요합니다. 본문에서 언급된 '추측적 디코딩'과 같은 기법은 더욱 발전하여, 더 빠르고 효율적인 토큰 생성을 가능하게 할 것입니다. 또한, 향후에는 모델의 '프롬프트 처리(prefill)' 단계와 '토큰 생성' 단계를 분리하여 최적화하는 하이브리드 방식이 더욱 중요해질 수 있습니다. 이는 컴퓨팅 바운드인 프롬프트 처리와 메모리 바운드인 토큰 생성을 각각의 최적화된 GPU 구성에서 처리하는 것을 의미하며, 이를 위한 llama.cpp와 같은 라이브러리의 발전이 기대됩니다. 궁극적으로, 개인용 하드웨어에서 LLM을 활용하는 것은 더욱 보편화될 것이며, 이를 위한 하드웨어 및 소프트웨어 최적화 기술은 지속적으로 발전할 것입니다.
📝 원문 및 참고
- Source: Lobsters
- 토론(Lobsters): [lobste.rs](https://lobste.rs/s/qc6pjd/ai_at_home_part_2_multi_gpu_drifting)
- 원문: [링크 열기](https://jdagostino.github.io/ai-pt2-multi-gpu-drifting/index.html)
---
출처: Lobsters · [원문 링크](https://jdagostino.github.io/ai-pt2-multi-gpu-drifting/index.html)
신고 · 불법·유해·아동 안전(CSAE) 관련 콘텐츠
댓글 0
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.