LLM 비용·지연시간·정확도, 세 축을 동시에 잡을 수 없을 때 어떻게 결정할 것인가

LLM을 서비스에 붙이기로 했다면, 다음 질문이 곧 현실이 된다. 비싼 최고 성능 모델을 쓸 것인가, 저렴한 경량 모델을 쓸 것인가, 아니면 둘을 섞을 것인가. 이 질문에 "상황에 따라 다르다"고만 답하면 요구사항 단계에서 아무것도 결정되지 않는다.

실제로 결정을 막는 것은 정보 부족이 아니다. 비용, 지연시간, 정확도 세 가지가 동시에 최적화되지 않는다는 구조적 사실을 의사결정 언어로 번역하지 못하는 것이다.

왜 벤치마크 비교로는 충분하지 않은가

모델 선택을 벤치마크 점수로 시작하면 대부분의 프로젝트에서 두 가지 실수 중 하나를 저지른다. 실제로 필요하지 않은 수준의 정확도를 위해 과도한 비용을 지불하거나, 비용을 줄이려다 사용자가 허용하지 않는 응답 품질로 서비스를 출시하는 것이다.

벤치마크는 모델의 이론적 한계를 측정한다. 운영 환경에서 중요한 것은 다르다. 동시 요청 수가 늘어날 때 지연시간이 어떻게 변하는가, 배치 처리 시 토큰당 비용이 어느 수준인가, 특정 도메인 태스크에서 정확도가 실제로 어느 정도 차이 나는가. 이 세 가지는 배포 설정과 트래픽 형태에 따라 같은 모델도 전혀 다른 결과를 낸다.

세 축의 트레이드오프 구조

LLM 추론의 효율 곡선은 비용과 성능 간의 최적 조합이 서비스마다 다르다는 전제에서 출발한다. 추론 엔지니어링 관점에서 이 곡선을 다루는 방법은 두 가지다. 하나는 현재 제약 안에서 특정 지점을 목표로 설정을 조정하는 것이고, 다른 하나는 전체 효율 자체를 끌어올리는 것이다.

배치 크기는 지연시간과 처리량의 교환이다. 동시 처리 요청 수를 늘리면 전체 처리량과 토큰당 비용은 개선된다. 그러나 사용자 한 명이 첫 토큰을 받기까지 걸리는 시간은 길어진다. 배치를 줄이면 반대가 된다. 이것은 설정 값 하나로 움직이는 레버이지만, 그 레버를 어디에 놓을지는 서비스 성격이 결정해야 한다.

병렬 처리 전략은 어디에 GPU를 쓸지의 문제다. 텐서 병렬 처리(TP) 수준을 높이면 지연시간이 줄어든다. 대신 GPU 간 통신 비용이 발생한다. 처리량을 높이려면 주의 계층을 복제하는 어텐션 데이터 병렬 처리(ADP) 방식이 더 적합하다. 하나의 배포에서 두 목표를 동시에 극대화하기 어렵다는 뜻이다.

양자화는 품질과 효율의 교환이다. 모델 가중치와 활성화 값의 수치 정밀도를 낮추면 같은 하드웨어에서 더 많은 요청을 처리할 수 있다. 최신 부동소수점 형식(MXFP4, NVFP4 등)을 활용하면 품질 손실이 크지 않은 지점까지 효율을 끌어올릴 수 있다는 것이 알려져 있다. 단, 이 경계는 모델과 태스크에 따라 불연속적으로 나타나며, 실험 없이 미리 예측하기 어렵다.

서비스 유형별 판단 기준

판단을 구체화하려면 워크로드 유형부터 분류해야 한다. 모든 LLM 요청이 같은 조건에서 실행되지 않기 때문이다.

실시간 인터랙션이 핵심인 서비스 — 사용자가 응답을 기다리며 다음 행동을 결정하는 유형이다. 고객 지원 챗봇, 코드 자동완성, 실시간 문서 어시스턴트가 여기에 해당한다. 이 경우 지연시간이 품질 다음으로 중요한 변수다. 최고 성능 모델을 소형 배치로 운영하거나, 특정 태스크에서 충분한 품질을 입증한 경량 모델을 택하는 것이 현실적이다. 사용자가 지불 의사가 있는 서비스라면 지연시간을 낮추는 데 비용을 더 쓸 수 있다.

