AI Router로 모델 비용을 줄이는 방법과 외부 AI API 장애 시 페일오버 설계
公開日 2026-08-13 · 更新日 2026-08-13 · 最終検証日 2026-08-13
結論
비용을 줄이는 핵심은 모든 요청을 큰 모델에 몰아넣지 않는 것입니다. 분류나 추출 같은 정형 작업은 작은 모델로, 설계 판단이나 장문 추론은 큰 모델로 분기하고, 프롬프트 캐시, 출력 토큰 상한, 결과 캐시, 배치화를 함께 사용합니다. 저가 모델의 출력은 품질 게이트로 검증하고, 불합격인 경우에만 상위 모델로 재시도합니다. 장애 대책으로는 프로바이더를 추상화하고, 헬스체크와 서킷 브레이커, 429와 5xx의 구분 처리, 저하 운전 정의를 준비합니다.
この文書の適用条件
| 対象製品 | AI Router(복수의 LLM 프로바이더를 묶는 중계 계층) |
|---|---|
| 確認バージョン | 제품 버전에 의존하지 않는 설계상의 설명(가격·지연시간은 계속 변동하므로 이 글에서는 다루지 않습니다) |
| 適用環境 | AWS, Azure, 온프레미스 |
| 必要権限 | 각 프로바이더의 API 키 참조 권한과 Router 호스트에 대한 접근 권한 |
| 実行影響 | 참조만 수행(헬스체크는 운영 트래픽과 별도 경로) |
| 再起動 | 불필요(라우팅 정책을 동적으로 읽어들이는 경우) |
| 最終検証日 | 2026-08-13 |
そのまま実行できるコマンド
- 対象
- 자사 AI Router의 라우팅 정책 정의
- 権限
- 정책 정의 편집 권한
- 変更作業
- 없음(정의 작성 예시)
- Production実行
- 해당 없음(설계 샘플)
# 対象: 自組織のAI Routerのルーティングポリシー定義
# 権限: ポリシー定義の編集権限
# 変更作業: なし(定義の記述例)
# Production 実行: 該当なし(設計サンプル)
# 「小 / 中 / 大」は自組織で採用しているモデルの相対的な区分を指す。
# 具体的なモデル名と価格は変動するため、ここでは書かずに定義側で解決する。
タスク種別 | 既定の割り当て | 出力上限 | 品質ゲート | 不合格時の扱い
----------------------|----------------|----------|------------------------------|----------------------------
分類・ラベル付け | 小 | 短 | 許可ラベル集合に含まれるか | 中へ1回だけ再試行
構造化抽出(JSON) | 小 | 中 | JSONスキーマ検証 | 中へ1回だけ再試行
要約(短文) | 小 | 中 | 入力に無い固有名詞が無いか | 中へ1回だけ再試行
要約(長文・横断) | 中 | 長 | 参照元の提示があるか | 大へ1回だけ再試行
コード生成(定型) | 中 | 中 | 構文解析とテスト実行 | 大へ1回だけ再試行
設計判断・長文推論 | 大 | 長 | 人間のレビュー | 再試行しない(人へ回す)
自由入力の対話 | 中 | 中 | 出力フィルタ | 中で再試行(上位へ上げない)
共通の制御:
timeout: タスク種別ごとに設定。長文推論だけ長くする
max_retries: 2 まで。ジッタ付き指数バックオフ
prompt_cache: システムプロンプトと共通コンテキストは前方固定にして再利用する
result_cache: 入力のハッシュをキーにする。ただし個人情報を含む入力は対象外
batching: 即時性が不要なタスクのみ。締切のあるタスクは対象外
budget_guard: 日次・月次の上限に対する消費割合を監視し、しきい値で通知する
計測の前提:
- 振り分けの妥当性は、自組織の利用ログ(タスク種別ごとの件数・入出力量・
品質ゲートの合格率・上位モデルへの再試行率)で判断する
- 単価と提供モデルは変わるため、各プロバイダの現行の価格ページを定期的に確認する품질 게이트 없이 저가 모델로 몰아넣으면, 실패한 출력을 사람이 수작업으로 고치는 시간이 늘어납니다. 게이트 합격률과 상위 모델로의 재시도율을 기록하고, 재시도가 많은 작업 종류는 기본 할당을 올리십시오. 판단 자료는 자사의 이용 로그입니다.
- 対象
- 자사 AI Router(복수 프로바이더를 묶는 중계 계층)
- 権限
- 각 프로바이더의 API 키 참조 권한과 Router 호스트에 대한 셸 접근
- 変更作業
- 없음(연결 확인과 상태 파일 읽기/쓰기만 수행)
- Production実行
- 가능(운영 트래픽과 별도 경로의 헬스체크)
# 対象: 自組織のAI Router(複数プロバイダを束ねる中継層)
# 権限: 各プロバイダのAPIキー参照権限とRouterホストへのシェルアクセス
# 変更作業: なし(疎通確認と状態ファイルの読み書きのみ)
# Production 実行: 可能(本番トラフィックとは別経路のヘルスチェック)
STATE_DIR=/var/lib/ai-router/breaker
FAIL_THRESHOLD=5 # 連続失敗がこの回数に達したら OPEN にする
mkdir -p "$STATE_DIR"
for p in provider-a provider-b; do
# 軽量なエンドポイントを使う。本番の推論リクエストで死活を測らない
code=$(curl -s -o /dev/null -w "%{http_code}" --max-time 5 "https://$p.example.com/v1/models")
fails=$(cat "$STATE_DIR/$p.fails" 2>/dev/null || echo 0)
case "$code" in
200)
fails=0
;;
429)
# レート制限は「プロバイダは生きている」。切り離さずバックオフとキューイングで受ける
echo "$p: 429 rate limited -> backoff, do not open breaker"
;;
5*|000)
# 5xx と接続不能は障害として数える(000 は curl が到達できなかった場合)
fails=$((fails + 1))
;;
4*)
# 429 以外の 4xx はこちらのリクエストの問題。切り離しても直らない
echo "$p: client error $code -> check request, do not open breaker"
;;
esac
echo "$fails" > "$STATE_DIR/$p.fails"
if [ "$fails" -ge "$FAIL_THRESHOLD" ]; then
echo "$p: OPEN -> 新規ルーティングを停止し、次候補へ退避。一定時間後に HALF_OPEN で試行"
else
echo "$p: CLOSED (http=$code consecutive_fails=$fails)"
fi
done헬스체크에는 운영 추론 요청이 아니라 경량 엔드포인트를 사용하십시오. 추론으로 생존 여부를 측정하면 확인 행위 자체가 비용과 부하를 발생시킵니다. OPEN에서 복귀할 때는 전량을 한 번에 되돌리지 말고 일부만 흘려보내는 HALF_OPEN을 거치십시오.
結果の読み方
| 列 | 意味 | 確認するポイント |
|---|---|---|
| 작업 난이도별 분기 | 정형 작업은 작은 모델로, 판단이 필요한 작업은 큰 모델로 돌린다 | 작업 종류별 건수와 입출력량을 이용 로그로 파악하고 있는가 |
| 품질 게이트 | 저가 모델의 출력을 검증한 뒤 채택하는 구조 | 합격률과 상위 모델로의 재시도율을 기록하고 있는가 |
| 프롬프트 캐시 | 공통 앞부분을 재사용해 입력 중복을 줄인다 | 공통 부분이 앞쪽에 고정되고 가변 부분이 뒤에 오는가 |
| 출력 토큰 상한 | 작업 종류별로 출력 길이를 제한한다 | 상한으로 잘린 출력이 하위 처리에서 깨지지 않는 설계인가 |
| 결과 캐시 | 동일 입력에 대한 결과를 재사용한다 | 개인정보를 포함한 입력이 캐시 대상에서 제외되어 있는가 |
| 배치화 | 즉시성이 필요 없는 처리를 모아서 실행한다 | 마감이 있는 작업이 잘못 배치에 섞여 있지 않은가 |
| 재시도와 타임아웃 | 실패 시 재시도 횟수와 대기시간 방침 | 재시도가 비용과 대기시간을 늘리고 있지 않은가. 상한이 있는가 |
| 추상화 레이어 | 호출 측이 프로바이더 고유의 차이를 의식하지 않는 구조 | 프로바이더 하나를 중단해도 앱 코드 변경 없이 전환되는가 |
| 서킷 브레이커 | 연속 실패한 경로로의 전송을 멈추는 구조 | OPEN 조건과 복귀 조건이 정의되고, 복귀 시 일부부터 되돌리는가 |
| 429와 5xx의 구분 처리 | 레이트 제한과 장애를 별도로 취급하는 것 | 429로 경로를 차단하지 않고 있는가(백오프로 받고 있는가) |
| 큐잉과 백프레셔 | 유입을 받아내고 한계 시 상류를 대기시키는 것 | 큐의 상한과 초과 시 동작이 정의되어 있는가 |
| 저하 운전(degraded mode) | 전체 기능이 아닌 주요 기능만 유지하는 상태 | 어떤 기능을 멈추고 어떤 기능을 남길지 사전에 정해져 있는가 |
| 출력 차이 허용 기준 | 프로바이더가 바뀌면 출력이 달라지는 것에 대한 허용 범위 | 하위 처리가 스키마 검증으로 흡수할 수 있는 형태인가 |
| 비용 상한 알림 | 예상치 못한 소비를 알아챌 수 있는 구조 | 일간과 월간 양쪽을 보고 있는가. 알림 대상이 유효한가 |
こういう状況で使います
- AI 이용 요금이 예상보다 늘고 있는데 어떤 작업이 끌어올리는지 알 수 없다
- 모든 처리를 같은 큰 모델로 처리하고 있다
- 외부 AI API가 불안정해지면 앱 전체가 응답하지 않게 된다
- 429가 반환되었을 때 장애와 동일하게 취급해 경로를 차단해버리고 있다
- 프로바이더를 전환했더니 출력 형식이 바뀌어 하위 처리가 깨졌다
- 재시도가 빈발해서 대기시간과 비용이 동시에 늘고 있다
考えられる原因(可能性の高い順)
01
작업 난이도와 관계없이 같은 모델을 사용하고 있다
분류나 추출 같은 정형 작업과 설계 판단 같은 추론을 같은 경로로 흘리면, 정형 작업분까지 비싼 경로를 통과합니다. 먼저 작업 종류를 나누는 것이 전제가 됩니다.
02
출력 길이에 상한이 없다
출력 토큰 상한이 설정되어 있지 않으면 필요 이상으로 긴 출력이 생성될 수 있습니다. 하위 처리가 사용하는 길이를 기준으로 상한을 정하십시오.
03
재시도 방침이 없다
실패할 때마다 무제한으로 재시도하면 비용과 대기시간이 늘어납니다. 횟수 상한과 백오프, 그리고 재시도하지 않을 조건을 정하십시오.
04
프로바이더 고유 호출이 앱 전체에 흩어져 있다
추상화 레이어가 없으면 장애 시 전환이 코드 변경이 됩니다. 호출을 한 곳에 집약하면 전환이 설정 변경만으로 끝납니다.
05
레이트 제한과 장애를 구별하지 않고 있다
429는 프로바이더가 동작 중임을 나타냅니다. 이를 장애로 보고 경로를 차단하면, 기다리면 통과했을 요청까지 다른 경로로 돌아가 상황이 악화될 수 있습니다.
06
저하 시 무엇을 멈출지 정해져 있지 않다
모든 기능을 유지하려 하면 전체가 느려집니다. 사전에 우선순위를 정해두면 주요 기능만 유지할 수 있습니다.
確認手順
- 1
작업 종류별 이용 실적을 집계한다
参照のみ자사 이용 로그에서 작업 종류별 건수, 입력량, 출력량, 실패율을 집계합니다. 분기 설계의 출발점은 여기입니다.
- 2
출력 토큰 분포를 확인한다
参照のみ실제 출력 길이를 분포로 보고 상한을 어디에 둘지 판단합니다. 평균만으로는 상한을 정할 수 없습니다.
- 3
재시도 발생률과 원인을 구분한다
参照のみ타임아웃, 429, 5xx, 품질 게이트 불합격 중 어느 것으로 재시도하고 있는지 구분해서 집계합니다. 대응 방식이 다릅니다.
- 4
프로바이더의 현재 가격과 제공 모델을 확인한다
参照のみ각 프로바이더의 가격 페이지를 참조해 자사 집계값에 대입합니다. 가격은 계속 변동하므로 정기적으로 재검토하십시오.
- 5
프로바이더 하나를 중단한 상태로 동작을 확인한다
中검증 환경에서 한쪽 경로를 비활성화하고 앱이 코드 변경 없이 계속 동작하는지 확인합니다.
対応方法
すぐに実施できる低リスクの対応
작업 종류 태깅을 시작한다
低모든 호출에 작업 종류 레이블을 붙여 이용 로그에 남깁니다. 분기 판단 자료가 없는 상태를 먼저 해소합니다.
출력 토큰 상한을 설정한다
低작업 종류별로 상한을 설정합니다. 상한으로 잘린 출력을 하위 처리가 안전하게 다룰 수 있는지 확인하십시오.
비용 상한 알림을 설정한다
低일간과 월간 양쪽에 임계값을 두고, 알림 대상이 유효한지 확인합니다.
429와 5xx의 취급을 구분한다
低429는 백오프로 받고, 5xx와 연결 불가만 브레이커의 실패로 집계하도록 합니다.
事前検討が必要な変更
호출을 추상화 레이어로 집약한다
中프로바이더 고유 구현을 한 곳에 모으고, 앱 쪽은 공통 인터페이스로 호출하도록 합니다. 전환이 설정 변경만으로 끝나게 됩니다.
품질 게이트를 구현한다
中스키마 검증, 허용값 대조, 구문 분석, 테스트 실행 등 작업 종류에 맞는 검증을 넣습니다. 합격했을 때만 결과를 채택합니다.
프롬프트 캐시와 결과 캐시를 도입한다
中공통 앞부분을 앞쪽에 고정하고, 동일 입력의 결과를 재사용합니다. 개인정보를 포함한 입력은 캐시 대상에서 제외하십시오.
서킷 브레이커와 헬스체크를 넣는다
中경량 엔드포인트로 생존 여부를 측정하고, 연속 실패 시 OPEN, 일정 시간 후 HALF_OPEN으로 일부를 되돌리는 전이를 구현합니다.
저하 운전의 내용을 정의한다
中어떤 기능을 멈추고 어떤 기능을 유지할지 사전에 정하고, 전환 절차를 준비합니다.
専門家のレビューが必要な作業
기본 모델 할당을 변경한다
専門家レビュー必須주요 작업의 할당을 낮추면 비용은 줄지만, 품질 게이트 불합격률이 오를 수 있습니다. 단계적으로 적용하고 합격률을 관측한 뒤 넓히십시오.
큐잉과 백프레셔를 도입한다
専門家レビュー必須유입을 받아내는 설계는 상류의 대기시간이나 체감에 영향을 줍니다. 업무 요건과 맞춰 상한과 초과 시 동작을 정하십시오.
!注意事項
- 이 글은 모델 가격, 토큰 단가, 응답시간, 절감률 수치를 다루지 않습니다. 이는 제공사 측 사정으로 변동하며, 기재한 시점에 곧 낡은 정보가 되기 때문입니다. 판단은 자사의 이용 로그와 각 프로바이더의 현재 가격 페이지로 하십시오.
- 저가 모델로 몰아넣는 설계는 품질 게이트와 함께 도입하십시오. 게이트가 없으면 실패한 출력을 사람이 수작업으로 고치는 시간이 늘어나 전체적으로는 절약이 되지 않습니다.
- 429로 경로를 차단하지 마십시오. 레이트 제한은 프로바이더가 동작 중임을 나타내며, 대응은 백오프와 큐잉입니다.
- 프로바이더를 전환하면 출력의 세부 사항이 바뀝니다. 하위 처리가 스키마 검증으로 흡수할 수 있는 형태가 아니면, 페일오버가 또 다른 장애를 낳습니다.
- 캐시 대상에 개인정보를 포함한 입력을 넣지 마십시오. 캐시 키 설계에 따라 다른 이용자에게 결과가 반환될 수 있습니다.
- 헬스체크에 운영 추론 요청을 사용하지 마십시오. 확인 행위 자체가 비용과 부하를 발생시킵니다.
バージョン・環境による違い
これで解決しない場合に確認すること
비용을 끌어올리는 작업 종류를 특정한다
건수가 많은 작업과 건당 입출력량이 큰 작업을 구분해서 봅니다. 대응 방식이 다릅니다.
품질 게이트 불합격률을 종류별로 본다
불합격률이 높은 종류는 기본 할당을 올리는 쪽이 결과적으로 더 저렴할 수 있습니다.
캐시 적중 상황을 확인한다
적중하지 않는다면 키 설계나 입력 편차에 원인이 있습니다.
페일오버를 실제로 발동시켜 본다
검증 환경에서 한쪽을 내려 전환과 저하 운전이 예상대로 되는지 확인합니다.
각 프로바이더의 현재 가격 페이지를 확인할 시기를 정한다
가격과 제공 모델은 바뀝니다. 재검토 주기를 운영 절차에 포함하십시오.
この文書の根拠と限界
一般的な技術説明
라우팅과 페일오버 설계는 가용성 설계와 캐시 설계의 일반적인 기법을 AI API에 적용한 것입니다. 모델 가격, 토큰 단가, 응답시간, 비용 절감률은 변동하며 검증도 할 수 없으므로 이 글에서는 전혀 기재하지 않았습니다. "GIIP 대응 범위" 단락만 GIIP 자체의 운영 형태에 대한 기술입니다.
よくある質問
어떤 작업을 작은 모델로 돌려도 됩니까?
출력의 정확성을 기계적으로 판정할 수 있는 작업입니다. 분류라면 허용 레이블 집합과의 대조, 구조화 추출이라면 JSON 스키마 검증, 코드 생성이라면 구문 분석과 테스트 실행으로 판정할 수 있습니다. 판정 수단이 없는 작업은 저가 경로로 돌려도 품질을 담보할 수 없습니다.
실제로 비용이 얼마나 줄어듭니까?
이 글에서는 수치를 제시하지 않습니다. 효과는 작업 구성 비율, 입출력 길이, 품질 게이트 합격률에 의존하며, 프로바이더 가격도 변동하기 때문입니다. 자사 이용 로그로 작업 종류별 입출력량을 집계하고, 각 프로바이더의 현재 가격 페이지에 대입해 추정하십시오.
429가 반환되었을 때 다른 프로바이더로 전환해야 합니까?
원칙적으로 백오프와 큐잉으로 받습니다. 429는 프로바이더가 동작 중임을 나타내므로, 차단해도 상황은 개선되지 않습니다. 대기시간이 업무상 허용되지 않는 경우에만 다른 경로로의 대피를 검토하십시오.
서킷 브레이커는 언제 OPEN으로 해야 합니까?
5xx와 연결 불가가 연속될 때입니다. 임계값은 자사의 실측 실패율로 정합니다. 복귀는 일정 시간 후 HALF_OPEN으로 일부만 흘려보내고, 성공하면 CLOSED로 되돌립니다.
프로바이더를 전환하면 출력이 바뀌어 버립니다. 어떻게 대응합니까?
하위 처리가 스키마 검증으로 흡수할 수 있는 형태로 만들고, 수용 기준을 "형식이 올바르고 필수 항목이 갖춰져 있는지"로 두십시오. 문구 일치를 전제로 한 처리가 있으면 페일오버마다 깨집니다.
저하 운전에서는 무엇을 멈춰야 합니까?
사전에 정해 두어야 합니다. 일반적으로 즉시성이 필요 없는 보조 기능(추천, 요약, 자동 태깅)을 먼저 멈추고 업무의 주요 흐름을 유지합니다. 순서를 장애 시점에 생각하면 판단이 늦어집니다.
この文書がカバーする質問
- 외부 AI API 장애 시 Failover 설계는 어떻게 하나요
- LLM 이용 요금을 줄이려면 어디서부터 시작해야 하나요
- 복수의 AI 프로바이더를 전환할 수 있는 구성을 만들고 싶어요
リスク表示の意味
- 参照のみデータと設定を変更しません。
- 低影響は限定的ですが、権限と負荷の確認が必要です。
- 中性能・ロック・コストに影響する可能性があります。
- 高障害・データ損失・復旧作業が発生する可能性があります。
- 専門家レビュー必須本番適用前に別途レビューが必須です。
GIIPの対応範囲
여기까지의 설계는 특정 제품을 사용하지 않고도 구현할 수 있습니다. GIIP에서는 복수의 AI 모델을 용도에 맞게 나누어 쓰는 구성을 취하고 있으며, 외부 API가 불안정할 때 처리가 멈추지 않도록 경로 전환과 저하 운전을 운영 절차에 포함하고 있습니다. 실제로 어느 구분에 어느 모델을 적용할지는 다루는 작업의 종류와 품질 요건에 따라 달라지므로, 자사의 이용 로그를 바탕으로 결정해야 합니다. 판단 자료 집계 방법부터 정리하고 싶다면 상담을 요청할 수 있습니다.
執筆・技術検証
GIIP プロダクション運用チーム
大規模Webサービス、SQL Server、Oracle、AWS、Azureの設計・移行・運用に約30年従事。x12largeクラスのAWS RDS for SQL Server環境12セット、約12万テーブルのOracle環境、約3TBのTiDBからAurora MySQLへの移行を経験。現在も複数のクラウドデータベースと約30のWebサービスを、AIエージェントと人間の専門家が継続的に監視・運用しています。
AI 자동 실행에 승인과 롤백이 필요한 이유와 설계 방법
자동 실행의 설계 요소(스냅샷·승인 게이트·dry-run 분리·allowlist·멱등성·감사 로그·단계적 전개·중지 스위치)와, 승인 없이 실행해서는 안 되는 작업의 경계를 정리합니다.
ai-operationsAI가 만든 애플리케이션을 프로덕션에 올리기까지 필요한 작업
"동작하는 코드가 완성됐다"에서 "프로덕션에서 운영 가능하다"까지 남는 작업을 14개 항목으로 정리하고, 하드코딩된 키 탐지와 의존 패키지 취약점 확인 명령을 함께 제공합니다.
awsAWS 데이터베이스 비용을 재검토할 때 확인할 항목
AWS 데이터베이스 비용을 영향이 작은 순서(미사용 정지 → right-sizing → 스토리지 → 백업 → 비운영 → 커밋먼트)로 재검토하기 위한 체크리스트입니다.
giip코딩 에이전트와 GIIP FDE Ops는 무엇이 다른가
코딩 에이전트와 운용 서비스는 "작업의 단위"가 다릅니다. 두 영역의 스코프 경계를 9가지 관점에서 비교하고, 자사에서 확인할 수 있는 명령을 함께 제공합니다.
関連サービス
AI 이용의 비용 구조를 시각화하기
同じ確認を複数の環境で継続する必要がある場合は、運用体制ごと相談できます。
AI 이용의 비용 구조를 시각화하기