• 1. 기존 모델 추론 성능 지표
• 2. 식별된 성능 병목 요소 및 원인 분석
• 3. 적용할 최적화 기법의 구체적 계획
• 4. 최적화 적용 후의 기대 성능 지표

키워드 추출 기능을 위해 6개의 오픈소스 LLM과 Gemini API를 비교 테스트함
키워드 추출은 장소 정보 키워드 추출, 사용자 입력 키워드 추출 두 가지 용도로 사용함
테스트 환경은 동일한 GPU 환경(Colab Pro + T4 기준)에서 용도 별 테스트 입력으로 모델별 지연 시간, 메모리 사용량, 응답 품질을 측정함

input_info = {
  "placeName": "영덕강구항",
  "category": "'음식점 > 한식 > 해물,생선 > 회",
  "originKey": "예약가능, 배달가능, 포장가능, 와이파이, 주차가능, 회식장소",
  "menus": [
    {"name": "참가자미", "price": "75,000원"},
    {"name": "통문어", "price": "70,000원"},
    ...
  ],
  "reviews": [
    "해산물 신선함은 정말 미쳤어요~ 밑반찬도 많지는 않지만...",
    "가성비 좋습니다 자주 갈 예정입니다",
    ...
  ]
}
keyword_list = ['예약 가능', '주차 가능', '회식 장소', '데이트 장소', '가족 모임', '소고기', '해산물', '일식', '한식', '양식', '분위기 좋음', '조용함']

당신은 장소 검색 키워드 추출 AI입니다.
장소 검색을 위한 장소 정보에서 해당 장소의 특징을 나타내는 키워드를 추출하세요.

**입력 데이터 설명**
input_info : 장소의 정보를 나타내는 json
keyword_list : AI가 반환할 수 있는 키워드 리스트

**출력 데이터 설명**
place_keyword : AI가 input_info 기반으로 keyword_list에서 추출한 키워드 목록
place_introduce : AI가 input_info를 기반으로 작성한 해당 장소를 추천하는 한 줄 소개글

**유의사항**
place_keyword 장소의 정보들을 잘 나타내야 합니다.
keyword_list에 존재하지 않는 키워드는 반환하면 안됩니다.
출력 형식을 반드시 지켜서 응답해야 합니다.

**입력 데이터**
input_info : {input_info}

keyword_list : {keyword_list}

**출력 형식**
{{
    user_keyword: ['키워드1', '키워드2', '키워드3', ...],
    place_introduce: '한 줄 소개글'
}}

장소 정보 키워드 추출은 DB 구축 과정에서 사용되기에 GPU 메모리 사용량을 기준으로 정렬함

gemini-2.0-flash-lite (API)의 응답 품질이 가장 좋았으며, 그 다음으로 gemma-2b-it 모델의 응답 품질이 좋았음
장소 정보 키워드 추출 기능은 실시간성을 갖지 않기 때문에, 프리티어의 분당 요청 수 제한 내에서 Gemini API 사용 예정

input_query = "내일 저녁에 예약 되는 회식 장소 알아봐줘, 해산물 메뉴로."
keyword_list = ['예약 가능', '주차 가능', '회식 장소', '데이트 장소', '가족 모임', '소고기', '해산물', '일식', '한식', '양식', '분위기 좋음', '조용함']

당신은 장소 검색 키워드 추출 AI입니다.
장소 검색을 위한 사용자 쿼리에서 사용자의 요구를 나타내는 키워드를 추출하세요.

**입력 데이터 설명**
input_query : 사용자가 장소를 검색하기 위해 검색한 입력어
keyword_list : AI가 반환할 수 있는 키워드 리스트

**출력 데이터 설명**
user_keyword : AI가 input_query를 기반으로 keyword_list에서 추출한 키워드 목록

**유의사항**
user_keyword는 사용자의 요구를 잘 표현해야 합니다.
keyword_list에 존재하지 않는 키워드는 반환하면 안됩니다.
출력 형식을 반드시 지켜서 응답해야 합니다.

**입력 데이터**
input_query : {input_query}

keyword_list : {keyword_list}

**출력 형식**
{{
    user_keyword: ['키워드1', '키워드2', '키워드3', ...],
}}

사용자 입력 키워드 추출은 실제 서비스에서 사용되기에 응답 시간을 기준으로 정렬함

