LLM 추론의 효율 프런티어: 트레이드오프 조절 vs 프런티어 확장

TL;DR Highlight

추론 기법은 지연-처리량 곡선 위를 옮기거나, 곡선 자체를 밀어낸다

Who Should Read

셀프호스팅 LLM 서빙의 지연시간과 비용 사이에서 어떤 설정부터 손댈지 고민하는 백엔드·MLOps 개발자

Core Mechanics

추론 기법은 두 종류다
- 곡선 위 이동: 지연시간과 처리량(비용을 좌우) 중 하나를 주고 하나를 얻는 기법이다.
- 곡선 확장: 곡선 전체를 밀어내서 쓸 수 있는 효율 자체를 늘리는 기법이다.
배치 크기는 가장 단순한 다이얼이다
- 배치가 작으면 사용자별 지연은 좋지만 GPU당 토큰이 적어 토큰당 비용이 높다.
- 배치를 키우면 사용자별 지연은 나빠지고 전체 처리량은 좋아져 비용이 내려간다.
병렬화 방식에 따라 성격이 갈린다
- 지연이 중요하면 Tensor Parallelism(TP, 모델을 GPU에 쪼개 얹기)을 늘린다. NVLink가 빨라서 통신 비용을 감당한다.
- Expert Parallelism(EP) 정도가 낮으면 지연에, 랙 전체에 펼치는 wide EP는 처리량에 유리하다.
- Attention Data Parallelism(ADP)은 어텐션 레이어를 복제해 처리량을 올리는 대신 요청별 속도를 내준다.
양자화는 곡선을 밀어내지만 품질과 거래한다
- 가중치·활성값·KV cache 정밀도를 낮추면 지연과 처리량이 모두 좋아진다.
- MXFP4, NVFP4 같은 microscaling 부동소수점 포맷에서는 품질 손실이 거의 없이 큰 효율 개선이 가능하다.
곡선은 매끄럽지 않고 들쭉날쭉하다
- 작은 설정 변경이 큰 차이를 만들고, 그 경계는 직관적이지 않다.

Community Reactions

셀프호스팅 경험상 저가 하드웨어에서도 같은 기법이 중요했다는 경험
- 파이프라인 병렬, RAM 캐싱, speculative decoding(도메인별 n-gram 포함), Q5-Q6 지원, FP8 컨텍스트, paged attention, prefix caching이 핵심이었다는 댓글이다.
- llama.cpp는 긴 컨텍스트 prefill 때 decode가 5 tok/s 수준으로 느려지고, vLLM/SGLang은 비표준 구성에서 불안정했다는 경험이다.
P/D 분리가 다음 큰 흐름일 것이라는 의견
- prefill은 연산 병목, decode는 메모리 병목이라 노드 종류를 달리 쓸 수 있다는 댓글이다.
- 2026년에 spec-dec이 주요 오픈소스 엔진에 채택되며 성숙했다는 의견도 있었다.
용어와 분석 틀이 아쉽다는 반론
- 이것은 파레토 프런티어이고 '효율적 프런티어'는 투자 포트폴리오 이론 용어라는 지적이다.
- 품질이 세 번째 축인데 깊게 다루지 않았고, 들쭉날쭉한 곡선이라 맞춤 벤치마크가 필요하다는 의견이다.
- 첫 문장은 어디에나 붙는 동어반복이라는 비판도 있었다.
기법 자체는 몇 년째 새롭지 않다는 의견
- 정밀도가 낮아지고 spec decoding 수락률이 좋아졌을 뿐 새 개념은 오래 없었다는 댓글이다.
- 가장 큰 효율 개선은 아키텍처 설계 단계에서 나온다는 주장이다.

How to Apply

지금 서빙 설정을 두 칸으로 분류하기
- 오늘 쓰는 vLLM·SGLang 등의 설정을 '곡선 위 이동'과 '곡선 확장'으로 나눠 표로 적는다.
- 아래 코드 예제의 프롬프트에 현재 설정과 트래픽 특성을 넣어 분류를 받아 본다.
배치 크기를 스윕해 우리 곡선 그리기
- 배치 크기를 여러 값으로 바꿔 사용자별 tok/s와 GPU당 총 tok/s를 함께 기록한다.
- 급격히 꺾이는 지점을 찾아 SLA에 맞는 점을 고른다.
양자화 후보를 품질 벤치와 함께 비교하기
- NVFP4 같은 저정밀 포맷을 켜고 우리 태스크 평가셋으로 품질 하락을 측정한다.
- 품질 손실이 허용 범위면 지연과 처리량 이득을 그대로 가져간다.
코드 생성 트래픽이면 speculative decoding 켜 보기
- 출력이 예측 가능한 워크로드에 EAGLE-3 등을 활성화해 tok/s 변화를 비교한다.
- 최대 배치 크기가 줄어드는지도 함께 확인한다.

Try It

복사해서 바로 해보기

# Claude·ChatGPT에 붙여넣기 (원문 분류 틀을 프롬프트로 옮긴 간이 버전)

나는 LLM 추론 서빙을 최적화하려고 한다. 아래 분류 기준을 쓴다.
- 곡선 위 이동(트레이드오프): 배치 크기, 병렬화 전략(TP/EP/ADP), 양자화(품질과 거래)
- 곡선 확장: 커널·런타임 최적화, speculative decoding, P/D disaggregation

내 환경:
- 모델: {{모델명}}
- GPU: {{GPU 종류와 수}}
- 서빙 엔진: {{vLLM/SGLang 등}}
- 트래픽 특성: {{예: 코딩 에이전트, 입력 길이, 출력 길이, 캐시 적중률}}
- 현재 설정: {{배치 크기, 병렬화, 정밀도 등}}
- 목표: {{지연 우선 / 비용 우선}}

요청:
1. 내 현재 설정을 위 두 분류로 나눠 표로 정리해라.
2. 아직 안 쓴 기법 중 효과가 클 것 같은 순서를 이유와 함께 말해라.
3. 각 기법을 검증할 스윕 실험(바꿀 변수, 측정 지표)을 설계해라.

이어서 해 볼 것: 스윕 결과를 붙여 주고 곡선이 꺾이는 지점을 해석해 달라고 요청해 보자.

Terminology

efficient frontier두 목표(예: 지연과 처리량)를 맞바꿀 때 얻을 수 있는 최선의 조합을 이은 곡선이다. 곡선 안쪽은 아직 개선 여지가 있는 설정이다.

continuous batching요청을 토큰 단위로 계속 끼워 넣어 배치를 기다리는 시간을 없애는 방식이다. 식당에서 자리 나는 대로 손님을 앉히는 것과 같다.

Tensor Parallelism(TP)한 레이어의 연산을 여러 GPU에 쪼개 나눠 계산하는 방식이다. 통신이 많아 빠른 NVLink가 필요하다.

speculative decoding다음 토큰을 먼저 추측해 두고 모델이 한꺼번에 검증해 빠르게 생성하는 기법이다. 예측 가능한 코드 출력에서 특히 잘 맞는다.

P/D disaggregation입력을 읽는 prefill과 토큰을 생성하는 decode를 별도 워커에서 돌리는 구조다. 주방에서 재료 손질과 조리를 분업하는 것과 비슷하다.

NVFP44비트 microscaling 부동소수점 포맷으로, 품질 손실을 거의 없이 서빙 효율을 크게 높일 수 있는 양자화 방식이다.