요약 (TL;DR)

좁고 테스트 가능한 프롬프트는 먼저 작은 모델 (small model)로 라우팅하고, 명시적인 품질 신호가 있을 때만 큰 모델 (large model)로 폴백 (fallback)하며, 지연 시간 허용이 가능한 작업은 배치 레인 (batch lane)으로 이동시키세요. SaaS 앱을 위한 가장 저렴한 아키텍처는 지연 시간 (latency), 품질 (quality), 그리고 미국(US) 또는 유럽(EU) 데이터 처리 SLO (Service Level Objectives)를 충족하면서도, 수락된 결과당 비용을 최소화하는 아키텍처입니다.

모든 라우트를 영리한 프롬프트가 아닌 운영 정책으로 취급하세요.

수락된 작업량을 측정하세요.

SaaS 앱은 프롬프트 라우팅을 통해 어떻게 LLM API 비용을 줄여야 하는가?

저는 먼저 트래픽을 요청 클래스 (request classes)로 나누는 것부터 시작합니다. 고객 지원 의도 분류 (Support-intent classification), 필드 추출 (field extraction), 문서 요약 (document summarization), 그리고 개방형 어시스턴트 (open-ended assistant)는 재무 수출 데이터상에서 동일한 LLM API 항목으로 표시되더라도 각각 실패 비용이 다릅니다. 각 클래스에 대해 출력 계약 (output contract), 지연 시간 목표 (latency objective), 최대 입력 크기 (maximum input size), 허용 가능한 폴백 비율 (acceptable fallback rate), 그리고 오답의 결과 (consequence of a wrong answer)를 작성합니다. 그런 다음 실제 테넌트 (tenant) 트래픽과 유사한 홀드아웃 예시 (held-out examples)를 사용하여 작은 모델을 큰 모델과 비교 테스트합니다.

라우팅 규칙은 장애 발생 시 설명할 수 있을 정도로 지루할 만큼 단순해야 합니다. 응답을 로컬에서 확인할 수 있는 경우(유효한 JSON, 허용된 레이블, 필수 필드 또는 제한된 점수 등)에는 작은 모델이 먼저 실행됩니다. 큰 모델은 해당 확인이 실패하거나 추론 (inference) 전에 요청이 고위험으로 분류된 경우에 대한 폴백으로 사용됩니다. 모델의 신뢰도 (model confidence)가 동일한 워크로드에 대해 보정 (calibrated)되지 않았다면, 이를 유일한 게이트 (gate)로 사용하지 마세요. 확신에 찬 잘못된 결과는 여전히 잘못된 결과입니다.

조용한 에스컬레이션 (silent escalation)은 피하세요.

이것은 제가 로드맵 검토 시 사용하는 '구매 대 자체 구축 (buy-versus-build)' 비교표입니다:

단순히 두 개의 모델이 존재한다는 이유만으로 라우터 (router)를 추가하지는 않을 것입니다. 볼륨이 낮거나, 프롬프트가 매주 바뀌거나, 평가 데이터셋 (evaluation set)을 관리하는 사람이 없다면, 우선 하나의 관리형 경로를 유지하며 측정치를 먼저 수집하십시오. 주의할 점은 라우팅이 두 번째 운영 시스템을 생성한다는 것입니다. 정책 버전 (policy versions), 텔레메트리 (telemetry), 평가 데이터, 그리고 롤백 (rollback) 모두에 관리자가 필요합니다.

코드에서 폴백 (fallback) 경로를 명시적으로 작성하세요

애플리케이션이 모델 인터페이스와 검증 규칙을 소유해야 합니다. 그래야 프로바이더 클라이언트 (provider client)를 교체 가능하게 유지할 수 있으며, 토큰을 소비하지 않고도 정책을 테스트할 수 있습니다. 이 질문을 던진 원래의 서비스가 Node.js일 수도 있지만, 운영 계약 (operational contract)은 언어에 독립적입니다. 여기에 제시된 모든 운영 예제는 Go 언어로 작성되었는데, 이는 제가 온콜 (on-call) 시 사용하는 스택이기 때문입니다.

package routing

