vLLM과 XGrammar로 예측 가능한 추론 API 만들기

문제: 모델이 답을 잘해도 형식이 틀리면 서비스에서 사용할 수 없습니다

RenameDP의 LLM 응답은 사람이 읽는 문장만 생성하면 되는 형태가 아니었습니다. 후속 로직이 응답을 처리하려면 정해진 스키마와 필드 구조를 따라야 했습니다.

프롬프트만으로 JSON 형식을 요청할 수도 있지만, 모델이 필드를 누락하거나 문법에 맞지 않는 값을 생성하면 파싱 단계에서 전체 요청이 실패할 수 있었습니다.

vLLM으로 추론 서버를 구성했습니다

오픈소스 모델을 GPU EC2에서 서비스하기 위해 vLLM 기반 추론 서버를 구성했습니다. 애플리케이션이 모델 구현 세부사항에 직접 의존하지 않도록 추론 엔드포인트를 분리하고, 모델 서버의 상태를 별도로 확인할 수 있는 구조로 만들었습니다.

이를 통해 애플리케이션과 모델 실행 환경의 책임을 분리하고, 이후 모델 변경이나 서버 운영 방식 개선도 추론 계층 안에서 처리할 수 있도록 했습니다.

XGrammar로 생성 가능한 출력 자체를 제한했습니다

구조화 출력은 프롬프트 지시만으로 보장하지 않고, XGrammar 기반 제약 디코딩을 적용했습니다.

모델이 토큰을 생성하는 단계에서 허용된 문법과 스키마에 맞는 후보만 선택하도록 제한해, 잘못된 JSON이나 허용되지 않은 필드가 생성될 가능성을 낮췄습니다.

핵심은 결과를 생성한 뒤 검사하는 것에 그치지 않고, 처음부터 유효한 결과만 생성할 수 있도록 출력 공간을 제한했다는 점입니다.

설계에서 중요하게 본 점

• 애플리케이션과 추론 서버의 책임 분리
• 모델 응답 파싱 실패가 전체 기능 장애로 이어지지 않도록 예방
• 프롬프트 품질에만 의존하지 않는 구조화 출력 보장
• 모델 교체 시에도 동일한 API 계약을 유지할 수 있는 구조

배운 점

LLM을 백엔드 기능으로 사용할 때는 자연어 품질뿐 아니라 API 계약 준수 여부가 중요했습니다. 제약 디코딩을 적용하면서 생성형 모델도 일반 백엔드 컴포넌트처럼 입력·출력 계약을 중심으로 설계해야 한다는 점을 배웠습니다.