온콜 에이전트, 7부. 사이징: 아무도 미리 하지 않는 토큰 계산

이 플랫폼에서 깊은 인시던트 조사 한 건, 트리아지 에이전트가 진단을 제안할 만큼의 증거를 모으기까지 도구 호출 여덟 라운드는 32,950토큰이 들고, 그중 31,600이 입력이다. Bedrock의 Converse API가 매 라운드마다 계속 자라나는 트랜스크립트 전체를 다시 보내기 때문이다. 여기에 실제 알람 볼륨을 곱하면 플랫폼의 월간 온디맨드 모델 청구서 전체가 약 14달러, 총 월 비용 약 21달러 안에서도 작은 축에 드는 항목이 된다. 1부가 명시적으로 미뤄둔 일, 즉 첫날부터 Provisioned Throughput을 사는 것은 손익분기에 필요한 사용률의 대략 400분의 1로 도는 워크로드에 월 15,768달러를 쓰는 일이었을 것이다. 어느 것도 다이어그램에서는 자명하지 않다. 누군가 산수를 해야만 드러나며, 이번 편이 그 산수를 처음부터 끝까지 한다. 모든 숫자는 Bedrock 가격표나 전체가 공개된 공식으로 추적 가능하다.

1부는 시나리오, 계정 30개에 걸친 주당 40건의 페이지를 정하고 대안들 대신 AgentCore와 Strands를 골랐다. 2부는 계정 경계와 추론 프로파일 배선을 구축했고, 이번 편이 답하는 바로 그 질문, Provisioned Throughput의 시간당 요금이 온디맨드의 토큰당 요금을 이기는 지점을 명명했다. 3부는 아래에서 비용이 매겨지는 그 라운드들, 트리아지 에이전트의 도구 호출 루프를 내놓았다. 4부는 그 도구들을 AgentCore Gateway 뒤로 옮겼다. 5부는 이번 편의 월 청구서가 이제 감당해야 하는 수퍼바이저, 런북, 비용 에이전트를 더했다. 6부는 모든 호출에 Guardrails를 붙였고, 그 결정은 이번 편의 청구서에 예상보다 더 크게 작용하는 것으로 드러난다. 아래의 모든 숫자는 동반 저장소 github.com/flightlesstux/agents-on-call의 docs/sizing-model.md에, 이 가상 회사의 숫자 대신 실제 숫자로 다시 돌려보기 위한 체크리스트와 함께 있다.

토큰 계산, 풀어본 예제

Converse API는 서버 측 대화 상태를 전혀 유지하지 않는다. 모든 도구 호출 라운드가 지금까지의 트랜스크립트 전체, 즉 시스템 프롬프트, 도구 스키마, 이전의 모든 도구 호출과 그 결과를 다시 보낸다. 입력 토큰이 라운드에 선형으로 늘지 않고 이미 보낸 모든 것의 합으로 늘어난다는 뜻이며, 더 긴 조사는 자기 자신의 역사에 대한 값을 거듭거듭 치른다. 구성 요소는 가정하는 대신 명시적으로 선언한다. 모든 호출에 동일한 1,800토큰의 정적 프리픽스(시스템 프롬프트, 도구 스키마, 가드레일 설정), 400토큰의 초기 알람 페이로드, 라운드당 150토큰의 어시스턴트 출력, 라운드당 덧붙는 350토큰의 도구 결과, 라운드마다 500토큰의 증가다. 라운드 r의 입력 크기는 S + 400 + 500*(r-1)이다.

3라운드에 해결되는 얕은 조사는 이렇게 생겼다:

증거가 쌓이기까지 더 많은 계정, 더 많은 도구, 더 많은 왕복이 필요한 8라운드짜리 깊은 조사는 이렇게 생겼다:

총 32,950토큰, 얕은 조사의 8,700 대비 2.7배의 라운드 수에 3.8배의 비용이다. 그 간극이 눈에 보이게 된 재전송 페널티다. total_input(N) = N*(S+400) + 500*N*(N-1)/2는 라운드 수에 선형이 아니라 이차식으로 자란다. 8라운드가 1라운드부터 7라운드까지의 값을 전부 다시 치르고 있기 때문이다.

