같은 ML 결과를 위해 어떤 GPU가 가장 저렴할까요?

허용되는 결과의 기준 정의하기

실험 전에 결정을 문서로 작성하세요: "어떤 구성이 모든 문서를 처리하고, 최소 품질을 충족하며, 마감 전에 완료되고, 투입 예산이 가장 적은가?" 시나리오를 정하세요: 여기서는 오프라인으로 처리되는 코퍼스입니다. 대화형 애플리케이션이라면 요청 도착, 동시성, 허용 지연 시간도 정의해야 하며, 그 순위는 이 단일 실험만으로 도출되지 않습니다.

모든 검사를 통과한 완전한 출력 집합을 검증된 코퍼스라고 부릅니다. 파일이 생성되었다고 해서 아직 허용된 결과는 아닙니다. 식별자, 형식, 커버리지, 그리고 사용 목적과 관련된 지표를 확인하세요. 시간을 보기 전에 기준 대비 임계값과 허용 오차를 기록하세요. 이렇게 하면 두 구성이 비트 단위로 동일한 수치를 내지 않더라도 결정에 대해 동등할 수 있습니다.

데이터셋, 품질 목표, 시나리오 간의 이러한 구분은 MLPerf Inference의 원칙에도 존재합니다. 아래 프로토콜은 프로젝트에 맞게 조정할 수 있는 우리의 작업 방법이며, MLPerf 실행이나 인증을 구성하지 않습니다.

기술 출처: MLCommons — 시나리오, 지표 및 품질 목표

입력, 기준 및 매니페스트 준비하기

사용 권한이 있는 코퍼스, 기준 답변 또는 평가 절차, 추론 코드, 선택한 모델을 실행할 수 있는 환경이 필요합니다. 최종 비교 코퍼스의 구성을 조정하는 데 사용되는 데이터와 비교용 데이터를 분리하세요. 최종 코퍼스를 본 뒤에 임계값을 조정한다면, 결론을 뒷받침할 새롭고 독립적인 평가를 준비하세요.

각 입력에 안정적인 식별자를 부여하세요. 코퍼스 지문, 처리 순서, 모델 및 토크나이저 리비전, 코드와 종속성 버전을 보관하세요. 매니페스트에는 사용된 GPU, 정밀도, 양자화, 컴파일, 어텐션 백엔드, 패딩 정책, 최대 길이도 기술합니다. 잘림이 다르면 비교할 작업이 달라집니다.

실제로 설치된 드라이버와 백엔드를 확인하세요. AMD 변형이라면 시스템, GPU, ROCm 및 프레임워크 조합을 공식 호환성 매트릭스에서 확인하세요. 문서를 참고했거나 그래픽카드 이름을 확인한 것만으로는 해당 환경이 설치되어 있다는 것이 증명되지 않습니다. 두 시험에서 소프트웨어 스택이 다르다면, 결론은 테스트한 전체 구성에 대한 것이 됩니다.

기술 출처: AMD — ROCm 호환성 매트릭스

예시: 동일한 1,000개 텍스트 분류하기

다음은 성능 결과를 미리 가정하지 않고 여러분의 데이터로 구성해 볼 실험입니다. 프로젝트의 범주로 1,000개 텍스트를 분류하려고 합니다. 짧은 항목 600개, 중간 항목 300개, 긴 항목 100개를 확보하세요. 선택한 tokenizer로 경계를 정의하고 클래스 분포가 대표성을 유지하도록 하세요. 이 구분은 프로토콜의 예시일 뿐이며, 제공된 코퍼스나 보편적인 비율 권장 사항이 아닙니다.

동일한 모델, 동일한 정밀도, 동일한 순서, 동일한 padding 규칙으로 배치 1, 4, 8을 비교하세요. 이 첫 번째 시리즈에서 유일한 변수는 배치입니다. 두 번째 시리즈에서는 정밀도나 하드웨어를 바꿀 수 있지만, 다른 선택 사항은 명시적으로 고정해야 합니다. 길이별 그룹화는 작업 구성 방식을 바꾸므로 새로 선언해야 하는 변형입니다.

각 실행마다 1,000개의 예측을 해당 식별자와 함께 내보내세요. 검증에서는 예상한 식별자가 중복이나 누락 없이 정확히 모두 나타나야 합니다. 잘못된 예측도 보관하세요. 이는 품질 계산에 사용됩니다. 어려운 예시를 제거하면 점수가 인위적으로 높아지고 실제로 처리된 코퍼스가 줄어듭니다.

시작, 워밍업, 측정 구간 분리하기

