왜 iGPU가 홈 서버 앱과 메모리를 경쟁하나요?

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

Why Does an iGPU Compete With Home Server Apps for Memory?

iGPU는 그래픽, 미디어, AI 작업이 CPU와 동일한 시스템 메모리 용량과 대역폭을 사용하기 때문에 홈 서버 앱과 경쟁합니다.

이 경쟁은 모니터링 도구에서 그래픽 엔진이 별도의 장치로 표시되기 때문에 쉽게 놓칠 수 있지만, 대부분의 통합 GPU는 큰 전용 VRAM 풀을 가지고 있지 않습니다. 컨테이너, 데이터베이스, 파일시스템 캐시, 가상 머신, 모델 런타임, 그리고 iGPU 모두 동일한 설치된 DRAM과 메모리 컨트롤러에 의존합니다. 아래 섹션에서는 예약된 메모리와 동적 사용을 구분하고, 프레임 서피스와 AI 버퍼가 작업 집합을 어떻게 확장하는지 설명하며, 서버가 여유 RAM이 있음에도 공유 대역폭 압박으로 인해 느려질 수 있는 이유를 보여줍니다.

통합 그래픽은 시스템 메모리 풀을 사용합니다

별도의 GPU는 보통 자체 VRAM을 가지고 있지만, 통합 GPU는 프로세서나 시스템 패키지에 내장되어 플랫폼의 메인 메모리에 접근합니다. CPU와 그래픽 엔진은 별도의 실행 자원이지만, 그들의 활성 데이터는 궁극적으로 동일한 물리적 DRAM 시스템을 차지합니다.

인텔은 통합 그래픽 메모리가 별도의 메모리 뱅크가 아닌 시스템 RAM에서 온다고 설명합니다. 즉, 디코딩된 프레임, AI 텐서, 데스크톱 서피스, 그래픽 버퍼는 애플리케이션 페이지, 데이터베이스 캐시, 파일시스템 데이터를 저장할 수 있는 용량을 소비합니다.

결과적으로 GPU가 Windows나 Linux가 사용 가능한 그래픽 메모리로 보고하는 모든 바이트를 영구적으로 소유하는 것은 아닙니다. 실제 사용량은 작업 부하, 드라이버 정책, 펌웨어 설정, 애플리케이션이 현재 매핑한 버퍼에 따라 변합니다.

보고된 공유 메모리는 한계치이며 고정 예약이 아닙니다

운영 체제는 종종 큰 “공유 GPU 메모리” 수치를 표시하는데, 이는 이미 서버에서 사라진 RAM으로 오해될 수 있습니다. 많은 구현에서 이 값은 고정 할당이 아니라 상한선 또는 회계 범주입니다.

인텔 그래픽 메모리 FAQ는 공유 시스템 메모리가 지속적인 예약이 아니라고 명시합니다. 그래픽 드라이버와 운영 체제는 현재 CPU와 GPU 작업 부하에 따라 메모리를 할당합니다.

이 구분은 용량 계획 시 중요합니다. 유휴 대시보드는 대부분의 RAM이 여유 있다고 표시할 수 있지만, 트랜스코딩, 비전 모델, 여러 원격 데스크톱이 빠르게 큰 서피스를 할당하여 컨테이너에 사용 가능한 여유 공간을 줄일 수 있습니다.

펌웨어 예약 메모리는 다릅니다. BIOS나 UEFI 설정은 운영 체제가 시작되기 전에 더 작은 고정 그래픽 영역을 예약할 수 있으며, 이 부분은 iGPU가 유휴 상태일 때도 일반 애플리케이션에서 사용할 수 없습니다.

프레임 서피스는 디코딩, 처리, 인코딩 중에 확장됩니다

하드웨어 트랜스코딩은 압축된 입력과 출력만 메모리에 유지하지 않습니다. 파이프라인은 디코딩된 프레임 서피스, 참조 프레임, 스케일링 또는 톤 매핑 버퍼, 비동기 디코딩 및 인코딩 단계를 유지할 충분한 대기 서피스도 필요로 합니다.

인텔 oneVPL은 디코더 서피스 풀을 설명하며, 활성 비디오 구성 요소에 충분한 프레임 서피스를 포함해야 한다고 합니다. 해상도, 비트 깊이, 크로마 포맷, 참조 프레임 수, 필터, 동시 스트림 모두 작업 메모리 양을 변경합니다.

