- LLM 운영에서 latency와 cost는 함께 움직이며 대부분 토큰 수와 모델 선택에서 결정된다.
- Top-k 축소, context 제한, 모델 분리가 가장 먼저 손대는 최적화 지점이다.
- Embedding과 검색 결과 캐싱은 운영 안정성을 위한 기본 설계다.
LLM 기반 시스템을 처음 만들 때는 보통 이런 고민을 한다. “어떻게 하면 더 똑똑하게 만들까?”
하지만 운영 단계에 들어가면 질문이 완전히 바뀐다. “왜 이렇게 느리지?”, “왜 비용이 이렇게 나오지?”
이 글은 운영 환경에서 실제로 가장 많이 조정하게 되는 포인트들에 대한 이야기다.
Latency와 Cost는 항상 함께 움직인다
LLM 시스템에서 응답이 느리면 비용도 높고, 비용을 줄이면 응답 품질이 흔들리는 경우가 많다. 그래서 대부분의 설계는 트레이드오프의 연속이다.
응답 속도를 늦추는 주요 원인들
운영 환경에서 latency를 증가시키는 요소는 비교적 명확하다.
- 불필요한 RAG 호출
- 과도한 top-k 검색
- 너무 긴 context
- 항상 대형 모델 사용
이 중 하나만 있어도 응답 속도는 체감될 정도로 느려진다.
실제로 가장 먼저 손대는 것들
1. Top-k 줄이기
초기에는 넉넉하게 검색하더라도, 운영 단계에서는 3~5 수준으로 축소하는 경우가 많다. 이렇게 하면 검색 시간과 context 길이가 함께 줄어든다.
2. Context 길이 제한
모든 문서를 다 넣지 않는다. 핵심 chunk만 전달해야 한다. context가 줄어들면 토큰 수가 줄고, 토큰 수가 줄면 비용도 줄어든다.
3. 모델 분리 전략
단순 요약이나 정리는 소형 모델로 처리하고, 복잡한 추론은 대형 모델로 처리한다. 모든 요청에 비싼 모델을 사용하는 구조는 운영 단계에서 비용을 빠르게 키운다.
캐싱은 선택이 아니라 필수다
운영 환경에서는 동일하거나 유사한 질문이 반복된다. 그래서 보통 두 가지를 캐싱한다.
- embedding 결과
- vector DB 검색 결과
이 구조만 잘 잡아도 latency는 눈에 띄게 줄고 비용은 안정화된다.
완벽한 답변보다 예측 가능한 시스템
운영 환경에서 중요한 것은 항상 최고의 답변이 아니라 항상 예측 가능한 응답이다.
언제 느려지는지, 언제 비용이 늘어나는지, 어떤 질문이 위험한지를 알고 통제할 수 있어야 한다.
정리하며
Latency와 비용은 기술 문제가 아니라 설계 문제인 경우가 대부분이다. 이 균형을 어떻게 잡느냐가 AI 시스템을 데모에서 서비스로 바꾼다.