1부의 온콜 데이터가 여기에 실제 볼륨을 댄다. 주당 40건의 페이지를 70/30으로 나눠 얕은 조사 28건과 깊은 조사 12건이다. 주당 얕은 조사 243,600토큰과 깊은 조사 395,400토큰, 합해서 639,000토큰이고, 트리아지 에이전트 하나만으로 월 약 277만 토큰이다. 런북, 비용 스윕, 수퍼바이저 에이전트가 대략 110만을 더해, 플랫폼 전체로 월 387만 토큰 근처가 된다. 런북 에이전트의 Knowledge Base 보강 라운드와 비용 에이전트의 일일 스윕을 포함한 에이전트별 전체 내역은 동반 문서에 있다. 다음 절로 들고 갈 숫자는, 이 볼륨에서는 이 중 무엇도 크지 않다는 것이다.

꾸준한 스윕 대 버스트 인시던트

비용 에이전트의 볼륨은 일부러 매끈하다. 하루 한 번 예약된 EventBridge 실행, 업무 외 시간, 인시던트와 1분도 겹치지 않는다. 트리아지 에이전트의 볼륨은 매끈하지 않으며, 평균은 그것을 숨긴다. 고르게 펴면 주당 606,000 입력 토큰은 분당 약 60토큰이다. 실제 인시던트는 상관되어 온다. 하나의 업스트림 장애가 같은 5분 안에 알람 여덟 개로 퍼지면 트리아지 세션 여덟 개가 돌기 시작하고, 그 첫 라운드들이 같은 TPM 윈도우에 내려앉는다. 수퍼바이저 자신의 디스패치 호출을 세기도 전에 트리아지만으로 그 1분에 8 x 2,200 = 17,600 입력 토큰이다. 매끈하게 편 평균의 대략 290배가, 정확히 장애가 진행 중이고 플랫폼이 계속 응답할 수 있는지가 가장 중요한 그 10분에 몰린다. 평균이 아니라 피크에 맞춰 사이징하라. 평균은 다음 달 인보이스에 찍히는 것이고, 피크는 알람 폭풍이 답을 받는지 `ThrottlingException`을 받는지를 결정하는 것이다.

쿼터, 스로틀링, 아프기 전에 알람 걸기

Bedrock의 두 호출 엔드포인트는 쿼터를 다르게 강제하며, 그 차이가 버스트가 실제로 부딪히는 대상을 바꾼다. bedrock-runtime 엔드포인트는 입력과 출력 토큰을 합쳐 모델별 단일 TPM 쿼터에 대해 세고, RPM은 모델마다 다르다. 일부 최상위 모델은 RPM 쿼터가 아예 없이 토큰만으로 관리된다. bedrock-mantle 엔드포인트는 입력과 출력을 별도의 토큰 쿼터로 나누고 RPM을 완전히 없앤다. 어느 쪽이든 쿼터는 계정과 리전 단위이며, 이 플랫폼이 돌리는 모든 에이전트가 공유하고 에이전트별로 할당되지 않는다. 그래서 상관된 알람 폭풍 동안 수퍼바이저의 디스패치 호출과 트리아지 에이전트의 8라운드 조사가 같은 풀에서 꺼내 쓴다. 올해 초 변경으로 셀프서비스 쿼터 증설 요청이 두 엔드포인트를 모두 덮게 됐다. 이전에는 bedrock-mantle이 서포트 티켓을 요구했다. 실제 간극 하나를 닫지만, 인시던트가 찾아내기 전에 상한을 알아야 할 필요까지 없애주지는 않는다.