gemini-2.0-flash-lite (API)의 응답 품질은 상당히 좋으며, 오픈소스 LLM들은 응답 품질이 좋지 않음
하지만 사용자 입력 키워드 추출 기능은 실시간성을 갖기에 API 비용 절감을 위해 오픈소스 LLM의 학습이 필요함
테스트 모델 기준으로는 gemma-2b-it을 최종 모델로 선정하나, 안좋은 응답 품질을 보이기에 타 모델로의 변경도 가능성 있음
하지만 메모리 사용량 또한 고려한 선택이기에 더 큰 모델로의 변경은 어려워보임

실제 모델 테스트 및 배포를 고려한 시뮬레이션 과정에서, 다음과 같이 유형별 병목 요소가 식별됨
이는 입력 처리, 응답 형식, 시스템 운영 관점으로 구분되며, 각각의 상황에 따른 원인 및 개선 방향을 기반으로 추후 최적화에 활용될 수 있음

모든 LLM은 입력 토큰 수에 대한 상한(예: 2048, 4096, 8192 등)이 존재하며, 이를 초과할 경우 추론이 실패하거나 GPU 커널 오류(CUDA error)가 발생할 수 있음
서비스 특성상 장소 정보 외에도 다양한 리뷰, 메뉴 데이터가 함께 입력되기 때문에 토큰 수가 쉽게 증가하는 구조이며, 실제 테스트에서도 입력 초과로 인한 추론 실패가 확인되었음

💡 개선 방향

• 프롬프트 입력 전 사전 토큰 길이 측정
• 모델별 제한에 맞춰 텍스트 슬라이싱 또는 요약 처리
• 모델별 max_length 자동 조정 기능 구현
• 사용자 리뷰는 별점 상위 기준으로 우선순위 정렬 후 상위 10개만 사용
• 메뉴 항목은 대표메뉴 위주로 압축하거나, 가격 정보 제외 등 간소화 처리

Gemini API 등 외부 LLM 서비스를 사용할 경우, 프리티어 환경에서는 분당 요청 수(예: 30회), **일일 총 호출 수(예: 1500회)**에 대한 제한이 존재하며,
이를 초과하면 요청이 거절되거나 응답 지연이 발생할 수 있음. 특히 트래픽이 집중되는 피크 타임(예: 점심, 저녁 시간대)에는 병목 현상이 서비스 전체로 확산될 위험이 있음

💡 개선 방향

• 프리티어의 Rate Limit을 고려한 요청 분산 설계
• 자동 재시도(backoff) 및 에러 응답 처리 루틴 구축
• 유료 플랜 전환 시 호출 제한 완화 고려
• 동일 장소에 대한 키워드 요청은 일정 시간 내 중복 요청 시 캐시된 응답 반환
• 키워드 추출은 검색 시점이 아닌 상세 페이지 진입 시 비동기 호출로 분리하여 UX 최적화

오픈소스 LLM 및 Gemini API 모두에서 응답의 일관성이 떨어지는 현상이 관찰되었음
오픈소스 LLM은 프롬프트에 명시한 리스트 형태로 응답하지 못하거나, 키워드 대신 해설형 문장을 생성하는 경우가 많았음
반면, Gemini API는 프롬프트에 부합하는 리스트 형식으로 응답을 반환하지만, 유사 의미 키워드 반환 또는 중복 요청에 대해 일관성이 낮은 결과가 자주 출력되었음

이러한 응답 일관성의 문제는 추천 로직의 신뢰성과 사용자 경험에 영향을 줄 수 있음

💡 개선 방향

• 프롬프트 템플릿 정제 및 사전 테스트 기반 안정화
• 프롬프트 기반 추출이 아닌, 문서 기반 추론을 위한 RAG 구조 도입
• 키워드 후보군을 사전에 정의하고, 모델이 이 안에서 추출하도록 제약하는 방식 사용
• 일관되지 않은 응답에 대해서는 후처리 필터링 로직 적용 및 대체 키워드로 보완

다수의 오픈소스 LLM은 한국어 키워드 추출 및 표현력에서 낮은 성능을 보였으며, 실제 운영 수준에서의 활용이 어려운 수준이었음
이는 서비스 품질의 신뢰도 저하로 이어질 수 있다.

💡 개선 방향

• 오픈소스 LLM의 fine-tuning을 통해 추론 품질 보완 필요
• 초기 운영은 Gemini 등 외부 API 기반으로 안정적인 성능 확보
• API 활용한 실 서비스 로그 기반 응답 데이터 수집 → 오픈소스 LLM에 대한 후속 fine-tuning 데이터셋 구축
• 장기적으로는 로컬 경량화 모델로 전환해 운영비 최적화 추진

