ITMAYA

네트워크 대역폭 테스트 - iperf 오픈소스로 하는 간편한 서버 간 네트워크 대역폭 테스트 네트워크 대역폭 테스트 - iperf iperf란? iperf는 오픈소스로 제공하고 있는 서버-서버 간, 또는 서버-클라이언트 간의 네트워크 대역폭을 테스트할 수 있는 편리한 도구입니다.윈도우, 리눅스, 안드로이드, IOS, MacOS 등 다양한 환경에서 사용할 수 있습니다. 대역폭 테스트 진행 테스트를 위해 2개의 서버를 준비했습니다. 테스트는 ubuntu 20.04 OS로 진행했습니다. 한대의 서버는“iperf 서버”로, 다른 한대의 서버는 “iperf 클라이언트”로 구성합니다. 두 서버에 공통으로 iperf를 설치합니다. iperf는 통신에 5201 포트를 사용합니다. 5201 포트의 통신에 문제가 없도록 방화벽을 구성합니다. $ sudo apt install iperf3$ sudo ufw allow 5201 iperf 서버를 실행합니다. (server1)$ iperf3 -s iperf 클라이언트에서 테스트를 실행합니다. (server2)$ iperf -c (server1 IP) -f G iperf는 기본 구성으로 2MB 단위로 파일을 총 10번 전송하여 테스트 결과를 출력합니다. 출력 값 표시를 알아보기 쉽게 하기 위해 -f G 옵션을 넣었습니다. G 옵션은 Gbyte입니다. 기타 자세한 내용은 아래 옵션 내용에서 확인 가능합니다. iperf 주요 옵션 -f : -f 다음 k m g K M G 등의 알파벳으로 결과값 출력을 달리할 수 있습니다. kbit/s mbit/s gbit/s Kbyte/s Mbyte/s Gbyte/s -w : -w 다음 소켓 버퍼 크기를 입력하여 버퍼크기를 조정할 수 있습니다. -s : 서버 모드로 실행합니다. -c : 클라이언트 모드로 실행합니다. -u : UDP로 테스트합니다. -d : 양방향 테스트를 동시에 수행합니다. 2022.12.12