Bedrock SDK 자체의 재시도 로직은 스로틀링 응답에 백오프하지만, 그것은 버스트를 다듬을 뿐 쿼터 여유를 만들어내지 않는다. 더 유용한 수는 어떤 재시도보다도 상류에 있다. 재시도가 이미 흡수한 첫 ThrottlingException이 아니라 쿼터 사용률 자체에 알람을 걸어라. TPM 상한의 70%에서 울리는 쿼터 사용률 알람은, 알람 폭풍이 온콜 엔지니어에게 성능이 떨어진 트리아지 에이전트를 안기기 며칠 전에 용량 계획 쪽에 페이지를 준다. 스로틀링 오류가 첫 신호가 되도록 기다린다는 것은, 이 플랫폼의 도움이 가장 필요한 인시던트가 플랫폼 자신의 오류 예산을 도구 호출 대신 재시도에 써버리는 인시던트가 된다는 뜻이다.

버스트 여유로서의 크로스 리전 프로파일

2부는 안정성을 위해, 그리고 토큰당 추가 비용 없이, 이 플랫폼 전체를 크로스 리전 추론 프로파일 위에 올렸다. 그 결정의 사이징 관점은 이렇다. TPM 쿼터는 리전의 엔드포인트 범위이므로, 크로스 리전 라우팅은 한 리전의 상한을 소진할 버스트가 단일 리전의 한도 뒤에 줄을 서는 대신 형제 리전의 별도 상한으로 흘러넘칠 수 있다는 뜻이다. 무제한 여유는 아니고 실제 상한을 아는 일을 대신하지도 않지만, 한 리전의 쿼터를 공짜로 지리 하나만큼의 쿼터로 바꿔주며, 이 플랫폼이 사는 대부분의 용량 여유보다 나은 거래다.

Provisioned Throughput 경제학: 손익분기점, 그리고 지금 사는 것이 왜 틀렸는가

Model Unit은 고정된 입력, 출력 토큰/분 상한과 맞바꿔 항상 청구되는 균일 시간당 요금을 산다. 선택한 모델의 가격표와 MU 처리량이 무엇이든 그렇고, AWS는 어느 쪽도 모델과 무관한 고정 숫자로 게시하지 않으므로 아래 공식은 AWS의 사실이 아니라 선언된 플레이스홀더 값을 쓰며, 누구든 실제 돈을 쓰기 전에 라이브 콘솔의 숫자가 필요하다:

max_monthly_input  = T_in  * 60 * 730   # 730 hours in an average month
max_monthly_output = T_out * 60 * 730

on_demand_equiv_cost = (max_monthly_input  / 1000) * I
                      + (max_monthly_output / 1000) * O

pt_monthly_cost        = P * 730
break_even_utilization = pt_monthly_cost / on_demand_equiv_cost

예시용 플레이스홀더(MU당 입력 200,000, 출력 100,000 토큰/분, 온디맨드 1,000토큰당 0.003달러와 0.015달러, 무약정 MU-시간당 21.60달러)로 계산하면, 그 MU 상한의 100% 사용률은 온디맨드로 월 91,980달러 가치이고, PT 자체는 월 15,768달러이며, 손익분기는 지속 사용률 17.14%에 떨어진다. 그 비율을 넘으면 PT가 싸다. 그 아래에서는 온디맨드가 이기며, 일을 하는 단어는 "지속"이다. 이것은 월 평균이고, 두 절 위의 버스트 예제는 상한을 1분 치는 것이 상한을 지속하는 것과 같지 않은 이유를 정확히 보여준다.

이 플랫폼의 실제 월 입력 볼륨 약 365만 토큰은 그 MU의 월 입력 상한의 0.042%로, 17.14% 손익분기점보다 대략 411배 아래다. 1부가 미루고 2부가 이 계산이 먼저 필요하다고 표시한 바로 그 수, 첫날 MU 하나를 사는 것은 온디맨드 모델 청구서 전체가 약 14달러인 워크로드를 지키려고 월 15,768달러를 쓰는 일이었을 것이다. 잘못은 산수가 아니라 산수를 전혀 하지 않는 것, 그리고 에이전트 네 개에 걸친 요청률 분포가 측정되기도 전에 월 요금에 약정하는 것이다. 측정 전에는 온디맨드, 프로비저닝은 그 후에만. 이는 신중함을 위한 신중함이 아니라 손익분기 계산이 실제로 말하는 바다.

프롬프트 캐싱이 같은 계산에 하는 일

