서진호

3 분 소요

세번째 추론 엔지니어링에 투자헤야 시점은 언제일까? 이러한 추론 최적화 기술을 실제 운영 환경에 적용하는 것은 상당한 작업이다. 여러 최적화 기술을 함께 결합하면 시스템 복잡성은 더욱 증가한다. 따라서 모든 엔지니어링 팀이 반드시 고민해야 하는 질문은 다음과 같다.

직접 추론 인프라를 구축하고 운영하는 것이 필요한가, 아니면 기존의 상용 API를 계속 사용하는 것이 더 적합한가?

이에 대한 답은 제품이 현재 어느 단계에 있는지에 따라 달라진다.

1. 초기 AI 제품 개발 단계

AI 제품을 처음 구축하는 초기 단계에서는 대부분의 경우 기존 AI 제공 업체가 제공하는 API를 사용하는 것이 가장 적합하다. 의미 있는 최적화를 수행하려면 실제 운영상의 제약 조건이 필요하다하지만 초기 단계의 제품은 일반적으로 다음과 같은 요소가 명확하지 않다.

  • 실제 사용자 트래픽 패턴(traffic pattern)
  • 필요한 지연 시간(latency requirement)
  • 요청 단위 비용(unit economics)

이 단계에서 엔지니어링 자원은 제품 기능 개발과 시장 검증에 집중하는 것이 더 효율적이다. 직접 추론 스택을 운영하는 것은 시스템 복잡성을 증가시키고, 빠른 반복 개발을 방해할 수 있다. 초기 제품 단계에서는 빠른 개선과 출시 속도가 가장 중요한 요소이기 때문이다.

2. 추론 엔지니어링으로 전환해야 하는 세 가지 신호

일반적으로 다음 세 가지 상황이 발생하면 기존 API 사용 방식에서 자체 추론 환경 구축으로 전환하는 것을 고려해야 한다.

3. 양자화(Quantization)

책의 60% 정도를 위키독스에 공개할 예정이다. 내용이 어떻게 구성되었는 지 궁금한 독자라면 아래의 주소로 방문하면 무료로 볼 수 있다.

1) API 비용 증가

API 사용 비용이 제품 운영 비용에서 중요한 비중을 차지하기 시작한 경우이다. 사용량이 증가하면 토큰 기반 과금(token-based pricing)은 빠르게 증가한다. 특히 대규모 사용자 기반을 가진 서비스에서는 자체 모델 운영 비용이 API 비용보다 낮아질 수 있다.

2) 지연 시간 요구 사항 증가

제품에서 요구하는 응답 속도가 폐쇄형 API가 제공할 수 있는 수준을 넘어선 경우이다. 예를 들어, 실시간 코드 자동 완성(code completion), 음성 인터페이스, 실시간 에이전트 같은 서비스는 일반적인 API 응답 시간보다 훨씬 낮은 지연 시간을 요구한다. 이 경우 기업은 모델 선택, GPU 구성, 배칭 정책, KV 캐시 관리 등을 직접 제어해야 한다.

3) 안정성 요구 증가

서비스 안정성 요구 수준이 공급 업체의 SLA(Service Level Agreement)를 초과하기 시작한 경우이다. 기업이 자체 서비스 수준 목표(Service Level Objective, SLO)를 유지해야 한다면, 외부 API 의존성은 제한 요소가 될 수 있다. 전용 GPU 환경과 자체 추론 스택을 구축하면 장애 대응, 용량 계획(capacity planning), 성능 조정을 직접 수행할 수 있다.

4. 커서 사례

커서는 이러한 전환을 효과적으로 수행한 대표적인 사례이다. 커서 제품의 핵심 가치는 초 단위 이하의 자동 완성 지연 시간이다. 하지만 폐쇄형 API는 여러 고객을 대상으로 일반적인 처리량을 최적화한다.

반면 코드 자동 완성 모델은 특정한 형태의 빠른 응답 속도가 필요하다. 커서는 오픈 모델을 자체 운영하고 전체 스택에 추론 엔지니어링을 적용했다. 그 결과 요구되는 낮은 지연 시간 목표를 달성할 수 있었다. 이러한 투자는 실제 성능 제약 조건이 존재했고, 워크로드 특성을 명확하게 이해하고 있었기 때문에 효과를 얻을 수 있었다.

5. 결론

LLM 추론은 서로 반대되는 물리적 제약을 가진 두 가지 연산으로 구성된다. Prefill은 연산 중심이며 요청마다 한 번 실행된다.Decode는 메모리 대역폭 중심이며 생성되는 각 토큰마다 실행된다.

추론 엔지니어링에서 사용되는 대부분의 최적화 기술은 이러한 구조적 차이에서 출발한다.이 구조를 이해하면 추론 엔지니어링 분야 전체를 훨씬 쉽게 이해할 수 있다.

이 모든 기술 위에는 하나의 중요한 의사 결정 문제가 존재한다. 바로 직접 구축할 것인지(build), 아니면 외부 서비스를 사용할 것인지(buy)에 대한 판단이다.

초기 단계의 대부분 제품에서는 상용 API가 여전히 가장 적합한 선택이다.

하지만 다음 상황에서는 자체 호스팅(self-hosting)이 의미를 갖기 시작한다.

  • API 비용이 실제 운영 비용의 중요한 부분이 되었을 때
  • 필요한 지연 시간이 폐쇄형 API가 제공하는 수준을 넘어섰을 때
  • 서비스 안정성 요구가 공급 업체 SLA 수준을 초과했을 때

이 시점부터 추론 엔지니어링은 비용 절감 기술이 아니라 제품 경쟁력을 결정하는 핵심 엔지니어링 영역이 된다.

6. Prefill과 Decode 관점에서 본 주요 최적화 기술

지금까지 설명한 각 기술은 모두 Prefill과 Decode 구조 안에서 설명할 수 있다.

용어 설명
배칭 사용자별 지연 시간(per-user latency)을 희생하여 전체 처리량을 증가시킨다.
Prefix Caching 프롬프트 앞부분(prefix)이 동일한 경우 Prefill 계산량을 줄인다.
양자화 모델 가중치를 압축하여 Prefill과 Decode 두 단계 모두의 효율을 향상시킨다.
추측 디코딩 GPU의 유휴 연산 자원을 활용하여 Decode 과정에서 더 많은 토큰을 생성한다.
병렬 처리 멀티 GPU를 활용하여 대규모 모델을 확장한다.
분리(Disaggregation) Prefill과 Decode를 서로 다른 하드웨어 환경에서 실행한다.

댓글남기기