손쉬운 GPU 클러스터 자동 배포화 도구 Nvidia DeepOps 손쉬운 GPU 클러스터 자동 배포화 도구 Nvidia DeepOps 점점 숫자가 늘어나는 GPU 서버 관리 어떻게 하시나요? - 오픈소스 편 DeepOps DeepOps는 Nvidia에서 제공하는 GPU 클러스터 배포 자동화 도구입니다. Ansible을 이용하여 클러스터를 구성하고, Nvidia에서 제공하는 예제를 통해 구동테스트를 할 수 있습니다. DeepOps에서 제공하는 클러스터는 두 가지입니다. 둘 중 하나를 선택하여 구성할 수 있습니다. Slurm : 병렬 연산 잡 스케쥴러 Kubernetes : 컨테이너 오케스트레이션 도구 Slurm? Kubernetes? 어떤 클러스터를 사용해야 하나요? Architecture ｜ MULTINODE AI AS A SERVICE STACK WITH KUBERNETES & SLURM 두 클러스터는 “클러스터”라는 이름은 공유하지만, 다른 색을 띠고 있는 서비스입니다. 저는 클러스터 제안 시 아래 기준으로 제안합니다. Slurm은여러 서버의 리소스를 합쳐서 사용하는데 적합합니다. Kubernetes는여러 서버의 리소스를 나누어 사용하는데 적합합니다. 저는 두 클러스터를 위 기준으로 정리했지만, 상황에 따라 더 적합한 클러스터는 달라질 수 있습니다. Slurm은 병렬 연산을 위해 사용할 수 있습니다. 1. 사용자가 일을 전달합니다. 2. 리소스를 확보합니다. 3. 일을 각 서버에 분배합니다. 4. 일을 완료합니다. 5. 다음 예정된 일을 시작합니다. Kubernetes를 활용하면 보다 많은 작업을 할 수 있습니다. 1. 컨테이너 배포를 자동화합니다. 2. 컨테이너 상태를 관리합니다. 물론, 컨테이너를 용도에 맞게 구성하여 Slurm과 같이 병렬 작업을 실행할 수 도 있으리라 생각됩니다. 하지만 많은 노력이 필요하겠네요. kubernetes는 보통 MLOps에서 프로젝트나 사용자 별로 리소스를 배정하거나, 배치 잡을 실행하는데 사용됩니다. DeepOps에 포함된 패키지 DeepOps에는 클러스터 패키지 외에도 관리를 위한 패키지도 다수 포함되어 있습니다. 대표적으로 DCGM을 활용하여 Grafana로 출력이 가능합니다. 배포 자동화를 위한 패키지도 포함되어 있습니다. 이런 패키지들을 통해 매우 쉽게 서버를 관리할 수 있고, 매우 쉽게 클러스터를 배포할 수 있습니다. 배포 전 구성 (공통) 테스트 환경 VM1 : hostname:chun1 / 192.168.1.34 (4core / 16gb / 100GB Disk) - Ubuntu 20.04 → bootstrap VM2 : hostname:chun2 / 192.168.1.35 (4core / 16gb / 100GB Disk) - Ubuntu 20.04 → master VM3 : hostname:chun3 / 192.168.1.36 (4core / 16gb / 100GB Disk) - Ubuntu 20.04 → worker1 VM4 : hostname:chun4 / 192.168.1.37 (4core / 16gb / 100GB Disk) - Ubuntu 20.04 → worker2 - bootstrap 서버를 따로 사용하지 않고, master에 구성하거나, 클라이언트에 VM으로 구성해도 상관없습니다. bootstrap 서버는 초기 구성시에만 사용하고, 클러스터 구동에 영향을 주지 않습니다. 하지만 추가 패키지 업데이트 등을 진행하려면 bootstrap 이 계속 필요합니다. - 테스트 환경은 GPU 없이 테스트하였습니다. CPU잡 구동은 문제없이 진행됩니다. 사용자 생성 및 sudoers에 계정 추가 및 apt 업데이트 (node chun1, chun2, chun3, chun4) $ sudo vi /etc/sudoers (추가) chun ALL=(ALL) NOPASSWD:ALL (수정) %sudo ALL=(ALL:ALL) NOPASSWD:ALL $ sudo apt update 노드 간 SSH RSA Key 교환 (node chun1) - chun 계정으로 실행 $ ssh-Keygen (enter-enter-enter) $ ssh-copy-id -i .ssh/id_rsa.pub chun@192.168.1.35 $ ssh-copy-id -i .ssh/id_rsa.pub chun@192.168.1.36 $ ssh-copy-id -i .ssh/id_rsa.pub chun@192.168.1.37 bootstrap 구성 패키지 설치 (node chun1) - chun 계정으로 실행 $ sudo apt -y install git $ git clone https://github.com/NVIDIA/deepops.git $ cd deepops $ ./scripts/setup.sh Slurm 구성 ansible 구성 (node chun1) $ vi config/inventory [all] login01 ansible_host=192.168.1.35 gpu01 ansible_host=192.168.1.36 gpu02 ansible_host=192.168.1.37 [slurm-master] login01 [slurm-nfs] login01 [slurm-node] gpu01 gpu02 [slurm-cache:children] slurm-master [slurm-nfs-client:children] slurm-node [slurm-metric:children] slurm-master [slurm-login:children] slurm-master [slurm-cluster:children] slurm-master slurm-node slurm-cache slurm-nfs slurm-metric slurm-login 구성 설치 $ ansible-playbook -l slurm-cluster playbooks/slurm-cluster.yml Kubernetes 구성 ansible 구성 (node chun1) $ vi config/inventory [all] mgmt01 ansible_host=192.168.1.35 gpu01 ansible_host=192.168.1.36 gpu02 ansible_host=192.168.1.37 [kube-master] mgmt01 [etcd] mgmt01 [kube-node] gpu01 gpu02 [k8s-cluster:childred] kube-master kube-node 구성 설치 $ ansible-playbook -l k8s-cluster playbooks/k8s-cluster.yml 마치며 너무 간단하게 slurm 클러스터와 kubernetes 구성을 해보았습니다. deepops에서 제공하는 설치 패키지는 온프레미스 환경에서 클러스터 구성시 매우 유용하게 사용될 수 있습니다. 클러스터 구성후, 사용 환경에 맞춰 몇 가지 커스텀 후에 바로 사용할 수 있는 매우 좋은 배포 도구입니다. 2022.12.08

