1단계는 백엔드와 AI 서버 사이의 계약을 정했다. 상용 LLM API를 쓴다는 전제였다. 프로덕션에서는 비용 절감, 데이터 보안, 성능 최적화, 통제권 확보를 위해 GPU 서버에 모델을 직접 서빙한다. 이 문서는 v2의 GPU 서빙 최적화 방안을 정한다.

자체 서빙으로 옮기기 전에 정해야 할 항목을 아래에 정리한다.

경로마다 최적화 목표가 다르다. "LLM 응답을 빠르게"로 묶으면 대기가 없는 구간에 지연 최적화를 하게 된다.

용어를 먼저 정의한다.

사용자가 AI 서버를 기다리는 화면은 대화와 분석 둘뿐이다(모델 API 설계의 「사용자 대기가 발생하는 구간」). 최적화 대상은 토큰 생성 속도와 분석 구간 소요시간이다.

flowchart LR
    subgraph AS["현재 — 상품 단위"]
        direction TB
        A1[드리퍼] --> A2[LLM 호출]
        B1[드립포트] --> B2[LLM 호출]
        C1[핸드밀] --> C2[LLM 호출]
        D1[...20개] --> D2[LLM 호출]
        A2 --> AR["40개의 서로 다른 문장"]
        B2 --> AR
        C2 --> AR
        D2 --> AR
    end

    subgraph BS["변경 — 검색 쿼리 단위"]
        direction TB
        Q1["쿼리 · 캠핑장에서 핸드드립"] --> QL[LLM 호출 1회]
        QL --> QR["문장 1개"]
        QR --> P1[드리퍼]
        QR --> P2[드립포트]
        Q2["쿼리 · 손목 부담 적은 분쇄"] --> QL2[LLM 호출 1회]
        QL2 --> QR2["문장 1개"]
        QR2 --> P3[핸드밀]
    end

flowchart TD
    C[프로필 확정] --> SUM[요약문 생성<br/>응답 모델]
    SUM --> K[표시 키워드 선별]
    K --> UI["확인 화면<br/>사용자 대기"]
    UI --> R[검색 문장 재작성<br/>파생 쿼리 생성]
    R --> E[임베딩 배치]
    E --> V[벡터 검색 · 하드필터]
    V --> SC[스코어 · 다양성 선별]
    SC --> RE[추천 이유 생성<br/>쿼리 단위]
    RE --> D["self + gift 반환"]

    style UI fill:#fff4e6
    style SUM fill:#f0f7ff
    style RE fill:#f0f7ff

flowchart LR
    S["시스템 프롬프트<br/>모든 턴에 동일"] --> H["누적 이력<br/>1턴부터 직전 턴까지<br/>뒤에만 붙는다"]
    H --> N["이번 턴 지시문 + 발화<br/>매 턴 새로 생긴다"]

    S -. 캐시 재사용 .-> C[("KV 캐시")]
    H -. 캐시 재사용 .-> C
    N --> P["신규 프리필<br/>= 이번 턴 토큰만"]

    style C fill:#fff4e6
    style P fill:#f0f7ff

 5턴  [시스템][1~4턴 이력]  + [5턴 지시+발화]
 6번째 사이클  [시스템][1~5 사이클 이력]  + [6번째 지시+발화]
20번째 사이클 [시스템][1~19 사이클 이력] + [20번째 지시+발화]
      └──── 캐시 재사용 ────┘  └─ 신규 프리필 ─┘

상품 1만 개 × 벡터 3종 = 3만 벡터
1024차원 float32 → 약 120MB

1단계는 계약을 고정했고 서빙 방식은 정하지 않았다. 이 단계에서 정할 항목은 다음과 같다.

계약은 바뀌지 않는다. 아래 최적화를 전부 적용해도 백엔드가 부르는 엔드포인트와 스키마는 그대로다. 예외는 마지막 절에 정리한다.

쿼리 단위와 배치 중 무엇을 쓸지는 E6에서 정한다. 배치는 호출이 2회로 준다. 대신 한 번의 실패가 리스트 전체 문구를 날린다. 부분 실패 격리와 호출 수를 맞바꾸는 선택이다.

query 항목 전체를 한 번에 넘긴다. 정규화한 표현을 키로 벡터를 캐시한다.

1단계가 확정과 리스트 생성을 나누면서 요약문 생성이 사용자 대기 경로로 들어왔다. 대화 종료에서 확인 화면까지의 전환이 이 호출 하나에 묶인다.

대화 턴의 타임아웃 20초를 그대로 쓰면 최악의 경우 사용자가 20초 동안 빈 화면을 본다. 타임아웃을 5초로 두고 재시도하지 않는다. 실패하면 summary를 null로 반환하고 프로필과 키워드만 보여준다. 요약문은 친구가 읽는 글이라 없어도 확인과 리스트 생성이 진행된다.

이전 설계에서는 요약문 생성을 검색 갈래와 병렬로 돌려 6초 예산을 맞추려 했다. 구간이 나뉘면서 두 호출이 다른 시점에 돌게 되어 병렬화가 필요 없어졌고, continuous batching이 있어야 이득이 난다는 조건도 함께 사라졌다.

같은 sessionId는 같은 인스턴스로 보낸다. 해시 기반으로 처리한다. 클라우드 구성을 정하기 전에 확정해야 한다. 나중에 바꾸면 O8의 이득이 사라진다.

여기서의 경량화는 역할별로 필요한 언어 이해 범위를 나누는 방식이다. 자연스러운 대화, 공개용 요약, 검색 의도 재작성에는 8B를 쓰고, 형식이 강제된 턴별 변경분에는 1.3B를 쓴다. 한 모델에 둘 다 시키면 모든 요청을 8B 비용으로 처리하게 된다.

