평균 지연 시간(average latency)만으로는 모델 접근성을 평가하기 어렵습니다. 문제는 모든 사람이 공유 경로에서 동시에 같은 GPU를 원하게 되는, 가장 바쁜 90분 동안 발생합니다. 따라서 비교할 가치가 있는 유일한 테스트는 조용한 오후의 벤치마크가 아니라, 실제로 작업하는 시간에 맞춰 예약된 버스트 테스트(burst test)입니다. 아래에는 제가 무료 호스팅 레인(free hosted lane), 자체 런타임을 실행하는 무료 서버, 유료 호스팅 레인(paid hosted lane), 그리고 직접 소유한 하드웨어 중에서 선택할 때 사용하는 의사결정 가이드가 있습니다.
핵심 주장은 간단합니다. 추론 레인은 작동하는 피크 시간대에서 어떻게 동작하는지를 기준으로 선택하고, 그다음으로 작업 부하(ops load)를 고려하며, 마지막에만 가격표(sticker price)를 고려해야 합니다. 1000 토큰당 가격은 시작점이 아니라 동점자 결정 요소일 뿐입니다. 만약 어떤 레인이 화요일 오후 4시(16:00)에 여러분의 기준 성능을 충족하지 못한다면, 그 저렴함은 마감 기한을 놓치는 비용에 비하면 무시할 수 있는 오차 범위에 불과합니다.
1. 측정하기 전에 기준점(floor) 정의하기
기준점(floor)이란 피크 시간대에 작업 단위당 허용 가능한 가장 느린 왕복 시간을 의미하며, 이는 방어할 수 있는 숫자가 되어야 합니다. 개발자가 기다리는 인라인 코딩 어시스턴트의 경우, 저의 기본 기준점은 작고 고정된 작업을 완료하는 데 걸리는 첫 번째 답변까지 25초입니다. 배치 작업(batch jobs)의 경우, 요청당 지연 시간보다는 시간당 처리량(throughput per hour)이 기준점이 됩니다. 이 숫자를 기록하고 창(window)을 하네스 설정에 입력하여 변동되지 않도록 해야 합니다.
왜 창(window)이 숫자보다 더 중요할까요? 무료로 제공되는 공유 용량은 큐(queue)이기 때문이며, 이 큐는 여러분의 스케줄이 아닌 다른 사람들의 스케줄에 의해 형성됩니다. 오전 9시에 측정한 p50 값으로는 오후 4시 30분(16:30)에 대해 거의 아무것도 알려주지 못합니다. 측정할 시간이 하나밖에 없다면, 바쁜 시간을 측정하세요.
2. 하네스 하나를 구축하고 모든 레인에 실행하기
아래의 하네스는 고정 크기의 버스트로 동일한 프롬프트를 네 가지 로컬 시간대에 걸쳐 보내고, 벽시계 지연 시간(wall-clock latency)과 시도당 재시도 횟수를 기록하며 CSV 파일에 추가합니다. 저는 프롬프트를 작고 결정론적으로 유지하여 차이가 작업 자체가 아닌 레인에서 나오도록 했습니다. 이 스크립트는 템플릿입니다: 저는 이 기사를 위해 어떤 제공업체(provider)를 대상으로도 실행한 적이 없으며, 여러분이 얻는 숫자는 여러분 자신의 것이 될 것입니다.
burst_timing.py -- template, unexecuted here
import csv, json, os, time, urllib.request
...
각 레인별로 3일간 실행합니다. 측정 코드가 변경되지 않도록 환경 변수를 통해서만 레인을 전환합니다:
export LLM_BASE_URL="https://lane-a/v1" LLM_MODEL="<listed-model>" LLM_API_KEY="..."
python burst_timing.py
# lane-b, lane-c, lane-d로 반복; 레인별로 하나의 CSV 파일 생성
3. CSV를 버스트당 세 개의 숫자로 축소하기
지연 시간(Latency)만으로는 오해의 소지가 있으므로, 각 버스트를 최소 통과율 대비 패스율(pass rate), p90 지연 시간, 재시도율(retry rate)로 축소합니다. 이 세 가지 숫자는 각각 대기 시간, 꼬리 분포 행동(tail behavior), 그리고 불안정성(flakiness)을 한 줄에 포착합니다.
# summarize.py -- template, unexecuted here
import csv, statistics, sys
...
제가 가장 중요하게 생각하는 출력 라인은 p90이 아닙니다. 바쁜 버스트 시간대의 패스율(pass rate)입니다. 09:00에 95%를 통과하고 16:00에 50%를 통과하는 레인은 72%의 레인이 아니라, 강력한 스케줄링 제약 조건(hard scheduling constraint)을 가진 레인이며, 그렇게 취급해야 합니다.
4. 각 레인을 트레이드오프 테이블에 배치하기
3일치 데이터를 확보하면, 의사 결정은 보통 속도에 관한 것이 아니라 실패의 형태(shape of the failure)에 관한 것이 됩니다. 이 표는 측정값이 들어온 후 제가 적용하는 프레임워크입니다.
| 최대 부하 시간대의 신호 | 무료 호스팅 모델 액세스 | 무료 서버 + 사용 런타임 | 유료 호스팅 | 자체 보유 하드웨어에 셀프 호스팅 |
|---|
| 테일 레이턴시 (Tail latency) | 공유 부하에 따라 변동됨 | 워밍업 후에는 예측 가능하지만, 콜드 스타트는 사용자가 책임짐 | 보통 비용을 지불하는 용량으로 평준화됨 | 안정적이며, 자체 장비에 의해 제한됨 |
| ... | | | | |
기준 충족 여부는 느낌이 아닌 규칙으로 명시되어야 합니다. 가장 바쁜 버스트(burst) 시점의 패스율이 90퍼센트 이상을 유지하고 재시도(retries)가 3일 동안 5퍼센트 미만인 경우 무료 호스팅 액세스를 선택하십시오. 동일한 테스트 환경(harness)으로 해당 장비에서 바닥을 청소할 수 있고, 이를 패치해 줄 담당자가 있는 경우에는 무료 서버 옵션을 선택하십시오. 바쁜 시간대의 패스율은 괜찮지만 계약상의 레이턴시 또는 더 높은 동시성(concurrency)이 필요한 경우 유료 호스팅을 이용하십시오. 데이터 경로 자체가 문제가 되는 것이 아니라면 자체 보유 하드웨어에 셀프 호스팅하는 것을 고려하십시오.
MonkeyCode는 모델 액세스와 서버 옵션이라는 두 가지 무료 경로를 모두 광고하고 있기 때문에 여기서 관련성이 높습니다. 이는 하나의 테스트 환경으로 조달 단계를 거치지 않고도 이들을 비교할 수 있다는 의미입니다. 저는 무료 할당량을 영구적인 것이라기보다는 운영자가 진술한 것으로 간주하므로, 스크린샷의 숫자를 신뢰하기보다 테스트를 실행하는 날짜에 현재 약관과 제한 사항을 확인합니다.
공개 고지: 이 기사는 MonkeyCode의 제품 홍보 활동의 일환으로 작성되었습니다.
5. 나중에 논쟁하기보다 졸업(이동) 트리거를 설정하라
결정 가이드는 일회성일 때 실패합니다. 시작하기 전에 트리거를 기록하십시오: 만약 근무일 중 3일 중 2일 동안 바쁜 버스트 패스율이 80퍼센트 미만으로 떨어지거나, 재시도가 10퍼센트를 초과하면 영향을 받는 태스크 클래스를 한 단계 이동시키십시오. 이 트리거는 선택을 되돌릴 수 있게 만들고 논쟁의 초점을 선호도보다는 데이터에 맞춥니다.
그런 다음 카운터 테스트를 다시 실행하십시오. 한 가지만 변경하고, 2일 기다린 후 같은 시간대에 동일한 버스트를 재실행합니다. 패스율이 변하지 않는다면, 원래 사용하던 단계가 문제가 아니었으며, 마이그레이션(migration)을 막은 것입니다.
이 테스트가 잘못된 도구인 경우
소규모 샘플은 신뢰하기 어려우며, 이 설계는 버스트당 8번의 시도를 사용합니다. 이는 심각한 스케줄링 문제를 포착하기에는 충분하지만 p99를 증명하기에는 부족합니다. 만약 엄격한 지연 시간 SLO(Service Level Objective)가 있거나, 네트워크 외부로 나갈 수 없는 규제 대상 데이터가 있거나, 하루에 40분짜리 생성 작업 부하가 있다면, 버스트 통계는 도움이 되지 않을 것이며 온프레미스 환경이나 로컬 박스가 도움을 줄 것입니다.
무료 서버 레인 역시 누군가가 유지보수를 담당한다는 가정을 전제로 합니다. 만약 아무도 맡지 않는다면, 그 장비는 분기 내에 패치되지 않은 미스터리가 됩니다. 그리고 어떤 무료 등급도 약속(commitment)이 아니므로, 모든 측정은 용량 계획이 아니라 만료일이 있는 스냅샷으로 간주해야 합니다.
만약 비용을 지출하기 전에 테스트 환경(harness)을 실행하고 싶다면, 두 개의 무료 레인이 시작하기에 합리적인 장소입니다. 그리고 가져갈 수 있는 유용한 것은 판결문보다는 자체 버스트 테이블일 것입니다.