개발 환경에서 Linux를 많이 사용하는 이유 개발 환경에서 Linux를 많이 사용하는 이유 개발 환경으로 Linux에 주로 사용하는 CentOS와 Ubuntu의 환경 차이점 Linux에 대해 리눅스는 리누스 토르발스가 커뮤니티 주체로 개발한 컴퓨터 운영체제입니다. 리눅스는 유닉스 운영체제를 기반으로 만들어진 운영체제이고, 유닉스와 같은 다중 사용자, 다중 작업(멀티태스킹), 다중 스레드를 지원하는 네트워크 운영체제(NOS)입니다. 리눅스는 서버로 작동하는데 최적화되어 있어, 서버에서 사용되는 운영체제로 많이 사용되고 있습니다. Linux의 특징 리눅스는 유닉스와 완벽하게 호환이 가능합니다. 공개 운영체제로 오픈소 스이므로 아무나 자유롭게 수정이 가능합니다. PC용 OS보다 안정적이며 우수한 성능을 지니고 있습니다. 배포판이 아닌 리눅스 자체는 무료입니다. 다중 사용자 멀티태스킹을 지원합니다. Linux 패키지에 대해 Linux 패키지는 Linux System에서 소프트웨어를 실행하는데 필요한 파일들이 담겨있는 설치 파일 묶음입니다. [예) 실행파일, 설정 파일, 라이브러리 등] Linux 패키지 종류에는 소스 패키지(Source Package), 바이너리 패키지(Binary Package)가 있습니다. Source Package [장점] 소스 패키지는 바이너리 패키지와 달리 원하는 대로 소프트웨어를 수정하여 사용할 수 있어 사용자의 입맛에 맞게 사용할 수 있다는 장점이 있습니다. [단점] Source Package는 소스코드가 들어있는 패키지로 컴파일 과정을 통해 바이너리 파일로 만들어야 실행할 수 있습니다. 설치할 때 컴파일 작업도 진행하므로 설치 시간이 길고 컴파일 작업 과정에서 오류가 발생할 확률이 있습니다. Binary Package [장점] Binary Package는 컴파일 작업이 되어있는 바이너리 파일이 들어있는 패키지입니다. 때문에 바로 설치가 가능하며, 오류가 없는 파일들로 컴파일이 되어있어 소스 패키지에 비해 설치 시간이 짧고 오류 발생 확률도 낮습니다. 그래서 리눅스의 기본 설치 패키지들은 대부분 바이너리 패키지입니다. [단점] 패키지 의존성이 있습니다. 바이너리 패키지는 컴파일이 되어있어 사용자의 컴퓨터 환경과 바이너리 패키지가 컴파일된 환경이 달라 문제가 발생할 수 있습니다. 특정 버전의 라이브러리가 필요하다면, 그 라이브러리들을 가지고 있지 않을 시 제대로 프로그램을 실행할 수 없다는 것입니다. Linux의 종류 Linux의 종류에는 매우 다양하게 있으나 크게 대중적으로 사용하는 CentOS와 Ubuntu가 있습니다. CentOS에 대해 CentOS는 Community Enterprise Operating System의 약자로 Red Hat 이 공개한 RHEL을 그대로 가져와 브랜드와 로고만 제거하고 배포한 배포본입니다. RHEL의 소스를 그대로 사용하고 있어 RHEL과 OS 버전, 패키지 구성이 똑같고 바이너리가 100% 호환됩니다. 무료로 사용이 가능하지만, 커뮤니티를 통해 지원이 되므로 패치가 느립니다. Ubuntu에 대해 영국의 캐노니컬이라는 회사에서 만든 배포판으로 쉬운 설치와 이용방법 덕분에 초보자들이 쉽게 접근할 수 있어 개인용 워크스테이션으로 많이 사용됩니다. 서버용으로 성능이나 기능이 부족하지 않지만 서버용 리눅스 점유율로 볼 때는 CentOS가 좀 더 높습니다. Linux에서 많이 사용하는 Ubuntu와 CentOS의 차이점 　　 Ubuntu CentOS System core 데비안 기반 레드헷 기반 Update 자주 가끔 보안 약하진 않지만 추가 구성 필요 강함 플랫폼의 초점 개인 개발 서버(데스크톱) 사용자에게 적합 실제로 서비스를 실행중인 상용화서버에 적합 패키지 apt-get, aptitude Yum 클라우드 인터페이스 OpenStack OpenStack, OpenNebula, CloudStack 가상화 KVM, Xen 기본 KVM 지원 안정성 좋다 강함 호스팅 시장 점유율 대략 33% 정도 대략 12% 정도 개발용으로 좋은 Ubuntu에 대해 1. 오픈소스 무료이며, 그래픽 사용자 인터페이스(GUI)와 명령행 인터페이스(CLI)가 있습니다. GUI를 사용할 시 단추, 창, 텍스트 상자 등의 그래픽 구성 요소를 사용해 쉽게 작업을 수행할 수 있습니다. 2. CLI를 사용할 시 사용자는 명령을 입력하고 신속하게 실행이 가능합니다. 3. 사용자는 Ubuntu 소프트웨어 센터 또는 다른 APT 기반 패키지 관리 도구에서 많은 무료 소프트웨어 및 도구를 다운로드할 수 있으며,많은 자료와 커뮤니티들로 초심자도 쉽게 사용할 수 있습니다.(Edubuntu라는 교육 응용 프로그램이 있는 우분투 교육용이 있습니다.) 4. 대비안으로부터 이어받은 APT를 통해 소프트웨어의 설치·관리 · 제거를 쉽게 할 수 있기 때문에 리눅스뿐만 아니라 컴퓨터 자체를 처음 접하는 이들에게 있어서도 최고의 리눅스 배포판이라고 할 수 있습니다. 5. 편리를 제공하기 위해 여러 하드웨어가 필요로 하는 다수의 펌웨어, 드라이버, 그리고 사용자가 주로 필요로 하는 여러 실용적인 소프트웨어들을 미리 탑재하고 있습니다. 덕분에 하드웨어 인식 기능이 뛰어납니다. Ubuntu, Ubuntu LTS의 차이 Ubuntu 정규 버전으로 6개월 주기로 배포하며, 배포 일로부터 9개월간 업데이트를 지원합니다. 배포 주기와 지원 주기가 짧지만 새로운 기능이 포함되어 있기 때문에 우분투의 기술을 체험해 보고 싶은 사용자들이 사용하기에 좋습니다. (데스크탑용으로 적합) Ubuntu LTS Long Term Support의 약자로 장기 지원을 뜻합니다. LTS 버전은 2년마다 새로운 버전을 배포하며, 업데이트는 배포 일로부터 5년까지 지원합니다.(서버용으로 적합) Ubuntu 패키지 설치방법 Ubuntu는 기본적으로 apt 명령과 apt-get, apt-cache 명령어를 사용하므로, 아래는 패키지 설치를 위한 간단한 명령어 비교 테이블입니다. apt와 apt-get, apt-cache 차이 apt 명령 기존명령 설명 apt install apt install 패키지 목록, 설치 apt remove apt remove 패키지 삭제 apt purge apt purge 패키지와 관련된 설정 제거 apt upgrade apt upgrade 업그레이드 가능한 모든 패키지 업그레이드 apt update apt update 레파지토리 인덱스 갱신 apt autoremove apt-get auto remove 불필요한 패키지 제거 apt full-upgrade apt-get disc-upgrade 의존성 고려한 패키지 업그레이드 apt search apt-cache search 프로그램 검색 apt show apt-cache show 패키지 상세 정보출력 apt edit-sources 소스 리스트 편집 상용화 서버에 좋은 CentOS에 대해 1. 무료입니다. 2. CentOS는 RHEL의 자유 형식입니다. 3. 각 버전은 최대 10년 동안 지속되고, 보안 업데이트도 제공하여 안정성이 높습니다. 4. CentOS는 Red Hat Branding을 대체하여 (동일한 소스코드) RHEL에서 실행 가능한 것들은 CentOS에서도 호환이 가능합니다. CentOS, RHEL의 차이 CentOS RHEL(레드햇 리눅스)의 동일한 소스코드로 무료로 RHEL을 사용할 수 있지만, 서비스를 받을 수 없어 유지가 가능한 사람들이 있어야 합니다. (엔터프라이즈 지원이 없습니다.) RHEL 레드햇의 공식 배포판으로 레드햇이 지원하는 서비스를 받을 수 있지만, 유료입니다.(엔터프라이즈 지원이 가능합니다.) CentOS 패키지 설치방법 CentOS는 기본적으로 YUM 명령어와, RPM 명령어를 사용합니다. 아래는 두 명령어의 비교 테이블입니다. YUM 명령 RPM 명령 설명 yum install rpm-Uvh 패키지 설치 yum remove rpm-e 패키지 삭제 yum update rpm-qa 업데이트 yum list rpm-qi 목록 YUM (Yellow dog Updater Modified) 인터넷을 통해 필요한 파일을 저장소에 다운로드한 뒤에 패키지를 구성한 요소를 전부 갖추어 설치하는 방법으로, 외부 서버랑 통신이 가능해야 합니다. (의존성 문제를 해결한 방식입니다.) RPM (Red Hat Package Manager) 리눅스 초기부터 사용해온 방식이며, 확장자는 RPM입니다. 인터넷 없이 RPM으로만 설치가 가능하나, 의존하는 패키지를 모두 직접 설치해야 합니다. (의존성 문제가 있습니다.) 2022.11.25

