pile·
AI / ML·스캐터랩스캐터랩 (이루다)·

새로운 루다를 지탱하는 모델 서빙 아키텍처 — 3편: 안정적인 LLM 서비스를 위한 서빙 최적화 기법

루다를 지탱하는 모델 서빙 아키텍처 3편으로, LLM 서빙 비용을 낮추기 위한 최적화 기법과 CPU/GPU/IPU 서빙 방법론, 부하테스트로 서빙 비용을 산정하는 법을 정리한다. 비용이 생성 AI의 최대 난제라는 전제에서 출발한다.

핵심 포인트
  • 커널 퓨전·early stopping·KV caching·Flash Attention으로 연산·메모리 오버헤드를 줄인다.
  • Dynamic Batching은 GPU Tensor Core 사용률을 높이지만 시퀀스 길이 편차·대기 지연 문제가 있고, FriendliAI의 Iteration Batching(특허 US-11442775-B1)이 이를 개선한다.
  • 서빙은 CPU·GPU·IPU/NPU로 나뉘며, GPU는 A100·A10·L4 등이 적합하고 T4 이하는 부적합하다.
  • 비용은 부하테스트로 Latency-RPS 그래프를 그려 목표 레이턴시의 처리량을 구하고, 필요 인스턴스 수 x 시간당 비용으로 산정한다.
  • Orca(Periflow)는 1000ms 제약에서 DeepSpeed보다 25배 이상 RPS를 냈다.
상세 정리
  • 커널 퓨전: MatMul 후 Add를 하나의 커널로 합쳐 중간 결과 저장·재로드 오버헤드를 제거한다. TensorRT가 자동 지원하고 CUDA C++로 직접 작성도 가능하다.
  • Early stopping: EOS 토큰 생성 시 토큰 생성을 중단한다. 커널 퓨전과 함께 쓰면 매 토큰 종료 검사·분기가 필요해 복잡하며, 동적 그래프 프레임워크나 커스텀 커널에서 쓴다.
  • KV caching: 자기회귀 특성상 과거 Context의 Key/Value는 안 변하므로 캐싱해 재사용한다. HuggingFace는 use_cache=True로 켠다.
  • Flash Attention: IO-aware 어텐션으로 메모리 처리량 병목을 해소해 기존 대비 약 2배 이상 레이턴시를 줄이며 성능 손실이 없다. FasterTransformer·Composer 등에서 쓴다.
  • Dynamic Batching: 시차 요청을 묶어 Tensor Core 활용률을 높이나 배치가 크면 레이턴시가 는다. 길이 10과 256이 한 배치면 패딩·마스크로 비효율이 생기고, 대기 초과 시 수 초 지연이 난다. Triton·TF Serving 핵심 기능이다.
  • Iteration Batching: FriendliAI의 iteration-level scheduling으로, 출력 토큰마다 새 요청 수신을 확인해 즉시 배치에 넣고 완료 요청은 바로 반환한다. 단 특허(US-11442775-B1)라 타사가 직접 구현할 수 없다.
  • CPU 서빙: GPU 수급난·저요구 상황용이다. FastAPI로 REST를 노출하고 PyTorch JIT·BetterTransformer·Intel Extension으로 성능을 올린다.
  • GPU 서빙: Ampere(A100/A10/A40)·Ada Lovelace(L4/L40)·Turing(RTX A6000)이 적합하고 T4 이하는 부적합하다. FasterTransformer(CUDA C++)를 Triton으로 배포해 dynamic batching·모델 병렬을 지원한다. FriendliAI Periflow는 FasterTransformer 대비 5~6배 처리량이나 라이센스 비용이 든다.
  • IPU/NPU 서빙: AWS Inferentia는 Neuron으로 컴파일하고 FLOP당 가격이 약 1/3이다. Inferentia2는 동적 그래프·175B 분산 추론을 지원하나 3B 이상에서 성능·생성 옵션이 미흡하다. Google TPU는 XLA·JAX 기반이나 공개 정보가 제한적이며, 리벨리온·하이퍼엑셀·Cerebras·GraphCore도 개발 중이다.
  • 부하테스트: RPS를 고정하고 그 RPS의 레이턴시를 측정한다. 지수분포(λ=RPS)로 요청을 시뮬레이션하고, Locust로 사용자 수를 천천히 늘리며 RPS별 레이턴시를 기록하되 요청 간격을 랜덤화해 몰림을 막는다.
  • 비용 산정: 단일 서버 Latency-RPS 그래프 → 목표 레이턴시의 처리량 → 목표 처리량/단일 처리량 = 인스턴스 수 → x 시간당 비용.
  • 마무리: vLLM(PagedAttention으로 HuggingFace 대비 24배)·Smooth Quantization 같은 신기법이 등장했고, 다음 편은 vLLM을 다룰 예정이다.
왜 읽나LLM 서빙 비용·지연을 줄이려는 ML 엔지니어에게 최적화 기법·하드웨어 선택·부하테스트 기반 비용 산정을 한눈에 정리한 레퍼런스.
스캐터랩
스캐터랩 (이루다) 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. AI / ML·LY CorporationLY Corporation·

    Grafana에서 자연어로 장애 원인을 분석하기: LLM 에이전트 기반 SRELens 개발기

    LY Corporation Home SRE 팀이 장애 분석 시 메트릭·로그·트레이스가 각각 다른 화면에 흩어져 있는 문제를 해결하기 위해 Grafana 플러그인 SRELens를 개발했다. SRELens는 LLM 에이전트가 자연어 질의를 받아 실제 관측성 데이터를 조회하고, 근거와 함께 장애 원인 후보를 정리해 주는 도구다. LGTM-P 스택(Loki·Grafana·Tempo·Mimir·Pyroscope)과 FlavaMCP 게이트웨이를 통합해 단일 채팅 인터페이스에서 멀티시그널 분석이 가능하다.

    #llm-app#mcp#observability+2