NVIDIA GPU와 CUDA가 가속 컴퓨팅을 어떻게 가능하게 했는지, 그리고 오늘날의 AI 인프라(칩, 네트워킹, 소프트웨어)가 현대 기술을 어떻게 구동하는지 알아보세요.

가속 컴퓨팅은 간단한 아이디어입니다. 범용 CPU에게 모든 작업을 시키는 대신, 무겁고 반복적인 부분을 특화된 프로세서(대개 GPU)에 오프로딩해서 훨씬 빠르고 효율적으로 처리하도록 하는 것입니다.
CPU는 다양한 작은 작업을 처리하는 데 탁월합니다—운영체제 실행, 애플리케이션 조정, 의사결정 등. GPU는 많은 유사한 계산을 동시에 수행하도록 설계되었습니다. 워크로드를 수천(또는 수백만)의 병렬 연산으로 쪼갤 수 있다면—예: 큰 행렬 곱셈이나 거대한 데이터 배치에 동일한 수학을 적용하는 경우—GPU는 처리량을 크게 끌어올리는 “가속기” 역할을 합니다.
게임이 GPU를 유명하게 만들었지만, 동일한 병렬 수학은 현대 컴퓨팅 전반에 나타납니다:
이 때문에 가속 컴퓨팅은 소비자용 PC에서 데이터센터로 이동했습니다. 단순히 “더 빠른 칩” 문제가 아니라, 비용·시간·전력 면에서 이전에는 현실적이지 않았던 워크로드를 실현 가능하게 만드는 문제입니다.
사람들이 “NVIDIA의 가속 컴퓨팅 스택”이라고 할 때 보통 함께 작동하는 세 계층을 의미합니다:
이 가이드를 마치면 GPU와 CPU의 차이 모델, 왜 AI가 GPU에 잘 맞는지, CUDA의 역할, 그리고 확장 가능한 실제 AI 시스템을 구축할 때 GPU 외에 무엇이 필요한지에 대한 명확한 정신 모델을 얻을 수 있습니다.
CPU는 소규모의 고도로 훈련된 전문가 팀과 같습니다. 수는 많지 않지만 각자는 의사결정, 빠른 작업 전환, 복잡한 분기 로직 처리에 능합니다.
반면 GPU는 수백·수천 명의 유능한 보조 인력을 가진 것과 같습니다. 각 보조의 개별 역량은 전문가보다 단순할 수 있지만, 함께하면 많은 유사한 작업을 동시에 처리할 수 있습니다.
CPU는 제어와 조정에 뛰어납니다: 운영체제 실행, 파일 관리, 네트워크 요청 처리, 분기가 많은 코드 경로 실행 등. 순차적 로직(1단계, 2단계, 3단계—특히 각 단계가 이전 단계에 의존할 때)에 최적화되어 있습니다.
GPU는 동일한 연산을 많은 데이터 조각에 병렬로 적용해야 할 때 빛을 발합니다. 하나의 코어가 반복적으로 작업하는 대신, 많은 코어가 동시에 작업을 수행합니다.
GPU에 친화적인 일반적 워크로드:
대부분의 실제 시스템에서 GPU는 CPU를 대체하지 않고 보완합니다.
CPU는 애플리케이션을 실행하고 데이터를 준비하며 작업을 조율합니다. GPU는 무거운 병렬 계산을 처리합니다. 훌륭한 "전문가" 조율 없이는 많은 보조들이 놀고 있게 되어 기대한 속도를 내지 못합니다.
GPU는 픽셀과 3D 장면을 그리는 특수 프로세서로 시작했습니다. 1990년대 후반과 2000년대 초반에 NVIDIA 등은 쉐이딩과 기하 처리 속도를 높이기 위해 병렬 유닛을 계속 늘렸습니다. 연구자들은 많은 비그래픽 문제도 많은 데이터 포인트에 동일한 연산을 반복 적용하는 것으로 환원된다는 사실을 발견했습니다—그래픽 파이프라인이 바로 그 용도에 맞게 설계되었기 때문입니다.
간단한 연대기:
그래픽 워크로드는 선형대수에 크게 의존합니다: 벡터, 행렬, 내적, 컨볼루션, 수많은 곱셈-덧셈 연산. 과학 계산도 동일한 빌딩 블록(시뮬레이션, 신호 처리 등)을 사용하며, 현대 기계학습은 특히 밀집 행렬 곱셈과 컨볼루션에 집중합니다.
핵심 적합성은 병렬성입니다: 많은 ML 작업은 큰 배치(픽셀, 토큰, 특성)에 동일한 연산을 적용합니다. GPU는 수천 개의 유사한 스레드를 효율적으로 실행하도록 설계되어 이러한 패턴에서 CPU보다 훨씬 많은 초당 산술 연산을 제공합니다.
NVIDIA의 영향은 단순히 더 빠른 칩이 아니었습니다; GPU를 일상 개발자가 쓸 수 있게 만든 점이 큽니다. CUDA는 GPU 프로그래밍 접근성을 높였고, 선형대수·신경망·데이터 처리용 라이브러리의 증가로 직접 커널을 작성할 필요가 줄었습니다.
더 많은 팀이 GPU 가속 제품을 출시하자 생태계는 강화되었습니다: 튜토리얼, 툴링, 경험 있는 엔지니어, 프레임워크 지원이 늘어나 다음 팀이 GPU를 채택하기 쉬워졌습니다.
강력한 GPU는 개발자가 신뢰성 있게 무엇을 할지 지시할 수 있어야만 유용합니다. CUDA(Compute Unified Device Architecture)는 NVIDIA의 프로그래밍 플랫폼으로, GPU를 단순한 그래픽 부속물이 아니라 실제 연산 대상으로 느껴지게 합니다.
CUDA는 두 가지 큰 역할을 동시에 합니다:
이 계층이 없으면 각 팀이 저수준 GPU 프로그래밍, 성능 튜닝, 메모리 관리를 매 세대 칩마다 다시 발명해야 합니다.
CUDA에서 커널은 여러 번 동시에 실행되도록 쓴 함수입니다. CPU처럼 한 번 호출하는 대신 수천(혹은 수백만) 개의 가벼운 스레드에 걸쳐 실행합니다. 각 스레드는 전체 작업의 작은 조각(픽셀 하나, 행렬의 한 행, 신경망 계산의 한 청크 등)을 처리합니다.
핵심 아이디어: 문제를 많은 유사한 독립 작업으로 쪼갤 수 있다면, CUDA는 GPU의 여러 코어에 그 작업들을 효율적으로 스케줄링할 수 있습니다.
대부분 사람은 AI 작업에서 원시 CUDA를 직접 쓰지 않습니다. CUDA는 보통 그들이 이미 사용하는 도구 아래에 있습니다:
그래서 “CUDA 지원”은 AI 인프라 계획에서 자주 체크박스가 됩니다: 어떤 최적화된 빌딩 블록을 스택에서 쓸 수 있는지를 결정합니다.
CUDA는 NVIDIA GPU에 밀접하게 결합되어 있습니다. 이런 긴밀한 통합이 빠르고 성숙한 이유이지만, 동일한 코드를 비-NVIDIA 하드웨어로 옮기려면 변경, 대체 백엔드, 또는 다른 프레임워크가 필요할 수 있습니다.
AI 모델은 복잡해 보이지만, 무거운 작업의 대부분은 거대한 규모에서 동일한 수학을 반복하는 것입니다.
텐서는 단지 숫자의 다차원 배열입니다: 벡터(1D), 행렬(2D), 혹은 더 높은 차원(3D/4D+). 신경망에서 텐서는 입력, 가중치, 중간 활성값, 출력을 나타냅니다.
핵심 연산은 이러한 텐서의 곱셈과 덧셈—특히 행렬 곱셈(및 관련된 컨볼루션)입니다. 학습과 추론은 이 패턴을 수백만~수조 번 실행합니다. 그래서 AI 성능은 종종 얼마나 빠르게 밀집 곱셈-덧셈 작업을 수행할 수 있는지로 측정됩니다.
GPU는 많은 유사한 계산을 병렬로 실행하도록 만들어졌습니다. 소수의 매우 빠른 코어 대신 많은 작은 코어가 그리드 같은 연산을 한꺼번에 처리합니다—텐서 워크로드 내부의 반복적인 수학에 완벽합니다.
현대 GPU는 또한 이 용도에 맞춘 특수 유닛을 포함해, 텐서 중심 연산을 일반 목적 코어보다 더 효율적으로 처리해 와트당 처리량을 높입니다.
학습은 보통 전체 연산량과 메모리 내에서 큰 텐서를 여러 번 이동하는 것이 병목입니다.
추론은 지연 시간 목표, 처리량, 그리고 GPU를 사이클 낭비 없이 계속 채워둘 수 있는 데이터 공급 속도가 병목인 경우가 많습니다.
AI 팀이 신경 쓰는 항목:
현대의 “GPU 서버”(종종 GPU 박스라고 부름)는 외관상 일반 서버와 비슷하지만, 내부는 하나 이상의 고성능 가속 카드에 데이터를 최대한 효율적으로 공급하도록 설계되어 있습니다.
각 GPU는 자체 고속 메모리인 VRAM을 가집니다. 많은 AI 작업은 GPU가 “너무 느리다”가 아니라 모델, 활성값, 배치 크기가 VRAM에 맞지 않아 실패합니다.
그래서 사람들이 "80GB GPU"나 "얼마나 많은 토큰이 들어가는가" 같은 이야기를 합니다. VRAM이 부족하면 배치 축소, 저정밀도 사용, 모델 샤딩, 또는 더 큰 VRAM GPU 추가 같은 선택을 해야 합니다.
서로 다른 GPU를 같은 박스에 넣는 것은 도움이 되지만 확장은 통신 필요성에 따라 달라집니다. 일부 워크로드는 거의 선형으로 확장되지만, 동기화 오버헤드, VRAM 중복, 데이터 로딩 병목 때문에 한계에 부딪힐 수 있습니다.
고급 GPU는 개당 수백 와트를 소모할 수 있습니다. 8- GPU 서버는 보통의 랙 서버보다 히터처럼 동작합니다. 따라서:
GPU 박스는 단순히 "GPU가 달린 서버"가 아니라 가속기를 최대 속도로 유지하기 위해 공급, 냉각, 통신을 설계한 시스템입니다.
GPU는 주변 시스템만큼 빠를 수 있습니다. "하나의 강력한 서버"에서 "여러 GPU가 함께 일하는 시스템"으로 가면, 제한 요인은 종종 원시 연산에서 데이터 이동 속도, 결과 공유, 모든 GPU를 바쁘게 유지하는 능력으로 바뀝니다.
단일 GPU 작업은 대부분 로컬 스토리지에서 데이터를 끌어와 실행합니다. 다중 GPU 학습(및 많은 추론 설정)은 지속적으로 데이터를 교환합니다: 그래디언트, 활성값, 모델 파라미터, 중간 결과 등. 이 교환이 느리면 GPU가 기다리고 유휴 시간이 발생합니다. 유휴 GPU 시간은 가장 비용 높은 시간입니다.
네트워크 병목의 두 가지 흔한 증상:
서버 내부에서 GPU들은 아주 빠르고 낮은 지연의 연결로 연결되어 우회 경로 없이 협업할 수 있습니다. 서버 간에는 고대역폭 네트워크 패브릭을 사용해 무거운 부하 하에서도 예측 가능한 성능을 유지합니다.
개념적으로 두 계층으로 생각하세요:
그래서 단순히 "GPU 수"만 묻는 것으로는 충분하지 않습니다—그 GPU들이 어떻게 통신하는지도 물어야 합니다.
GPU는 "파일"로 학습하지 않고 배치 스트림으로 학습합니다. 데이터 로딩이 느리면 연산이 중단됩니다. 효율적인 파이프라인은 보통:
잘 구축된 파이프라인은 같은 GPU로도 체감 성능을 크게 끌어올릴 수 있습니다.
실제 환경에서는 여러 팀이 같은 클러스터를 공유합니다. 스케줄링은 어떤 작업에 GPU를 언제 얼마나 할당할지 결정합니다. 좋은 스케줄링은 "GPU 기근"(작업이 기다리는 상황)과 "GPU 낭비"(할당되었지만 유휴)를 줄입니다. 우선순위 큐, 선점, 리소스 맞춤(권장 크기) 같은 정책은 예산으로서 GPU 시간이 중요한 환경에서 필수적입니다.
하드웨어만으로는 이야기의 절반일 뿐입니다. NVIDIA의 실제 장점은 GPU를 빠른 칩에서 팀이 구축·배포·유지할 수 있는 사용 가능한 플랫폼으로 바꾸는 소프트웨어 스택입니다.
대부분 팀은 원시 GPU 코드를 직접 쓰지 않습니다. 대신 행렬 연산, 컨볼루션, 비디오 처리, 데이터 이동 같은 공통의 비용이 큰 연산을 처리하는 최적화된 라이브러리와 SDK를 조립합니다. 이는 저수준 커널을 다시 작성하지 않고 제품 로직에 집중할 수 있게 하는 미리 만든 레고 조각과 같습니다.
인기 있는 ML 프레임워크는 NVIDIA 스택과 통합되어 모델을 GPU에서 실행하면 프레임워크가 핵심 연산을 밑단의 최적화 라이브러리로 라우팅합니다. 사용자 관점에서는 단순히 장치를 전환하는 것(“GPU 사용”)처럼 보이지만, 그 뒤에는 프레임워크, CUDA 런타임, 성능 라이브러리의 연쇄작용이 있습니다.
최소한 관리해야 할 항목:
여기서 많은 프로젝트가 실수합니다. 드라이버, CUDA 버전, 프레임워크 릴리스는 호환성 제약이 있고 불일치는 속도 저하에서 배포 실패까지 초래할 수 있습니다. 많은 팀이 "검증된(known-good) 조합"을 표준으로 정하고 컨테이너에서 버전을 고정하며 단계적 롤아웃(개발 → 스테이징 → 프로덕션)을 사용합니다. GPU 소프트웨어 스택을 일회성 설치가 아닌 제품 종속성으로 취급하세요.
모델을 단일 GPU에서 실행하게 되면 다음 질문은 어떻게 더 빠르게 만들지(혹은 더 큰 모델을 수용할지)입니다. 두 가지 주요 경로가 있습니다: 스케일 업(한 머신에 더 많거나 더 좋은 GPU)과 스케일 아웃(여러 머신이 함께 작업).
한 개 GPU에서는 모든 것이 로컬입니다: 모델, 데이터, GPU 메모리. 다중 GPU에서는 디바이스 간 작업을 조정하기 시작합니다.
스케일 업은 보통 2–8 GPU가 들어가는 서버로 이동하는 것을 의미합니다. 같은 호스트 CPU와 스토리지를 공유하므로 큰 업그레이드가 될 수 있습니다.
스케일 아웃은 더 많은 서버를 추가하고 빠른 네트워킹으로 연결하는 것입니다. 이로써 수십~수천 GPU 규모의 학습이 가능하지만 조정 문제가 주요 관심사가 됩니다.
데이터 병렬: 각 GPU가 모델 전체의 복사본을 가지고 서로 다른 데이터 슬라이스로 학습합니다. 각 스텝 후에 GPU들은 그래디언트를 교환해 가중치를 동기화합니다. 시작하기 쉬워서 가장 일반적입니다.
모델 병렬: 모델 자체를 GPU들 사이에 분할합니다(모델이 너무 크거나 하나에 두기엔 느릴 때). 이 경우 순전파와 역전파 중에도 GPU 간 통신이 필요합니다. 더 큰 모델을 가능하게 하지만 통신 비용이 늘어납니다.
많은 실제 시스템은 서버 내부에서는 모델 병렬을, 서버 간에는 데이터 병렬을 병합해 사용합니다.
GPU가 늘어나면 "대화하는 시간"이 늘어납니다. 워크로드가 작거나 네트워크가 느리면 GPU가 업데이트를 기다리느라 유휴 상태가 됩니다. 다음 상황에서 수익 체감이 나타납니다:
다중 GPU나 클러스터가 필요할 수 있는 경우:
이 시점에서 스택은 GPU뿐 아니라 빠른 인터커넥트, 네트워킹, 스케줄링을 포함하도록 이동합니다—확장은 원시 연산만이 아니라 조정의 문제이기도 합니다.
가속 컴퓨팅은 연구소 전용의 뒷단 기술이 아닙니다. 많은 일상 제품이 즉각적이고 유창하며 점점 더 지능적인 이유 중 하나가 특정 워크로드가 병렬로 수천 개의 작은 연산을 동시에 실행할 때 극적으로 빨라지기 때문입니다.
대부분 사람들은 서빙 측면을 눈치챕니다: 채팅 어시스턴트, 이미지 생성기, 실시간 번역, 앱 내의 ‘스마트’ 기능들. 내부적으로 GPU는 두 단계를 지원합니다:
프로덕션에서는 응답 속도 향상, 서버당 처리량 증가, 주어진 데이터센터 예산으로 더 크고 능력 있는 모델을 운영할 수 있는 능력으로 나타납니다.
스트리밍 플랫폼과 비디오 앱은 인코딩, 디코딩, 업스케일링, 배경 제거, 이펙트 같은 작업에 가속을 사용합니다. 크리에이티브 툴은 타임라인 재생, 색보정, 3D 렌더링, AI 기반 기능(노이즈 제거, 생성 채우기, 스타일 전이)에 이점을 얻습니다. 실용적 결과는 대기 시간 감소와 편집 중 실시간 피드백 증가입니다.
가속 컴퓨팅은 거대한 격자나 많은 입자에 걸쳐 동일한 수학을 반복하는 시뮬레이션에서 널리 사용됩니다: 기후 모델, 전산 유체 역학, 분자 역학, 설계 검증 등. 시뮬레이션 주기가 짧아지면 R&D 속도 증가, 더 많은 설계 반복, 더 높은 품질 결과로 이어질 수 있습니다.
추천, 검색 랭킹, 광고 최적화, 사기 탐지 등은 대량의 이벤트 스트림을 빠르게 처리해야 합니다. GPU는 일부 특성 처리와 모델 실행을 가속해 사용자가 페이지에 머무르는 동안 결정을 내릴 수 있게 합니다.
모든 것이 GPU에 어울리는 것은 아닙니다. 워크로드가 작거나 분기가 많거나 순차 로직이 지배적이면 CPU가 더 단순하고 저렴할 수 있습니다. 가속 컴퓨팅은 많은 유사한 수학을 한꺼번에 실행할 수 있거나 지연·처리량이 제품 경험을 직접 좌우할 때 빛을 발합니다.
실용적 제품 메모: 점점 더 많은 팀이 AI 기능을 구축하면서 병목은 "CUDA를 쓸 수 있나"가 아니라 "앱을 안전하게 배포하고 반복할 수 있나"가 되는 경우가 많습니다. 예를 들어 Koder.ai 같은 플랫폼은 채팅 기반 워크플로로 웹/백엔드/모바일 앱을 프로토타이핑하고 배포한 뒤, 가속된 추론 서비스를 뒤에서 통합해 가속이 필요할 때 전체 전달 파이프라인을 재구성하지 않고도 활용할 수 있게 해줍니다.
AI용으로 "GPU를 산다"는 것은 사실 작은 플랫폼을 사는 것입니다: 컴퓨트, 메모리, 네트워킹, 스토리지, 전력, 냉각, 소프트웨어 지원까지 포함됩니다. 미리 구조를 갖추면 모델이 커지거나 사용량이 늘어날 때 고통을 줄일 수 있습니다.
향후 12–18개월 동안 주로 무엇을 실행할지(학습, 파인튜닝, 추론)와 모델 크기를 고려하세요.
강력한 GPU도 잘못 매칭된 박스에서는 성능을 내지 못합니다. 숨겨진 비용:
혼합 전략이 흔합니다: 기본 용량은 온프레미스에 두고 최대 학습은 클라우드로 버스트.
공급사(또는 내부 플랫폼 팀)에게 물어보세요:
이 답변들을 제품의 일부로 취급하세요: 제원상 최고 GPU라도 전력·냉각·데이터 공급을 감당하지 못하면 최적의 플랫폼이 아닙니다.
가속 컴퓨팅은 분명 이점이 크지만 "공짜 성능"은 아닙니다. GPU, 소프트웨어, 운영에 관한 선택은 장기간 제약을 만들 수 있으며, 특히 팀이 어떤 스택을 표준으로 삼으면 바꾸기 어려운 상황이 됩니다.
CUDA와 NVIDIA 라이브러리 생태계는 팀을 빠르게 생산성 있게 만들지만, 같은 편의성이 이식성을 떨어뜨릴 수 있습니다. CUDA 특정 커널이나 메모리 관리 패턴, 독점 라이브러리에 의존하는 코드는 다른 가속기로 옮기려면 상당한 재작업이 필요할 수 있습니다.
실용적 접근법은 "비즈니스 로직"과 "가속기 로직"을 분리하는 것입니다: 모델 코드, 데이터 전처리, 오케스트레이션은 가능한 한 이식 가능하게 유지하고, 커스텀 GPU 커널은 깔끔한 인터페이스 뒤에 숨기세요. 이식성이 중요하다면(비록 느려도) 대체 경로에서 핵심 워크로드를 조기에 검증해 실제 전환 비용을 파악하세요.
GPU 공급은 변동적일 수 있고 가격은 수요에 따라 움직입니다. 총비용은 하드웨어를 넘어 전력, 냉각, 랙 공간, 인력 시간이 지배적일 수 있습니다.
에너지는 1등급 제약입니다. 더 빠른 학습이 좋지만 전력 소모가 두 배가 되고 결과 시간이 개선되지 않으면 비용이 더 비쌀 수 있습니다. 단순한 "GPU 시간" 대신 학습당 비용, 토큰당 전력, 이용률 같은 지표를 추적하세요.
여러 팀이 GPU를 공유할 때 기본 위생이 중요합니다: 강력한 테넌시 경계, 감 audited 접근, 최신 드라이버 패치, 모델 가중치 및 데이터셋의 신중한 취급. 플랫폼이 지원하는 격리 수단(컨테이너/VM, 작업별 자격증명, 네트워크 분리)을 우선 사용하고 GPU 노드를 고가치 자산으로 취급하세요.
세 분야에서 진전이 예상됩니다: 더 나은 효율성(성능/와트), GPU와 노드 간 더 빠른 네트워킹, 운영 마찰을 줄이는 더 성숙한 소프트웨어 계층(프로파일링, 스케줄링, 재현성, 안전한 멀티테넌시).
가속 컴퓨팅을 도입한다면 대표적인 워크로드 한두 개로 시작해 엔드투엔드 비용과 지연 시간을 측정하고 이식성 가정을 문서화하세요. 그런 다음 작은 "골든 패스"(표준 이미지, 드라이버, 모니터링, 접근 제어)를 만들고 팀 확장 전에 표준을 수립하세요.
관련 기획은 /blog/choosing-gpus-and-platforms 와 /blog/scaling-up-and-scaling-out 을 참조하세요.
가속 컴퓨팅은 "무거운 반복 연산"을 범용 CPU 대신 특화된 프로세서(대개 GPU)에 실행하도록 옮기는 것을 의미합니다.
실전에서는 CPU가 애플리케이션과 데이터 흐름을 조율하고, GPU는 행렬 곱셈 같은 많은 수의 유사한 연산을 병렬로 실행합니다.
CPU는 제어 흐름(많은 분기, 작업 전환, 운영체제 실행)에 최적화되어 있습니다.
GPU는 처리량(동일한 연산을 대규모 데이터에 한꺼번에 적용)에 최적화되어 있습니다. AI, 비디오, 시뮬레이션 같은 작업은 데이터 병렬 패턴에 잘 맞아 GPU가 해당 부분에서 훨씬 빠릅니다.
대부분의 실제 시스템은 둘을 함께 씁니다.
CPU, 스토리지, 네트워킹이 따라오지 못하면 GPU가 유휴 상태가 되어 기대한 가속을 얻을 수 없습니다.
사람들이 보통 의미하는 것은 세 가지 계층이 함께 작동한다는 것입니다:
CUDA는 개발자가 NVIDIA GPU에서 범용 연산을 실행할 수 있게 하는 소프트웨어 플랫폼입니다.
프로그래밍 모델(커널/스레드), 컴파일러 툴체인, 런타임, 드라이버를 포함하고 있으며, 흔히 원시 CUDA 코드를 직접 쓰지 않아도 되는 풍부한 라이브러리 생태계를 제공합니다.
커널은 많은 횟수로 병렬 실행되도록 작성한 함수입니다.
CPU에서 함수를 한 번 호출하는 대신, 수천~수백만 개의 가벼운 스레드로 커널을 실행합니다. 각 스레드는 한 조각의 작업(하나의 요소, 픽셀, 행 등)을 처리하며 GPU는 이를 많은 코어에 분배해 처리량을 극대화합니다.
비싼 연산의 대부분이 텐서(다차원 배열) 연산, 특히 행렬 곱셈과 컨볼루션으로 환원되기 때문입니다.
GPU는 이러한 유사한 산술 연산을 대규모로 병렬 실행하도록 설계되었고, 최신 GPU는 텐서 연산을 더 효율적으로 처리하는 특수 유닛을 포함해 와트당 처리량을 높입니다.
**학습(Training)**은 모델 가중치를 최적화하는 과정으로, 전체 연산량과 메모리 내에서 큰 텐서를 여러 번 이동하는 것이 병목인 경우가 많습니다.
**추론(Inference)**은 예측을 제공하는 단계로, 지연 시간 목표, 처리량, 데이터를 빠르게 공급해 GPU를 지속적으로 바쁘게 유지하는 것이 더 큰 제약이 될 수 있습니다. 배칭, 양자화, 파이프라인 최적화는 두 경우에 따라 달라집니다.
VRAM은 GPU에 한 번에 로드될 수 있는 것을 제한합니다: 모델 가중치, 활성값, 배치 데이터 등입니다.
VRAM이 부족하면 보통 다음 중 하나를 해야 합니다:
많은 프로젝트가 ‘원시 연산 성능’보다 메모리 한계에 먼저 부딪힙니다.
GPU를 고를 때는 피크 성능 수치뿐 아니라 전체 플랫폼을 고려해야 합니다:
포괄적인 검토가 없으면 좋은 GPU도 제대로 활용되지 못합니다.