무거운 작업일수록 NVLink를 사용하는 이유 딥러닝 환경에서 왜 NVLink를 선호할까? 무거운 작업일수록 NVLink를 사용하는 이유 NVLink 이전에는 CPU만으로 연산을 할 수 있었지만, 지금은 CPU만으로는 버겁기 때문에 GPU는 선택이 아닌 필수가 되었습니다. GPU 서버 또는 워크스테이션을 사용하는 사용자들은 내가 사용하는 GPU가 좀 더 유연하고 많은 퍼포먼스를 보여줬으면 좋겠다고 생각을 할 것입니다. GPU를 상위 GPU로 바꾸고 싶어도 비용이 문제가 되기 때문에 이런 고민을 덜어줄 건 NVLink라고 생각합니다. NVLink 가 뭔가요? NVLink는 다중 GPU 시스템에 사용되는 기존의 PCI-E 기반 솔루션보다 더욱 유연한 퍼포먼스를 제공하는 고속 GPU 상호 연결 장치입니다. NVLink를 사용할 경우 GPU사이에 통신 대역폭을 높여 양방향으로 통신할 수 있기 때문에 NVLink 없이 단일 GPU를 사용했을 때 보다 더 나은 성능을 기대할 수 있습니다. ex) A6000 GPU 2개에 NVLink를 연결해주면 ‘최대’ 112GB/s의 대역폭 및 결합된 96GB 메모리를 제공하여 가장 메모리 집약적인 워크로드를 처리할 수 있습니다. NVLink는 모든 GPU에 호환이 되나요? NVLink라고 모든 GPU에 호환이 되는 건 아닙니다. 좌측 사진 2장처럼 (NVLink 2세대) 제품들은 쿼드로 제품(RTX5000 등)에 장착이 가능하고 3세대 NVLink(우측 사진 2장)는 A 시리즈 (A100, A5000, A6000 . . . )에 장착이 가능합니다. NVLink는 하나밖에 장착을 못하나요? 다른 GPU들은 GPU에 1개의 NVLink 슬롯이 있는 반면 A100 GPU의 경우 3개의 NVLink를 장착할 수 있습니다. 그러므로 총 12개의 NVLink를 장착할 수 있는데 12개 모두 장착한다면 총 600GB/s 대역대를 구현할 수 있는 장점이 있습니다. *앞으로 출시될 H100 GPU도 A100과 같은 1 GPU 3 NVLink 방향으로 출시될 방향으로 예상합니다. 최근 딥러닝 환경에서 많이 이용하는 GPU별 대역폭 자료 아래 자료는 Idel 상태의 GPU에 NVLink를 장착했을 때 보이는 대역폭 참고자료입니다. [GPU 외 다른 하드웨어 스펙] System : ESC8000A-E11 CPU : AMD EPYC 3rd 7413 x 2 Memory : 64GB x 8 M.2 NVMe : SK Hynix Platinum P41 M.2 NVMe 2TB x 1 ( RTX 3090 GPU x 2 + 3세대 NVLink 1 ) x ( A5000 GPU x 2 + 3세대 NVLink 1) x ( A6000 GPU x 4 + 3세대 NVLink 1 )[0번 1번 GPU에 NVLink 장착, 2번 3번 GPU는 장착안함] 위와 같은 참고 사례를 보아도 GPU를 단순하게 사용하는 것보다 NVLink를 사용해서 더욱 유연한 퍼포먼스를 기대하는 게 더 나은 방향이라고 생각합니다. 2022.10.06

