더 낮은 비용과 더 높은 가동 시간을 위한 최고의 멀티 프로바이더 LLM 서비스는, 건전한 라우팅 아키텍처와 명시적인 운영 관행(정의된 SLO, 지속적인 프로바이더 상태 모니터링, 테스트된 인시던트 플레이북, 그리고 관리되는 폴백 정책)을 결합한 서비스입니다. 라우팅 설계는 어떤 모델을 사용할 수 있는지 결정합니다. 운영은 해당 라우팅이 구축된 후 서비스가 실제로 가동 시간 약속을 이행하는지 여부를 결정합니다.
이 글은 운영 계층에 초점을 맞춥니다. 라우팅 설계 자체(폴백 정책, 비용 계층 모델 선택, 서킷 브레이커, 재시도 예산)에 대해서는 더 낮은 비용과 다운타임을 위한 최고의 멀티 프로바이더 LLM 플랫폼을 참조하세요.
멀티 프로바이더 LLM 서비스에서 "더 높은 가동 시간"의 의미
LLM 서비스의 가동 시간은 서버 가용성과 동일하지 않습니다. 프로바이더의 상태 페이지가 녹색으로 표시되더라도 사용자는 지연 시간 증가, 출력 품질 저하, 또는 에이전트 워크플로우의 무음 부분 실패를 경험할 수 있습니다.
멀티 프로바이더 LLM 서비스에 대한 실용적인 가동 시간 SLO는 다음을 포함해야 합니다:
- 성공적인 완료율: 지연 시간 예산 내에서 유효하고 사용 가능한 응답을 반환하는 LLM 요청의 비율
- 첫 번째 토큰까지의 시간 (P95): 평균 지연 시간이 아닌, 대화형 사용자가 경험하는 지연 시간
- 에이전트 워크플로우 완료율: 에이전트 워크로드의 경우, 성공적인 최종 상태에 도달하는 다단계 작업의 비율
- 성공적인 작업당 비용: 재시도, 폴백 또는 더 긴 출력이 성공적인 완료를 추가하지 않고 지출을 부풀릴 때 상승하는 효율성 신호
서버 가용성이 99.9%라도 모델 성능 저하, 속도 제한 소진 또는 샌드박스 실패로 인해 무음 오류가 발생하면 사용자에게 보이는 가동 시간 SLO를 놓칠 수 있습니다.
멀티 프로바이더 LLM 서비스를 위한 SLO 설계
프로바이더가 아닌 워크로드 클래스별로 SLO 정의
프로바이더 안정성은 모델, 리전 및 계층에 따라 다릅니다. SLO 목표는 프로바이더 수준이 아닌 워크로드 클래스 수준(사용자 대상 작업)에서 정의하세요.
| 워크로드 클래스 | SLO 목표 예시 | 오류 예산 (30일) |
|---|---|---|
| 대화형 채팅 (P95 지연 시간 ≤ 2초) | 99.5% 성공적인 완료 | 3.6시간 |
| 에이전트 워크플로우 완료 | 99.0% 작업이 최종 상태 도달 | 7.2시간 |
| 배치 추출 / 분류 | SLA 윈도우 내 99.9% 완료 | 43분 |
| 스트리밍 생성 (P95 TTFT ≤ 1초) | 99.0% 요청이 TTFT 예산 충족 | 7.2시간 |
워크로드 클래스 SLO를 사용하면 오류 예산을 정확하게 할당할 수 있습니다. 인시던트가 대화형 채팅 예산은 소진했지만 배치 예산은 소진하지 않은 경우, 신뢰성 작업을 어디에 집중해야 하는지 알 수 있습니다.
가용성 SLO와 품질 SLO 분리
멀티 프로바이더 시스템은 높은 가용성(요청이 응답을 받음)을 유지하면서도 품질이 저하될 수 있습니다(폴백 모델이 약한 답변을 생성). 두 가지를 모두 추적하세요:
- 가용성 SLO: 지연 시간 예산 내에서 오류가 없는 응답률
- 품질 SLO: 최소 품질 임계값(인간 레이블, 자동 평가, 사용자 비추천율)을 충족하는 응답의 비율
인시던트 중 폴백 경로가 활성화되면, 품질 SLO 소진율은 저하된 모드가 허용 가능한지 아니면 시스템이 대기열에 넣거나 중단해야 하는지 알려주는 신호입니다.
프로바이더 상태 모니터링 기준
효과적인 멀티 프로바이더 모니터링은 프로바이더 상태 페이지 이상을 관찰합니다. 관찰된 트래픽에서 자체 상태 신호를 구축하세요.
| 신호 | 측정 항목 | 알림 임계값 예시 |
|---|---|---|
| 프로바이더 + 모델별 오류율 | 분당 4xx/5xx 응답 | 5분 윈도우에서 > 5% |
| 프로바이더 + 모델별 P95 지연 시간 | 첫 번째 토큰까지의 시간, 총 완료 시간 | 3분 연속 기준치의 2배 초과 |
| 속도 제한 적중률 | 요청 대비 429 응답 비율 | 2분 윈도우에서 > 2% |
| 폴백 활성화율 | 보조 모델로 라우팅된 요청 | 5분간 10% 이상 지속(주 프로바이더 성능 저하 신호 가능) |
| 에이전트 워크플로우 실패율 | 최종 상태에 도달하지 못한 다단계 작업 | 10분 윈도우에서 > 1% |
| 성공적인 작업당 비용 | (입력 토큰 + 출력 토큰) × 가격 / 성공적인 완료 | 7일 기준치 대비 20% 초과 |
| 품질 점수 변화 | 자동 평가 통과율 또는 사용자 부정적 피드백률 | 7일 기준치 대비 15% 이상 상대적 감소 |
Novita AI LLM API를 사용하는 팀의 경우, OpenAI 호환 채팅 완료 엔드포인트는 이러한 신호에 직접 공급되는 표준 HTTP 상태 코드 및 지연 시간 헤더를 반환합니다. 모든 요청에 모델 ID, 프로바이더 경로 및 재시도 횟수를 기록하여 모니터링이 엔드포인트 수준이 아닌 모델별로 이루어지도록 하세요.
모든 LLM 요청 로그에 출력할 항목
{
"request_id": "req_abc123",
"workload_class": "interactive_chat",
"primary_model": "meta-llama/llama-3.1-70b-instruct",
"routed_model": "meta-llama/llama-3.1-8b-instruct",
"route_reason": "primary_rate_limited",
"provider": "novita",
"latency_ms": 1240,
"ttft_ms": 380,
"input_tokens": 512,
"output_tokens": 148,
"retry_count": 1,
"status": "success",
"quality_eval": "pass",
"cost_usd": 0.00031
}
route_reason은 대부분의 팀이 생략하는 필드입니다. 이것이 없으면 대시보드에서 정상적인 폴백(예상된 동작)과 저하된 폴백(프로바이더 인시던트)을 구분할 수 없습니다.
프로바이더 성능 저하를 위한 알림 아키텍처
알림은 전술적(온콜 엔지니어가 즉시 조치) 및 전략적(라우팅 정책 변경이 필요한 트렌드)의 두 가지 수준에서 발생해야 합니다.
전술적 알림 (온콜 엔지니어 호출)
- 프로덕션 워크로드 클래스에서 5분 동안 프로바이더 오류율이 5% 초과
- 대화형 채팅에서 3분 연속 P95 지연 시간이 기준치의 2배 초과
- 10분 동안 에이전트 워크플로우 실패율이 1% 초과
- 1시간 동안 월간 오류 예산의 5%를 초과하는 품질 SLO 소진율
전략적 알림 (Slack 채널, 호출 없음)
- 30분 동안 10% 이상 지속되는 폴백 활성화율(라우팅 정책 조정 필요할 수 있음)
- 2시간 동안 7일 기준치 대비 20% 초과하는 성공적인 작업당 비용
- 24시간 동안 증가 추세인 주 모델 속도 제한 적중(용량 계획 신호)
- 7일 윈도우 동안 저하되는 백업 모델 품질에 대한 품질 점수 변화 알림
워크로드 클래스별 알림 라우팅
모든 알림을 동일한 채널로 보내지 마세요. 올바른 팀이 조치를 취할 수 있도록 워크로드 클래스별로 전술적 알림을 라우팅하세요. 내부 코파일럿의 429 스파이크는 고객 대면 에이전트 워크플로우의 동일한 스파이크보다 우선순위가 낮은 이벤트입니다.
멀티 프로바이더 LLM 서비스를 위한 인시던트 플레이북
라우팅 정책은 자동으로 수행할 작업을 결정합니다. 인시던트 플레이북은 자동 동작이 충분하지 않거나 인시던트가 모호할 때 온콜 엔지니어를 안내합니다.
플레이북: 기본 프로바이더 오류율 상승
트리거: 프로덕션 워크로드 클래스에서 5분 동안 기본 모델 오류율 > 5%.
- 확인: 프로바이더 상태 페이지와 자체 오류 로그를 확인합니다. 일시적 스파이크와 지속적인 성능 저하를 구분합니다.
- 영향 평가: 영향을 받는 워크로드 클래스는 몇 개입니까? 폴백 모델이 이미 활성화되어 있고 품질 SLO 이내입니까?
- 폴백이 활성화되어 있고 품질 SLO가 충족되는 경우: 복구를 모니터링합니다. 30분 검토 체크포인트를 설정합니다.
- 폴백이 활성화되어 있지만 품질 SLO가 소진 중인 경우: 고위험 워크로드(법률, 금융, 안전 중요)를 대기열 또는 수동 보류로 이동합니다. 이해관계자에게 알립니다.
- 사용 가능한 폴백이 없는 경우: 저하된 모드를 활성화합니다(사용자에게 표시되는 공지, 긴급하지 않은 요청 대기열). 인시던트 사령관에게 에스컬레이션합니다.
- 복구: 기본 오류율이 10분 동안 1% 미만으로 돌아오면 점진적으로 트래픽을 다시 전환합니다. 한 번에 모든 트래픽을 전환하지 마세요.
- 인시던트 후: 인시던트 기간, 영향을 받은 워크로드 클래스, 품질 SLO 소진, 비용 영향 및 발견된 폴백 정책 격차를 기록합니다.
플레이북: 속도 제한 소진
트리거: 2분 동안 기본 모델에 대한 429 비율 > 2%.
- 할당량 대시보드 확인: 지속적인 용량 문제인지 트래픽 스파이크인지 확인합니다.
- 스파이크인 경우: 백오프 및 재시도 예산을 활성화합니다. 적격 워크로드에 대해 오버플로를 보조 모델 계층으로 라우팅합니다.
- 지속적인 경우: 우선순위가 낮은 워크로드에 대한 요청 대기열을 구현합니다. 예측 가능한 대용량 트래픽을 전용 엔드포인트로 이동하는 것을 고려하세요. — Novita AI GPU Cloud 또는 전용 LLM 엔드포인트는 공유 API 속도 제한을 초과한 워크로드에 대해 더 예측 가능한 용량을 제공할 수 있습니다.
- 무한정 재시도하지 마세요: 재시도 예산을 적용합니다. 각 429를 워크로드 클래스 및 모델과 함께 기록하여 어떤 호출 패턴이 가장 큰 영향을 받는지 식별합니다.
플레이북: 에이전트 워크플로우 실패 스파이크
트리거: 10분 동안 에이전트 워크플로우 실패율 > 1%.
- 실패 유형 구분: 실패가 LLM 호출(모델 오류, 속도 제한, 컨텍스트 오버플로)에 있는지 아니면 실행 계층(샌드박스 시간 초과, 잘못된 형식의 도구 호출 출력, 파일 작업 오류)에 있는지 확인합니다.
- LLM 계층 실패의 경우: 위의 기본 프로바이더 오류율 플레이북을 따릅니다.
- 샌드박스 또는 실행 실패의 경우: Novita Agent Sandbox 로그를 확인합니다. 문제가 체계적인지(잘못된 도구 호출을 유발하는 잘못된 프롬프트 템플릿) 또는 환경적인지(샌드박스 용량, 네트워크 시간 초과) 식별합니다.
- 영향을 받는 워크플로우 유형 격리: 브라우저 자동화 실패가 독립적인 코드 실행 워크플로우에 중단을 유발해서는 안 됩니다.
- 복구 게이트: 전체 트래픽을 복원하기 전에 영향을 받는 워크플로우를 통해 대표적인 골든 프롬프트 세트를 실행하고 실패율이 기준치로 돌아왔는지 확인합니다.
플레이북: 폴백 중 품질 SLO 저하
트리거: 폴백 모델이 활성화된 동안 품질 점수가 7일 기준치에서 15% 이상 하락.
- 영향을 받는 워크로드 클래스 식별: 품질 저하 는 종종 워크로드에 따라 다릅니다. 폴백 모델은 단순 분류를 잘 처리할 수 있지만 장문 추론에서는 성능이 저하될 수 있습니다.
- 워크로드 클래스별 폴백 제한 적용: 품질 저하가 허용 가능한 워크로드로만 저하된 폴백을 제한합니다. 고위험 작업은 대기열에 넣거나 중단합니다.
- 고객 대면 영향에 대해 이해관계자에게 알립니다.
- 인시던트 후: 백업 모델에 대해 관찰된 품질 제한을 반영하여 폴백 승인 매트릭스를 업데이트합니다.
폴백 정책 거버넌스
라우팅 정책은 사용 가능한 폴백 모델을 결정합니다. 거버넌스는 각 워크로드 클래스에 대해 어떤 폴백이 승인되었는지 — 그리고 자동 폴백이 전혀 발생해서는 안 되는 경우를 결정합니다.
폴백 승인 매트릭스
워크로드 클래스별로 문서화된 폴백 승인 매트릭스를 유지 관리하세요:
| 워크로드 클래스 | 기본 모델 | 승인된 폴백 | 조건 | 금지된 폴백 |
|---|---|---|---|---|
| 고객 채팅 | 모델 A (대형) | 모델 B (중형) | 골든 세트에서 품질 평가 통과 | 승인 목록에 없는 모든 모델 |
| 내부 코파일럿 | 모델 A (대형) | 모델 B (중형), 모델 C (소형) | 품질 평가 통과 | 해당 없음 |
| 법률 / 규정 준수 초안 | 모델 A (대형) | 대기열 전용 | 자동 폴백 없음 | 모든 소형 모델 |
| 배치 분류 | 모델 C (소형) | 모델 D (대체 프로바이더) | 품질 평가 통과 | 대형 모델 (비용 관리) |
| 브라우저 에이전트 | 모델 A (대형) + 샌드박스 | 대기열 | 샌드박스 실행이 확인되어야 함 | 도구 지원이 없는 텍스트 전용 모델 |
이 매트릭스를 매월, 그리고 폴백 동작이 예상치 못했거나 부적절했던 모든 인시던트 후에 검토하세요.
폴백 정책 변경은 누가 담당합니까?
폴백 정책 변경은 엔지니어링 팀(시스템이 변경을 지원할 수 있는지)과 제품 또는 위험 팀(품질 트레이드오프가 수용 가능한지) 모두의 승인을 받아야 합니다. 품질 기준에 대한 인간의 승인 없이 더 저렴한 모델로 전환하는 자동 라우팅 시스템은 무음 제품 위험을 만듭니다.
각 변경 사항을 문서화하세요: 어떤 모델, 어떤 워크로드 클래스, 어떤 품질 평가가 실행되었는지, 누가 승인했는지, 그리고 어떤 조건이 정책 검토를 트리거하는지.
Novita AI가 멀티 프로바이더 가동 시간 운영을 지원하는 방법
Novita AI는 팀이 여기에 설명된 종류의 운영 관행을 위해 계측할 수 있는 AI 및 에이전트 클라우드(LLM API, Agent Sandbox 및 GPU Cloud)로 운영됩니다.
LLM API는 모든 요청에 대해 표준 HTTP 상태 코드, 지연 시간 헤더 및 토큰 수를 반환하여 프로바이더 상태 모니터링 및 SLO 추적을 위한 원시 신호를 제공합니다. 모델 라이브러리는 현재 모델 가용성을 나열하여 실제로 지원되는 모델에 대해 라우팅 정책을 구축할 수 있도록 합니다. OpenAI 호환 채팅 완료 API는 기존 관찰 가능성 도구(요청 로깅, 지연 시간 추적, 오류율 대시보드)가 사용자 지정 계측 없이 작동함을 의미합니다.
Novita Agent Sandbox는 에이전트 워크플로우를 위한 관리형 실행 환경을 추가합니다. 동일한 워크플로우 로그에서 LLM 호출 결과와 샌드박스 실행 결과를 모두 관찰할 수 있는 기능은 에이전트 워크플로우 실패 플레이북과 직접적으로 관련됩니다. 두 계층의 로그 없이는 모델 실패와 샌드박스 실행 실패를 구분할 수 없습니다.
Novita AI GPU Cloud 및 전용 엔드포인트는 공유 API 속도 제한이 신뢰성 제약 조건이 될 때 팀에 운영 경로를 제공합니다. 429가 반복적인 인시던트 트리거인 워크로드의 경우 전용 용량으로 이동하면 공유 API 운영 모델에서 한 가지 인시던트 클래스가 제거됩니다.
프로덕션 배포 전 운영 준비 상태 체크리스트
멀티 프로바이더 LLM 서비스가 운영 준비가 되었는지 평가할 때 이 체크리스트를 사용하세요:
SLO 정의
- [ ] 각 프로덕션 워크로드 클래스에 대한 SLO 목표 정의 (가용성 + 품질)
- [ ] 오류 예산 계산 및 문서화
- [ ] 각 SLO에 대한 소진율 알림 구성
모니터링
- [ ] 모든 LLM 요청 로그: 모델, 프로바이더, 경로 이유, 지연 시간, 토큰, 재시도 횟수, 상태, 품질 평가 결과
- [ ] 대시보드는 오류율, P95 지연 시간, 폴백 활성화율, 성공적인 작업당 비용을 워크로드 클래스별로 분류하여 표시
- [ ] 프로바이더 상태 신호는 상태 페이지뿐만 아니라 관찰된 트래픽에서 파생
알림
- [ ] 프로덕션 워크로드 클래스에 대해 전술적 알림 (호출) 구성
- [ ] 비용 변화 및 폴백율 추세에 대한 전략적 알림 (Slack) 구성
- [ ] 알림 라우팅이 워크로드 클래스를 담당 팀에 매핑
인시던트 플레이북
- [ ] 기본 프로바이더 오류 스파이크, 속도 제한 소진, 에이전트 워크플로우 실패, 품질 SLO 저하에 대한 플레이북 작성 및 접근 가능
- [ ] 각 플레이북에 대한 복구 게이트 정의 (전체 트래픽 복원 전에 충족되어야 하는 조건)
- [ ] 인시던트 후 검토 프로세스 문서화
폴백 거버넌스
- [ ] 폴백 승인 매트릭스 존재 및 최신 상태 유지
- [ ] 고위험 워크로드 클래스에 대한 금지된 폴백 조건 문서화
- [ ] 정책 변경 승인 프로세스 정의 (엔지니어링 + 제품/위험)
- [ ] 월간 검토 일정 수립
인프라 탈출구
- [ ] 공유 API 속도 제한이 반복적인 제약 조건인 워크로드를 위한 전용 엔드포인트 또는 GPU Cloud 경로 식별
FAQ
멀티 프로바이더 라우팅 설계와 멀티 프로바이더 운영의 차이점은 무엇인가요?
라우팅 설계는 정책(기본 및 폴백 모델, 재시도 시기, 특정 오류 유형 처리 방법)을 결정합니다. 운영은 정책이 작동하는지 확인하는 지속적인 관행(SLO 소진 모니터링, 작동하지 않을 때 인시던트 플레이북 실행, 정책 변경 관리)입니다. 서비스가 가동 시간 약속을 안정적으로 이행하려면 둘 다 필요합니다.
멀티 프로바이더 LLM 서비스에 대한 현실적인 가동 시간 SLO는 어떻게 설정하나요?
대표적인 트래픽 윈도우에서 현재 성공적인 완료율과 P95 지연 시간을 측정하는 것으로 시작하세요. 라우팅 정책이 사용 가능한 오류 예산으로 현실적으로 지원할 수 있는 수준으로 SLO 목표를 설정하세요. 새 서비스의 경우 99.0%–99.5% 성공적인 완료율이 합리적인 시작 목표입니다. 처음 몇 개의 오류 예산 윈도우를 관찰한 후 조정하세요.
폴백 승인 매트릭스는 얼마나 자주 검토해야 하나요?
최소 월 1회, 그리고 폴백 동작이 예상치 못했거나 폴백 중 품질이 저하된 모든 인시던트 후에 검토하세요. 모델 기능과 가격은 충분히 자주 변경되므로 Q1에 유효한 매트릭스가 Q3에는 유효하지 않을 수 있습니다.
멀티 프로바이더 폴백이 자동이 되어서는 안 되는 경우는 언제인가요?
워크로드 클래스에 안전, 법률, 금융 또는 규정 준수 민감도가 있고 폴백 모델이 해당 특정 작업 유형에 대해 평가되지 않은 경우입니다. 이러한 경우 대기열에 넣거나 사용자에게 표시되는 사용 불가 상태가 품질이 낮은 자동 응답보다 더 안전합니다.
Novita AI는 이 운영 모델에 어떻게 적합합니까?
Novita AI는 위의 관행을 사용하여 계측하고 운영하는 인프라 계층(추론용 LLM API, 에이전트 실행용 Agent Sandbox, 전용 용량용 GPU Cloud)을 제공합니다. 서비스를 안정적으로 만드는 SLO 정의, 모니터링 구성, 플레이북 또는 거버넌스 결정을 대체하지 않습니다. 이러한 것들은 팀의 운영 관행에서 비롯됩니다.
추천 문서
- 더 낮은 비용과 다운타임을 위한 최고의 멀티 프로바이더 LLM 플랫폼 — 라우팅 설계: 폴백 정책, 비용 계층 모델 선택, 서킷 브레이커
- 2026년 최고의 LLM API 프로바이더
- AI 에이전트에 적합한 추론 프로바이더 선택하기
- Novita AI의 LLM 전용 엔드포인트
