AXCOBPRODUCT
COMPANY홈
프로젝트 문의

AXCOB LABLLM SERVING WORKLOAD REVIEW

고객이 먼저 발견하기 전에,
서빙의 한계를 찾습니다.

요청이 길어지고 동시에 몰릴 때, 처리량과 첫 응답은 어떻게 바뀔까요? GPU 실측과 요청 로그 분석을 바탕으로 라우팅과 요청 수용 기준을 검토합니다.

리뷰 시작하기 연구 원문 보기

비식별 요청 로그로 시작 · 검토 범위와 일정은 환경 확인 후 협의

MEASURED / 2026.05.12CONCURRENCY 16
40.1sP99 TIME TO FIRST TOKEN

H100 SXM5 · LLAMA 3.1 70B FP8
VLLM 0.19.1 · INPUT 8K · SYNTHETIC n=30

01 / MEASURED EVIDENCE

감이 아니라
측정으로 시작합니다.

2026년 5월 12~13일, H100 SXM5와 Llama 3.1 70B FP8, vLLM 0.19.1에서 합성 부하를 측정했습니다. 핵심 동시성 조건은 각각 3회 재측정했습니다.
A

THROUGHPUT / C4 → C16

83.05 → 83.20tokens per second

Spheron의 입력 8K 조건에서 설정 동시성을 4에서 16으로 늘렸을 때, 출력 처리량 증가는 약 0.2%였습니다.

B

P99 TTFT / C4 → C16

4.6s → 40.1s약 8.7배 · 조건별 요청 30건

같은 실험에서 첫 토큰까지 P99 대기시간이 늘었습니다. 소표본에서 관찰한 예비 결과로, 고객 환경의 성능 보장값은 아닙니다.

C

MIXED WORKLOAD

4.3x / 1.08x혼합 부하 비교 · 예비 결과

짧은 요청의 P99 악화는 Spheron과 Lambda에서 달랐습니다. 긴 요청 표본도 각각 20건과 100건으로 달라 추가 검증이 필요합니다.

CROSS-PROVIDER REPLICATION

5월 13일 Lambda의 서버를 재시작한 뒤, 입력 8K·동시성 4와 16에서 유사한 지연 증가를 관찰했습니다. 두 공급자의 특정 구성에서 확인한 결과이며, 혼합 부하와 장시간 운영 시 차이의 원인은 아직 규명하지 않았습니다.

재현 노트와 원본 데이터

REVIEW PIPELINE

로그에서 정책까지,
판단 경로를 남깁니다.

  1. 01INGEST

    비식별 요청 로그의 형식과 누락을 확인합니다.

  2. 02BUCKET

    입력 길이와 동시성별로 워크로드를 나눕니다.

  3. 03COMPARE

    참조 실측과 비교하고, 추가 GPU 측정이 필요한 범위를 찾습니다.

  4. 04POLICY

    확인된 근거와 가정을 나눠 라우팅·요청 수용 기준을 제안합니다.

평균 처리량은 대시보드가 보여줍니다.

P99는 고객이 느낍니다.

P99는 응답이 느린 요청의 대기시간을 보여줍니다. 긴 요청이 섞이거나 동시성이 높아질 때, 평균 처리량과 함께 확인해야 합니다.

02 / WHAT YOU SEND

파일 하나.
프롬프트는 필요 없습니다.

CSV 또는 JSONL의 비식별 요청 기록으로 분석 범위를 정합니다. 대표 트래픽 24시간분을 권장하며, 초기 검토에는 프롬프트 원문과 개인정보가 필요하지 않습니다.
01request_id

해시 처리한 고유 식별자도 괜찮습니다.

02timestamp

ISO 8601 또는 Unix epoch. UTC를 권장합니다.

03input_tokens

토큰화된 입력 길이. 추정값도 가능합니다.

04output_tokens

토큰화된 출력 또는 완료 길이입니다.

05status

success, error, timeout 또는 같은 의미의 상태값입니다.

06latency_ms

종단 지연 시간. TTFT와 TPOT는 선택입니다.

토큰 수가 없다면 기록 가능한 길이 정보부터 확인합니다. 추정값은 실측값과 구분하고, GPU 재측정 조건은 별도로 정합니다.

03 / WHAT YOU RECEIVE

측정의 근거를,
운영의 기준으로.

환경과 로그를 확인한 뒤, 필요한 분석과 추가 실측 범위에 맞춰 결과물을 정합니다.
01

운영 경계 리포트

입력 길이·동시성별 처리량과 지연을 정리하고, 참조 실측으로 비교할 수 있는 범위와 추가 측정이 필요한 범위를 구분합니다.

MATCH / COVERAGE / SOURCE
02

라우팅·요청 수용 정책

확인된 조건을 바탕으로 대화형·비동기 처리 경로, 동시성 상한과 입력 길이 기준을 검토 가능한 정책으로 정리합니다.

ROUTING / CONCURRENCY / JSON
03

추가 측정·비용 검토

목표 응답시간과 GPU 비용 가정을 확인하고, 혼합 부하·서버 가동시간 등 실제 환경에서 다시 검증할 조건을 제안합니다.

LATENCY / COST / MEASUREMENT PLAN

04 / OPEN RESEARCH

측정값부터 분석 코드까지,
근거를 확인하세요.

2026년 5월의 실험 방법, 원본 벤치마크 JSON, 실행 로그와 분석 스크립트를 공개했습니다. 운영 경계·비용·정책을 산출한 과정과 실험의 한계를 함께 확인할 수 있습니다.

github.com/jacob-sunho-kim/llm-boundary-research 공개 저장소 확인: 2026.09.15 · 마지막 갱신: 2026.05.13 · 코드 MIT · 연구 자료 CC-BY-4.0
THE HONEST PART

모르는 범위는
모른다고 표시합니다.

참조 결과는 H100 SXM5의 특정 모델·양자화·서빙 버전에서 얻은 합성 부하 실측입니다. GPU나 모델, 실제 요청 구성이 달라지면 다시 측정해야 합니다. 로그 비교, GPU 실측, 비용 가정에서 계산한 추정치를 구분해 설명합니다.

START A REVIEW

우리 서비스의 경계,
함께 확인합니다.

서빙 환경과 현재 문제를 알려주시면 검토 범위·일정부터 정합니다.
리뷰 요청 메일 작성 초기 검토: 비식별 요청 기록 · 모델·GPU·서빙 스택 · 목표 응답시간

측정일 2026.05.12~13 · 내용 확인 2026.09.15. 처리량 약 0.2% 증가와 P99 약 8.7배는 Spheron의 입력 8K·설정 동시성 4/16·조건별 합성 요청 30건에서 계산했습니다. FP8 KV와 prefix cache를 사용했으며, 실제 고객 트래픽과 다른 GPU·서빙 버전의 결과는 별도 측정이 필요합니다.