머신러닝 전용 장비를 사용하는 이유 머신러닝 전용 장비를 사용하는 이유 채굴장비를 머신러닝에 사용할 수 있을까? 일반서버 vs GPU서버 우리가 쉽게 접하는 일반 서버는 CPU, Memory, Storage의 운영에 맞춰 설계된 반면, GPU 전용 서버는 GPU의 안정적인 운영을 위해 설계되었습니다. 큰 차이점은 3가지 입니다. 프로세서마다 차이가 있지만 인텔 프로세서를 기준으로, 평균 CPU 1개당 40개의 PCI 레인을 확장할 수 있습니다. 이는 우리가 흔히 말하는 “PCIe 16배속 그래픽카드” 의 “16배속" 이 “16개의 레인” 을 뜻합니다. 서버는 GPU외에도 USB, LAN, IPMI, RGB, BMC, BIOS 등의 다양한 장치가 필수로 운영되어야 하고 이는 적게는 1개, 많게는 4개까지의 PCIe 레인을 사용합니다. 기본 10개정도의 PCIe 레인을 사용한다고 가정하면, CPU 1개당 최대 2개의 16배속 GPU를 장착할 수 있습니다. 채굴장비에는 CPU 1개에 8개이상의 GPU를 장착합니다. 어떻게 그럴수 있을까요? 답은 간단합니다. GPU마다 1배속만 할당하면 됩니다. 전송대역폭을 낮추어 동작하게 하여도 채굴에는 큰 영향을 끼치지 않습니다. 하지만 이 대역폭은 머신러닝에서는 매우 중요합니다. GPU전용 장비에서는 다수의 GPU 병렬 사용을 위해 PLX를 채택하여 PCIe 레인을 확장하고 1개의 CPU만으로 128개 이상의 레인 사용이 가능하도록 설계됩니다. PLX는 PCIe 레인 확장을 위해 사용하고 이를 위해 많은 자원이 사용됩니다. 또, 안정적인 GPU운영을 위한 발열설계 및 발열 제어에 필요한 센서, 통제가 함께 장착되어 있습니다. 그리고 전원부는 눈에 띄는 차이점이 있습니다. 일반서버는 보통 500W-1000W 를 평균으로 전력이 공급되는 반면, GPU서버는 4000W-5000W의 전력공급장치가 장착되고, 충분히 버틸수 있는 내부 전력설계가 되어야 합니다. GPU 1개당 최대 피크에 400W 이상의 전력을 소모하고 8개의 GPU를 사용한다면 3500W 이상의 전력이 필요합니다. 일반서버에는 낮은 사양의 GPU 1개 혹은 2개가 장착될 수 있다면, GPU서버에는 고성능의 GPU 8-10개를 장착하여 사용할 수 있습니다. 당연히 추후 장애 포인트도 GPU서버가 훨씬 적습니다. 그리고 GPU서버의 모든 전원은 이중화되어 제공됩니다. 채굴 vs 머신러닝 위 내용대로 CPU 1개당 평균 40개의 레인을 사용할 수 있습니다. 레인은 대역폭을 PCI-E 3.0 1개 레인의 이론상 최대 전송 속도는 1GB/s 입니다. 채굴은 하나의 낮은 데이터, 복잡한 계산을 GPU로 보내 계산하고 계산된 낮은 데이터를 돌려받습니다. 대역폭이 클 필요가 없습니다. 하여 PCI-E레인을 1레인찍 잘게 쪼개어 GPU에 할당하고 GPU는 낮은 대역폭으로 통신하지만 높은 성능을 낼 수 있습니다. 머신러닝은 큰 데이터를 GPU에 보내어 학습 및 연산하고, 학습된 큰데이터가 결과물로 회신됩니다. 대역폭이 머신러닝 성능에 큰 영향을 미칩니다. 고가의 하이엔드급 GPU를 사용할 경우, GPU간 NVSwitch 를 제공하여 모든 GPU간 NVLink가 활성화 됩니다. GPU간 대역폭이 넓어져, 특정작업에서는 NVSwitch 미사용시보다 10배 이상의 성능차이가 나오기도 합니다. 고가의 하이엔드급 시스템이 아닌 일반 GPU전용시스템과 채굴장비도 같은 작업수행시 10배 이상의 성능차를 경험 할 수 있습니다. 가격차이 채굴장비와 머신러닝 시스템에서 공통으로 사용하는건 GPU입니다. GPU를 제외한 모든 시스템이 다르죠. GPU종류마다 다르지만 최근 머신러닝에 많이 사용하는 Quadro RTX A5000 을 예로 든다면 개당 270만원 정도의 금액으로 8GPU 시스템 한대에 GPU가격으로만 2000만원 정도입니다. 플랫폼을 선택한다면 채굴용으로 제작된 조립컴퓨터는 대략 200만원이고, 머신러닝 전용 시스템은 대략 800만원입니다 결론 시스템은 용도에 맞게 사용해야 합니다 G머신러닝장비 구입시 가장 먼저 생각해야 하는건 당연히 GPU의 종류입니다. 하지만 그에 못지 않게 GPU가 동작하는 플랫폼도 중요합니다. 사용 GPU의 최적성능 및 긴 수명을 원하신다면 GPU전용 장비를 사용해야 합니다. 저렴한 플랫폼을 선택한다면 10배 이상의 성능을 손해 볼 수 있고, 짧은 장비 수명으로 큰 비용이 매몰될 수 있습니다. 2022.07.22

테크니컬 스토리