비용·성능·장애 관리

7.3 비용·성능·장애 관리

세부 학습 목표

• 쿼터·RPM·TPM·PTU·일시 용량 부족과 요청 집중을 구별한다.
• 토큰·검색·평가·저장·로그의 총비용을 계산하고 제한·재시도를 설계한다.
• trace·토큰·안전·근거성·드리프트·단계 지연으로 운영 오류를 진단한다.

개요

• 수용량: 요청 수·토큰 수·동시 실행 제한 확인.
• 비용: 모델·검색·저장·평가·로그 비용 합산.
• 장애 진단: 같은 요청의 단계별 기록으로 병목 조사.
• 개선: 동일 평가 조건에서 품질·지연·비용을 함께 비교.

사용량 제한과 비용 예산

• TPM은 분당 토큰, RPM은 분당 요청 수입니다.

  긴 입력을 보내면 요청 수가 적어도 토큰 제한에 먼저 도달할 수 있습니다. 반대로 짧은 요청을 아주 많이 보내면 요청 수 제한이 문제가 됩니다. 실제 제한은 모델·버전·배포 유형에 따라 다르며, 모델별로 구독/지역 등의 quota 관리 범위도 확인해야 합니다. 리소스만 새로 만들면 항상 한도가 늘어난다고 가정하지 않습니다.

• 2026년 10월 문서 기준, Azure OpenAI의 TPM 할당과 RPM은 모델별 비율로 연결되므로 두 값을 독립적으로 설정한다고 가정하지 않습니다.

  TPM 기반 제한 계산은 실제 청구 토큰 수가 아니라 요청 시점의 추정 처리량과 최대 출력 설정 등을 반영합니다. RPM도 1분 총량만 보지 말고 짧은 시간의 요청 집중을 확인합니다. PTU 배포는 별도의 사용률 기반 제한 방식을 확인합니다.

• Azure OpenAI의 429는 제한 초과뿐 아니라 일시적 처리 용량 부족이나 유효 제한 조정에서도 발생할 수 있습니다.

  오류 본문과 서비스가 제공하는 retry-after-ms, x-ratelimit-* 응답 헤더를 함께 확인합니다.

• 429가 발생하면 즉시 같은 요청을 무한 반복하지 않습니다.

  서비스가 제공한 대기 안내를 확인하고, 횟수와 전체 제한 시간을 둔 지수 백오프·임의 지연을 적용합니다. 여러 요청이 동시에 재시도하면 혼잡을 더 키울 수 있으므로 큐와 동시 실행 제한도 함께 검토합니다. 결제·발주처럼 부작용이 있는 작업은 재시도 전에 중복 실행 방지가 필요합니다.

• 예산 경고는 사용량을 관찰하는 기능입니다.

  경고를 설정한 것만으로 모든 리소스가 즉시 중지되는 예산 차단기가 되지는 않습니다. 앱에서 사용자별 요청 제한, 최대 출력 길이, 작업 취소 같은 제어를 따로 설계합니다.

비용을 계산하는 연습

다음 단가는 계산 연습용으로 만든 값이며 실제 Azure 요금이 아닙니다. 텍스트 입력·출력만 계산하고 검색·이미지·음성·캐시·예약 용량 등은 제외했습니다.

from decimal import Decimal
 
requests = Decimal("1000")
input_tokens = Decimal("1200")
output_tokens = Decimal("300")
input_price_per_million = Decimal("2")
output_price_per_million = Decimal("8")
 
cost = requests * (
    input_tokens * input_price_per_million
    + output_tokens * output_price_per_million
) / Decimal("1000000")
assert cost == Decimal("4.8")
print(f"예상 비용: {cost:.2f} 단위")

• 요청 1,000건의 계산 결과는 4.80 단위입니다.

  실제 견적에서는 모델의 청구 단위와 배포 유형을 확인하고, Search·Storage·Application Insights 등 함께 쓰는 서비스 비용을 더합니다. 개발·평가·운영 리소스를 태그로 구분하면 비용 증가 원인을 찾기 쉽습니다. 비용 데이터에는 집계 지연이 있을 수 있으므로 같은 기간과 같은 리소스 범위로 비교합니다.

지연을 단계별로 나눈다

• Trace는 하나의 요청에 대한 실행 기록이고, span은 그 안의 개별 작업입니다.

  OpenTelemetry로 검색, 모델 호출, 도구 실행의 시간과 성공 여부를 묶으면 느려진 구간을 구분할 수 있습니다. 이는 관측 가능한 실행 기록을 살펴보는 것이며 모델의 비공개 내부 추론을 얻는다는 뜻이 아닙니다.

• 예를 들어 총 8초 중 검색 0.3초, 모델 호출 1.2초, 업무 API 6초라면 모델만 교체해도 큰 개선이 없을 수 있습니다.

  병렬 실행 구간은 시간이 겹치므로 span의 소요 시간을 단순 합산한 값이 전체 시간과 항상 같지는 않습니다. 평균 외에 p95처럼 느린 요청 구간의 값과 오류율, 처리량도 확인합니다.

개선 전후에 같은 조건을 사용한다

