우리 LLM 서빙 실측: 처리량과 지연의 교차검증

우리 LLM 서빙 실측: 처리량과 지연의 교차검증는 우리 ai-server(Hax) 스택에서 직접 측정한 운영 수치를, 숫자 나열이 아니라 그 수치가 실제 의사결정에 어떤 뜻인지까지 풀어 설명하는 실측 회고다. 로컬 AI를 처음 다루는 독자라도 이 글 하나로 '이 숫자를 보고 무엇을 결정하면 되는가'를 5분 안에 잡을 수 있게 구성했다.

이 수치가 의미하는 것#

200토큰 전체 생성 지연 5153ms를 처리량으로 환산하면 38.8 tok/s로, 실측 처리량 38.8 tok/s와 정확히 일치한다(교차검증 통과). 이는 큐 대기나 네트워크 지연 오염 없이 순수 생성 속도가 그대로 나온다는 뜻이라, 이 수치를 용량 산정의 기준선으로 신뢰할 수 있다.

어떻게 측정했나 (재현 조건)#

이 수치들은 공개 스펙이나 마케팅 값이 아니라 아래 조건에서 우리가 직접 잰 값이다. 측정 조건을 함께 적는 이유는, 조건이 바뀌면 숫자도 바뀌기 때문이다 — 콜드 스타트인지 워밍업 후인지, 배치 크기가 얼마인지, 어떤 하드웨어인지에 따라 같은 모델도 다른 값을 낸다. 그래서 재현 가능한 조건을 명시한다(측정일 2026-07-04):

• bench_harness.probe_llm_bench (unified-api 실측, 3회 중앙값)

숫자 하나만 외우기보다 이 조건과 함께 이해해야, 여러분의 환경에서 '우리는 왜 다른 값이 나올까'를 스스로 진단할 수 있다.

실전에서 어떻게 쓰나#

위 파생 판단은 곧바로 운영 결정으로 이어진다. 핵심은 원수치를 외우는 게 아니라 수치 사이의 관계를 읽는 것이다 — 두 값의 비율, 사용률, 교차검증 결과가 실제로 '무엇을 늘리고 무엇을 아껴야 하는가'를 가리킨다. 우리는 이 방식으로 새 하드웨어를 사기 전에 현재 여유부터 확인하고, 워크플로를 빠른 경로와 품질 경로로 나눈다. 같은 논리를 여러분의 로컬 AI 셋업에도 그대로 적용할 수 있다.

왜 이게 공개 스펙보다 신뢰할 만한가#

제조사 공개 스펙이나 남의 벤치가 아니라 우리 운영 환경에서 실제로 측정한 값이다. 위 표의 모든 숫자는 측정값이며(추정 아님), 측정 날짜와 출처(Hax /data)를 붙였다. AI가 생성한 일반론과 달리, 이 파생 판단은 실측 없이는 만들 수 없다 — 그게 이 글의 차별점이다. 우리 스택 실측값만 사용했고, 내부 토큰·사설 경로 같은 비공개 정보는 노출하지 않았다.

참고: 위 수치는 측정일 2026-07-04 기준 우리 스택 실측값이며, 조건이 바뀌면 갱신한다(측정값만 사용, 추정 없음).

함께 읽기: 오픈웨이트 vs 클로즈드 LLM, 직접 본 속도·품질·비용, Mistral Small 문서 요약: 지연 실측과 데이터 잔류 정책

재현 (직접 측정해 보기)#

로컬 러너의 처리량(tok/s)·지연을 공개 벤치로 직접 측정:

# llama.cpp — 처리량(tg)·프롬프트 처리(pp≈TTFT 관련)
llama-bench -m your-model.gguf -p 512 -n 200

# 또는 vLLM
vllm bench throughput --model <model> --num-prompts 100 --input-len 512 --output-len 200

우리 실측(unified-api, 3회 중앙값): 생성 처리량 38.8 tok/s·200토큰 지연 5153ms(2026-07-04). 러너·양자화·배치가 값을 좌우하니 조건을 맞춰 비교 — 원수치는 /data.

참고 링크#

• Hax data