AI 모델 서빙

Model artifact(모델 실행 자료): 가중치·tokenizer·config 등 특정 model을 재현 가능하게 실행하는 파일 묶음입니다.

Model artifact는 가중치 파일만 뜻하지 않습니다. tokenizer, configuration, chat template와 필요한 전처리 규칙까지 함께 있어야 같은 입력을 같은 token과 tensor로 바꿉니다. runtime image와 driver 조합도 실행 결과와 지원 형식에 영향을 줍니다.

Triton model repository는 model 이름 아래 숫자 version 디렉터리와 설정을 연결합니다. server가 실행되어도 특정 backend가 model을 읽지 못하면 해당 model은 ready가 아닙니다. vLLM의 API 호환성 역시 모든 model이 같은 기능과 template를 지원한다는 뜻은 아닙니다.

fixture에서 model 1은 ready이고 model 2는 tokenizer 파일 누락으로 로드 실패했습니다. server live가 200이라는 이유로 model 2로 traffic을 옮기면 실제 요청이 실패합니다. 배포 manifest에는 파일 checksum과 runtime image digest를 함께 보존해야 합니다.

아래 fixture에서 live 성공과 model ready 실패가 함께 나타납니다. traffic 전환 여부와 다음에 읽을 load log를 결정합니다.

왜 이런가

Triton model repository는 model 이름 아래 숫자 version 디렉터리와 설정을 연결합니다. server가 실행되어도 특정 backend가 model을 읽지 못하면 해당 model은 ready가 아닙니다. vLLM의 API 호환성 역시 모든 model이 같은 기능과 template를 지원한다는 뜻은 아닙니다.

언제 문제가 되는가

digest 불일치·model load 실패 조건이면 진행 근거가 부족합니다.

초보자가 자주 하는 오해

model remote code를 검토 없이 실행하거나 mutable tag만으로 배포를 재현했다고 기록하지 않습니다. 본문의 HTTP code는 fixture이며 실패 code는 구현·버전에 따라 확인합니다.

직접 확인하는 방법

가중치·tokenizer·config checksum을 release manifest와 대조합니다. runtime image digest·backend와 GPU 지원 범위를 기록합니다.

API boundary(API 접근 경계): 호출자의 신원·권한·입력 범위와 자원 사용량을 검사하는 지점입니다.

추론 endpoint는 GPU 자원뿐 아니라 사용자 입력과 출력에 접근하는 경계입니다. TLS는 전송 보호, 인증은 호출자 식별, 권한 검사는 model 사용 범위를 다룹니다. 이 중 하나의 성공이 나머지를 대신하지 않습니다.

gateway는 인증·요청 크기·rate limit을 검사하고 runtime은 model 입력 형식과 생성 한도를 검증합니다. readiness를 통과한 replica에만 traffic을 보내며 종료 시에는 새 요청을 막고 진행 중인 요청을 정리해야 합니다. streaming은 연결이 열린 뒤의 오류와 취소도 따로 기록합니다.

예제에서는 무인증 요청 401, 입력 한도 초과 413, 인증된 정상 요청 200을 기대합니다. 내부 runtime이 gateway를 우회해 공개되면 gateway의 인증과 제한이 무력해집니다. 따라서 허용 경로와 금지 경로를 둘 다 시험합니다.

교육용 접근 시험 기록에서 무인증 우회가 있는지 판독합니다. token을 직접 발급하거나 외부 API를 호출하지 않습니다.

왜 이런가

gateway는 인증·요청 크기·rate limit을 검사하고 runtime은 model 입력 형식과 생성 한도를 검증합니다. readiness를 통과한 replica에만 traffic을 보내며 종료 시에는 새 요청을 막고 진행 중인 요청을 정리해야 합니다. streaming은 연결이 열린 뒤의 오류와 취소도 따로 기록합니다.

언제 문제가 되는가

인증 우회·입력 원문 log·무제한 요청 조건이면 진행 근거가 부족합니다.

초보자가 자주 하는 오해

API key를 브라우저 bundle·명령행 예제·ticket에 넣지 않습니다. 실제 입력 원문과 Authorization header를 기본 log로 수집하지 않습니다.

직접 확인하는 방법

인증 issuer·권한 범위·token 수명을 확인합니다. body 크기·입력 token·출력 token·동시성 상한을 분리합니다.

TTFT(Time To First Token, 첫 token까지의 시간): 요청을 시작한 뒤 첫 출력 token을 받을 때까지 걸린 시간입니다.

Time To First Token(TTFT, 첫 token까지의 시간)은 대기와 prefill 영향을 받고, Time Per Output Token(TPOT, 출력 token당 시간)은 decode 구간을 설명합니다. 전체 token/s가 높아도 개별 사용자가 긴 대기를 겪을 수 있으므로 지표 하나로 capacity를 승인하지 않습니다.

동시 요청이 늘면 batch 효율이 좋아질 수 있지만 KV cache와 queue도 커집니다. 입력 길이·출력 길이·cache hit·정밀도와 model digest를 고정하지 않으면 서로 다른 일을 비교하게 됩니다. warmup과 측정 구간도 분리해야 합니다.

학습용 2,048 input·256 output token 부하에서 동시성 4의 p95 TTFT는 0.7초, 16은 2.8초입니다. 목표가 1초 이하라면 두 번째 구성은 총 throughput이 높아도 승인하지 않습니다. 이 수치는 성능 예측값이 아니라 판단 연습을 위한 fixture입니다.

아래 고정 fixture에서 1초 TTFT 목표를 만족하는 후보를 고르고 추가 시험을 적습니다. 실제 부하를 발생시키지 않습니다.

왜 이런가

동시 요청이 늘면 batch 효율이 좋아질 수 있지만 KV cache와 queue도 커집니다. 입력 길이·출력 길이·cache hit·정밀도와 model digest를 고정하지 않으면 서로 다른 일을 비교하게 됩니다. warmup과 측정 구간도 분리해야 합니다.

언제 문제가 되는가

TTFT 목표 초과·OOM·취소 증가 조건이면 진행 근거가 부족합니다.

초보자가 자주 하는 오해

TPOT 계산은 출력 token 수와 집계 정의를 명시합니다. 첫 token 하나만 나온 요청은 같은 방식으로 나눌 수 없습니다. 실제 측정 전 capacity는 미확인입니다.

직접 확인하는 방법

model·runtime digest와 hardware·precision을 고정합니다. 입력·출력 길이 분포와 warmup·측정 시간을 기록합니다.