캐싱은 토큰 계산 절의 재전송 페널티를 거의 해결된 문제로 바꾼다. 캐시된 프리픽스는 90% 할인으로 읽히고, 캐시에 새로 쓰는 내용은 그 배수 외의 별도 요금 없이 정상 입력 가격의 1.25배다. 라운드별로 적용하면, 1라운드는 전체 입력을 캐시에 쓰고, 이후 모든 라운드는 직전 라운드의 입력 전체를 정상가의 10%로 읽으며, 새로 덧붙는 500토큰에만 정가 더하기 25%를 치른다:

billing_input(1) = input(1) * 1.25
billing_input(r) = input(r-1) * 0.10 + 500 * 1.25   # r >= 2

얕은 조사의 캐시 적용 과금 환산 입력은 8,100에서 4,490토큰으로, 44.6% 줄어든다. 깊은 조사는 31,600에서 9,715로 69.3% 줄어드는데, 더 큰 이유는 캐싱이 상쇄하는 재전송 페널티가 라운드가 늘수록 복리로 붙기 때문이다. 캐싱은 캐싱 없는 비용이 더 아픈 곳에서 정확히 더 크게 돕는다. 달러로는 깊은 인시던트의 총 비용(입력 더하기 출력, 출력은 캐싱의 영향을 받지 않는다)이 0.1151달러에서 0.0494달러로 57.1% 떨어진다. 트리아지 에이전트의 주간 믹스 전체에 적용하면 그 에이전트 하나의 월 모델 비용이 10.02달러에서 5.29달러로, 4.73달러, 47.2% 절감이다. 같은 메커니즘이 런북과 비용 스윕 에이전트 자신의 멀티 라운드 루프에도 더 작은 절대 규모로 적용된다. 훨씬 덜 자주 돌기 때문이다. 동반 문서는 볼륨과 라운드 수가 가장 많아 효과가 가장 큰 에이전트인 트리아지에 대해서만 전체 재계산을 싣는다.

플랫폼 전체의 월 비용 모델

모든 항목을 모아, 출처가 있는 AgentCore와 Guardrails 가격을 위의 토큰 볼륨에 대입하고, 모델 토큰 줄은 트리아지 에이전트 캐싱 적용 전후를 모두 보이면 이렇다:

곱씹을 것이 둘 있다. Runtime, Gateway, Memory는 이 볼륨에서 반올림 오차다. 초 단위 과금과 모델을 기다리는 유휴 시간 무과금 덕에, 동시성과 세션 길이가 자릿수 단위로 오르기 전까지 관리형 인프라는 거의 잡히지도 않는다. Guardrails는 반올림 오차가 아니다. 캐싱 없는 합계의 대략 30%로, Runtime, Gateway, Memory를 합친 것보다 약 15배 비싸고, 캐싱이 모델 줄을 줄인 뒤에는 자신이 스캔하는 모델 청구서의 거의 3분의 2 크기다. 모델의 토큰 수에서 멈추는 사이징 연습은 실제 청구서의 3분의 1을 놓치며, 그것은 대부분의 사람이 비용이 아니라 컴플라이언스를 위해 사이징하는 서비스에 앉아 있다.

에이전트별 모델 라이트사이징