필요한 다운로드, 설치, 로드 및 컴파일을 안정화된 처리와 별도로 기록하세요. 이러한 과정은 실행 시간 측정에서 제외할 수 있지만 대여 시간의 일부를 차지합니다. 모든 변형에 동일한 워밍업 규칙을 정하세요. 포함할 입력, 실행 횟수, 재컴파일 처리 방식 등입니다. 어떤 변형이 이득을 보는지 확인한 후에 이 규칙을 조정하지 마세요.

주요 시간의 경계를 정의하세요. 이 오프라인 예시에서는 코퍼스 읽기, tokenization, 전송, 추론, 호스트에서의 예측 생성까지 측정하세요. 그런 다음 평가와 결과물 작성을 별도로 시간 측정하여 전체 캠페인 시간을 산출하세요. GPU 연산만 제한한 시간은 이 처리 시간과 직접 비교할 수 없습니다.

CUDA 연산은 비동기식입니다. 호스트 타이머는 시작 전에 이전 연산 완료를 기다리고, 종료 전에 측정 대상 작업 완료를 기다려야 합니다. CUDA 이벤트는 GPU 범위를 올바르게 정의한 경우에 적합합니다. 단일 연산의 경우 torch.utils.benchmark.Timer가 워밍업과 동기화를 처리합니다. 변형 간에 동일한 측정 경계를 유지하세요.

기술 출처: PyTorch 2.14 — 비동기 CUDA 실행 · PyTorch — torch.utils.benchmark로 측정하기

반복하고 실패도 보관하기

이 첫 번째 비교에서는 변형당 다섯 번의 전체 실행을 계획하세요. 순서를 번갈아 배치하세요. 예를 들어 1–4–8, 그다음 4–8–1, 그다음 8–1–4 순으로 하여 특정 변형이 항상 먼저 실행되지 않도록 하세요. 프로세스, 캐시, 워밍업 정책은 유지하세요. 이 다섯 번의 실행은 여러분의 작은 시리즈를 설명할 뿐이며, 그것만으로 장기간의 안정성을 입증하지는 않습니다.

원시 표의 한 행은 중단을 포함하여 시도된 실행을 나타냅니다. 이는 변형과 코퍼스를 파라미터, 소요 시간 및 품질 판정에 연결합니다. expected_ids와 observed_ids 필드는 항목 수를 기록하며, ids_match는 별도로 보관된 예측 파일에서 확인된 집합의 동등성을 확정합니다. corpus_accepted에는 해당 실행의 판정이 담깁니다. 오류와 출력 경로는 notes에 기록하세요. 측정값이 없으면 해당 셀을 비워 두고 그 이유를 밝히세요. GPU의 부재는 0초 또는 0바이트의 측정값이 아닙니다.

긴 입력에서 batch 8이 메모리를 초과하면 실패한 행과 완료된 항목 수를 그대로 유지하세요. 이 실행을 더 작은 batch로 조용히 대체하지 마세요. 재개 설정은 별도의 변형이 되며, 그 시간과 시도 횟수도 결산에 포함됩니다. 중단이나 형식 오류는 빨랐다는 이유로 경제적 성공이 되지 않습니다.

다섯 번의 시험으로 소요 시간을 과대 해석하지 않고 읽기

다섯 개의 원시 소요 시간, 그 중앙값, 최솟값, 최댓값을 성공 및 실패 횟수와 함께 제시하세요. 중앙값은 이 관측값들의 중심을 설명할 뿐 사고를 없애지는 않습니다. 문서화된 외부 원인으로 어떤 실행을 제외한다면 그 흔적을 남기고 모든 변형에 동일한 제외 규칙을 적용하세요.

다섯 번의 실행으로 계산한 p95를 느린 경우의 견고한 추정값으로 제시하지 마세요. 요청 지연 시간을 연구하려면 도착 시나리오와 동시성을 포함한 적절한 개별 시간 집합을 수집하세요. 코퍼스의 다섯 소요 시간과 1,000개 요청의 지연 시간은 같은 모집단이 아닙니다.

관측된 분산이 중앙값 간의 차이와 비슷하다면 그 시리즈는 아직 옵션들을 가리지 못합니다. 공통 프로토콜로 반복을 추가하거나 특정 원인을 살펴보세요: 로딩, 입력 형태, 컴파일, 동시 활동. 각 카드에서 가장 좋은 실행만 골라 유지하지 마세요.

정밀도 변경 후 품질 확인

FP32, BF16 또는 양자화를 비교하려면 동일한 입력과 동일한 기준에서 다시 시작하세요. 형식, 주요 지표, 사전에 정한 하위 그룹을 평가하세요. 허용 범위를 벗어난 변형은 다른 목적에는 흥미로울 수 있지만, 사후에 임계값을 낮춰 동등 품질 비교에 합류하지는 않습니다.

