2025.06 – 현재 · DigitalPresso
RenameDP 셀프호스팅 LLM 서비스
보안 제약 환경을 위한 오픈소스 LLM 추론 서비스 구축
BackendCloudMLOpsAIvLLMXGrammarAWS GPU EC2AWS LambdaCPU EC2Slack APIFastAPI
- 보안 요구 대응
- 외부 LLM API 사용 불가→전용 GPU 인프라에 셀프호스팅
- GPU 운영
- Slack 명령으로 수동 기동·중지→요청 시 자동 기동 (Request-on-Wake)
- 구조화 출력
- 응답 형식 오류 가능→XGrammar 스키마 제약 디코딩
개요
- 보안 요구로 외부 LLM API 사용 불가
- 오픈소스 LLM을 AWS GPU EC2에 직접 서빙, vLLM 추론 서버 구성
- 목표: 응답 형식 안정성 · GPU 비용 · 기동 시간 · 대용량 요청 전달
발전 과정
- 초기: Slack 명령으로 GPU 인스턴스 수동 기동·중지
- 개선: Lambda가 인스턴스 상태 제어, CPU EC2가 요청 보관·중계 (Request-on-Wake)
기술 포스트
- 외부 LLM API 없이 오픈소스 모델을 셀프호스팅한 이유
- vLLM과 XGrammar로 안정적인 추론 API 구성
- Slack 수동 운영에서 Request-on-Wake 구조로 전환
- Lambda 요청 본문 한계를 CPU EC2 게이트웨이로 해결
Posts
- 2025.06 – 현재
외부 LLM API 없이 오픈소스 모델을 셀프 호스팅한 이유
보안 요구를 만족하기 위해 외부 API 의존 대신 모델과 추론 인프라를 직접 운영한 배경과 판단을 정리했습니다.
- 2025.06 – 현재
vLLM과 XGrammar로 예측 가능한 추론 API 만들기
GPU 추론 처리량을 고려한 vLLM 서빙과 구조화 출력 오류를 줄이기 위한 XGrammar 제약 디코딩 적용 과정을 정리했습니다.
- 2025.06 – 현재
Slack 수동 운영에서 Request-on-Wake 구조로 전환하기
Slack 명령으로 GPU EC2를 켜고 끄던 초기 운영 방식을 실제 요청이 들어올 때 자동 기동하는 구조로 개선했습니다.
- 2025.06 – 현재
Lambda 요청 본문 한계를 CPU EC2 게이트웨이로 해결하기
Lambda는 인스턴스 제어에 집중시키고, 대용량 요청의 수신·보관·전달은 CPU EC2가 담당하도록 데이터 경로를 분리했습니다.