import (
...

코드가 하지 않는 작업에 주목하십시오: 맹목적인 재시도 (retry), 친절한 문단 파싱, 또는 프로바이더 클라이언트 내부에 에스컬레이션 (escalation)을 숨기는 행위 등입니다. 실제 운영 환경에서는 요청 클래스, 정책 버전, 선택된 모델 클래스, 검증 결과, 폴백 이유, 지연 시간 (latency), 그리고 가능한 경우 입출력 토큰 수를 출력할 것입니다. 테넌트 (tenant)의 텍스트에는 개인정보나 기밀 데이터가 포함될 수 있으므로, 프롬프트 본문은 기본 로그에 남기지 않습니다.

그 경계(boundary)를 테스트하십시오.

한 번의 콜드 스타트 (cold-start) 사고가 제 머릿속에 이 교훈을 각인시켰습니다. 실제 트래픽 상황에서 p99 지연 시간이 17분 동안 8.4초에 달했지만, 우리의 합성 체크 (synthetic checks)는 계속 정상(green)으로 표시되었습니다. 합성 체크의 일정한 간격이 관련 경로를 따뜻하게(warm) 유지했기 때문입니다. 모델 호출은 연결 설정, 큐잉 (queueing), 재시도와 예산을 공유합니다. 꼬리 지연 시간 (tail SLO)을 해치는 저렴한 첫 번째 홉 (hop)은 어떤 유용한 의미에서도 결코 저렴하지 않습니다.

지연 허용이 가능한 LLM 작업은 배치 레인 (batch lane)으로 보내세요

배치 처리 (Batch processing)는 웹 계층 (web tier)에 매달려 있는 루프(loop)가 아니라, 내구성이 있는 큐 (durable queue) 뒤에 위치해야 합니다. 백필 (Backfills), 야간 데이터 보강 (nightly enrichment), 평가 실행 (evaluation runs), 그리고 예약된 요약 (scheduled summaries)은 완료 시간 범위를 허용할 수 있지만, 대화형 채팅 (interactive chat)이나 차단형 양식 검증 (blocking form validation)은 대개 이를 허용할 수 없습니다. 이러한 레인 (lanes)을 분리하면, 워커 (workers)가 설정된 용량에 맞춰 수요를 조절하는 동안 동기식 서비스 (synchronous service)가 자신의 지연 시간 예산 (latency budget)을 보호할 수 있습니다.

각 배치 항목은 멱등성 키 (idempotency key), 테넌트 (tenant) 및 지역 정책 (region policy), 프롬프트 버전 (prompt version), 모델 클래스 (model class), 시도 횟수 (attempt count), 그리고 내구성이 있는 최종 상태 (durable terminal state)가 필요합니다. 워커는 제한된 작업 (bounded work)을 점유하고, 결과를 원자적 (atomically)으로 기록해야 하며, 클라이언트 계약 (client contract)에 의해 재시도 가능하다고 선언된 오류에 대해서만 재시도해야 합니다. 독성 항목 (Poison items)은 영원히 순환하는 대신 검토 큐 (review queue)로 보내야 합니다. 이는 일반적인 작업 처리 (job processing)처럼 들리는데, 실제로 그렇기 때문입니다. LLM 호출이라고 해서 큐잉 이론 (queueing theory)을 벗어나는 것은 아닙니다.

용량 계획 (Capacity planning)은 도착률 (arrival rate), 항목당 토큰 수 (tokens per item), 허용 가능한 완료 시간 범위 (acceptable completion window), 그리고 측정된 서비스 시간 (measured service time)에서 시작됩니다. 저는 재시도 (retries)와 재실행 (replays)을 위한 여유분 (headroom)을 확보한 다음, 배치 임포트 (batch import)가 대화형 경로 (interactive route)의 할당량 (quota)을 소비할 수 없도록 워커 동시성 (worker concurrency)을 제한합니다. 비용 대시보드 (Cost dashboards)는 각 요청 클래스별로 승인된 출력 (accepted outputs)에 따라 지출을 나누어야 합니다. 가공되지 않은 토큰 비용 (raw token cost)은 스키마 실패 (schema failures), 중복 작업 (duplicate work), 그리고 폴백 증폭 (fallback amplification)을 숨깁니다.

경계를 명확히 유지하십시오.

고객이 동일한 요청을 기다리고 있는 경우에는 배치가 적합하지 않으며, 팀에 가속기 용량 계획 (accelerator capacity planning) 및 추론 온콜 (inference on-call) 경험이 부족할 때는 셀프 호스팅 (self-hosting)이 적합하지 않습니다. 반대로, 안정적이고 대량인 오프라인 워크로드 (offline workload)는 활용도 (utilization)를 계획할 수 있기 때문에 셀프 호스팅 추론 (self-hosted inference)을 검토할 가치가 있을 수 있습니다. 귀하의 트래픽에서 그 교차점이 어디인지 저는 확신할 수 없습니다. 모델 크기, 활용도, 인력, 그리고 품질 목표에 따라 결과는 달라질 수 있습니다 (your mileage may vary). 결정은 낙관적인 활용도 백분율이 포함된 스프레드시트 셀이 아니라, 부하 테스트 (load test)와 소유권 검토 (ownership review)를 통해 내려져야 합니다.

Node.js 애플리케이션의 경우, 메시지 스키마 (message schema)가 버전 관리되고 양측이 멱등성 (idempotency)에 동의한다면, 웹 프로세스가 동일한 정책 엔벨로프 (policy envelope)를 큐에 넣고 Go 워커 (worker)가 이를 소비할 수 있습니다. 언어 간의 경계는 요청 계약 (request contract)을 보존하는 것보다 덜 중요합니다.

미국 및 EU 정책 검증, 점진적 배포, 그리고 깔끔한 롤백 (Rollback)

지역 선택은 지연 시간 (latency) 조절 이전에 데이터 거버넌스 (data-governance) 결정 사항입니다. 미국 및 EU 테넌트 (tenant)의 경우, 승인된 처리 지역을 테넌트 정책에 기록하고, 모델 경로에는 최소한으로 요구되는 콘텐츠만 전달하며, 보존 기대치를 정의하고, 보안 및 법무 소유자가 제공업체 계약을 검증하도록 해야 합니다. 엔드포인트 레이블 하나만으로는 전체 데이터 흐름에 대한 증거가 될 수 없습니다. 데이터 거주성 (residency) 또는 전송 요구 사항을 입증할 수 없다면, 다른 경로가 품질 테스트에서 더 높은 점수를 받더라도 해당 워크로드는 승인된 경로에 유지해야 합니다.

출시 전에, 홀드아웃 세트 (held-out set)를 현재 정책과 제안된 정책 모두에 대해 재실행(replay)하십시오. 수락률 (acceptance rate), 스키마 오류 (schema failures), 폴백 (fallback) 비율, 수락된 결과당 입력 및 출력 토큰, 그리고 지연 시간 백분위수 (latency percentiles)를 비교하십시오. 결과를 프롬프트 클래스 (prompt class), 테넌트 지역, 입력 크기 대역별로 세분화하십시오. 평균값은 에러 예산 (error budget)을 소모하는 롱 컨텍스트 (long-context) 경로를 숨길 수 있습니다. 임베딩 (Embeddings)은 평가 및 검색 워크플로우를 위해 유사한 입력을 그룹화하는 데 도움이 될 수 있지만, 생성된 답변에 대한 레이블이 지정된 수락 기준을 대체할 수는 없습니다.

꼬리 부분 (the tail)을 주시하십시오.

버전 관리된 플래그 (versioned flag)를 사용하여 소규모 테넌트 코호트 (cohort)에 배포하십시오. 중단 조건 (stop conditions)은 변경 계획에 포함되어야 합니다. 클래스 임계값을 초과하는 검증 실패, 과도한 폴백, 또는 꼬리 지연 시간 (tail-latency) 위반이 발생하면 해당 클래스를 알려진 양호한 경로로 고정해야 합니다. 롤백 (Rollback)은 압박 속에서 애플리케이션 코드를 배포하는 것이 아니라 정책을 변경하는 것을 의미합니다. 영향을 받는 배치 소비자 (batch consumers)를 일시 중지하고, 그들의 내구성이 있는 항목 (durable items)을 보존하며, 동기식 클래스를 전환한 후, 큐에 쌓인 작업을 재개하기 전에 텔레메트리 (telemetry)를 통해 복구를 확인하십시오.

저의 최종적인 go/no-go 검토 의견은 직설적입니다. 평가 코퍼스 (evaluation corpus)를 누가 소유하는가, 누가 페이지를 수신하는가, 용량 상한선 (capacity ceiling)은 무엇인가, 정책을 얼마나 빨리 되돌릴 수 있는가, 그리고 큐 (queue)에 실제 형태의 테스트 항목들이 포함되어 있고 대시보드 (dashboards)를 모니터링하고 있는 동안 정책 작성자 이외의 누군가가 그 되돌리기 작업을 실행해 본 적이 있는가? 만약 이 질문들에 대한 답변이 모호하다면, 최적화는 보류됩니다. 단일 모델 설계는 라우팅 (routing)을 통해 예상되는 비용 절감액보다 그 단순함이 SLO (Service Level Objective)를 더 잘 보호할 수 있을 때 올바른 선택입니다. 추가적인 추론 계층 (inference tier)은 그에 따른 운영상의 발자국 (operational footprint)만큼의 가치를 증명해야 합니다.

References

• https://platform.openai.com/docs/guides/embeddings