AMD GPU로 모델이나 체크포인트를 로드하고 있다면, 해당 데이터가 호스트 RAM을 거치지 않는지 한 번 확인해 보길 바란다.
ROCm 10.1에서는 스토리지에서 GPU 메모리로 직접 데이터를 전송하는 경로가 비동기 I/O(async I/O)에도 확장되었다. AMD가 10월 5일에 발표한 기술 설명의 핵심은 연산 장치에 데이터를 전달하는 메커니즘이다.
- HIP 스트림(HIP stream)에 읽기와 쓰기를 투입하여 호스트 측 중계 복사(intermediate copy)를 생략할 수 있다.
- 직결이 불가능한 요청에는 호스트 메모리를 경유하는 다른 경로가 존재한다.
- 비동기 호환 경로(async compatible path)는 스트림별로 기본적으로 16MiB의 중계 버퍼를 재사용한다.
그것이 바로 ROCm 10.1에 포함된 “hipFile 0.5.0”이다. 16MiB는 환경 변수 사양에 명시된 실제 기본값이다.
예를 들어, 64GiB 파일을 호스트 RAM을 경유하여 GPU로 전송한다고 가정하면, 호스트 측의 논리적인 읽기와 쓰기는 총 128GiB가 된다. 이는 경로 이해를 위한 예시 계산일 뿐이며, 실제로 측정된 DRAM 전송량은 아니다. 중계를 생략한다는 의미는 이 왕복(round trip)을 만들지 않는 데 있다.
“Async를 호출했다” 또는 “읽기에 성공했다”만으로는 데이터가 직결 경로를 통과했다고 말할 수 없다.
ストレージから中継槽を経由する経路と、GPUへ直接つながる経路をガラス管で表したイラスト
생성된 일러스트. 호박색 중계조를 거치는 경로와, 그 과정을 생략하는 경로를 나타낸 비유이며, 실제 장비의 배선도는 아니다.
자료 확인일은 2026년 10월 11일이다. 신규성은 10월 5일 AMD 설명에 기반하며, 버전 및 제약 사항은 ROCm Core SDK 10.1.0의 릴리스 노트에 따른다. 세부 사항은 확인 시점에 0.5.0으로 표시된 hipFile 공식 자료를 참조했다. 대상은 같은 릴리스에서 제시된 Linux/Instinct 구성이다. 실제 장비 벤치마크는 미실시이며, 아래 HIP 코드와 명령어 역시 미실행 상태다. 64GiB의 예시는 자체적인 단순 계산으로 성능 수치가 아니다.
공식 백엔드 사양, 환경 변수, 비동기 API, 공식 샘플을 같은 날짜에 대조하여 정리했다.
| 항목 | 값/사양 | 오해하기 쉬운 점 |
|---|
| 이번 대상 버전 | hipFile 0.5.0 | ROCm 전체 버전 번호와는 다름 |
| 주요 전송 경로 | 2종류 | fastpath와 fallback |
| fastpath 적격 스코어 | 100 | 대역폭(bandwidth) 점수가 아님 |
| fallback 적격 스코어 | 1 | 처리할 수 없는 백엔드는 −1 |
| 비동기 fallback 중계 버퍼 | 스트림별 기본 16MiB | 0을 지정해도 기본 용량을 사용함 |
ALLOW_COMPAT_MODE의 기본값 | true | 경로 선택 시 fallback을 허용함 |
FORCE_COMPAT_MODE의 기본값 | false | 직결이 가능하면 후보가 됨 |
| 비동기 API의 1회 최대 I/O량 | $2^{31}$−시스템 페이지 크기 byte | 페이지 크기가 4KiB일 경우 2,147,479,552 byte |
| 공식 왕복 샘플 | 4 스트림 × 1MiB = 4MiB | 대용량 스토리지를 위한 성능 시험은 아님 |
| 페이지 정렬을 선언하는 stream 플래그 | 4KiB 정렬 | 모든 파일 시스템의 필수 정렬 값은 아닐 수 있음 |
여기까지는 공개된 사양 이야기다. 흥미로운 것은 그 너머에 있다.
AMD Infinity Storage 설명에서, fastpath는 스토리지와 GPU 메모리 사이를 DMA로 전송한다. CPU는 요청 투입이나 완료 처리에 관여하지만, 페이로드(payload)를 호스트 측 중계 영역으로 복사하지 않는다.
fallback: 스토리지 → 호스트 중계 버퍼 → GPU 메모리
fastpath: 스토리지 ─────────────────→ GPU 메모리
CPU는 요청 투입 및 완료 처리를 담당
“CPU를 전혀 사용하지 않는” 것은 아니다. 스토리지상의 데이터를 GPU로 전달할 때, 호스트 RAM에 한 번 놓는 과정을 없애는 설계다.
앞서 64GiB 예시에서 계산한 것은, 중계 영역으로의 64GiB 쓰기와, 거기서의 64GiB 읽기이다. 페이지 캐시나 캐시 계층의 동작까지 재현한 모델은 아니다. 이 128GiB를 생략할 가능성과 처리 시간이 절반이 된다는 것은 동의어가 아니다. 스토리지, PCIe, 연산 중 어디가 병목(bottleneck)이 되느냐에 따라 효과가 달라진다.
요청을 받으면 각 백엔드는 처리 가능성을 점수로 반환한다. 직결 가능한 fastpath가 100점, 호환 경로가 1점, 거부가 −1점이다. 높은 점수의 경로가 선택된다.
판단에 사용되는 것은 파일 열기 방식, GPU 버퍼 종류, 파일 시스템, 정렬 조건 등이다. 일반적인 로컬 NVMe 구성에서는 O_DIRECT, 디바이스 메모리(device memory), 대응하는 ext4/XFS 등이 문제가 된다.
한편, 선택된 후에도 장치 탐색이나 P2P DMA가 실패할 여지가 있다. 여기서 10.1.0의 릴리스 노트는 다음과 같이 명시하고 있다.
async fastpath operations do not currently retry on the fallback backend if the fastpath fails in this release.
직접 연결(直結)이 불가능하다면 처음부터 폴백(fallback)을 선택하는 경우와, 직접 연결을 시도한 후 실패하는 경우를 나누어 생각해야 한다.
| 발견된 증거 | 의미할 수 있는 것 | 의미할 수 없는 것 |
|---|
| fastpath의 적격 점수 100 | 해당 요청을 받아들일 조건이 갖춰짐 | 전송이 반드시 완료됨 |
ais-check의 종료 코드 0 | 대응하는 볼륨이 최소한 하나 존재함 | 대상 파일이나 GPU가 직접 연결 가능함 |
ais-stats의 경로별 바이트 수 | 어떤 경로로 얼마나 전송했는지 | 해당 경로가 항상 최속임 |
| 비동기 처리 후 바이트 수와 내용 일치 | 요청한 데이터의 전송 결과를 확인할 수 있음 | 호스트 측 중계가 없었음 |
비동기 API는 HIP stream에 I/O를 배치한다. 같은 stream 상에서는, 읽기를 한 후에 투입된 처리가 그 읽기보다 나중에 동작한다. 별개의 non-blocking stream 간에는, 그 순서 관계가 자동으로 생겨나지 않는다.
아래는 비동기 API의 인수를 사용한 순서 설명용 유사 코드이다. 미실행 상태임. 파일・GPU 버퍼・stream 등록 처리와 에러 처리는 생략했다.
// 유사 코드. 크기(size)・오프셋(offset)・완료 바이트 수는 동기 완료까지 유지시킨다.
size_t bytes = 1 << 20;
hoff_t file_offset = 0, buffer_offset = 0;
...
이 코드에서 알 수 있는 것은, 요청의 투입과 데이터의 사용 가능화를 분리해야 한다는 것이다. 경로가 fastpath였는지 여부는 별도로 통계로 확인한다.
자료를 통해 설명할 수 있는 것은 경로와 API의 계약(contract)까지이며, 손에 쥔 구성에서 얻을 수 있는 대역폭이나 단축 시간은 실제 기기 측정(실측)이 필요하다.
전제는 대응하는 Linux・Instinct 환경에 hipFile과 툴이 도입되어 있다는 것이다. 도입할 곳은 공식 설치 절차를 따르도록 한다. 아래의 /path/to/...나 앱 이름은 자신의 검증 환경 값으로 대체해야 한다.
공식 호환성 확인 절차 명령어에서, 볼륨별 HIPFILE 열을 읽는다.
# 미실행. 정확한 진단을 위해서는 root 권한이 필요하다.
sudo ais-check -v
종료 코드만 보는 것은 빠르다. 모델 파일을 놓는 마운트 포인트 행에서 yes가 되어 있는지, kernel・HIP runtime・amdgpu의 조건도 갖춰져 있는지 확인한다.
공식 비동기 샘플은 4개의 stream을 사용한다. 각 stream에서 1MiB를 읽고, 그 stream으로 다시 쓰기 한다. 다음 명령어는, 대응 버전의 소스 일체로부터 공식 CMake 절차로 샘플을 빌드하고, 실행 파일이 있는 디렉토리로 이동한 후 사용한다.
이 샘플은 입력 파일도 생성하며, 기존 내용을 덮어쓴다. 실제 모델 파일을 전달하지 말 것. 검증하고 싶은 볼륨 위의 전용 디렉토리를 사용한다.
# 미실행. 양쪽 모두 검증용 새로운 파일 경로로 대체해야 한다.
./roundtrip-async-multi-stream-registered \
/path/to/readfile /path/to/writefile 0
샘플의 바이트 수・해시 검증이 통하는 것과, 직접 연결로 동작하는 것은 별개이다. 다음 절차를 거듭한다.
공식 통계 툴은 앱을 실행하여, 그 I/O를 경로별로 집계할 수 있다. ./your_hipfile_app는 hipFile을 사용하는 검증 앱으로 대체한다.
# 미실행. 검증 앱의 필요한 인자도 끝에 붙인다.
HIPFILE_STATS_LEVEL=1 ais-stats ./your_hipfile_app
종료 후 보고서에서 fastpath와 fallback 각각의 읽기 바이트 수를 비교한다. fallback이 늘어났다면, 그 시점에서 'GPU 직결 실험'이라고 부르는 것을 멈추고 위치나 요구 조건을 조사해야 한다.
통계 수집에는 부하가 있기 때문에, 성능을 비교하는 두 조건에서는 수집 설정도 동일하게 맞춘다. 전송 크기뿐만 아니라, 에러 수와 비정렬 I/O 건수도 함께 읽는다.
당신의 환경에서는 파일의 위치, 정렬, GPU 가상화 중 어느 것이 첫 번째 장벽이 될 것 같은가? 당신의 예상도 댓글로 알려주었으면 한다.
제약 목록에는 LVM/device-mapper, multipath, dm-crypt, MD RAID, loopback과 같은 중간 블록 계층을 언급하고 있다. 파일 시스템 종류만 동일하게 맞춘다고 해서 그 아래 경로가 조건을 충족한다고 할 수는 없다.
대책: 대상 마운트의 배후에 있는 블록 계층까지 확인해야 한다. 암호화나 이중화 해제 여부를 속도만으로 결정해서는 안 된다.
HIPFILE_STREAM_PAGE_ALIGNED_INPUTS
은 4KiB 정렬을 선언하는 플래그이다. 한편, 백엔드가 검사하는 조건에서는 statx()
이 반환하는 offset 측과 메모리 주소 측의 정렬 값을 구분한다. 두 값이 같지 않을 수 있다.
크기만 정렬해도 파일 오프셋이나 버퍼 주소가 벗어나면 의도한 경로를 사용할 수 없다.
대책: 크기, file offset, buffer offset/address를 종합적으로 검사하고, 플래그로 사실과 다른 선언을 하지 않아야 한다.
HIPFILE_ALLOW_COMPAT_MODE=true여도, 0.5.0의 알려진 문제에는 비동기 fastpath의 자동 재시도가 없다고 명시되어 있다. 장치 탐색이나 P2P DMA가 실패하면, 그 비동기 작업은 실패한다.
대책: 투입 시 반환 값, 스트림 완료, 전송 바이트 수를 확인해야 한다. 호환 경로를 검증하고 싶다면, 후술하는 강제 설정으로 처음부터 선택해야 한다.
같은 알려진 문제에서는 SR-IOV의 VF에서 fastpath는 무효화된다. PF만이 대응 대상이다. ais-check
의 VF 경고는 종료 코드를 바꾸지 않는다.
즉, 'GPU를 인식했다'와 'GPU와 스토리지가 직결되었다'는 별개의 확인 사항이다.
대책: amd-smi로 VF인지 확인하고, 진단 경고와 경로별 바이트 수를 읽어야 한다.
다른 제품으로 넘어가기 전에, 같은 바이너리의 경로만 바꿔서 비교할 수 있다. 아래는 10월 11일에 확인한 공식 환경 변수들로 구성한 표이다. 열 이름의 ALLOW와 FORCE는 각각 HIPFILE_ALLOW_COMPAT_MODE와 HIPFILE_FORCE_COMPAT_MODE를 가리킨다.
| 비교 조건 | ALLOW | FORCE | 경로 선택 | 적합 용도 |
|---|
| 일반 자동 선택 | true | false | fastpath를 우선하고, 부적격이면 수용 가능한 fallback | 일반 설정에서의 경로 관측 |
| 직결 필수 | false | false | fallback을 허용하지 않고, 직결 불가하면 실패 | 중계 복사(中継コピー)를 숨기지 않는 검증 |
| 호환 강제 | true | true | 처음부터 fallback | 호스트 경유와의 비교 대조 |
두 경로 모두 요구를 수락받지 못하면 실패한다. 자동 선택 행도, 비동기 fastpath의 도중 실패를 구제하는 설정은 아니다. ALLOW=false와 FORCE=true의 조합은, fallback을 강제하면서 금지하기 때문에 I/O가 실패한다.
표에서 읽어낼 수 있는 것:
- 직결 검증에서는 성공률보다 경로를 고정하는 것이 우선이다. 자동 fallback이 섞인 비교에서는 무엇을 측정했는지 달라진다. -
- 호환 강제는 제거해야 할 기능이라고 단정할 수 없다. 환경 제약이 있는 구성이나 비교 대조로서의 역할이 있다. -
- 16MiB를 크게 해도 fastpath가 되지 않는다. 중계 용량 조정과 경로 선택을 혼동하지 말아야 한다.
검증용 앱을 직결 필수로 실행하는 설정은 다음 형태가 된다. 미실행. 이 명령어는 공식 환경 변수와 ais-stats의 시작 방법을 조합한 것이다.
HIPFILE_ALLOW_COMPAT_MODE=false \
HIPFILE_FORCE_COMPAT_MODE=false \
HIPFILE_STATS_LEVEL=1 \
...
비교할 때는 위 2개의 변수만 표대로 변경하고, 파일, GPU, I/O 크기, 스트림 수, 측정 구간은 고정한다. 먼저 경로별 바이트 수를 확인한 다음, 대역폭과 대기 시간을 비교한다.
✗ "Async라면 GPU 직결" → 비동기 fallback에도 중계 버퍼가 있다
✗ "16MiB보다 큰 파일은 읽을 수 없다" → 중계 용량과 전송 전체 크기는 별개다
✗ "진단 종료 코드 0이면 완료" → 대응 볼륨의 존재와 실제 요구는 별개다
...
hipFile의 흥미로운 점은, 애플리케이션이 원하는 'GPU 메모리상의 데이터'를 호스트 RAM을 거치지 않고 전달할 수 있다는 점에 있다. 이 길이 열리면, 연산기 최적화만으로는 도달할 수 없었던 대기 시간(latency)에 손을 댈 수 있게 된다.
하지만 API 이름도 종료 코드도, 데이터가 지나간 길의 증거는 될 수 없다. 오늘, 검증용 로드 중 하나를 골라 fastpath와 fallback의 전송 바이트 수를 나란히 비교해 보길 바란다.
ROCm 10.1: Breaking the Data-Movement Bottleneck (2026-10-05)
ROCm Core SDK 10.1.0 release notes
AMD Infinity Storage
hipFile fastpath and fallback backends
hipFile environment variables
Asynchronous I/O API reference
Check system compatibility with ais-check
hipFile ais-stats tool
Asynchronous multi-stream I/O with registered streams
Install hipFile
Build and install hipFile from source
Limitations
Known issues
GPU 로드 대기 시간을 측정하는 동료들에게, 좋아요・저장・공유로 이 3단계를 전달해 주길 바란다.
댓글로 알려주었으면 한다.
**먼저 측정한다면, 모델 로드・체크포인트・데이터셋 중 무엇을 선택할까?**당신의 검증 환경에서는, 직결 필수와 호환성 fallback 중 어느 것을 기본값으로 할래?