비동기 처리가 가능한 파이프라인 — 사용자가 즉각적인 응답을 기다리지 않는 워크로드다. 문서 요약, 대량 분류, 야간 리포트 생성이 대표적이다. 여기서는 처리량과 토큰당 비용이 지배적인 기준이 된다. 배치를 크게 구성하고 더 저렴한 모델로 처리하는 전략이 유리하다. 정확도 요구치를 먼저 정의하고, 그 기준을 통과하는 모델 중 가장 저렴한 것을 선택하는 순서가 맞다.

에이전트·멀티스텝 추론 워크로드 — 단일 응답이 아니라 여러 단계의 추론과 도구 호출이 연결되는 구조다. 각 단계의 오류가 누적되기 때문에 정확도에 대한 민감도가 높다. 동시에 단계마다 비용이 붙으므로 전체 파이프라인 비용도 빠르게 올라간다. 이 유형에서는 모든 단계에 동일한 모델을 사용하는 것보다, 판단이 필요한 핵심 단계에만 고성능 모델을 두고 나머지는 경량 모델로 처리하는 계층화된 설계가 검토할 만한 접근이다.

요구사항 단계에서 먼저 확인할 것들

모델을 선택하기 전에 아래 질문에 숫자로 답할 수 있어야 한다. 정성적인 답이 나온다면 아직 요구사항이 완성되지 않은 것이다.

• 허용 가능한 최대 지연시간은 얼마인가? 첫 토큰 도착까지의 시간(TTFT)과 전체 응답 완료 시간을 구분해서 정의해야 한다.
• 일일 또는 월간 토큰 소모량 예측치가 있는가? 토큰 단가가 같아도 규모에 따라 비용 차이가 수십 배 달라진다.
• 정확도 기준을 태스크 단위로 측정했는가? 전반적인 모델 성능이 아니라 이 서비스의 이 태스크에서 어느 수준이 필요한지를 구체화해야 한다.
• 트래픽 패턴이 균일한가, 급등 구간이 있는가? 피크 트래픽 대응 방식에 따라 배포 전략이 달라진다.

이 네 가지 질문에 대한 답이 없는 상태에서 모델을 결정하면, 프로토타입 이후 단계에서 비용이나 품질 문제로 재설계하게 될 가능성이 높다.

단일 모델 대 혼합 전략

실제 프로덕션 환경에서는 하나의 모델로 모든 요청을 처리하는 것보다, 요청 유형에 따라 모델을 분기하는 방식이 비용 효율을 높이는 경우가 있다. 단순 분류나 포맷 변환처럼 난이도가 낮은 요청은 경량 모델로 처리하고, 복잡한 추론이 필요한 요청만 고성능 모델로 보내는 구조다.

이 전략이 실효성을 갖추려면 두 가지 조건이 충족되어야 한다. 요청을 사전에 난이도로 분류하는 로직이 충분히 신뢰할 수 있어야 하고, 경량 모델의 응답이 해당 유형에서 실제로 허용 품질을 충족해야 한다. 이 두 조건을 실험 없이 가정만으로 진행하면 라우팅 실패나 품질 저하가 운영 중에 드러난다.

혼합 전략을 택할 때는 라우팅 판단 비용과 두 모델 운영의 복잡성도 총비용에 포함해서 평가해야 한다. 단일 모델 대비 실질적인 비용 절감이 이 오버헤드를 상쇄하는지 검증하는 과정이 필요하다.

무엇이 여전히 불확실한가

효율 곡선이 연속적이고 예측 가능하다면 이 결정은 훨씬 쉬울 것이다. 실제로는 설정 변수의 작은 변화가 비선형적 결과를 만들어내는 구간이 존재한다. 양자화 수준, 배치 크기, 병렬 처리 조합이 특정 임계점을 넘으면 지연시간이나 품질이 급격히 변하는 패턴이 있다는 것이 알려져 있지만, 그 임계점은 모델과 배포 환경에 따라 다르며 사전에 계산하기보다 실험으로 찾아야 한다.

이는 요구사항 단계에서 내린 결정이 프로토타입 단계에서 반드시 검증되어야 한다는 뜻이다. 모델 선택과 설정이 실제 트래픽 조건에서 예측대로 작동하는지를 확인하지 않은 채 프로덕션에 진입하는 것은 구조적 위험이다.

---