위의 토큰 계산은 모든 에이전트에 모델 하나를 가정하는데, 그것은 쉬운 기본값이지 옳은 최종 상태가 아니다. 네 에이전트는 모델에게 진짜로 다른 것을 요구한다. 트리아지는 도구 출력으로부터의 구조화된 진단이다. 증거가 들어가고 그럴듯한 근본 원인의 유한한 집합이 나온다. 시스템 프롬프트와 도구 스키마가 빡빡해지고 나면 더 작고 싼 모델이 잘 처리하는 일이며, 정확히 3부의 낮은 temperature 설정이 이미 맞춰져 있던 워크로드다. 비용 에이전트의 일일 스윕은 대부분 도구가 이미 가져온 숫자에 대한 집계와 임계값 비교로, 출력 형식을 안정적으로 따르는 가장 작은 모델에 더욱 잘 맞는다. 런북 에이전트가 더 강한 모델이 더 높은 토큰당 가격값을 하는 유일한 자리다. 4부의 승인 게이트 뒤에서 사람이 곧 승인할 바로 그 SSM 문서와 파라미터를 작성하고 있고, 거기서의 실수는 어차피 다른 누군가가 재확인하는 진단 속 실수가 아니라 실제 블라스트 반경을 가진 실수다. 모든 에이전트를 같은 모델로 기본 설정하는 대신 실수의 실제 비용에 모델 크기를 맞추는 것은, 프롬프트 캐싱과 PT 뒤에 있는 것과 같은 본능이다. 과제가 필요로 하지 않는 능력에 쓰지 말고, 오답이 비싼 곳에 써라. "잘 처리한다"를 추측에서 믿을 만한 숫자로 바꿔주는 것이 8부의 평가 하네스다.

지켜봐야 할 실패 모드

이 모델이 실제 계정을 상대로 돌아가기 전에 알아둘 가치가 있는 것이 넷이다. 첫째, 위의 모든 달러 수치는 이 시리즈가 일부러 특정 Bedrock 모델 하나에 고정하지 않은 두 플레이스홀더 입력, 온디맨드 토큰당 가격과 Provisioned Throughput MU 처리량 상한에 의존한다. 합계를 믿기 전에 라이브 가격 페이지의 값을 넣어라. 낡은 플레이스홀더는 명백히 틀린 청구서가 아니라 자신만만하게 틀린 청구서를 만든다. 둘째, 350토큰의 도구 결과 가정은 거의 확실히 보수적이다. 실제 CloudWatch 메트릭 덤프나 로그 발췌는 그 5배에서 10배가 될 수 있고, 라운드에 걸쳐 이차식으로 복리가 붙는 항이므로 거기서의 과소평가는 하류의 모든 숫자를 고정 오프셋이 아니라 비례해서 줄인다. 셋째, 손익분기 계산은 월 평균이다. 실제 트래픽이 버스트 절처럼 생긴, 길게 조용하다가 상관된 스파이크가 몰아치는 플랫폼은 서류상 손익분기 근처에도 못 가면서 정작 중요한 그 10분 동안 스로틀링당할 수 있으며, 이는 어느 쪽이든 PT 구매보다 크로스 리전 여유와 쿼터 알람을 지지하는 논거다. 넷째, 프롬프트 캐싱의 절감은 캐시 히트가 실제로 성사되는 데 달려 있다. 월 중에 수정된 시스템 프롬프트나 도구 스키마는 캐시된 프리픽스를 무효화하고, 캐시가 다시 차기 전까지 캐싱 없는 전체 비용을 잠시 되살린다. 어떤 프롬프트 변경 후에든 지켜볼 일이지, 없다고 가정할 일이 아니다.

다음으로 읽을 글

• 6부, 가드레일: 모두가 건너뛰는 부분, 이번 편의 월 비용 모델이 기대는 Guardrails 단위 가격과, 얼마나 많은 텍스트가 실제로 스캔되는지를 결정하는 호출 패턴을 다룬다.
• 8부, 프로덕션: 옵저버빌리티, 평가, 그리고 거짓말하는 날, 위의 모델 라이트사이징 결정이 옳다고 가정되는 대신 실제 트레이스에 대해 시험되는 편이다.
• ercan.cloud의 The AWS Well-Architected Framework: A Key to Cloud Success, 이번 편이 사실상 하나의 긴 풀이 예제인 Cost Optimization 필러, 약정하기 전에 측정하라를 다룬다.

위 표에서 잘라낸 런북과 비용 스윕 에이전트의 에이전트별 내역과 모든 숫자를 실제 계정에 대해 다시 돌려보기 위한 체크리스트를 포함한 전체 docs/sizing-model.md는 동반 저장소인 github.com/flightlesstux/agents-on-call에 있다. 이런 플랫폼을 대규모로 운영할 때의 데이터베이스와 인프라 쪽 이야기는 ercan.cloud에, 허브는 ercanermis.com에 있다.