LLM 모델은 파라미터 수에 비례하여 GPU 메모리와 로딩 시간을 많이 소모하므로,
운영 환경에 따라 단일 모델만 실행 가능한 구조가 되는 경우가 있음
특히 Jetson Orin, Colab과 같은 저사양 환경에서는 한 번에 하나의 모델만 실행하거나,
모델 로딩/삭제 시 대기 시간이 길어 테스트 및 운영의 효율성이 떨어지는 문제가 발생하였음

💡 개선 방향

• 초기 테스트 및 단일 목적 추론은 모델별 독립 실행 구조 유지
• 경량화 모델(2B 이하)을 우선 사용하고, 필요한 경우 추론 역할 분리 (예: 쿼리 vs 장소 정보)
• 자주 호출되는 추론 경로(API)는 상시 로딩,
  비동기 또는 낮은 빈도의 작업은 On-Demand 로딩 구조 고려

일부 기능(예: 사용자 쿼리 기반 실시간 키워드 추출)은 빠른 응답이 필수적이나,
모델 로딩 또는 추론 지연으로 인해 실시간 처리에 병목이 발생할 수 있음
또한 다수 사용자가 동시에 접근할 경우, 단일 모델 구조에서는 요청이 직렬로 처리되므로, 대기 시간이 급증하는 문제가 발생함

💡 개선 방향

• 실시간 응답이 필요한 기능은 외부 API 기반 LLM으로 처리하고,
  비실시간 기능(예: 장소 정보 요약)은 서버 내 선처리 구조로 분리
• 자주 등장하는 쿼리는 키워드 결과를 캐싱하여 재사용하고,
  응답 지연 시 기본 추천 fallback을 제공하여 UX 안정화
• 동시 요청 대응이 필요한 경우, 추론 서버를 기능 단위로 나누거나,
  모델 프로세스를 분산 배치하는 구조 고려

• 지연 시간 감소: 평균 응답 시간을 1초 이하로 단축
• 응답 안정성 확보: 비일관된 응답 포맷 제거 및 키워드 추출 정확도 향상
• 운영 비용 절감: API 호출 빈도 최소화 및 GPU 자원 효율적 사용

🔹 1단계: Gemini API 기반 MVP 개발

• 안정적인 키워드 포맷 생성과 빠른 응답 속도를 기반으로 MVP 시스템 구축
• 프롬프트 기반 키워드 추출 기능을 우선적으로 API에 연결하여 서비스 운영
• 사용자 입력 및 추천 로그를 수집하여 응답 이력 기반 데이터셋 자동 축적

🔹 2단계: 용도별 API → 자체 모델 전환 전략

• LLM 활용 목적을 장소 키워드 추출과 사용자 입력 키워드 추출로 분리
• 장소 키워드 추출은 비실시간성 기능으로 프리티어 내에서 Gemini API 지속 활용 예정
• 사용자 입력 키워드 추출은 실시간 응답이 필요한 기능으로,
  Gemini API의 분당 호출 수 제한으로 인해 서비스 병목 발생 가능
• 해당 기능은 실시간 처리에 적합한 자체 모델로 전환하고,
  수집된 사용자 입력/응답 로그 기반으로 gemma-2b-it, polyglot-ko 등 경량 모델에 fine-tuning 수행

🔹 3단계: 서비스 단위 최적화 및 효율적 리소스 운영 구조 구축

• LLM 응답 품질 편차를 줄이기 위해, MVP 개발 단계부터
  사전 정의된 키워드 후보군 기반의 응답 정제 로직을 도입
  → soft-matching 및 post-filtering을 통해 응답 일관성 확보
• 실시간 처리가 필요한 요청은 캐시 활용 + fallback 대응 시나리오 도입으로 UX 안정화
• 기능별 응답 대기 허용시간에 따라 추론 모델을 역할 단위로 분리 배치
  예:
  • 장소 정보 요약 → 비동기 처리 + 고성능 모델
  • 사용자 쿼리 분석 → 실시간 처리 + 저지연 모델
• 실 서비스 기준에서 모델 스케일 조정을 고려하여,
  On-Demand 추론 구조 또는 다중 엔드포인트 분산 로딩 전략 설계 예정

ℹ️ 자체 모델 전환은 Gemini API의 분당 호출 제한 및 일일 호출량 제한으로 인해
실시간 사용자 쿼리 처리 시 병목이 발생하는 구조적 한계를 해소하기 위한 전략적 선택임