단일 4K 프레임 서피스는 그것을 생성한 압축 패킷보다 훨씬 큽니다. 따라서 여러 동시 트랜스코딩은 미디어 파일이 디스크에 남아 있어도 그래픽에서 보이는 메모리 사용량을 증가시킬 수 있습니다.

고정 기능 미디어 엔진은 CPU 산술 작업을 줄일 수 있지만, 이러한 프레임을 공유 메모리 계층을 통해 저장하고 이동해야 하는 필요성을 제거하지는 않습니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

용량 압박은 앱을 회수 및 스왑으로 밀어넣을 수 있습니다

iGPU 할당과 애플리케이션 작업 집합이 설치된 RAM에 근접하면 운영 체제는 깨끗한 캐시 페이지를 회수하거나 메모리를 압축하고, 애플리케이션 페이지를 퇴출하거나 데이터를 스왑으로 이동해야 합니다. 첫 번째 눈에 띄는 느려짐은 GPU 작업이 아닌 관련 없는 데이터베이스나 웹 앱에서 나타날 수 있습니다.

인텔의 최신 메모리 균형 제어는 그래픽 메모리 수요가 높은 애플리케이션과 CPU 메모리 수요가 높은 애플리케이션 간의 균형을 명확히 설명합니다. 그래픽 한도를 높이면 한 작업 부하에는 도움이 되지만 시스템 나머지 부분에 대한 보호는 줄어듭니다.

파일시스템 캐시는 종종 조용한 희생양입니다. 홈 서버는 컨테이너에 충분한 익명 메모리를 유지할 수 있지만, 자주 읽는 미디어 메타데이터, 썸네일, 데이터베이스 페이지, 디렉터리 항목을 퇴출하여 저장 장치가 느리게 느껴지게 할 수 있습니다. 드라이브 사용률은 변하지 않았음에도 말입니다.

대역폭 경쟁은 RAM 용량이 가득 차기 전에 나타날 수 있습니다

여유 용량은 얼마나 더 많은 데이터를 저장할 수 있는지를 측정하며, CPU와 iGPU가 이미 사용 중인 데이터를 얼마나 빨리 이동할 수 있는지는 측정하지 않습니다. 두 엔진 모두 동시에 DRAM 대역폭을 요청할 수 있습니다.

인텔의 GPU 최적화 가이드는 CPU와 통합 GPU 간의 공유 DRAM 트래픽을 설명합니다. ZimaSpace의 메모리 대역폭 제한 설명은 AI 디코딩, 비디오 프레임, 애플리케이션 캐시, CPU 작업이 메모리 용량이 소진되었다고 작업 관리자에 보고되기 전에 서로를 느리게 할 수 있는 이유를 보여줍니다.

이로 인해 특징적인 증상이 나타납니다: GPU 또는 CPU 사용률이 100% 미만으로 유지되면서도 메모리 채널, 데이터 속도, 복사 동작, 동시 작업 부하에 따라 처리량이 크게 변할 수 있습니다.

용량과 대역폭을 별도의 한계로 측정하세요

서버를 단계별로 테스트하세요: 애플리케이션 단독, iGPU 작업 부하 단독, 그리고 두 가지를 함께. 사용 가능한 메모리, 커밋된 메모리, 스왑 활동, 파일시스템 캐시, 메모리 대역폭, iGPU 엔진 사용량, 그리고 중요한 애플리케이션 응답 시간을 기록하세요.

Windows는 GPU 메모리 세그먼트를 노출하며, Linux 도구는 드라이버에 따라 그래픽 엔진과 시스템 메모리 활동을 노출할 수 있습니다. 유용한 비교는 보고된 “VRAM” 수치가 아니라 iGPU 작업이 시작될 때 전체 메모리 시스템이 어떻게 변하는지입니다.

스왑이나 공격적인 캐시 회수가 나타나면 RAM을 추가하거나 동시 서피스를 줄이고, 애플리케이션 작업 집합을 축소하거나 가속기 작업 부하를 분리하세요. 용량이 충분하지만 CPU와 iGPU 처리량이 함께 떨어진다면 채널 구성을 개선하거나 복사를 줄이거나 한 작업 부하를 전용 메모리가 있는 장치로 옮기세요.