프롬프트 조립 순서는 prefix caching에 의존한다. 델타 스키마 강제는 guided decoding(스키마에 맞는 토큰만 생성하도록 제한하는 디코딩)에 의존한다. 둘이 없는 스택은 후보가 아니다. vLLM을 기본으로 두고 측정한다.

L1은 인스턴스 밖에 둔다. 프로세스 메모리에 두면 캐시가 인스턴스마다 따로 쌓인다. 임베딩 캐시는 "캠핑", "커피" 같은 표현이 사용자 사이에서 반복된다는 전제로 얻는 이득이라, 저장 위치가 나뉘면 히트율이 인스턴스 수만큼 나뉜다. O4의 세션 고정 라우팅도 여기서는 도움이 되지 않는다. 그 라우팅은 같은 세션을 같은 곳으로 보내는 규칙이고, L1이 노리는 것은 서로 다른 사용자 사이의 공유다.

리스트 생성 잡의 실행 위치도 이유가 된다. 임베딩 호출은 이 잡 안에서 일어난다. 잡을 별도 워커가 돌리면 API 프로세스 메모리에 둔 캐시는 워커에서 보이지 않는다. 공용 저장소여야 두 쪽이 같은 캐시를 본다.

이미 세션 상태와 잡 큐로 Redis를 쓰고 있어 새로 붙이는 인프라가 아니다. TTL과 용량 상한(LRU 축출)을 저장소가 처리하므로 만료 관리를 직접 짤 필요도 없다. 크기는 1024차원 float32 기준 벡터 하나가 약 4KB다. 표현 10만 개를 담아도 수백 MB 수준이라 한 대로 감당한다.

L0은 같은 방식으로 옮길 수 없다. KV 캐시는 GPU 메모리에 있고, 직렬화해서 꺼내 옮기면 다시 계산하는 것보다 비싸다. 그래서 L0은 저장소 공유가 아니라 O4의 라우팅으로 푼다. 두 층은 같은 캐시라도 해법이 다르다.

[시스템(불변)] → [누적 이력] → [이번 사이클 지시 + 발화] 순서를 쓴다. 이력은 최대 20개 대화 사이클 전량 누적하고 잘라내지 않는다. 캐시된 접두사에 신규 토큰만 얹으면 대화가 진행돼도 매번 프리필하는 양이 이번 발화 중심으로 유지된다. 상세는 프리뷰 3에 있다.

상용 API에서는 정할 수 없는 항목이다. 자체 서빙이라서 조정할 수 있다.

응답 모델 공식 BF16 체크포인트는 약 16.1GB라 24GB GPU 한 장에 적재할 수 있다. 남은 VRAM은 CUDA graph, activation, KV cache가 사용하므로 응답 모델은 단독 worker로 두고 컨텍스트를 8K로 제한한다. 초기 운영 기준은 공식 BF16이며, 양자화는 24GB 적재가 목적이 아니라 더 높은 동시성이나 비용 절감이 실측으로 필요한 경우에만 별도 품질 실험으로 검토한다.

응답 모델은 O9의 공식 BF16 체크포인트로 올린다. GPU 종류, 모델 revision, vLLM image digest를 결과에 함께 적는다.

같은 조건이 아니면 전후 비교가 성립하지 않는다.

• 발화는 고정 12개 대화 사이클 스크립트를 쓴다. 유저 시뮬레이터는 입력 토큰 수가 매번 달라져 비교가 깨진다. 시뮬레이터는 품질 평가에만 쓴다
• E8은 12개 사이클 스크립트를 마친 뒤 확정된 프로필을 주입하고 정정 대화를 3개 사이클 잇는다. 이 경로는 캐시가 비어 있는 상태에서 누적 이력을 한 번에 프리필하므로 다른 실험과 조건이 다르다
• 온도(응답 0.7 · 추출 0.1), 대화 사이클 상한, 컨텍스트 길이, limit을 고정한다
• 콜드와 웜을 분리해서 잰다. 프롬프트 조립 순서의 효과는 웜에서만 나타난다
• 각 조건을 N회 반복하고 p50과 p95를 낸다

측정 코드는 modeltest.ipynb에 있다. 마지막 셀이 아래 결과 표를 출력한다.

경량화는 품질을 깎는다. 허용 범위를 미리 정하고 그 안에서만 채택한다.

필수재현율  ≥ 베이스라인 − 5%p
금지위반    증가 0

기존 평가 리포트의 숫자는 구 단일 호출 프롬프트와 다른 모델 기준이다. 지금 구조의 베이스라인이 아니다. 카나나 두 모델로 골드셋을 다시 돌린 값을 베이스라인으로 삼는다.

• 벡터 검색과 임베딩 모델은 재지 않는다. 카탈로그와 pgvector가 아직 없다. 이유 생성 실험의 후보 상품은 합성이며 호출 수와 소요시간만 유효하다
• 절대값으로 SLO(Service Level Objective)를 판정하지 않는다. A100 1장, 4bit, vLLM 기준이다. 서빙 스펙이 바뀌면 값도 바뀐다. 구성 간 상대 비교만 근거로 쓴다

측정하지 못한 구간은 "미측정"으로 표기한다. 임의 숫자로 채우지 않는다.

측정 후 채운다. modeltest.ipynb의 출력이 이 표로 들어온다.

프론트엔드에 가는 영향은 없다. 백엔드는 저장 개수만 확인한다. 클라우드는 라우팅 규칙만 확인한다.

이 문서는 무엇을 어떻게 서빙할지를 정한다. 어떤 단위로 묶어 배포할지는 정하지 않는다.