• 작은 모델로 교체하거나 검색 문맥을 줄이면 비용이 내려갈 수 있지만 근거 누락이 늘 수 있습니다.

  4.2의 평가 세트를 고정하고 품질·지연·비용을 함께 비교합니다. 로그에는 요청 ID, 버전, 지연, 토큰 수 같은 진단 정보를 남기되 개인정보와 비밀 값의 저장 여부·보존 기간을 정합니다. 로그 저장량 자체도 비용에 포함됩니다.

TPM·RPM으로 수용량 계산

• TPM(Tokens Per Minute)과 RPM(Requests Per Minute)은 서로 다른 기준으로 검사되는 제한입니다.

  그러나 Azure OpenAI의 일부 모델·배포 유형은 할당한 TPM에서 RPM이 모델별 비율로 결정되므로 두 한도를 독립적으로 설정하지 못합니다. 토큰 속도 제한은 청구된 실제 출력 토큰이 아니라 프롬프트와 최대 출력 설정 등을 활용한 요청 시점 추정치로 적용될 수 있습니다.

• 상황: 가상의 처리 제한으로 TPM 60,000, RPM 120이 주어지고 요청당 제한 계산에 반영되는 추정 토큰이 1,000개라고 가정하자.

  분당 80건을 보낼 수 있는가?

• 적용: 가정한 조건에서 토큰 측 상한은 60,000÷1,000=분당 60건이고 RPM 가상 상한은 120건이므로 80건은 전부 처리할 수 없습니다.

  실제 Azure에서는 모델별 연계 RPM 제한과 요청 추정 토큰·순간 버스트까지 고려해야 합니다.

• TPM·RPM 할당과 계산 

429와 재시도 정책

• HTTP 429는 정해진 RPM·TPM 제한을 넘긴 경우 외에도 일시적인 서비스 처리 용량 부족이나 유효 제한의 일시적 조정으로 발생할 수 있습니다.

  오류 문구, retry-after-ms 및 x-ratelimit 헤더를 확인하고, 제한 횟수의 재시도와 지수 백오프·지터를 적용합니다. 응답이 성공하지 않았더라도 일부 요청이 제한 계산에 포함될 수 있습니다.

• 상황: 100명의 사용자가 동시에 429를 받은 뒤 모두 1초 간격으로 재호출합니다.

• 적용: 429의 오류 메시지와 retry-after-ms 헤더로 제한 초과와 일시적 용량 문제를 구분합니다.

  재시도 횟수를 제한하고 지수 백오프·지터·동시성 제어를 적용합니다. 여러 사용자가 동시에 재호출하지 않도록 큐도 고려합니다.

• HTTP 429 원인·응답 헤더 

토큰 비용과 요청 예산

• 요금은 모델, 배포 유형 및 적용되는 가격 정책에 따라 달라집니다.

  단가를 하드코딩하지 않고 기준 일시·단위를 명시해야 가격이 바뀌어도 예산을 다시 계산할 수 있습니다.

• 상황: 1일 2,000회 호출, 평균 입력 1,500토큰, 출력 500토큰이 발생합니다.

• 적용: 입력 3,000,000토큰, 출력 1,000,000토큰입니다.

  모델별 입력 단가와 출력 단가 및 적용 단위를 각각 곱해 계산합니다.

운영 확장 병목 찾기

• 병목은 종속 서비스 중 어디에서든 발생할 수 있습니다.

  응답 지연만 보고 모델을 늘리기보다 단계별 trace와 제한·CPU·검색시간 지표를 비교합니다.

• 상황: 전체 응답은 5초인데 모델 추론 700ms, 검색 3.8초, 후처리 500ms입니다.

• 적용: 전체 지연 중 검색이 차지하는 시간을 먼저 검토하고, 쿼리 실행·인덱스·네트워크의 병목을 개선한 뒤 모델 확장을 고려합니다.

확인 문제

할당: 60,000 TPM / 분당 요청 수 제한은 여유
정상 시: 20 requests/min × 예상 2,000 tokens = 40,000
변경 후: 20 requests/min × 예상 4,000 tokens = 80,000
응답: 429 / Retry-After=10
현재 재시도: 즉시 3회

                     이전       후보
검색 p95              180ms     190ms
도구 p95              300ms    1900ms
모델 p95              900ms     910ms
답변의 근거 불일치율      3%        12%
불일치 답변별 trace: 아직 연결하지 않음

trace T9 / total=12.0s
retrieval:    0.0–0.4s
tool attempt: 0.4–1.4s / timeout
retry wait:   1.4–9.4s
tool retry:   9.4–10.0s / success
model:       10.0–12.0s

참고 자료

• Microsoft Foundry Models quotas and limits 
• Plan and manage costs for Microsoft Foundry 
• Agent tracing overview 
• Observability in generative AI 
• Manage Azure OpenAI in Microsoft Foundry Models quota 

자료 확인: 2026-10-22 · 적용 사례 교정: 2026-10-23. 사례는 교육용이며 Azure API 호출·요금은 실행 검증하지 않았습니다.

요청 수는 비슷한데 입력 문서 길이가 두 배가 됐고 지연·토큰 사용이 함께 늘었습니다. 연결 장애는 관찰되지 않았습니다.