사용한 시드와 결정론적 옵션을 기록하세요. PyTorch는 같은 시드를 사용하더라도 버전, 플랫폼 또는 CPU와 GPU 실행 간의 완전한 재현성을 보장하지 않습니다. 따라서 무엇을 재현하려는지 명확히 하세요: 동일한 출력, 한정된 수치 편차 또는 허용 가능한 업무 품질. 확률적 프로토콜이라면 여러 공통 시드를 마련하고 그 결과를 따로 보관하세요.

기술 출처: PyTorch 2.14 — 재현성의 범위와 한계

메모리를 실현 가능성 기준으로 사용하기

어떤 옵션의 비용을 비교하기 전에, 그 옵션이 긴 입력을 포함한 코퍼스를 끝까지 처리해야 합니다. 장치별 메모리 피크와 카운터의 범위를 기록하세요. PyTorch에서 memory_allocated는 텐서를, memory_reserved는 할당자가 관리하는 메모리를 추적합니다. 이 값들은 서로 더해지지 않습니다. 각각의 피크는 서로 다른 시점에 발생할 수 있습니다.

메모리 폴더의 노트북은 추정과 관측을 구분하는 데 도움이 됩니다. 그 연습이 여러분 모델의 측정을 대신하지는 않습니다. 여러분의 환경을 로드하고 매개변수를 유지한 채 워크로드를 다시 실행하세요. 카드별로 표시된 용량과 로트 가격만으로는 처리량, 상호 연결 또는 여러 GPU에 걸친 모델의 자동 분배를 추론할 수 없습니다.

기술 출처: PyTorch 2.14 — 메모리 카운터와 할당자

전체 일정으로 소요 시간 선택하기

필요한 소요 시간은 GPU 커널들의 합만이 아닙니다. 인스턴스 준비부터 결과물 회수까지의 접근 창을 구성하세요: 설치, 점검, 워밍업, 비교, 예정된 재개, 평가, 내보내기. 인스턴스를 계속 유지해야 하는 대기 기간도 더하세요. 작업들이 겹칠 때는 두 소요 시간을 두 번 더하지 말고 실제 일정을 기준으로 판단하세요.

속도 가정이 없는 일정 예시입니다. 월요일 오전 9시부터 금요일 오전 9시까지 같은 시간대에서 서머타임 변경 없이 접근을 유지하려고 한다고 가정합니다. 이 기간은 96시간입니다. 이는 3일권의 72시간을 초과하며 7일권의 168시간 안에 들어옵니다. 이것이 작업이 제때 끝난다는 것을 증명하지는 않습니다. 소요 시간은 여전히 측정해야 합니다.

계산기를 사용하면 전체 기간을 입력할 수 있고 3일, 7일, 30일권이 표시됩니다. 일정을 커버하는 권이 후보가 됩니다. 캠페인이 정한 기간을 초과하면 일정을 수정하거나 추가로 필요한 기간을 명시적으로 산정하십시오. 자동 연장을 가정하지 마십시오.

요금제로 발생 비용 계산하기

임대 예산은 한 로트의 요금제 가격에 로트 수를 곱한 값입니다. 검증된 코퍼스당 비용은 이 총액을 명시한 범위에서 실제로 승인된 유효 코퍼스 수로 나눈 값입니다. 승인된 코퍼스가 없으면 이 비율은 정의되지 않습니다. 지출한 비용은 결산에 그대로 남습니다.

아래 가격은 2026년 9월 24일자 카탈로그에서 가져온 것입니다. 이는 계산 규칙을 예시할 뿐, 어떤 GPU가 작업을 가장 빨리 끝내는지는 확정하지 않습니다. B200 로트에는 이미 두 장의 카드가 포함되어 있으므로, 그 가격에 다시 2를 곱하면 이 카드들을 두 번 세게 됩니다. 따라서 7일 동안의 RTX 4090 로트 2개는 220 USD이고, 7일 동안의 B200 2대 로트 하나는 2,071 USD입니다.

짧은 실행이라고 해서 요금제가 시간당 청구로 바뀌지는 않습니다. 계산기는 기간의 일부가 사용되지 않더라도 요금제 총액을 사용합니다. 더 넓은 프로젝트 예산의 경우 실제로 적용되는 다른 지출과 그 근거를 별도로 기록하십시오. 한 변형에서 측정한 비용과 다른 변형에서 누락된 항목을 섞지 마십시오.

기술 출처: IteraGPU — 카탈로그 요금제

측정 반복이 아닌 유효 산출물 세기

동일 벤치마크를 다섯 번 반복하는 것은 분산을 관찰하기 위한 것입니다. 파일 다섯 개를 작성했다는 이유만으로 그것이 다섯 개의 유효한 프로덕션 코퍼스가 되지는 않습니다. 캠페인 전에 예상 산출물을 정의하고 승인된 각 산출물을 한 번만 세십시오. 실제 작업이 여러 코퍼스에 걸쳐 있다면 각 구성이 동일한 코퍼스를 처리하고 동일한 품질 규칙을 적용해야 합니다.

계산기에서 유효 산출물이 실제로 완료되고 검증될 때까지 코퍼스 수를 비워 두십시오. 품질 체크박스는 사용자本人的 검증을 확인하는 것이며, 이 도구는 예측이나 지표를 읽지 않습니다. 확인된 수량만 입력하십시오. 캠페인 기간은 계획 가정일 수 있지만, 용량 예측이 승인된 결과를 대신하지는 않습니다.

최종 결산은 각 허용 가능한 구성에 대해 품질 판정, 원시 소요 시간, 캠페인 기간, 발생한 요금제, 승인된 산출물 수를 종합합니다. 빠른 옵션은 촉박한 마감에 유용할 수 있지만 가장 저렴하지는 않을 수 있습니다. 같은 일정 안에 들어오는 두 옵션은 발생 비용, 실패 또는 남은 불확실성으로 구분할 수 있습니다.

프로토콜을 다운로드하고 재사용 가능한 증거 남기기

IteraGPU Lab v1 폴더에는 이 비교와 메모리 측정에 필요한 자료가 모여 있습니다. README와 품질 프로토콜부터 시작한 다음, 원시 표에 본인의 실행을 추가하십시오. 성능 셀은 실행 전까지 비어 있으며, 요금은 측정값과 분리된 카탈로그 데이터입니다.

RTX 4090 두 묶음을 7일 동안 사용하는 비용을 산출하려면 calcul_forfaits.py와 tarifs-forfaits.csv를 같은 폴더에 두고, 그 폴더에서 터미널을 열어 Python 3.10 이상으로 아래 명령을 실행하세요. 그러면 GPU 두 장에 대해 220.00 USD의 정액 요금이 표시됩니다. 선택 옵션인 --accepted-results는 실제로 완료되고 검증된 서로 다른 유효 코퍼스의 정수를 받습니다. 그러한 확인이 없다면 이 옵션은 생략하세요. 그 경우 스크립트는 결과당 비용을 임의로 만들지 않고 정액 요금만 계산합니다.

매니페스트, 입력 지문, 예측, 판정, 시도 표를 함께 보관하세요. 결정 메모에는 선택한 설정, 그 설정이 감당하는 부하, 선택 이유를 적습니다. 이를 IteraGPU 원장의 대여 기록과 대조할 수 있으며, 모델이나 버전이 바뀔 때 실험 질문을 그대로 다시 실행할 수 있습니다.

이 오프라인 프로토콜만으로는 대화형 서비스, 수렴까지의 학습, 또는 다른 데이터셋을 정당화할 수 없습니다. 이러한 용도에서는 비교하기 전에 유효 단위와 검증 항목을 다시 정의하세요. 제공된 파일은 실험을 준비하고 기록하기 위한 것이며, 이 폴더에는 카탈로그 구성 간의 실측 비교나 관측된 절감 효과가 제시되어 있지 않습니다.

python calcul_forfaits.py --gpu rtx-4090 --days 7 --lots 2

• IteraGPU Lab v1 — 전체 패키지 ↓

  스크립트, 노트북, 표 및 안내 아카이브.

• 품질 프로토콜 ↓

  실험 전에 확정할 입력, 수용 기준 및 비교 규칙.

• 원시 결과 표 ↓

  파라미터, 측정값, 판정 및 실패를 기록할 빈 시트.

• 정액 요금 계산 ↓

  묶음당 가격, 3·7·30일 기간 및 검증된 코퍼스를 사용한 예산 계산.

• 정액 요금 가격표 ↓

  제공된 계산에서 사용하는 카탈로그 가격 스냅샷.

• 메모리 측정 노트북 ↓

  메모리 패키지와 함께 해석할 계산 및 측정 연습.

• 메모리 측정 스크립트 ↓

  환경 점검 기능이 포함된 연습의 Python 버전.

• 지침 및 사전 요구 사항 ↓

  도구의 범위와 이를 실행하고 출력을 보관하는 절차.

• 리소스 라이선스 ↓

  패키지의 원본 리소스 재사용 조건.